Re: [logging] interesting performance figures

[Remy Maucherat]

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 times).
>
> 1. there is a small performance degradation between the 1.0.3, 1.0.4 and
> 1.1RC5 but not significant (a few percentiles).
> 2. 1.0.2 is a *lot* faster for log4j that the later releases
> 3. isDebugEnabled is a *lot* faster than logging
> 4. getLog is *slow*
>
> i have some ideas for improving performance against log4j (but testing
> them will have to wait till tomorrow).

As long as isDebugEnabled is fast, I'm happy. In most cases, debug
level will mean logging a ton of things, so will be slow (of course,
people have complained that TC was too slow with debug logging). Are
the figures similar with JDK logging ?

--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] JCL2.0 design - Architecture

[Remy Maucherat]

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 would bundle a
> lib-specific jar (of course that only works when child-first
> classloading is selected or the container doesn't provide JCL). [1]
>
> Containers would generally bundle commons-logging-dynamic.jar, and would
> end up with exactly the same functionality that exists now. They *could*
> (as you mention) use a lib-specific implementation if they are happy to
> have every webapp use one logging lib but commons-logging-dynamic would
> be the usual choice.

That's good. I think the ability to prevent webapps from using the
logging they want could be a good feature too.

> As a result, this wouldn't reduce any of the existing complexity for
> JCL-in-containers (except that we can discard code that tries to handle
> embedded systems & java1.1, as those systems can use the lib-specific
> ones). However I hope we've nailed many of the outstanding
> container-based issues in the 1.1 release anyway, which
> LogFactoryDynamic will effectively inherit. This *will* resolve issues
> in non-container environments as those can use the simpler jars.
>
> [1] Hmm..one thing we've discovered is that it's a bad idea to have two
> jars in the classpath providing the Log interface. JCL1.1 provides a
> "commons-logging-adapters.jar" for webapps to use when the container
> provides commons-logging.jar. But the proposed jars I've shown here
> include Log so aren't safe to use from a webapp when any other jcl jar
> is in a shared path. More thought needed :-(

Yes, usually, there are problems with multiple Log definitions.

> > - Please continue providing support for using the TCCL (as the TCCL -
> > or similar - is used in most JNDI impls, doing otherwise is a bit
> > redudant as far as I am concerned, and JNDI access is most likely
> > slower).
>
> I'd be very interested in your opinion about the safety/stability of
> TCCL-based solutions. I was looking at Sun's java bugtracker recently
> and found an issue raised by JBoss stating that they wanted some
> classloader synchronisation code changed as Marc Fleury has been
> experimenting with "dependency-based classloaders that aren't tree
> structured". From the comments it seems like a few other people are
> experimenting with similar approaches. So is it still going to be safe
> in the long run to assume every webapp has a distinct TCCL, and that it
> is possible to walk up the classloader ancestry links to find all
> possible implementations of a particular class?

I was pointing out that TCCL was being used to track the logging
environment. For classloading itself, it's up to you to figure it out
:)

> > - If you're changing the API, I think you should consider using
> > java.util.logging as the facade API to replace the commons-logging 1.0
> > API. While the API exposed might be a bit sub optimal, this would be
> > the most "standard" way from users' perspective. See JULI in Tomcat,
> > and www.x4juli.org for java.util.logging "implementations" (providers
> > may be more accurate), but both are done using the
> > full-logging-implementation way, so maybe not very good examples, as
> > you would want to only develop facades.
>
> I don't quite understand what you mean here.
>
> Are you suggesting that commons-logging-xxx.jar should include our
> implementations of "java.util.logging.*" classes? I don't think that's
> allowed/possible...

I think providing a LogManager and the appropriate facade Loggers, I
don't see why it wouldn't work, but I didn't look that deeply into the
feasability.

> Or are you suggesting that we write an implementation of
> j.u.l.LogManager so that the commons-logging-xxx.jar can be "plugged in"
> as a j.u.l implementation? I had made the assumption that JCL would be
> supporting java versions earlier than 1.4. I guess I should check, but I
> would think that the consensus is that we can't assume 1.4+ for JCL2.x

Well, that works too I guess, you could have one of the facades be a
facade for c-l.

> Or are you suggesting that we model the JCL api on j.u.l so that moving
> between the two is a minor search-and-replace? I agree that j.u.l is
> eventually going to be the standard logging interface (5-10 years away)
> by virtue of it being in the java standard libs. However there is
> significant benefit for the JCL project in keeping changes to the
> existing API small; the major users of JCL2.x will be existing JCL1.x
> users. In addition, much of the j.u.l API is about configuration which
> is something that JCL explicitly doesn't do; it wraps the *logging*
> parts only. JCL also has to be a "least common denominator" API, so
> deliberately leaves out things like a Level class. By the time all those
> things are left out, I don't think the remaind

Re: [logging] JCL2.0 design - Architecture

[Remy Maucherat]

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 you need to keep a working dynamic discovery.
- Please continue providing support for using the TCCL (as the TCCL -
or similar - is used in most JNDI impls, doing otherwise is a bit
redudant as far as I am concerned, and JNDI access is most likely
slower).
- If you're changing the API, I think you should consider using
java.util.logging as the facade API to replace the commons-logging 1.0
API. While the API exposed might be a bit sub optimal, this would be
the most "standard" way from users' perspective. See JULI in Tomcat,
and www.x4juli.org for java.util.logging "implementations" (providers
may be more accurate), but both are done using the
full-logging-implementation way, so maybe not very good examples, as
you would want to only develop facades.

--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Don't count out NIO just yet; check out "Grizzly"

[Remy Maucherat]

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:
> http://weblogs.java.net/blog/jfarcand/archive/2005/06/
> grizzly_an_http.html
> It's a blog about "Grizzly", an HTTP Listener using NIO for GlassFish.
> It's worth reading all of it.

I have found the Grizzly benchmarks that have been published to be
bogus (or at least to be valid for very specific workloads, and having
bad behavior for many others).

If you want high scalability without compromising raw performance, I
recommend you use the APR connectors (AJP or HTTP) that are included
in Tomcat 5.5.14 (actually in 5.5.12+, but bugs have been fixed).

--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 to move away from JCL (or at least removed
> commons-logging-api.jar from the shared classpath) that would certainly
> have made life easier for the commons-logging maintainers, as the
> presence of jcl in the shared classpath is the root cause of the main
> problems experienced by jcl users.

This does not make sense to me. It actually prevents classloading
issues, and does not introduce problems as long as you can read the
documentation.

> I agree that none of these are critical, and code can be written
> satisfactorily without any of these features; tomcat is living proof of
> that. But the fact remains that these features are not in JCL because
> JCL is a "least common denominator" API; *some* logging implementations
> don´t provide these, so JCL can´t.

Feel free to write your own logging API, then, with whatever gimmicks
you need. It does not matter to me, as unlike c-l, java.util.logging,
and log4j, I can safely ignore it ;)

