JBoss Hot Redeployment

[hariprasad]

Hai All,

I have a issue with JBoss Hot Redeployment.

I have an EAR say Static.ear,which uses a JAR file(Dynamic.jar) in my application.

The logic is that,the Dynamic.jar is provided so that any user can use it to configure/customize some of functionalities in the application.From Static.ear,it uses reflection and loads the class from the Dynamic.ear to execute a customized feature.

So now,intially I have deployed both EAR & JAR files.After sometime,the Dynamic.JAR is only updated.JBoss does not do a Hot Redeployment and it still uses the old JAR file classes.But when I redepoy the EAR,it takes the latest JAR file.

Can anybody tell me where is the problem....


Thanks
Hari

[dimitris]

There is no magic here. If you somehow redeploy a .jar used by an .ear you have to redeploy the .ear as well, because it has already loaded and uses the classes of the .jar in memory. Java doesn't have a mechanism to unload or replace classes in memory, so it just created new versions of those classes and get rids of the old ones only when they are not referenced by anybody anymore.

[hariprasad]

Hai dimitris,

Thanks for your help

But the question is

Hot Deployment is a feature which is supposed to do this I suppose .....right ?

My understanding of Hot Redeployment is

1.Deploy newly developed components to a running production system.
2.Remove (undeploy) deployed live components from a running server.
3.Modify (redeploy) the behavior of the component by updating with the current definition.

So does this update only applies to call for the first time without any previous references...is what I understood from ur answer.
Is that right ?

So I have to do a rethink on the design of the application or is there any other better way to implement this ?


Thanks in advance
Hari

[dimitris]

You can hot deploy/undeploy modules, not modify.

Again, you can't swap classes on the fly, you need to redeploy the whole thing (the jar and whoever uses it).

[hariprasad]

Hai dimitris,

Thanks for your reply again.

I was looking for a solution for the problem and found the article 'JBossClassLoadingUseCases'.This says,

'However, it is possible to trick the server (or the VM) into doing this. If application A interacts with application B, but doesn't have any direct references to the B classes, and B changes, let's say a newer and better version becomes available, it is possible to create a new class loader, load the new B classes and have the invocation bus (the application server) route all invocations from A to the new B classes. This way, A deals with a new version of B without even knowing it. If the application server is careful to drop all explicit references to the old B classes, they will eventually be garbage collected and the old B will eventually disappear from the system.'

Is this a feasible solution ?

But I also understand that usage of new Custom Class Loaders is a violation of EJB Specifications.

Is there any other way to get around you propose for this scenario ?Because we dont want to redeploy the Static.ear,as it runs in production environment on a 24*7 basis.

Hoping for your inputs on this.

Thanks
Hari

[elindfor]

Is there any other way to get around you propose for this scenario ?Because we dont want to redeploy the Static.ear,as it runs in production environment on a 24*7 basis.

Hi Hari,

Another way to round this problem would be to set up a kind of secondary server. You should assign the client to send the requests to this server always when the primary server is not available. If you want to deploy a new JAR into the primary server, you should deploy the old JAR into the secondary server. Now you can re-start the primary server and do the re-deployment. 24*7 service should be guaranteed because the requests are targeted to the secondary server while the primary server is re-starting.

I have not tested this kind of solution, but I don't see any reason why it should not work out.

Best,
Erno Lindfors
[e-mail]