commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
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?
<ras>

*******************************************
Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability & WebServices
IBM WebSphere Development


On Wed, 3 Jul 2002 rsitze@us.ibm.com 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
and

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.

Costin


> integrate LogFactory with that, then our hashtable lookup will be
replaced
> 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
EXACTLY
> the use I've put it to in AxisInternalServices.  I'm not breaking the
model
> 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            rsitze@us.ibm.com
> CORBA Interoperability & WebServices
> IBM WebSphere Development
>
>
>

>                       costinm@covalent

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

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

>                       Please respond

>                       to axis-dev

>

>

>
>
>
>
> On Tue, 2 Jul 2002 rsitze@us.ibm.com 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
same
> > 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
by
> > axis, possibly the same configuration properties file that axis will
use
> 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
>
>
>

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