> > JFluid didn't ever show logging as an issue, so it does not matter to me.
> 
> It does depend upon usage patterns. My particular concern is that
> "isDebugEnabled" is a very carefully optimised operation in log4j.
> Calling it via JCL at least doubles the time taken. And similarly for
> getLog("foo"). Agreed, that does only matter if such calls are inside
> very tight loops which is probably not good practice anyway.

Unless you can provide hard numbers ...
You apparently have never profiled Tomcat or any similar container
(suggesting it is a good idea, on any logging framework, to call
getLogger inside your app's critical path is quite funny). As I said,
there are not enough calls like that in the critical path to make it
relevant in any way.

> > I don't think Tomcat has a buisiness deciding which logger people
> > should use, just the same as for your libraries.
> 
> Well, libraries *cannot* make such assumptions. Application writers can
> decide which side of the JCL vs concrete-logging tradeoff they want to
> choose.

You mean library have a business deciding which logger people should use ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 work ok. At the moment, it simply uses a weak hashmap,
which I think should be enough.

> > We'll see how well this works soon, as it is used to provide logging
> > defaults in the new Tomcat build (the previous defaults were using
> > java.util.logging as well, but with the default implementations, and
> > consequently didn't do anything useful).
> 
> I´ll just point out there are two quite independent logging concepts
> here: logging of internal container details, and logging by webapp code.
> 
> I´m quite sure you can use j.u.logging for Tomcat´s internal logging.

No, I can't, the configuration is too restrictive, etc. That's what we
were doing by default in previous Tomcat 5.5 releases.

> Have you also looked into the issues relating to what happens when a
> webapp uses j.u.logging API to log messages (or when some library that
> app depends upon does so)?

I'd recomend you look at it. Why do you think it would cause problems ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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.

> JCL is great for libraries, where the code *cannot* make any assumptions
> about what logging library is available. However there is a significant
> price to pay for using JCL:
>   * a "least common denominator API", and

We have never needed anything more.

>   * a significant performance hit.

JFluid didn't ever show logging as an issue, so it does not matter to me.

> Application code which can make assumptions about what logging library
> it will be bundled with should generally code directly to that logging
> libraries´API. The app then gets a more complete API and better
> performance. [1]
> 
> And libraries which provide fairly simple functionality don´t need
> logging at all; they can report problems via exceptions.
> 
> But for libraries that are complex enough to need logging, but can´t
> assume a particular logging implementation, what options are there other
> than commons logging (or UGLI once it is released)? I would really be
> interested to know! Hard-wiring the use of log4j into such a library
> isn´t an option for obvious reasons.
> 
> Please note that the above is just my personal view..

I don't think Tomcat has a buisiness deciding which logger people
should use, just the same as for your libraries.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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:
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/juli/

I think the API, java.util.logging, got many things right:
- the API functionality itself seems good enough to me
- it has a design making it easy to extend once you figure out the API
(no docs), since you simply have to replace the main LogManager
- it is extremely robust in a container environment (one-per-VM
singleton design for the LogManager, and the core classes are hard to
replace: this means classloading problems are almost impossible)
- really usified configuration (being in the boot classloader, any of
the VM own logging will go to it)
- security (it uses the security manager all over the place)
- handlers are simple

JULI would provide:
- LogManager implementations targetted at various containers (I am
interested in Tomcat at the moment)
- various handlers (many can be ported from existing log4j appenders)

I am certain that no API is perfect, and that java.util.logging does
have its flaws, but from a container perspective, it got some
important points right.

We'll see how well this works soon, as it is used to provide logging
defaults in the new Tomcat build (the previous defaults were using
java.util.logging as well, but with the default implementations, and
consequently didn't do anything useful).

> > Is there any pace for this in the logging project, or should I
> > seek another home ?
> 
> If not in Logging, perhaps in Jakarta Commons?  It appears that we have
> several folks trying to move JCL to the next level, and both you and Richard
> Sitze ahould have considerable common ground in terms of needs.

I do consider commons, but commons does this funny things to your
package names, and it's a bit annoying ;) Also, I am a bit confused
about the logging project scope. Does it want to host logging related
projects or not ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 Log4j because of its feature set. I really don't think
> I'm a part of a small minority here either.

I don't think you're part of a minority: I was talking about
middleware and/or containers. It makes sense that people writing
applications would not care at all.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 to any moderately astute observer
> that bundling an API with the JDK is not enough to create a standard.

Heard of the JCP and its standards ? I also heard Apache was an active
contributor to it, and kinda influential too, these days.

> Remy, there is more to logging than what meets your eye as a Tomcat
> developer. I am confident that by continuing to carefully listen to
> your (Tomcat) constituency, you will eventually change your mind.

This is sticking your head in the sand ...

The only thing logical is that there's actually no value in the API
log4j provides to applications: most of them will only use a
featureset equivalent to what commons-logging exposes (as proven by
the fact that nearly everyone uses commons-logging at the moment). I
think your decision of not supporting java.util.logging at any cost is
clearly the root of all the gripes.

My plan for JULI is to:
- write LogManagers tuned to a variety of containers (starting with
Tomcat, and maybe JBoss later)
- port log4j appenders as java.util.logging handlers (this should be quite easy)
Is there any pace for this in the logging project, or should I seek
another home ? The project is definitely much smaller than a standard
project, more like a commons component.

> In other words, don't listen to what LS people have to say, only
> listen to what Tomcat users say.

The idea is that I listened to no one in this case, and made up my own
completely independent decision. My current Tomcat implementation of a
LogManager seems to work very well.
Who are "LS people" anyway ?

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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
> > (especially non backwards compatible updates ;) ).
> 
> Out of dumb interest, what's the need for JCL in Tomcat? Tomcat 5.x is
> JDK 5.x only isn't it, so couldn't it be using java.util.logging?

Because we don't have a good enough java.util.logging implementation.
The default implementation in the JDK is jsut bad, so no matter what
people have to be able to use log4j. I added a container friendly one
last week, to be used in the upcoming 5.5.9 to provide decent
defaults, but it is likely not very mature, and it's missing handlers
(= appenders).

Even if it was ready, there's a benefit of being able to configure
logging server wide (this include applications) in one place. This
works, with log4j, only if everything uses either commons-logging or
log4j. So nothing is going to change overnight.

BTW, we do require JDK 1.4, and package for JDK 5.0 (JDK 5.0 is not required).

> Much of Commons needs JCL to support JDK 1.2 clients, but I'd have
> thought you only have that problem in Tomcat 3 and 4 maintenance
> branches? Unless the idea is just to support users who might want to
> use log4j.
> 
> I've still been using log4j, so is it due to java.util.logging being too weak?

Yes, the default implementation is only good enough for simple client
side applications. The problem however, is that people are writing
articles comaring this crappy default impl to log4j.

> My main complaint is that I have to have a String to create a Logger,
> rather than log4j which lets me use a Class so I suspect I've not felt
> the java.util.logging pain yet.

What's the actual use of getLogger(clazz) ? All it actually does is
getLogger(clazz.getName()).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 binary incompatible upgrade and (i suspect) many will (like remy)
> choose java.util.logging. i think that a measure of backwards
> compatibility is necessary for adoption.

Yes definitely. If I am forced to adopt a different logging API for
development, as the work will be on JDK 1.4, it will be
java.util.logging. Having written a custom impl of java.util.logging,
I can now assert that, given the right implementation of LogManager,
it is powerful enough.

BTW, assuming the logging project is now open and friendly enough, is
there room for such a project there ?

> personally speaking, i find working on JCL a difficult and often
> thankless task. i'd be grateful if logging offered to take away all my
> JCL pain. however, i do feel an obligation to downstream users (such as
> remy). i feel duty bound to act in their best interests. i am
> unconvinced that simply renaming UGLI to JCL2 would be in their best
> interests (or indeed anyone's) but (as i said previously) the JCL
> developers are not in any real position to either help or hinder any
> move to rebrand UGLI.

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
(especially non backwards compatible updates ;) ).

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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.

This is, as I mentioned, a personal note, which obviously you may
disagree on. For the rest, I took the opportunity to express my
opinion since I was asked.

As for the rest, the plan presented does not satisfy me, for the reasons stated.

What I would actually like is a log4j 2.0 revolution, which would use
java.util.logging as the logging API exposed to applications.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2

[Remy Maucherat]

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 informal at
> this point, soliciting opinions.
> 
> First, as background:
> 
> -  Jakarta Commons Logging (JCL) has some problems, as discussed in
> http://www.qos.ch/logging/classloader.jsp and
> http://marc.theaimsgroup.com/?t=11078097261
>  &r=1&w=2 among
> many other problems.
> 
> -  The log4j team has developed UGLI
> (http://logging.apache.org/log4j/docs/ugli.html) to solve these problems,
> following a good amount of thought and discussion
> 
> -  UGLI is new and very few people know about it, while JCL is very
> familiar and widely used
> 
> I (personally, not speaking for the entire log4j team here) think it would
> be a lot easier for UGLI to be adopted if it is essentially called JCL 2.0
> or better yet, commons-logging 2.0 (CL2), taking advantage of that brand
> name instead of throwing a completely new and unfamiliar, "yet another
> logging interface" to the users.  So I wanted to ask: what would the commons
> development community, especially those working on commons-logging, think
> of:
> 
> -  Move the commons-logging project out of jakarta, into its own
> project in Logging Services
> 
> -  Proactively cooperate with the log4j team, commons-logging team,
> and other interesting parties (e.g. Tomcat, so I'm wearing about three
> different hats when writing this message), to combine JCL 2.0 intended
> features with current UGLI features
> 
> Comments?

At this point, the only productive thing that could happen is if log4j
adopted the java.util.logging API as the logging API for log4j.next.
The java.util.logging API, wether you guys accept it or not, is the
only realistic standard moving forward. That way, we would not be
needing any "wrapper API" gimmick, and applications could use the full
logging APIs rather than being limited to a small subset of its
functionality.

One big thing you'll have to understand: I do not and will not change
the API yet again (so anything "new" provided will have to be source
and binary compatible). I'm just tired of logging problems.

As a personal note, I find this proposal completely out of place after
years of FUDing and dissing commons-logging in general, and anything
not log4j in particular.

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] [logging] promote RC1 to alpha status

[Remy Maucherat]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jcl blog post

[Remy Maucherat]

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
> 
> There's lots of ways to shoot yourself in the foot the same way ...
> you don't need JCL to do that ... pretty much any implementation of
> the factory design pattern should be looked at with suspicion.
> 
> By the way ... if you use [chain] you should *really* pay attention to
> the Javadocs for CatalogFactory.clear() ;-)

I like this one too, which is very similar (and of course,
undocumented - the javadocs make you think the method which has to be
called to resolved the leak is useless; the issue is also very hard to
diagnose, as for some reason profilers will not "see" references kept
by this cache):
http://issues.apache.org/bugzilla/show_bug.cgi?id=26135#c6

If I was still working in Santa Clara, the J2SE folks would have heard
I wasn't happy about their "cool" feature ;)

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Notify about using the e-mail account.

[Remy Maucherat]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [digester] [PATCH] Adding Ant-like properties support

[Remy Maucherat]

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 this 
patch/feature more.
BTW, I do have commit access on digester, so I can commit it myself if 
the change is acceptable (for a first implementation).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[digester] [PATCH] Adding Ant-like properties support

[Remy Maucherat]

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 this 
patch/feature more.

Remy

/*
 * $Header: 
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/SetPropertyRule.java,v
 1.14 2003/10/09 21:09:46 rdonkin Exp $
 * $Revision: 1.14 $
 * $Date: 2003/10/09 21:09:46 $
 *
 * 
 * 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2001-2003 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution,
 *if any, must include the following acknowledgement:  
 *   "This product includes software developed by the 
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowledgement may appear in the software itself,
 *if and wherever such third-party acknowledgements normally appear.
 *
 * 4. The names "Apache", "The Jakarta Project", "Commons", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written 
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache",
 *"Apache" nor may "Apache" appear in their names without prior 
 *written permission of the Apache Software Foundation.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * <http://www.apache.org/>.
 *
 */ 


package org.apache.commons.digester;

/**
 * This maps provides properties mapping to system classes. 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/java/org/apache/commons/digester/Digester.java
===
RCS file: 
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/Digester.java,v
retrieving revision 1.83
diff -u -r1.83 Digester.java
--- src/java/org/apache/commons/digester/Digester.java  9 Oct 2003 21:09:46 -  
 1.83
+++ src/java/org/apache/commons/digester/Digester.java  11 Nov 2003 18:27:01 -
@@ -281,6 +281,12 @@
 
 
 /**
+ * Properties source.
+ */
+protected PropertySource[] propertySources = null;
+
+
+/**
  * The public identifier of the DTD we are currently parsing under
  * (if any).
  */
@@ -624,6 +630,30 @@
 }
 
 
