You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2005/10/07 11:16:13 UTC
[logging] new release?
Hi All,
A week or so ago I was prompted by new activity on the logging topic to
review what is currently sitting in SVN. I think it's actually quite
good, and perhaps we could try to push for a release.
The issues I'm aware of are:
* Do we include the ServletContextListener stuff or not? And if we do,
do we put it in an "optional" jar or in the main jar?
Personally, I would like to include it, and put it in the main jar.
It does no harm being there, as no logging classes reference it. It
only gets used if someone explicitly references it from a web.xml
file.
There have been objections about adding "dependencies", but JCL is
a project that already has heaps of compile-time dependencies that
aren't actually runtime dependencies, eg LogKit is a compile-time
dependency too, but isn't needed to run.
* Do we include the WeakHashtable stuff or not? And if so, do we
put it in an "optional" jar or in the main jar. On the positive
side, it will fix memory leaks for many people. And on JDKs that
don't support weak references JCL politely falls back to a standard
hashtable. On the negative side it isn't a 100% fix; it won't work
if the LogFactoryImpl is loaded from a parent loader but the log
adapter class is loaded from the webapp. This isn't a common
situation, but a partial fix can be confusing. And the
ServletContextListener should be a 100% fix. The other concern is
that it is a lot of new - and quite tricky - code.
I can't make up my mind on this. I'm tempted to put it in an optional
jar. However if we put it in the main jar, then (a) we don't need to
document its use so much, and (b) we could do away with the optional
jar completely which would be nice.
* There's a proposal to add a system property to disable all TCCL use.
It's worth considering.
* There's a proposal to add "get logger name" functionality.
* We still don't handle "cross-application" calls. Apparently by using
JCA or similar one component can get a reference to an object in
another container and make a call to it. In that case, there is
absolutely no way the existing code can load a log adapter class from
the contextClassLoader and cast it to a Log implementation.
Currently, we walk the classloader ancestry chain looking for which
loader is a child of which, and find they aren't related so panic.
Perhaps we could just fall back to using diagnostic logging to output
a message, then assign a NoOp logger?
* How do we handle Log4J 1.2->1.3 stuff? Some people have offered to
investigate whether a single class can handle both versions. If that
doesn't work out, then what? Currently, SVN has *removed* the
Log4JLogger class, and added Log4J12Logger/Log4J13Logger. My reasons
are documented in a recent email to this list (or was it the user
list?). It's obviously up for debate though.
And do we want to offer 1.3 support, given that 1.3 is still alpha?
I would prefer not to; better to provide a minor release after
log4j 1.3 is released than provide ahead-of-time support and get
it wrong. Actually, for the current release we could provide a
Log4JLogger class with TRACE support, and worry about splitting
into log4j1.2/1.3 when the new version comes along. I would still
like to see the version-checking stuff in the Log4J12Logger class
kept, though.
Anything else??
Note that I'm still very short of time at the moment. I'd really like to
see a new JCL release, but can't promise to contribute much towards it
at the moment.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] new release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 18:49 +1300, Simon Kitching wrote:
> On Fri, 2005-10-07 at 09:24 +0000, Henning P. Schmiedehausen wrote:
> > Simon Kitching <sk...@apache.org> writes:
> >
> > > And do we want to offer 1.3 support, given that 1.3 is still alpha?
> > > I would prefer not to; better to provide a minor release after
> > > log4j 1.3 is released than provide ahead-of-time support and get
> > > it wrong. Actually, for the current release we could provide a
> > > Log4JLogger class with TRACE support, and worry about splitting
> > > into log4j1.2/1.3 when the new version comes along. I would still
> > > like to see the version-checking stuff in the Log4J12Logger class
> > > kept, though.
> >
> > The long stretches of inactivity at JCL would suggest that we better
> > put some support in there now or we might have a situation where 1.3
> > is out and JCL has no support for it for quite a while.
>
> The reason for the long stretches of inactivity is that the issues
> currently existing in JCL are *hard* to fix, and JCL was severely
> under-documented.
>
> However handling something like the log4j 1.2 -> 1.3 change is pretty
> easy. I wouldn't expect much delay getting a new release out to handle
> log4j 1.3.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] new release?
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2005-10-07 at 09:24 +0000, Henning P. Schmiedehausen wrote:
> Simon Kitching <sk...@apache.org> writes:
>
> > And do we want to offer 1.3 support, given that 1.3 is still alpha?
> > I would prefer not to; better to provide a minor release after
> > log4j 1.3 is released than provide ahead-of-time support and get
> > it wrong. Actually, for the current release we could provide a
> > Log4JLogger class with TRACE support, and worry about splitting
> > into log4j1.2/1.3 when the new version comes along. I would still
> > like to see the version-checking stuff in the Log4J12Logger class
> > kept, though.
>
> The long stretches of inactivity at JCL would suggest that we better
> put some support in there now or we might have a situation where 1.3
> is out and JCL has no support for it for quite a while.
The reason for the long stretches of inactivity is that the issues
currently existing in JCL are *hard* to fix, and JCL was severely
under-documented.
However handling something like the log4j 1.2 -> 1.3 change is pretty
easy. I wouldn't expect much delay getting a new release out to handle
log4j 1.3.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] new release?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Simon Kitching <sk...@apache.org> writes:
> And do we want to offer 1.3 support, given that 1.3 is still alpha?
> I would prefer not to; better to provide a minor release after
> log4j 1.3 is released than provide ahead-of-time support and get
> it wrong. Actually, for the current release we could provide a
> Log4JLogger class with TRACE support, and worry about splitting
> into log4j1.2/1.3 when the new version comes along. I would still
> like to see the version-checking stuff in the Log4J12Logger class
> kept, though.
The long stretches of inactivity at JCL would suggest that we better
put some support in there now or we might have a situation where 1.3
is out and JCL has no support for it for quite a while.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
robert burrell donkin <ro...@blueyonder.co.uk> writes:
>> There have been objections about adding "dependencies", but JCL is
>> a project that already has heaps of compile-time dependencies that
>> aren't actually runtime dependencies, eg LogKit is a compile-time
>> dependency too, but isn't needed to run.
>i think that there are a lot of different issues here which could do
>with being untangled. i'll make a stab at outlined the different ones i
>see (possibly with a few to documenting later). please feel free to kick
>off discussion (i've refrained from presenting solutions) and add any
>i've missed.
>downstream maintainers
>----------------------
>my major concern was about the impact of JCL dependencies on downstream
>maintainers (rather than users). this include the gump infrastructure
>and packagers such as debian. JCL is now a really basic component right
>at the bottom of the java package tree.
I think the problem is the perception of "compile time dependencies"
and "run time dependencies" here.
Our current build tool (maven) is not able to distinguish between
compile-time and run-time dependencies. And some packagers don't
understand this and start to require all of the compile time
dependencies also at runtime.
>in the best case scenario, more dependencies mean that maintainers have
>more work to do. in the worst case scenario, maintainers will be forced
>to remove JCL and all packages that depend upon it from their
>distribution. for example, debian will only ship java libraries that
>will run on a free JVM. so, the impact of adding an innocuous dependency
That is a political decision of debian (and e.g. Fedora) to do
so. They won't be able to ship a large number of packages anyway
(e.g. everything that requires Sun libs until either GlassFish or
Geronimo come along far enough to allow the usage of things like mail
or activation).
The question for this scenario is: Do we want to cater to the needs of
"truly free software" (as in GNU) or do we want to continue down the
road of "truly free software" (as in ASF). :-)
>may be that downstream maintainers are forced to remove scores or
>hundreds or packages from their distributions.
No matter what decision we make, there is someone is bound to stand up
and whine. So IMHO we should just continue as it is comfortable to the
JCL community and let the rest sort out the political details.
>perceived dependencies
>----------------------
>a different concern is that users are given the wrong impression of the
>libraries which are required to run JCL. this includes users who feel
>they need to find and download sources for all dependencies and those
>who need to distribution and run a minimal stripped down version. what
>classes and dependencies are required is a FAQ.
+1 I hope that m2 will help us along here in being able to clearly
specify build and runtime dependencies.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
Niall Pemberton wrote:
> You need verson 1.9.2 of the maven-xdoc-plugin to get it to generate the
> comments (it was introduced in version 1.9.0, but doesn't work in 1.9.1).
>
> Validator uses this feature and it works well:
>
> http://jakarta.apache.org/commons/validator/dependencies.html
>
> Hopefully maven 2 will be better though - it has "scopes" for depenencies
> which hopefully it uses to create a better dependency report (I haven't
> tried it yet)
You can classify your dependencies (test, compile-time, run-time).
A very important feature that is missing in maven1.
Most (all?) things that where bad in maven1 have changed in m2.
I tried m2 and it is really cool. But the site-generation stuff etc. is not
far enough to make it worth to migrate yet. But it will rock!
>
> http://maven.apache.org/maven2/dependency-mechanism.html#dependency_scope
>
> Niall
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDTC3ZmPuec2Dcv/8RAm7CAJwOzDDiCg+DamA7V9sTCbkFV7AoxgCfX5Ls
ybOQKb4BbjIJwj5dnL5/a8U=
=efRo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
You need verson 1.9.2 of the maven-xdoc-plugin to get it to generate the
comments (it was introduced in version 1.9.0, but doesn't work in 1.9.1).
Validator uses this feature and it works well:
http://jakarta.apache.org/commons/validator/dependencies.html
Hopefully maven 2 will be better though - it has "scopes" for depenencies
which hopefully it uses to create a better dependency report (I haven't
tried it yet)
http://maven.apache.org/maven2/dependency-mechanism.html#dependency_scope
Niall
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > > (logging uses ant for builds but) i agree that this is a major issue
for
> > > all projects that use maven. JCL uses maven to generate the
> > > documentation which is misleading.
> > >
> > > does anyone know how to add comments for dependencies?
> >
> > For Maven 1 it could be solved by setting properties [1] on the
> > dependency. This would be something local to commons-logging that would
> > not work automatically in other places.
> >
> > [1]
> >
http://maven.apache.org/reference/project-descriptor.html#class_Dependency
>
> thanks :)
>
> helped me to track down what i was looking for:
>
> <properties>
> <comment>XXX</comment>
> </properties>
>
> can be used to add comments which appear in the dependency report.
>
> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 18:27 +0200, Dennis Lundberg wrote:
> robert burrell donkin wrote:
> > On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
> >
> >>Our current build tool (maven) is not able to distinguish between
> >>compile-time and run-time dependencies. And some packagers don't
> >>understand this and start to require all of the compile time
> >>dependencies also at runtime.
> >
> >
> > (logging uses ant for builds but) i agree that this is a major issue for
> > all projects that use maven. JCL uses maven to generate the
> > documentation which is misleading.
> >
> > does anyone know how to add comments for dependencies?
>
> For Maven 1 it could be solved by setting properties [1] on the
> dependency. This would be something local to commons-logging that would
> not work automatically in other places.
>
> [1]
> http://maven.apache.org/reference/project-descriptor.html#class_Dependency
thanks :)
helped me to track down what i was looking for:
<properties>
<comment>XXX</comment>
</properties>
can be used to add comments which appear in the dependency report.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by Dennis Lundberg <de...@mdh.se>.
robert burrell donkin wrote:
> On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
>
>>Our current build tool (maven) is not able to distinguish between
>>compile-time and run-time dependencies. And some packagers don't
>>understand this and start to require all of the compile time
>>dependencies also at runtime.
>
>
> (logging uses ant for builds but) i agree that this is a major issue for
> all projects that use maven. JCL uses maven to generate the
> documentation which is misleading.
>
> does anyone know how to add comments for dependencies?
For Maven 1 it could be solved by setting properties [1] on the
dependency. This would be something local to commons-logging that would
not work automatically in other places.
[1]
http://maven.apache.org/reference/project-descriptor.html#class_Dependency
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] dependencies [WAS Re: [logging] new release?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 09:39 +0000, Henning P. Schmiedehausen wrote:
> robert burrell donkin <ro...@blueyonder.co.uk> writes:
<snip>
> >downstream maintainers
> >----------------------
> >my major concern was about the impact of JCL dependencies on downstream
> >maintainers (rather than users). this include the gump infrastructure
> >and packagers such as debian. JCL is now a really basic component right
> >at the bottom of the java package tree.
>
> I think the problem is the perception of "compile time dependencies"
> and "run time dependencies" here.
IMHO for downstream maintainers, it's more a question of official core
dependencies (which is something a little different from either runtime
or compile time dependencies). the current build detects when optional
dependencies are missing and does not build anything relying on them.
required core dependencies are much smaller than those that we compile
into the standard distribution.
for gump, JCL is split into api and full. projects declare themselves
dependent upon the api and then don't have to worry about all the other
dependencies.
one of the biggest mistakes we made was creating an official
distribution which works only for compilation: to run an application,
you need something a little bigger. this means that the tactic which
works well for gump can't be easily applied by downstream maintainers
elsewhere.
> Our current build tool (maven) is not able to distinguish between
> compile-time and run-time dependencies. And some packagers don't
> understand this and start to require all of the compile time
> dependencies also at runtime.
(logging uses ant for builds but) i agree that this is a major issue for
all projects that use maven. JCL uses maven to generate the
documentation which is misleading.
does anyone know how to add comments for dependencies?
> >in the best case scenario, more dependencies mean that maintainers have
> >more work to do. in the worst case scenario, maintainers will be forced
> >to remove JCL and all packages that depend upon it from their
> >distribution. for example, debian will only ship java libraries that
> >will run on a free JVM. so, the impact of adding an innocuous dependency
>
> That is a political decision of debian (and e.g. Fedora) to do
> so. They won't be able to ship a large number of packages anyway
> (e.g. everything that requires Sun libs until either GlassFish or
> Geronimo come along far enough to allow the usage of things like mail
> or activation).
though some are more agnostic about JVM's than debian, all packagers
have similar problems with any dependencies they cannot package and
distribute. the whole point of package maintenance is to ensure that the
end user ends up with a working system.
the more official required dependencies a library declares, the more
likely it is that it cannot be packaged. so this is a real issue (as
well as one of perception).
> The question for this scenario is: Do we want to cater to the needs of
> "truly free software" (as in GNU) or do we want to continue down the
> road of "truly free software" (as in ASF). :-)
JCL is a library whose downstream users are often libraries and
applications. IMO the right attitude is to allow downstream libraries
and application a choice. this means having some appreciation of the
problems of downstream maintainers of packages.
> >may be that downstream maintainers are forced to remove scores or
> >hundreds or packages from their distributions.
>
> No matter what decision we make, there is someone is bound to stand up
> and whine. So IMHO we should just continue as it is comfortable to the
> JCL community and let the rest sort out the political details.
this isn't politics: it's about being sympathetic to the needs of our
downstream users. downstream users for a library include many
maintainers as well as developers of libraries and applications. IMO
it's important that allow them to choose whether they want to be able to
support packaged distributions or not. we should not be making this
choice for them.
many (most?) downstream maintainers roll their own from the source
possibly this could be addressed by analysing the ant build and creating
documentation aimed specifically at them.
> >perceived dependencies
> >----------------------
> >a different concern is that users are given the wrong impression of the
> >libraries which are required to run JCL. this includes users who feel
> >they need to find and download sources for all dependencies and those
> >who need to distribution and run a minimal stripped down version. what
> >classes and dependencies are required is a FAQ.
>
> +1 I hope that m2 will help us along here in being able to clearly
> specify build and runtime dependencies.
+1
the documentation we created for the break in compatibility between
collections 2 and 3 seemed to work out ok so maybe this one can be
addressed by documentation.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] dependencies [WAS Re: [logging] new release?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-10-07 at 22:16 +1300, Simon Kitching wrote:
> Hi All,
>
> A week or so ago I was prompted by new activity on the logging topic to
> review what is currently sitting in SVN. I think it's actually quite
> good, and perhaps we could try to push for a release.
>
> The issues I'm aware of are:
> * Do we include the ServletContextListener stuff or not? And if we do,
> do we put it in an "optional" jar or in the main jar?
>
> Personally, I would like to include it, and put it in the main jar.
> It does no harm being there, as no logging classes reference it. It
> only gets used if someone explicitly references it from a web.xml
> file.
>
> There have been objections about adding "dependencies", but JCL is
> a project that already has heaps of compile-time dependencies that
> aren't actually runtime dependencies, eg LogKit is a compile-time
> dependency too, but isn't needed to run.
i think that there are a lot of different issues here which could do
with being untangled. i'll make a stab at outlined the different ones i
see (possibly with a few to documenting later). please feel free to kick
off discussion (i've refrained from presenting solutions) and add any
i've missed.
downstream maintainers
----------------------
my major concern was about the impact of JCL dependencies on downstream
maintainers (rather than users). this include the gump infrastructure
and packagers such as debian. JCL is now a really basic component right
at the bottom of the java package tree.
in the best case scenario, more dependencies mean that maintainers have
more work to do. in the worst case scenario, maintainers will be forced
to remove JCL and all packages that depend upon it from their
distribution. for example, debian will only ship java libraries that
will run on a free JVM. so, the impact of adding an innocuous dependency
may be that downstream maintainers are forced to remove scores or
hundreds or packages from their distributions.
perceived dependencies
----------------------
a different concern is that users are given the wrong impression of the
libraries which are required to run JCL. this includes users who feel
they need to find and download sources for all dependencies and those
who need to distribution and run a minimal stripped down version. what
classes and dependencies are required is a FAQ.
solution specific jars
----------------------
we ship a number of jars to help users configure JCL effectively in
containers with complex classloaders. this will allow better
documentation to be created describing how to configure JCL effectively.
however, the complexity (and possible confusion) of shipping additional
optional jars is increased by the fact there are already multiple
versions of the core shipped.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] new release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-10-07 at 22:16 +1300, Simon Kitching wrote:
> Hi All,
>
> A week or so ago I was prompted by new activity on the logging topic to
> review what is currently sitting in SVN. I think it's actually quite
> good, and perhaps we could try to push for a release.
>
> The issues I'm aware of are:
> * There's a proposal to add a system property to disable all TCCL use.
> It's worth considering.
sounds reasonable to me but would need documenting since switching this
off in certain container configurations would likely have unfortunate
consequences...
<snip>
> * We still don't handle "cross-application" calls. Apparently by using
> JCA or similar one component can get a reference to an object in
> another container and make a call to it. In that case, there is
> absolutely no way the existing code can load a log adapter class from
> the contextClassLoader and cast it to a Log implementation.
i'm not sure i'm up to speed on this one. sounds a little dubious to me
but i'd need to study the details carefully. could you provide more
information or a link to a bug report?
> Currently, we walk the classloader ancestry chain looking for which
> loader is a child of which, and find they aren't related so panic.
> Perhaps we could just fall back to using diagnostic logging to output
> a message, then assign a NoOp logger?
sounds like a reasonable approach. i do wonder whether this has more to
do with use practices, though. if so, then we'd need to document and add
a recommendation...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org