Richard Sitze <[EMAIL PROTECTED]> writes:
>This is a strong point from a "lazy" point of view [no offense, please].
>But it's also one if it's greatest weaknesses. You have no way of knowing
>which logger impl. you are going to be using. Yes, you can configure. No,
>there is no assurance that what you configured will be used... you can
>check it once, but when you start deploying your applications in
>production, you have to re-check.. and re-check... and you never know when
>someone's going to change the classpath and change the behavior. It's a
>nightmare.
Making sure that you always hand out the right logging implementatin
is the job of your application / your container. It should use
e.g. log4j as its enterprise logger and allow components, that are 3rd
party or independently written from your application and want to use
JCL to use these and wire their logging output into your enterprise
logging.
An example here. Turbine optionally configures log4j and offers it to
its components and applications as "its enterprise logger". It also
uses a commons-logging.properties file (which is part of the META
environment and distributed with every turbine application unless the
developer changes it explicitly), to wire JCL onto log4j.
The Turbine core itself uses _only_ JCL and we do encourage our users
whenever they write a new service or component to do the same. So you
can "plug" a Turbine application into your enterprise container and
simply rewire all of its logging using commons-logging.properties
(which then should point at your enterprise logging facility).
Your app would be responsible to offer the JCL implementation
(which boils down to what? One class (factory) and one Log interface
implementation) to its components. When they ask for
"Log log = LogFactory.getLog(<mumble>)", the app is ultimately
responsible that they get a logger which is then integrated with your
enterprise logging. If this fails, this IMHO is an application
failure, not a JCL failure.
The enterprise logging scope (I will keep the L10N and I18N issues out
here) for JCL is IMHO the same scope as for the "regular"
component. If you run a smallish program (or build a component), an
unconfigured JCL will output to stderr. Which works well.
If you run in an enterprise environment, you must make sure, that this
enterprise environment returns the right configuration to the
LogFactory so that it returns your implementation.
The current lookup process is IMHO too fragile because it depends on
jars in the classpath. Using bytecode engineering has its merits
(because it would allow your enterprise application to simply "rewire"
the Factory implementation lookup process to return your enterprise
logger).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