+/**
+ * Return the property sources set for this digester.
+ */
+public PropertySource[] getPropertySources() {
+
+return (this.propertySources);
+
+}
+
+
+/**
+ * Set the property sources for this Digester. Setting this to a non
+ * empty array will enable property replacement for all attribute values.
+ * Properties can be referred to in the XML as ${property.name}.
+ *
+ * @param errorHandler The new error handler
+ */
+public void setPropertySources(PropertySource[] propertySources) {
+
+ 

Re: commons-logging & classloading (continued)

[Remy Maucherat]

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 
not well thought out. However, I don't think that all the problems we 
see involving c-l classloading can be attributed to us not using c-l 
"properly". It may work perfectly well with Tomcat5, but that doesn't 
mean there aren't improvements that can be made. Or even accomodations 
that could be made to other containers than Tomcat5.

Could someone please explain why the suggestion to load the Log 
interface with the loadClass() method is not acceptable.
- The core Log classes should be loaded once from one place (= 
(basically) they should be in the system classloader)
- the log implementations (ex: the log4j implementation) should reside 
in the same classloader as the logger; ideally, the logger ships with 
wrapper classes for commons-logging

This is the most efficient design, and fairly easy to understand. 
Coincidentally, this is the design that commons-logging implements, and 
it is good for a complex container environment.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[digester] Feature addition to digester

[Remy Maucherat]

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

* Digester.setPropertySources(PropertySource[] sources), which would:
  - enable property replacement (this would be disable otherwise, for 
100% compatibility)
  - use the sources in the given order until one returns a non null 
value; if all return null, no replacement occurs

The implementation is very simple, and the code is present in the Tomcat 
sources.

This would allow nice dynamic integration capabilities for files a 
container which XML files are parsed by the digester, and (more 
generally) will allow cool Ant-like properties management.

I can commit a patch if the feature is considered useful (the Tomcat 
community certainly did like it).

Comments ?

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[daemon] New feature ?

[Remy Maucherat]

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 commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0

[Remy Maucherat]

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)

