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
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'm currently wasting my time trying to figure out why WAS won't load my EAR and why said EAR have problem.
Context:
One of my colleague updated a version of a jar and then my m2e seem to have not picked up and was giving thousand of error (was working fine before)
I tried to check if it was Nexus (work fine). My encrypted password in the setting.xml (work fine).
I decided to try maven from the command line, everything worked fine there to.
When I tried again in RAD (IBM eclipse) everything was now ok, no more error.
I then proceeded to put the generated EAR in my websphere server via add and remove project and I get multiple error when I try to start the server with that ear. (see below)
I though that because it was compiled via maven cmd prompt, I might have compiled with the wrong jvm or something so I deleted my maven repo (.m2 in the user) and try to get the jar via m2e in RAD only.
It's worked until I started the server with the new EAR and got the same set of error.
Any idea on what to do to get rid of these error and have a healthy server.
Here some of the error:
[11/10/17 12:08:51:994 EST] 00000075 annotation W
com.ibm.ws.webcontainer.annotation.WASAnnotationHelper collectClasses
SRVE8000W: Skipped class that failed to initialize for annotation
scanning.
java.lang.ClassNotFoundException: org.springframework.web.servlet.tags.form.SelectTag at
java.lang.Class.forNameImpl(Native Method) at
java.lang.Class.forName(Class.java:219) ...
[11/10/17 12:09:00:282 EST] 00000075 wtp W
org.eclipse.jst.j2ee.commonarchivecore.internal.strategy.TempZipFile
clearTempFile Failed to delete temporary file [
C:\IBM\WebSphere\AppServer-x86\profiles\chris_pro\wstemp\appdepl15fa68a2a21\AuthRenfClientWeb-2.0.26.war2406380505527260260.tmp
] [11/10/17 12:09:00:433 EST] 00000075 SinglePathCla E WSVR0120E: An
error occurred processing com.mycom.bla.testalive.TestAliveServlet
java.io.FileNotFoundException:
C:\IBM\WebSphere\AppServer-x86\profiles\chris_pro\wstemp\appdepl15fa68a2a21\Client-1.61.5-SNAPSHOT.jar6655053587500024283.tmp
(The system cannot find the file specified.) ...
SRVE0266E: Error occured while initializing servlets: {0}
javax.servlet.UnavailableException: SRVE0203E: Servlet [SecurityManager]:
com.mycom.bla.pres.request.http.HttpSecurityManagerServlet was found,
but is missing another required class. SRVE0206E: This error typically
implies that the servlet was originally compiled with classes which
cannot be located by the server. SRVE0187E: Check your class path to
ensure that all classes required by the servlet are present.SRVE0210I:
This problem can be debugged by recompiling the servlet using only the
classes in the application's runtime class path SRVE0234I: Application
class
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 tried to deploy a Vaadin hello world application in JBOSS. The application is as simple as it can be.
My development environment is eclipse for java EE + tomcat
java.lang.RuntimeException: Error configuring property: includeWebInfInClasspath for WarClassLoaderDeployer
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
(...)
Caused by: java.lang.IllegalArgumentException: No such property includeWebInfInClasspath for bean org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer available [java2ClassLoadingCompliance, parentFirst, requiredInputs, filteredPackages, allInputs, deploymentRegistry, class, stage, wantComponents, componentsOnly, input, inputs, relativeOrder, output, useUnitName, outputs, topLevelOnly]
I have tried to google this error with no success.
Does anyone have any clues?
Is it a web server configuration or my *.war is missing something?
EDIT:
This error occur when I start the server after placing my *.war in the folder.
My JBOSS version is 5
I guess, you're using an old JBoss 5.
The WarClassLoaderDeployer is configured in the file server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml. (The 'default' directory should be changed to whatever you passed as -c parameter) Open the file, find the WarClassLoaderDeployer bean and drop the line defining the property with name includeWebInfInClasspath.
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.