Classloading problem on SAP WAS: persistent class not found

dbeutner · **Posted:** Thu Nov 11, 2004 8:45 am

Hi there,

I am going to get Hibernate working on SAP WAS 6.20 (there, within enterprise portal, which, seen from WAS perspective, is a web application, which holds it's own portal applications).

If I put all the Hibernate stuff (JARs) as well as the xml files into the portal application project so that it gets deployed as part of my portal application, everything works fine.s

Now this is not very nice, one whishes to lay the Hibernate -- application independent -- stuff on the base of the WAS, so that each application -- especially, but not restricted to -- also each portal applications can use it.

With this, the xml files (hibernate.cfg.xml and mapping files) are to be seen as part of the application. They shouldn't be anywhere except within the to be deployed PAR file (Portal Archive). The same holds for the mapping classes.

So I put all libs under .../cluster/server/additional-libs and made the necesary entries within reference.txt and library.txt. This works in the meaning of: The classes are found from within the portal application. Also the xml files are found.

Now the pain looks like this:

Hibernate version: 2.1.6

Full stack trace of any exception that occurs:

Quote:

net.sf.hibernate.MappingException: Error reading resource: services/servlet_jsp/work/jspTemp/irj/root/WEB-INF/portal/portalapps/HibernateTest/resources/myprojects.hbm.xml
at net.sf.hibernate.cfg.Configuration.addResource(Configuration.java:339)
at net.sf.hibernate.cfg.Configuration.doConfigure(Configuration.java:1013)
at net.sf.hibernate.cfg.Configuration.doConfigure(Configuration.java:969)
at net.sf.hibernate.cfg.Configuration.configure(Configuration.java:931)
at com.btexx.hibernate.HibernateTestComponent.doContent(HibernateTestComponent.java:22)
at com.sapportals.portal.prt.component.AbstractPortalComponent.serviceDeprecated(AbstractPortalComponent.java:209)
at com.sapportals.portal.prt.component.AbstractPortalComponent.service(AbstractPortalComponent.java:114)
at com.sapportals.portal.prt.core.PortalRequestManager.callPortalComponent(PortalRequestManager.java:301)
at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:138)
at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:191)
at com.sapportals.portal.prt.component.PortalComponentResponse.include(PortalComponentResponse.java:217)
at com.sapportals.portal.prt.pom.PortalNode.service(PortalNode.java:580)
at com.sapportals.portal.prt.core.PortalRequestManager.callPortalComponent(PortalRequestManager.java:301)
at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:138)
at com.sapportals.portal.prt.core.PortalRequestManager.dispatchRequest(PortalRequestManager.java:191)
at com.sapportals.portal.prt.core.PortalRequestManager.runRequestCycle(PortalRequestManager.java:670)
at com.sapportals.portal.prt.connection.ServletConnection.handleRequest(ServletConnection.java:229)
at com.sapportals.portal.prt.dispatcher.Dispatcher$doService.run(Dispatcher.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at com.sapportals.portal.prt.dispatcher.Dispatcher.service(Dispatcher.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.inqmy.services.servlets_jsp.server.InvokerServlet.service(InvokerServlet.java:126)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.inqmy.services.servlets_jsp.server.RunServlet.runSerlvet(RunServlet.java:149)
at com.inqmy.services.servlets_jsp.server.ServletsAndJspImpl.startServlet(ServletsAndJspImpl.java:832)
at com.inqmy.services.httpserver.server.RequestAnalizer.checkFilename(RequestAnalizer.java:666)
at com.inqmy.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:313)
at com.inqmy.services.httpserver.server.Response.handle(Response.java:173)
at com.inqmy.services.httpserver.server.HttpServerFrame.request(HttpServerFrame.java:1288)
at com.inqmy.core.service.context.container.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:36)
at com.inqmy.core.cluster.impl5.ParserRunner.run(ParserRunner.java:55)
at com.inqmy.core.thread.impl0.ActionObject.run(ActionObject.java:46)
at java.security.AccessController.doPrivileged(Native Method)
at com.inqmy.core.thread.impl0.SingleThread.run(SingleThread.java:148)
Caused by: net.sf.hibernate.MappingException: persistent class [com.btexx.hibernate.Project] not found
at net.sf.hibernate.cfg.Binder.bindClass(Binder.java:84)
at net.sf.hibernate.cfg.Binder.bindRootClass(Binder.java:221)
at net.sf.hibernate.cfg.Binder.bindRoot(Binder.java:1256)
at net.sf.hibernate.cfg.Configuration.add(Configuration.java:252)
at net.sf.hibernate.cfg.Configuration.addInputStream(Configuration.java:288)
at net.sf.hibernate.cfg.Configuration.addResource(Configuration.java:336)
... 33 more
Caused by: java.lang.ClassNotFoundException: com.btexx.hibernate.Project
at com.sapportals.portal.prt.util.AutoClassLoader.loadClass(AutoClassLoader.java:1458)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:115)
at net.sf.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:102)
at net.sf.hibernate.cfg.Binder.bindClass(Binder.java:81)
... 38 more

