|> |public interface DeployerMBean extends ServiceMBean {
|> | /**
|> | * extended method to find out whether and in which classloader
|> | * an application is actually running
|> | */
|> | public ClassLoader whereDeployed(URL url) throws
|DeploymentException;
|> |
|>
|> The name is really bad but I am very pleased to see the "central naming"
|> architecture. Finally we see a first take at the CL-service.
|
|BTW, what is the purpose of this method?
To give you a classloader for a specified URL/Class/dependent object... :)
|IMHO the one class/one CL should be enforced by using classloader trees
|within a system. That way there is no way to mess things up due to the
|classloader delegation model.
hey here I agree (wow :) in fact the method is a "window" to that tree.
Whether we construct that tree on URL, JNDI name, class name is something
that I am open to discussing. I believe it is class name as you do (see my
previous posts)
|> You can either have the J2EE Deployer keep that logic (today it
|is done this
|> way and imho sucks) or we can do it at the containerFactory
|level (like you
|> propose).
|
|Or introduce a SystemDeployer which is yet another umbrealla layer. This
|is what we are talking about, so it might make sense.
bla... why "systemDeployer" you still need to explain... it is an
APplicationDeployer (or something like it) that manages links and
dependencies.
|> We need to sit down and actually map the action of deploying an
|application
|> with many beans and some already deployed and sym linked with ejb-ref, we
|> need to define the topology (I know you guys like fancy words) of the CL,
|
|The topology is simple: tree. Has to be.
hehe, the linking of the CL has to be tree indeed since the parent mechanism
is the only one afforded by your monkeyClassloaders.
However the mapping of the subset of classes spaces by a sur-jection to the
CL space is something that we need to clearly define.
dum...da da.... don't you love the sound of it? (I don't even know what the
fuck I am talking about :))))
|> I will try to take a crack at it next week it is a service we have been
|> talking about for awhile now (level2) but never got around to doing
|
|IMHO we should not do this before we have the new metadata model done.
|The metadata object is what get's passed around (not the CL) and the
|various container factories extend this with their own stuff (ET adds
|WAR info, CF adds EJB info, etc.). This way you have one object graph
|that you can traverse and find all info you will ever need. And if you
|need to add info that's ok too, since the new metadata model allows
|arbitrary "facets" to be added at any level (e.g. an EJB JAR can have a
|"classloader" facet which is the classloader of the app). This approach
|will make the system model muuuch easier to do.
mmmm the CL stuff is VM bound, the metadata should be able to travel....
separate issues in my mind
marc
"I love to wrestle with the kid"
let's go down to the mud, this is the fun part...
|
|regards,
| Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
