On 2/20/06, Simon Kitching [EMAIL PROTECTED] wrote:
Standalone applications, applets, embedded systems would use a
lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL stuff,
no dynamic discovery stuff, only one logging adapter.
Webapps that want to use a specific logging lib
On 2/21/06, robert burrell donkin [EMAIL PROTECTED] wrote:
i've been running some performance tests: the aim being to check how
much slower JCL 1.1 runs that the 1.0.x releases. the figures for log4j
are interesting. the raw data is below (the percentages are normalised
to 1.0.4 benchmark
I am not very enthusiastic (from the container perspective). Let's see:
- Static discovery may look nice to some, but given the most likely
class overloading rules, it means the whole container and its
applications would use a single logging framework (which is ok in many
cases, though). So IMO
On 12/13/05, David Smiley [EMAIL PROTECTED] wrote:
Last I recall, the HTTPClient team abandoned the idea of an NIO based
HTTPClient implementation since testing that Oleg did turned up poor
results.
I happened upon some information today which may cause the HTTPClient
team to rethink this:
On Apr 1, 2005 3:53 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Remy Maucherat wrote:
I´d assumed that the information about JULI here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html
meant that use of JCL was obsolete. Sorry if I misunderstood.
If tomcat had really chosen
On Sat, 26 Mar 2005 11:19:56 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
This is a puzzling comment to me. What is the basis of the statement
that nearly everyone uses Commons Logging? No project that I have
ever worked on (outside the ASF) has ever used Commons Logging. They
have all used
On Sat, 26 Mar 2005 17:23:43 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote:
Remy wrote:
My plan for JULI is to:
What is JULI? I know JCL, UGLI, Log4J, j.u.logging ... hmmm ... is JULI an
acronym for j.u.l-integration?
JULI is a java.util.logging implementation. It currently lives here:
On Sun, 27 Mar 2005 20:21:04 +0200, Simon Kitching [EMAIL PROTECTED] wrote:
There really is no reason for an application to use JCL. I´m personally
surprised that Tomcat chose to do so for its internal logging, and
pleased to see that the next version is moving away from it.
That's news to me.
On Sun, 27 Mar 2005 20:31:19 +0200, Simon Kitching [EMAIL PROTECTED] wrote:
What happens when multiple independent webapps use j.u.logging?
Can each webapp have its own personal logging configuration file?
And if so, is logging correctly cleaned up when the webapp is undeployed?
Yes, it should
On Sat, 26 Mar 2005 16:57:02 +0100, Ceki Gülcü [EMAIL PROTECTED] wrote:
On 2005-03-24 23:50:45, Remy Maucherat said,
It doesn't make any sense for log4j.next to adopt java.util.logging
API. As for the claim that java.util.logging is the only realistic
standard forward, it should be clear
On Fri, 25 Mar 2005 09:16:31 +0100 (MET), Boris Unckel
[EMAIL PROTECTED] wrote:
Hello Remy,
This is not the intention of Yoav. To quote the discussion[1] as summary.
This Get rid of the we vs them and create a we atmosphere. - Niclas
Hedhman last mail in log4j-developers in that thread.
On Fri, 25 Mar 2005 13:33:47 +, robert burrell donkin
[EMAIL PROTECTED] wrote:
i also understand remy's point: backwards compatibility is very
important. it is JCL's huge installation base that gives momentum. many
users will review the choice of logging system altogether when faced
with a
On Fri, 25 Mar 2005 09:29:41 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
On Fri, 25 Mar 2005 15:11:53 +0100, Remy Maucherat
[EMAIL PROTECTED] wrote:
That's fine, and thanks for all the hard work. c-l works well enough
in Tomcat right now, so no more updates are actually needed
On Thu, 24 Mar 2005 14:37:28 -0500, Yoav Shapira [EMAIL PROTECTED] wrote:
Hi,
Over on the log4j mailing list, we've been discussing an interesting idea
for the next-generation commons-logging-type component, and wanted to run
the idea by the commons-dev crew for feedback. This is just
On Sat, 26 Feb 2005 19:41:05 +, robert burrell donkin
[EMAIL PROTECTED] wrote:
[X] +1 Promote RC1 to commons-logging-1.0.5-alpha1
[ ] +0 In favour of this release
[ ] -0 Against this release
[ ] -1 Do not release RC1
Rémy
On Tue, 15 Feb 2005 21:02:28 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Tue, 15 Feb 2005 22:50:51 -0600, Vic [EMAIL PROTECTED] wrote:
oops :-[
Wrong link, this is it:
http://www.szegedi.org/articles/memleak.html
It talks about Commons logging, since i'ts open season.
.V
Bill Culp wrote:
Your attachment did not come through. Could you give me an example of
the 'negative content'?
This thing seems to be a virus targetted at the users of ASF products.
Please ignore it. I have sent a request to apmail already to block these.
Rémy
. This base
* implementation lookups properties in the system properties.
*
* @author Remy Maucherat
* @version $Revision: 1.14 $ $Date: 2003/10/09 21:09:46 $
*/
public class PropertySource {
public String getProperty(String key) {
return System.getProperty(key);
}
}
Index: src
Remy Maucherat wrote:
Hi,
I described the feature a couple weeks ago, and here's my patch.
It currently only replaces attributes processed by the setProperties
rule. This did sound good enough to me. I read about processing text
nodes too (does Ant do this also ?), so maybe we can improve
Will Jaynes wrote:
Well, I submitted this as a bug and included a patch. But Remy
immediately marked it as RESOLVED/WONTFIX. He doesn't really address my
suggestion other than to say that c-l if used properly ... is well
thought out, and works perfectly well I would never suggest that c-l is
Hi,
I'd like to add a feature to the digester, allowing property
replacement, similar to Ant. Basically, ${...} in an attribute value
would get replaced by a property value.
The following elements would be added:
* PropertySource interface, containing a String getProperty(String key)
method
Could that kind of feature be added to procrun and jsvc ? I think it
would be useful.
http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Dirk Verbeeck wrote:
I'd like to propose a vote on the following release plan
for DBCP 2.0. This release plan can also be found
at:
http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt
Per the Jakarta/ASF guidelines (see
http://jakarta.apache.org/site/decisions.html),
Dirk Verbeeck wrote:
OK, I don't expect any problem.
New proposal:
Review: 1 October 2003 - 15 October 2003
Do you plan to release an alpha or a beta at the start of the review
period ? That would be really useful :)
(I'd include the binary with a new TC 5 beta to get wide real world testing)
Mladen Turk wrote:
Hi,
When the daemon changed location from sandbox my karma has been lost.
I'll need it for jakarta-commons/daemon.
+1.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Dirk Verbeeck wrote:
The last release of DBCP pool is almost a year old now. A new one is
long overdue.
Bugzilla has Zarro Boogs found and the threading changes are now
already a month in the nightly builds with no error reports.
There are always more enhancements to be done (logging,
Shapira, Yoav wrote:
Howdy,
I'd like to nominate I would like to propose Jean-Frederic Clere
([EMAIL PROTECTED]) as a new commons committer. He's already a
committer for tomcat, tomcat connectors, commons-sandbox, and other
modules, and I need his help on commons-daemon ;)
[X] +1, let him
Jan Luehe wrote:
Please see
http://cvs.apache.org/~luehe/commons-el-1.0_RC1
for the release candidate deliverables.
+1
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FileUpload.setRepositoryPath(String) and FileItem(String) were removed
from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and
5.0.x build. The first method has no apparent replacement (but I didn't
try to dig around).
This is clearly an unacceptable situation from the Tomcat
I would like to nominate Sean Sullivan as a committer for the Jakarta
Commons project. Sean has been active in providing patches and support
the
HttpClient project over the last several months and I think he would be a
good addition to the community.
+1.
Remy
--
To unsubscribe, e-mail:
I can post the patch to the list, or if someone wants to grant me
karma for jakarta-commons I can just commit it to CVS.
+1 for giving you karma.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-- Cut Here --
Vote to promote the modeler package from Sandbox to Commons proper
[X] +1 I am in favor of this action and will help
[ ] +0 I am in favor of this action but cannot help
[ ] -0 I am not in favor of this action
[ ] -1 I am opposed to this action and here is why:
Hi,
I would like to propose a new common component, based on code used
in tomcat, avalon and other java servers to work as NT services and unix
daemons.
The initial code is based on the wrapper project at sourceforge,
and will replace ( and be merged with ) the other components
that
+1
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
OK,
I've discovered why I'm not seeing the body as the result of the PUT,
it's a feature of HttpClient.
Tomcat is sending me the following response
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: 132
Content-Type: text/xml
Date: Thu, 21 Feb 2002 13:21:35 GMT
Content-Length: 132
I just spotted the daemon project in CVS and wondered if there was any
intention of implementing JSR 96
http://jcp.org/jsr/detail/96.jsp
Also I wonder if JSR 96 will release an open source reference
implementation?
I was, but now it's not.
But of course, we could still decide later to
BTW have you seen the Java Service Wrapper?
http://wrapper.sourceforge.net/doc/english/index.html
I've not looked too deep yet at all 3 of these but its on my radar -
I'd
be
interested in any comments folk have on the pros cons of the above.
The Java API does the same,
I'd like to propose Marc Saegesser as a committer on HttpClient. Mark
has posted some great functional patches for HttpClient in the last week
and is an active user with great ideas for taking it forward.
Also, most of the 'usual' HttpClient committers are also busy with other
projects,
Hi,
I've added a new component to the commons subproject (in the sandbox), which
is designed to allow Java programs to run as native operating system daemons
(services under Windows NT).
Because of its nature, this component contains a significant amount of
native code.
This component API and
Please excuse this really long post, but there's a lot to cover.
First, let me introduce myself. My name is Marc Saegeser and I've been a
committer on the Jakarta-Tomcat project for over a year. I was the
release
manager for the Tomcat 3.2.2-3.2.4 releases. I'm not currently a
committer
Just 2 comments:
- I understand the use of the sentinel but in the very fast glance I
took at the code I still did not understand a couple of bits of
code related to it. Since it was a very fast glance, it is very
probable that everything is ok and that I just didn't get it yet.
On Sat, 2 Feb 2002, Peter Donald wrote:
Separate voting rights not commit rights. Only people who show
commitment to
a product should be able to have binding votes on it.
_Using_ a commons component in another jakarta project is a huge
commitment to that component. The rule is there to
On Wed, 30 Jan 2002 19:41, Sam Ruby wrote:
At the time commons was created, Avalon was notorious for changing
interfaces without even so much as a moments notice. The rationalle
given
was that Avalon was still in alpha - interminably so.
And here he goes again. Interesting comment given
- CUT HERE -
[X] +1 I support the release of Commons Logging 1.0 and will help
[ ] +0 I support the release, but cannot help
[ ] -0 I am not in favor of the release
[ ] -1 I am opposed to this release, and here's why (attach reasons)
- CUT HERE -
Remy
--
To
I am still trying to track down where the first Log and LogSource came
from. I tracked it back to httpclient, and I am looking further. Rod,
can you tell me where the Log and LogSource originated from in
httpclient?
Yes, it first appeared in httpclient. I remember it extremely well, since
So that clinches it. The _initial_ HttpClient abstraction was definitely
not informed by Avalon. In fact, we had already packaged Logging as a
separate component by then. (Hey, I guess I wrote the proposal. I should
add myself as a contributor!)
Maybe the Avalon abstraction should have
Remy Maucherat wrote:
So that clinches it. The _initial_ HttpClient abstraction was
definitely
not informed by Avalon. In fact, we had already packaged Logging as a
separate component by then. (Hey, I guess I wrote the proposal. I
should
add myself as a contributor!)
Maybe the Avalon
It is a pity that I missed the start of THIS party but here I go!
A, I'm relieved, I thought you were sick or something.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
On Wed, 30 Jan 2002 09:28, Remy Maucherat wrote:
If we both want to move forward, I think now that you got your quote,
you
should withdraw your -1.
Actually I think if we want to move forward I should add my -1. That way
it
may become even more obvious what an absurd rule allows people
As you can all see, Robert Donkin has submitted many fine patches to
Digester, BeanUtils, Betwixt and others. His work is of high caliber
and I would like to see him as a comitter here at the Commons.
He is a comitter on the ECS project, so he can already play in the
sandbox. I would
50 matches
Mail list logo
