Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 05 Sep 2005 19:33:33 +0200
From: Jeremias Maerki <dev.jeremias@greenmail.ch>
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Logging for FOrayFont
In-Reply-To: <20050905150609.8C3FF10FB2A5@asf.osuosl.org>
References: <20050905090048.58D7.DEV.JEREMIAS@greenmail.ch>
 <20050905150609.8C3FF10FB2A5@asf.osuosl.org>
Message-Id: <20050905174237.58F5.DEV.JEREMIAS@greenmail.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


On 05.09.2005 17:05:48 Victor Mote wrote:
> Jeremias Maerki wrote:
>=20
> > I got a little shock when I realized a problem I didn't think=20
> > of when we discussed moving FOP components over to XML=20
> > Graphics Commons. We said we would try to remove logging code=20
> > from these basic components entirely.
> >
> > Now, I forgot to consider the decision to use FOrayFont made earlier.
> > The external dependency on FOrayFont also would be a problem=20
> > in itself because the Batik side has strong feelings against=20
> > external dependencies.
> > We need to think about what to do about this WRT the PDF and=20
> > PS transcoders. Optimized text painting in these two=20
> > transcoders depends a lot on the font subsystem.
>=20
> Well, the little change I just made removes entirely any dependency on
> Avalon in any FOray code, except for the fact that Ant seems to need it f=
or
> logging (needed for creating hyphenation patterns and such). There is no
> longer any Avalon code in FOrayFont. In fact, that was the primary
> motivation for making the change. The Avalon Logger interface would have
> been quite a sufficient solution for anything that FOray needs, and, sinc=
e
> it is an interface, adapters could be written from it to anything else, j=
ust
> as Vincent and I have been discussing for the PseudoLogger interface.

Yeah, yet another generic logger abstraction interface. Sigh.

> > Aside from that, a thought about the aXSL APIs: Being an=20
> > ex-Avaloner SoC (separation of concerns) is a big concern to=20
> > me. The functional API of a package should IMO actually not=20
> > deal with (or rather expose) logging at all. It's a separate=20
> > concern. I'm ever growing more cofident that=20
> > developer-oriented logging should be done through a static=20
> > logging facility (like Commons Logging) and that=20
> > end-user-oriented logging needs to operate per processing run=20
> > (like Avalon Logger) but not necessarily through a standard=20
> > logging abstraction interface, but rather an=20
> > application-specific one that provides exactly what the=20
> > application needs to send feedback to the end-users. In that=20
> > light, a PDF or font library shouldn't expose any logging=20
> > facilities at all or at least to static logging that is=20
> > externally configured.
>=20
> First, do you understand that the FOrayFont library does not "expose any
> logging facilities" to the client, but instead asks the client to expose =
the
> logging facilities to it?

Yes. Sorry for the not quite accurate wording plus a typo. Let's try
again: [a work interface] shouldn't expose any logging specifica (as
they are a separate concern, see Avalon's LogEnabled interface or newer
dependency injection systems). If developer-oriented logging is
absolutely necessary I prefer static logging (like Commons Logging or
Log4J) today.

> A PseudoLogger is required (but can be passed
> null) in the FontServer constructor

That's an implementation detail and not a problem. It has nothing to do
with the API. FontServer is an interface in the API and you are talking
about the implementation of FontServer here, I assume.

> and is required in a method in
> FontConsumer. But FontConsumer is implemented on the client side, in whic=
h
> the client application tells FOray about itself.

This method getPseudoLogger() is what caught my purist's eye in the
first place. It breaks IoC.

> Second, why should FOray limit its clients to only use static logging? If
> the client has to expose a static logging mechanism to FOray in order to =
get
> static logging to work, what can possibly be wrong with exposing a
> non-static logging mechanism to FOray? Right now, FOray doesn't care whet=
her
> static or non-static logging is used. Why should it?

Exactly. Why should it? If you remove all logging concerns from the work
interface you don't do any assumptions about how logging is done. The
presence of getPseudoLogger(), though, produces a strong emphasis on
non-static logging.

> Third, lets define the "concern". <important>My understanding of Separati=
on
> of Concerns in this case is that FOrayFont owns the concern that a messag=
e
> needs to be logged, and that the client application owns the concern of h=
ow
> that logging should be accomplished.</important>
>=20
> In order to maintain that Separation of Concerns, one of two things must
> happen:
> 1. The client must tell the component how stuff should be logged.
> 2. The server must tell the client what should be logged.
>=20
> This means some logging-related stuff will appear in the interface betwee=
n
> the two.

Not IMO. It can be an implementation detail. See more below.

> The design considerations are as follows:
> 1. FOrayFont needs to be able to log messages.

For whom? For the developer or for the end-user? Because that's what
I've learned during the past months: That it should be well divided
between the two audiences. The speciality is that the developer doesn't
need a logger per processing run (i.e. non-static logging) and the
end-user often needs more than just pure Strings through a generic
logging interface. Note that this is not yet reality in FOP but I
believe it will be soon.

> 2. FOrayFont needs to be able to work with any client system, regardless =
of
> their preferences on logging.

Nobody challenges that. Due to input from Batik the question is raised
whether such a library should do any logging at all. Don't get me wrong.
I'm all for developer-oriented logging, even in basic libraries. It's
just that I somehow need to find out how to accomodate everyone, like
you intend, too. The complication here is that I needed to bring a new
consideration into play. And we really need to pay attention what we are
talking about: the aXSL API or the FOray implementation. If you read my
message again I specifically talk about aXSL, not FOray.

