You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2004/10/06 07:11:30 UTC
loader
I checked in the first part - I'm still working on making build.xml
changes and the catalina-side code.
It is certainly experimental code for now - I think it works better than
Bootstrap/etc, but the reloading of connectors/etc is still very tricky
( it kind of works, but I still don't have a clean interface ).
I placed it in util/loader mainly for eclipse/IDE users - I have it
compiled to a separate classes dir, and use the eclipse autocompilation
- it's pretty cool and efficient ( i.e. no need to use "ant" or compile
most of the time, just type and run :-).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> I didn't have time to look at the code yet, though.
Wait a week or 2 - the loader part is fine, but the catalina side is
still a bit messy and I need to find a good way to integrate with the
build ( to make it completely optional/isolated - I don't want to affect
the 5.5 schedule by breaking something :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Mladen Turk wrote:
>
>>
>> Costin, can you elabborate the purpose of the patch?
>> Perhaps I've missed few discussions.
>>
>
> There are few goals:
> - allow tomcat components ( connector, valves, etc ) to be
> added/removed/upgraded dynamically, at runtime - without requiring a
> full restart.
> - cleanup the startup code - the split startup package, lots of
> introspection and dependencies ( commons-logging, jmx needed in
> CLASSPATH )
> - maybe improve the class loading - for example WebappClassLoader use
> of the jar index, the code is a bit complex, etc
> - make it easier to integrate tomcat in apps like jboss or eclipse -
> which both use similar class loaders and module mechanisms ( jbossmx
> and osgi ).
>
> One extra benefit may be on allowing more flexibility in the
> common/shared/webapp hierarchy - if WebappClassLoader extends the
> loader, it will be easier to have webapps using different versions of
> shared libraries ( right now you need to place shared libs in shared
> or common, and you can't have more than a version ).
>
> I've been trying to do this for a very long time - there is some code
> in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ),
> but using an m-let-like classloader is a better solution than what was
> there.
+1: nice goals :)
I didn't have time to look at the code yet, though.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
> Costin Manolache wrote:
>
>> Mladen Turk wrote:
>>
>>>
>>> What about commons-deamon?
>>>
>>
>> What about it :-) ?
>>
>> Daemon is a different level - it's about launching a resident process
>> (or service in windows ). No connection with how the process is loading
>> its classes.
>>
>
>
> Sure, but the wheel was invented long time ago :).
> How about making things usable?
Which things to make usable ? Daemon ? It's not my itch to start
services on windows:-)
Yes, the wheel was invented long ago - and we are still using the
simplistic hierarchical class loader + delegation.
> Do we really need all those different loaders?
That can be said about anything :-)
I'm making the compile optional - so if you don't explicitely ask for it
it'll not get compiled. When it's completely ready - I hope it will
replace Bootstrap/StandardClassLoader - so we'll still have 1 loader for
standalone.
If embeded - as I said, the intent is to not use the loader but the
embedor's loader - however ability to split tomcat in smaller components
and manage each separately should remain ( supported by the embedding
app loader ). That's why the loader is mirroring the fundamental
behavior of mlet/jboss/eclipse/osgi - i.e. repository of classloaders
delegating to each other.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> Mladen Turk wrote:
>>
>> What about commons-deamon?
>>
>
> What about it :-) ?
>
> Daemon is a different level - it's about launching a resident process
> (or service in windows ). No connection with how the process is loading
> its classes.
>
Sure, but the wheel was invented long time ago :).
How about making things usable?
Do we really need all those different loaders?
MT.
Re: loader
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
> Costin Manolache wrote:
>
>> Mladen Turk wrote:
>>
>>>
>>> Costin, can you elabborate the purpose of the patch?
>>> Perhaps I've missed few discussions.
>>>
>>
>> There are few goals:
>> - allow tomcat components ( connector, valves, etc ) to be
>> added/removed/upgraded dynamically, at runtime - without requiring a
>> full restart.
>> - cleanup the startup code - the split startup package, lots of
>> introspection and dependencies ( commons-logging, jmx needed in
>> CLASSPATH )
>> - maybe improve the class loading - for example WebappClassLoader use
>> of the jar index, the code is a bit complex, etc
>> - make it easier to integrate tomcat in apps like jboss or eclipse -
>> which both use similar class loaders and module mechanisms ( jbossmx
>> and osgi ).
>>
>> One extra benefit may be on allowing more flexibility in the
>> common/shared/webapp hierarchy - if WebappClassLoader extends the
>> loader, it will be easier to have webapps using different versions of
>> shared libraries ( right now you need to place shared libs in shared
>> or common, and you can't have more than a version ).
>>
>> I've been trying to do this for a very long time - there is some code
>> in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ),
>> but using an m-let-like classloader is a better solution than what was
>> there.
>>
>
> What about commons-deamon?
>
What about it :-) ?
Daemon is a different level - it's about launching a resident process
(or service in windows ). No connection with how the process is loading
its classes.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> Mladen Turk wrote:
>
>>
>> Costin, can you elabborate the purpose of the patch?
>> Perhaps I've missed few discussions.
>>
>
> There are few goals:
> - allow tomcat components ( connector, valves, etc ) to be
> added/removed/upgraded dynamically, at runtime - without requiring a
> full restart.
> - cleanup the startup code - the split startup package, lots of
> introspection and dependencies ( commons-logging, jmx needed in CLASSPATH )
> - maybe improve the class loading - for example WebappClassLoader use of
> the jar index, the code is a bit complex, etc
> - make it easier to integrate tomcat in apps like jboss or eclipse -
> which both use similar class loaders and module mechanisms ( jbossmx and
> osgi ).
>
> One extra benefit may be on allowing more flexibility in the
> common/shared/webapp hierarchy - if WebappClassLoader extends the
> loader, it will be easier to have webapps using different versions of
> shared libraries ( right now you need to place shared libs in shared or
> common, and you can't have more than a version ).
>
> I've been trying to do this for a very long time - there is some code in
> 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but
> using an m-let-like classloader is a better solution than what was there.
>
What about commons-deamon?
MT.
Re: loader
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
> Costin, can you elabborate the purpose of the patch?
> Perhaps I've missed few discussions.
>
There are few goals:
- allow tomcat components ( connector, valves, etc ) to be
added/removed/upgraded dynamically, at runtime - without requiring a
full restart.
- cleanup the startup code - the split startup package, lots of
introspection and dependencies ( commons-logging, jmx needed in CLASSPATH )
- maybe improve the class loading - for example WebappClassLoader use of
the jar index, the code is a bit complex, etc
- make it easier to integrate tomcat in apps like jboss or eclipse -
which both use similar class loaders and module mechanisms ( jbossmx and
osgi ).
One extra benefit may be on allowing more flexibility in the
common/shared/webapp hierarchy - if WebappClassLoader extends the
loader, it will be easier to have webapps using different versions of
shared libraries ( right now you need to place shared libs in shared or
common, and you can't have more than a version ).
I've been trying to do this for a very long time - there is some code in
3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but
using an m-let-like classloader is a better solution than what was there.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: loader
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> I checked in the first part - I'm still working on making build.xml
> changes and the catalina-side code.
>
> It is certainly experimental code for now - I think it works better than
> Bootstrap/etc, but the reloading of connectors/etc is still very tricky
> ( it kind of works, but I still don't have a clean interface ).
>
> I placed it in util/loader mainly for eclipse/IDE users - I have it
> compiled to a separate classes dir, and use the eclipse autocompilation
> - it's pretty cool and efficient ( i.e. no need to use "ant" or compile
> most of the time, just type and run :-).
>
Costin, can you elabborate the purpose of the patch?
Perhaps I've missed few discussions.
Regards,
Mladen
Re: loader
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> I checked in the first part - I'm still working on making build.xml
> changes and the catalina-side code.
>
> It is certainly experimental code for now - I think it works better than
> Bootstrap/etc, but the reloading of connectors/etc is still very tricky
> ( it kind of works, but I still don't have a clean interface ).
>
Didn't look much in detail...
We'll need something that will signal that all the classes are
loaded, probably even adding that as native (if native is used),
so we can use that instead TomcatLoader.
MT.