I did ear deployment in weblogic 10.It conatins war, ejb jar, APP-INF, META-INF. Now When I am calling the service from war, I am getting classnot found exception.When I deploy the war file , without using ear file this service works absoulutely fine.
How to resolve this problem. How classloader will check for jars
It's impossible to solve your problem without more details but as you asked for documentation on how classloaders work in WebLogic, you will find information in Understanding WebLogic Server Application Classloading. Also have a look at Understanding J2EE Application Server Class Loading Architectures on TheServerSide.com (quite old but still perfectly valid).
In your particular case, I'd like to know if you are using Manifest Class-Path entries. More details on how your EAR is structure exactly would be also welcome. Please update your question accordingly.
Related
I have created and deployed one war for my application.
I wanted to use derby for integration testing so I created one module in Jboss.
At run time I am getting ClassCastException for same class, since the class is getting loaded twice: first from war, then from my module's jar.
To elaborate, my war, say application.war contains myderby.jar and under my module i have added myderby.jar .My class, say Custom.java, is present in myderby.jar.
If you want a jar to be accessible to multiple WARs, JARs, or an EAR and a WAR/JAR - or in fact any such combination, you can include it as a global module. Here's how it can be done.
This might also help.
As Suggested I followed the following link
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Add_a_module_to_all_deployments.html and it worked for me.
I am developing a Java EE 6 bottom-up JAX-WS to expose an EJB3.1 stateless session bean. The web service in a WAR is failing to install on deployment because it references an external jar (or shared library) which one can assume is not loaded yet.
The common suggestion is to include the jars in the /lib folder, which does fix the issue, however the jars need to remain in this external shared library location and NOT in the ear file, because they amount to 30MB.
What are some techniques to get around this issue in a Websphere (WAS v.8) environment or any server environment.
Some suggestions I have found include:
1. define classpath in META-INF file.
2. define the resources in deployment.xml
3. alter class loading order
4. (from ibm) In the case where the jars are part of a Shared Library configured on WebSphere Application Server, then a User Library must be used to configure the project for development before generating the WebService.
However, I have been unsuccessful to find any help online in these areas. Is there another technique or does anyone know anything about accomplishing this? Thanks in advance.
EDIT: If I specify the libraries in the META-INF using class-path, they are loaded before extensions, shared libraries..etc, but they are still loaded after the WAR which is not good. Again, this isn't a runtime issue because the web services are created at deployment on the fly.
I submitted a ticket to IBM. The libraries referenced by the web service are needed during deployment and must be bundled into the Ear in some fashion. I threw them in the web-inf/lib folder. However, if the referenced libraries then depend on additional libraries, these can be placed in the Shared Libraries. Seems odd to me too, but let's all just admit "shared libraries" are a hack anyways.
If you still have issues, just make sure your class loading is set to parent_last.
I have had many problems because there are different SAAJ packages with SOAP classes:
com/sun/xml/internal/messaging/saaj/soap/ in rt.jar
com/sun/xml/messaging/saaj/soap/ in saaj-impl.jar
When WebLogic uses classes from com/sun/xml/internal/messaging/saaj/soap/ and an application is created using classes from com/sun/xml/messaging/saaj/soap/, it throws exceptions like these when the app is deployed:
com.sun.xml.internal.messaging.saaj.soap.LocalStrings != com.sun.xml.messaging.saaj.soap.LocalStrings
or
java.lang.NoClassDefFoundError: com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl
My solution was create a weblogic.xml descriptor with saaj reference and including saaj-impl.jar into the war.
Question is: Can I know what SAAJ package is used in WebLogic Server?
If you use weblogic 10.3.3(or i think even any other version) , the SAAJ implementation used by is of the JDK runtime installed since the web server initializes the CLASSPATH to the JDK jars first. So you need to override it with your jar file so it can find your desired implementation first.
The only solution with weblogic that worked for me was to set PRE_CLASSPATH in weblogic setDomainEnv.cmd file like this,
set PRE_CLASSPATH=%DOMAIN_HOME%\lib\endorsed\saaj-impl-1.3.18.jar
whereby DOMAIN_HOME represents Weblogic domain, but it can be any other absolute path as well to point the jar. A bit about the issue is also described Here
What libraries are required to run a Web Service Client that has been generated from Axis 2 on JBoss. So far I have not found anything in my searches.
I assume that the following error:
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
Is due to the fact that I have place every jar file from Axis lib folder into my projects
My Solution
Did it the hard way - added and subtracted jars from my lib directory until I got it to deploy and run with no exceptions
Is what you have pasted the root cause of the stack trace? In case it is not, the problem is that probably your app is deployed with xerces related jar files in it (ex: xercesImpl-x.x.x.jar). JBoss is shipped with the xerces jars in its JBOSS_HOME/lib/endorsed folder. If the same classes are deployed with your web app this may result in class loading issues.
You can try to remove the xerces libs from your app and then test the web service client again.
Cheers!
We've been using WAS 6.1 so far to deploy our web apps. Now we need to migrate to an economics-savvy Tomcat + OpenEJB solution. The OpenEJB 3.1.2 container is plugged into Tomcat 6.18, no standalone OpenEJB server here.
So here I am, trying to deploy my EJB 2.1 objects into OpenEJB...
My problem is that the EJBs code requires external .jar libraries, and I don't know where to put them so that they are actually taken into account into the container's classpath. It works fine into catalina.home/lib, so it does into openejb.home/lib. But still I'd rather find out a way to package the EJBs so that they are easy deployed with their linked .jar dropped right into place to be used by the OpenEJB container.
It can include building up an .ear or a .jar with the right descriptor files... Any solution that works is good enough for me.
Can possibly anyone help?
Ear Approach
You can just drop it into the Tomcat webapps/ directory and it will be picked up.
Example ear (valid):
myapplication.ear
lib/
lib/libraryOne.jar
lib/libraryTwo.jar
redEjbs.jar
blueEjbs.jar
Common mistake (invalid):
myapplication.ear
libraryOne.jar (err. not a javaee module)
libraryTwo.jar (err. not a javaee module)
redEjbs.jar
blueEjbs.jar
Only Java EE modules are allowed at the root. These are EJB jars, .war files, Connector .rar files and Application Client jars. Prior to Java EE 5, libraries had to be explicitly listed in an application.xml file. Java EE 5 and forward they can be added to a lib/ directory and be understood to be just plain jars as opposed to a Java EE module.
Collapsed EAR approach
In OpenEJB/Tomcat you can put all your libraries into the war file and be free of the ear concept. This is now part of Java EE 6.
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Common mistake, including specs:
mywebapp.war
WEB-INF/lib/javax.ejb.jar (err. clashes with the related system library)
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Doesn't sound like that is the issue, but adding for completeness.
Common mistake, broken dependencies:
tomcat/lib/libraryTwo.jar
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
The above is not invalid from a spec perspective and is impossible for the server to detect, but still can lead to apps not loading correctly. If libraryTwo.jar needs classes in libraryOne.jar then this app will never work as the Tomcat "lib" classloader cannot see classes from the "webapp" classloader, so classes from libraryTwo.jar will never successfully load. Unfortunately, the vm will almost never say the actual class that was missing and instead will report the first class in the chain of events that lead to needing a class that was missing. This is almost always a bean or servlet class.
Thanks David.
I tried all of the above, but still no luck.
The Collapsed EAR approach wouldn't work for me I guess, as I far as I know Tomcat 6.0.18 doesn't comply to the J2EE 6 specs. Maybe I'm wrong , but I tried and it didn't work anyway. So back to the standard EAR approach.
My EAR is organized exactly as described in your very first example. One Ejb jar, two library jars in /lib, and that's it. Tomcat still can't instanciate my EJB because the EJB class relates to an unreachable class from Library Jar Two.
I simplified my application.xml file so that it only declares one single EJB:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ...>
<application>
<display-name>ProxyaEAR</display-name>
<module id="EjbModule">
<ejb>ProxyaEJB.jar</ejb>
</module>
</application>
Any other thoughts??