Hi!
marc fleury wrote:
> |> |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... :)
Which is needed..when..?
All you need is the classloader tree. If a node want's to use a class it
uses its own classloader to get to it. The classloader delegation model
will make sure that you can access it if it is available in the tree
from the node up to the root.
> |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.
Which isn't really needed at any point. Or is it? Explain when.
> 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)
The tree is constructed by relating applications (=EAR files). The
parent of an EAR classloader is the parent EAR's classloader. Plain and
simple.
> |> 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.
It's just a name. I called it "system" because "application" was kind of
taken by the J2EE terminology. A system is a set of applications (==set
of EAR files) and their relationship.
If you want to call it "application" that's ok, as long as we agree on
the terminology and it doesn't confuse the matters more.
> |> 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.
"monkey"? What?
> 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.
Can you say this in English please?
If you are talking about duplication of classes in a tree that's ok as
long as the duplication doesn't occur along a line from the root, i.e.
two subtrees may define the same class and they will indeed get two
versions of the same class.
> dum...da da.... don't you love the sound of it? (I don't even know what the
> fuck I am talking about :))))
Wow, what a surprise. ;-)
> |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....
nonono, each metadata object is VM-local and is created at deployment
time. You don't want to pass that around.
> separate issues in my mind
It's all about metadata about the application. Some is static (and read
from XML) and some is dynamic and "attached" to the metadata structure
at runtime. The result is a metadata structure that you can traverse to
find all relevant information about all nodes in the tree. You never get
the "I can't get that information from here" problem.
> marc
> "I love to wrestle with the kid"
> let's go down to the mud, this is the fun part...
Make sure you hold your breath when you hit the mud floor buddy ;-)
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