Final vote 16 October 2003- 18 October 2003
Release: 19 October 2003
Great !

Since the schedule is compatible, I'll switch TC 5 to a 2.0 (or 1.1, 
whatever) "preview" build as soon as one is available.

Thanks :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0

[Remy Maucherat]

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), this
> release plan must be approved via a lazy majority vote. The
> voting period will end at 23:59:59 GMT on 1 October 2003
> or when a clear majority has been established,
> whichever comes first.
>
> Here's your ballot:
>
> < Please return this portion with your vote >
> [X] +1I am in favor of this plan and I will help
> [ ] +0I am in favor of this plan, but I am unable to help
> [ ] -0I am not in favor of this plan
> [ ] -1I am opposed to this plan being executed,
>  and my reason is:
>
> < /Please return this portion with your vote >
I will help test DBCP 2.0 with Tomcat 5. Speaking of the release 
schedule, it would be great if it could be included in the initial 
stable TC 5, given that critical issues are being addressed.

Would it be possible to accelerate the schedule ? To be included with TC 
5, it would mean it needs to be released before the end of October (and 
likely a bit earlier). Of course, I understand it's not a good idea to 
rush releases, so if it can't happen, so be it :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROCRUN] reorganization

[Remy Maucherat]

Mladen Turk wrote:

