Adam,
Given that you have supplied a corrective patch 5 days ago, and that no commons-logging developer has picked it up, do you think pretending the problem does not exist is the wisest approach?
Gump has proved itself by catching the problem. We may be able to fool gump but the problem is going to surface at runtime, unless of course it gets fixed before.
At 05:06 PM 5/17/2004, Adam R. B. Jack wrote:
> -the issue is not that we have broken something, but that commons logger > and log4j are no longer compatible at run time in Gump, at least for us. > Maybe its a classpath thing, maybe it's something else.
Interesting, I hadn't expected this, but it is interesting.
Gump noticed (a week ago?) that a change to log4j (a final removal after a 2 year deprecation) cause C-L no longer to compile. This was reported, and even a patch added to Bugzilla for C-L, however this patch wasn't added (I need to check if it has yet).
Anyhow to try to get past this we let C-L temporarily depend upon log4j-1.2 (also Gumped) and this seemed to work. Unfortunately your environment explicitly states log4j ('cos it had to, see next) so you get the runtime problem. [Jar Hell I'd like to work on via depot-version, but that is a separate topic.]
So we have a few courses of action, the best being C-L committing the patch to become compatible w/ log4j today & up to two years ago (as I read it). Also, I think we ought look at C-L setting it's optional dependencies as runtime, and you no longer explicitly depending upon log4j, but depending upon commons-logging inherit="runtime". Hopefully that will Gump you on the correct C-L dependency.
Stefan, anything to add?
regards,
Adam
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
