You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Eric SCHAEFFER <es...@posterconseil.com> on 2000/08/07 18:19:07 UTC
Important changes in FOP
Hi,
I'm working on image handling.
I've integrated Pankaj Narula work (package to read image headers: images
are no longer loaded and kept in memory during the layout process), it seems
to work well.
I'm also working on the configuration problem (I need a config file for the
image classes). I use the avalon package, like Cocoon 2 does. But I need to
modify all FO objects, to make them have access to the Driver (or
FOTreeBuilder) class: the Driver class can load a confi file, but FO objects
need to access this configuration.
In fact, in Cocoon, all components are constructed with a "manager" that is
a kind of Hashtable. If a component needs to have access to the parser, it
calls manager.getComponent("parser").
I think it's a better solution, and want to use it for FOP.
Any comments, suggestions, ... ?
PS: I'm still working on it, but I commit my work in a few days.
Eric.
Avalon (Was: Important changes in FOP)
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
I think I've understand something:
If you use components by role, you just give the class name in parameter,
and the component manager will create a new instance at each request.
If you use components by name, the component manager will return a single
instance (that will be shared).
Am I right ?
And I've got another question:
If you want to give parameters to a component, you write, in the config
file, something like
<parameter name="..." value="..."/>
But if you want to give it a list of classes, without "names", what is the
"good" way of doing it ?
Ex.:
ImageReaders are classes that read image headers, check if it is an
image type it can handle, and read the width and height.
<component role="image-reader-factory"
class="org.apache.fop.image.analyser.ImageReaderFactory">
<image-reader class="org.apache.fop.image.analyser.GIFReader"/>
<image-reader class="org.apache.fop.image.analyser.JPEGReader"/>
<image-reader class="org.apache.fop.image.analyser.PNGReader"/>
<image-reader class="org.apache.fop.image.analyser.BMPReader"/>
</component>
This factory needs parameters, but it's just a list of classes, and not
named parameters.
Eric.
Re: Important changes in FOP
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <fo...@xml.apache.org>
Sent: Tuesday, August 08, 2000 4:45 PM
Subject: Re: Important changes in FOP
> Eric SCHAEFFER wrote:
> >
> > Hi,
> >
> > I'm working on image handling.
> > I've integrated Pankaj Narula work (package to read image headers:
images
> > are no longer loaded and kept in memory during the layout process), it
seems
> > to work well.
> > I'm also working on the configuration problem (I need a config file for
the
> > image classes). I use the avalon package, like Cocoon 2 does. But I need
to
> > modify all FO objects, to make them have access to the Driver (or
> > FOTreeBuilder) class: the Driver class can load a confi file, but FO
objects
> > need to access this configuration.
> > In fact, in Cocoon, all components are constructed with a "manager" that
is
> > a kind of Hashtable. If a component needs to have access to the parser,
it
> > calls manager.getComponent("parser").
> > I think it's a better solution, and want to use it for FOP.
>
> YES!!! Please do!!!
Ok, but I will need a little help. I've got difficulties understanding the
Avalon component model.
1- Does the component manager create a new instance of the requested
component on each getComponent() call, or does it only return an already
created instance (during initialization) ?
2- What is the difference between Component and NamedComponent, which one to
choose and why ?
In fact, my problem is that, during the layouting process, I need to get an
ImageFactory instance to determine the image type and load it correctly. But
this image factory instance can be shared by all FO objects, and it will be
stupid to create a new instance each time we need to access it.
But I understand that for a "parser" component, it would be better that
getComponent() return a new instance...
>
> Fotis, once this is implemented, we could solve the messaging problem by
> doing
>
> manager.getComponent("messager");
>
> instead of having to use static methods.
>
> I've tried to use your messaging API and they work perfectly on a single
> instance, but are a cuncurrency and security nightmare on the server
> side where multiple FOP may exist in the same address space.
>
I've got static method also in FopImageFactory, and PDFXObject...
(want to remove them)
> > Any comments, suggestions, ... ?
>
> The key would be to use AspectJ, but it's far from being stable enough
> to base a real project on.
>
What is AspectJ ?
> > PS: I'm still working on it, but I commit my work in a few days.
>
> +1 on using the Avalon internal component model for FOP as well, even if
> this requires to change lots of objects around.
>
I'm also +1, but I don't know if I can do it alone
:-(
Eric.
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
Re: Important changes in FOP
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: "Fotis Jannidis" <fo...@lrz.uni-muenchen.de>
To: <fo...@xml.apache.org>
Sent: Wednesday, August 09, 2000 8:02 PM
Subject: Re: Important changes in FOP
> From: Stefano Mazzocchi <st...@apache.org>
>
> > Fotis, once this is implemented, we could solve the messaging problem by
> > doing
> >
> > manager.getComponent("messager");
> >
> > instead of having to use static methods.
> >
> > I've tried to use your messaging API and they work perfectly on a single
> > instance, but are a concurrency and security nightmare on the server
> > side where multiple FOP may exist in the same address space.
>
> Stefano, do you think static methods are generally a problem in server
context or just
> when they are transporting different 'content' like System.out.print(),
that is if their
> variables can have different values? As you probably know they are used at
the very
> core of the Fop design, because every flow object has a static inner class
(Maker) and
> this has a static method make().
I don't think Maker inner classes cause problem. It's just a convenient way
to create a new object and initialize it. It doesn't contain or use data for
the current "fop session".
Yet factory or messaging classes shouldn't be static or have static methods.
Eric.
>
> Fotis
>
>
Re: Important changes in FOP
Posted by Stefano Mazzocchi <st...@apache.org>.
Fotis Jannidis wrote:
>
> From: Stefano Mazzocchi <st...@apache.org>
>
> > Fotis, once this is implemented, we could solve the messaging problem by
> > doing
> >
> > manager.getComponent("messager");
> >
> > instead of having to use static methods.
> >
> > I've tried to use your messaging API and they work perfectly on a single
> > instance, but are a concurrency and security nightmare on the server
> > side where multiple FOP may exist in the same address space.
>
> Stefano, do you think static methods are generally a problem in server context or just
> when they are transporting different 'content' like System.out.print(), that is if their
> variables can have different values? As you probably know they are used at the very
> core of the Fop design, because every flow object has a static inner class (Maker) and
> this has a static method make().
I might be entirely wrong (I admit my ignorance on the FOP internals),
but I don't see a problem here since it is _never_ the case that
different FOP instances in the same JVM have different static inner
classes, so, in this case, it helps reducing memory consumption since
both instances use the same static methods since both _have_ to use the
same.
The logging issue is entirely different since the two instances must
_NOT_ share the same logging channel.
Hope it helps.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Important changes in FOP
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
From: Stefano Mazzocchi <st...@apache.org>
> Fotis, once this is implemented, we could solve the messaging problem by
> doing
>
> manager.getComponent("messager");
>
> instead of having to use static methods.
>
> I've tried to use your messaging API and they work perfectly on a single
> instance, but are a concurrency and security nightmare on the server
> side where multiple FOP may exist in the same address space.
Stefano, do you think static methods are generally a problem in server context or just
when they are transporting different 'content' like System.out.print(), that is if their
variables can have different values? As you probably know they are used at the very
core of the Fop design, because every flow object has a static inner class (Maker) and
this has a static method make().
Fotis
Re: Important changes in FOP
Posted by Stefano Mazzocchi <st...@apache.org>.
Eric SCHAEFFER wrote:
>
> Hi,
>
> I'm working on image handling.
> I've integrated Pankaj Narula work (package to read image headers: images
> are no longer loaded and kept in memory during the layout process), it seems
> to work well.
> I'm also working on the configuration problem (I need a config file for the
> image classes). I use the avalon package, like Cocoon 2 does. But I need to
> modify all FO objects, to make them have access to the Driver (or
> FOTreeBuilder) class: the Driver class can load a confi file, but FO objects
> need to access this configuration.
> In fact, in Cocoon, all components are constructed with a "manager" that is
> a kind of Hashtable. If a component needs to have access to the parser, it
> calls manager.getComponent("parser").
> I think it's a better solution, and want to use it for FOP.
YES!!! Please do!!!
Fotis, once this is implemented, we could solve the messaging problem by
doing
manager.getComponent("messager");
instead of having to use static methods.
I've tried to use your messaging API and they work perfectly on a single
instance, but are a cuncurrency and security nightmare on the server
side where multiple FOP may exist in the same address space.
> Any comments, suggestions, ... ?
The key would be to use AspectJ, but it's far from being stable enough
to base a real project on.
> PS: I'm still working on it, but I commit my work in a few days.
+1 on using the Avalon internal component model for FOP as well, even if
this requires to change lots of objects around.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Important changes in FOP
Posted by Stefano Mazzocchi <st...@apache.org>.
Fotis Jannidis wrote:
>
> Eric:
> > >I'm working on image handling.
> > >I've integrated Pankaj Narula work (package to read image headers: images
> > >are no longer loaded and kept in memory during the layout process), it seems
> > >to work well.
> > >I'm also working on the configuration problem (I need a config file for the
> > >image classes). I use the avalon package, like Cocoon 2 does. But I need to
> > >modify all FO objects, to make them have access to the Driver (or
> > >FOTreeBuilder) class: the Driver class can load a confi file, but FO objects
> > >need to access this configuration.
> > >In fact, in Cocoon, all components are constructed with a "manager" that is
> > >a kind of Hashtable. If a component needs to have access to the parser, it
> > >calls manager.getComponent("parser").
> > >I think it's a better solution, and want to use it for FOP.
> > >
> > >Any comments, suggestions, ... ?
> > >
> > >PS: I'm still working on it, but I commit my work in a few days.
> > >
> > >Eric.
>
> Arved:
> > I absolutely, definitely think this should be part of FOP_0_15_0. I'm
> > releasing 0_14_0 very shortly and there is no way we want to postpone it
> > anymore.
> >
> > Let's consider your suggestions and upcoming potential commits as being the
> > first flurry of work for 0_15_0.
> >
> > I get the gist of your suggestion. One thing I will definitely agree with
> > is, we need to review and possibly adapt FOP system-wide procedures for
> > accessibility of information. I don't know if what you suggest is the way to
> > do it - I'm not saying it's not. I guess I could stand to see more
> > discussion on this point.
Of course, my +1 goes for 0_15 not before.
> Eric,
> I am not familiar with the Cocoon2 design and have a few questions regarding avalon.
> I had a (short) look at the avalon documentation <http://java.apache.org/framework/>. If
> I understand it correctly this is a server framework. Could you explain, why you think we
> need it?
Avalon is a server framework, true, but contains two component models:
one for servers, and one for server blocks.
A block is, more or less, a collection of objects that implements a
particular logic.
FOP is, in Avalon sense, a Block. Cocoon core is as well.
A server is composed of one or more blocks.
But Avalon has another component model used to componentize blocks, this
is what Cocoon2 currently uses and it's not related to the server side
at all, it's just a collection of classes that simplify the creation of
highly componentized applications (or blocks, for Avalon).
> Or do you just use the configuration part of it? Isn't this linked with a redesign,
> a partitioning in blocks and components?
Yes, it's already there. You may decide to make FOP implement Block to
make it Avalon-aware, but if you don't there is no overhead and FOP may
live well without having anything to do with Avalon itself.
> At the first look, it sounds like quite a overhead for Fop.
No, rather the opposite: it will make it much easier to developers to
understand FOP internals once they are used to the internal Avalon
component model.
> Going this way could also be a way to handle the MessageHandler problem in a better
> way. Stefano warned against the use of static methods in the context of web
> applications, but then I wanted to avoid the overhead, which is necessary for other
> solutions. If we need it anyway for the configuration design... And we need a
> configuration framework also for other aspects like adding user fonts.
Totally correct, so this is why I strongly suggest you guys to consider
the Avalon internal component model as a solution for your configuration
and component communication problems.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Important changes in FOP
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
I'm not familiar with Avalon too. But I wrote a producer for Cocoon and
played a bit with the Cocoon configuration framwork a few month ago.
These configuration classes have been moved to Avalon (and improved), and
are used in Cocoon2. I find the Avalon configuration architecture very good
(but a bit difficult to understand and apply to FOP - blocks, components,
named components, which one to choose...).
Of course, I don't think we need the "service/server" part of Avalon (for
now), and I didn't look at it. But if we want to make FOP configurable, I
think Avalon is a good candidate and doesn't introduce so much overhead.
No ?
Eric.
----- Original Message -----
From: "Fotis Jannidis" <fo...@lrz.uni-muenchen.de>
To: <fo...@xml.apache.org>
Sent: Tuesday, August 08, 2000 12:20 PM
Subject: Re: Important changes in FOP
> Eric,
> I am not familiar with the Cocoon2 design and have a few questions
regarding avalon.
> I had a (short) look at the avalon documentation
<http://java.apache.org/framework/>. If
> I understand it correctly this is a server framework. Could you explain,
why you think we
> need it? Or do you just use the configuration part of it? Isn't this
linked with a redesign,
> a partitioning in blocks and components? At the first look, it sounds like
quite a overhead
> for Fop.
> Going this way could also be a way to handle the MessageHandler problem in
a better
> way. Stefano warned against the use of static methods in the context of
web
> applications, but then I wanted to avoid the overhead, which is necessary
for other
> solutions. If we need it anyway for the configuration design... And we
need a
> configuration framework also for other aspects like adding user fonts.
> Fotis
>
>
Re: Important changes in FOP
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
Eric:
> >I'm working on image handling.
> >I've integrated Pankaj Narula work (package to read image headers: images
> >are no longer loaded and kept in memory during the layout process), it seems
> >to work well.
> >I'm also working on the configuration problem (I need a config file for the
> >image classes). I use the avalon package, like Cocoon 2 does. But I need to
> >modify all FO objects, to make them have access to the Driver (or
> >FOTreeBuilder) class: the Driver class can load a confi file, but FO objects
> >need to access this configuration.
> >In fact, in Cocoon, all components are constructed with a "manager" that is
> >a kind of Hashtable. If a component needs to have access to the parser, it
> >calls manager.getComponent("parser").
> >I think it's a better solution, and want to use it for FOP.
> >
> >Any comments, suggestions, ... ?
> >
> >PS: I'm still working on it, but I commit my work in a few days.
> >
> >Eric.
Arved:
> I absolutely, definitely think this should be part of FOP_0_15_0. I'm
> releasing 0_14_0 very shortly and there is no way we want to postpone it
> anymore.
>
> Let's consider your suggestions and upcoming potential commits as being the
> first flurry of work for 0_15_0.
>
> I get the gist of your suggestion. One thing I will definitely agree with
> is, we need to review and possibly adapt FOP system-wide procedures for
> accessibility of information. I don't know if what you suggest is the way to
> do it - I'm not saying it's not. I guess I could stand to see more
> discussion on this point.
Eric,
I am not familiar with the Cocoon2 design and have a few questions regarding avalon.
I had a (short) look at the avalon documentation <http://java.apache.org/framework/>. If
I understand it correctly this is a server framework. Could you explain, why you think we
need it? Or do you just use the configuration part of it? Isn't this linked with a redesign,
a partitioning in blocks and components? At the first look, it sounds like quite a overhead
for Fop.
Going this way could also be a way to handle the MessageHandler problem in a better
way. Stefano warned against the use of static methods in the context of web
applications, but then I wanted to avoid the overhead, which is necessary for other
solutions. If we need it anyway for the configuration design... And we need a
configuration framework also for other aspects like adding user fonts.
Fotis
Re: Important changes in FOP
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
Ok, no commit untill the next release.
For configuration, have look at Avalon (http://java.apache.org, cvs
repository: framework) and Cocoon2.
Eric.
----- Original Message -----
From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
To: <fo...@xml.apache.org>
Cc: <fo...@xml.apache.org>
Sent: Tuesday, August 08, 2000 11:25 AM
Subject: Re: Important changes in FOP
> At 06:19 PM 8/7/00 +0200, Eric SCHAEFFER wrote:
> >Hi,
> >
> >I'm working on image handling.
> >I've integrated Pankaj Narula work (package to read image headers: images
> >are no longer loaded and kept in memory during the layout process), it
seems
> >to work well.
> >I'm also working on the configuration problem (I need a config file for
the
> >image classes). I use the avalon package, like Cocoon 2 does. But I need
to
> >modify all FO objects, to make them have access to the Driver (or
> >FOTreeBuilder) class: the Driver class can load a confi file, but FO
objects
> >need to access this configuration.
> >In fact, in Cocoon, all components are constructed with a "manager" that
is
> >a kind of Hashtable. If a component needs to have access to the parser,
it
> >calls manager.getComponent("parser").
> >I think it's a better solution, and want to use it for FOP.
> >
> >Any comments, suggestions, ... ?
> >
> >PS: I'm still working on it, but I commit my work in a few days.
> >
> >Eric.
>
> I absolutely, definitely think this should be part of FOP_0_15_0. I'm
> releasing 0_14_0 very shortly and there is no way we want to postpone it
> anymore.
>
> Let's consider your suggestions and upcoming potential commits as being
the
> first flurry of work for 0_15_0.
>
> I get the gist of your suggestion. One thing I will definitely agree with
> is, we need to review and possibly adapt FOP system-wide procedures for
> accessibility of information. I don't know if what you suggest is the way
to
> do it - I'm not saying it's not. I guess I could stand to see more
> discussion on this point.
>
> Regards, Arved
>
> Senior Developer
> e-plicity.com (www.e-plicity.com)
> Halifax, Nova Scotia
> "B2B Wireless in Canada's Ocean Playground"
>
Re: Important changes in FOP
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 06:19 PM 8/7/00 +0200, Eric SCHAEFFER wrote:
>Hi,
>
>I'm working on image handling.
>I've integrated Pankaj Narula work (package to read image headers: images
>are no longer loaded and kept in memory during the layout process), it seems
>to work well.
>I'm also working on the configuration problem (I need a config file for the
>image classes). I use the avalon package, like Cocoon 2 does. But I need to
>modify all FO objects, to make them have access to the Driver (or
>FOTreeBuilder) class: the Driver class can load a confi file, but FO objects
>need to access this configuration.
>In fact, in Cocoon, all components are constructed with a "manager" that is
>a kind of Hashtable. If a component needs to have access to the parser, it
>calls manager.getComponent("parser").
>I think it's a better solution, and want to use it for FOP.
>
>Any comments, suggestions, ... ?
>
>PS: I'm still working on it, but I commit my work in a few days.
>
>Eric.
I absolutely, definitely think this should be part of FOP_0_15_0. I'm
releasing 0_14_0 very shortly and there is no way we want to postpone it
anymore.
Let's consider your suggestions and upcoming potential commits as being the
first flurry of work for 0_15_0.
I get the gist of your suggestion. One thing I will definitely agree with
is, we need to review and possibly adapt FOP system-wide procedures for
accessibility of information. I don't know if what you suggest is the way to
do it - I'm not saying it's not. I guess I could stand to see more
discussion on this point.
Regards, Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"