tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <>
Subject RE: Jakarta Collections 3.0?
Date Mon, 02 Feb 2004 13:48:45 GMT

FYI, it will be a while before BeanUtils (which is a dependency of
Digester itself, so it's the blocker on this collections 3.0 migration)
has a final release (it'll be BeanUtils 1.7) that depends on collections
3.0.  The current BeanUtils dev version already builds fine against
collections 3.0, however, and therefore it's possible to obtain snapshot
builds.  I started a thread to discuss the next BeanUtils release on the
commons-dev mailing list, if anyone is interested -- I'll be helping out
with that release.

Yoav Shapira
Millennium ChemInformatics

>-----Original Message-----
>From: news [] On Behalf Of Costin Manolache
>Sent: Monday, February 02, 2004 2:04 AM
>Subject: Re: Jakarta Collections 3.0?
>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
>>> digester, which depends on beanutils and collections. They both
>>> on logging, and modeler also depends on jmx.
>>> So unless some classloader trick is used - we have to have
>>> 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
>>> 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
>>> 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
>>> 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
>> digester. Etc, etc :-(
>I think some of it can be done in a separate loader ( I tried it at
>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 ).
>To unsubscribe, e-mail:
>For additional commands, e-mail:

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message