Announcement Announcement Module
No announcement yet.
Spring doesnt work after WebLogic deployment update. Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring doesnt work after WebLogic deployment update.

    I'm running Spring 2.0.6 on WebLogic 9.2. Everything was working as expected until I tried an enhancement to the deployment configuration...

    In the early stages of development everything is in one EAR file, including all 3rd party jars including Spring.

    I'm using Stateless Session EJBs and have configured the spring application context to be a singleton via ContextSingletonBeanFactoryLocator because I may have many beans and am using Hibernate and don't want hundreds of bean factories.

    When I update the deployment via WebLogic admin console and run again everything works fine, and the Spring context gets reloaded from scratch - this is desirable.

    In attempting to enhance the deployment I've taken the 3rd party jars out of the EAR and put them into the WebLogic domain lib directory so they are on the classpath (see footnote at the end).

    But now after WebLogic startup and one test run being successful, on update deployment and re-run the app wont work again because there seems to be some left overs from the previous app deployment. It looks like the singleton application context hasn't gone away. Its obvious from the trace that the Spring context is not being reloaded. I get a class cast exception when the EJB looks up the service object from the factory.

    java.rmi.RemoteException: Error in ejbCreate:; nested exception is:
    java.lang.ClassCastException: $Proxy60

    (nothings changed codewise, the object is of the correct interface but I'm guessing there is a new classloader involved)

    09:00:43,371 DEBUG DefaultListableBeanFactory - Returning cached instance of singleton bean 'businessBeanFactory'
    09:00:43,371 DEBUG WeakReferenceMonitor - Monitoring handle [[email protected] d48] with
    release listener [ [email protected]]
    09:00:43,371 INFO TransTestSpringEjb - onEjbCreate, this = [email protected] d48
    09:00:43,371 DEBUG DefaultListableBeanFactory - Returning cached instance of singleton bean 'cidInboundService'
    09:00:43,387 DEBUG SingletonBeanFactoryLocator - ContextSingletonBeanFactoryLocator.getInstance(): instances.hashCode=-1
    864226355, instances={classpath*:beanRefContext.xml=org.sprin gframework.context.access.ContextSingletonBeanFact oryLocato
    [email protected]}

    Even if I stop the deployment in WebLogic and restart it there is still no benefit, the problem still exists. Only if WebLogic is restarted after deployment update does the problem go away.

    Any advice?

    I looked into WebLogic shared J2EE shared libraries as suggested in but I dont have any shared J2EE components only 3rd party jars and if you go down the avenue of 'optional packages' you need to mess with the manifests of each jar file.

  • #2
    Even after deleting the deployment and re-installing a new deployment from the same EAR the problem still exists.

    And running WebLogic in production mode doesnt make any difference either.

    It seems that classes once loaded are not going to be reloaded after redeployment - puzzling.

    So how does one persuade WebLogic to flush out all classes from an application and cause them to be reloaded after a redeployment without recourse to stoppping WL and restarting it ?
    Last edited by JulesT; Oct 3rd, 2007, 08:57 AM.


    • #3
      Where do you have the spring.jar loaded? System or Application Classpath? If you use the Singleton... and the spring classes are loaded in the System Classpath then they are not going to be reloaded after a redeployment, so or you put the spring.jar inside your application and remove it from the system classpath or you implements your own Singleton in the context of your application.



      • #4
        Thanks - yes I've reconfigured and built a j2ee shared library and put all 3rd party jars including spring in there and now it works OK.

        I just thought it was a bit of a nuisance having to create a dumy EJB etc just to get the j2ee shared library to deploy when I dont actually have any EJBs I want to share.