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.
Related
I have installed cave-repository to Fuse and afterwards I created a new repository. When I try to reach repository via http, I receive the following error from undertow.
NOTE: I did no change to undertow settings. It is a default fuse package.
java.lang.IllegalStateException: UT010026: Async is not supported for
this request, as not all filters or Servlets were marked as supporting
async at
io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:1023)
at
org.apache.karaf.cave.repository.service.maven.MavenServlet.doGet(MavenServlet.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:750) at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.ops4j.pax.web.service.undertow.internal.Context$1.lambda$wrap$0(Context.java:615)
at
io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:119)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I tried the same steps (installing and creating cave repository) in karaf with jetty, and everything works fine there.
During the search in google, I have found the following page in redhat but due to subscription I am not able to see the content.
https://access.redhat.com/solutions/4222431
The problem is that (as I commented under https://ops4j1.jira.com/browse/PAXWEB-1254) Cave's MavenServlet is registered using plain HttpService.registerServlet() without specifying async supported flag. It works with Jetty only by coincidence (doesn't work - as expected - with pax-web-tomcat and pax-web-undertow).
Karaf Cave should either use Pax Web specific WebContainer extension to org.osgi.service.http.HttpService or register the servlet using annotations.
We'll continue the discussion in Karaf/Cave project.
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.
This code
private AlternatorDBClientV2 Client;
#Before
public void setUp() throws Exception {
this.Client = new AlternatorDBClientV2();
}
gives me this exception
java.lang.IllegalStateException: Unrecognized prefix for the AWS http client class name AlternatorDBClientV2
at com.amazonaws.AmazonWebServiceClient.computeServiceName(AmazonWebServiceClient.java:546)
at com.amazonaws.AmazonWebServiceClient.getServiceNameIntern(AmazonWebServiceClient.java:509)
at com.amazonaws.AmazonWebServiceClient.configSigner(AmazonWebServiceClient.java:202)
at com.amazonaws.AmazonWebServiceClient.setEndpoint(AmazonWebServiceClient.java:135)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.setEndpoint(AlternatorDBClientV2.java:273)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.init(AlternatorDBClientV2.java:109)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:96)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:91)
at com.salesfront.test.CreateUserTest.setUp(CreateUserTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
The stack trace line numbers indicate you have configured version 1.6.8 of the AWS Java SDK on your application's pom.xml file.
I reviewed successive Git tags for the AWS Java SDK project which I cloned to my workstation from its GitHub site:
https://github.com/aws/aws-sdk-java
The Alternator project is built and regression tested using version 1.6.4 of the AWS Java SDK.
Since version 1.6.4 of the AWS Java SDK Amazon has been adding logic to auto-detect the data center region and service to connect to based on parsing the endpoint URL and the actual name of the specific sub-class of AmazonWebServiceClient.java
The Alternator emulator clients are just such sub-classes of AmazonWebServiceClient but they do not follow the expected naming conventions.
To use the current version of Alternator you should revise your pom.xml to reference version 1.6.4 of the AWS Java SDK. You can experiment with using version 1.6.5, 1.6.6, or 1.6.7, but definitely 1.6.8 is incompatible with Alternator.
There is a pending Pull Request at the Alternator GitHub repository that resolves this issue.
https://github.com/mboudreau/Alternator/pull/84
Since the original answer, newer versions of Alternator have been created that allow use of higher versions 1.6 and 1.7 of the AWS SDK for Java.
Refer to the Issues and Pull Requests sections of the Alternator GitHub repository:
https://github.com/mboudreau/Alternator
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'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?