Robert Burrell Donkin ha scritto:
On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin (JIRA) ha scritto:
* Entry point:
* SieveFactory
This should only be used to wire together the default implementations,
otherwise direct objects wiring should be allowed for
extensibility/integration.
i see no reason why SieveFactory needs to be coupled to the default
implementations. the factory should be either abstract or an interface
and loaded by the configuration.
My think is that if it is an entry point it cannot be abstract or an
interface. The entry point is the object I instantiate to use sieve (in my
terms).
But I guess here we are simply using different terms. It's better I wait and
look at how you will change code and maybe I should better speak with code
in reply :-)
SieveFactory is currently the (badly named) entry point. it might be
better to have a proper factory as the entry point.
Make sense.
i'm not sure it's worthwhile to create yet another logger bridge in
this case. injecting a JCL log is probably good enough.
My issue with JCL injecting is that Logger does not have a getChildLogger.
yes - that's probably the biggest mistake we made when creating the
API. then again, the JEE specifications weren't broken at that time so
it didn't seem necessary to cater for injecting loggers.
OT: why not to starting a commons-logging 2.0 that has this feature?
So if you inject a JCL logger you can't have different names in the various
components.
jsieve doesn't need this functionality
Ok. Then plain commons logging is ok.
Furthermore there are many people not happy with commons-logging, and they
often don't understand the difference between injected commons-logging and
static commons-logging usage. The bad name for loggers born by their static
usage.
i strongly suspect that JCL is the most widely used library in java.
lots of people whinge but everyone uses it. the JEE specifications are
mutally incompatible when it comes to classloaders. this makes it
impossible to fix JCL or come up with anything better than it that is
compatible with both the servlet and enterprise specifications.
it's problems are well known as are the workarounds. alternative
solutions often have better reputations because no one really uses
them.
the JCP is absolutely culpable for the whole mess. they refused to
invite ceki onto the expert group for java.util.logging and so forced
people to choose between log4j and java.util.logging. this forced JCL
to be created. the JCP then decided that it was more important that
JEE engines could do whatever they want with classloaders than
consistency with the Java2 or servlet specifications. this caused the
classloading hell with JCL and made it impossible to fix for both
servlet containers and JEE containers.
Interesting summary. Didn't know the history of things. Thank you!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
