On 2001.09.20 19:14:02 -0400 marc fleury wrote:
> |well, it seems to me that there is always going to be a spine
> classloader,
> |and for each application an application classloader. Now if an ear or
> |other "application" say includes some sars, do they get loaded with the
> |system classloader or the application classloader? I'd tend to think
> the
> |application classloader.
>
> that is not how parent delegation works. If you put the classes in the
> parent (system) those are going to be picked up. If you want to override
> this then we need unification of Scoped and URL classloaders.
Maybe I wasn't clear enough. As I understand it, everything (all the
classes) in an ear gets loaded by a application classloader, so it can't
interfere with other applications, right? I'm saying perhaps this should
apply also to mbeans whose codebase is in a sar in the ear, rather than
adding the mbeans' codebase to the system classloader, which is what would
happen if we used the ServiceDeployer right now.
btw we need to use the scoped classloader or a ServiceLibrary like
classloader for deploying rars that are in an ear, so the rest of the
application can find the rar's classes! I've seen some comments that make
me think weblogic may not have got this quite right ;-)
>
> |I haven't had a chance to really investigate, is there a fundamental
> |difference between your new classloader scheme and the scoped
> classloader?
> |Can we unify them at some point?
>
> Scoped class loader is more advanced than the URLCL and deals
> specifically
> with
> 1- scope which could be interesting in the case of system (versions)
> 2- redeployment of the applications which doesnot apply to the Mbeans.
Why not? I think we need to be able to undeploy/redeploy mbeans without
bringing down the server, and in fact we can today-- there's a little
problem with automatic recursive undeployment that I'm about to fix, but
you can undeploy sars, making the classes unavailable, and redeploy them.
See the ServiceDeployer tests.
david jencks
>
> I have separated MBeanCL and URL CL as this goes deeper in the case of
> the
> system itself, that is the about the only point that is a bit more
> advanced.
>
> Unification when needed, not now afaics
>
> marcf
>
> |
> |david jencks
> |
> |
> |<snip>
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