Hi,

Since the procrun is fairly generic application that might have it's
usage beyond the Tomcat5 scope, after some consultations with remm, I
propose the following reorganization:
1. All the TC specific code and resources will be moved to
j-t-c/procrun.
2. There will be no build files in the bin neither they will be
maintained.
3. The binaries will be in the j-t-c/procrun/bin so that we can use them
in the installation build.
4. Make the needed callback mechanism to enable the separation.
+1.

There is another approach; that we make the subfolder 'tomcat' in the
procrun and keep all the tomcat specific code in there.
It could have its purpose too, cause it will show how to customize the
procrun to a specific application look and feel, without the need to
download from j-t-c.
I see the point, but IMO even examples should be rather generic. Also, 
if thay are production components, they shouldn't be labelled as examples.
The TC branding modifications should be mentioned in the docs, however.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: karma pls.

[Remy Maucherat]

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: [EMAIL PROTECTED]

Re: [DBCP][Pool] Ready for release

[Remy Maucherat]

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, parameter 
changes at runtime, XA support, pool grow rate, ...) but more and more 
users are asking for a stable release and I think we're ready for it.

The plan is to vote on a release next weekend and the actual release a 
few days later.

Please test the latest nightly build and report any problem. (or give a 
positive vote on the release)
I haven't tested it yet. If you could put out a RC, I could package it 
with future Tomcat 5.0.x builds, which should get help the new DBCP get 
some testing.
It would be especially useful to get a new DBCP release before Tomcat 
5.0.x gets stable, so that many users can get the bugfixes.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Sort of new committer:

[Remy Maucherat]

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 commit!
[ ] +0
[ ] -0
[ ] -1, no, because
+1 of course. I immediately sent a complaint to the PMC list and 
[EMAIL PROTECTED], but no reply yet.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] commons-el 1.0 release

[Remy Maucherat]

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]

[5.0] fileupload 1.0 RC 1 API breakage

[Remy Maucherat]

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 perspective 
:-( I'm hoping there can be positive solutions to the problem ...

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] commons-launcher promotion

[Remy Maucherat]

This is a proposal to move commons-launcher to Commons Proper.

The Launcher component contains, as its name implies, a powerful Java 
application launcher, configured through XML. It is designed to abstract 
native operating system "features" which hinder portability when dealing 
with complex applications.
It is currently used in Tomcat 5, and included in the Tomcat 5.0.0 
milestone.

The component seems mature feature and stability wise.


+1 [ ] Yes, move commons-launcher to Commons Proper
-1 [ ] No, because:



In addition, it is proposed that a first 0.9 beta release of 
commons-launcher be made available.


+1 [ ] Yes.
-0 [ ] No, because:



I am willing to act as the release manager.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[daemon] [VOTE] Code reorg and API changes

[Remy Maucherat]

As was discussed a while ago with Costin and a few others, it appears 
that the daemon API is inadequate, and a refactoring is proposed.

The reorg is:
- Removal of the daemon API (org.apache.commons.daemon), to be replaced 
by pure introspection. The rationale for this was discussed with Costin 
at the time.
- Creation of a commons-launcher component to host the launcher code now 
used in the upcoming Tomcat 5. It turns out the merge with Ant will not 
happen in the forseeable future, and the functionality is useful in 
Tomcat, so I think we should keep the code in the commons, and wait for 
it to be "picked up" :)
- As a consequence, the "daemon" module will be renamed to "launcher". 
It is also proposed that the resulting module be moved to commons proper.


+1 [ ] Yes
-1 [ ] No:




Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New committer: Sean Sullivan

[Remy Maucherat]

> 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:   
For additional commands, e-mail: 

Re: [PATCH] DBCP, tracking, reporting, and recovering abandoned connections

[Remy Maucherat]

> > 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:   
For additional commands, e-mail: 

Re: [VOTE] Promote "Modeler" from Sandbox to Commons, Release 1.0

[Remy Maucherat]

> -- 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:
>
>
> Vote to release Commons Modeler 1.0:
> [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:
>
> -- Cut Here --

Modeler has been used for a long time in the Tomcat 4.1.x branch (of which
the first milestone is now available). The tool has been stable for a long
time, so it makes sense to make a release.
Also, it works with both the JMX RI from Sun and MX4J (which is currently
bundled with Tomcat 4.1).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: PROPOSAL: new 'wrapper' commons component

[Remy Maucherat]

> 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 duplicate the same functionality ( daemon, jk_nt_service, etc).
>
> Attached is the proposal, please send your votes.

+1.

'wrapper' has more advanced features than all the other service wrappers
currently used @Jakarta (or elsewhere).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Update charter to allow any Apache committer into the sandbox

[Remy Maucherat]

+1

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] New committers: Jean-Frederic Clere and Patrick Luby

[Remy Maucherat]

Hi,

I'd like to propose Jean-Frederic as a committer in the commons.
Jean-Frederic has been contributing a lot of code in the TC world, and plans
to continue contributing (as he was doing before) code to the new 'daemon'
component.

I'd also like to propose Patrick Luby as a committer. He'll also be
contributing to the 'daemon' component. He has good Unix knowledge, which
will come in handy for this project. His past activities in the open-source
world include bootstraping OpenOffice port to MacOS X, as well as
contributions to Tomcat.

+1 for both of them.

Remy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [httpclient] Request For Enhancement

[Remy Maucherat]

