You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jacob Kjome <ho...@visi.com> on 2002/06/19 21:59:00 UTC
Re: Request to drop version number from log4j jar file name ( WAS: St range weblogic problem with new jarfile name )
Hello Tom,
sorry, but for keeping track of what jars you have in your webapp, it
is nice to be able to look at the directory and see what version of
jar files you have. Besides, it takes all of 2 seconds to rename it
to what you want. As far as having multiple versions in classloaders,
that can still happen as long as the log4j.jar is sitting in different
directories. You have the same issues. In the case of the named jar,
at least you know quickly which one to remove and which one to keep.
+1 for continuing to provided version named jars.
Jake
Wednesday, June 19, 2002, 2:44:43 PM, you wrote:
TC> To bring the discussion back to my original request... ;->
TC> This thread has brought to our attention an unexpected problem related to the log4j-1.2.x.jar file name. Like Mr. Bridges, I would not claim that this is a log4j problem - it's quite clear it's
TC> a deficiency in the BEA code.
TC> Ceki replied to my original post, saying that this was the correct forum to make such a request, but I was not really informed as to the status of that request, and it's not clear to me what is
TC> involved in the decision process. Is this just a unilateral decision to be made by Ceki, or is there some formal or informal decision making process among a core set of log4j developers? If the
TC> version number was added because a user requested it, can it be dropped because another user or group of users requests that it be dropped?
TC> In any case, I would like to re-submit my request to drop the version number from the log4j jar file name. Here are the reasons I included in my original post:
TC> * All scripts that reference the jar file will need to be modified when taking each minor release. This would include scripts to build applications, run programs, set classpaths, etc.
TC> * Multiple versions of the jar file will end up in the system. If it's in the Java extensions directories, where class loading order cannot be controlled, there will be cases where the wrong
TC> version of classes will be found.
TC> I would also like to point out that as far as I know, the other major players in the Java arena ( Sun, IBM,...BEA - ha, ha!, etc. ) are not adding version numbers to their jar file names. While
TC> this certainly doesn't mean that log4j has to follow this convention, it does mean that log4j will be the exception to the rule ( which, by the way, makes it susceptible to coding errors such as
TC> we've seen here ;-> ).
TC> So please post a decision to this request.
TC> Thanks,
TC> Tom
TC> ------------------------------------------
TC> Tom Caulkins
TC> Senior Systems Developer
TC> Platform Services - Business Intelligence Platform
TC> SAS Institute Inc.
TC> Tom.Caulkins@sas.com
TC> -----Original Message-----
TC> From: Lu, David [mailto:dlu@tiaa-cref.org]
TC> Sent: Wednesday, June 19, 2002 1:52 PM
TC> To: 'Log4J Users List'
TC> Subject: RE: Strange weblogic problem with new jarfile name (WAS: Why is
TC> the version number included in the log4j jar file name?)
TC> We have experienced the same problem with not only the log4j jar but any
TC> other jar that has a "dot" (other than the one preceding the jar suffix) in
TC> its filename. We experienced this problem in WebLogic 7.0 with jars like
TC> castor-0.9.3.9-xml.jar and jakarta-regexp-1.2.jar.
TC> BEA told us that this problem was a corrected known problem in 6.x but that
TC> this bug fix slipped through the cracks during the 7.0 build.
TC> It should be corrected in the next sp update for 7.0. I don't know which sp
TC> version of 6.x has this fix.
TC> I have searched for the CR(?) number which BEA once provided me but have not
TC> been able to find it.
TC> If you're really interested, you may want to do a search at BEA's site for
TC> something like "multiple dots in jars"
TC> david
TC> -----Original Message-----
TC> From: Edward Q. Bridges [mailto:ebridges@teachscape.com]
TC> Sent: Wednesday, June 19, 2002 1:44 PM
TC> To: Log4J Users List; Steve.Lewis@ctimi.com
TC> Cc: Ceki Gülcü
TC> Subject: Re: Strange weblogic problem with new jarfile name (WAS: Why is
TC> the version number included in the log4j jar file name?)
TC> i deleted the .wlnotdelete, and the directories that weblogic created under
TC> WEB-
TC> INF in the exploded war (and other directories & files).
TC> yes of course, unjarring the log4j would work. typically, however,
TC> unjarring a
TC> jar file is not a practical solution.
TC> further, that's not really the issue. the issue is that the *name* of the
TC> jar
TC> file is the problem. it works fine when the jar file is named log4j.jar,
TC> but
TC> not when it's named log4j-1.2.4.jar.
TC> and, of course, this is not a log4j problem per se, but a weblogic problem.
TC> i
TC> posted it here because of the relevance to recent discussion, and in cases
TC> omeone had come across the problem before.
TC> thanks!
TC> --e--
TC> On Wed, 19 Jun 2002 12:32:03 -0400, Steve.Lewis@ctimi.com wrote:
>>
>> Unfortunately, WebLogic sometimes gets confused and you have to delete
TC> temp
>> directories or occasionally even .wlnotdelete directories and restart to
>> set things straight. I just put log4j on my system classpath, although I
>> had something similar to yours and I just unjarred log4j and WebLogic was
>> able to see everything in classes/org/apache/log4j/etc.
>>
>> Steve
>>
>>
>>
>>
>>
>> |---------+---------------------------->
>> | | "Edward Q. |
>> | | Bridges" |
>> | | <ebridges@teachsc|
>> | | ape.com> |
>> | | |
>> | | 06/19/2002 12:35 |
>> | | PM |
>> | | Please respond to|
>> | | "Log4J Users |
>> | | List" |
>> | | |
>> |---------+---------------------------->
>>
>>---------------------------------------------------------------------------
TC> -----------------------------------|
>> |
TC> |
>> | To: "Ceki Gülcü" <ce...@qos.ch>, "Log4J Users List" <log4j-
TC> user@jakarta.apache.org> |
>> | cc:
TC> |
>> | Subject: Re: Strange weblogic problem with new jarfile name
TC> (WAS:
TC> Why is the version number included |
>> | in the log4j jar file name?)
TC> |
>>
>>---------------------------------------------------------------------------
TC> -----------------------------------|
>>
>>
>>
>>
>>
>> i will test, but be assured that this came after several hours yesterday
>> late
>> afternoon and this morning of mine and another fellow's time -- most of it
>> waiting on weblogic restarts :)
>>
>> this was also successfully reproduced on two different installations (our
>> individual development instances and on our central staging/testing
>> instance --
>> which is clustered).
>>
>> this was also reproduced in deploys using exploded war-files and intact
>> war-
>> files.
>>
>> i'd be more than happy to try other approaches at your (or anyone else's)
>> suggestion.
>>
>> best regards
>> --e--
>>
>>
>>
>> On Wed, 19 Jun 2002 18:29:57 +0200, Ceki Gülcü wrote:
>>
>> > Edward,
>> >
>> > I personally tested the alpha and beta versions of log4j (but not 1.2
>> > final and later versions) under WL 6.1. So I find your discovery quite
>> > surprising. Can you please double check? I suggest that you remove the
>> > tmp directory and restart WL. Let us know if the problem persists.
>> >
>> > At 12:14 19.06.2002 -0400, Edward Q. Bridges wrote:
>> > >we just upgraded log4j to the 1.2.4 jar.
>> > >
>> > >we encountered a very very strange problem (using Weblogic 6.1), that
>> > >seems to be
>> > >directly related to having the version number in the filename of the
>> jar.
>> > >
>> > >weblogic would fail upon access to a servlet that depended on log4j
>> > >(basically every
>> > >servlet, since they all inherit from a class that contains an instance
>> of
>> > >Logger (used to
>> > >be Category)).
>> > >
>> > >it would fail because it couldn't find the class, and yet, the
>> > >log4j-1.2.4.jar file was
>> > >in WEB-INF/lib
>> > >
>> > >upon closer examination, weblogic copies the jar files that a web-app
TC> is
>>
>> > >dependent on
>> > >into its own special directory within WEB_INF, and mangles the names.
>> to
>> > >illustrate,
>> > >here is the (edited) output of a find command in our deploy directory
>> (our
>> > >web-app is
>> > >named "ts2"):
>> > >
>> > >bash-2.03$ find . -name '*.jar'
>> > >.
>> > >.
>> > >./ts2/WEB-INF/lib/log4j.jar
>> > >.
>> > >.
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/log4j59854.jar
>> > >.
>> > >.
>> > >
>> > >note that log4j.jar is mangled into log4j59854.jar.
>> > >
>> > >now, after renaming log4j.jar to log4j.1.2.4.jar and clearing out the
>> > >deploy directory
>> > >and redeploying the web-application, this is what it looks like:
>> > >.
>> > >.
>> > >./ts2/WEB-INF/lib/log4j-1.2.4.jar
>> > >.
>> > >.
>> > >.
>> > >(all jars in the weblogic directory displayed):
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/startup59860.jar
>> >
>>
>>./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/jaxen-full59861.jar
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/jdom59862.jar
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/commons-
>> beanutils59863.jar
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/soap59864.jar
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/commons-
>> collections59865.jar
>> > >./ts2/WEB-INF/_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/saxpath59866.jar
>> > >
>> > >note, that log4j-1.2.4.jar is now ignored, and i cannot execute a web
>> > >application.
>> > >
>> > >now, i recognize that this is, in fact, a weblogic error and not a
TC> log4j
>>
>> > >error. but, i
>> > >mention it here because of the recent discussion regarding the name
>> > >change, in case
>> > >anyone might come across a similar issue. has anyone else encountered
>> this?
>> > >
>> > >best regards
>> > >--e--
>> > >
>> > >
>> > >
>> > >--
>> > >Edward Q. Bridges
>> > >http://www.teachscape.com
>> >
>> > --
>> > Ceki
>> >
>> >
>> > --
>> > To unsubscribe, e-mail: <
>> mailto:log4j-user-unsubscribe@jakarta.apache.org>
>> > For additional commands, e-mail: <
>> mailto:log4j-user-help@jakarta.apache.org>
>> >
>>
>>
>> --
>> Edward Q. Bridges
>> http://www.teachscape.com
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
TC> <mailto:log4j-user-unsubscribe@jakarta.apache.org
>> >
>> For additional commands, e-mail:
TC> <mailto:log4j-user-help@jakarta.apache.org
>> >
>>
>>
>>
>>
>> --
>> >
TC> NOTICE: This e-mail message and all attachments transmitted with it may>
TC> contain legally privileged and confidential information intended solely >
TC> for the use of the addressee. If the reader of this message is not the >
TC> intended recipient, you are hereby notified that any reading, >
TC> dissemination, distribution, copying, or other use of this message or >
TC> its attachments, hyperlinks, or any other files of any kind is strictly >
TC> prohibited. If you have received this message in error, please notify >
TC> the sender immediately by telephone (865-218-2000) or by a reply to this>
TC> electronic mail message and delete this message and all copies and >
TC> backups thereof. >
TC> >
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
TC> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
TC> <ma...@jakarta.apache.org>
>>
TC> --
TC> Edward Q. Bridges
TC> http://www.teachscape.com
TC> --
TC> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TC> For additional commands, e-mail: <ma...@jakarta.apache.org>
TC> **********************************************************************
TC> This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please
TC> contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it,
TC> is strictly prohibited.
TC> TIAA-CREF
TC> **********************************************************************
TC> --
TC> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TC> For additional commands, e-mail: <ma...@jakarta.apache.org>
TC> --
TC> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TC> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Jacob mailto:hoju@visi.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>