commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Promoting discovery from sandbox
Date Mon, 08 Jul 2002 17:37:23 GMT
Costin & everyone else: Hope you had a great vacation (I did).

So, what is the protocol for moving discovery from the soundbox to the
main-line?  Just rename project?

Richard A. Sitze  
CORBA Interoperability & WebServices
IBM WebSphere Development

On Wed, 3 Jul 2002 wrote:

> When I'm working on a project, it's always my goal to minimize individual
> modules/components/classes direct exposure to external dependencies  EVEN
> when the stated charter for such a dependency is as ideal as commons-
> logging.  Glen, I ALMOST proposed that we have an 'interface org.apache.

I'm not sure that's very good. Do you do the same for SAX or DOM or
collections ?

My main problem with bypassing commons-logging discovery mechanism is
that in doing so you may also bypass the container ( tomcat ) ability
to do important things - like webapp separation, jmx support on the
loggers that support that ( which requires container hooks into the
log creation), sandbox configuration, etc.

> Back to LogFactory.  The point of commons logging is not to use of
> LogFactory, the point is 'Log'.  LogFactory was incidental to Log: it's a
> tool that some would argue (and have) is an anomoly that doesn't properly
> belong.  Moving it out of view DOES make sense.

I don't agree - LogFactory is as important as Log.

Log is what the user should care. LogFactory is important for
the container.

> If/when we push the 'discovery' service (costin, you have no recent
> comments on that - so are we ready to push it out of the sandbox?) out

My last comment was a +1 ( and I had a short vacation ).

There are problems, but it's already a step forward and we can fix
it later.


> integrate LogFactory with that, then our hashtable lookup will be
> with two looks ups (one by service spi [LogFactory], the second by
> classloader).  Still relatively small overhead, I agree BUT unnecessary.
> LogFactory provides the 'getFactory' method AND makes it public for
> the use I've put it to in AxisInternalServices.  I'm not breaking the
> at all.
> I guess I'm trying to work both ends (and middle) of a bridge: axis,
> logging, and discovery.  I don't want my efforts on the last two to have
> detremental impact on axis (no matter how slight).
> <ras>
> *******************************************
> Richard A. Sitze  
> CORBA Interoperability & WebServices
> IBM WebSphere Development

>                       costinm@covalent

>                       .net                     To:      axis-dev@xml.
>                                                cc:

>                       07/02/2002 05:07         Subject: RE: cvs commit:
xml-axis/java/test/wsdl/multithread MultithreadTe
>                       PM

>                       Please respond

>                       to axis-dev



> On Tue, 2 Jul 2002 wrote:
> > Glen, I understand BUT..  Calling LogFactory.getLog
> > - forces a hashtable lookup on every call to obtain the correct
> LogFactory
> > implementation (key is classloader)...
> That's why you would call LogFactory.getLog() only once, at init time.
> Most projects are using a static field - and the cost is minimal.
> > - doesn't guarentee that the LogFactory implementation found is the
> > one used by the rest of Axis (context class loaders, etc)
> That may only happen if you have multiple logger implementations and
> a strange configuration.
> > By getting calling and caching LogFactory.getFactory(),
> > - we go directly the the correct instance every time.
> > - avoid differences in class loader etc.
> > - Provide a single hook where (if needed) the log factory could be
> > overriden by axis, rather than depending upon the logging configuration
> to
> > figure out the right one...
> > I've got a side agenda with this in that in the (near future?) I can
> > override the logger's configuration file and have it use one provided
> > axis, possibly the same configuration properties file that axis will
> in
> > the near future.
> Well, that may conflict with what we are trying to do in tomcat - i.e.
> allow central configuration ( probably JMX based ) of the loggers.
> Also creating a hook and configuration for axis logging factory may
> conflict with the container hooks and configurations.
> There are ongoing discussions with Ceki and on tomcat-dev on how to
> deal with the logging and log configuration.
> Costin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message