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
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
+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 stage
It means a fix will be made available as part of the next phase.
ras
***
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:
Anyway,
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
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,
Sorry
Ceki Gülcü [EMAIL PROTECTED] wrote on 02/07/2005 01:32:26 PM:
snip
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
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.
anyone
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.
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/loadable by Parent.
- Child is the thread context
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:
The problem: it won't work if commons-logging.jar is installed
[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
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.
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 check
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
Phil Steitz [EMAIL PROTECTED] wrote on 01/24/2005 05:25:09 PM:
snip/
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 quickly
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:
+1, I agree with you and Ceki. TRACE is debatable (I personally
like it), more than TRACE
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
information that can help you identify
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 enter and
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(),
with
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 }, Entering);
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 }, Entering);
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 propose
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 directed to
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, you
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 default
logger.
The warning will be visible
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
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.org
Subject:
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, Charles Daniels wrote:
If I understand the JCL
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 APIs perform
Ceki Gülcü [EMAIL PROTECTED] wrote on 12/22/2004 04:53:49 AM:
snip/
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 think
robert burrell donkin [EMAIL PROTECTED] wrote on
12/20/2004 02:51:17 PM:
snip/
... 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 produced, then
[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:
snip
That a single log request can be rendered for more than
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.
Good point. I
, 2004, at 12:24 PM, Richard Sitze wrote:
snip
We ARE assuming that maintaining SOME SIGNIFICANT compatibility with
the
existing JCL is of paramount importance. We are NOT trying to
standardize
on some other API within the industry, but rather to evolve an
existing
standard
news [EMAIL PROTECTED] wrote on 12/21/2004 02:01:07 PM:
snip/
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
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 application
category
logger names for the other
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 logging implementations. Why not
just
leave it generic
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:
Sorry to come in on this late. I just read the archives after Ceki
posted
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 low, and
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 thread
[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 messages.
A lot of products do, as I
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
***
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 PROTECTED] wrote on 12/15/2004
...byte
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
David Graham [EMAIL PROTECTED] wrote on 12/16/2004 11:47:46 AM:
snip/
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 to
robert burrell donkin [EMAIL PROTECTED] wrote on
12/16/2004 04:38:34 PM:
snip/
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 systems watching
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:
-
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:
snip
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 string.
Having a
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 based upon
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 yet not
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? I claim
we
need a standard approach for this, based on the 'resource bundle name'
parameters
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
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 Log {
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
do not support this API proposal, and here are my reasons
Matt
Richard Sitze wrote:
Interesting point Simon.. more below
Simon Kitching [EMAIL PROTECTED] wrote on 12/10/2004
10:57:47
PM:
Hi Richard
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);
Not sufficient.
a) Leaving the
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 effect.
All the default/fall back behavior means
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
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, and
[Looks like the attachments got lost... Let's try them separately]
package org.apache.commons.logging;
/**
* pFactory for creating [EMAIL PROTECTED] Log} and [EMAIL PROTECTED]
EnterpriseLog}
instances,
* with discovery and configuration features similar to that employed by
* standard
package org.apache.commons.logging;
/**
* pAn advanced logging interface abstracting logging APIs. This
interface
* extends the simple logging interface decribed by [EMAIL PROTECTED] Log},
providing
* the following additional capabilities:/p
* ul
* lithe ability to capture
attributes as the ErrorMessage
class.
Regards,
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Im Auftrag von Richard Sitze
Gesendet: Donnerstag, 9. Dezember 2004 21:21
An: [EMAIL PROTECTED]
Betreff: [logging] Enterprise Common Logging... dare we
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
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
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:
snip
Further, the JCL User Guide has a section labeled National Language
Support And Internationalization, in which
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... dare we say
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 Message(key, params));
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: Thursday, December
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
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
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
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
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',
:
was Richard Sitze/Austin/IBM
received
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
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
+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
, 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.
Please VOTE for or against
[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
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
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
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.
ras
***
Richard A. Sitze
IBM WebSphere WebServices
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
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.
ras
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
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
Please open a defect in Bugzilla for this.
ras
***
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
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
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
-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 release 1.0.2
On Wednesday, September 25, 2002, at 11:07 PM, Richard Sitze wrote:
snip
4
=103057245722889w=
2
I assume this is a valid reason for a -1 vote. If not, someone please
correct me (like I really need to say that :) )
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one ring to find them...
-Original Message-
From: Richard
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
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,
to Jakarta
Commons
Developers 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
+1
***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability WebServices
IBM WebSphere Development
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 other apache
utility/libraries in web application servers:
1. How do we find overload
testing my mail protocols.
***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability WebServices
IBM WebSphere Development
1 - 100 of 112 matches
Mail list logo
