To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery has an issue affecting its community integration.
This issue af
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery has an issue affecting its community integration.
This issue af
+1
***
Richard A. Sitze
IBM WebSphere WebServices Development
robert burrell donkin <[EMAIL PROTECTED]> wrote on
02/26/2005 01:41:05 PM:
> the release candidate has been available for a while now and i am not
> aware of any problems with it. the next stag
With so many benchmark and profiling tools available that do not require
instrumenting the code, what real benefit do you see this providing?
Similarly, with AspectJ [or other alternatives], what are you providing
that goes beyond what you might do in that space?
*
It means a fix will be made available as part of the next phase.
***
Richard A. Sitze
IBM WebSphere WebServices Development
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/14/2005 06:20:14 AM:
> At 05:59 PM 2/13/2005, robert burrell donkin wrote:
>
> > > Anyw
robert burrell donkin <[EMAIL PROTECTED]> wrote on
02/08/2005 04:25:57 PM:
> one of the drawbacks about JCL 1.0.x is the approach to handling errors
> in the configuration and discovery mechanism. JCL falls down and (in
> most commons use cases) takes the application with it. it also fails to
> p
Just for the record, might as well get this out now :-)
I'm going to take a fairly STRONG position against fixing discovery in a
1.0.6 if that is the ONLY change going in. Why?
- The "fix" I envision will necessitate "backwards incompatible" behavior
in a "standalone" commons-logging.jar file.
robert burrell donkin <[EMAIL PROTECTED]> wrote on
02/07/2005 02:45:28 PM:
> certainly the web application deployer should know :)
>
> IIRC it should be possible to tap into lifecycle events and perform the
> shutdown by creating a small amount of code external to the actual
> application.
>
>
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/07/2005 01:32:26 PM:
> >The idea of having separate jar files has been floated about for a few
> >years, for various reasons. I believe it's only recently been
associated
> >with the idea that such would help alleviate classloader problems in
the
Oh for better diagramming facilities in mail :-)
***
Richard A. Sitze
IBM WebSphere WebServices Development
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/07/2005 11:17:36 AM:
>
> On 2005-01-27 22:52:02, Richard Sitze wrote:
>
> Richard,
robert burrell donkin <[EMAIL PROTECTED]> wrote on 01/30/2005 04:09:54
PM:
>
> On 28 Jan 2005, at 20:15, Richard Sitze wrote:
>
> > [re-send.. I don't see this picked up... hmmm]
> >
> >
> > Once, a long long time ago... someone wrote:
> >
>
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 02/01/2005 01:55:13 PM:
>
> On 2005-01-27 22:52:02, Richard Sitze wrote:
>
> > A. Parent / Child ClassLoaders, General
> >
> > - commons-logging.jar#org.apache.commons.logging.Log is
> > loaded/loadabl
[re-send.. I don't see this picked up... hmmm]
I'd like to begin to identify the ClassLoader problems with the
current JCL discovery mechanism. If you are aware of additional
issues, please respond and let's get them all out on the table.
I believe the following two scenarios summarize the speci
[re-send.. I don't see this picked up... hmmm]
Once, a long long time ago... someone wrote:
> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed
> in a child loader ( like WEB-INF/lib ).
>
> What happens:
Once, a long long time ago... someone wrote:
> The problem: it won't work if commons-logging.jar is installed in the
> parent class loader, and log4j.jar ( or another logger ) is installed
> in a child loader ( like WEB-INF/lib ).
>
> What happens:
> - the factory uses the thread class loader to
I'd like to begin to identify the ClassLoader problems with the
current JCL discovery mechanism. If you are aware of additional
issues, please respond and let's get them all out on the table.
I believe the following two scenarios summarize the specific issues,
as well as more general problems.
A
Well I've had a few days to cool off, and my head feels better too.
I acknowledge that there are problems with the discovery process in JCL.
We aim to fix that, it is one of the tenants of what is being proposed for
JCL version 'next'.
I wish it were as simple to resolve these issues in the mor
ing. But competitions is a good thing; my projects
> will ship w/ Log4j instead and ugli. One less jar is good.
> .V
>
>
> Matt Sgarlata wrote:
>
> > Richard Sitze wrote:
> >
> >> news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
> >>
&g
Phil Steitz <[EMAIL PROTECTED]> wrote on 01/24/2005 05:25:09 PM:
> While I agree with everything that you have said about "indiscriminate
> logging," I think you are missing Richard's point here. In some
> environments, this sort of ad hoc change is not allowed or cannot be
> executed quickl
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 01/24/2005 11:06:21 AM:
> Richard Sitze wrote on 2005-01-21 20:07:49:
>
> >The purpose of logging is to capture enough state of a system, so that
> >when you identify *where* the error occurs in the logs, you have
> >
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 01/21/2005 01:45:46 PM:
>
> Logging too much can be as bad as the absence of logging.
>
> Cluttering the log output with entry and exit events will increase the
> amount of noise and negatively impact the usefulness of the
> logs. Consequenly, logging ente
robert burrell donkin <[EMAIL PROTECTED]> wrote on
01/19/2005 04:49:09 PM:
> IMO the first step before any work can begin on any improvements is to
> release the current code (this contains an important enhancement
> improving memory release in the 1.0.x series of releases). therefore,
> i pr
Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:16:35 AM:
> 9. Logging entry/exit event is not so common and I'd better write
directly:
>
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
>
> rather than
>
> log.enter(this, "foo", new Object[] { param1, param2 }, "
Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:16:35 AM:
> 9. Logging entry/exit event is not so common and I'd better write
directly:
>
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
>
> rather than
>
> log.enter(this, "foo", new Object[] { param1, param2 }, "
Eclipse makes search/replace of strings during refactoring "optional".
It's certainly easy enough to manage there.
Emmanuel Bourg <[EMAIL PROTECTED]> wrote on 01/19/2005 06:22:29 AM:
> Tomas Znamenacek wrote:
>
> > 1. Refactoring a method containing calls to log.enter() and
log.exit(),
> > wit
Paul Libbrecht <[EMAIL PROTECTED]> wrote on 01/04/2005 03:26:00 AM:
> Hi,
>
> This may be related but I was fighting recently with embedding Jelly
> within jEdit which, of course, has its own class-loading mechanism
> because of plugins.
> I simply did not manage to have jelly:log messages dire
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:31:23 PM:
>
> At 2004-12-16 16:51:31, Richard Sitze wrote:
>
> > I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
> >
> > I advocate a *warn* or *error* on either, using the simple defau
news <[EMAIL PROTECTED]> wrote on 12/27/2004 06:40:16 PM:
> I think often JCL will be used as you describe, but not always.
"Not always" is of less concern. Matt, the PRIMARY focus of JCL is as
Ceki described. There are no if/ands/buts about it. If you choose to use
it in any other fashion,
Martin Cooper <[EMAIL PROTECTED]> wrote on 12/27/2004 01:07:28 PM:
> On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <[EMAIL PROTECTED]>
wrote:
> > Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:
> >
> > > At 03:05 AM 12/27/2004
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/27/2004
02:57:45 AM:
> "Charles Daniels" <[EMAIL PROTECTED]> writes:
>
> >> -Original Message-
> >> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> >> Sent: Sunday, December 26, 2004 11:24 AM
> >> To: commons-dev@jakarta.apache.or
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:49:45 AM:
> At 03:05 AM 12/27/2004, Charles Daniels wrote:
>
> >If I understand the JCL discovery mechanism correctly, it actually
> >should work just fine in the scenario you describe above. For it to
> >work, you would not set the org.apach
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/25/2004 06:25:51
PM:
> On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> > In my last message, I failed to emphasize the brittleness of the
> > "break into interfaces" hypothesis. Even if at a high-level of
> > abstraction two API
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/22/2004 04:53:49 AM:
> JCL shows indications of mission creep. I believe this to be a factual
> observation independent of ASF representation.
Just to help clarify your concern, would you please define "mission
creep".
> >(conversely, if you do thin
news <[EMAIL PROTECTED]> wrote on 12/21/2004 02:01:07 PM:
> > And yes, I'm leaning towards EXPLICITLY naming methods to encourage
best
> > practices. To use the distinction made by Curt, I'm pushing the trace
> > level methods towards diagnostic logger function, and stepping away
from
> >
te:
> > On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
>
>
>
> >> We ARE assuming that maintaining SOME SIGNIFICANT compatibility with
> >> the
> >> existing JCL is of paramount importance. We are NOT trying to
> >> standardize
>
news <[EMAIL PROTECTED]> wrote on 12/21/2004 08:04:09 AM:
> robert burrell donkin wrote:
> > On 18 Dec 2004, at 23:07, Scott Deboy wrote:
> >
> >> Enter and exit should not be defined as severities. This is useful
> >> information, but orthogonal to a logging event's severity attribute.
>
> Go
[mutters something about keeping OUR troups in line..]
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/20/2004 04:03:28 PM:
> On 18 Dec 2004, at 20:52, Curt Arnold wrote:
> > On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
>
>
>
> >>> That a si
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/20/2004 02:51:17 PM:
> > ... how do you propose to reconcile this "pluggable" mechanism
> > with the underlying logger that DOES accept "MSGID" and Object[]
> > directly?
> >
> > I'm of the opinion that IF a reasonable proposal can be prod
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/18/2004 03:19:41 PM:
>
> On Dec 18, 2004, at 2:18 PM, Richard Sitze wrote:
>
> >>
> >> +1. Just because the JDK 1.4 log does this, doesn't mean that we
have
> >> to enforce this behavior on all loggin
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/18/2004 02:52:02 PM:
>
> On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote:
> >
> > As you pointed out earlier, much of this depends on how the logger is
> > used. Class category names for code logging, other "ap
Developers of open source components that are expected to be plugged into
different projects simply cannot and should not assume that Log4J, JSR-47,
Avalon, or any other logger IS present. This may severely limit the
logging capabilities that may be used by such components. This is the
price
[forgive me for changing the subject, I'm trying to take steps to try to
help us focus on separate issues]
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 12/17/2004 09:10:34 PM:
> Richard Sitze wrote:
>
> > As a real example, the axis community uses globalized
While acknowledging that while we all orbit the same sun, we also stand in
different time zones and see it differently... :-)
news <[EMAIL PROTECTED]> wrote on 12/18/2004 10:44:11 AM:
> Noel J. Bergman wrote:
> > Simon Kitching wrote:
> >>I've been convinced by the arguments put forward in this
Excellent!
Chris Lambrou <[EMAIL PROTECTED]> wrote on 12/17/2004 04:32:28 PM:
>
> >Someone suggested that for Log, it would be appropriate to make it an
> >abstract class rather than an interface, so we can make these kinds of
> >changes easier in the future. I think the risks for this are lo
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM:
>
> On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
>
> > Good comments, thanks.
> >
> >
> > Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:
> >
> >&
Good comments, thanks.
Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM:
> Sorry to come in on this late. I just read the archives after Ceki
> posted a link on log4j-dev.
>
> First, I agree Enterprise is a poor name. I tend to think in terms of
Ok.. let me make a few points:
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/16/2004 04:38:34 PM:
> >
> > I think this demonstrates a major issue.
> >
> > When using logging in an "enterprise" situation, the logging can be
> > considered a critical part of the application. If you have heavy-duty
> > monitoring system
David Graham <[EMAIL PROTECTED]> wrote on 12/16/2004 11:47:46 AM:
> >
> > The current proposal is:
> >
> > - configuration is always manditory.
>
> Doesn't mandatory configuration relieve us from needing to split
> commons-logging.jar into several pieces? I like the fact that I don't
> have
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 10:18:44
PM:
> On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote:
> > Simon Kitching wrote:
> > > I think this demonstrates a major issue.
> > >
> > > When using logging in an "enterprise" situation, the logging can be
> > > considered a crit
Just for the record, the primary issue is NOT inability to locate a
logger. It's not finding the "expected" logger [from the developer/users
perspective], and silently falling back to an "alternate" logger.
***
Richard A. Sitze
IBM WebSphere WebServices
***
Richard A. Sitze
IBM WebSphere WebServices Development
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 06:23:35
PM:
> On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
> > "Henning P. Schmiedehausen" <[EMAIL PRO
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004
03:06:41 PM:
> robert burrell donkin <[EMAIL PROTECTED]> writes:
>
> >the passivity is a symptom of commons logging being too big, too
> >complex and too tightly coupled to the needs of applications run in
> >containers and ye
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/15/2004 01:44:47 PM:
> On 11 Dec 2004, at 02:24, Noel J. Bergman wrote:
>
> > It disturbs me that what seems to me to be a reasonable and small set
> > of
> > requirements --- along with what appears to have been considerable
> > forethought
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/15/2004 01:39:57 PM:
> On 10 Dec 2004, at 01:42, Charles Daniels wrote:
>
> > 8<
>
> 8<
>
> >> Regardless of the performance, though, there is still the matter of
> >> exactly where the messagekey+params gets converted to a
> >> message str
Glad you made it Robert, was starting to feel that this was getting
snubbed by the core logging advocates ;-)!
robert burrell donkin <[EMAIL PROTECTED]> wrote on
12/15/2004 01:39:12 PM:
>
> On 10 Dec 2004, at 00:40, David Graham wrote:
>
> >
> > --- simon <[EMAIL PROTECTED]> wrote:
> >
> >
your application integrates components that use JCL
[Jakarta Commons Logging], then bind JCL to Log4J in your hosting
environment, and you are ready to move forward.
>
>
> Richard Sitze wrote:
>
> >Now, were does the *component* developer 'place' this content?
Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004
02:26:41 PM:
>
> >>Then calling code that wants to make use of localized logging would
make
> >>
> >>
> >>this call:
> >>
> >>private static final LocalizedLog log = (LocalizedLog)
> >>LogFactory.getLog(MyClass.class);
> >>
> >>
> >
> >N
Will move the discussion back to your proposal.
Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/12/2004
02:58:38 PM:
> To support localized log messages, we only need to introduce one
> *optional* interface that will *not* affect any existing functionality.
>
> interface LocalizedLog extends Lo
[ ] +0 I support this API proposal but am unable to help
> [ ] -0 I do not support this API proposal
> [ ] -1 I do not support this API proposal, and here are my reasons
>
>
> Matt
>
> Richard Sitze wrote:
This is probably only worth saying one time, so please take this as
informational, and not as argumentative.
First, the term we use is - in the end - of no real concern to us. We
have a functional requirement. Would be nice if the term was meaningful.
That said, I believe "enterprise" is mean
Interesting point Simon.. more below
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/10/2004 10:57:47
PM:
> Hi Richard,
>
> The class javadoc for the EnterpriseLog class states:
>
> Please note that a specific implementation of Commons Logging can choose
> to support either the simple logging i
Good points. Please consider:
a. There are logging implementations today, I believe, that can accept
this information.
b. Consider AspectJ as an enabler of such methods, as opposed to an
alternative.
c. I'm not fluent in AspectJ terminology, so forgive any mistakes... but
I see this as an
"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/10/2004
04:34:07 AM:
> Richard Sitze <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> >B.2. Fix fragile configuration problems - Currently
> > the user has NO idea which impl is in
We don't globalize trace level messaging [debug, entry/exit, trace]
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/09/2004 07:23:54
PM:
> On Fri, 2004-12-10 at 13:20, Charles Daniels wrote:
> > > -Original Message-
> > > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
> > > Sent: Thursda
"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 07:42:47 PM:
> 8<
>
> > >
> > > Since all of the logging methods (fatal, error, etc.)
> > accept a message
> > > of type Object, you could support i18n/l10n by doing
> > something like the
> > > following:
> > >
> > > log.warn(new Mess
"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 06:20:14 PM:
> > -Original Message-
> > From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 09, 2004 4:54 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [logging] Enterprise Common Logging... da
Huh... is this where I hide in the corner and pretend that I didn't write
that section of the user's guide?
"Charles Daniels" <[EMAIL PROTECTED]> wrote on 12/09/2004 05:20:24 PM:
> Further, the JCL User Guide has a section labeled "National Language
> Support And Internationalization", in whi
The discovery process is a concern. It's not trivial. It only gets worse
over time. Enough said.
To be quite frank, here is what I believe to be the right strategy
1. Implement a "workable" discovery mechanism where it belongs... in
Commons Discovery.
2. Have the existing LogFactory attem
Good point. Which is why we elected to begin our proposal as an extension
to the existing Log interface, rather than making any immediate
adaptations to it. Any component based on the the existing interface [JCL
1.0.X] will be able to execute with JCL 2. Likewise, component developers
make c
ring messageName, LogMessage logMessage);
> Log message class could have similar attributes as the ErrorMessage
class.
> Regards,
> Daniel
>
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> >
[mailto:[EMAIL PROTECTED]
> > Im Auftrag von Ri
package org.apache.commons.logging;
/**
* An advanced logging interface abstracting logging APIs. This
interface
* extends the simple logging interface decribed by [EMAIL PROTECTED] Log},
providing
* the following additional capabilities:
*
* the ability to capture internationalized data
[Looks like the attachments got lost... Let's try them separately]
package org.apache.commons.logging;
/**
* Factory for creating [EMAIL PROTECTED] Log} and [EMAIL PROTECTED]
EnterpriseLog}
instances,
* with discovery and configuration features similar to that employed by
* standard Jav
IBM would like to open a discussion within the Jakarta commons community
on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise
level logging functionality. We recognize the value that a "logging
implementation independent API" brings to open source component
development, an
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
Project State : 'Success'
Full details
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project commons-discovery *no longer* has an issue.
Project State : 'Prerequisite Failed', R
:
was Richard Sitze/Austin/IBM
received
by
So, I'm coming into this a bit late and all, and I know a few others have
been looking at this over the past few weeks... hope this does more than
just add fuel to the fire.
commons-discovery was created to address the classloader usage patterns
being discussed : how to discover an implementio
Hence the need to maintain commons-logging.jar AS-IS.
We already HAVE commons-logging-api.jar, we simply need to add new jar
files for each implementation 'flavor'. Consideration could be given to
including a commons-logging.properties file that configures the logger,
though there are pro/cons
, 2003, at 05:41 PM, Richard Sitze wrote:
> [OK, Let's try the more formal VOTE subject line :-) Sorry for the
> duplicate note.]
>
> commons-discovery has been fairly stable for a while (one recent bug
fix,
> and a few in the past), and I'd like to cut a 0.2 release
+1
***
Richard A. Sitze
IBM WebSphere WebServices Development
Commons-logging has recently undergone some bug fixes, documentation
cleanup, and the addition of additional unit test suites to simulate its
use within servlet containers and other environment
[OK, Let's try the more formal VOTE subject line :-) Sorry for the
duplicate note.]
commons-discovery has been fairly stable for a while (one recent bug fix,
and a few in the past), and I'd like to cut a 0.2 release.
Please VOTE for or against.
POSITION: There has not been
Discovery has been very stable for a while now, with a few bug fixes
It's a prereq for at least one project (Axis) that is getting ready to cut
a new release.
I'd like to ask for a vote to cut a 0.2 release,
and a volunteer with sufficient karma to help me out. I'd be happy to do
what bu
Summary: +1 on all issues
> Folks,
>
> A lot of people are interested in an updated release of commons-logging
> that incorporates post-1.0.2 bugfixes. In order to do so, we need to
> address the following outstanding bug reports -- I've described my own
> recommendations on dealing with them in
I think some work was done to alleviate the 'forced' Log4J... are you
using a released build, or a nightly build? If the first, try a
nightly... if it still happens (re)open a bugzilla bug report.
***
Richard A. Sitze
IBM WebSphere WebServices Developmen
I'm partially responsible for the current classloading scheme. I'd sure
like to understand what your problems are. Can you describe a
step-by-step scenario that demonstrates what you see happening, and why
you think it's not correct?
Likewise, for any code changes that you make, please help m
I'll wait for the formal call to vote before I start voting, BUT I support
the following:
+ release a 1.0.3 before any major code changes
+ JNDI
- NO API changes
- NO new runtime dependencies, and I'd like to be able to build, even if
I cannot test it.
***
I like playing in the sandbox, I just don't like to be unpleasantly
surprised on what I find buried within. I can see both sides, but it does
appear to be IMPERATIVE that the catbox... err sandbox be kept clean for
visitors.
We simply cannot become, or even appear to become, a public reposito
To locate a service (based on sun's current mechanism) we can drop a file
whose name is the service interface and content is the name of the
implementation:
META-INF/services/package.ServiceName:
implPackage.ServiceNameImpl
One 'scheme' for locating a service is have the impleme
Please open a defect in Bugzilla for this.
***
Richard A. Sitze
IBM WebSphere WebServices Development
Hi,
This issue has already been raised long time back under the subject
"Support for JDK1.4 Logger in Commons Package". It was told that time that
it
The Commons team is proud to announce a release of Commons Logging 1.0.2.
This release introduces bug fixes for various NullPointerExceptions, and
Security Exceptions in J2EE environments.
Binary/Source:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1.0.2
Additiona
o help him with.
>
> Scott
>
>> -Original Message-
>> From: robert burrell donkin
>> [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, September 26, 2002 4:05 AM
>> To: Jakarta Commons Developers List
>> Subject: Re: [logging] VOTE for cutting releas
I volunteer to be the release manager.
This is also my explicit vote for cutting 1.0.2: +1
By my count, current binding votes are at:
+12 (scott sanders, richard sitze)
+00
-10
***
Richard A. Sitze
IBM WebSphere WebServices Development
l, one ring to find them..."
> -Original Message-
> From: Richard Sitze [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 25, 2002 10:43 AM
> To: [EMAIL PROTECTED]
> Subject: [logging] VOTE for cutting release 1.0.2
>
>
> There were some changes that went into
This does not appear to be a discovery error.
That said, there are a few NPE exception in commons-logging 1.0.1. And
these were fixed. Please a recent nightly build and see if that corrects
this problem.
***
Richard A. Sitze
IBM WebSphere WebServices D
Have you taken a look at how Eclipse handles this?
http://eclipse.org
***
Richard A. Sitze
IBM WebSphere WebServices Development
Following some interesting discussions on the Maven list, I'd like to
propose starting an SCM abstraction project, tentative
pers List"
On Thu, 6 Jun 2002, Richard Sitze wrote:
> I'm new this part of the game (classloaders), but I'm becoming more and
> more aware of the issues. So, I'd like to add to your question some
bigger
> issues surrounding the placement of commons-logging &am
1 - 100 of 117 matches
Mail list logo