> 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
> Server: Apache Tomcat/4.0.2 (HTTP/1.1 Connector)
> SOAPAction: ""
>
> Followed by the data.
>
> Notice that there are two (identical) content-type and content-length
> headers. The value of the Content-Type
> org.apache.commons.httpclient.Header is now "132, 132" and so doesn't
> parse.
>
> This is being done by the JAXM Ref Impl - it's calling
> resp.addHeader("Content-Length", 132) twice. I've seen mention that
> HttpClient handles some pathological cases - is this something it should
> handle?

Yes, it would be a lot better.
The server side (TC 4) also has a few similar problems with JAXM at the
moment ;-)

Note: One of the most useful features of the client IMO is that it lets you
write your own methods easily. So if you don't like what the default POST is
doing, it should be easy to create a new one.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposal: New Committer - Marc Saegesser

[Remy Maucherat]

> 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, so Marc has lots more time than anyone else to keep the 
> project moving forward.
> 
> +1's?

+1.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [daemon] JSR 96 support?

[Remy Maucherat]

> > > 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, and the native components look more or less
> > equivalent. The code for the component had been in the Tomcat CVS for a
> > while.
> > Tomcat is currently using a third project as its NT service wrapper.
It'll
> > be easier to depend on the commons rather than an external project.
>
> Cool - was just a heads up more than anything else.

I didn't know about it, BTW.
Tomcat is using that one:
http://www.alexandriasc.com/software/JavaService/index.html

So there are plenty of these out there (and that's rather a good thing).

As for JSR 96, I'll reserve my judgement on it until they release a public
draft. Pier has been saying that it's bad, that's all I know.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [daemon] JSR 96 support?

[Remy Maucherat]

> 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 implement the spec even if
it's not that good. We could also propose a 2.0 version of the API in a
subsequent JSR.

> 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, and the native components look more or less
equivalent. The code for the component had been in the Tomcat CVS for a
while.
Tomcat is currently using a third project as its NT service wrapper. It'll
be easier to depend on the commons rather than an external project.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Daemon] New commons component

[Remy Maucherat]

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 Unix code was developed by Pier Fumagalli as part of
the Tomcat 4 project, but is fully generic and not tied in any way to
Tomcat, so other server side applications may find it useful.

The NT service code and related utilities were written by Jean-Frederic
Clere.

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [httpclient] HTTP Digest authentication

[Remy Maucherat]

> > I was looking at the
> >
> > org.apache.commons.httpclient.Authenticator
> >
> > class.  The class implements "Basic" authentication only.
> >
> > It does not implement the "Digest" authentication scheme.
> >
> > The Digest authentication scheme is described in RFC 2617:
> >
> >   ftp://ftp.isi.edu/in-notes/rfc2617.txt
> >
> > Is anybody planning to implement Digest authentication?
> >
> > Is there a reason why it has not been implemented?
>
> As far as I am concerned, it's 100% lack of time.
> Digest is quite important in the WebDAV world, so I'm interested in the
> funtionality.
>
> > Would it be worthwhile for me to implement Digest
> > authentication?
>
> Only if you feel like it.
> Tomcat 4 has an implementation of DIGEST you can test against on the
server
> side.

Ooops, sorry, I just realized that was already implemented in Slide.
I attach the authenticator, which can be used as a good starting point.

If everyone is ok with it, I can merge the code with the code in the commons
HTTP client authenticator.

Remy



Authenticator.java
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [httpclient] HTTP Digest authentication

[Remy Maucherat]

> I was looking at the
>
> org.apache.commons.httpclient.Authenticator
>
> class.  The class implements "Basic" authentication only.
>
> It does not implement the "Digest" authentication scheme.
>
> The Digest authentication scheme is described in RFC 2617:
>
>   ftp://ftp.isi.edu/in-notes/rfc2617.txt
>
> Is anybody planning to implement Digest authentication?
>
> Is there a reason why it has not been implemented?

As far as I am concerned, it's 100% lack of time.
Digest is quite important in the WebDAV world, so I'm interested in the
funtionality.

> Would it be worthwhile for me to implement Digest
> authentication?

Only if you feel like it.
Tomcat 4 has an implementation of DIGEST you can test against on the server
side.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [httpclient] Lots of patches and discussion

[Remy Maucherat]

> 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
> on any Jakarta-Commons projects.

Welcome :)

> Now a question.  What is the status of the HttpClient 2.0 release?  The
code
> is currently tagged alpha 1 but the RELEASE_PLAN_2_0.txt document hasn't
> been modified since October, 2001.  I ask because, depending on how
iminent
> an actual release is, some of the changes that I'm proposing should
probably
> be made on a separate branch.

Maybe Rodney could comment on that.

> Here's my story.  I have need of something like HttpClient in my product
but
> I found that I had to extend it somewhat.  The extensions are very generic
> and I believe useful to others so I'd like to add to the HttpClient
project.
> I also found several bugs that I fixed along the way.  I've documented
these
> changes below.
>
> I need to be able to use HttpClient (or a derivative) to navigate around
the
> web pretty much like a regular user-agent.  I want to be able to access
any
> site and any web application that I can reach with a reasonably modern
> browser.  HttpClient does a good job of implementing the client side of
RFC
> 2616.  Unfortunately, there are lots of sites and some very big name
> applications that do not implement the server side correctly.  Some sites
> (Yahoo! in particular) actually require a broken client implementation
just
> to log in.  Here are two examples of things I've found so far.
> RFC2616/10.3.3 forbids changing a 302 redirected POST method into a GET
> method but acknowledges that most clients are broken in this regard (this
is
> the failure that Yahoo! requires).  I have found sites that send relative
> URLs in the Location: header of a redirect (this violates RFC2616/14.30).
> Supporting these sites will require 'breaking' HttpClient.  I propose
adding
> some kind of flag to put HttpClient into a 'compatability mode' that
> impelements this and any other required broken behaviour.