The strange thing is that I used SysInternals File Monitor to check where the classloader looks for the mapping class file. In each case -- independent if the Hibernate stuff lays at WAS base or gets deployed as part of the portal application -- the file monitor only shows (unsuccessful) attempts to read from .../cluster/server as well as from ../cluster/server/services/servlet_jsp/work/jspTemp/irj/work.

Nevertheless, as said, it works if the Hibernate stuff is within the portal app...

Any hints?!

Thanks in advance
Detlev

dbeutner · **Posted:** Thu Nov 11, 2004 9:23 am

Sorry, the last paragrah must read

Quote:

Caused by: java.lang.ClassNotFoundException: com.btexx.hibernate.Project
at com.inqmy.frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:198)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at com.inqmy.frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:135)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:115)
at net.sf.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:102)
at net.sf.hibernate.cfg.Binder.bindClass(Binder.java:81)
... 38 more

But this also shows the difference: The inqmy ReferencedLoader is part of the WAS (it's name has been InQMy before, if someone remembers), whereas the AutoClassLoader is part of the portal (the IRJ servlet application).

If I put all the stuff at WAS base: inqmy ReferencedLoader fails.
If I put all the stuff within portalapp: AutoClassLoader works.
If I put all the stuff within portalapp, but delete the mapping class: AutoClassLoader fails.

What I would need is to pass the classloader to Hibernate, via this.getClass().getClassLoader(), also see http://www.jroller.com/comments/donraka ... f_ear_that

If I do not overlook something, this seems to be a very urgent request for Hibernate, as the problem will appear in several managed environments, if you don't go the ugly way (a) to deploy the whole Hibernate stuff with each app using it or (b) put the mapping classes etc on the server root. Both is inacceptable.

Any chance?

Thanks in advance
Detlev

max · **Posted:** Sun Nov 14, 2004 10:15 am

hmm - fixing this classloading for resources willl only solve the tip of the iceberg. If we fixed this scenario there are still a bunch of places where we behave like any good citizen and look in current thread context first and then our own classes classloader.

.."injecting" a third classloader is not trivial since some of these methods are static and called by different parts which does not easily can get access to a "common" classloader.

Because where should this "common" classloader be placed ?
In the session ? configuration ? sessionfactory ? what about the static methods which don't have access to one of these ?

I would say that is what current thread context classloaders is for!

dbeutner · **Posted:** Sun Nov 14, 2004 12:35 pm

Hi Max,

quite right, the place where the thread context classloader is used again and again is the static classForName method. I have opened an improvement issue on JIRA, followed by a very strange and blocking discussion with Christian; now he has reopened this issue, see http://opensource.atlassian.com/project ... se/HB-1309

I see that setting the classpath manually takes some efforts. I have done it for the configuration (this was a fast one, taking about 15 minutes or so). Nevertheless, as you said, changing it in completeness will take much more time and thinking. (If one would go this way, the ClassLoader should be passed to the Configuration, from there on to the SessionFactory; further passing must be checked.)

Anyhow, for seeing this would be an effort, I will check the possibility to use the thread context classloader. But that means to manipulate it, and this only works if it is not used by the EP implementation itself.

Tomorrow I will check the source code. If this checking gives the green light, I will contact SAP for asking (a) if there is any technical need to have the thread context classloader restricted to the webapp, and if not, (b) if the thread context classloader could be set by EP (instead of the application having it to do).

I will come back with the results.

Best regards
Detlev

dbeutner · **Posted:** Sun Nov 14, 2004 12:37 pm

Sorry, must read http://opensource.atlassian.com/project ... se/HB-1310

max · **Posted:** Sun Nov 14, 2004 12:41 pm

yes - and this "carrying" around of a classloader is worse code-smell than intermediatly set the tx context class loader for doing the configuration...IMHO.

I'll look forward to hear SAP's opinion on this (and how they/you cope with other api's that depend on a classloader ;)