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 Tom Caulkins <To...@sas.com> on 2002/06/19 21:44:43 UTC
Request to drop version number from log4j jar file name ( WAS: St
range weblogic problem with new jarfile name )
To bring the discussion back to my original request... ;->
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 a deficiency in the BEA code.
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 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 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?
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:
* 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.
* 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 version of classes will be found.
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 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 we've seen here ;-> ).
So please post a decision to this request.
Thanks,
Tom
------------------------------------------
Tom Caulkins
Senior Systems Developer
Platform Services - Business Intelligence Platform
SAS Institute Inc.
Tom.Caulkins@sas.com
-----Original Message-----
From: Lu, David [mailto:dlu@tiaa-cref.org]
Sent: Wednesday, June 19, 2002 1:52 PM
To: 'Log4J Users List'
Subject: RE: Strange weblogic problem with new jarfile name (WAS: Why is
the version number included in the log4j jar file name?)
We have experienced the same problem with not only the log4j jar but any
other jar that has a "dot" (other than the one preceding the jar suffix) in
its filename. We experienced this problem in WebLogic 7.0 with jars like
castor-0.9.3.9-xml.jar and jakarta-regexp-1.2.jar.
BEA told us that this problem was a corrected known problem in 6.x but that
this bug fix slipped through the cracks during the 7.0 build.
It should be corrected in the next sp update for 7.0. I don't know which sp
version of 6.x has this fix.
I have searched for the CR(?) number which BEA once provided me but have not
been able to find it.
If you're really interested, you may want to do a search at BEA's site for
something like "multiple dots in jars"
david
-----Original Message-----
From: Edward Q. Bridges [mailto:ebridges@teachscape.com]
Sent: Wednesday, June 19, 2002 1:44 PM
To: Log4J Users List; Steve.Lewis@ctimi.com
Cc: Ceki Gülcü
Subject: Re: Strange weblogic problem with new jarfile name (WAS: Why is
the version number included in the log4j jar file name?)
i deleted the .wlnotdelete, and the directories that weblogic created under
WEB-
INF in the exploded war (and other directories & files).
yes of course, unjarring the log4j would work. typically, however,
unjarring a
jar file is not a practical solution.
further, that's not really the issue. the issue is that the *name* of the
jar
file is the problem. it works fine when the jar file is named log4j.jar,
but
not when it's named log4j-1.2.4.jar.
and, of course, this is not a log4j problem per se, but a weblogic problem.
i
posted it here because of the relevance to recent discussion, and in cases
omeone had come across the problem before.
thanks!
--e--
On Wed, 19 Jun 2002 12:32:03 -0400, Steve.Lewis@ctimi.com wrote:
>
> Unfortunately, WebLogic sometimes gets confused and you have to delete
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" |
> | | |
> |---------+---------------------------->
>
>---------------------------------------------------------------------------
-----------------------------------|
> |
|
> | To: "Ceki Gülcü" <ce...@qos.ch>, "Log4J Users List" <log4j-
user@jakarta.apache.org> |
> | cc:
|
> | Subject: Re: Strange weblogic problem with new jarfile name
(WAS:
Why is the version number included |
> | in the log4j jar file name?)
|
>
>---------------------------------------------------------------------------
-----------------------------------|
>
>
>
>
>
> 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
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
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:
<mailto:log4j-user-unsubscribe@jakarta.apache.org
> >
> For additional commands, e-mail:
<mailto:log4j-user-help@jakarta.apache.org
> >
>
>
>
>
> --
> >
NOTICE: This e-mail message and all attachments transmitted with it may>
contain legally privileged and confidential information intended solely >
for the use of the addressee. If the reader of this message is not the >
intended recipient, you are hereby notified that any reading, >
dissemination, distribution, copying, or other use of this message or >
its attachments, hyperlinks, or any other files of any kind is strictly >
prohibited. If you have received this message in error, please notify >
the sender immediately by telephone (865-218-2000) or by a reply to this>
electronic mail message and delete this message and all copies and >
backups thereof. >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
Edward Q. Bridges
http://www.teachscape.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
**********************************************************************
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 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, is strictly prohibited.
TIAA-CREF
**********************************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request to drop version number from log4j jar file name ( WAS: St range weblogic problem with new jarfile name )
Posted by Jacob Kjome <ho...@visi.com>.
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>
Re: Request to drop version number from log4j jar file name ( WAS: Strange weblogic problem with new jarfile name )
Posted by "Edward Q. Bridges" <eb...@teachscape.com>.
even though we ran into the problems i described here, i would have to say that
i remain committed to the idea that version numbers in jar file names is a good
idea.
the issues you describe and that we encountered are problems in the use of the
jar file that can be addressed by individual means (renaming the file to not
have numbers, using symlinks, etc., etc.).
the benefits of having versioned jarfiles, for my purposes, far outweighs not
having them versioned.
+1 versioned jars
On Wed, 19 Jun 2002 15:44:43 -0400, Tom Caulkins wrote:
> To bring the discussion back to my original request... ;->
>
> 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 a deficiency in the BEA code.
>
> 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 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
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?
>
> 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:
>
> * 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.
>
> * 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 version of classes will be found.
>
> 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 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
we've seen here ;-> ).
>
> So please post a decision to this request.
>
> Thanks,
> Tom
>
> ------------------------------------------
>
> Tom Caulkins
> Senior Systems Developer
> Platform Services - Business Intelligence Platform
> SAS Institute Inc.
> Tom.Caulkins@sas.com
>
>
> -----Original Message-----
> From: Lu, David [mailto:dlu@tiaa-cref.org]
> Sent: Wednesday, June 19, 2002 1:52 PM
> To: 'Log4J Users List'
> Subject: RE: Strange weblogic problem with new jarfile name (WAS: Why is
> the version number included in the log4j jar file name?)
>
>
> We have experienced the same problem with not only the log4j jar but any
> other jar that has a "dot" (other than the one preceding the jar suffix) in
> its filename. We experienced this problem in WebLogic 7.0 with jars like
> castor-0.9.3.9-xml.jar and jakarta-regexp-1.2.jar.
>
> BEA told us that this problem was a corrected known problem in 6.x but that
> this bug fix slipped through the cracks during the 7.0 build.
> It should be corrected in the next sp update for 7.0. I don't know which sp
> version of 6.x has this fix.
>
> I have searched for the CR(?) number which BEA once provided me but have not
> been able to find it.
>
> If you're really interested, you may want to do a search at BEA's site for
> something like "multiple dots in jars"
>
> david
>
> -----Original Message-----
> From: Edward Q. Bridges [mailto:ebridges@teachscape.com]
> Sent: Wednesday, June 19, 2002 1:44 PM
> To: Log4J Users List; Steve.Lewis@ctimi.com
> Cc: Ceki Gülcü
> Subject: Re: Strange weblogic problem with new jarfile name (WAS: Why is
> the version number included in the log4j jar file name?)
>
>
>
> i deleted the .wlnotdelete, and the directories that weblogic created under
> WEB-
> INF in the exploded war (and other directories & files).
>
> yes of course, unjarring the log4j would work. typically, however,
> unjarring a
> jar file is not a practical solution.
>
> further, that's not really the issue. the issue is that the *name* of the
> jar
> file is the problem. it works fine when the jar file is named log4j.jar,
> but
> not when it's named log4j-1.2.4.jar.
>
> and, of course, this is not a log4j problem per se, but a weblogic problem.
> i
> posted it here because of the relevance to recent discussion, and in cases
> omeone had come across the problem before.
>
> thanks!
> --e--
>
>
>
> On Wed, 19 Jun 2002 12:32:03 -0400, Steve.Lewis@ctimi.com wrote:
>
> >
> > Unfortunately, WebLogic sometimes gets confused and you have to delete
> 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" |
> > | | |
> > |---------+---------------------------->
> >
> >---------------------------------------------------------------------------
> -----------------------------------|
> > |
>
> |
> > | To: "Ceki Gülcü" <ce...@qos.ch>, "Log4J Users List" <log4j-
> user@jakarta.apache.org> |
> > | cc:
>
> |
> > | Subject: Re: Strange weblogic problem with new jarfile name
> (WAS:
> Why is the version number included |
> > | in the log4j jar file name?)
>
> |
> >
> >---------------------------------------------------------------------------
> -----------------------------------|
> >
> >
> >
> >
> >
> > 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
> 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
> 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:
> <mailto:log4j-user-unsubscribe@jakarta.apache.org
> > >
> > For additional commands, e-mail:
> <mailto:log4j-user-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> > --
> > >
> NOTICE: This e-mail message and all attachments transmitted with it may>
> contain legally privileged and confidential information intended solely >
> for the use of the addressee. If the reader of this message is not the >
> intended recipient, you are hereby notified that any reading, >
> dissemination, distribution, copying, or other use of this message or >
> its attachments, hyperlinks, or any other files of any kind is strictly >
> prohibited. If you have received this message in error, please notify >
> the sender immediately by telephone (865-218-2000) or by a reply to this>
> electronic mail message and delete this message and all copies and >
> backups thereof. >
> >
>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> Edward Q. Bridges
> http://www.teachscape.com
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> **********************************************************************
> 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 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, is strictly prohibited.
> TIAA-CREF
> **********************************************************************
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Edward Q. Bridges
http://www.teachscape.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>