That sounds reasonable.

> A second need is to provide a mechanism for getting user acknowledgment
for
> certain actions.  For exampe when redirecting from secure to non-secure
> sites.
>
> I am going to start working on these changes next but I want to discuss
them
> with the HttpClient community so see if they feel they belong in the
commons
> HttpClient project or if the project should be forked.
>
> Anyway, below is a description of the modified and new files.  The patches
> and new files are attached.
>
> Modified files...
>
> Cookie.java
>   -  Added support for old Netscape cookies.  The biggest difference is
that
> the test for valid domains is different for Netscape cookies and RFC 2109
> cookies.
>   -  Added space after the semicolons separating the values.  This is
> required by sites that only implement the old Netscape cookie
specification.
>   -  Added additional date format for expiration times.
>
> HttpConnection.java
>   -  The write*() and print*() methods now throw HttpRecoverableException.
>
> HttpMethodBase.java
>   -  Added a new exception class, HttpRecoverableException.  There are
some
> error conditions that we can try to recover from internally.  The biggest
> one I found was when a server unexepectedly closed the socket.  In this
case
> we should just try to re-open the connection and try the request again.
>   -  Fixed a problem with the handling of 100 status codes.  If we get a
100
> after we've already sent the request body, RFC 2616 states that the
response
> should be ignored.  The currently implementation incorrectly broke out of
> the loop looking for the response.
>   -  Always recreate the cookie header.  A redirect response may have
> included additional cookies that we need to send with the redirected
request
> and the path may have changed thus requiring a different cookie set.
>   -  Fixed readRequestBody implementation.  A new version of this function
> also takes an output stream.  This makes it easier for subclasses to use
> this implementation directly instead of having to re-implement it in order
> to support things like saving the response to a file.
>   -  Better support for responses that don't contain a Content-Length or
> Transfer-Encoding header.  By the specification, if these headers are both
> absent, the response has no body content.  In the real world what this
means
> is that the server probably didn't know the length when the response was
> committed.  It just sends the response and closes the connection when the
> body is complete.  This assumption falls apart when we get a response that
> *can not* contain a body.  In this case, the simple implemenation keeps
> reading looking for a response body and actually ends up reading the next
> response headers as the body.  I've added a list of responses that,
> accor

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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 make people know
> that they can use a commons component without fear. The rule
> allows people that use a component to get more involved in it's
> development - including by vote and review of the code and vetoing
> change that are wrong.
>
> That's what makes commons successfull IMHO. Changing that will turn
> it into avalon - who may have nice code, but most people prefer
> to reimplement the code rather than using it.
>
> ( and don't tell me that it's the fault of the mean people who
> just want to reinvent the wheel. The fact that commons got where
> it is today proves that we can share code )

+1 for everything (including the past emails from Costin, but I'm not going
to quote everything).
Not very surprising since that's the same speech which convinced me one year
ago that the commons project was a good idea after all :)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> On 2/1/02 3:49 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>
> >> So, I agree with Peter: the commons will get too big and has a
> >> too loose structure to control things like this (which is still
> >> not the case with Avalon).
> >
> > Which is also why I don't want to use Avalon to put my shared code.
> > When you need a repository of random components, and you want as many
people
> > as possible to contribute to it and share their code, you can't have a
rigid
> > structure, or they'll choose not to bother.
> > Since we want to maximize code sharing, we need the loose structure.
>
> But the point of commons is *not* to make things to conform to a structure
> like a framework.
>
> Other than documentation and hopefully build procedures, the components
> should be free to be architected as the component developers wish.  If we
> start forcing "You must use XYZ" then we have Yet Another Framework,
right?

Yes, that's exactly what I meant by 'loose structure' ('rigid structure' =
framework).
Did you understand my comments in another way ?

Remy


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance

[Remy Maucherat]

> 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.
>
>  - I should have been more explicit about "code style". I mean "code
>formatting style". This is an ongoing discussion and I am not sure
>that the "right way" is well defined at the commons.
>
> Hey everybody!
> Is there a well defined rule for Code Formatting Style at the Commons?

No, there's no general rule and no Coding Style Police either :-)
If you contribute to a component, the general rule is that you're supposed
to follow the component's coding style.

> The Jakarta general rule at:
>   http://jakarta.apache.org/site/source.html
>
> is:
>   All Java Language source code in the repository must be written in
>   conformance to the "Code Conventions for the Java Programming
>   Language as published by Sun, or in conformance with another
>   well-defined convention specified by the subproject. See the FAQ
>   page for links to subproject conventions.
>
> Some projects like Velocity:
>   http://jakarta.apache.org/velocity/code-standards.html
> define such non-Sun conventions.

There are indeed plenty of projects which don't follow this (not that I
care).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance

[Remy Maucherat]

> I've submitted this patch twice now (once back in mid-November, once a
> week ago), but it still has yet to be committed.

If nobody has time to apply or look at Michael's patches, how about giving
him karma on jakarta-commons ?

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New committer - Paulo Gaspar

[Remy Maucherat]

+1 for Paulo too.

> All this suggestions that I "bigmouthed" my way into becoming
> a committer depress me!
> =;o)

Well, obviously, you're not getting in because you're quiet ;-)
Lol.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Commons/Avalon [was Re: [Logging] [VOTE] Commons Logging 1.0 Release]

[Remy Maucherat]

> 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 that you know the
relative
> stability of projects given your work with GUMP. I guess I should expect
it
> but I had thought you were better than that.

