You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2007/11/19 04:13:36 UTC
[pool][dbcp] instrumentation
I have been working on adding logging to pool and dbcp per previous
discussion here. I started with a partially instrumented version of
pool 1.3 that I have been using to investigate bug reports and test
performance. I used jdk logging with the following guidelines
* Finest (trace) level for detailed/diagnostic logging
* Finer level for things a commons developer may want to know
* Fine (debug) level for things a developer of an app using this
component may want to know
* Config level for configuration-modification events
* Info level for things a system administrator may want to know
* Warning level for things indicating a recoverable problem
* Severe level for things indicating a problem that the component
could not recover from
I used fully qualified class names for loggers, flags, logp and a
custom formatter that adds the thread id to the log message.
While running with Config or higher levels, there does not appear to
be any measurable performance impact, the instrumentation seriously
clutters the already complex code. So I guess what I would like to
propose is that we release both fully instrumented and minimally
instrumented jars for these components, with the minimally
instrumented version in trunk and a "-inst" version built from a copy
of the release tag. This is essentially what I have done for (most
of) pool 1.3, which I would like to complete and commit to a branch
and release as pool-1.3-inst or somesuch. Similarly for
dbcp-1.2.2-inst and then for subsequent versions.
I know this seems like extra work for components that we are lacking
volunteers for, but it could really help in resolving user issues if
instrumented jars were available. Alternatively, we could just move
forward with dbcp 1.3, pool 1.4, adding "Config-level" logging (or
event notification) only. Thoughts?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by Phil Steitz <ph...@gmail.com>.
On 11/20/07, Noel J. Bergman <no...@devtech.com> wrote:
> Jörg Schaible wrote:
> > Since the JUL loggers sit in the system class path, any formatter
> > implementation *must* be available also in the system class path.
>
> Isn't this part of what JULI fixes?
>
>From the tomcat docs, looks like yes. I guess the problem is how
things will work in other containers / classloading contexts.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by Phil Steitz <ph...@gmail.com>.
On Dec 8, 2007 6:44 PM, sebb <se...@gmail.com> wrote:
>
> On 20/11/2007, Phil Steitz <ph...@gmail.com> wrote:
> > On Nov 20, 2007 2:30 AM, Jörg Schaible
> > <Jo...@elsag-solutions.com> wrote:
> > > Phil Steitz wrote:
> > > > On Nov 19, 2007 11:46 PM, Jörg Schaible
> > > > <Jo...@elsag-solutions.com> wrote:
> > > >>
> > > >> Phil Steitz wrote:
> > > [snip]
> > > >>> Any other comments on the naming, levels, use of JUL before I start?
> > > >>
> > > >> Why not using commons-logging? It supports trace level. JUL
> > > > is really a pain. It is applicable for applications like
> > > > Tomcat, but not really for components. Everybody that tried
> > > > to use an own JUL-formatter knows what I mean. Big enterprise
> > > > companies normally hesitate or simply do not permit to add
> > > > 3rd party jars to the JVM classpath.
> > > >
> > > > Can you explain more what you mean about third party jars here? It
> > > > was general pushback / hesitancy to bring in dependency on
> > > > commons-logging (or anything else) that led us to think about just
> > > > using jdk logging. I was going to add a simple formatter (all that I
> > > > need is to expose the thread ID) and bundle it with pool, making it
> > > > also available to dbcp.
> > > >
> > > > I am open to either approach and don't particularly care which API we
> > > > use. I just want to minimize conflict / configuration hassles for
> > > > users.
> > >
> > > Since the JUL loggers sit in the system class path, any formatter implementation *must* be available also in the system class path. For simple Java applications this is no issue, simply set the VM class path at startup, but this is no longer true if the app deals with classloaders. I was bitten the first time using the uberjar mechanism of Maven1 that uses an own classloader to extract the classes from the embedded jars, my JUL formatter was simply no longer available. In a Java EE environment your "simple" formatter is never used - unless you put your jar with the formatter implementation into the JRE's ext directory or setup the app server accordingly. However, I don't have to tell you, that as consequence no web or enterprise app will be able to use its own version of this jar.
> > >
> > > There is a reason why JUL was never a real success story.
> >
> > Thanks, Jorg. I understand now. This is not good. So, any objections
> > to bringing in commons-logging, or alternative ideas?
>
> As a commons project, IMO it should be using commons-logging.
>
> Likewise POOL...
>
Thanks for the feedback. I agree both should use the same approach.
I will translate the JUL stuff that I have for pool to use the c-l API
and start committing. Thanks in advance for patches / feedback.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by sebb <se...@gmail.com>.
On 20/11/2007, Phil Steitz <ph...@gmail.com> wrote:
> On Nov 20, 2007 2:30 AM, Jörg Schaible
> <Jo...@elsag-solutions.com> wrote:
> > Phil Steitz wrote:
> > > On Nov 19, 2007 11:46 PM, Jörg Schaible
> > > <Jo...@elsag-solutions.com> wrote:
> > >>
> > >> Phil Steitz wrote:
> > [snip]
> > >>> Any other comments on the naming, levels, use of JUL before I start?
> > >>
> > >> Why not using commons-logging? It supports trace level. JUL
> > > is really a pain. It is applicable for applications like
> > > Tomcat, but not really for components. Everybody that tried
> > > to use an own JUL-formatter knows what I mean. Big enterprise
> > > companies normally hesitate or simply do not permit to add
> > > 3rd party jars to the JVM classpath.
> > >
> > > Can you explain more what you mean about third party jars here? It
> > > was general pushback / hesitancy to bring in dependency on
> > > commons-logging (or anything else) that led us to think about just
> > > using jdk logging. I was going to add a simple formatter (all that I
> > > need is to expose the thread ID) and bundle it with pool, making it
> > > also available to dbcp.
> > >
> > > I am open to either approach and don't particularly care which API we
> > > use. I just want to minimize conflict / configuration hassles for
> > > users.
> >
> > Since the JUL loggers sit in the system class path, any formatter implementation *must* be available also in the system class path. For simple Java applications this is no issue, simply set the VM class path at startup, but this is no longer true if the app deals with classloaders. I was bitten the first time using the uberjar mechanism of Maven1 that uses an own classloader to extract the classes from the embedded jars, my JUL formatter was simply no longer available. In a Java EE environment your "simple" formatter is never used - unless you put your jar with the formatter implementation into the JRE's ext directory or setup the app server accordingly. However, I don't have to tell you, that as consequence no web or enterprise app will be able to use its own version of this jar.
> >
> > There is a reason why JUL was never a real success story.
>
> Thanks, Jorg. I understand now. This is not good. So, any objections
> to bringing in commons-logging, or alternative ideas?
As a commons project, IMO it should be using commons-logging.
Likewise POOL...
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by Phil Steitz <ph...@gmail.com>.
On Nov 20, 2007 2:30 AM, Jörg Schaible
<Jo...@elsag-solutions.com> wrote:
> Phil Steitz wrote:
> > On Nov 19, 2007 11:46 PM, Jörg Schaible
> > <Jo...@elsag-solutions.com> wrote:
> >>
> >> Phil Steitz wrote:
> [snip]
> >>> Any other comments on the naming, levels, use of JUL before I start?
> >>
> >> Why not using commons-logging? It supports trace level. JUL
> > is really a pain. It is applicable for applications like
> > Tomcat, but not really for components. Everybody that tried
> > to use an own JUL-formatter knows what I mean. Big enterprise
> > companies normally hesitate or simply do not permit to add
> > 3rd party jars to the JVM classpath.
> >
> > Can you explain more what you mean about third party jars here? It
> > was general pushback / hesitancy to bring in dependency on
> > commons-logging (or anything else) that led us to think about just
> > using jdk logging. I was going to add a simple formatter (all that I
> > need is to expose the thread ID) and bundle it with pool, making it
> > also available to dbcp.
> >
> > I am open to either approach and don't particularly care which API we
> > use. I just want to minimize conflict / configuration hassles for
> > users.
>
> Since the JUL loggers sit in the system class path, any formatter implementation *must* be available also in the system class path. For simple Java applications this is no issue, simply set the VM class path at startup, but this is no longer true if the app deals with classloaders. I was bitten the first time using the uberjar mechanism of Maven1 that uses an own classloader to extract the classes from the embedded jars, my JUL formatter was simply no longer available. In a Java EE environment your "simple" formatter is never used - unless you put your jar with the formatter implementation into the JRE's ext directory or setup the app server accordingly. However, I don't have to tell you, that as consequence no web or enterprise app will be able to use its own version of this jar.
>
> There is a reason why JUL was never a real success story.
Thanks, Jorg. I understand now. This is not good. So, any objections
to bringing in commons-logging, or alternative ideas?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool][dbcp] instrumentation
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jörg Schaible wrote:
> Since the JUL loggers sit in the system class path, any formatter
> implementation *must* be available also in the system class path.
Isn't this part of what JULI fixes?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool][dbcp] instrumentation
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Phil Steitz wrote:
> On Nov 19, 2007 11:46 PM, Jörg Schaible
> <Jo...@elsag-solutions.com> wrote:
>>
>> Phil Steitz wrote:
[snip]
>>> Any other comments on the naming, levels, use of JUL before I start?
>>
>> Why not using commons-logging? It supports trace level. JUL
> is really a pain. It is applicable for applications like
> Tomcat, but not really for components. Everybody that tried
> to use an own JUL-formatter knows what I mean. Big enterprise
> companies normally hesitate or simply do not permit to add
> 3rd party jars to the JVM classpath.
>
> Can you explain more what you mean about third party jars here? It
> was general pushback / hesitancy to bring in dependency on
> commons-logging (or anything else) that led us to think about just
> using jdk logging. I was going to add a simple formatter (all that I
> need is to expose the thread ID) and bundle it with pool, making it
> also available to dbcp.
>
> I am open to either approach and don't particularly care which API we
> use. I just want to minimize conflict / configuration hassles for
> users.
Since the JUL loggers sit in the system class path, any formatter implementation *must* be available also in the system class path. For simple Java applications this is no issue, simply set the VM class path at startup, but this is no longer true if the app deals with classloaders. I was bitten the first time using the uberjar mechanism of Maven1 that uses an own classloader to extract the classes from the embedded jars, my JUL formatter was simply no longer available. In a Java EE environment your "simple" formatter is never used - unless you put your jar with the formatter implementation into the JRE's ext directory or setup the app server accordingly. However, I don't have to tell you, that as consequence no web or enterprise app will be able to use its own version of this jar.
There is a reason why JUL was never a real success story.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by Phil Steitz <ph...@gmail.com>.
On Nov 19, 2007 11:46 PM, Jörg Schaible
<Jo...@elsag-solutions.com> wrote:
>
> Phil Steitz wrote:
> > On 11/19/07, Noel J. Bergman <no...@devtech.com> wrote:
> >> sebb wrote:
> >>
> >>> Phil Steitz <ph...@gmail.com> wrote:
> >>>> I have been working on adding logging to pool and dbcp per previous
> >>>> discussion here. I started with a partially instrumented version
> >>>> of pool 1.3 that I have been using to investigate bug reports and
> >>>> test performance. I used jdk logging with the following guidelines
> >>
> >>> Might have been better to use one of the logging facades - or can
> >>> JUL be configured to co-operate with other logging implementations?
> >>
> >> ref: http://www.crazysquirrel.com/computing/java/logging.jspx
> >> http://tomcat.apache.org/tomcat-6.0-doc/logging.html
> >>
> > http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su
> >> mmary.html
> >>
> >>
> >>>> While running with Config or higher levels, there does not appear
> >>>> to be any measurable performance impact, the instrumentation
> >>>> seriously clutters the already complex code. So I guess what I
> >>>> would like to propose is that we release both fully instrumented
> >>>> and minimally instrumented jars for these components, with the
> >>>> minimally instrumented version in trunk and a "-inst" version
> >>>> built from a copy of the release tag.
> >>
> >>> So there are now two versions of code that need to be maintained:
> >>> - a simpler trunk
> >>> - more complicated tag version
> >>
> >>> Seems to me that this adds a huge load to the release process,
> >>> unless some way can be found to add the logging automatically.
> >>
> >> I also see that as a concern, including for maintanence, unless the
> >> instrumentation could be automated during the build process.
> >>
> >>>> I know this seems like extra work for components that we are
> >>>> lacking volunteers for, but it could really help in resolving user
> >>>> issues if instrumented jars were available.
> >>
> >> Given that it isn't a performance hit, and given the benefits that
> >> are claimed, I would sooner we maintain a single branch with
> >> instrumentation than two branches.
> >>
> >> Phil, your thoughts?
> >
> > Thanks for the feedback. I agree that maintaining a single branch is
> > best, but what I am struggling with is how ugly the already complex
> > code becomes when I add (appropriately flagged) trace-level logging
> > capabilities, which I have found useful in troubleshooting issues.
> >
> > I guess the best approach is to forego trace-level logging and get
> > some basic instrumentation into trunk. I will start committing this
> > for pool and dbcp and welcome suggestions for improvement.
> >
> > Any other comments on the naming, levels, use of JUL before I start?
>
> Why not using commons-logging? It supports trace level. JUL is really a pain. It is applicable for applications like Tomcat, but not really for components. Everybody that tried to use an own JUL-formatter knows what I mean. Big enterprise companies normally hesitate or simply do not permit to add 3rd party jars to the JVM classpath.
Can you explain more what you mean about third party jars here? It
was general pushback / hesitancy to bring in dependency on
commons-logging (or anything else) that led us to think about just
using jdk logging. I was going to add a simple formatter (all that I
need is to expose the thread ID) and bundle it with pool, making it
also available to dbcp.
I am open to either approach and don't particularly care which API we
use. I just want to minimize conflict / configuration hassles for
users.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool][dbcp] instrumentation
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Phil Steitz wrote:
> On 11/19/07, Noel J. Bergman <no...@devtech.com> wrote:
>> sebb wrote:
>>
>>> Phil Steitz <ph...@gmail.com> wrote:
>>>> I have been working on adding logging to pool and dbcp per previous
>>>> discussion here. I started with a partially instrumented version
>>>> of pool 1.3 that I have been using to investigate bug reports and
>>>> test performance. I used jdk logging with the following guidelines
>>
>>> Might have been better to use one of the logging facades - or can
>>> JUL be configured to co-operate with other logging implementations?
>>
>> ref: http://www.crazysquirrel.com/computing/java/logging.jspx
>> http://tomcat.apache.org/tomcat-6.0-doc/logging.html
>>
> http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su
>> mmary.html
>>
>>
>>>> While running with Config or higher levels, there does not appear
>>>> to be any measurable performance impact, the instrumentation
>>>> seriously clutters the already complex code. So I guess what I
>>>> would like to propose is that we release both fully instrumented
>>>> and minimally instrumented jars for these components, with the
>>>> minimally instrumented version in trunk and a "-inst" version
>>>> built from a copy of the release tag.
>>
>>> So there are now two versions of code that need to be maintained:
>>> - a simpler trunk
>>> - more complicated tag version
>>
>>> Seems to me that this adds a huge load to the release process,
>>> unless some way can be found to add the logging automatically.
>>
>> I also see that as a concern, including for maintanence, unless the
>> instrumentation could be automated during the build process.
>>
>>>> I know this seems like extra work for components that we are
>>>> lacking volunteers for, but it could really help in resolving user
>>>> issues if instrumented jars were available.
>>
>> Given that it isn't a performance hit, and given the benefits that
>> are claimed, I would sooner we maintain a single branch with
>> instrumentation than two branches.
>>
>> Phil, your thoughts?
>
> Thanks for the feedback. I agree that maintaining a single branch is
> best, but what I am struggling with is how ugly the already complex
> code becomes when I add (appropriately flagged) trace-level logging
> capabilities, which I have found useful in troubleshooting issues.
>
> I guess the best approach is to forego trace-level logging and get
> some basic instrumentation into trunk. I will start committing this
> for pool and dbcp and welcome suggestions for improvement.
>
> Any other comments on the naming, levels, use of JUL before I start?
Why not using commons-logging? It supports trace level. JUL is really a pain. It is applicable for applications like Tomcat, but not really for components. Everybody that tried to use an own JUL-formatter knows what I mean. Big enterprise companies normally hesitate or simply do not permit to add 3rd party jars to the JVM classpath.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by Phil Steitz <ph...@gmail.com>.
On 11/19/07, Noel J. Bergman <no...@devtech.com> wrote:
> sebb wrote:
>
> > Phil Steitz <ph...@gmail.com> wrote:
> > > I have been working on adding logging to pool and dbcp per previous
> > > discussion here. I started with a partially instrumented version of
> > > pool 1.3 that I have been using to investigate bug reports and test
> > > performance. I used jdk logging with the following guidelines
>
> > Might have been better to use one of the logging facades - or can JUL
> > be configured to co-operate with other logging implementations?
>
> ref: http://www.crazysquirrel.com/computing/java/logging.jspx
> http://tomcat.apache.org/tomcat-6.0-doc/logging.html
> http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su
> mmary.html
>
>
> > > While running with Config or higher levels, there does not appear to
> > > be any measurable performance impact, the instrumentation seriously
> > > clutters the already complex code. So I guess what I would like to
> > > propose is that we release both fully instrumented and minimally
> > > instrumented jars for these components, with the minimally
> > > instrumented version in trunk and a "-inst" version built from a copy
> > > of the release tag.
>
> > So there are now two versions of code that need to be maintained:
> > - a simpler trunk
> > - more complicated tag version
>
> > Seems to me that this adds a huge load to the release process, unless
> > some way can be found to add the logging automatically.
>
> I also see that as a concern, including for maintanence, unless the
> instrumentation could be automated during the build process.
>
> > > I know this seems like extra work for components that we are lacking
> > > volunteers for, but it could really help in resolving user issues if
> > > instrumented jars were available.
>
> Given that it isn't a performance hit, and given the benefits that are
> claimed, I would sooner we maintain a single branch with instrumentation
> than two branches.
>
> Phil, your thoughts?
Thanks for the feedback. I agree that maintaining a single branch is
best, but what I am struggling with is how ugly the already complex
code becomes when I add (appropriately flagged) trace-level logging
capabilities, which I have found useful in troubleshooting issues.
I guess the best approach is to forego trace-level logging and get
some basic instrumentation into trunk. I will start committing this
for pool and dbcp and welcome suggestions for improvement.
Any other comments on the naming, levels, use of JUL before I start?
Phil
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool][dbcp] instrumentation
Posted by "Noel J. Bergman" <no...@devtech.com>.
sebb wrote:
> Phil Steitz <ph...@gmail.com> wrote:
> > I have been working on adding logging to pool and dbcp per previous
> > discussion here. I started with a partially instrumented version of
> > pool 1.3 that I have been using to investigate bug reports and test
> > performance. I used jdk logging with the following guidelines
> Might have been better to use one of the logging facades - or can JUL
> be configured to co-operate with other logging implementations?
ref: http://www.crazysquirrel.com/computing/java/logging.jspx
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su
mmary.html
> > While running with Config or higher levels, there does not appear to
> > be any measurable performance impact, the instrumentation seriously
> > clutters the already complex code. So I guess what I would like to
> > propose is that we release both fully instrumented and minimally
> > instrumented jars for these components, with the minimally
> > instrumented version in trunk and a "-inst" version built from a copy
> > of the release tag.
> So there are now two versions of code that need to be maintained:
> - a simpler trunk
> - more complicated tag version
> Seems to me that this adds a huge load to the release process, unless
> some way can be found to add the logging automatically.
I also see that as a concern, including for maintanence, unless the
instrumentation could be automated during the build process.
> > I know this seems like extra work for components that we are lacking
> > volunteers for, but it could really help in resolving user issues if
> > instrumented jars were available.
Given that it isn't a performance hit, and given the benefits that are
claimed, I would sooner we maintain a single branch with instrumentation
than two branches.
Phil, your thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool][dbcp] instrumentation
Posted by sebb <se...@gmail.com>.
On 19/11/2007, Phil Steitz <ph...@gmail.com> wrote:
> I have been working on adding logging to pool and dbcp per previous
> discussion here. I started with a partially instrumented version of
> pool 1.3 that I have been using to investigate bug reports and test
> performance. I used jdk logging with the following guidelines
Might have been better to use one of the logging facades - or can JUL
be configured to co-operate with other logging implementations?
> * Finest (trace) level for detailed/diagnostic logging
> * Finer level for things a commons developer may want to know
> * Fine (debug) level for things a developer of an app using this
> component may want to know
> * Config level for configuration-modification events
> * Info level for things a system administrator may want to know
> * Warning level for things indicating a recoverable problem
> * Severe level for things indicating a problem that the component
> could not recover from
>
> I used fully qualified class names for loggers, flags, logp and a
> custom formatter that adds the thread id to the log message.
>
> While running with Config or higher levels, there does not appear to
> be any measurable performance impact, the instrumentation seriously
> clutters the already complex code. So I guess what I would like to
> propose is that we release both fully instrumented and minimally
> instrumented jars for these components, with the minimally
> instrumented version in trunk and a "-inst" version built from a copy
> of the release tag. This is essentially what I have done for (most
> of) pool 1.3, which I would like to complete and commit to a branch
> and release as pool-1.3-inst or somesuch. Similarly for
> dbcp-1.2.2-inst and then for subsequent versions.
So there are now two versions of code that need to be maintained:
- a simpler trunk
- more complicated tag version
Seems to me that this adds a huge load to the release process, unless
some way can be found to add the logging automatically. In which case,
one could develop trunk without logging, and add the logging just to
the release.
AIUI, *every* release tag will need to be converted to an instrumented release.
Or every change to trunk will need to be added to the instrumented version.
I don't think this is sustainable.
> I know this seems like extra work for components that we are lacking
> volunteers for, but it could really help in resolving user issues if
> instrumented jars were available. Alternatively, we could just move
> forward with dbcp 1.3, pool 1.4, adding "Config-level" logging (or
> event notification) only. Thoughts?
Given that the instrumentation does not seem to impact performance, it
seems unfair to force the user to swap jars in order to provide
logging facilities.
But whatever is done, I agree that some logging is needed in the normal jars.
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org