You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dennis Lundberg <de...@mdh.se> on 2004/02/27 22:18:56 UTC
[logging] Are we ready for 1.0.4?
What are the plans for upcoming releases of commons-logging?
The reason I'm asking is that we would like to start using
commons-logging in an applet environment. We plan on using the SimpleLog
implementation to minimize the size of the download to the client. The
current (1.0.3) release doesn't work in an untrusted applet. There is a
patch that fixes this problem already in cvs though.
There are currently 8 open bugs for commons-logging in bugzilla. Two of
them includes patches by yours truly (25940 and 27124). I think that 4
of the remaining bugs (26802, 25156, 26598, 27135) should also be
considered for a 1.0.4 release. However I don't yet feel confident
enough with the inner workings of commons-logging to make patches for them.
What are your thoughts on making a commons-logging 1.0.4 release?
--
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] Are we ready for 1.0.4?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 28 Feb 2004, at 18:17, Craig R. McClanahan wrote:
> Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
>
>> On 27 Feb 2004, at 21:18, Dennis Lundberg wrote:
>>
>>> What are the plans for upcoming releases of commons-logging?
>>>
>>> The reason I'm asking is that we would like to start using
>>> commons-logging in an applet environment. We plan on using the
>>> SimpleLog implementation to minimize the size of the download to the
>>> client. The current (1.0.3) release doesn't work in an untrusted
>>> applet. There is a patch that fixes this problem already in cvs
>>> though.
>>>
>>> There are currently 8 open bugs for commons-logging in bugzilla. Two
>>> of them includes patches by yours truly (25940 and 27124). I think
>>> that 4 of the remaining bugs (26802, 25156, 26598, 27135) should also
>>> be considered for a 1.0.4 release. However I don't yet feel confident
>>> enough with the inner workings of commons-logging to make patches for
>>> them.
>>>
>>> What are your thoughts on making a commons-logging 1.0.4 release?
>>
>> we'd someone on the jakarta pmc to volunteer to act as the release
>> manager.
>
> Even though the PMC requirement is only to approve the release, not to
> do the
> grunt work to create it, I volunteer to RM a commons-logging 1.0.4
> release.
> I'm a Jakarta PMC member, so that should assuage Robert's concerns :-).
cool :)
i'm definitely willing to help with the grunt stuff.
my particular concern is that i'm not convinced that the jakarta pmc
can (in law) approve anything at the moment. (which is why i resigned
from the pmc.) i'm also of the opinion that the ASF cannot offer legal
aid to plain committers cutting releases (in the event that the
distribution is disputed in law).
> Besides, I haven't done the RM thing on any Apache code recently, so
> it's time
> to start doing that again. Can someone (Robert) point me at the
> latest and
> greatest process docs?
good question, this one :)
there's a bit of dispute about where the java instructions for creating
releases should be located. (now that jakarta is being un-brellar'd.)
so, i'm not really maintaining any of the documentation any more (at
least until there's some kind of consensus reached about where it
belongs).
the jakarta commons specific instructions can be found here:
http://jakarta.apache.org/commons/releases/index.html
this document is more cutting edge:
http://nagoya.apache.org/wiki/apachewiki.cgi?ReleaseManager
you'll need to create a openPGP-compatible signature for the release(i
use http://www.gnupg.org).
i've talked quite a few people through the new way for releases so
please ask away if you have any questions.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Are we ready for 1.0.4?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
> On 27 Feb 2004, at 21:18, Dennis Lundberg wrote:
>
> > What are the plans for upcoming releases of commons-logging?
> >
> > The reason I'm asking is that we would like to start using
> > commons-logging in an applet environment. We plan on using the
> > SimpleLog implementation to minimize the size of the download to the
> > client. The current (1.0.3) release doesn't work in an untrusted
> > applet. There is a patch that fixes this problem already in cvs
> > though.
> >
> > There are currently 8 open bugs for commons-logging in bugzilla. Two
> > of them includes patches by yours truly (25940 and 27124). I think
> > that 4 of the remaining bugs (26802, 25156, 26598, 27135) should also
> > be considered for a 1.0.4 release. However I don't yet feel confident
> > enough with the inner workings of commons-logging to make patches for
> > them.
> >
> > What are your thoughts on making a commons-logging 1.0.4 release?
>
> we'd someone on the jakarta pmc to volunteer to act as the release
> manager.
>
Even though the PMC requirement is only to approve the release, not to do the
grunt work to create it, I volunteer to RM a commons-logging 1.0.4 release.
I'm a Jakarta PMC member, so that should assuage Robert's concerns :-).
Besides, I haven't done the RM thing on any Apache code recently, so it's time
to start doing that again. Can someone (Robert) point me at the latest and
greatest process docs?
> - robert
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Are we ready for 1.0.4?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 27 Feb 2004, at 21:18, Dennis Lundberg wrote:
> What are the plans for upcoming releases of commons-logging?
>
> The reason I'm asking is that we would like to start using
> commons-logging in an applet environment. We plan on using the
> SimpleLog implementation to minimize the size of the download to the
> client. The current (1.0.3) release doesn't work in an untrusted
> applet. There is a patch that fixes this problem already in cvs
> though.
>
> There are currently 8 open bugs for commons-logging in bugzilla. Two
> of them includes patches by yours truly (25940 and 27124). I think
> that 4 of the remaining bugs (26802, 25156, 26598, 27135) should also
> be considered for a 1.0.4 release. However I don't yet feel confident
> enough with the inner workings of commons-logging to make patches for
> them.
>
> What are your thoughts on making a commons-logging 1.0.4 release?
we'd someone on the jakarta pmc to volunteer to act as the release
manager.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] improved exception diagnostics [WAS Re: [logging] work needed for 1.0.4]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 1 Mar 2004, at 02:44, Craig R. McClanahan wrote:
> Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
<snip>
>> the requests for changes seem (to me) to be focussed mainly on
>> improved
>> diagnostics (more meaningful stack traces and messages). we may be
>> able
>> to retain the older symantics by changing LogConfigurationException so
>> that it extracts the target exception and uses that for stack traces
>> and to create the message but still sets the internal cause as it does
>> now.
>>
>
> The only visible semantic change will be to people that are currently
> unwrapping
> InvocationTargetException instances themselves to get at the
> underlying cause.
> If LogConfigurationException never includes one, that code will never
> get
> executed, so we're just saving the applications an extra unwrap step,
> in
> addition to making exceptions more readable if we didn't do the unwrap
> ourselves.
>
> A couple of notes if we decide to implement this:
>
> * As Dennis points out, we should be calling
> InvocationTargetException.getTargetException()
> for pre-1.4 compatibility.
>
> * It's still possible for an ITE to have a null
> cause, in which case we should pass the ITE into
> the constructor for LogConfigurationException
> (it's better than a null).
i can definitely live with the above solution.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] improved exception diagnostics [WAS Re: [logging] work needed for 1.0.4]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
> (new thread to discuss these issues.)
>
> On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
>
> > #25156 [logging] Enhance error message for
> > "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> > - This seems to me to be similar to #26598
> >
> > #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does
> > not provide enough information on an InvocationTargetException in the
> > newInstance() method.
> > - This is something that has to be decided on. It involves catching an
> > extra Exception to provide a better error-message. Code that shows how
> > to do it is available in the bugreport.
>
> these are about making it easier for people to work out what's gone
> wrong when a LogConfigurationException is thrown. at the moment, all
> throwables are caught and rethrown as LogConfigurationException's. this
> includes InvocationTargetException's. (see
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26598)
>
> i think it's important to understand that any change in this area would
> probably result in a change in exception handling symantics. any code
> that processed LogConfigurationException's by using getCause may be
> effected by a change in this area.
In other code that deals with InvocationTargetExceptions, I've found myself
migrating more towards code that behaves as this enhancement request reports,
for precisely the reason being reported here (usability). Therefore, I'm
inclined to say "yes" on this one.
>
> the requests for changes seem (to me) to be focussed mainly on improved
> diagnostics (more meaningful stack traces and messages). we may be able
> to retain the older symantics by changing LogConfigurationException so
> that it extracts the target exception and uses that for stack traces
> and to create the message but still sets the internal cause as it does
> now.
>
The only visible semantic change will be to people that are currently unwrapping
InvocationTargetException instances themselves to get at the underlying cause.
If LogConfigurationException never includes one, that code will never get
executed, so we're just saving the applications an extra unwrap step, in
addition to making exceptions more readable if we didn't do the unwrap
ourselves.
A couple of notes if we decide to implement this:
* As Dennis points out, we should be calling
InvocationTargetException.getTargetException()
for pre-1.4 compatibility.
* It's still possible for an ITE to have a null
cause, in which case we should pass the ITE into
the constructor for LogConfigurationException
(it's better than a null).
Craig
> comments, anyone?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] improved exception diagnostics [WAS Re: [logging] work needed for 1.0.4]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
(new thread to discuss these issues.)
On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
> #25156 [logging] Enhance error message for
> "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> - This seems to me to be similar to #26598
>
> #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does
> not provide enough information on an InvocationTargetException in the
> newInstance() method.
> - This is something that has to be decided on. It involves catching an
> extra Exception to provide a better error-message. Code that shows how
> to do it is available in the bugreport.
these are about making it easier for people to work out what's gone
wrong when a LogConfigurationException is thrown. at the moment, all
throwables are caught and rethrown as LogConfigurationException's. this
includes InvocationTargetException's. (see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26598)
i think it's important to understand that any change in this area would
probably result in a change in exception handling symantics. any code
that processed LogConfigurationException's by using getCause may be
effected by a change in this area.
the requests for changes seem (to me) to be focussed mainly on improved
diagnostics (more meaningful stack traces and messages). we may be able
to retain the older symantics by changing LogConfigurationException so
that it extracts the target exception and uses that for stack traces
and to create the message but still sets the internal cause as it does
now.
comments, anyone?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] work needed for 1.0.4 [WAS Re: [logging] Are we ready for 1.0.4?]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
> On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
>
> > Here is a status for bugs regarding logging:
> >
> > #10818 [logging] Add method enter() and exit() methods to public Log
> > API
>
> this means breaking the Log interface. there is some utility in this
> proposal but i think that log is so widely used that backwards
> compatibility is crucial. i'd probably support rejecting this one.
>
I agree with Robert. In addition, not all of the logging implementations
support this sort of thing, so this change would violate the principle that c-l
is a simple wrapper around the existing functionality. Therefore, I'm leaning
towards -1 on this, even in a 2.0 version of c-l.
How, for example, would Log4JLogger implement such calls since Log4J doesn't
support these notions?
> > #21114 [logging] Create Log factory method getLog()
>
> ditto
-1 as well.
Log is an interface because the whole point of the package is to be a *wrapper*
around existing implementations. If you don't want to use LogFactory, then
just call "new SimpleLog()" or whatever yourself, or provide your own factory
-- although that, of course, would defeat the purpose of your proposed
enhancement.
>
> > - These involve changing the public API, so it's not something we can
> > do in a point release. Should these be marked as LATER in bugzilla?
>
> these involve breaking backward compatibility and would require a full
> version change. we could probably mark them LATER and add for
> consideration in commons-logging 2. comments anyone?
>
For the reasons stated above, I don't like them even in a c-l version 2.
> > #25156 [logging] Enhance error message for
> > "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> > - This seems to me to be similar to #26598
>
> i'd like to put a fix in for this but i think a little bit of
> discussion is required. i'll probably start a separate thread.
>
I'll follow up on the separate thread.
> > #25940 [logging] SimpleLog.java adds extra - characters
> > - This one's mine. There is a patch available for this one that is
> > pretty starightforward. The format of the log message needed some
> > work.
>
> fixed
>
> > #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does
> > not provide enough information on an InvocationTargetException in the
> > newInstance() method.
> > - This is something that has to be decided on. It involves catching an
> > extra Exception to provide a better error-message. Code that shows how
> > to do it is available in the bugreport.
>
> see 25156 above
>
> > #27135 [logging] SimpleLog log method should defer writing for better
> > reuse!
> > - This is something for the architects to decide. The key question
> > here is whether subclassing SimpleLog should be allowed.
>
> i'm inclined to discourage subclassing of SimpleLog but i don't feel
> very strongly on this issue (i can't see there being much harm). anyone
> else have any comments?
>
I can buy into this one, and will go ahead and do the commit.
We recently removed the "final" declaration on the implementation classes, so we
should go ahead and factor internal things to make subclassing easier when it
makes sense.
> > Other things that needs to be done:
> >
> > * I guess someone has to update all the files to the new licence.
>
> done
>
> > * I proofread the mavenized user guide earlier from a syntactic
> > perspective. Someone should read it form the semantic perspective.
>
> i'll get started on proofreading the user guide now.
>
> - robert
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] work needed for 1.0.4 [WAS Re: [logging] Are we ready for 1.0.4?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 28 Feb 2004, at 19:37, Dennis Lundberg wrote:
> Here is a status for bugs regarding logging:
>
> #10818 [logging] Add method enter() and exit() methods to public Log
> API
this means breaking the Log interface. there is some utility in this
proposal but i think that log is so widely used that backwards
compatibility is crucial. i'd probably support rejecting this one.
> #21114 [logging] Create Log factory method getLog()
ditto
> - These involve changing the public API, so it's not something we can
> do in a point release. Should these be marked as LATER in bugzilla?
these involve breaking backward compatibility and would require a full
version change. we could probably mark them LATER and add for
consideration in commons-logging 2. comments anyone?
> #25156 [logging] Enhance error message for
> "org.apache.commons.logging.impl.Log4JLogger does not implement Log"
> - This seems to me to be similar to #26598
i'd like to put a fix in for this but i think a little bit of
discussion is required. i'll probably start a separate thread.
> #25940 [logging] SimpleLog.java adds extra - characters
> - This one's mine. There is a patch available for this one that is
> pretty starightforward. The format of the log message needed some
> work.
fixed
> #26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does
> not provide enough information on an InvocationTargetException in the
> newInstance() method.
> - This is something that has to be decided on. It involves catching an
> extra Exception to provide a better error-message. Code that shows how
> to do it is available in the bugreport.
see 25156 above
> #27135 [logging] SimpleLog log method should defer writing for better
> reuse!
> - This is something for the architects to decide. The key question
> here is whether subclassing SimpleLog should be allowed.
i'm inclined to discourage subclassing of SimpleLog but i don't feel
very strongly on this issue (i can't see there being much harm). anyone
else have any comments?
> Other things that needs to be done:
>
> * I guess someone has to update all the files to the new licence.
done
> * I proofread the mavenized user guide earlier from a syntactic
> perspective. Someone should read it form the semantic perspective.
i'll get started on proofreading the user guide now.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] work needed for 1.0.4 [WAS Re: [logging] Are we ready
for 1.0.4?]
Posted by Dennis Lundberg <de...@mdh.se>.
Here is a status for bugs regarding logging:
#10818 [logging] Add method enter() and exit() methods to public Log API
#21114 [logging] Create Log factory method getLog()
- These involve changing the public API, so it's not something we can do
in a point release. Should these be marked as LATER in bugzilla?
#25156 [logging] Enhance error message for
"org.apache.commons.logging.impl.Log4JLogger does not implement Log"
- This seems to me to be similar to #26598
#25940 [logging] SimpleLog.java adds extra - characters
- This one's mine. There is a patch available for this one that is
pretty starightforward. The format of the log message needed some work.
#26598 [logging] org.apache.commons.logging.impl.LogFactoryImpl does not
provide enough information on an InvocationTargetException in the
newInstance() method.
- This is something that has to be decided on. It involves catching an
extra Exception to provide a better error-message. Code that shows how
to do it is available in the bugreport.
#27135 [logging] SimpleLog log method should defer writing for better reuse!
- This is something for the architects to decide. The key question here
is whether subclassing SimpleLog should be allowed.
Other things that needs to be done:
* I guess someone has to update all the files to the new licence.
* I proofread the mavenized user guide earlier from a syntactic
perspective. Someone should read it form the semantic perspective.
--
Dennis Lundberg
robert burrell donkin wrote:
> dennis seems to have been doing a good job going through the bugs.
> dennis: could you post a status report for the bugs? (stuff like)
>
> the web site is in transition to the mavenized version. i think that we
> need to complete this for we cut the release. we probably need to find
> some time to proofread the mavenized user guide. if no one jumps in and
> volunteers for this job, i'll take a look sometime early next week. the
> other issue is that i cannot build the commons website (in order to
> remove the links to the old site) at the moment. i'll try to get on top
> of this issue soon.
>
> there are some features i've been wanting to add for a while now but
> they'll probably wait until after this release. anyone else have any
> critical features that they really want in?
>
> - robert
>
> On 27 Feb 2004, at 21:18, Dennis Lundberg wrote:
>
>> What are the plans for upcoming releases of commons-logging?
>>
>> The reason I'm asking is that we would like to start using
>> commons-logging in an applet environment. We plan on using the
>> SimpleLog implementation to minimize the size of the download to the
>> client. The current (1.0.3) release doesn't work in an untrusted
>> applet. There is a patch that fixes this problem already in cvs though.
>>
>> There are currently 8 open bugs for commons-logging in bugzilla. Two
>> of them includes patches by yours truly (25940 and 27124). I think
>> that 4 of the remaining bugs (26802, 25156, 26598, 27135) should also
>> be considered for a 1.0.4 release. However I don't yet feel confident
>> enough with the inner workings of commons-logging to make patches for
>> them.
>>
>> What are your thoughts on making a commons-logging 1.0.4 release?
>>
>> --
>> Dennis Lundberg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] work needed for 1.0.4 [WAS Re: [logging] Are we ready for 1.0.4?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
dennis seems to have been doing a good job going through the bugs.
dennis: could you post a status report for the bugs? (stuff like)
the web site is in transition to the mavenized version. i think that we
need to complete this for we cut the release. we probably need to find
some time to proofread the mavenized user guide. if no one jumps in and
volunteers for this job, i'll take a look sometime early next week. the
other issue is that i cannot build the commons website (in order to
remove the links to the old site) at the moment. i'll try to get on top
of this issue soon.
there are some features i've been wanting to add for a while now but
they'll probably wait until after this release. anyone else have any
critical features that they really want in?
- robert
On 27 Feb 2004, at 21:18, Dennis Lundberg wrote:
> What are the plans for upcoming releases of commons-logging?
>
> The reason I'm asking is that we would like to start using
> commons-logging in an applet environment. We plan on using the
> SimpleLog implementation to minimize the size of the download to the
> client. The current (1.0.3) release doesn't work in an untrusted
> applet. There is a patch that fixes this problem already in cvs
> though.
>
> There are currently 8 open bugs for commons-logging in bugzilla. Two
> of them includes patches by yours truly (25940 and 27124). I think
> that 4 of the remaining bugs (26802, 25156, 26598, 27135) should also
> be considered for a 1.0.4 release. However I don't yet feel confident
> enough with the inner workings of commons-logging to make patches for
> them.
>
> What are your thoughts on making a commons-logging 1.0.4 release?
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org