I've setup SmartTarget on a separate server and got the SmartTarget Deployment Web Service working so when content is published from Tridion, instead of dropping the XML content generated on the local file system it sends it via the web service to the server where Fredhopper is installed. All good so far...
The problem I have is the deployed XML files are being dropped in Fredhoppers root directory C:\fredhopper\instance01\FAS and not the directory where XML files are loaded from (C:\fredhopper\instance01\FAS\data\xml\incoming\batch)! The only place I've found in configuration for specifying the correct pickup directory is in the SmartTargetDeploymentWebService.properties file in SmartTargetDeploymentWebService.war, but this is setup correctly to point at C:\fredhopper\instance01\FAS\data\xml\incoming\batch
Anyone know what might be causing this? I might just be being stupid so hopefully someone with some experience will be able to point me in the right direction ;)
UPDATE: Spotted this in the logs for when the deployment service first loads:
2012-07-19 12:56:05,909 ERROR SmartTargetDeployment - Unable to load configuration for fredhopper.location
java.lang.NullPointerException: null
at java.util.Properties$LineReader.readLine(Properties.java:418) ~[na:1.6.0_23]
at java.util.Properties.load0(Properties.java:337) ~[na:1.6.0_23]
at java.util.Properties.load(Properties.java:325) ~[na:1.6.0_23]
at com.tridion.smarttarget.web.SmartTargetDeployment.<init>(SmartTargetDeployment.java:33) ~[classes/:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.6.0_23]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [na:1.6.0_23]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [na:1.6.0_23]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [na:1.6.0_23]
at java.lang.Class.newInstance0(Class.java:355) [na:1.6.0_23]
at java.lang.Class.newInstance(Class.java:308) [na:1.6.0_23]
at com.sun.xml.ws.api.server.InstanceResolver.createNewInstance(InstanceResolver.java:215) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.api.server.InstanceResolver.createDefault(InstanceResolver.java:180) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:124) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147) [webservices-rt-1.4.jar:1.0]
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108) [webservices-rt-1.4.jar:1.0]
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3669) [tmp6105104870192773276catalina.jar:na]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4104) [tmp6105104870192773276catalina.jar:na]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) [tmp6105104870192773276catalina.jar:na]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) [tmp6105104870192773276catalina.jar:na]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) [tmp6105104870192773276catalina.jar:na]
Can you check the location specified in WEB-INF/classes/SmartTargetDeploymentWebService_conf.xml?
According to the documentation, that's where the location should be set.
Generally if you find null reference exceptions in the realm of XML configuration files, it's helpful to perform schema validation of the configuration files. I don't know if the schemas are available for this specific config. #Nuno - do you know?
Related
BLUF: I'm getting a stackoverflow starting my Liberty server with a single war file before it reaches any of my code. I can't debug what is causing the problem. I tried adding trace statements to server.xml but never got files I could interpret (were binary) and trying to Open Log Files had no choices available (greyed out). If anyone has any ideas how to determine what is causing the stack overflow I'd appreciate the help. Thanks in advance. My code does use #Inject but I don't think this is the issue as all works fine if I move code from a separate project/jar into the war project.
Running wlp 17.0.0.1 when starting a single war using shared libraries to jar files in a single directory, I get a StackOverflowError before any of my code is reached (based on setting breakpoints in the RestServicesApplication and any static initializers).
This problem only occurs when some classes have been moved to a separate project and therefore into a separate jar (e.g., moving them back to the war project allows all to run fine).
I've checked that all classes and methods references are public. I'm calling public static methods in the new jar file.
I'm not sure how to figure out the problem as no references to my code are in the ffdc files in the stack traces.
I've verified the needed classes are in the jar file and there are no duplicate classes being referenced.
Essentially, the class in the war file has a call like:
public static JSONObject processFuzzyMatch(ID session,
ID userID, JSONObject request)
throws ILDException {
try {
return NLUFuzzyEntityMatcherFunction.processFuzzyMatch(request);
} catch (Exception e) {
throw new ILDException(e);
}
}
and NLUFuzzyEntityMatcherFunction is in the jar file declared as:
public static JSONObject processFuzzyMatch(JSONObject request)
throws Exception
Here is an example of the reported problem with the last line repeating (for the stack overflow...)
Stack Dump = com.ibm.ws.container.service.state.StateChangeException: java.lang.StackOverflowError
at com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:33)
at com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:51)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:376)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:403)
at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:66)
at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1253)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:866)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.StackOverflowError
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:819)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:88)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.wsspi.kernel.service.utils.FileUtils.fileExists(FileUtils.java:85)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:232)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:207)
at com.ibm.ws.artifact.loose.internal.LooseArchive.getEntry(LooseArchive.java:782)
at com.ibm.ws.artifact.overlay.internal.DirectoryBasedOverlayContainerImpl.getEntry(DirectoryBasedOverlayContainerImpl.java:838)
at com.ibm.ws.adaptable.module.internal.AdaptableContainerImpl.getEntry(AdaptableContainerImpl.java:113)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:613)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
(above line repeats due to stack overflow)
This is a known problem on Liberty. The fix to that problem will be available on Liberty 17.0.0.3.
You can use some workarounds:
I assume you have a folder named WEB-INF within a jar. Change the folder name to something else. That folder name causes the JSP engine to go to the web module's WEB-INF (scanning everything again!), instead of the jar's WEB-INF.
Try setting the JSP configuration parameter disableTldSearch to true; this may be troublesome if you are using custom tag libraries. With the property set, all your custom TLD files need to be declared in the web.xml.
Disable CDI; I know this may not be possible for you as you mentioned you are using injections.
Somehow I screwed up the project settings for the jar project (likely because I'd copied the pom.xml from the Web project and forgot to change it to jar...). This may have resulted in the screwed up xml file in the /apps folder with an embedded reference to a non-existent war file (see below):
<?xml version="1.0" encoding="UTF-8"?>
<archive>
<archive targetInArchive="/WEB-INF/lib/ildMicroServices-1.0.0-SNAPSHOT.jar">
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/test-
classes" targetInArchive="/WEB-INF/classes"/>
</archive>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/m2e-wtp/web-resources" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/test-classes" targetInArchive="/WEB-INF/classes"/>
</archive>
By deleting this embedded archive the problem went away.
I only found this after upgrading from Neon to Oxygen, and 17.0.0.1 to 17.0.0.2 and when setting up the new server using the old server's artifacts, I noticed the xml file in /apps didn't look correct.
I hope this helps somebody.
I have an ear file that has a validation.xml file in one of its ejb modules when I want to deploy it on Weblogic 12.2.1, then the Weblogic throws the following exception:
<BEA-000000> <Error parsing validation.xml synchronously
java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.<init>(File.java:418)
at org.eclipse.persistence.jaxb.ValidationXMLReader.parseValidationXML(ValidationXMLReader.java:147)
at org.eclipse.persistence.jaxb.ValidationXMLReader.call(ValidationXMLReader.java:67)
at org.eclipse.persistence.jaxb.BeanValidationHelper.parseValidationXml(BeanValidationHelper.java:178)
at org.eclipse.persistence.jaxb.BeanValidationHelper.getConstraintsMap(BeanValidationHelper.java:143)
at org.eclipse.persistence.jaxb.BeanValidationHelper.isConstrained(BeanValidationHelper.java:120)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:255)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:206)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.validateAndBuildJAXBElement(JAXBUnmarshaller.java:235)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:640)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:38)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:20)
at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:201)
at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:125)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:81)
at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:353)
at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:120)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.jboss.weld.util.ServiceLoader.prepareInstance(ServiceLoader.java:240)
at org.jboss.weld.util.ServiceLoader.loadService(ServiceLoader.java:214)
at org.jboss.weld.util.ServiceLoader.loadServiceFile(ServiceLoader.java:182)
at org.jboss.weld.util.ServiceLoader.reload(ServiceLoader.java:162)
at org.jboss.weld.util.ServiceLoader.iterator(ServiceLoader.java:297)
at com.oracle.injection.provider.weld.BasicDeployment.getExtensions(BasicDeployment.java:106)
at com.oracle.injection.provider.weld.WeldInjectionContainer.initialize(WeldInjectionContainer.java:92)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:64)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:41)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:39)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:753)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:263)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:67)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:601)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:171)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:121)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:343)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:895)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1422)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:454)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:181)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:643)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:617)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
The validation.xml file's content shows in the below:
<?xml version="1.0" encoding="UTF-8" ?>
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://jboss.org/xml/ns/javax/validation/configuration
validation-configuration-1.1.xsd"
version="1.1">
</validation-config>
How to deploy ear file with validation.xml on weblogic 12.2.1?
It drives me crazy too. I tried to downgrade bean validation to 1.0, but did not help.
Here they suggest to ignore it since it is warning only, set the logger to SEVERE level.
I had the same problem with web application.
In my case validation.xml was in one of my jars. I was able to fix the problem by moving the file directly to the war that was being deployed.
In case of ear file I believe the same solution should work.
I think this is a bug in EclipseLink/TopLink (which is used for JPA and JAXB binding in WLS 12.2.1 and upwards). I opened a FORUM entry in the EclipseLink forum: https://www.eclipse.org/forums/index.php/m/1759047/#msg_1759047
Summary: They try to read the validation.xml resource like this:
URL validationXml = Thread.currentThread().getContextClassLoader().getResource("META INF/validation.xml");
and then:
new File(validationXml.toURI())
but the toURI contains an URI that looks like this:
The URL.toString is: zip:/local/saladin/wls12/weblogic/12.2.1.0.0/domains/XXXX/servers/AdminServer/tmp/_WL_user/xxxx-application_1.5.5_dev-SNAPSHOT/s86txs/lib/xxx-xxxx-xxxxdatamodel-1.5.5_dev-SNAPSHOT.jar!/META-INF/validation.xml
So this is not a file, and therefore it cannot work.
The correct way would be to get the resource as Stream and not as File. But as to a solution, I don't know really how to fix it without modifying the EclipseLink source code. It is quite ugly to have those Warnings in the logfile and not being able to do anything about it.
java.lang.IllegalStateException: STREAM
at org.mortbay.jetty.Response.getWriter(Response.java:616)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:187)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:180)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:237)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:173)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:124)
at org.apache.jsp.admin.index_jsp._jspService(org.apache.jsp.admin.index_jsp:415)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2013-04-03 09:45:39.844:WARN::/solr/admin/
The above is the stacktrace that i get when try to check if solr is running by going to the admin page. I have solr integration module 7.x.1.x-dev for drupal 7 and i am using its schema.xml and solrconfig.xml on Apache Solr 3.2. In the browser, when i request the page it says missing core name in path. What would be wrong ?
Usually try to change the solrconfig.xml or schema.xml in your example/solr/conf dir or it may be related to your version of Java. One of the two most likely.
I am testing JBoss AS 7 prior to deployment with a .war file of an app running in a different server.
I get this error when I try to log onto the database via the app:
SEVERE [] (http--0.0.0.0-8080-4) java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
java.lang.ClassNotFoundException: org.apache.commons.codec.DecoderException from [Module "deployment.app.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:220)
In some forums, they suggest adding the commons-codec jar, but I already have it in JBoss, right? (in here: jboss-as-7.1.1.Final/modules/org/apache/commons/codec/main/commons-codec-1.4.jar)
OSGi is not activated, frankly I have no idea to what purpose it serves, but when I try to activate it it messes with my war as it fails to deploy...
I have JDK, but no JRE if that's any help.
JBoss AS 7 does not use OSGi by default for modular class loading. It uses JBoss Modules so this has nothing to do with OSGi.
What you need to do if you want to use the commons-codec provided with JBoss AS 7 is add a dependency to your deployment.
Modules are not visible by your artefact classes automatically. You have three possibilities:
Define a global module in your standalone.xml
http://javahowto.blogspot.de/2012/09/how-to-create-global-modules-in-jboss.html
This module will be used by all artefacts you are deploying on Jboss.
Put it into your war artefact, into the lib folder. You can do that with Maven.
Define an explicit dependency within your Manifest. https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Section Dependencies: Manifest Entries
I'm moving a Flex 3 site to Flex 4, but when I run the application, it attempts to download a .swz file from Adobe, and gives the following error:
*** Security Sandbox Violation ***
Connection to http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz halted - not permitted from http://localhost/Fl/CityGIS/main.swf
Error #2048: Security sandbox violation: http://localhost/Fl/CityGIS/main.swf cannot load data from http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz.
Failed to load RSL http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz
Failing over to RSL textLayout_1.1.0.604.swz
Following this is an attempt to download the same file from localhost.
Is there a way to configure the SDK to get these files, or an issue with the configuration of my application?
I found I only had this problem when I using: -use-network=false, and I was attempting to run the html locally and the .swf was accessing locally files (outside the flex security free folders).
My workaround is to update sdks//frameworks/flex-config.xml (in the Flash Builder directory), and swap the order runtime shared paths: for example:
<runtime-shared-library-path>
<path-element>libs/textLayout.swc</path-element>
<rsl-url>http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
<rsl-url>textLayout_1.1.0.604.swz</rsl-url>
<policy-file-url></policy-file-url>
</runtime-shared-library-path>
TO:
<runtime-shared-library-path>
<path-element>libs/textLayout.swc</path-element>
<rsl-url>textLayout_1.1.0.604.swz</rsl-url>
<policy-file-url></policy-file-url>
<rsl-url>http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
</runtime-shared-library-path>
You'll have to do this for the other 5 or so entries.
Adobe should really look at this, and fix the problem.
Hope this helps.
Cheers
Parmy
I think the problem is that the location it is using for the textLayout swc
http://fpdownload.adobe.com/pub/swz/tlf/1.1.0.604/textLayout_1.1.0.604.swz
redirects to
/pub/swz/flex/4.1.0.15186/textLayout_1.1.0.601.swf
and the cross domains policy is not happy about that.
I think this points to an issue with the version of the sdk that you are using. You can go into sdks/<FRAMEWORK_VERSION>/frameworks/flex-config.xml (in the Flash Builder directory) and see exactly how the runtime shared library path is configured for textLayout.swc. This is what I have for flex_sdk_4.1.0.15186:
<!-- TextLayout SWC -->
<runtime-shared-library-path>
<path-element>libs/textLayout.swc</path-element>
<rsl-url>textLayout_1.1.0.601.swf</rsl-url>
<policy-file-url></policy-file-url>
<rsl-url>http://fpdownload.adobe.com/pub/swz/flex/4.1.0.15186/textLayout_1.1.0.601.swf</rsl-url>
<policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url>
</runtime-shared-library-path>
I suggest try switching to the latest 4.1 sdk and recompiling.
Hmmmm - generally this is because the site you are accessing does not contain a crossdomain.xml file. However I can download it from here.
Try adding this to your compiler options: -use-network=false
Then clean and force build your app.
If that doesn't work, and just grasping for straws, but have you tried to manually download it and place it in your project lib space?
Also, are you sure you are updated to Flex 4.1?
I just checked my local KB (evernote) and mentioned that FireFox sometimes has an issue with caching, and that restarting FF solved it once for me.