On 4/3/02 4:13 PM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
> Yes, but remember that in the big picture we are as much about solving > problems by using existing assets as we are about adding to > org.apache.common.*. Please, lets not invite changes without clearly > understood requirements. > > In this case Geir's proposal requires (somewhere, and I admit that we don't > care where) a supporting framework to be useful. It may be that the Avalon > solution solves this problem for this Geir by providing both the framework > AND the logger interface, independent of any one logger (which is a goal of > the commons logging - remember that Avalon did that first, even if not in > line with what we wanted for org.apache.commons.logging). Here's the key - I was motivated this by wanting to add loggable component support to my *existing* framework that is adding support for components, some of which may want to log. I agree - if starting with a clean slate, there is no purpose for this (unless I want to :), but for the case where stuff exists, this I think helps integrate. > > If the requirement stands after the group conversation, great. If not, say > bye-bye until such time as we have a clear picture for the greater need. > > In this case, my vote would be -1 to changing commons-logging (Am I a > voting member under the new by-laws or not? I'm a committer in Axis, and > I've submitted changes to commons logging) for the reasons above. If you are not a commons committer, no. if you are a commons committer for any component whatsoever, your vote counts for logging. Weird, eh? > I could be swayed if Geir is set on working within commons logging, but I > think he has a existing solution elsewhere that is more than appropriate > for his needs. This is why I proposed it : I have an *existing* framework that is not Avalon, Struts or Turbine (hard to believe other solutions are possible, I know, I know...) that we are going to add an externally configurable component toolbox. These components have no requirements other than the are public classes with public methods written in Java. I want to require that, if they want to log, the components implement what I thought was a lifecycle free, framework free, invocation model free commons logging *interface*. I wanted to make sure that the components were able to be used elsewhere, without dragging with them the requirement that Log or LogFactory was in the classpath so they could statically get a logger. In order to do that, I needed a way for components to signal that they wanted and could handle a Commons logger... <sigh> > > Note also that if we introduce the "push" model, and we really desire to > remain consistent within the Jakarta community, then sooner or later we > will want to have that "push" model functional under the Avalon component > framework.... do we REALLY want to go there??? I'll repeat that they > ALREADY HAVE a logger independent interface with minimal supporting > framework. What does this have to do with Avalon again? Avalon doesn't have a monopoly on setter methods in Jakarta-land. > > While it would be nice to talk about a common interface for both commons > logging and LogKit, it must be pointed out that there are fundamental > differences in the API generally used by the user, most notable being > "Object message" versus "String message". Isn't this the WHOLE POINT of commons logging? That I can use the commons logging interface, and hide the implementation behind it? So the factory can return a LogImpl based on log4j, logkit, or whatever I choose? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Somebody has to do something, and it's just incredibly pathetic that it has to be us. - Jerry Garcia -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
