Hi,
I saw you changes in cvs regarding mx.loading. Great that you are
relaxing the signature restriction! But I also saw that you have added
the possibility to let the heirirachical load from parent first; this
would be a welcome addition and might perhaps make it a little bit
easier to live with the current classloader architecture (one might at
least place interface/param classes in the global repository). However;
i do not understand how it will work.
As far as I can see this would be done through heir.loadClass(), but as
far as I can see it this method is never ever called (except from
UnifiedClassLoader.loadClass, but wich is overridden in
UnifiedClassLoader3.
Is not the loading scheme actually this:
ucl3.loadClass->LoadMgr->beginLoadTask(and then either - i order).
1. ucl3.repository->loadClassFromCache
2.
ucl3.repository->loadClassFromClassLoader->ucl3->loadClassLocally->ucl.super.loadClass()
3.
ucl3.repository->getPackageClassLoaders->ClassLoadingTask->run->ucl3->loadClassLocally.
As far as I can see it there is nowhere in this scheme that java2 parent
delegation actually can play any role apart from the cache (the class
must already have been loaded in a parent) and in getPackageClassLoader.
The following scenario for example would not allow for Java2 parent
delegation.
Global rep: MyInterface.class
HeirRep: MyInterface.class MyImpl.class
Because if MyImpl.class was loaded the first and MyInterface.class was
not previously loaded we would end up in stage 2 and the classloader
would load MyInterface.class from HeirRep. The only way in the current
scheme would be to do something with loadClassFromClassLoader.
Another thing I have been noting during my (frustrating) work with this
how the caching work in an hierarchical situation: when classes are
loaded through getPackageClassLoader classes will be cached not in the
repository the class had its classloader, but in the repository where
the classloader how started the loading is located. This means that a
class can actually be loaded through a repository hier up the chain
without being cached there.
Should not this part in LoadMgr:
if( loadTask.threadTaskCount == 0 )
{
Class loadedClass = threadTask.getLoadedClass();
if( loadedClass != null )
{
ClassLoader loader = loadedClass.getClassLoader();
// Place the loaded class into the repositry cache
repository.cacheLoadedClass(threadTask.getClassname(),
loadedClass, loader);
}
synchronized( loadTask )
{
loadTask.state = ClassLoadingTask.FINISHED;
loadTask.notify();
}
}
Instead use the UCL3.repository to cache the class?
Well, some comments just. And by the way: thanks for all your hard work.
//Peter
mån 2003-03-03 klockan 20.01 skrev Scott M Stark:
> Yes, the redeploy semantic through the proxy was too much. I will handle the
> changes to allow for subclassing LoaderRespoitory this week.
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> ----- Original Message -----
> From: "Peter Antman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, March 03, 2003 6:53 AM
> Subject: [JBoss-dev] Possibility to override LoaderResository
>
>
> > Hi,
> > my last sugestion on how to enhance the scoped loader repository stuff
> > does not seems to have been welcomed into JBoss. However it would be
> > verry nice if it was possible to extends LoaderRespoitory and
> > EARDeployer outside of the jboss package hierarkies. This is not
> > possible now due to some protected signatures in jboss.mx.loading and
> > the way the EARDeployer is written. Some fairly small changes would
> > however make it possible to define your own repository strategies. Here
> > are the diffs to do it. Is these changes possible to get into the 3.0
> > line or would they distrupt any current funktionality that I do not
> > understand (security wise for example):
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
CTO WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
