You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Sgarlata <sg...@users.sourceforge.net> on 2004/12/20 00:59:40 UTC
Re: [logging] ECL: Log interface vs. abstract class
Ceki Gülcü wrote:
> Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
> domains for categorizing logging statements. When that happens, the
> notion of logging levels will be looked at very differently.
>
> Commons-logging promises to abstract different logging APIs such as
> log4j, Avalon logkit and java.util.logging API. However, such a task
> is near impossible to fulfill, while Avalon Logkit is nowhere to be
> seen. In the history of software, no one has ever managed to abstract
> competing and divergent APIs without their active cooperation. Chances
> are it won't happen this time around either.
>
> User who currently use commons-logging are likely to go through a
> lengthy and painful conversion process when they realize that log4j
> offers must-have features.
I think this added functionality that is coming in Log4J demonstrates
another reason to leave Log as an interface rather than converting it to
an abstract class. Assuming we make LocalizedLog an interface that
extends Log, when Log4J introduces support for their new "domain"
logging (if you will), JCL can just introduce a DomainLog interface that
extends Log and has nothing to do with LocalizedLog. A logging
implementation may or may not support internationalization, and may or
may not support this new "domain" concept. In this way, we can have Log
implementations describe which features they support by implementing
certain interfaces and not others.
If Log becomes an abstract class, then instead of just introducing a
LocalizedLog interface and a DomainLog interface, we would would have a
factorial explosion of abstract Log subclasses:
DomainLog extends Log
LocalizedLog extends Log
DomainLocalizedLog extends Log
If we need to introduce FeatureNumberThree we will have all the above
abstract classes plus:
FeatureNumberThreeLog extends Log
DomainFeatureNumberThreeLog extends Log
LocalizedFeatureNumberThreeLog extends Log
LocalizedDomainFeatureNumberThreeLog extends Log
etc.
Conclusion: Switching to an abstract class doesn't just hamper the
flexibility of users of JCL; it also decreases JCL's ability to expose
more logging features by simply introducing new interfaces.
>
>> Matt
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Ceki Gülcü <ce...@qos.ch>.
Whether you choose Log to be an interface or an abstract class does
not really matter. The point I am trying to convey is that jcl will
not be able to abstract more than one logging API. Although desirable,
abstraction is not technically feasible.
At 12:59 AM 12/20/2004, Matt Sgarlata wrote:
>I think this added functionality that is coming in Log4J demonstrates
>another reason to leave Log as an interface rather than converting it to
>an abstract class. Assuming we make LocalizedLog an interface that
>extends Log, when Log4J introduces support for their new "domain" logging
>(if you will), JCL can just introduce a DomainLog interface that extends
>Log and has nothing to do with LocalizedLog. A logging implementation may
>or may not support internationalization, and may or may not support this
>new "domain" concept. In this way, we can have Log implementations
>describe which features they support by implementing certain interfaces
>and not others.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Ceki Gülcü <ce...@qos.ch>.
Henning,
Thank you for sharing your mind. You have the right to pooh-pooh my
opinions as much I have the right to express them. I still happen to
think that the X.25 TCP/IP analogy bears relevance to the
discussion. The fact that a simple analogy was sufficient to push your
buttons should tell you something.
At 09:04 AM 12/21/2004, Henning P. Schmiedehausen wrote:
>Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@qos.ch> writes:
>
> >all the attempts made at bridging X.25 and TCP/IP, both well defined
> >and stable protocols, have failed miserably, even if both stacks
> >supposedly fit into layers 1-4 of the 7 layer OSI network model.
>
>But X.25 and TCP/IP use two completely different paradigms ("always
>deliver" vs. "best effort"). BTDTGTT.
>
>This is like saying "a good football player should also be a good
>basketball player, because both are games played with a ball".
>
>If this is the level to which this discussion will degrade, it makes
>no sense to discuss. You are (once again) comparing apples to
>pears.
>
> Regards
> Henning
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Ceki =?iso-8859-1?Q?G=FClc=FC?= <ce...@qos.ch> writes:
>all the attempts made at bridging X.25 and TCP/IP, both well defined
>and stable protocols, have failed miserably, even if both stacks
>supposedly fit into layers 1-4 of the 7 layer OSI network model.
But X.25 and TCP/IP use two completely different paradigms ("always
deliver" vs. "best effort"). BTDTGTT.
This is like saying "a good football player should also be a good
basketball player, because both are games played with a ball".
If this is the level to which this discussion will degrade, it makes
no sense to discuss. You are (once again) comparing apples to
pears.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Richard Sitze <rs...@us.ibm.com>.
Simon Kitching <s_...@paradise.net.nz> wrote on 12/25/2004 06:25:51
PM:
> On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> > In my last message, I failed to emphasize the brittleness of the
> > "break into interfaces" hypothesis. Even if at a high-level of
> > abstraction two APIs perform the same task, this does not mean that
> > they can be abstracted away by a thin facade (or bridge). For example,
> > all the attempts made at bridging X.25 and TCP/IP, both well defined
> > and stable protocols, have failed miserably, even if both stacks
> > supposedly fit into layers 1-4 of the 7 layer OSI network model.
>
> I quite agree with this.
>
> And I don't think the approach of providing multiple optional interfaces
> in commons-logging to support "advanced" features that various logging
> libraries implement is useful either. As I've written in previous
> emails, I do *not* like the idea of an application failing to start
> because an appropriate logging implementation is not present.
>
> I think commons-logging should be a *simple* API that abstracts only the
> *basic* functionality of logging. The current API is fine; log strings
> at various priority levels to a single named category. Any reasonable
> log implementation will be able to provide a sane mapping for these
> concepts.
>
> But I don't think it is worth trying to extend JCL much beyond this. As
> Ceki says, logging libraries can provide widely varying features and it
> is not productive to try to map these to portable APIs.
Agreed in general, but there are some directions that are reasonable to
follow. i18n is one.
> JCL does a very useful job for jakarta-commons libraries: provide a
> means for the commons libraries to implement logging without enforcing a
> logging implementation on the larger app which uses the library. Note
> that the kind of log messages generated by commons components are of
> course implementation-related and are therefore aimed at the *developer*
> not the user. For this reason, i18n support is not terribly useful for
> commons component logging.
Not true. In particular, the Message level API's [fatal, error, warn,
info] may be targeted towards either end users, or [international]
developers using the component. In either case, i18n is useful.
For example, HTTPSender reflects an edge component to which customers are
directly exposed. Failure to open ports, dropped socket connections...
any socket, TCP/IP, or HTTP error is of interest to the end user, not just
the developer using HTTPSender. Clearly, the developer would very much
prefer that the users *resolve* these problems [in their native languages]
rather than have the user contact the developer. And the component
developer would prefer that the app developer understand how/if the API's
are being misused, again in their natural language if possible.
There is a need for i18n logging, and IBM's recognition of this need is
much broader than *my* immediately daily chores. I'm just a spokeman here
folks: the proposal is submitted on behalf of IBM, not IBM WebSphere
[J2EE]. IBM and many other global companies are involved with a number of
open source projects. Internationalization IS becoming more and more
important for our customers. And our customers using open source are your
customers.
The IBM community also feels *strongly* that we must NOT fragment the
logging community any further than it already is, strong alignment with
JCL is necessary.
> However I'm not convinced that for *applications* (rather than
> libraries) it is sensible to use JCL at all; why not just pick a
> concrete logging implementation and use that? You get all the necessary
> features, and apps can deploy whatever logging implementation they want.
Agree 100%. NO question. This is fundamental to JCL's goals.
> The only awkward situation is container frameworks like J2EE. In this
> case, you may want logging to be redirected to the container's logging
> implementation so that logging from all apps within the framework is
> treated consistently. I can see some kind of common API cabable of
> generating i18n messages being useful here.
>
> After all the discussion on logging recently, I'm coming to the
> conclusion that Richard's original proposed features (i18n, discovery
> changes) should *not* be included in JCL. None of these features help
> commons components with their logging requirements, and these features
Disagree strongly. And I believe there are others would also disagree.
> *are* going to make JCL significantly more complex and controversial. It
> would be better to start a separate project. If this project can
> successfully resolve the issues then maybe it could be merged back in to
> JCL.
>
> To summarize, my (non-binding) votes are:
> -1 to adding extra *optional* features to JCL that fail if the
> "discovered" logging implementation doesn't suport them. This
> includes Richard's EnterpriseLog class, and Matt Scarlata's
> proposals too.
> -1 to *mandatory* configuration for JCL
> +1 to keeping JCL as a least-common-denominator logging API that
> can be used for commons components.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
Simon, I agree with you 80% and I think you're right that JCL should
stay as-is for now.
I think you're dead-on with this new line of thinking. It won't seem
like it because now I'm going to spend the rest of this email
disagreeing with you, but I'm with you on the big leap you took in your
last post; I'm just disagreeing with you on the minor details :) See
below...
Simon Kitching wrote:
> On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
>
>>In my last message, I failed to emphasize the brittleness of the
>>"break into interfaces" hypothesis. Even if at a high-level of
>>abstraction two APIs perform the same task, this does not mean that
>>they can be abstracted away by a thin facade (or bridge). For example,
>>all the attempts made at bridging X.25 and TCP/IP, both well defined
>>and stable protocols, have failed miserably, even if both stacks
>>supposedly fit into layers 1-4 of the 7 layer OSI network model.
>
>
> I quite agree with this.
I don't think that just because *some* bridging attempts fail that *all*
bridging attempts must necessarily fail. In the case of localized
logging, I think we could quite easily introduce a bridge API.
HOWEVER, at this point there's nothing to bridge! Correct me if I'm
wrong, but there are two options for internationalization on the table
right now:
1) Log4J
2) ResourceBundles + some other logging implementation (e.g. JDK 1.4
logging or JCL's SimpleLog)
If internationalization becomes a part of most logging APIs and it
becomes clear that localized log messages really are needed by many
applications, *then* JCL can worry about providing a bridge API. (In
other words, if JDK 1.4 logging adds localization features in a future
JDK, say JDK 1.6 or 1.7, then JCL can worry about the bridging API.)
For now, if you need internationalization, it's not difficult to roll
your own abstraction over JCL like this
public class MyStaticLoggerUtils {
public static void info(Log log, String messageKey, Object args[]) {
// code here
}
}
So Richard can have his enter/exit methods and I can have my
ReloadableResourceBundle from Spring and we can go happily our own ways ;)
> And I don't think the approach of providing multiple optional interfaces
> in commons-logging to support "advanced" features that various logging
> libraries implement is useful either. As I've written in previous
> emails, I do *not* like the idea of an application failing to start
> because an appropriate logging implementation is not present.
I don't think that introducing advanced features implies that logging
*must* break if those advanced features aren't present. I think this
could be configurable both at the component level *and* at the
application level (i.e. - Component X says "I want
Internationalization!" and Application Y is free to say "too bad"). In
the case of internationalization, we've already demonstrated that it
would be easy to fall back to logging the message codes without any
resolution. (For example, I get message code output like this all the
time from the JSTL tags implemented by the Taglibs project. Not very
cute, but not a huge problem either)
> I think commons-logging should be a *simple* API that abstracts only the
> *basic* functionality of logging. The current API is fine; log strings
> at various priority levels to a single named category. Any reasonable
> log implementation will be able to provide a sane mapping for these
> concepts.
>
> But I don't think it is worth trying to extend JCL much beyond this. As
> Ceki says, logging libraries can provide widely varying features and it
> is not productive to try to map these to portable APIs.
>
> JCL does a very useful job for jakarta-commons libraries: provide a
> means for the commons libraries to implement logging without enforcing a
> logging implementation on the larger app which uses the library. Note
> that the kind of log messages generated by commons components are of
> course implementation-related and are therefore aimed at the *developer*
> not the user. For this reason, i18n support is not terribly useful for
> commons component logging.
>
> However I'm not convinced that for *applications* (rather than
> libraries) it is sensible to use JCL at all; why not just pick a
> concrete logging implementation and use that? You get all the necessary
> features, and apps can deploy whatever logging implementation they want.
I don't think it's fair to say that applications don't need an
abstraction over logging APIs. This is like saying "why code to
interfaces and use factories rather than just coding to classes?".
Abstractions over specific implementations can be useful at all levels
of a system. It's really up to the system's architect to determine
where abstractions are appropriate and where they are not. I think it's
a little bold to claim that applications never need a logging
abstraction and can feel safe in coding directly to a logging
implementation. I personally always choose to use JCL; both in
components and for applications.
> The only awkward situation is container frameworks like J2EE. In this
> case, you may want logging to be redirected to the container's logging
> implementation so that logging from all apps within the framework is
> treated consistently. I can see some kind of common API cabable of
> generating i18n messages being useful here.
>
> After all the discussion on logging recently, I'm coming to the
> conclusion that Richard's original proposed features (i18n, discovery
> changes) should *not* be included in JCL. None of these features help
> commons components with their logging requirements, and these features
> *are* going to make JCL significantly more complex and controversial. It
> would be better to start a separate project. If this project can
> successfully resolve the issues then maybe it could be merged back in to
> JCL.
>
> To summarize, my (non-binding) votes are:
> -1 to adding extra *optional* features to JCL that fail if the
> "discovered" logging implementation doesn't suport them. This
> includes Richard's EnterpriseLog class, and Matt Scarlata's
> proposals too.
I agree we should ditch EnterpriseLog and my proposal. However, I'd
like to reiterate that, as I mentioned above, I don't think that
"introducing optional features" implies "system startup failure if
optional feature missing"
> -1 to *mandatory* configuration for JCL
I agree with you
> +1 to keeping JCL as a least-common-denominator logging API that
> can be used for commons components.
I agree with you
> Regards,
>
> Simon
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Simon Kitching <s_...@paradise.net.nz>.
On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> In my last message, I failed to emphasize the brittleness of the
> "break into interfaces" hypothesis. Even if at a high-level of
> abstraction two APIs perform the same task, this does not mean that
> they can be abstracted away by a thin facade (or bridge). For example,
> all the attempts made at bridging X.25 and TCP/IP, both well defined
> and stable protocols, have failed miserably, even if both stacks
> supposedly fit into layers 1-4 of the 7 layer OSI network model.
I quite agree with this.
And I don't think the approach of providing multiple optional interfaces
in commons-logging to support "advanced" features that various logging
libraries implement is useful either. As I've written in previous
emails, I do *not* like the idea of an application failing to start
because an appropriate logging implementation is not present.
I think commons-logging should be a *simple* API that abstracts only the
*basic* functionality of logging. The current API is fine; log strings
at various priority levels to a single named category. Any reasonable
log implementation will be able to provide a sane mapping for these
concepts.
But I don't think it is worth trying to extend JCL much beyond this. As
Ceki says, logging libraries can provide widely varying features and it
is not productive to try to map these to portable APIs.
JCL does a very useful job for jakarta-commons libraries: provide a
means for the commons libraries to implement logging without enforcing a
logging implementation on the larger app which uses the library. Note
that the kind of log messages generated by commons components are of
course implementation-related and are therefore aimed at the *developer*
not the user. For this reason, i18n support is not terribly useful for
commons component logging.
However I'm not convinced that for *applications* (rather than
libraries) it is sensible to use JCL at all; why not just pick a
concrete logging implementation and use that? You get all the necessary
features, and apps can deploy whatever logging implementation they want.
The only awkward situation is container frameworks like J2EE. In this
case, you may want logging to be redirected to the container's logging
implementation so that logging from all apps within the framework is
treated consistently. I can see some kind of common API cabable of
generating i18n messages being useful here.
After all the discussion on logging recently, I'm coming to the
conclusion that Richard's original proposed features (i18n, discovery
changes) should *not* be included in JCL. None of these features help
commons components with their logging requirements, and these features
*are* going to make JCL significantly more complex and controversial. It
would be better to start a separate project. If this project can
successfully resolve the issues then maybe it could be merged back in to
JCL.
To summarize, my (non-binding) votes are:
-1 to adding extra *optional* features to JCL that fail if the
"discovered" logging implementation doesn't suport them. This
includes Richard's EnterpriseLog class, and Matt Scarlata's
proposals too.
-1 to *mandatory* configuration for JCL
+1 to keeping JCL as a least-common-denominator logging API that
can be used for commons components.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Ceki Gülcü <ce...@qos.ch>.
In my last message, I failed to emphasize the brittleness of the
"break into interfaces" hypothesis. Even if at a high-level of
abstraction two APIs perform the same task, this does not mean that
they can be abstracted away by a thin facade (or bridge). For example,
all the attempts made at bridging X.25 and TCP/IP, both well defined
and stable protocols, have failed miserably, even if both stacks
supposedly fit into layers 1-4 of the 7 layer OSI network model.
The Logging problem has not been completely solved yet. Log4j will
continue to evolve at a quick pace during the coming years. I believe
that trying to foresee, let alone abstract this evolution is an iffy
proposal at best.
Some will say that Logging is no where comparable in complexity of a
network protocol. Some will say that JSR 47 cannot be ignored since it
is part of the JDK. Some will say that they absolutely require API
independence to satisfy their clients. I realize that asking you to
take my word for it is too big a leap of faith. Consequently, and as
in the past, I fully expect my repeated warnings to be ignored.
Coming back to your example, you are assuming that localization
support will be done by introducing new member methods in the "logger"
interface/ abstract class. However, this will not necessarily be the
case. As Curt Arnold mentioned earlier, localization support can be
added by adding new semantics to the existing methods. Of course,
another logging API may choose another path where localization support
is done through new specialized methods. Now, JCL's task is two
abstract these two different approaches. Which even in the case of
this quasi-trivial example looks extremely hard to get right. Hence my
observation that in the case of evolving and divergent APIs,
abstraction although desirable, is not feasible.
The interface vs. abstract class debate only makes sense in the case
of APIs submitting to a common standard. In that case, the common
standard should be implemented in terms of interfaces instead of
abstract classes in order too leave enough wiggling room for willing
implementations of the standard. However, even if you are right,
since there is no common standard, the debate interface vs. abstract
class is moot.
My personal attempts at a future-aware standard showed how difficult
the abstraction task was. (I was only concerned with abstracting
log4j's own interfaces.)
See also
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/
At 04:41 PM 12/20/2004, Matt Sgarlata wrote:
>Let's make this more concrete by examining the problem currently presented
>to us: localization of logging messages (this would be API-X in your
>example). If JCL adds a new LocalizedLog interface (JCL-IX), calls to the
>localized log will work as expected when the underlying logging
>implementation supports localization (branch 1 in your post). If
>localization is not available, the unresolved message keys are supplied to
>the underlying logging implementation (branch 2).
>
>This seems perfectly reasonable to me. If the underlying logging
>implementation doesn't support internationalization, then the log messages
>aren't internationalized. Of course, if you've gone to all the trouble of
>making your message internationalized, I would expect this would narrow
>down the field of logging implementations you chose from :)
>
>I hope I'm not being argumentative or dense. I'm really just trying to
>make a case for using interfaces rather than abstract classes. My point
>earlier was simply that the more features are supported by JCL, the harder
>it will be to squeeze them into some type of abstract class hierarchy and
>the more compelling an interface-based abstraction layer is.
>
>Matt
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
Let's make this more concrete by examining the problem currently
presented to us: localization of logging messages (this would be API-X
in your example). If JCL adds a new LocalizedLog interface (JCL-IX),
calls to the localized log will work as expected when the underlying
logging implementation supports localization (branch 1 in your post).
If localization is not available, the unresolved message keys are
supplied to the underlying logging implementation (branch 2).
This seems perfectly reasonable to me. If the underlying logging
implementation doesn't support internationalization, then the log
messages aren't internationalized. Of course, if you've gone to all the
trouble of making your message internationalized, I would expect this
would narrow down the field of logging implementations you chose from :)
I hope I'm not being argumentative or dense. I'm really just trying to
make a case for using interfaces rather than abstract classes. My point
earlier was simply that the more features are supported by JCL, the
harder it will be to squeeze them into some type of abstract class
hierarchy and the more compelling an interface-based abstraction layer is.
Matt
Ceki Gülcü wrote:
>
> Aren't you assuming that things can be placed in nice orthogonal and
> independent boxes?
>
> Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
> an interface unique to API X. Let JCL-IX be JCL's mirror of interface
> IX. If the end-user sprinkles her code with JCL-IX calls, there are
> two possible branches:
>
> 1) API X is available, and there no unintended or unforeseen
> interactions between JCL-IX and IX then everything will be fine. If
> there are unintended or unforeseen interactions, then this usually
> takes a long time to discover, let alone to repair. In the mean time,
> your users will be pulling out their hair in frustration.
>
> 2) API X is unavailable. In that case, JCL might may attempt to
> replace the functionality offered by API X with a NOP implementation or
> a simple alternative. However, if API X is considered core
> functionality, then the promise of abstraction cannot be not fulfilled
> without duplicating the code found in API X.
>
> Writing a good facade is much harder than what people realize. In the
> case of competing and divergent APIs, it is an impossible one.
>
> At 03:18 PM 12/20/2004, Matt Sgarlata wrote:
>
>> I disagree; different logging APIs can be supported with the addition
>> of new interfaces. Using this strategy, the set of interfaces that a
>> given Log implementation implements define the set of features which
>> that logging implementation supports.
>>
>> Ceki Gülcü wrote:
>>
>>>
>>> Whether you choose Log to be an interface or an abstract class does
>>> not really matter. The point I am trying to convey is that jcl will
>>> not be able to abstract more than one logging API. Although desirable,
>>> abstraction is not technically feasible.
>>
>>
>> --
>> Ceki Gülcü
>>
>> The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Ceki Gülcü <ce...@qos.ch>.
Aren't you assuming that things can be placed in nice orthogonal and
independent boxes?
Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
an interface unique to API X. Let JCL-IX be JCL's mirror of interface
IX. If the end-user sprinkles her code with JCL-IX calls, there are
two possible branches:
1) API X is available, and there no unintended or unforeseen
interactions between JCL-IX and IX then everything will be fine. If
there are unintended or unforeseen interactions, then this usually
takes a long time to discover, let alone to repair. In the mean time,
your users will be pulling out their hair in frustration.
2) API X is unavailable. In that case, JCL might may attempt to
replace the functionality offered by API X with a NOP implementation or
a simple alternative. However, if API X is considered core
functionality, then the promise of abstraction cannot be not fulfilled
without duplicating the code found in API X.
Writing a good facade is much harder than what people realize. In the
case of competing and divergent APIs, it is an impossible one.
At 03:18 PM 12/20/2004, Matt Sgarlata wrote:
>I disagree; different logging APIs can be supported with the addition of
>new interfaces. Using this strategy, the set of interfaces that a given
>Log implementation implements define the set of features which that
>logging implementation supports.
>
>Ceki Gülcü wrote:
>>
>>Whether you choose Log to be an interface or an abstract class does
>>not really matter. The point I am trying to convey is that jcl will
>>not be able to abstract more than one logging API. Although desirable,
>>abstraction is not technically feasible.
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: Log interface vs. abstract class
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
I disagree; different logging APIs can be supported with the addition of
new interfaces. Using this strategy, the set of interfaces that a given
Log implementation implements define the set of features which that
logging implementation supports.
Ceki Gülcü wrote:
>
>
> Whether you choose Log to be an interface or an abstract class does
> not really matter. The point I am trying to convey is that jcl will
> not be able to abstract more than one logging API. Although desirable,
> abstraction is not technically feasible.
>
>
> At 12:59 AM 12/20/2004, Matt Sgarlata wrote:
>
>> I think this added functionality that is coming in Log4J demonstrates
>> another reason to leave Log as an interface rather than converting it
>> to an abstract class. Assuming we make LocalizedLog an interface that
>> extends Log, when Log4J introduces support for their new "domain"
>> logging (if you will), JCL can just introduce a DomainLog interface
>> that extends Log and has nothing to do with LocalizedLog. A logging
>> implementation may or may not support internationalization, and may or
>> may not support this new "domain" concept. In this way, we can have
>> Log implementations describe which features they support by
>> implementing certain interfaces and not others.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org