• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Challenge - Hot Deploying!

 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,
All appservers these days do automatic hot deploying of the enterprise applications, i.e jars/wars/ears.
I have some application which i am right now developing which need to be hot deployed. The application is like this.
I have a servlet running in the appserver(Weblogic 6.0) and it has dependency class files in "hotDeploy.jar" file which is NOT in the classpath of the appserver. What i am doing is loading the classes in the jar using my own class loader from the servlet. I am able to this successfully.
But the main problem is this. I have the servlet completely developed and stable. But my "hotDeploy.jar" contents are not stable and they keep changing form time to time as the development goes and as the requeirements changes. So i need to load the latest classes every time i try to use the classes in "hotDeploy.jar". Right now i am not able to do this and every time i make a change in the "hotDeploy.jar" contents, i need to restart the server which is really painful. Does any body has any idea how the hot deploying is done in appservers, so that i can incorporate that feature in to my application.
 
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ram,
if I understand you right you will replace your own deployment mechanism with a standardized like *.war file???
Here is an explanation about creating the war file: http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=18&t=000684
It should be standardized more or less in all app-servers. If you can't deploy the standardized war, you know you can look in the Weblogic Doku or ask in Weblogic forum on Javaranch.
Not sure if it helps, but hope so.
Axel
 
Ram Dhan Yadav K
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Axel,
I know how to deploy a war file. Thats not my issue.
I want to know how they do that in code, so that i can do that myself in my code. My applications has to be hotdeployed with the help of my code, not with the help of appservers hotdeployment policy.
You can think as if i am trying to write a hotdeploying tool!
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is my understanding that hot deploying is typically done by watching a file or directory for updates. This could take the form of a thread that would check the last modified time of your directory or file that you are interested in. When you notice that it is updated (or has just arrived for the first time) then you can take some action.
In your case you probably are extending or want to extend URLClassLoader to load the class(es) that you are interested in. Beware though, writing your own classloader can be very tricky and you can run into some annoying problems... notably NoClassDefFoundErrors and ClassCastExceptions. If you decide to take this route you need to remember not to keep instances of the old class around once you have loaded a new version of the same class.
If there is any way that you could combine all of your classes into your one war file to avoid having to do this, I'd recommend that first.
Hope that helps!
 
Ram Dhan Yadav K
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rob,
Thanks for the information. But how do i remove the old class instanced which are hanging out there in the environment before i load the new classes. This is my basic and most critical problem.
thanks,
 
Ram Dhan Yadav K
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any Ideas or clues?
Or guys i want to know if any of you guys have drilled down the code of open source projects like jboss and have any clue where that sort of functionality can be found?
thanks,
 
Rob
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ram,
The main problem I'm seeing with your situation is that you are hot deploying only a section of your application. Programs like JBoss use hot deployment but deploy a self contained group of classes and each deployment gets its own class loader instance. You could download it for free at http://www.jboss.org/ and check out their source code for ideas.
In your case you have a class which can possibly change over time interacting with other classes which do not change. There is a huge problem if the class or classes you are hot deploying are going to change their API. If methods are being added / removed then this is very difficult and it would probably be easier to just restart the server while developing.
A possible way would be to have an interface or abstract base class that the "hot classes" would implement / extend. You would put the interface in the stable jar and the new implementations would be in the hotdeploy.jar. A factory method or class would create instances of the interface by getting the latest implementation.
As for getting rid of old versions of the class you might want to consider an event based notification model. (Keep in mind that this is just my initial idea on how I might approach it. I haven't coded this and tested if it would work.) I was thinking that there would be something like a ClassUpdateListener interface that would have to be implemented by anything that keeps a reference to one of these hot classes. The factory that creates instances would offer a method like:

The factory would in this case perhaps have an internal thread doing the watching. When a new version is loaded it would make a callback to classes that have gotten instances from it.
In this way everyone who has a reference to one of the old classes could copy information into a new instance of the class using the well known methods defined in the base class or interface for the hot class. Once the instances of the old class have no references to them, they are eligable for garbage collection.
I have to say though that I would not go through all of this trouble if this hot deployment is not a feature of the end product. If this is solely for the purpose of ease of development then I'm not sure that all this is worth it. (Other than for the experience of having done it, of course )
 
Ram Dhan Yadav K
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rob,
------------------
The main problem I'm seeing with your situation is that you are hot deploying only a section of your application.
------------------

Exactly
-----------------------
Programs like JBoss use hot deployment but deploy a self contained group of classes and each deployment gets its own class loader instance. You could download it for free at http://www.jboss.org/ and check out their source code for ideas.
-------------------------

Its going to be a night mare!

-------------------------
In your case you have a class which can possibly change over time interacting with other classes which do not change. There is a huge problem if the class or classes you are hot deploying are going to change their API. If methods are being added / removed then this is very difficult and it would probably be easier to just restart the server while developing.
------------------------

But this the feature of the application i am developing. A small change, i have a stable set of classes(Servlet), which keep loading a set of unstable classes!
----------------------
A possible way would be to have an interface or abstract base class that the "hot classes" would implement / extend. You would put the interface in the stable jar and the new implementations would be in the hotdeploy.jar. A factory method or class would create instances of the interface by getting the latest implementation.
----------------------

I am exactly doing this. I have a stable interface which the unstable classes are implementing and i am trying to load these unstable classes using a my own class loader!
-----------------
As for getting rid of old versions of the class you might want to consider an event based notification model. (Keep in mind that this is just my initial idea on how I might approach it. I haven't coded this and tested if it would work.) I was thinking that there would be something like a ClassUpdateListener interface that would have to be implemented by anything that keeps a reference to one of these hot classes. The factory that creates instances would offer a method like:

code:
--------------------------------------------------------------------------------
public static HotClass newHotClass(ClassUpdateListener l)
--------------------------------------------------------------------------------
The factory would in this case perhaps have an internal thread doing the watching. When a new version is loaded it would make a callback to classes that have gotten instances from it.
In this way everyone who has a reference to one of the old classes could copy information into a new instance of the class using the well known methods defined in the base class or interface for the hot class. Once the instances of the old class have no references to them, they are eligable for garbage collection.
-----------------------------------

Looks interesting, i will try to to slog on this idea!
I have to say though that I would not go through all of this trouble if this hot deployment is not a feature of the end product. If this is solely for the purpose of ease of development then I'm not sure that all this is worth it. (Other than for the experience of having done it, of course )
Its my food now, i have to do it!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic