I am using Resin 3.1.9 to run Java Web Application with JPA 2.1.
I have put libraries (JAR) on my WEB-INF/lib folder, and I have include them to resin.conf by this:
<class-loader>
<tree-loader path="${resin.root}/webapps/myapp/WEB-INF/lib"/>
</class-loader>
If I didn't include it in resin.conf, I saw an exception about failed to load some classes (even when in first loading on home page).
OK now when loading home page it is no problem, but I wonder when I try to add some record (via CRUD form), it said:
java.lang.NoClassDefFoundError: javax/persistence/spi/PersistenceProvider
In fact, class javax.persistence.spi.PersistenceProvider is absolutely exist in "WEB-INF/lib" which is in file "hibernate-jpa-2.1-api-1.0.0.Final.jar"
Is there any debugging step how to check loaded libraries during Resin startup?
Or is there something wrong in my resin.conf?
EDIT
After some investigations, it seems my suggestion of an SPI problem is wrong: double JPA implementations not properly declared raise a PersistenceException.
This is probably not a class loading problem but rather an SPI problem. Have you checked the provider element for hibernate in your persistence.xml ? This should be something like this :
<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
Perhaps you should also mention an SPI declaration, but you should only do so if you have multiple implementations available. This is probably the case because of the JPA implementation of your Java EE web profile server.
In such a case, you should add a services folder in your META-INF folder and create a javax.persistence.spi.PersistenceProvider text file inside.
This file should list the two persistence provider implementations (hibernate and the one included in Resin, I don't find it in the documentation).
Related
I am trying to do a log4j migration for a legacy application. I made the changes to the configuration files and tested it locally with Tomcat, where the logs were displayed correctly. However when I deploy on WAS, the logging stops.
I checked a lot of pages about the necessary dependencies and the possible problems, but now I feel I'm stuck. Here is what I already tried:
Added the log4j jars manually to the lib/ext directory in WAS (together with commons-logging, I read an article where it helped, although all these jar-s were already present in the ear)
Double checked, that the configuration file is on the classpath and that it's syntax is correct
Added logj42-web dependency
Added the necessary filters in web.xml (Spring version is 3.8, so also the config listener with the config name context-param)
Checked classloader in WAS - it's parent first
Am I missing something?
Any ideas are appreciated. Thank you in advance!
WAS includes its own commons-logging API (that does not utilize Log4j), so bringing your own logger requires a bit of extra class-loader-related config. Typically, that would go something like this:
Put your commons-logging and log4j jars, along with your logging properties files, in some directory (not WAS_HOME/lib/ext) readable by the user running the server.
Create a shared library on the server, with that directory as its class path, and select the "use an isolated class loader" option. Associate that shared library with your application or web module.
Ideally, that should be it. Isolated shared libraries search themselves before delegating to the server's loaders, so your application will "see" the commons-logging/log4j classes in the shared library instead of in the server, and likewise, it should pick up the configuration files from that directory instead of the ones found in the server.
You can also accomplish this same basic thing by leaving all the logging stuff in your WAR or EAR and setting its class loader to parent-last (which causes the class loader to search locally before delegating to the server-level loaders), but that is a bit riskier configuration - if your application includes APIs that are also provided by the server, parent-last class loading increases the possibility of ClassCastExceptions or LinkageErrors.
I have an ear file with a web module and a ejb module(just used for message driven beans). The ejb module has dependency on web module and it's classes. I would need to load the web module first and then ejb module. But the liberty always loading the ejb module first causing com.ibm.ws.container.service.state.StateChangeException: java.lang.NoClassDefFoundError:
How to control the order of modules loading within the same ear file? On traditional webshpere there is an option called 'Starting weight'. Whichever module has lowest value takes precedence and loads it first. so the application works good on tradition Websphere. However, this property seems missing on Liberty. I already looked at this. It only talks about deploying the multiple war files and their order.
If your EJB module depends on Web, that is bad design. It should be the other way around.
If you have such situation , proper way would be to extract shared classes in to a common jar file, let say mycommon.jar and then put that into ear\lib folder. In this way they will be visible by both modules ejb and web.
If your EJB module depends on the javax web api (e.g. servletRequest) that is even worse, and you should redesign such classes to POJO DTOs.
As a last resort you could try what is described here and add <initialize-in-order>true</initialize-in-order> in your application.xml.
FRowe's solution will not work, as classes are not shared between the applications, so changing load order of apps will not help. Each Java™ EE application has its own class loader in a running Liberty server.
Consider using the ability to control app start order as described here: https://www.openliberty.io/blog/2020/06/05/graphql-open-liberty-20006.html?_ga=2.4728563.17466047.1620833568-1423690488.1614284842&cm_mc_uid=99965752544816136653536&cm_mc_sid_50200000=61078141620909829332#ORDER
You'll have to deploy the war module as an app instead of packaging it within the ear, but you should be able to achieve the proper ordering.
I am creating a library using spring-boot (v2.1.6.RELEASE) as a starter project that will facilitate as base extension jar responsible for configuring and starting up some of the components based on client project properties file.
The issue I am facing is that if the client project's SpringBoot Application class contains the same package path as library everything works like charm! but when client project contains different package path and includes ComponentScan, it is not able to load or start components from the library.
Did anyone encounter this issue? how to make client application to auto-configure some of the components from library jar?
Note: I am following the library creation example from here: https://www.baeldung.com/spring-boot-custom-starter
There are many things that can go wrong here, without seeing relevant parts of actual code its hard to tell something concrete. Out of my head, here are a couple of points for consideration that can hopefully lead to the solution:
Since we use starters in our applications (and sometimes people use explicit component scanning in there spring applications) and this obviously works, probably the issue is with the starter module itself. Don't think that the fact that the component scan is used alone prevents the starter from being loaded ;)
Make sure the starter is a: regular library and not packaged as a spring boot application (read you don't use spring boot plugin) and have <packaging>jar</packaging> in your pom.xml or whatever you use to build.
Make sure you have: src/main/resources/META-INF/spring.factories file
(case sensitive and everything)
Make sure that this spring.factories file indeed contains a valid reference on your configuration (java class annotated with #Configuration). If you use component scanning in the same package, it will find and load this configuration even without spring factories, in this case, its just kind of another portion of your code just packaged as a separate jar. So this looks especially "suspicious" to me.
Make sure that #Configuration doesn't have #Conditional-something - maybe this condition is not obeyed and the configuration doesn't start. For debugging purposes maybe you even should remove these #Conditional annotations just to ensure that the Configuration starts. You can also provide some logging inside the #Configuration class, like: "loading my cool library".
I am trying to get an apache camel app using CXF working on WebSphere.
Noticed a number of errors
Caused by: java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:262)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
This occurs because the org.apache.neethi classes are loaded from the WAS run-time instead of the neeti3.0.2.jar from WEB-INF/lib
here is the info from class loader:
class load: org.apache.neethi.builders.AssertionBuilder from: file:/D:/Tools/WebSphere/AppServer/plugins/org.apache.axis2.jar
The Web Application config has been changed to use the class loader policy. It is set to Parent Last. Yet this class seems to be using the Parent First Policy.
Is there anything in the CXF package that over-rides this policy?
I noticed that using Axis2 and WAS
http://axis.apache.org/axis2/java/core/docs/app_server.html
Avoiding conflicts with WebSphere's JAX-WS runtime has some additional steps mentioned for Axis2. Is there something similar that is required to get this to work?
Thanks
Manglu
Not specific to Camel, but we are dealing with a similar issue.
1) You can use an isolated shared library if you want. This seems to fix the classloader from pulling in these other libraries via OSGi. This solution isn't for everyone.
2) When setting an app that PARENT_LAST, make sure you're doing it in the correct place. If you have jars inside your wars, then you'll have to set PARENT_LAST on the WAR modules, not the application. In the WAS console> Applications > Application Type > websphere enterprise applications> MyEAR > manage Modules > MyWar > Change the "Class loader order" and make it "parent last"
3) After you make your changes, you can export the ear file. In the ear, there is a file META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml that has this config. For maven ear's, you can put this into src/main/application for it to be packaged up with the ear.
Hope that this helps. Good luck.
We are discussing a similar topic at the Camel mailing lists. I suggest to take a look there: http://camel.465427.n5.nabble.com/camel-cxf-in-WebSphere-without-geronimo-jetty-depdendencies-possible-tp5726490.html
I am trying to build an project in Eclipse (actually I'm using RAD, so basically eclipse, and when I say 'Java EE Project' I mean an 'Enterprise Application Project').
My Enterprise Application Project (the 'EAR' project) has two module projects :
- service
- web
The service project has some stuff in it, all wired up using Spring.
The web project has its own stuff in it, all wired up using Spring. The UI stuff in the web project needs to use the stuff in the service project.
Both projects are included in the EAR project as modules.
The web project lists the 'service' project as a dependent project in the build path, it's checked off for export, and also has it listed as a EE Module Dependency.
I'm having a really hard time to get this working though:
The spring context in the web project is of course what gets loaded when the application is deployed, and it imports the spring config I need from the service project. This seems to be working fine.
When spring tries to instantiate a bean it throws a ClassNotFoundException. On the very first bean.
I tried simply copying the spring config from my service context and pasting it into my web context, but I got the same ClassNotFoundException.
I have tried instantiating an object of that type (the class that spring says cannot be found) in the java controller class in the web project, and it is successful, both at compile time (no compile errors) and at runtime (no exceptions).
So the classes from my service project are not available on the classpath when spring tries to use them.
Any ideas what's going on here and/or what I might be able to do about it?
There is a class loader policy that you should use ParentClass First . That will be managed either through Application.xml or through web.xml . You need to check your xml's then try.
It's a class loader issue.
Since you're using Spring, I'll assume that you don't have EJBs. If that's the case, why do you need an EAR? Deploy the whole thing as a web project, in a single WAR.
Put all your .class and Spring configuration .xml files in WEB-INF/classes. Load the configuration using org.springframework.web.context.ContextLoaderListener.
I seem to have fixed this - I'm not sure exactly what the problem was but there must have been a small typo in my spring config. I decided to just start fresh with a new spring config and when I started building the new one back up things were working fine. There must have been a problem with the old one.
Thanks for the suggestions though.
Unfortunately we're not always able to change project structure. We're working on structures other people have put in place.
I looked into the ParentClassFirst vs ParentClassLast setting - it seems on websphere the ParentClassFirst setting is the default if you don't specify anything, so I'm leaving it without specification to get that functionality.
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/crun_classload.html