Trying to deploy multiple versions of a bean in weblogic 6.1

Discussions

EJB programming & troubleshooting: Trying to deploy multiple versions of a bean in weblogic 6.1

  1. We are trying to deploy more than one version of a given entity or session bean in one instance of weblogic. Our strategy is to create multiple EAR files and registering the different versions in separate branches of the JNDI tree. Our client then does a lookup in the correct branch for the version it wants.

    It all looks as if it is working correctly when finding the correct one of the multiple home interfaces, but when an instance of the bean is created, it seems to use one version only (perhaps the first ear that was loaded)

    Has anyone successfully solved this problem?
  2. We deploed 2 independent web applications as one deployment unit. They both used user info entity bean, deployed separately by each application. We encountered the same problem: appararently, EJB container picked up the version of the EJB stub implementation class that was loaded first and did not bother to distinguish between 2 deployments. It usually result in inability to unmarshall a stub after lookup. Having spent a couple of weeks trying to find something in documentation and user groups we resorted to this solution. We put all EJB jars on the class path - in startWebapp. In this case WebLogic seems to grasp the picture - it has some problems with dynamically doing though. BEA's 'resolved bugs' screens contain a lot of announcements about resolving bugs that sound very similar to this one - but we're running on SP2 and the problem is definitely there.
  3. It was our mistake, We did get it working, but in the mean time, we learned something useful. The loader for resource bundles does not work exactly like the classloader, so with ear files deploying different versions of the same ejb application - if each ear contained a 'settings.jar' with identically named property files they would become confused, however, if we put the critical property files in the same jars as the class file that needed them within their respective ear file, they would be seen distinctly from version to version