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/02/01 17:48:46 UTC
Re: Jakarta Collections 3.0?
If I remember correctly ( and if it didn't change ), tomcat needs
modeler in a parent classloader. Modeler has an optional dependency on
digester, which depends on beanutils and collections. They both depend
on logging, and modeler also depends on jmx.
So unless some classloader trick is used - we have to have collections
in the parent loader - which forces the entire tomcat instalation to use
the same collection version ( unless reverse loader tricks are used ).
That implies that if tomcat upgrades to collections3.0 - all webapps
that use collections2.0 may stop working.
Even more interesting - we don't actually have this choice - since if
digester changes to the new collections, we're forced to do the same :-)
What if we use modeler without digester ? Are there other components
that depend on digester + collections ? At least for emebed this would
be a good solution ( it won't reduce the size too much, but it may
reduce the dependency impact it has when it's embeded - since whatever
app it is emebeded into will be forced to update collections and all
packages that depend on it - or do classloader tricks )
Costin
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>> Jess Holle wrote:
>>
>>> Can anyone shed any light on the plans for Tomcat using Jakarta
>>> Collections 3.0?
>>>
>>> I ask as we currently bundle Jakarta Collections for use in and out
>>> of the servlet engine. We wish to use a consistent version
>>> throughout. Given that Tomcat bundles Jakarta Collections within its
>>> common/lib area, we effectively use whatever Tomcat uses while in the
>>> servlet engine in any case. We're therefore at Collections 2.1 as
>>> Tomcat is.
>>>
>>> Are there plans to move Tomcat to Jakarta Collections 3.0?
>>
>>
>>
>> It would have been better if either:
>> - 3.0 was backwards compatible with 2.0 :)
>> - it was using different package names
>>
>> Note that you should be able to override and use collections 2.1
>> inside a webapp even if collections 3.0 is in common/lib, and
>> hopefully it'll work. If it doesn't, there will be a huge mess, and
>> lots of hate mail ;)
>>
>
> I guess we missed the release vote in commons ( us and all people using
> digester, benautils - and their dependencies as well ) ...
>
>
>
> Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Jakarta Collections 3.0?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> If I remember correctly ( and if it didn't change ), tomcat needs
>> modeler in a parent classloader. Modeler has an optional dependency on
>> digester, which depends on beanutils and collections. They both depend
>> on logging, and modeler also depends on jmx.
>>
>> So unless some classloader trick is used - we have to have collections
>> in the parent loader - which forces the entire tomcat instalation to
>> use the same collection version ( unless reverse loader tricks are
>> used ).
>> That implies that if tomcat upgrades to collections3.0 - all webapps
>> that use collections2.0 may stop working.
>
>
> Why ? I don't understand. Tomcat will override anything except the
> system classloader.
You mean the classes in the common loader get overriden by the reverse
loader ? Does it work if some classes are loaded with a loader ( for
example some from the old package ) and some are loaded with the other
loader ? I mean, can we force a loader for a particular package -
blocking delegation completely ( even for classes that are not found ) ?
>
>> Even more interesting - we don't actually have this choice - since if
>> digester changes to the new collections, we're forced to do the same :-)
>>
>> What if we use modeler without digester ? Are there other components
>> that depend on digester + collections ? At least for emebed this would
>> be a good solution ( it won't reduce the size too much, but it may
>> reduce the dependency impact it has when it's embeded - since whatever
>> app it is emebeded into will be forced to update collections and all
>> packages that depend on it - or do classloader tricks )
>
>
> The startup code depends on digester :-( The web.xml parsing depends on
> digester. Etc, etc :-(
I think some of it can be done in a separate loader ( I tried it at some
time ), at least loading the web.xml part. For the startup code - I
don't know ( but it could use ant or jmx ).
I guess a lot has changed since I last looked, but packages like
collections 3 in the top class loader makes me pretty uncomfortable.
( the real problem will be for apps that embed tomcat, when digester or
other components will start using collection3 - forcing tomcat too ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Jakarta Collections 3.0?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> If I remember correctly ( and if it didn't change ), tomcat needs
> modeler in a parent classloader. Modeler has an optional dependency on
> digester, which depends on beanutils and collections. They both depend
> on logging, and modeler also depends on jmx.
>
> So unless some classloader trick is used - we have to have collections
> in the parent loader - which forces the entire tomcat instalation to use
> the same collection version ( unless reverse loader tricks are used ).
> That implies that if tomcat upgrades to collections3.0 - all webapps
> that use collections2.0 may stop working.
Why ? I don't understand. Tomcat will override anything except the
system classloader.
> Even more interesting - we don't actually have this choice - since if
> digester changes to the new collections, we're forced to do the same :-)
>
> What if we use modeler without digester ? Are there other components
> that depend on digester + collections ? At least for emebed this would
> be a good solution ( it won't reduce the size too much, but it may
> reduce the dependency impact it has when it's embeded - since whatever
> app it is emebeded into will be forced to update collections and all
> packages that depend on it - or do classloader tricks )
The startup code depends on digester :-( The web.xml parsing depends on
digester. Etc, etc :-(
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Jakarta Collections 3.0?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
>> Subscribers to COMMONS-DEV will see that I'm proposing to remove the
>> dependency
>> on [collections] from both [beanutils] and [digester]. Both
>> dependencies are
>> very thin, and doing this will avoid penalizing [beanutils]/[digester]
>> customers for what [collections] did.
>
> Great!
>
> I'm feeling a bit guilty ( and I think other should too ) about missing
> the release vote for collections.
I agree: this would be great (too many cascading dependencies causing
trouble in the end). Thx :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Jakarta Collections 3.0?
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
>
> Subscribers to COMMONS-DEV will see that I'm proposing to remove the dependency
> on [collections] from both [beanutils] and [digester]. Both dependencies are
> very thin, and doing this will avoid penalizing [beanutils]/[digester]
> customers for what [collections] did.
Great!
I'm feeling a bit guilty ( and I think other should too ) about missing
the release vote for collections.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Jakarta Collections 3.0?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Costin Manolache <cm...@yahoo.com>:
> If I remember correctly ( and if it didn't change ), tomcat needs
> modeler in a parent classloader. Modeler has an optional dependency on
> digester, which depends on beanutils and collections. They both depend
> on logging, and modeler also depends on jmx.
>
> So unless some classloader trick is used - we have to have collections
> in the parent loader - which forces the entire tomcat instalation to use
> the same collection version ( unless reverse loader tricks are used ).
> That implies that if tomcat upgrades to collections3.0 - all webapps
> that use collections2.0 may stop working.
>
> Even more interesting - we don't actually have this choice - since if
> digester changes to the new collections, we're forced to do the same :-)
>
>
> What if we use modeler without digester ? Are there other components
> that depend on digester + collections ? At least for emebed this would
> be a good solution ( it won't reduce the size too much, but it may
> reduce the dependency impact it has when it's embeded - since whatever
> app it is emebeded into will be forced to update collections and all
> packages that depend on it - or do classloader tricks )
>
Subscribers to COMMONS-DEV will see that I'm proposing to remove the dependency
on [collections] from both [beanutils] and [digester]. Both dependencies are
very thin, and doing this will avoid penalizing [beanutils]/[digester]
customers for what [collections] did.
>
> Costin
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org