Howdy, 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 [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache >Sent: Monday, February 02, 2004 2:04 AM >To: [EMAIL PROTECTED] >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 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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