> I can keep all logging internal to the FOrayFont subsystem, which would m=
ean
> that the client application (FOP) has no control over the logging
> whatsoever. Very bad. FOray has to guess what kind of logger to use, and =
it
> will never be right.

It's not true that it doesn't have control. It's just that (static) logging
is controlled from elsewhere.

> I can expose a logging interface that allows the client application to
> handle logging its own way. This has been the approach used so far.
>=20
> The only other solution is a bit more complex, and IMO, quickly becomes
> ugly. FOrayFont currently asks some client object to implement the
> FontConsumer interface. Instead of having FontConsumer provide a
> PseudoLogger, it could have a method instead that logs messages:
>=20
>     /**
>      * @param level An integer describing the level at which this message
> should be logged,
>      * that is, error, warning, debug, etc.
>      */
>     public void logMessage(String message, int level) ;

That would be worse, IMO.

> The problem here is that I need to then create another interface that has
> something similar that can pass itself to FontServer so that general (not
> document-specific) logging messages can be handled. I also need to create
> one for Graphics, Text, FOTree, etc. I will have 10 or 12 methods in vari=
ous
> interfaces that all do the same thing. This seems silly to me. This begs =
for
> a type to do this, which the Avalon Logger interface provided and which
> PseudoLogger provides as well.
>
> Further, does a logMessage() method still expose logging functionality in=
 a
> way that is objectionable to you and to Batik?

Yes. IMO the API should not expose any aspect of logging, only pure work
functionality. An implementation of the API, on the other side, will
then expose any technical means (methods, config files...) to
configure/control logging. Do you find logging aspects in APIs like DOM,
JAXP, JDBC, EJB etc.? No, I don't think so. But any DOM implementation,
or JDBC driver or Enterprise Java Bean is allowed to do logging of some
sort and there are ways/approaches to configure it. Or take my JAXG. It
doesn't care about how and if (developer-oriented) logging is done. Only
the implementations define ways to control that if they support it. That
is the key point!

> > Now, I know this has the potential to spark a heated debate=20
> > again and it raises question marks about the FOrayFont=20
> > integration, but ATM I really don't know what to do about it=20
> > right now. I just realized we have a problem here. I/we made=20
> > promises on general@xmlgraphics.apache.org to try to remove=20
> > logging and other external dependencies (like Avalon) for the=20
> > common components because that's something which is very=20
> > important to the Batik side.
>=20
> So, then, how are those components supposed to log anything? Or, if they =
are
> to log using their own static stuff, how can this be configured by the
> client?

Eventually such basic libraries shouldn't log anything anymore. That's
the big dilemma I'm sitting in, the one I need to find a way out of.
Anyway, ways to remove the necessity to log are: unit tests and
stabilization. The problem is getting rid of something so extremely
handy but actually completely unnecessary for something basic like a PDF
or font library. But I'd never want to get rid of the ability to log in
a complex system like a layout engine.

> > Maybe we could have two different implementations of the=20
> > PDFTextElementBridge so Batik can do native text rendering in=20
> > a different way than FOP but there's still the PDF library=20
> > that depends largely on the font subsystem. But maybe this=20
> > could be handled in a similar way. I need to investigate that=20
> > a little more.
>=20
> I'll be glad to help any way I can, and at this stage FOray can be flexib=
le.
> But I must admit that I don't follow the logic. I need for someone to do =
one
> of the following:
> 1. explain which of the two design considerations listed above you would
> have your components abandon

=46rom my POV as a developer in general: none of them.
=46rom my POV as the one who pushes for XML Graphics Commons: both.

See my problem?

> 2. suggest a solution that allows *both* design considerations to be
> retained, but does not have the client either doing the logging or tellin=
g
> the component how to do the logging.

Let logging be entirely an implementation detail, not a part of the
functional API.

> I still find myself learning new tricks,

Me too! Me tooooo!

> so perhaps there is some other
> elegant alternative that I am simply too blind to yet see.

We don't need a solution right now. I would just like you to think about
removing logging as an aspect of the aXSL APIs. That would make things
easier. But it's also just an aspect of my general view of API design.
It actually doesn't have so much to do with Batik and XML Graphics
Commons.

I just needed to raise the overall concern about external dependencies
because of what Thomas said in our discussion about XML Graphics Commons
and because of the stuff we voted on. We don't have to find a solution
today. I don't even have time for that right now. I can't continue with
moving the main components to Commons right now anyway because I need to
wait for what Vincent is doing. Furthermore, I want to get that first
preview release out of the door and that can't happen with XML Graphics
Commons. It's too late for that.

> The deeper question here is whether it is really wise to avoid all extern=
al
> dependencies. FOray is invested heavily in the idea that reusability is A
> Good Thing. My sense is that FOP still struggles with this question.

I usually don't use external dependencies without considering all the
consequences. I'm all for reuse. The problem is that we found out that Bati=
k
and FOP have an extremely differing views on these things and we decided
to start sharing (PDF lib etc.) and transferring (Transcoders)
components inside the XML Graphics project. This has some consequences.
As I said, I just wanted everyone to know that there are issues that
will need to be dealt with someday but we don't have to do it right now.
If there's an obvious solution, good, but I don't see it right now.


Jeremias Maerki