Nice attempt at rewriting history, but I had been using Avalon before you
actually joined the project, and I gave up somwhere afterwards. Gump keep
detailed records about what changes, but the devlopment of Avalon was even
more unstable before (I followed the changes, and none of them appeared to
be for any legitimate reason other than cosmetic). So after a while, I
decided I would rather rewrite a component rather than depend on
org.apache.avalon (of course, the components from Avalon depend on the
framework, so if you use one, you have to use the framework).

In recent times, Avalon has been starting to deprecate first, and it almost
seem you can talk with Peter (although I didn't try myself yet). So it seems
the situation is a lot better now, and that's good for everyone :)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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 to vote on
> something they dont use/develope and never plant to use/develope.

My +1 should read:
- I plan to use it (actually, I just voted +1 on its use in Slide earlier
today, before that release proposal was made).
- I'm a committer on jakarta-commons, and I plan to submit patches if I find
a bug.
So I think it's perfectly valid. I fully reckon I never participated in its
development, but I don't think it's relevant here.

A release vote is a majority vote anyway.

Remy


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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:   
For additional commands, e-mail: 

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> Remy Maucherat wrote:
>
> > Maybe at that time we *didn't* want to work together for some very
specific
> > reasons. After all, the original commons proposal, which I was part of,
> > was -1ed only by Peter, because we apparently had diverging opinions
about
> > how shared code should be governed.
> > Given the number of components in the commons, I think it has been quite
> > successful with its goals, and it did abide by its basic principles
> > (openness, bazaar style repository, extremely few external dependencies,
no
> > imposed coding style, etc etc).
>
>
> Hmmm.   Remy, I have to say this sounds quite petty.

It is not petty at all.
All the points are mentioned are about having no BigGuy controlling what
code I am supposed to be sharing.

> > I'm also greatly disturbed by the timing and the ferocity of your
> > complaints. AFAIK, nobody here did invent the facade pattern or the
Logger
> > interface (or whatever you choose to call it). It seems Rodney came up
with
> > something similar to LogKit by accident.
>
>
> Timing maybe, ferocity?  If you think that is ferocity, then you haven't
> had any kind of debate yet.

Well, I don't know. I've seen you once in a while on this list, the whole
development process was open, the commit messages went by. The second a
release proposal comes, a veto flies, and its justification is "I invented
facaded logging APIs" (please allow me to paraphrase a bit).

> The "I 'tried' and gave up" attitude is bad.

Big difference here. I don't see why I should have to convince anyone to be
able to share my code.
Commons is just that. A place to share code, without too much political
bagage hassle (unlike, for example, being a top-level project).

> > Now, if all you want is some credit for "being there", then so be it,
you
> > have it :) You just could have asked it a lot sooner and in a lot nicer
way.
>
> Sooner, no.

Whatever ...

> Nicer way, possibly.

No kidding ;-)

> Well, perhaps we can both get over ourselves and just move on.  I'm
willing
> to burry the hatchet if you are.  However, I *don't* like when projects
that
> can work together disassociate because of petty reasons.  If there are
*real*
> technical reasons, I can appreciate it.

The community reason is more than enough for me. I thought the biggest
strenght of Jakarta was that it was a community, BTW. Technical stuff always
come second in all the charters I've seen, and everything tends to encourage
community building. So thanks, but I'll keep my community friendly "petty"
stuff :)

If we both want to move forward, I think now that you got your quote, you
should withdraw your -1.

Remy


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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 abstraction should have a credit to HttpClient.  ;)
> >
> > +1 ;-)
> > Although, seeing all this, I'm not sure I want to be involved in any way
> > with Avalon ;-)
>
> However, if you guys tried to work with us from the outset, much of this
> confusion would never have risen.

Maybe at that time we *didn't* want to work together for some very specific
reasons. After all, the original commons proposal, which I was part of,
was -1ed only by Peter, because we apparently had diverging opinions about
how shared code should be governed.
Given the number of components in the commons, I think it has been quite
successful with its goals, and it did abide by its basic principles
(openness, bazaar style repository, extremely few external dependencies, no
imposed coding style, etc etc).

I'm also greatly disturbed by the timing and the ferocity of your
complaints. AFAIK, nobody here did invent the facade pattern or the Logger
interface (or whatever you choose to call it). It seems Rodney came up with
something similar to LogKit by accident.

Now, if all you want is some credit for "being there", then so be it, you
have it :) You just could have asked it a lot sooner and in a lot nicer way.

Scott added that: "That is the past.  This is the present, and I WANT Avalon
and commons to work in harmony, not dischord."
Well, maybe, but the present still reminds me of the past a lot :-(
Hopefully, that's the last time it happens.

Remy


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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 a credit to HttpClient.  ;)

+1 ;-)
Although, seeing all this, I'm not sure I want to be involved in any way
with Avalon ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> 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 I
spent 1 week bitching about it (since at that point in time, it was
yet-another-logging API).
To his credit, Rodney made it separate from httpclient.

Quite frankly, I think all these logging are extremely similar, the main
difference being the interface names.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Logging] [VOTE] Commons Logging 1.0 Release

[Remy Maucherat]

> - 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 unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Robert Donkin as Comitter

[Remy Maucherat]

> 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 like him to play with Digester, BeanUtils, etc as
> well.
> 
> +1 from me,

+1.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [HttpClient] OOPS [PATCH] Bug 5018

[Remy Maucherat]

> To my surprise, I just discovered that ResponseInputStream is already 
> attempting to support chunked transfer encoding. Therefore, the patch I 
> previously submitted to address this bug is moot. Please disregard my 
> previous patch postings for bug 5018.
> 
> However, I have identified the bug in ResponseInputStream. At line 99, 
> it attempts to find the index of the constant "chunked" in a 
> case-sensitive manner. Some servers, such as WebLogic, reply with 
> "Chunked", thus causing this test to fail. The attached patch should 
> solve this problem.

Yes, that's correct. The value should be case-insensitive.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: