You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/09/28 18:09:36 UTC
single instance per context on avalon components
Working for finishing up the gallery code, I've come into the need to
share the instance of an avalon component between two cocoon pipeline
components, respectively a transformer and a generator.
This is the same need of the FragmentExtractor generator/transformer
pair: one collects information at transformation stage and stores this
information for later retrieval at generation stage. It's not a common
need, but I assume this will turn out very useful for complex operations
like pagination and path expansion (which is why I need this).
So, my code compiles and does what it should: the problem is that the
two sitemap components (the generator and the transformer) get two
different instances of the component so one stores correctly and the
other retrieves correctly, the problem is that it never retrieves
anything since it's the other instance that gets filled with data :(
how do I share a component without using static methods?
(oh, BTW, the FragmentExtractor is buggy in that respect since it uses a
static hashtable instead of using a shared component, this could well
create problems on situations where more than one cocoon is run in the
same JVM! please, kill all static instances!)
Thanks much in advance.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: single instance per context on avalon components
Posted by Berin Loritsch <bl...@apache.org>.
In order for a Component to be instantiated once per ComponentManager,
you must have your Component implement the ThreadSafe interface (which
means your Component must be thread safe).
The ExcaliburComponentManager/ExcaliburComponentSelector apply the
following logic:
1)If a Component implements ThreadSafe then the CM assumes that the
developer knows their stuff, and shares one instance of the Component
with all requestors.
2)If a Component implements Poolable (which is done if you implement
Recyclable), then the CM assumes again that the developer knows their
stuff but creates a pool of Components to share. Each thread gets
a unique instance. This works for 99% of all cases where a thread
needs a unique instance.
3)If a Component implements SingleThreaded then the CM assumes that
the developer knows what they are doing, and that Poolable does not
"cut the mustard" for this Component and it creates a new instance
of the Component for each request. This is used for the 1% of the
time that a thread needs a unique instance, but the instance created
cannot be reused (i.e. the JaxpParser or XercesParser).
4)If a Component does not implement any of the afformentioned interfaces
the CM assumes the developer doesn't know all the details, and it treats
the Component as if it had implemented SingleThreaded.
5)If the developer explicitly adds a component to the CM before it is
initialized (after initialization the CM is "locked"), then the CM
assumes that the developer is managing the Component and that it is
ThreadSafe.
The last two cases are the safest assumptions concidering the context
that they are used within. In 4, the CM makes no assumptions about
the code. In 5, the CM assumes the Component is not to be managed by
it.
Stefano Mazzocchi wrote:
>
> Working for finishing up the gallery code, I've come into the need to
> share the instance of an avalon component between two cocoon pipeline
> components, respectively a transformer and a generator.
>
> This is the same need of the FragmentExtractor generator/transformer
> pair: one collects information at transformation stage and stores this
> information for later retrieval at generation stage. It's not a common
> need, but I assume this will turn out very useful for complex operations
> like pagination and path expansion (which is why I need this).
>
> So, my code compiles and does what it should: the problem is that the
> two sitemap components (the generator and the transformer) get two
> different instances of the component so one stores correctly and the
> other retrieves correctly, the problem is that it never retrieves
> anything since it's the other instance that gets filled with data :(
>
> how do I share a component without using static methods?
>
> (oh, BTW, the FragmentExtractor is buggy in that respect since it uses a
> static hashtable instead of using a shared component, this could well
> create problems on situations where more than one cocoon is run in the
> same JVM! please, kill all static instances!)
>
> Thanks much in advance.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: C2/Linux: Problems using current IBM JDK
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Matthew Langham wrote:
>
> Hi Michael,
>
> thanks for your message. We are now testing all combinations :-) and will
> post our results.
>
> Just one question: Which JDK did you use to compile Cocoon?
With the IBM JDK from SuSE7.2:
me@laptop:~ > java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001025 (JIT
enabled: jitc))
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: C2/Linux: Problems using current IBM JDK
Posted by Matthew Langham <ml...@sundn.de>.
Hi Michael,
thanks for your message. We are now testing all combinations :-) and will
post our results.
Just one question: Which JDK did you use to compile Cocoon?
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
Gesendet: Donnerstag, 4. Oktober 2001 14:50
An: cocoon-dev@xml.apache.org
Betreff: Re: C2/Linux: Problems using current IBM JDK
Matthew Langham wrote:
>
> We are currently experimenting with different Java JDKs under SuSE Linux
7.2
> and have a problem with the current IBM JDK.
>
> After compilation the sitemap.class cannot be loaded and we get an
> appopriate error message "Cant find class for ...". Nothing further is
> traced.
>
> We have tried the various switches in web.xml and deleted the Work
directory
> first etc.
>
> Any ideas? Anyone else currently running C2 under Suse Linux with the IBM
> JDK - which version are you using? Any gotchas when switching over from a
> running Sun JDK?
I'm running C2 on SuSE 7.2 with IBM-SDK (v1.3.0 is on the SuSE-CD's).
As I remember, the problem was tomcat. I downloaded tomcat3.2.3
and than it was working. (I never tried it with the Sun-SDK.)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: AW: C2/Linux: Problems using current IBM JDK
Posted by Matthew Langham <ml...@sundn.de>.
Michael,
>>
Compiling Cocoon with the IBM JDK would be the next thing to do - but what
happens if we run that in a SUN JDK - or Blackdown....
<<
Ok we have now tried that as well. Still no luck.
>>
me@laptop:~ > java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001025 (JIT
enabled: jitc))
<<
You are using an older IBM JDK (the current one is: cx130-20010626).
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Matthew Langham [mailto:mlangham@sundn.de]
Gesendet: Freitag, 5. Oktober 2001 15:14
An: cocoon-dev@xml.apache.org
Betreff: AW: AW: C2/Linux: Problems using current IBM JDK
Hi
Compiling Cocoon with the IBM JDK would be the next thing to do - but what
happens if we run that in a SUN JDK - or Blackdown....
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Michael Hartle [mailto:mhartle@hartle-klug.com]
Gesendet: Freitag, 5. Oktober 2001 15:05
An: cocoon-dev@xml.apache.org
Betreff: Re: AW: C2/Linux: Problems using current IBM JDK
Matthew Langham wrote:
>Does anyone have an idea as to why this could be the case?
>
>The effect also remains if we disable the JIT and change the security
policy
>of tomcat.
>
>So we have absolutely no idea what is happening.
>
Have you both build and tested cocoon with each JDK version ? IIRC I
once had a similar problem when I tried to run cocoon with a different
JDK than I had build it.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: AW: C2/Linux: Problems using current IBM JDK
Posted by Matthew Langham <ml...@sundn.de>.
Hi
Compiling Cocoon with the IBM JDK would be the next thing to do - but what
happens if we run that in a SUN JDK - or Blackdown....
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Michael Hartle [mailto:mhartle@hartle-klug.com]
Gesendet: Freitag, 5. Oktober 2001 15:05
An: cocoon-dev@xml.apache.org
Betreff: Re: AW: C2/Linux: Problems using current IBM JDK
Matthew Langham wrote:
>Does anyone have an idea as to why this could be the case?
>
>The effect also remains if we disable the JIT and change the security
policy
>of tomcat.
>
>So we have absolutely no idea what is happening.
>
Have you both build and tested cocoon with each JDK version ? IIRC I
once had a similar problem when I tried to run cocoon with a different
JDK than I had build it.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: C2/Linux: Problems using current IBM JDK
Posted by Michael Hartle <mh...@hartle-klug.com>.
Matthew Langham wrote:
>Does anyone have an idea as to why this could be the case?
>
>The effect also remains if we disable the JIT and change the security policy
>of tomcat.
>
>So we have absolutely no idea what is happening.
>
Have you both build and tested cocoon with each JDK version ? IIRC I
once had a similar problem when I tried to run cocoon with a different
JDK than I had build it.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: C2/Linux: Problems using current IBM JDK
Posted by Matthew Langham <ml...@sundn.de>.
Hi Cocoon'ers
After testing a variety of combinations today here are our findings:
Using an older version of the IBM jdk (build cx130-20000623) Cocoon starts
and everything seems to be fine ...
BUT
The current C2.0 version does not run under Suse Linux using the newest IBM
JVM (IBMjdk1.3.0 build: cx130-20010626). The sitemap is compiled but then
cannot be loaded. This effect does not change by updating Tomcat from 3.2.2
to 3.2.3.
The error we receive is:
>>
description org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org/apache/cocoon/www/sitemap_xmap' due to a
java.lang.ClassNotFoundException: org.apache.cocoon.www.sitemap_xmap
<<
And the stacktrace:
>>
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org/apache/cocoon/www/sitemap_xmap' due to a
java.lang.ClassNotFoundException: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createR
esource(ProgramGeneratorImpl.java:278)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(Pr
ogramGeneratorImpl.java:192)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:208)
at java.lang.Thread.run(Thread.java:498)
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org/apache/cocoon/www/sitemap_xmap' due to a
java.lang.ClassNotFoundException: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProg
ram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguag
e.load(CompiledProgrammingLanguage.java:127)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generat
eResource(ProgramGeneratorImpl.java:324)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createR
esource(ProgramGeneratorImpl.java:275)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(Pr
ogramGeneratorImpl.java:192)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:208)
at java.lang.Thread.run(Thread.java:498)
<<
Does anyone have an idea as to why this could be the case?
The effect also remains if we disable the JIT and change the security policy
of tomcat.
So we have absolutely no idea what is happening.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Enke Michael [mailto:Michael.Enke@wincor-nixdorf.com]
Gesendet: Donnerstag, 4. Oktober 2001 14:50
An: cocoon-dev@xml.apache.org
Betreff: Re: C2/Linux: Problems using current IBM JDK
Matthew Langham wrote:
>
> We are currently experimenting with different Java JDKs under SuSE Linux
7.2
> and have a problem with the current IBM JDK.
>
> After compilation the sitemap.class cannot be loaded and we get an
> appopriate error message "Cant find class for ...". Nothing further is
> traced.
>
> We have tried the various switches in web.xml and deleted the Work
directory
> first etc.
>
> Any ideas? Anyone else currently running C2 under Suse Linux with the IBM
> JDK - which version are you using? Any gotchas when switching over from a
> running Sun JDK?
I'm running C2 on SuSE 7.2 with IBM-SDK (v1.3.0 is on the SuSE-CD's).
As I remember, the problem was tomcat. I downloaded tomcat3.2.3
and than it was working. (I never tried it with the Sun-SDK.)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2/Linux: Problems using current IBM JDK
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Matthew Langham wrote:
>
> We are currently experimenting with different Java JDKs under SuSE Linux 7.2
> and have a problem with the current IBM JDK.
>
> After compilation the sitemap.class cannot be loaded and we get an
> appopriate error message "Cant find class for ...". Nothing further is
> traced.
>
> We have tried the various switches in web.xml and deleted the Work directory
> first etc.
>
> Any ideas? Anyone else currently running C2 under Suse Linux with the IBM
> JDK - which version are you using? Any gotchas when switching over from a
> running Sun JDK?
I'm running C2 on SuSE 7.2 with IBM-SDK (v1.3.0 is on the SuSE-CD's).
As I remember, the problem was tomcat. I downloaded tomcat3.2.3
and than it was working. (I never tried it with the Sun-SDK.)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2/Linux: Problems using current IBM JDK
Posted by Vadim Gritsenko <va...@verizon.net>.
I have Cocoon running on SuSe 7.0, with IBM JDK (one which bundled with WebSphere).
Details are:.
uname -a:
Linux l004090 2.2.16 #6 SMP Wed May 23 16:39:31 EDT 2001 s390 unknown
java -version:
java version "1.2.2"
Classic VM (J2RE 1.2.2 IBM build c390_x122-20001209 (JIT disabled))
Resin-2.0-2, Cocoon 2.0 CVS 20010915.
http://l004090.zseriespenguins.ihost.com/
Regards,
Vadim
> -----Original Message-----
> From: Matthew Langham [mailto:mlangham@sundn.de]
> Sent: Tuesday, October 02, 2001 10:37 AM
> To: cocoon-dev@xml.apache.org
> Subject: C2/Linux: Problems using current IBM JDK
>
>
> We are currently experimenting with different Java JDKs under SuSE Linux 7.2
> and have a problem with the current IBM JDK.
>
> After compilation the sitemap.class cannot be loaded and we get an
> appopriate error message "Cant find class for ...". Nothing further is
> traced.
>
> We have tried the various switches in web.xml and deleted the Work directory
> first etc.
>
> Any ideas? Anyone else currently running C2 under Suse Linux with the IBM
> JDK - which version are you using? Any gotchas when switching over from a
> running Sun JDK?
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
C2/Linux: Problems using current IBM JDK
Posted by Matthew Langham <ml...@sundn.de>.
We are currently experimenting with different Java JDKs under SuSE Linux 7.2
and have a problem with the current IBM JDK.
After compilation the sitemap.class cannot be loaded and we get an
appopriate error message "Cant find class for ...". Nothing further is
traced.
We have tried the various switches in web.xml and deleted the Work directory
first etc.
Any ideas? Anyone else currently running C2 under Suse Linux with the IBM
JDK - which version are you using? Any gotchas when switching over from a
running Sun JDK?
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: single instance per context on avalon components
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> >
> > This is actually I feature I am looking for since weeks, but had never
> > time to finish it....
> >
> > There is of course the ThreadSafe interface from Avalon, but then
> > you have only one single instance in the whole system. That's not
> > suitable for many cases.
> >
> > I would like to add a Cocoon-specific marker interface, similar
> > to the SitemapModelComponent interface (but a different name)
> > >>>
> > public interface RequestModelComponent extends Component {
> > /**
> > * Set the <code>SourceResolver</code>, objectModel <code>Map</code>,
> > * the source and sitemap <code>Parameters</code> used to process the
> > request.
> > */
> > void setup(SourceResolver resolver, Map objectModel) throws
> > ProcessingException;
> > }
> > <<<<
> >
> > The behaviour for this would be:
> > - The first time during a request processing a component marked with
> > this interface is looked up, a new instance is created (or got from
> > the pool) and the setup method is called. This object is stored
> > somewhere so that the ComponentManager has access to it for later
> > requests.
> > - The second, third.. time during the same request this component is
> > looked up, it is get from the store and the setup() method is
> > not looked up
> > - Every time a release is called on this object, nothing really happens
> > - When the request processing is finished, the ComponentManager
> > must really release all stored objects.
> >
> > So actually objects marked in this way are more or less ThreadSafe
> > but per request exists a different instance.
>
> Hmmm, not sure I understand the need for such a behavior. I mean: if you
> don't call setup() in subsequent requests, wouldn't you get into an
> inconsistent state for the environment variables?
>
> Can you make an example of use, I'm probably missing your point.
First and formost I must stress that unless you are using only one method
in a Component, you cannot guarantee it to be threadsafe. (i.e. setUp then
getModel).
Secondly, trying to make setUp() only called on the first invocation of the
Component is not consistent with intended use. The ResourceManager and
objectModel can be different for each request. Especially the objectModel.
You cannot assume they will stay the same for the life of the Component.
Lastly, from the time you look up a Component to the time you release it,
its state is guaranteed to be the same. After you release it, it follows
the rules of the CM.
> > I didn't look much more in the Avalon code, but I thought, implementing
> > an own ComponentManager which does exactly this behaviour in the
> > lookup and release methods would be simply enough.
>
> Yes, in case we need cocoon-specific behavior, extending avalon's
> component manager is the way to go, rather than forcing new behaviors up
> into avalong foodchain.
Keep in mind, a better understanding of Avalon code will keep you from
reinventing the wheel--poorly. Avalon's code has been tested and hammered,
and I would be resistent to new functionality if you can use what exists
currently. There are some specific ComponentSelectors in Cocoon, but they
extend Avalon's ComponentSelector, and add specific functionality.
I don't quite get what you are driving at that you think Avalon doesn't
support. (Who knows, there might be a good reason for it).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: single instance per context on avalon components
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> > Stefano Mazzocchi wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > This is actually I feature I am looking for since weeks, but had never
> > > time to finish it....
> > >
> > > There is of course the ThreadSafe interface from Avalon, but then
> > > you have only one single instance in the whole system. That's not
> > > suitable for many cases.
> > >
> > > I would like to add a Cocoon-specific marker interface, similar
> > > to the SitemapModelComponent interface (but a different name)
> > > >>>
> > > public interface RequestModelComponent extends Component {
> > > /**
> > > * Set the <code>SourceResolver</code>, objectModel
> > <code>Map</code>,
> > > * the source and sitemap <code>Parameters</code> used to
> > process the
> > > request.
> > > */
> > > void setup(SourceResolver resolver, Map objectModel) throws
> > > ProcessingException;
> > > }
> > > <<<<
> > >
> > > The behaviour for this would be:
> > > - The first time during a request processing a component marked with
> > > this interface is looked up, a new instance is created (or got from
> > > the pool) and the setup method is called. This object is stored
> > > somewhere so that the ComponentManager has access to it for later
> > > requests.
> > > - The second, third.. time during the same request this component is
> > > looked up, it is get from the store and the setup() method is
> > > not looked up
> > > - Every time a release is called on this object, nothing really happens
> > > - When the request processing is finished, the ComponentManager
> > > must really release all stored objects.
> > >
> > > So actually objects marked in this way are more or less ThreadSafe
> > > but per request exists a different instance.
> >
> > Hmmm, not sure I understand the need for such a behavior. I mean: if you
> > don't call setup() in subsequent requests, wouldn't you get into an
> > inconsistent state for the environment variables?
> >
> > Can you make an example of use, I'm probably missing your point.
> >
> We use this behaviour for many utility components. Although this is not
> a "real world example" and might not be appropriate modelled, lets imagine
> a component for statistics. In order to work correctly this component needs
> access to the objectModel (to get the request object and from that the
> current requestURI) and it "logs" how many components are used during the
> processing of one request.
> Imagine a simple pipeline with a generator, transformer and serializer.
> The generator looksup the "Statistics" component called SCA, it is created
> from scratch
> (or taken from a pool) and the setup() method is called.
> The generator now sends his information to SCA. Now the transformer
> looks up a "Statistics" component to send his information. If now a new
> instance SCB would be created, this instance would not know about the
> information
> previously send to SCA, so we need the same instance SCA here.
> As this instance is already setup there is no need to call this method
> again.
>
> If in the same time a different request is processed parallel which uses
> the same pipeline (or any other, it doesn't really matter), the generator
> looks up its own "Statistics" component, which of course can not be SCA as
> it
> is used in the other pipeline.
> It is a "new" instance which is used exclusivly in this pipeline.
>
> So summarizing it:
> - a ThreadSafe component is shared by all components in all requests.
> - a "normal" component is not shared at all, each component gets its own
> instance.
> - a RequestModelComponent is shared by all components in the *same* request.
>
> I think this is a pattern which is very useful in building xml applications
> with Cocoon 2.
Ok, gotcha.
+1 from me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: single instance per context on avalon components
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> > Stefano Mazzocchi wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > This is actually I feature I am looking for since weeks, but had never
> > > time to finish it....
> > >
> > > There is of course the ThreadSafe interface from Avalon, but then
> > > you have only one single instance in the whole system. That's not
> > > suitable for many cases.
> > >
> > > I would like to add a Cocoon-specific marker interface, similar
> > > to the SitemapModelComponent interface (but a different name)
> > > >>>
> > > public interface RequestModelComponent extends Component {
> > > /**
> > > * Set the <code>SourceResolver</code>, objectModel
> > <code>Map</code>,
> > > * the source and sitemap <code>Parameters</code> used to
> > process the
> > > request.
> > > */
> > > void setup(SourceResolver resolver, Map objectModel) throws
> > > ProcessingException;
> > > }
> > > <<<<
> > >
> > > The behaviour for this would be:
> > > - The first time during a request processing a component marked with
> > > this interface is looked up, a new instance is created (or got from
> > > the pool) and the setup method is called. This object is stored
> > > somewhere so that the ComponentManager has access to it for later
> > > requests.
> > > - The second, third.. time during the same request this component is
> > > looked up, it is get from the store and the setup() method is
> > > not looked up
> > > - Every time a release is called on this object, nothing really happens
> > > - When the request processing is finished, the ComponentManager
> > > must really release all stored objects.
> > >
> > > So actually objects marked in this way are more or less ThreadSafe
> > > but per request exists a different instance.
> >
> > Hmmm, not sure I understand the need for such a behavior. I mean: if you
> > don't call setup() in subsequent requests, wouldn't you get into an
> > inconsistent state for the environment variables?
> >
> > Can you make an example of use, I'm probably missing your point.
> >
> We use this behaviour for many utility components. Although this is not
> a "real world example" and might not be appropriate modelled, lets imagine
> a component for statistics. In order to work correctly this component needs
> access to the objectModel (to get the request object and from that the
> current requestURI) and it "logs" how many components are used during the
> processing of one request.
> Imagine a simple pipeline with a generator, transformer and serializer.
> The generator looksup the "Statistics" component called SCA, it is created
> from scratch
> (or taken from a pool) and the setup() method is called.
> The generator now sends his information to SCA. Now the transformer
> looks up a "Statistics" component to send his information. If now a new
> instance SCB would be created, this instance would not know about the
> information
> previously send to SCA, so we need the same instance SCA here.
> As this instance is already setup there is no need to call this method
> again.
>
> If in the same time a different request is processed parallel which uses
> the same pipeline (or any other, it doesn't really matter), the generator
> looks up its own "Statistics" component, which of course can not be SCA as
> it
> is used in the other pipeline.
> It is a "new" instance which is used exclusivly in this pipeline.
>
> So summarizing it:
> - a ThreadSafe component is shared by all components in all requests.
> - a "normal" component is not shared at all, each component gets its own
> instance.
> - a RequestModelComponent is shared by all components in the *same* request.
>
> I think this is a pattern which is very useful in building xml applications
> with Cocoon 2.
Ok, gotcha.
+1 from me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: single instance per context on avalon components
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> >
> > This is actually I feature I am looking for since weeks, but had never
> > time to finish it....
> >
> > There is of course the ThreadSafe interface from Avalon, but then
> > you have only one single instance in the whole system. That's not
> > suitable for many cases.
> >
> > I would like to add a Cocoon-specific marker interface, similar
> > to the SitemapModelComponent interface (but a different name)
> > >>>
> > public interface RequestModelComponent extends Component {
> > /**
> > * Set the <code>SourceResolver</code>, objectModel
> <code>Map</code>,
> > * the source and sitemap <code>Parameters</code> used to
> process the
> > request.
> > */
> > void setup(SourceResolver resolver, Map objectModel) throws
> > ProcessingException;
> > }
> > <<<<
> >
> > The behaviour for this would be:
> > - The first time during a request processing a component marked with
> > this interface is looked up, a new instance is created (or got from
> > the pool) and the setup method is called. This object is stored
> > somewhere so that the ComponentManager has access to it for later
> > requests.
> > - The second, third.. time during the same request this component is
> > looked up, it is get from the store and the setup() method is
> > not looked up
> > - Every time a release is called on this object, nothing really happens
> > - When the request processing is finished, the ComponentManager
> > must really release all stored objects.
> >
> > So actually objects marked in this way are more or less ThreadSafe
> > but per request exists a different instance.
>
> Hmmm, not sure I understand the need for such a behavior. I mean: if you
> don't call setup() in subsequent requests, wouldn't you get into an
> inconsistent state for the environment variables?
>
> Can you make an example of use, I'm probably missing your point.
>
We use this behaviour for many utility components. Although this is not
a "real world example" and might not be appropriate modelled, lets imagine
a component for statistics. In order to work correctly this component needs
access to the objectModel (to get the request object and from that the
current requestURI) and it "logs" how many components are used during the
processing of one request.
Imagine a simple pipeline with a generator, transformer and serializer.
The generator looksup the "Statistics" component called SCA, it is created
from scratch
(or taken from a pool) and the setup() method is called.
The generator now sends his information to SCA. Now the transformer
looks up a "Statistics" component to send his information. If now a new
instance SCB would be created, this instance would not know about the
information
previously send to SCA, so we need the same instance SCA here.
As this instance is already setup there is no need to call this method
again.
If in the same time a different request is processed parallel which uses
the same pipeline (or any other, it doesn't really matter), the generator
looks up its own "Statistics" component, which of course can not be SCA as
it
is used in the other pipeline.
It is a "new" instance which is used exclusivly in this pipeline.
So summarizing it:
- a ThreadSafe component is shared by all components in all requests.
- a "normal" component is not shared at all, each component gets its own
instance.
- a RequestModelComponent is shared by all components in the *same* request.
I think this is a pattern which is very useful in building xml applications
with Cocoon 2.
Carsten
> > I didn't look much more in the Avalon code, but I thought, implementing
> > an own ComponentManager which does exactly this behaviour in the
> > lookup and release methods would be simply enough.
>
> Yes, in case we need cocoon-specific behavior, extending avalon's
> component manager is the way to go, rather than forcing new behaviors up
> into avalong foodchain.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: single instance per context on avalon components
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> This is actually I feature I am looking for since weeks, but had never
> time to finish it....
>
> There is of course the ThreadSafe interface from Avalon, but then
> you have only one single instance in the whole system. That's not
> suitable for many cases.
>
> I would like to add a Cocoon-specific marker interface, similar
> to the SitemapModelComponent interface (but a different name)
> >>>
> public interface RequestModelComponent extends Component {
> /**
> * Set the <code>SourceResolver</code>, objectModel <code>Map</code>,
> * the source and sitemap <code>Parameters</code> used to process the
> request.
> */
> void setup(SourceResolver resolver, Map objectModel) throws
> ProcessingException;
> }
> <<<<
>
> The behaviour for this would be:
> - The first time during a request processing a component marked with
> this interface is looked up, a new instance is created (or got from
> the pool) and the setup method is called. This object is stored
> somewhere so that the ComponentManager has access to it for later
> requests.
> - The second, third.. time during the same request this component is
> looked up, it is get from the store and the setup() method is
> not looked up
> - Every time a release is called on this object, nothing really happens
> - When the request processing is finished, the ComponentManager
> must really release all stored objects.
>
> So actually objects marked in this way are more or less ThreadSafe
> but per request exists a different instance.
Hmmm, not sure I understand the need for such a behavior. I mean: if you
don't call setup() in subsequent requests, wouldn't you get into an
inconsistent state for the environment variables?
Can you make an example of use, I'm probably missing your point.
> I didn't look much more in the Avalon code, but I thought, implementing
> an own ComponentManager which does exactly this behaviour in the
> lookup and release methods would be simply enough.
Yes, in case we need cocoon-specific behavior, extending avalon's
component manager is the way to go, rather than forcing new behaviors up
into avalong foodchain.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: single instance per context on avalon components
Posted by Carsten Ziegeler <cz...@sundn.de>.
This is actually I feature I am looking for since weeks, but had never
time to finish it....
There is of course the ThreadSafe interface from Avalon, but then
you have only one single instance in the whole system. That's not
suitable for many cases.
I would like to add a Cocoon-specific marker interface, similar
to the SitemapModelComponent interface (but a different name)
>>>
public interface RequestModelComponent extends Component {
/**
* Set the <code>SourceResolver</code>, objectModel <code>Map</code>,
* the source and sitemap <code>Parameters</code> used to process the
request.
*/
void setup(SourceResolver resolver, Map objectModel) throws
ProcessingException;
}
<<<<
The behaviour for this would be:
- The first time during a request processing a component marked with
this interface is looked up, a new instance is created (or got from
the pool) and the setup method is called. This object is stored
somewhere so that the ComponentManager has access to it for later
requests.
- The second, third.. time during the same request this component is
looked up, it is get from the store and the setup() method is
not looked up
- Every time a release is called on this object, nothing really happens
- When the request processing is finished, the ComponentManager
must really release all stored objects.
So actually objects marked in this way are more or less ThreadSafe
but per request exists a different instance.
I didn't look much more in the Avalon code, but I thought, implementing
an own ComponentManager which does exactly this behaviour in the
lookup and release methods would be simply enough.
Your thoughts?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> Stefano Mazzocchi
>
> Working for finishing up the gallery code, I've come into the need to
> share the instance of an avalon component between two cocoon pipeline
> components, respectively a transformer and a generator.
>
> This is the same need of the FragmentExtractor generator/transformer
> pair: one collects information at transformation stage and stores this
> information for later retrieval at generation stage. It's not a common
> need, but I assume this will turn out very useful for complex operations
> like pagination and path expansion (which is why I need this).
>
> So, my code compiles and does what it should: the problem is that the
> two sitemap components (the generator and the transformer) get two
> different instances of the component so one stores correctly and the
> other retrieves correctly, the problem is that it never retrieves
> anything since it's the other instance that gets filled with data :(
>
> how do I share a component without using static methods?
>
> (oh, BTW, the FragmentExtractor is buggy in that respect since it uses a
> static hashtable instead of using a shared component, this could well
> create problems on situations where more than one cocoon is run in the
> same JVM! please, kill all static instances!)
>
> Thanks much in advance.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org