Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

EJB versioning  RSS feed

 
Tmmet Johnson
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,
I have an EJB running in a JVM which is called from 2 apps. running in
diffrent JVMs.

My questions are as follows..

1. Is there way to version the EJBs that I provide to the client apps?

2. If I include a new method in the EJB (which would be used by only app.
B) and does not modify the existing methods in the EJB,do I have to provide
the new stubs to app. A?

3.If my EJB uses application jars , is it mandatory to include those jars
in the classpath in manifest.mf of EJB jar?
Is there any advantage in including the application jars used by EJB in
classpath of manifest.mf file?

4. Is there a way to support backward compatibility for the EJbs(EJB stubs)?

Thanks in advance.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont know the answer but Why not have a single bean class and two different interfaces representing the 2 versions?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tmmet,


1. Is there way to version the EJBs that I provide to the client apps?

Yes it is. One idea that I can suggest you is to deploy the new bean, using the updated classes with a different jndi name. For example if you have to versions of the account bean, you can deploy them with the names ejb/account/1.0/AccountBean and ejb/account/1.1/AccountBean. The jndi will get updated accordingly and you�ll see two distinct folders containing both versions of your ejb. The client needs only to lookup the right version of your bean. Using ejb references would become very handy in this case.

2. If I include a new method in the EJB (which would be used by only app.
B) and does not modify the existing methods in the EJB,do I have to provide
the new stubs to app. A?

First you have to understand that modern containers don�t use ejb stubs for interacting with remote clients. They use dynamic proxies and they build the stubs dynamically at runtime. All you need to do is to make sure that the clients have the latest remote and home interfaces.

3. If my EJB uses application jars , is it mandatory to include those jars
in the classpath in manifest.mf of EJB jar?
Is there any advantage in including the application jars used by EJB in
classpath of manifest.mf file?

That depends upon each container classloading architecture, but from what I know it should work with most of the containers (I guess resin is an exception though). The advantage of doing so is that when updating the libraries you only need to redeploy the application. On the other hand, if you�d add those libraries to the system classpath, then you would need to restart the server in order to load the new jars.

4. Is there a way to support backward compatibility for the EJbs(EJB stubs)?

As I said you shouldn�t worry about ejb stubs. Standard ejb-client.jar should contain only the remote/local home interfaces and all other common classes, like DTOs. Thinks could become more complicated if you�d need to implement CORBA-IIOP clients. Then you have to generate the specific stubs as well, but again for "classic" j2ee applications this is not required.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!