You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Eric SCHAEFFER <es...@posterconseil.com> on 2000/08/10 10:28:51 UTC
Avalon explainations
Hi,
I work on FOP, and I'd like to make it Avalon aware. Can someone explain to
me how Avalon configuration framework should be used ?
I've got several questions:
1- Does the component manager should create a new instance of the requested
component on each getComponent() method call, or does it should 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 FO -> "internal representation"
process (layouting process), I need to use a factory class instance. This
factory instance is initialized by a configuration file, but it would be
stupid to create a new instance of this class each time I want to use it...
On the other hand, I understand that for a "parser" component, it would be
better that
getComponent() return a new instance...
3- 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 of the image.
<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.
Thank's,
Eric.
Re: Avalon explainations
Posted by "Pier P. Fumagalli" <pi...@apache.org>.
I'm not on the Avalon mailing list, but Fede might give some insights...
Fede? - That rat is playing Dune 2000 in his room right now... :) :) :)
Pier
Eric SCHAEFFER wrote:
>
> Hi,
>
> I work on FOP, and I'd like to make it Avalon aware. Can someone explain to
> me how Avalon configuration framework should be used ?
>
> I've got several questions:
>
> 1- Does the component manager should create a new instance of the requested
> component on each getComponent() method call, or does it should 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 FO -> "internal representation"
> process (layouting process), I need to use a factory class instance. This
> factory instance is initialized by a configuration file, but it would be
> stupid to create a new instance of this class each time I want to use it...
>
> On the other hand, I understand that for a "parser" component, it would be
> better that
> getComponent() return a new instance...
>
> 3- 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 of the image.
>
> <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.
>
> Thank's,
> Eric.
Re: Avalon explainations
Posted by Berin Loritsch <bl...@infoplanning.com>.
Eric SCHAEFFER wrote:
> > Inside the ImageReaderFactory, you can access the image-readers through
> > a NamedComponentManager using the class names as the type (unless you
> > wanted a shorter name). The framework assists in many areas, but
> > be careful to use the right tool for the right job.
> >
> I'm not sure to understand you.
>
> My ImageReaderFactory uses a list of classes that implement the ImageReader
> interface. It only asks each of its ImageReader instances to try to read the
> image headers. If an ImageReader instance can read it, the image is of the
> type the ImageReader can handle. For a Gif image, there's only one
> ImageReader class. But using a configurable factory enable users to add
> their own image readers (for other image types by example).
In that case, you don't really need the NamedComponentManager for what you
are doing. For this purpose the Factory pattern is better than Component
Manager pattern.
Yes using a configurable factory does enable users to add their own image
readers, and there are a number of ways of accomplishing the task of adding
handlers. I need to incorporate a package browser utility to the Avalon
framework that you would be able to specify that every class within a package
would be an ImageReader (it will probably have a sanity check to see if the
class implements or extends a specified interface/class).
But, being strapped for time....
I do have some code to start with that can be updated.
Re: Avalon explainations
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@infoplanning.com>
To: <co...@xml.apache.org>
Sent: Thursday, August 10, 2000 2:59 PM
Subject: Re: Avalon explainations
> donaldp@mad.scientist.com wrote:
> >
> > On Thu, 10 Aug 2000, Eric SCHAEFFER wrote:
> > > I work on FOP, and I'd like to make it Avalon aware. Can someone
explain to
> > > me how Avalon configuration framework should be used ?
> >
> > Unfortunately at this current moment the Avalon list is
> > going through it. There are some parties who would remove
> > the Configuration interface completely and do everything
> > through JNDI.
> >
> > I am trying to stop that but unfortunately I am lone in my
> > venture so it looks like all Configuration and
> > ComponentManager could be dropped soon.
>
> These statements only hold true for the Block level. Within a
> Block we will still use the familiar framework that Cocoon uses.
>
> > > I've got several questions:
> > >
> > > 3- 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 of the image.
> > >
> > > <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.
> >
> > Unfortunately there is no "good" way of doing it. Actually
> > there is very little way of doing it all with
> > ComponentManagers. I need this functionality for my app so I
> > am trying to get this put into a ComponentManager but I keep
> > getting told it is bad design practice :<. Thou I will still
> > work on them to try and get it allowed :D.
>
> If the ImageReader classes read the image's header to determine which
> type of image it is, then it would probably be best to return the
> ImageReaderFactory class from a ComponentManager.
>
Sure...
> Inside the ImageReaderFactory, you can access the image-readers through
> a NamedComponentManager using the class names as the type (unless you
> wanted a shorter name). The framework assists in many areas, but
> be careful to use the right tool for the right job.
>
I'm not sure to understand you.
My ImageReaderFactory uses a list of classes that implement the ImageReader
interface. It only asks each of its ImageReader instances to try to read the
image headers. If an ImageReader instance can read it, the image is of the
type the ImageReader can handle. For a Gif image, there's only one
ImageReader class. But using a configurable factory enable users to add
their own image readers (for other image types by example).
So, parameters are really a list of classes, of type ImageReader.
> The point is do what works. I don't forsee the ComponentManager classes
> being removed from within blocks any time soon.
>
Ouf...
Eric.
Re: Avalon explainations
Posted by Berin Loritsch <bl...@infoplanning.com>.
donaldp@mad.scientist.com wrote:
>
> On Thu, 10 Aug 2000, Eric SCHAEFFER wrote:
> > I work on FOP, and I'd like to make it Avalon aware. Can someone explain to
> > me how Avalon configuration framework should be used ?
>
> Unfortunately at this current moment the Avalon list is
> going through it. There are some parties who would remove
> the Configuration interface completely and do everything
> through JNDI.
>
> I am trying to stop that but unfortunately I am lone in my
> venture so it looks like all Configuration and
> ComponentManager could be dropped soon.
These statements only hold true for the Block level. Within a
Block we will still use the familiar framework that Cocoon uses.
> > I've got several questions:
> >
> > 3- 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 of the image.
> >
> > <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.
>
> Unfortunately there is no "good" way of doing it. Actually
> there is very little way of doing it all with
> ComponentManagers. I need this functionality for my app so I
> am trying to get this put into a ComponentManager but I keep
> getting told it is bad design practice :<. Thou I will still
> work on them to try and get it allowed :D.
If the ImageReader classes read the image's header to determine which
type of image it is, then it would probably be best to return the
ImageReaderFactory class from a ComponentManager.
Inside the ImageReaderFactory, you can access the image-readers through
a NamedComponentManager using the class names as the type (unless you
wanted a shorter name). The framework assists in many areas, but
be careful to use the right tool for the right job.
The point is do what works. I don't forsee the ComponentManager classes
being removed from within blocks any time soon.
Re: Avalon explainations
Posted by Paul Russell <pa...@luminas.co.uk>.
On Thu, Aug 10, 2000 at 11:44:30AM +0200, Eric SCHAEFFER wrote:
> What's the advantage of using JNDI ???
> They don't want to use config files anymore ? And what about portability ?
JNDI is portable (part of J2SE as of 1.3), and configuration
files are a missed blessing. Personally I'm not involved in
that discussion, but I can see reasons why JNDI would be
beneficial. A lot of application servers etc have a JNDI SPI
at their core, and all the configuration of components,
location of components & beans is done through this. It works
very well in this situation. Personally, I'd welcome the option
to take a snapshot of the configuration as XML, and import that
at a later date, but I see significant advantages to not having
configuration files as such lying around on servers (unless
they're persisted there by the server itself, anyway).
This is one of those arguments that has the potential to run
and run. In terms of Avalon, I'm not sure what the answer is,
but in terms of the application server architectures I've been
designing, JNDI and similar technologies are an answer to a
difficult problem.
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: Avalon explainations
Posted by do...@mad.scientist.com.
> > Unfortunately at this current moment the Avalon list is
> > going through it. There are some parties who would remove
> > the Configuration interface completely and do everything
> > through JNDI.
> >
>
> ????????????
> What's the advantage of using JNDI ???
> They don't want to use config files anymore ? And what about portability ?
The theory is to load everything through JNDI because that
is a standard. So you would still use config files - jou
could just not use certain patterns like having multiple
elements with same tag name under another tag - ala
<x>
<y/>
<y/>
</x>
There are heaps of other penalties for using the standard
aswell and it kills Avalons Inversion of Control idea. There
is a posibility that you will still be able to get
configurations as they are now. Thou instead of implementing
Configurable you will instead have to do something like
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.avalon.engine.BlockFactory");
env.put(Context.PROVIDER_URL, "avalon://localhost/cocoon");
env.put(AvalonContext.SRC_COMPONENT, this);
Context context = new InitialContext( env );
Configuration conf = (Configuration)context.lookup("comp/env");
and then proceed as you do now.
Needless to say I ain't thrilled with that way or also other
restrictions (like you can't do this from non-primordial
classloader due to bug in JNDI).
> > I am trying to stop that but unfortunately I am lone in my
> > venture so it looks like all Configuration and
> > ComponentManager could be dropped soon.
>
> I really don't understand why....
nor I.
Cheers,
Pete
*--------------------------------------------------*
| Latrobe University, | |
| Bundoora, Australia | Does the name 'Pavlov' |
| Office: PW220 | ring a bell ? |
| Ex: 2503 | |
*--------------------------------------------------*
Re: Avalon explainations
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: <do...@mad.scientist.com>
To: <co...@xml.apache.org>
Sent: Thursday, August 10, 2000 11:06 AM
Subject: Re: Avalon explainations
> On Thu, 10 Aug 2000, Eric SCHAEFFER wrote:
> > I work on FOP, and I'd like to make it Avalon aware. Can someone explain
to
> > me how Avalon configuration framework should be used ?
>
> Unfortunately at this current moment the Avalon list is
> going through it. There are some parties who would remove
> the Configuration interface completely and do everything
> through JNDI.
>
????????????
What's the advantage of using JNDI ???
They don't want to use config files anymore ? And what about portability ?
> I am trying to stop that but unfortunately I am lone in my
> venture so it looks like all Configuration and
> ComponentManager could be dropped soon.
I really don't understand why....
>
> In which case it may be best to hold off converting FOP just
> yet to see the outcome.
>
> > I've got several questions:
> >
> > 1- Does the component manager should create a new instance of the
requested
> > component on each getComponent() method call, or does it should only
return
> > an already
> > created instance (during initialization) ?
>
> A ComponentManager just associates particular component
> roles with a component. Usually that means a simple lookup
> in a hashtable or iteration over already existing
> components. The avalon SimpleComponentManager simply looks
> in a hastable and if found it returns it. Otherwise it
> checks if it has a parent ComponentManager and returns the
> role in it's parent's context. This allows a hierarchy of
> component managers.
>
> So really it should only return created instances but if
> there is a particular reason to not behave this way it is
> possible for you to change this. Cocoon itself is the
> ComponentManager and it dynamically creates new components
> during lookup IIRC. However ideally you should populate it
> before you pass it to the component.
>
> > 2- What is the difference between Component and NamedComponent, which
one to
> > choose and why ?
>
> NamedComponent is useful when you have multiple components
> that have same role. For instance Cocoon has multiple
> generators. A normal ComponentManager can't determine the
> difference between all of them, but if you give them names
> you can extract a particular named component from manager.
>
> > In fact, my problem is that, during the FO -> "internal representation"
> > process (layouting process), I need to use a factory class instance.
This
> > factory instance is initialized by a configuration file, but it would be
> > stupid to create a new instance of this class each time I want to use
it...
>
> Sounds like it is crying out for the lazy singlton design
> pattern. ie
>
> class MyClass {
>
> protected static MyClass singleton;
>
> public MyClass getMyClass() {
> if( null == singleton ) {
> singleton = createMyClass();
> }
> return singleton;
> }
>
> > On the other hand, I understand that for a "parser" component, it would
be
> > better that
> > getComponent() return a new instance...
>
> ComponentManager wouldn't be the right place to get a parser
> then. The ComponentManager may return a factory that you can
> use to create Parsers and that would be an acceptable way to
> use it.
>
> >
> > 3- 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 of the image.
> >
> > <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.
>
> Unfortunately there is no "good" way of doing it. Actually
> there is very little way of doing it all with
> ComponentManagers. I need this functionality for my app so I
> am trying to get this put into a ComponentManager but I keep
> getting told it is bad design practice :<. Thou I will still
> work on them to try and get it allowed :D.
>
> Cheers,
>
> Pete
>
> *--------------------------------------------------*
> | Latrobe University, | |
> | Bundoora, Australia | Does the name 'Pavlov' |
> | Office: PW220 | ring a bell ? |
> | Ex: 2503 | |
> *--------------------------------------------------*
>
Thank's a lot.
Eric.
Re: Avalon explainations
Posted by do...@mad.scientist.com.
On Thu, 10 Aug 2000, Eric SCHAEFFER wrote:
> I work on FOP, and I'd like to make it Avalon aware. Can someone explain to
> me how Avalon configuration framework should be used ?
Unfortunately at this current moment the Avalon list is
going through it. There are some parties who would remove
the Configuration interface completely and do everything
through JNDI.
I am trying to stop that but unfortunately I am lone in my
venture so it looks like all Configuration and
ComponentManager could be dropped soon.
In which case it may be best to hold off converting FOP just
yet to see the outcome.
> I've got several questions:
>
> 1- Does the component manager should create a new instance of the requested
> component on each getComponent() method call, or does it should only return
> an already
> created instance (during initialization) ?
A ComponentManager just associates particular component
roles with a component. Usually that means a simple lookup
in a hashtable or iteration over already existing
components. The avalon SimpleComponentManager simply looks
in a hastable and if found it returns it. Otherwise it
checks if it has a parent ComponentManager and returns the
role in it's parent's context. This allows a hierarchy of
component managers.
So really it should only return created instances but if
there is a particular reason to not behave this way it is
possible for you to change this. Cocoon itself is the
ComponentManager and it dynamically creates new components
during lookup IIRC. However ideally you should populate it
before you pass it to the component.
> 2- What is the difference between Component and NamedComponent, which one to
> choose and why ?
NamedComponent is useful when you have multiple components
that have same role. For instance Cocoon has multiple
generators. A normal ComponentManager can't determine the
difference between all of them, but if you give them names
you can extract a particular named component from manager.
> In fact, my problem is that, during the FO -> "internal representation"
> process (layouting process), I need to use a factory class instance. This
> factory instance is initialized by a configuration file, but it would be
> stupid to create a new instance of this class each time I want to use it...
Sounds like it is crying out for the lazy singlton design
pattern. ie
class MyClass {
protected static MyClass singleton;
public MyClass getMyClass() {
if( null == singleton ) {
singleton = createMyClass();
}
return singleton;
}
> On the other hand, I understand that for a "parser" component, it would be
> better that
> getComponent() return a new instance...
ComponentManager wouldn't be the right place to get a parser
then. The ComponentManager may return a factory that you can
use to create Parsers and that would be an acceptable way to
use it.
>
> 3- 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 of the image.
>
> <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.
Unfortunately there is no "good" way of doing it. Actually
there is very little way of doing it all with
ComponentManagers. I need this functionality for my app so I
am trying to get this put into a ComponentManager but I keep
getting told it is bad design practice :<. Thou I will still
work on them to try and get it allowed :D.
Cheers,
Pete
*--------------------------------------------------*
| Latrobe University, | |
| Bundoora, Australia | Does the name 'Pavlov' |
| Office: PW220 | ring a bell ? |
| Ex: 2503 | |
*--------------------------------------------------*