Sean, Thanks for the response. I didn't mean to imply that CFMX had done anything wrong. I'm well aware that issues with .jar versioning is a familiar frustration in the Java world.
I had hoped that someone with a more intimate knowledge of CFMX internals could suggest a solution that didn't involved reworking my code. Plus, it seems to me that if I do rework the code to comply with log4j 1.1.3, when the next version of CFMX comes out with a newer version of log4j, my code breaks again. Plus, while in this case the problem was log4j changing its API, it's not inconceivable that other shared libraries may have a similar problem, now or in the future. It seems unrealistic that developers must be tied to the versions of libraries shipped with CFMX. I think a better solution would be a means by which an application can be defined such that its libraries take precedence over the ones shipped with CFMX (which of course is possible with standalone engines). Or is this possible now with CFMX and I'm overlooking it? Thanks, Dave Jones NetEffect At 01:57 PM 6/21/03 -0700, you wrote: >On Saturday, Jun 21, 2003, at 13:47 US/Pacific, Dave Jones wrote: > > So, it appears that a) the log4j.jar that ships with CFMX is not > > compatible with log4j 1.2.7; and b) that CFMX is dependent upon > > its version of log4j. > >What you've got here are two Java applications running on the same JVM >that require different versions of the same library - and the library >itself has changed its API. If you're going to point a finger of blame >at some component of this, you could reasonably pick the library >(log4j) for breaking the contract (API) it had with its users. > > > Or is it unreasonable to expect CFMX to support existing Java > > apps? > >A lot of Java apps will work just fine with CFMX - library vendors >shouldn't change APIs in incompatible ways (and they generally don't). > > > If existing Java apps have to be > > rewritten for the CFMX environment, much of the perceived benefits go > > away. > >Your Java app would need to be "rewritten" if you moved it to any >environment where you had a different version of log4j. Here's what it >says on the log4j page: > >"Version 1.2 is the 22nd major public release of log4j. All changes >except the removal of deprecated methods are backward compatible such >that log4j 1.2 can be considered a drop in replacement for log4j 1.1.3. >The only exception is the renaming of the CategoryFactory class to >LoggerFactory class such that subclasses of Category class must be >modified and recompiled. The recommended pattern for >extending the Logger class is wrapping. Moreover, we strongly >discourage casual users from subclassing the Category or Logger > classes." > >You can see from this that they have introduced two types of >incompatibility: >- removing deprecated methods (breaking code that relied on them) >- renaming a class (breaking code that uses that class or the Category >class) > >CFMX uses 1.1.3. The log4j site has that version available so you could >download it and recompile your code against that version (you may or >may not need to make code changes). > >Sean A Corfield -- http://www.corfield.org/blog/ > >"If you're not annoying somebody, you're not really alive." >-- Margaret Atwood > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
