I've found a similar issue described in detail in the scala mailing list (also here). It seems to be related to this change in classpath management when creating scala interpretation environments.
In my case both scala-library and scala-compiler are included in the war being deployed to WebLogic 10.3 (camel version: 2.8.0, jvm: oracle 1.6).
The exception is shown below:
com.sun.jersey.api.container.ContainerException: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeToUsingServletTemplateEngine(ScalateTemplateProcessor.scala:190)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:136)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:44)
at com.sun.jersey.spi.template.ResolvedViewable.writeTo(ResolvedViewable.java:103)
at com.sun.jersey.server.impl.template.ViewableMessageBodyWriter.writeTo(ViewableMessageBodyWriter.java:83)
Truncated. see log file for complete stacktrace
Caused By: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:784)
at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:643)
at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:374)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:368)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:426)
Truncated. see log file for complete stacktrace
Caused By: scala.tools.nsc.MissingRequirementError: object scala not found.
at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:653)
at scala.tools.nsc.symtab.Definitions$definitions$.getModule(Definitions.scala:603)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackage(Definitions.scala:145)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackageClass(Definitions.scala:146)
at scala.tools.nsc.symtab.Definitions$definitions$.AnyClass(Definitions.scala:176)
The question: is it possible to make camel web-console work in this environment?
No its a problem with WebLogic. Scalaete needs to add special support for WebLogic, as WebLogic does classloading a bit differently, than the usual practice.
Related
I have a Java-web application running on Tomcat 9. It works fine on a Windowns machine. But after deploying this app on a Debian Linux server I've encountered java.lang.StackOverflow exceptions on some particular pages. Here is the beginning of the stacktrace log:
27-Dec-2017 08:54:43.746 SEVERE [https-jsse-nio-9443-exec-3]
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for
servlet [jsp] threw exception
java.lang.StackOverflowError
at java.io.UnixFileSystem.canonicalize0(Native Method)
at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:172)
at java.io.File.getCanonicalPath(File.java:618)
at org.apache.catalina.webresources.AbstractFileResourceSet.file(AbstractFileResourceSet.java:90)
Please, see full stacktrace here:
https://pastebin.com/0AmFDY8F
As far as I understand, the exception occurs while compiling the JSP page source by Jasper and it's somehow related to the resolving of Linux paths / directories. Could anybody please help me to figure out what the exact problem is? I didn't create any symbolic links, if the problem can be related to this.
According to your stack trace, the problem is caused by not being able to find a specific path as resolved by your Spring framework:
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:154)
...
Caused by: java.io.IOException: JSPException including path '/struct/context/tutorials.jsp'.
The Spring framework is likely using the canonical paths to resolve the file, and it fails perhaps because there is some quirk in the framework related to the type of Unix system you are deploying to.
Please reference this in the Spring documentation:
https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-install-supported-operating-systems
The default script supports most Linux distributions and is tested on CentOS and Ubuntu. Other platforms, such as OS X and FreeBSD, will require the use of a custom embeddedLaunchScript.
Notice that Debian was not listed. Hopefully this puts you on the right path.
If I'm chasing a red herring here, I'm sorry - but you haven't given us much to go on.
Finally I've found what caused the StackOverflow exception. I have a recursive JSP tag call to render nested options for a <select> tag. After removing the recursion, the exception disappeared. Sure, it's just a workaround, so I'm still wondering why it works fine on Windows and doesn't on Linux.
I am installing solr on WAS 8.5.5 with IBM jdk 7.
I deployed the solr as a war and added solr.data.dir and solr.solr.home to custom properties.
Upon accessing the url: http://localhost:9080/solr,
I see the below error on the browser:
Error 500: javax.servlet.ServletException: Filter [SolrRequestFilter]: org.apache.solr.servlet.SolrDispatchFilter was found, but is missing another required class
And the following error in the logs:
SRVE0293E: [Servlet Error]-[com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor]: java.lang.NoClassDefFoundError: org.apache.solr.servlet.SolrDispatchFilter (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:176) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1600) at java.beans.Beans.instantiate(Beans.java:241) at java.beans.Beans.instantiate(Beans.java:89) at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:533) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:475) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:308) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:380) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:892) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1025).....
The lib folder of WEB-INF do contain the solr dependencies
Any Help from anybody ?
After scratching my head for 48 hours, finally able to make SOLR up and running on WebSphere.
Looks like the whole fundamental is to understand the class loading strategy on WAS8, and hence choosing the right strategy.
Have enumerated the different steps for solr deployment on WAS 8
Solr Deployment on WebSphere 8.5.5
I have been using Neo4J 1.8.x as an embedded database in an application framework that breaks the regular ServiceLoader used by Neo4j. So far, I've worked around this issue by using the OSGi instructions for Neo4j. This has worked great.
However, these OSGi instructions no longer work for 1.9.0, 1.9.1 or 2.0.0-M03. When initializing the embedded database I get this exception:
java.lang.ExceptionInInitializerError
at plugins.fritter.Fritter.setupNeo4j(Fritter.java:240)
at plugins.fritter.Fritter.runPlugin(Fritter.java:106)
at freenet.pluginmanager.PluginHandler.startPlugin(PluginHandler.java:45)
at freenet.pluginmanager.PluginManager.realStartPlugin(PluginManager.java:394)
at freenet.pluginmanager.PluginManager.startPluginFile(PluginManager.java:367)
at freenet.clients.http.PproxyToadlet$3.run(PproxyToadlet.java:157)
at freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:247)
at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:187)
at freenet.support.io.NativeThread.run(NativeThread.java:129)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.neo4j.graphdb.factory.GraphDatabaseSettings.<clinit>(GraphDatabaseSettings.java:79)
... 9 more
I am aware that the OSGi setup instructions have changed from 1.9.0 and higher versions OSGI, but the new initialization methods do not address the issue.
Is neo4j > 1.8.3 still supported in a non-ServiceLoader / OSGi context and, if so, what is the proper way to set it up?
As test project I've create a very simple WebService using wsdl and jax-ws. The client runs very well if it is deployed as web application in GlassFish but if I start the same (WebService-)Code in Eclipse directly, I get the following error:
WARNUNG: Input Action on WSDL operation AddNumbers and #Action on its associated Web Method addNumbers did not match and will cause problems in dispatching the requests
Exception in thread "main" java.lang.NoClassDefFoundError: org/glassfish/ha/store/api/BackingStoreException
at com.sun.xml.ws.rx.mc.runtime.McConfigurationFactory.createInstance(McConfigurationFactory.java:66)
at com.sun.xml.ws.rx.mc.runtime.McTubeFactory.createTube(McTubeFactory.java:68)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:84)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:130)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:228)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:205)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:178)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:85)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:608)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:348)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:312)
at javax.xml.ws.Service.getPort(Service.java:134)
at mnm.namedesdienstes.webservice.service.NameDesDienstesService.getNameDesDienstesPortTypePort(NameDesDienstesService.java:56)
at webserviceClient.NameDesDienstesClient.myTest(NameDesDienstesClient.java:12)
at webserviceClient.NameDesDienstesClient.main(NameDesDienstesClient.java:25)
Caused by: java.lang.ClassNotFoundException: org.glassfish.ha.store.api.BackingStoreException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 16 more
After some research I found out that it must have something to do with different versions of some library files. So now my question is, how can I "fix" my eclipse java execution to run my webservice client correctly? I've found some tips to copy some jar to an endorsed-directory, but which jars into which directory :-)
I'm using Max OS 10.6.8, Eclipse Project uses JVM 1.6. My Mac Java Version is
xmacbook:~ cstraube$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
UPDATE: My first try (thanks to the link from remipod) I performed the following steps:
Get the directory of endorsed lirbaries with System.out.println(System.getProperty("java.endorsed.dirs"));
Next, I copied the two files JAXWS2.1.7-20090419.jar and JAXB2_20080513.jar (both Version 2.1.7) into this directory
Unfortunately I get still the same error
I have similar problem with yours when deploying web service (JAX-WS) in tomcat 7.
The missing class definition could be found in ha-api.jar.
org/glassfish/ha/store/api/BackingStoreException
You should add the ha-api.jar (From JAX-WS distribution) into server lib. For my case, the eclipse run tomcat 7, so the location is (Tomcat 7.0\lib).
You have to copy the fitting versions of jaxws-api.jar and jaxb-api.jar into the directory /Library/Java/Home/lib/endorsed (Mac).
Have a look at this link JAX WS with WS 2.1.1. You will need to give precedence to your version of jaxws to the provided jaxws from the jre 1.6.
Edit:
Glassfish already includes some libraries, as well as java 6. I had to track down version conflicts with jaxws in glassfish 3.1 / 3.1.1 and java 6 / 7. You might check the exact java runtime eclipse uses to start the application and look for duplicate jars on the effective classpath.
The endorsed mechanism just provides an easy and error prone way to override the included jaxws distribution. Error prone, because your colleague will suffer from the same problem.
I havn't seen the exception org.glassfish.ha.store.api.BackingStoreException in the context of jaxws. Your version conflict could be created by another library than jaxws...
I experienced the exact same exception
org.glassfish.ha.store.api.BackingStoreException
And after ensuring my JAX-WS and JAX-B jars were all the same version the issue was still occurring.
THE FIX: I then added the ha-api.jar to the WEB-INF\lib directory and this solved the issue.
The clue here was the "ha" package in the exceptions class path as seen above. Hope this helps!
I'm trying to deploy a WAR in GF V3 that has CXF as a dependency and I get the following exception:
[#|2011-02-08T07:34:15.736-0800|WARNING|oracle-glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=32;_ThreadName=http-thread-pool-8080-(2);|StandardWrapperValve[MyServlet]: PWC1406: Servlet.service() for servlet MyServlet threw exception
com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://254.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:241)
at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:141)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:376)
at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:129)
at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:82)
at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:311)
at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:62)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:77)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:121)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:224)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:201)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:174)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:81)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:602)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:344)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:326)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:308)
at javax.xml.ws.Service.getPort(Service.java:99)
at com.mycompany.myapp.webserviceclient.SomeWebserviceService.getSomeWebservicePort(SomeWebserviceService.java:58)
This sorta indicates to me that there is a bundle in my WAR\lib directory that is causing problems, but when I expand the WAR and do a search on META-INF\services I do not find anything that is close what is outlined in the exception.
I originally had CXF and it's transitive dependencies in the war\lib dir, but I've since removed that and still encounter the same error.
Nothing useful comes up when searching google and I'm at a loss here.
Does anyone know what might be going on here?
EDIT #1
Another symptom of this is that the tester pages for deployed web services will not work properly.
I had a similar problem with my glassfish3.1. Below is a stack trace
Caused by: com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://96.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:245)
at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:145)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:380)
at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:133)
at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:86)
at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:315)
at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:67)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:84)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:130)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:228)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:205)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:178)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:85)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:608)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:348)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:312)
at javax.xml.ws.Service.getPort(Service.java:134)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:563)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:169)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104)
at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1002)
... 20 more
The problem was traced to the conflicting mappings for "com.sun.xml.ws.api.pipe.TransportPipeFactory" inside two different modules.
prompt> grep -rl com.sun.xml.ws.api.pipe.TransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules*
modules/webservices-osgi.jar
modules/sun-javaee-engine.jar
prompt> grep -rl com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules/*
modules/sun-javaee-engine.jar
Clearly, the required file was sitting in the wrong jar "sun-javaee-engine.jar".
Above, "sun-javaee-engine.jar" is loaded by the "Java EE Service Engine Module". Once I removed the module (using glassfish update tool) everything started working fine.
EDIT #1:
Here is how to remove the module using the update tool on the Unix command line:
sudo ./pkg uninstall sun-javaee-engine