I am in the process of upgrading WebLogic Server 11g (10.3.6.0) to 12c (12.2.1.3.0).
I installed the war file without a problem onto the 12c server. Then, I tried to start the module. I was getting weblogic.application.ModuleException: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.springframework.aop.framework.AopConfigException error due to missing a particular class file. It seems like the class file belongs to "spring-aop-2.5.2.jar."
When I deployed the same war file onto the WebLogic Server 11g environment, I did not observe any problem. I ensured that "spring-aop-2.5.2.jar" exists in the war file. I am using the version 2.5.2 for the SpringFramework. I suspect it may also be a problem.
Based on my research, some people suggested to append <package-name>net.sf.cglib.*</package-name> into the to <prefer-application-packages> in your weblogic-application.xml. I do not have the weblogic-application.xml in my project or in the war file. I only see the file on the server. Although I appended the tag into weblogic-application.xml, I am still geting the same error.
Should I configure anything else based on my description? Any idea?
Having the same issue, I got it to work by putting both spring and cglib jars in the ear APP-INF/lib folder and using the following META-INF/weblogic-application.xml
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.3/weblogic-application.xsd">
<prefer-application-packages>
<package-name>net.sf.cglib.*</package-name>
<package-name>org.springframework.*</package-name>
</prefer-application-packages>
</weblogic-application>
From my understanding, it's important that:
Both cglib and spring jars are in the same classpath folder
Both are present in "prefer-application-packages"
Using "prefer-application-packages" in weblogic.xml inside my .war file did not seem to work for some reason.
You should modify your weblogic.xml file to use the proper libraries with prefer-application-packages. However, do not forget to include this.
<prefer-web-inf-classes>false</prefer-web-inf-classes>
Oracle states here
Note that in order to use prefer-application-packages or prefer-application-resources, prefer-web-inf-classes must be set to false.
Related
Whilst deploying an Eclipse RAP war file on WebLogic 12.2.1.3, we are encountering the following error;
java.lang.LinkageError: loader constraint violation: loader previously initiated loading for a different type with name "org/aopalliance/aop/Advice"
After performing some analysis we identified the issue is due to WebLogic 12.2.1.3 shipping with org.glassfish.hk2.external.aopalliance-repackaged.jar within oracle_common\modules, and this conflicts with com.springsource.org.aopalliance_1.0.0.jar, within the WEB-INF\plugins directory of our WAR file.
We have tried a few things to remediate this, but with no luck so far;
Removed org.glassfish.hk2.external.aopalliance-repackaged.jar from oracle_common\modules (WebLogic deploys but then shuts itself down)
Remove com.springsource.org.aopalliance_1.0.0.jar from the WAR file (WebLogic starts, but does not deploy the bundles within the WAR file)
Updated weblogic.xml in the WAR file with;
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>org.aopalliance.*</package-name>
</prefer-application-packages>
</container-descriptor>
Copied com.springsource.org.aopalliance_1.0.0.jar to the WEB-INF\lib folder of the WAR, with the above weblogic.xml change
Any suggestions of other changes we could try would be much appreciated.
Many Thanks
Mike
try updating the launch.ini in your war file, setting the values for osgi.parentClassloader and osgi.contextClassLoaderParent to ext :-
osgi.parentClassloader=ext
osgi.contextClassLoaderParent=ext
Cheers
Rod
I'm building a set of REST services and deploying each service to a separate WAR file. Since each of these services uses the exact same persistence configuration, I've placed my persistence.xml in a jar file (the path of the persistence.xml file in the jar is still /META-INF).
When running this using TomEE (1.7), this works just fine. However, when I try the same thing with WebSphere (8.5.5.x) my persistence units do not get loaded. In the WebSphere log, I get an error that looks like:
[4/27/16 8:54:21:653 EDT] 00000080 JPAApplInfo E CWWJP0029E: The server cannot find the MRO_PU_JTA persistence unit in the Customer_WAR.war module and the DS_APP_EAR application.
[4/27/16 8:54:21:654 EDT] 00000080 InjectionBind E CWNEN0035E: The ds.services.helper.AbstractServiceHelper/em reference of type javax.persistence.EntityManager for the component in the Customer_WAR.war module of the DS_APP_EAR application cannot be resolved.
[4/27/16 8:54:21:657 EDT] 00000080 ResourceInjec E CWOWB0102E: A JCDI error has occurred: The ds.services.helper.AbstractServiceHelper/em reference of type javax.persistence.EntityManager for the null component in the Customer_WAR.war module of the DS_APP_EAR application cannot be resolved.
When I copy the persistence.xml file from my jar file to the local WAR's META-INF, this error goes away and everything works fine. Since I have a ton of services to deploy this way, I don't want to have to make copies of persistence.xml for every WAR file.
Is there any way to get WebSphere to find my persistence.xml file? Maybe some setting in WebSphere that I haven't been able to find?
Thanks.
Ok, so it seems that this is a duplicate of the following: Sharing a persistence unit across components in a .ear file
Looking at the answer to that question from Pascal Thivent, it becomes fairly obvious what the problem is: In order to get this to work, the jar file that contains the persistence.xml must be present in the /lib directory of the EAR that is being deployed to WebSphere. Apparently, the way it works is that the EAR resolves the persistence.xml file, and when each WAR file attempts to inject the entity manager, it refers to the EAR to do so. This is in contrast to TomEE (which is deploying without an EAR file). In that case the dependency is resolved by the WAR file classloader, so just having the jar file in the classpath of the WAR is sufficient.
I currently have my persistence.xml located in src/main/resources/META-INF/persistence.xml. Also I am using eclipselink 2.4 as my JPA 2.0 implementation.
After publishing to the server and trying to run the app in the browser I get the following error:
Exception: : java.lang.IllegalArgumentException: No persistence unit named 'X'
is available in scope Webapp. Available persistence units: [] at
This is ONLY when building in Eclipse. Leaving META-INF on the path src/main/resources/META-INF/persistence.xml and performing maven install to build the war file, the META-INF folder is correctly placed in WEB-INF/classes/META-INF/persistence.xml like it should be (inside the war). Seems that it is only and issue of when the webapp is built and ran locally in Eclipse. Can anyone explain this?
Can anyone explain what the problem is? Maybe someone has ran into this problem before?
I am trying to run the application. just i installed the tomcat and netBeans.
It is giving following error. if i try to give build alone,,, build is successful. but i am unable to deploy in server ...
Created dir: D:\Test\build\generated\src
Created dir: D:\Test\build\generated\classes
Compiling 1 source file to D:\Test\build\generated\classes
Undeploying ...
undeploy?path=/excelRD
OK - Undeployed application at context path /excelRD
In-place deployment at D:\Test\build\web
D:\Test\build\web\META-INF\context.xml (The system cannot find the file specified)
D:\Test\nbproject\build-impl.xml:686: The module has not been deployed.
Please do needful
The error message seems clear you need a file context.xml in your project.
In a regular apache project created with Netbeans, you have in the directory Web Pages an other directory names META-INF and in this directory the file context.xml.
Try to respect this architecture. The minimal context.xml contant is :
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/excelRD"/>
He may also be seeing an issues I've seen on NetBeans for years. You have a perfectly valid context.xml file that can't be found by NetBeans during deployment. If you open the file, touch it in anyway (type in a character, delete that character, then save), the problem goes away. I've had this happen so many times that I've gotten in the habit of always touching the context.xml file before I deploy.
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??