Jason,
I am very interested in a centralized management of classes per VM. This is
the only way we will make the GPA come alive with JMX as a bus. Setting
classloaders properly on thread context requires every service or module to
be able to identify the classes with a global application notion.
I need to go back to rabbit hole next week (been sidetracked the last few
weeks with support) and once I separate the stacks (including an httpd one
;-) surprise surprise) then I will run smack on into these issues and then
the centralized repo and loading will trivially appear.
In the mean time I recommend you read the Jung code on the new deployer some
of the Class Loader magic we discussed back in Christmass.
regards
marcf
|-----Original Message-----
|From: Jason Dillon [mailto:[EMAIL PROTECTED]]
|Sent: Friday, July 20, 2001 4:38 AM
|To: [EMAIL PROTECTED]
|Cc: [EMAIL PROTECTED]
|Subject: .sar, class loaders and depend. libs
|
|
|Marc, have you done any work on the new loading system with respect to
|common dependency libraries (for dynamic library reloading... possibly even
|usage of more than one library version per vm) for the new startup
|mechanism yet? I remember that you said that was one thing you were
|interested in.
|
|If there was a ServiceClassLoader, which would inspect a the available
|classes from:
|
| 1) The .sar class loader
|
|The service archinve classes will override all others (perhaps there is a
|per service config class loader that preceeds this to allow for per
|configuration class loading overrides).
|
| 2) A dynamic library class loader
|
|This is where we plug in a list of other class loaders, which will be the
|class loaders for a library archive, like ant 1.1 vs. ant 2. This is
|an odd example, but imagine a service that used ant 1.1 in someway, then a
|service that required ant 2.0. Both set of classes could be loaded in the
|same vm at the same time. Why I don't know, but the point is that we could
|load arbirary versions of dependant libraries into the same vm for
|services.
|Could even be used for fast hot swap when versions change. Have both
|versions of the service in memory and initalized at the same time,
|then turn
|off the old one, start the new one. Down time is minimized =)
|
| 3) the server class loader
|
|This is the basic class loader used to load the core JBoss components.
|Perhaps this is reloadable?
|
| 4) the system class loader
| 5) the primordial class loader
|
|Yada, yada, yada.
|
| * * *
|
|Just a thought.
|
|--jason
|
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
