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 John Ferron <jo...@alliantenergy.com> on 2005/04/06 19:04:26 UTC
Alpha 6 release
Is there something wrong with how the zip is built or am I setting up
incorrectly? I downloaded the latest release of the Junit 1.3 alpha 6
release and when I looked for the DBAppender class file, it was no where
to be found. Do I have to import the project and re-build the project?
Please advise in setting this up.
John
Re: Alpha 6 release
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 05:15 PM 4/8/2005, Jacob Kjome wrote:
> >Quoting James Stauffer <st...@gmail.com>:
> >
> > > How would log4j-all.jar have classloader problems? Would it have
> > > something in it besides log4j code?
> > >
> >
> >I think Ceki is referring to the case where, let's say we have
> >log4j-all.jar in
> >CATALINA_HOME/common/lib and somejdbcdriver.jar in WEB-INF/lib. Using the
> >DBAppender, we'd get ClassNotFoundException or NoClassDefFoundError for the
> >JDBC stuff. Then again, if we put log4j.jar in CATALINA_HOME/common/lib and
> >log4j-db.jar in WEB-INF/lib alongside somejdbcdriver.jar, how would Log4j
> find
> >the DBAppender itself? Instantiate it via the thread context classloader?
> I
> >suppose that's doable. Ceki, is that what we're doing? I'm at work and
> can't
> >look at the code ATM.
>
> That's exactly what we are doing. Not only is it doable, that is how it is
> *done* in log4j 1.2 (and 1.3 as well). The main difference is that in 1.3
> log4j.jar is split according to dependency which subsequently allows the
> scenario you describe, which is backed up by test cases (cactus).
>
> >I'm probably forgetting something here, but I'm not sure I agree that
> separate
> >jars are all that useful other than decreasing the size of log4j.jar in the
> >case where one doesn't need all the extra optional stuff.
>
> You don't mean to discard the scenario you just described in the previous
> paragraph, do you?
>
Well, actually, yes. For instance, if I am going to use a connection pool, I'll
be using a container managed one. In that case, I must have the JDBC driver at
the system or server level, not the webapp level. Having a separate
log4j-db.jar doesn't help me at all in this case. In fact, it makes it
annoying because I have yet another jar to add to the server classpath. I'd
rather just have a log4j-all.jar and be done with it. This also applies to
JMS, JMX, and other types of stuff which is container managed, as well as XML
stuff since XML parsers are generally system wide, not webapp specific. Those
dependencies must be at the server level anyway, so why clutter things up with
separate jars?
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:15 PM 4/8/2005, Jacob Kjome wrote:
>Quoting James Stauffer <st...@gmail.com>:
>
> > How would log4j-all.jar have classloader problems? Would it have
> > something in it besides log4j code?
> >
>
>I think Ceki is referring to the case where, let's say we have
>log4j-all.jar in
>CATALINA_HOME/common/lib and somejdbcdriver.jar in WEB-INF/lib. Using the
>DBAppender, we'd get ClassNotFoundException or NoClassDefFoundError for the
>JDBC stuff. Then again, if we put log4j.jar in CATALINA_HOME/common/lib and
>log4j-db.jar in WEB-INF/lib alongside somejdbcdriver.jar, how would Log4j find
>the DBAppender itself? Instantiate it via the thread context classloader? I
>suppose that's doable. Ceki, is that what we're doing? I'm at work and can't
>look at the code ATM.
That's exactly what we are doing. Not only is it doable, that is how it is
*done* in log4j 1.2 (and 1.3 as well). The main difference is that in 1.3
log4j.jar is split according to dependency which subsequently allows the
scenario you describe, which is backed up by test cases (cactus).
>I'm probably forgetting something here, but I'm not sure I agree that separate
>jars are all that useful other than decreasing the size of log4j.jar in the
>case where one doesn't need all the extra optional stuff.
You don't mean to discard the scenario you just described in the previous
paragraph, do you?
>Jake
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by Jacob Kjome <ho...@visi.com>.
Quoting James Stauffer <st...@gmail.com>:
> How would log4j-all.jar have classloader problems? Would it have
> something in it besides log4j code?
>
I think Ceki is referring to the case where, let's say we have log4j-all.jar in
CATALINA_HOME/common/lib and somejdbcdriver.jar in WEB-INF/lib. Using the
DBAppender, we'd get ClassNotFoundException or NoClassDefFoundError for the
JDBC stuff. Then again, if we put log4j.jar in CATALINA_HOME/common/lib and
log4j-db.jar in WEB-INF/lib alongside somejdbcdriver.jar, how would Log4j find
the DBAppender itself? Instantiate it via the thread context classloader? I
suppose that's doable. Ceki, is that what we're doing? I'm at work and can't
look at the code ATM.
I'm probably forgetting something here, but I'm not sure I agree that separate
jars are all that useful other than decreasing the size of log4j.jar in the
case where one doesn't need all the extra optional stuff.
Jake
> On Apr 7, 2005 9:39 AM, Ceki Gülcü <ce...@qos.ch> wrote:
> > At 03:09 AM 4/7/2005, Jacob Kjome wrote:
> > >At 10:37 AM 4/7/2005 +1000, you wrote:
> > > >The build system now builds core, and optional jars. If you don't setup
> > > >your build.properties correctly, the build system will detect it does
> > > >not have enough of the dependencies to build the other optional jars,
> > > >which is where the DBAppender will sit.
> > > >
> > >
> > >Paul,
> > >
> > >I think he's saying that the official download from logging.apache.org is
> > >missing the dbappender. What I think he missed was the log4j-db.jar. The
> > >optional stuff has been slplit out to separate jar files. I still think
> > >we should have a log4j-all.jar for those who want to deal with a single
> > >jar file with all that log4j has to offer.
> >
> > While a log4j-all.jar file would yield certain immediate benefits, e.g.
> > simplification, it would also open the possibility for class loader
> > problems in app servers. Keep in mind that log4j.jar was split into several
> > parts for technical reasons. It wasn't done with an aim to make life
> > difficult for our users. Honest. :-)
> >
> > Do we want to trade immediate comfort to our users with long term usability
> > of our product in real-world situations? Does John Ferron prefer to face a
> > missing class problem (missing log4j-db.jar file) or incompatible class
> > version problem (JCL+Tomcat+log4j+DBAppender combination)?
> >
> > With the split jar approach we can offer a deployment recipe which stable
> > under a wide range of conditions whereas the single jar solution is stable
> > only in simple (trivial?) cases. Admittedly, it's a fine point which is
> > neither immediately obvious nor convincing.
> >
> > >Jake
> >
> > --
> > Ceki Gülcü
> >
> > The complete log4j manual: http://www.qos.ch/log4j/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
> --
> James Stauffer
> Are you good? Take the test at http://www.livingwaters.com/good/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by James Stauffer <st...@gmail.com>.
How would log4j-all.jar have classloader problems? Would it have
something in it besides log4j code?
On Apr 7, 2005 9:39 AM, Ceki Gülcü <ce...@qos.ch> wrote:
> At 03:09 AM 4/7/2005, Jacob Kjome wrote:
> >At 10:37 AM 4/7/2005 +1000, you wrote:
> > >The build system now builds core, and optional jars. If you don't setup
> > >your build.properties correctly, the build system will detect it does
> > >not have enough of the dependencies to build the other optional jars,
> > >which is where the DBAppender will sit.
> > >
> >
> >Paul,
> >
> >I think he's saying that the official download from logging.apache.org is
> >missing the dbappender. What I think he missed was the log4j-db.jar. The
> >optional stuff has been slplit out to separate jar files. I still think
> >we should have a log4j-all.jar for those who want to deal with a single
> >jar file with all that log4j has to offer.
>
> While a log4j-all.jar file would yield certain immediate benefits, e.g.
> simplification, it would also open the possibility for class loader
> problems in app servers. Keep in mind that log4j.jar was split into several
> parts for technical reasons. It wasn't done with an aim to make life
> difficult for our users. Honest. :-)
>
> Do we want to trade immediate comfort to our users with long term usability
> of our product in real-world situations? Does John Ferron prefer to face a
> missing class problem (missing log4j-db.jar file) or incompatible class
> version problem (JCL+Tomcat+log4j+DBAppender combination)?
>
> With the split jar approach we can offer a deployment recipe which stable
> under a wide range of conditions whereas the single jar solution is stable
> only in simple (trivial?) cases. Admittedly, it's a fine point which is
> neither immediately obvious nor convincing.
>
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
James Stauffer
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by Ceki Gülcü <ce...@qos.ch>.
At 03:09 AM 4/7/2005, Jacob Kjome wrote:
>At 10:37 AM 4/7/2005 +1000, you wrote:
> >The build system now builds core, and optional jars. If you don't setup
> >your build.properties correctly, the build system will detect it does
> >not have enough of the dependencies to build the other optional jars,
> >which is where the DBAppender will sit.
> >
>
>Paul,
>
>I think he's saying that the official download from logging.apache.org is
>missing the dbappender. What I think he missed was the log4j-db.jar. The
>optional stuff has been slplit out to separate jar files. I still think
>we should have a log4j-all.jar for those who want to deal with a single
>jar file with all that log4j has to offer.
While a log4j-all.jar file would yield certain immediate benefits, e.g.
simplification, it would also open the possibility for class loader
problems in app servers. Keep in mind that log4j.jar was split into several
parts for technical reasons. It wasn't done with an aim to make life
difficult for our users. Honest. :-)
Do we want to trade immediate comfort to our users with long term usability
of our product in real-world situations? Does John Ferron prefer to face a
missing class problem (missing log4j-db.jar file) or incompatible class
version problem (JCL+Tomcat+log4j+DBAppender combination)?
With the split jar approach we can offer a deployment recipe which stable
under a wide range of conditions whereas the single jar solution is stable
only in simple (trivial?) cases. Admittedly, it's a fine point which is
neither immediately obvious nor convincing.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by Jacob Kjome <ho...@visi.com>.
At 10:37 AM 4/7/2005 +1000, you wrote:
>The build system now builds core, and optional jars. If you don't setup
>your build.properties correctly, the build system will detect it does
>not have enough of the dependencies to build the other optional jars,
>which is where the DBAppender will sit.
>
Paul,
I think he's saying that the official download from logging.apache.org is
missing the dbappender. What I think he missed was the log4j-db.jar. The
optional stuff has been slplit out to separate jar files. I still think we
should have a log4j-all.jar for those who want to deal with a single jar
file with all that log4j has to offer.
Jake
>cheers,
>
>Paul
>
>John Ferron wrote:
>
>>Is there something wrong with how the zip is built or am I setting up
>>incorrectly? I downloaded the latest release of the Junit 1.3 alpha 6
>>release and when I looked for the DBAppender class file, it was no where
>>to be found. Do I have to import the project and re-build the project?
>>Please advise in setting this up.
>>
>>John
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Alpha 6 release
Posted by Paul Smith <ps...@aconex.com>.
The build system now builds core, and optional jars. If you don't setup
your build.properties correctly, the build system will detect it does
not have enough of the dependencies to build the other optional jars,
which is where the DBAppender will sit.
cheers,
Paul
John Ferron wrote:
>Is there something wrong with how the zip is built or am I setting up
>incorrectly? I downloaded the latest release of the Junit 1.3 alpha 6
>release and when I looked for the DBAppender class file, it was no where
>to be found. Do I have to import the project and re-build the project?
>Please advise in setting this up.
>
>John
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org