On Tue, 4 Mar 2003 01:18, Ulrich Mayring wrote: > Peter Donald wrote: > > Specifically the following jars are no longer accessible to application > > by default; > > > > excalibur-thread > > excalibur-threadcontext > > excalibur-pool > > excalibur-collections > > excalibur-instrument > > excalibur-logger > > excalibur-util > > excalibur-extension > > excalibur-concurrent > > Does this mean that every application that, for example, wants to log > needs to include the excalibur-logger jar?
Nope. Logging is handled by the kernel. But if you host another container inside phoenix (ie fortress) it may need that jar. Essentially some of those jars are only needed by container type applications. These jars being excalibur-extension excalibur-logger excalibur-util excalibur-threadcontext And you only need them if you include components that depend on them. > Also, could you again explain > the "versioning problem" that you are trying to solve? I haven't > understood it. Essentially I get asked a couple of times a week why X doesn't work with version Y of Phoenix and it is due to incompatible library versions. Usually it is because they have incompatible versions of excalibur-instrument, excalibur-pool, excalibur-threadcontext or excalibur-thread. The funny thing is that the only one of those librarys that phoenix uses is threadcontext. It previously used the rest but they no longer used at all but they keep causing problems. Even worse we once had a thread jar that was incompatible with the threadcontext jar and no one noticed as phoenix never used the thread jar. It wasn't noticed until some of the applications tried to run using thread that problems arose. > I'm not sure if I understood you correctly, but if this means what I > think it means, then this change is IMHO not feasible for an application > server. Imagine 100s of applications running under Phoenix, all > including the same JAR - this is a waste of memory. Also, it is update > hell, when you have to rebuild and redeploy every single application. See below. That functionality has not been taken away - only the default libraries have changed. Users can still choose to do just this and in many cases it makes perfect sense to do this. > The right solution would be to let users make the choice, like it is > now, instead of limiting them. I thought it was a great feature that I > could put libraries in phoenix/lib or in the SAR file - why take that > feature away? That feature has not been taken away - it still exists. The only difference is that there are less libraries that are included by *default*. You can still copy those libraries back into $PHOENIX_HOME/lib and any other libraries into there that you want. -- Cheers, Peter Donald He strains to hear a whisper who refuses to hear a shout. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
