I have a .war application module, that can be successfully deployed without any exotic changes and server tuning. However, i was unable to deploy this app to GF 3.1.2: server throws following exception:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoSuchFieldError: theInstance
What i am doing wrong? Has anyone suggest me something? Is there any additional settings that i should perform to deploy .war module successfully?
Thanks a lot in advance.
UPD
More precise log entry:
javax.xml.bind.JAXBException: Provider com.sun.xml.bind.ContextFactory_1_0_1 could not be instantiated: javax.xml.bind.JAXBException
- with linked exception:
[java.lang.NoSuchFieldError: theInstance]
- with linked exception:
[javax.xml.bind.JAXBException
- with linked exception:
[java.lang.NoSuchFieldError: theInstance]]
Sounds like a class loader issue.
You need your WEB-INF/lib JAXB jars used ahead of the GlassFish JAXB jars.
Or change your app to use the versions GlassFish 3.1.2 is bundled with.
Servlet spec says that web applications should use the local class loader before delegating to the parent. I think GlassFish delegates to the the parent class loader for web applications by default. Use <class-loader delegate="false"/> in web.xml or glassfish-web.xml.
Note there may be other ways to modify the class loader in GlassFish if this does not work.
This type of issue is common during deployment to many application servers.
I've used GlassFish daily for the last 5+ years and see this every so often.
Recently saw a similar issue when deploying to JBoss on CloudBees, and modified a deployment descriptor accordingly.
Googling "glassfish prefer web-inf/lib jars".
Response To psed comment below
EJB interfaces must reside in the class path hierarchy shared by the Web module and EJB module. If you have an EJB interface jar in WEB-INF/lib and another copy of the EJB interface jar on the EJB module classpath, you would get a ClassCastException when injecting/locating the EJB in your web application. I assume WebServices have the same issue. Sharing the EJB interface jar though an EAR should resolve this issue though. Note there may be other issues I am unaware of
You should not bundle JAXB jars with your application - Glassfish already has them, and it seems this is causing a conflict (incidentally, I've been digging through JAXB code recently, and theInstance is part of a static class defined by MarshallerImpl)
You should place your all jar files to your runtime server lib...
This instruction is for GlassFish 3.1.2
The issue is runtime classes from JAXB 2.2.5 are not backward compilable with JAXB 1 code.
This issue was fixed with JAXB 2.2.6, however, it's not in latest GlassFish release. So, either you wait until the next GlassFish upgrade or you do it manually.
Here is how i did,
I removed the 2 bundle files from GlassFish module
C:\glassfish3\glassfish\modules\jaxb-osgi.jar
C:\glassfish3\glassfish\modules\endorsed\jaxb-api-osgi.jar
Clear the osgi-cache by deleting all the subfolder in
C:\glassfish3\glassfish\domains\domain1\osgi-cache
Download JAXB 2.2.6 from ORACLE JAXB
Extract the zip file to a temp location [C:\Java\jaxb-ri-2.2.6\jaxb-ri-2.2.6\osgi]
copy C:\Java\jaxb-ri-2.2.6\jaxb-ri-2.2.6\osgi\jaxb-osgi.jar to C:\glassfish3\glassfish\modules\
copy C:\Java\jaxb-ri-2.2.6\jaxb-ri-2.2.6\osgi\jaxb-api-osgi.jar to C:\glassfish3\glassfish\modules\endorsed\
restart your server ... i hope this will help. Good Luck
Related
I have an application which is able to run properly in tomcat, but when added a dependency of another application in maven I encountered the error below when deploying on Tomcat (the build works just fine):
java.lang.NoSuchFieldError: REFLECTION
There could be conflicts in the jars as imported by your application and as that are already present in the lib folder of tomcat directory.
Remove the duplicate jars from the lib folder tomcat directory. That may resolve the issue.
Teja: has maven shade helped you anyhow? I'm following a similar issue in Jetty now and I'm interested in trying different approaches. So far I've discarded different versions that may be adding noise.
Application structure description: Ear application with ejb module (.jar), jboss-seam (.jar) and war module (.war).
I have a StartupAction.class (seam component) annotated with org.jboss.seam.annotations.Startup. During application deployment I need to get the resource from application.war module root (application.war/pages/page.xhtml) and WEB-INF/classes (application.war/WEB-INF/classes/file.properties)
Jboss 4.2
Thread.currentThread().getContextClassLoader().getResourceAsStream("file.properties") would fetch the file from application.war/WEB-INF/classes/file.properties.
Jboss 7.1.1
Code from above doesn't work with Jboss 7.
I know that the class loading changed but I can't figure it out how to get into application.war in jboss 7.
Is it possible to do this? Are there any example of this?
Thanks in advance.
As mentioned by #BalusC, you will not be able to read a properties file that is embedded in a web module from any other modules (EJB or otherwise) that are packaged in your EAR.
The fact that this works in JBoss 4.x is a consequence of it providing backwards compatibility for even earlier versions of JBoss. Additional configuration is required in JBoss 4.x in order for it to use specification compliant class loading. JBoss 7.x and newer use specification compliant class loading by default.
If your properties file contains external configuration that is intended to be accessible after deployment then you might consider the approach described in How to put an external file in the classpath.
However, if it is effectively static data then you should package the properties file in a jar module and place it in the the lib directory of your EAR.
In jboss7, you have a classloader for each subdeploy.
In your case, Thread.currentThread().getContextClassLoader() will return the classloader of the current deployment.
To fix your problem, you could try this:
SomeRandomClassContainedInsideTheWAR.class.getClassLoader()
Check this guide to learn more about JBoss7 ClassLoader
https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
I have a war that uses the errai-bus, which depends on guava 14.0.1. I'm deploying the app with Jboss, but when I do, Jboss is using its weld version of guava, which is guava r6 (very old). This causes horrible class loading issues and the errai-bus completely fails to work.
Even when I declare guava 14.0.1 as a top-level dependency in my pom, it still uses guava r6. How can I stop Jboss from loading the wrong guava version for my war?
I've tried to look up info about how to do this with the class loader files in Jboss AS 6, but I can't seem to find any documentation.
You can try add the following jboss-classloading.xml to your WEB-INF folder:
<classloading xmlns="urn:jboss:classloading:1.0"
name="mywar.war"
domain="mywar_domain"
parent-domain="Ignored"
export-all="NON_EMPTY"
import-all="true">
</classloading>
In this case, put the war's classloader in the mywar_domain which is shared with all other applications that don't define their own domain. Also choose to look at all other classes exported by other applications import-all and to expose all our classes to other classes export-all.
What you get when you deploy this file, is that the Web application classloader will act as top-level Classloader so there will be no conflict with the same classes in the server's library.
See also:
JBoss 5 - ClassLoading
Demystifying the JBoss5 jboss-classloading.xml file
Anyway JBoss AS 6 is out of date, and have a lot of de bugs unresolved. You would have to see the possibility of using a newer version (Wildfly or JBoss EAP 6).
But the class found in jboss-4.2.2.GA/client/jbossall-client.jar. Still the application is throwing exception.
Should we move the file to server/default/lib
First lets clarify whether the dependency of this class is in your webapp or from jboss itself. If it is in your webapp, better copy this jar (provided you already confirmed that this jar contains the complained class) to webapp corresponding WEB-INF/lib folder. In case if is from jboss startup itself, better copy the jar to server/default/lib folder (assuming you are using default profile of jboss server)
Fixed the issue by using ObjectMessage by replacing SpyObjectMessage. SpyObjectMessage seems like JBoss mq implementation (JBoss 4.0.5)
I have an EJB and a WEB module in my IntelliJ, created 5 entities that I would hope to load into a database using annotations.
I go to project settings, under modules, and select that I want to add JPA facet, I know have a EJB, WEB and JPA facet. I use eclipselink, so I checked that under JPA settings, I then added my persistence.xml file, configured the file.
Problem is that when deploying, it simply will not deploy the persistence.xml file, which means I can not find it under my glassfish 3.0 server when selecting my application under deployment descriptors. I only find my sun-web-ejb.xml under the EJB module. persistence.xml is not under the WEB module either, but I assume it should be under the EJB module anyway.
Is it intended that my persistence.xml should not be loaded on the server so that I can find the xml file under GF admin console (applications -> EJB module of mine -> deployment descriptors) ?
If this is not intended, is there anything in particular I need to do in IntelliJ to make persistence.xml being deployed on server? Maybe its something in particular I need to do with my JPA facet?
Thank you for any feedback on this, I can ofcourse provide more detailed information about my setup if neccessary.
I only find my sun-web-ejb.xml under the EJB module.
That's already weird. If I'm not wrong, this is a proprietary deployment descriptor for the Web module.
persistence.xml is not under the WEB module either, but I assume it should be under the EJB module anyway
It all depends on how you package and deploy your entities, which can be done in several ways (see What You May Need to Know About Persistence Unit Packaging Options).
If your entities are packaged in an EJB-JAR, the persistence.xml must be placed in the META-INF directory.
But you could package them inside the Web module, this would be simpler in your case. See the above link.
Is it intended that my persistence.xml should not be loaded on the server so that I can find the xml file under GF admin console (applications -> EJB module of mine -> deployment descriptors)?
I suggest to check that the physical JAR contains the META-INF/persistence.xml.
If this is not intended, is there anything in particular I need to do in IntelliJ to make persistence.xml being deployed on server? Maybe its something in particular I need to do with my JPA facet?
Can't say. Maybe the following link could help: Enabling JPA Support.