Skip to Content
As some of you have noticed, our previous Java EE 5 compatible releases had problem incoroprating the famous Hibernate framework. Portability is important for us, so I am happy to explain how one can use Hibernate with our CE release. Update: The feature is available on the 2007 JavaOne DVD, which unfortunatelly is not availabe for download at this moment (04/06/2007). CE 1.0 SP1 will also contain this feature; the feature is not available on CE 1.0 SP0, downloadable at the moment on the service marketplace. In our engine we use parent-first rule when loading resources. Components are coupled on classloading level by creating the respective parent-child classloader hierarchy. While this approach gives us predictable and simple hierarchy, it causes inconveniences in some rare cases. The Hibernate scenario is such case. We took some time to think how similar problems can be solved in the future – we wanted to have generic solution, not just local fix. Alternatives were to introduce some filtering concept or to restructure our classloaders. With thousands of applications deployed, forming layers of frameworks, one has to think about predictability of the classloading behaviour – supportability is valuable asset. On the other hand, restructuring was not needed, just slight extension in few scenarios. This quickly led to the decision to extend the classloading structure of the apps in the manner I will describe below. I will skip number of details, as I know you are eager to finally run that Hibernate application. Here we go…
What we need is to get the Hibernate classes loaded with the highest priority, no matter what classloading dependency our application has specified. For this purpose, the heavy resources classloader is introduced, working in the following manner :

  • created with the resources located in the lib folder in the root if the ear, only when the application version is Java EE5
  • first in the parent list. This guarantees the following delegation order when loading a resource :
    1. heavy loader (and it’s parent respectively)
    2. default references, specified by the containers during deploy. Usually contain the standard Java EE APIs
    3. application specific references (specified in the application-j2ee-engine.xml)
    4. all other application resources contained in the EAR

You need to do two things in order to run your Hibernate application :

  1. Pack the Hibernate framework as shared library (see Applications and shared libraries) or as part of your application. My advice is to pack it as shared library if you have more than one application, using it. In both cases it is mandatory that the application packing the Hibernate binaries :
    • is Java EE 5 one
    • all the Hibernate jars are located in the /lib folder.
    • the EAR contains application-service.xml (even if practically empty) – this is achieved by adding the SAP Application Library Container facet to your project
  2. Switch on the Heavy loaders behaviour as it is switched off by default :
    • start the Config tool
    • change the Define_Heavy_Resources property of the library_container to true; save the change
    • restart the whole instance for the change to take effect
    • deploy your application(s)
  3. Check that the heavy loader is created and contains all Hibernate jars. I assume you packed Hibernate as shared library in application named com.vendorX/Hibernate :
    • using telnet, issue >ll | grep com.vendorX/Hibernate
    • you should get as output two classloaders [com.vendorX/Hibernate] [com.vendorX/Hibernate-library-loader] The second one is the heavy classloader – check via the llr command that it contains all related jars. In the example I have (Thank Adrian) it looks like this : >llr com.vendorX/Hibernate-library-loader   Loader name:     [com.vendorX/Hibernate-library-loader]   Direct parent loaders:     [library:javax~persistence~api]     [library:ejb_api]   Direct child loaders:     [com.vendorX/Hibernate]   Resources:    C:usrsapCE1...app_libraries_containerlibjboss-archive-browsing.jar     C:usrsapCE1...app_libraries_containerliblucene-core-2.0.0.jar     C:usrsapCE1...app_libraries_containerlibasm-attrs.jar     C:usrsapCE1...app_libraries_containerlibantlr-2.7.6.jar     C:usrsapCE1...app_libraries_containerlibcommons-collections-2.1.1.jar     C:usrsapCE1...app_libraries_containerlibcommons-logging-1.0.4.jar     C:usrsapCE1...app_libraries_containerlibjavassist.jar     C:usrsapCE1...app_libraries_containerlibhibernate3.jar     C:usrsapCE1...app_libraries_containerliblog4j-1.2.11.jar     C:usrsapCE1...app_libraries_containerlibhibernate-annotations.jar     C:usrsapCE1...app_libraries_containerlibhibernate-entitymanager.jar     C:usrsapCE1...app_libraries_containerlibcglib-2.1.3.jar     C:usrsapCE1...app_libraries_containerlibehcache-1.2.jar     C:usrsapCE1...app_libraries_containerlibdom4j-1.6.1.jar     C:usrsapCE1...app_libraries_containerlibasm.jar

With this, I hope you have enough knowledge to port your applications to our engine.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Matthias Steiner
    Hi Georgie,

    *that’s good news!*

    Even though I know you’ve mainly aimed to provide some insight on the classloading aspects, can you say a word about the hibernate dialect you used?

    AFAIK, there’s no OpenSQL dialect for Hibernate and so I’d assume that you’d have to leave the OpenSQL world and use native DB driver and dialects… can you comment on this?

    Otheriwse, great blog… good to know somebody talks about class loading topics on SDN.

    Cheers,
    Matthias

    (0) 
    1. Anonymous
      🙂
      Although this was marketed internally as ‘the Hibernate feature’ it serves many more cases – we solved a JAXB incompatibility problem with this same solution.

      About Hibernate – I think it was very ordinary one (Andrian Goerler did the test app). AFAIK there is no open sql hibernate, so yes – native connection is used (I guess).

      (0) 
      1. Jian Liao
        Since the latest hibernate depends on JPA API 2.0 version, but the JPA API bundled by NetWeaver 7.3 is still 1.0 version. Is there any way override javax.* package?
        (0) 
  2. Stephan Erb
    Hello,

    I am running NW CE SP3 and for me the property mentioned above is already set.

    Since which release does it default to true?

    Best Regards,
    Stephan

    (0) 
  3. sunita r
    Currently I am using NetWeaver CE 7.1, currently  when I bring up the application it is picking up Sun implementation of JSF, instead of the one myfaces, which is under WEB-INF/lib folder.

    Would this fix will resolve that issue as well?

    (0) 
  4. Radu Fantaziu
    Hi Georgi,

    I’ve tried your solution to deploy a new version of JAX-WS 2-1-3 implementation inside of an ear. I wanted to use this implementation instead of NetWeaver’s implementation of JAX-WS 2.0 because I’m interested in streaming MTOM.
    I ‘ve used “llr” to dump the class loader hierachy and everything seems to be OK.
    After that, I deployed a servlet as a web service entry point inside of the ear (as a war module). At the initialization of this servelt (in the init() method), the [library:tc~bl~base_webservices_lib] classloader
    is always used instead of “heavy resources” classloader defined in the ear.
    Is it possible to use the “heavy resources” classloader in a web service entry point deployed as a servlet?

    Thanks,
    Radu

    (0) 

Leave a Reply