We Keep Coding

Deploy war to JBOSS

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.

Could not load any resource bundle by com.sun.org.apache.xerces.internal.impl.msg.XMLSchemaMessages

I have a web application and using jenkins for build and deployment to glassfish 3+ server. But now I am facing a problem. The jenkins is building the application successfully but when it tries to deploy the application to the target server then it failed with following error
Deploying /var/lib/jenkins/workspace/Gordon Converter Dev/target/gordons-dev-deployment.war to container GlassFish 3.x Remote
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.util.CargoException: Deployment has failed: Action failed Deploying application to target server failed; Error occurred during deployment: Exception while deploying the app [gordons-dev-deployment] : Could not load any resource bundle by com.sun.org.apache.xerces.internal.impl.msg.XMLSchemaMessages. Please see server.log for more details.
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.waitForProgressObject(AbstractJsr88Deployer.java:220)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.deploy(AbstractJsr88Deployer.java:76)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:142)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:920)
at hudson.FilePath.act(FilePath.java:893)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:756)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1040)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:669)
at hudson.model.Run.execute(Run.java:1735)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Finished: FAILURE

I just got this error too and I noticed that Java had auto updated itself to the latest version. So I was compiling the application with Java 1.7.0_131, but Glassfish3 was still running under Java 1.7.0_121. My solution was to restart Glassfish so that it was running under the new version of Java 1.7.0_131. I guess I could have also downgraded my Java back to 1.7.0_121 and compiled my application with that... Bottom line here is to make sure that you are compiling with the same version of Java that Glassfish is running.

java.lang.NoSuchMethodError: org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest

I am handling file uploads by a multipart filter as described here. I created a WAR file and deployed on Weblogic 10.3.3 server and got error:
<Dec 8, 2011 5:37:07 PM IST> <Error> <HTTP> <BEA-101020> <[ServletContext#26087289[app:playground module:playground.war path:/playground spec-version:null]] Servlet failed with Exception
java.lang.NoSuchMethodError: org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(Lorg/apache/commons/fileupload/RequestContext;)Ljava/util/List;
at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at net.balusc.webapp.MultipartFilter.parseRequest(MultipartFilter.java:169)
at net.balusc.webapp.MultipartFilter.doFilter(MultipartFilter.java:123)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684)
Truncated. see log file for complete stacktrace
Then I deployed same WAR file on Tomcat 7.0.11 server and it is successfully running. How is this caused and how can I deploy successfully on Weblogic?

Deployment on Weblogic 10.3.3 results in an error:
java.lang.NoSuchMethodError: org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(Lorg/apache/commons/fileupload/RequestContext;)Ljava/util/List;
Deployment on Tomcat 7.0.11 is successful.
Weblogic already ships with Apache Commons FileUpload libraries. This error indicates that they are of an older version than which you have in /WEB-INF/lib.
You have at least 3 options:
Remove the JARs from /WEB-INF/lib.
Replace them by exactly the same version as Weblogic is using.
Change the Weblogic classloading policy to load classes from application first.

You can use following API to upload files to JBoss Server
http://commons.apache.org/fileupload/index.html

Check If your Jar Library has duplicate Jar files with Different versions.
Delete the old version file.

Apache Camel web console's scalate servlet fails in WebLogic

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.

Deploying WAR with CXF in Glassfish V3

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