Re: Template block in ibiblio maven repository
Yes, the default excludes are not available - I'll put up the missing jars today. Carsten Jason Johnston wrote: > It looks like the block.properties shipped with 2.1.9 had the imageop, > jcr, and template blocks excluded by default. That's probably why they > didn't get built. > > Just checked the jcr block on ibiblio and its 2.1.9 jar is indeed > missing as well; I didn't notice it before since its 2.1.8 jar is there. > > > Joerg Heinicke wrote: >> Sounds like the new blocks are missing. IRIC both imageop and template >> block were added in 2.1.9. Must they be listed in some conf? >> >> Jörg >> >> On 30.04.2006 15:51, Jason Johnston wrote: >>> I checked the whole list of blocks and the imageop block JAR is also >>> missing. >>> >>> >>> Jason Johnston wrote: I'm converting one of my projects to use Maven for its build process. I've set it up to pull down the needed Cocoon JARs from the ibiblio repository at http://www.ibiblio.org/maven2/cocoon/*. It's working great, except I noticed that the template block included in 2.1.9 is not available in that repository. Is that something someone on this list can add to ibiblio? > > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote: > It will mean some changes for the portal block as it use the Cocoon > component and the same complicated setup as the the CocoonServlet. > Geting a component container that is setup by a servlet context listener > through the portlet context should work fine a simplify the portlet > setup as well. I guess you're refering to the portlet environment itself (using Cocoon as a portlet). The portal itself should not be affected by this. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying setup
Daniel Fagerstrom said: > Carsten Ziegeler skrev: >> Daniel Fagerstrom wrote: >>> >> I'm mostly fine with your proposed changes if you think that this helps >> Cocoon. In the end all changes that don't require to rewrite or change >> our current blocks are fine for me. > > It will mean some changes for the portal block as it use the Cocoon > component and the same complicated setup as the the CocoonServlet. > Geting a component container that is setup by a servlet context listener > through the portlet context should work fine a simplify the portlet > setup as well. Please provide an example of what this would look like. I really need to understand how this will simplify anything. > >> But I'm remaining very sceptical wrt to a 2.2 release in general. I >> think one of our main goals is currently out of focus: release early, >> release often. This has nothing to do with this RT specifically, I just >> wanted to use this thread as a reminder to focus on a release :) > > My personal goal is to release a blocks based Cocoon. But if anyone want > to release something from trunk earlier, I'm fine with that. I just > don't see any activity in that direction. While true, it is unfortunate. Switching to Maven 2 for building projects is a lot less scary than switching from 2.1 to an OSGi based system. That doesn't make it bad, but it may make the resistance to adopt it high. I believe that is why it was recommended at the gettogether that the focus be on delivering trunk with Maven 2 by the end of the year and then focusing on "real blocks". At least, that is what I remember hearing. > > The important differences between 2.1 and trunk is in the cocoon-core, > and as long as it is as complicated as it is today, only a few people > understand it well enough to be able to work on it. So refactorings that > make the core easier to understand and less monolithic will make it > easier for more people to get involved, which IMO should increase the > chance for a release. For me, this remains to be seen. Moving stuff from cocoon's core to OSGi doesn't make it any less complicated. It just makes it a different set of things to understand. And unless you are getting rid of caching, pipelines, etc. there is still a lot of Cocoon specific stuff to understand. Frankly, if trunk was completely working with Maven 2 I'd be all over it trying to get it into production. But since it has been in sandbox mode for so long, I've focused completely on 2.1 as that is what my employer will be using until trunk gets in a mode where I trust it. And I don't see much point in learning how trunk works until it stabilizes. Ralph
Re: [RT] Simplifying setup
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: I'm mostly fine with your proposed changes if you think that this helps Cocoon. In the end all changes that don't require to rewrite or change our current blocks are fine for me. It will mean some changes for the portal block as it use the Cocoon component and the same complicated setup as the the CocoonServlet. Geting a component container that is setup by a servlet context listener through the portlet context should work fine a simplify the portlet setup as well. But I'm remaining very sceptical wrt to a 2.2 release in general. I think one of our main goals is currently out of focus: release early, release often. This has nothing to do with this RT specifically, I just wanted to use this thread as a reminder to focus on a release :) My personal goal is to release a blocks based Cocoon. But if anyone want to release something from trunk earlier, I'm fine with that. I just don't see any activity in that direction. The important differences between 2.1 and trunk is in the cocoon-core, and as long as it is as complicated as it is today, only a few people understand it well enough to be able to work on it. So refactorings that make the core easier to understand and less monolithic will make it easier for more people to get involved, which IMO should increase the chance for a release. /Daniel
Re: [RT] Simplifying setup
Sylvain Wallez skrev: Daniel Fagerstrom wrote: ... For the Cocoon main servlet I suggest that we start from the SitemapServlet http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java, and modify it so that it gets the bean container from a servlet context attribute instead of being injected. Makes sense also. The servlet specification states that servlet should have a no-arg constructor and get whatever then need to work in the init() method. So having servlets expecting dependencies to be injected by some external stuff makes them something that is no more exactly a servlet. Note that it can be circumvented somehow by having the init method grab the component container and do the injection process. Yes, in the current block fw I use dependency injection into servlets for components while connections to other servlets (blocks) are available through request dispatchers and (block) properties go to servlet init parameters. After having thought a little bit more about it I have realized that it is better to make the components and/or the service manager that a block depends on available to it as servlet context attributes. This makes the blocks fw usable for more existing servlets and it make the life cycle for the servlets less complicated. Also the sitemap path (for non default valiues) could be taken from servlet config init parameter instead of the current mechanism. WDYM? What I mean is that the tree processor currently get the path to the sitemap.xmap from the configuration file. If the tree processor stop being a managed component and just is setup in the SitemapServlet, it will still need to get the sitemap path from somewhere. IMO a servlet config init parameter would be a reasonable place to set the sitemap path. /Daniel
[jira] Commented: (COCOON-1841) strange behavior with sitemaps mounted from within jars
[ http://issues.apache.org/jira/browse/COCOON-1841?page=comments#action_12377246 ] Harlan Iverson commented on COCOON-1841: I just tried it on the latest SVN 2_1_X snapshot, 20060501103717, same issue applies. > strange behavior with sitemaps mounted from within jars > --- > > Key: COCOON-1841 > URL: http://issues.apache.org/jira/browse/COCOON-1841 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.8 > Reporter: Harlan Iverson > Attachments: cocoon-sitemap-resources.zip > > When I mount a sitemap from a jar using resource:// (sitemap A), and the > mounted sitemap mounts another one (sitemap B), relative paths from within > sitemap B throw a SourceNotFoundException. A minimal reproduce case is > attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [continuum] BUILD FAILURE: Portal Block Implementation
Carsten Ziegeler wrote: > > Ah, great! This shows how useful tests are. I fixed the bug in the > implementation and the block should now build fine again. cool, the next build (around 1am) should pick up that change then and we'll get notified on the list. We didn't get notified of the initial build failure in the first place because it occured initially after i migrated CI to 1.0.3. > Btw, did you change anything to make the build work again? On my machine > maven was never able to find the core test jar as the name in the > repository did not match the name maven searched for. I found out that Continuum doesn't copy test-jars to it's internal deployment repository. As i was rsync'ing this internal one with svn.a.o/maven-snapshot-repository the test-jars got always left out. The other modules were only able to build because the m2 repository of the zone maven account happened to have a previous copy of the test-jar installed. I've cleared out the local repo and did a fresh rsync with the snapshot repository. If the problem still persists let me know. Thanks Jorg
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote: > I'm mostly fine with your proposed changes if you think that this helps Cocoon. In the end all changes that don't require to rewrite or change our current blocks are fine for me. But I'm remaining very sceptical wrt to a 2.2 release in general. I think one of our main goals is currently out of focus: release early, release often. This has nothing to do with this RT specifically, I just wanted to use this thread as a reminder to focus on a release :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [continuum] BUILD FAILURE: Portal Block Implementation
Jorg Heymans wrote: > Note that this report is outdated. > > The portal block impl is currently not building because of failing tests. > > http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=384&id=97 Ah, great! This shows how useful tests are. I fixed the bug in the implementation and the block should now build fine again. Btw, did you change anything to make the build work again? On my machine maven was never able to find the core test jar as the name in the repository did not match the name maven searched for. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1841) strange behavior with sitemaps mounted from within jars
strange behavior with sitemaps mounted from within jars --- Key: COCOON-1841 URL: http://issues.apache.org/jira/browse/COCOON-1841 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.8 Reporter: Harlan Iverson Attachments: cocoon-sitemap-resources.zip When I mount a sitemap from a jar using resource:// (sitemap A), and the mounted sitemap mounts another one (sitemap B), relative paths from within sitemap B throw a SourceNotFoundException. A minimal reproduce case is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[GT2006] The 5th Cocoon GetTogether: call for ideas
Hi folks, Following in Steven's footsteps, I'd hereby like to bootstrap this year's jubilee Cocoon GetTogether. The sun is shining (kind of..), spring is in the air, and we need to start thinking about our beloved annual Cocoon gathering. I believe the outcome of last year's discussion was that we all want the Cocoon GetTogether to be as much of a community driven event as possible. That's why I'm sending this Request for Ideas to the dev and user mailinglists. So here it is - if you got something to say, or have any ideas you'd like to share, please say it now! - Who is willing to organize this year's event? - Where? - When? - How long? - How big? Of course, I think Amsterdam is a really good place for Get Togethers, just as Ghent is, but maybe it's time to move again :).. However, I'd be happy to host the event in Amsterdam again. For now, let's come up with some ideas and get that Cocoon GT community feeling flowing again... Kind regards, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl / [EMAIL PROTECTED] --
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote: > People, I'm fed up with the sickening complicated setup sequence in > Cocoon. Much of the complication is related to setting up the > component manager and general over componentization. > > I'd like to remove the component container setup from the concern area > of Cocoon. The component container should instead be setup by the > servlet container using a ServletContextListener and made available to > the Cocoon main servlet through a servlet context attribute (the > details will be slightly different in the blocks context). Yup. This is a common practice adopted by Spring and NanoContainer. > Furthermore the setup contains a number of classes and components with > fairly overlapping and fuzzy concern areas: The CocoonServlet creates > a CoreUtil which creates a CocoonBeanFactory which in turn is used to > get the Cocoon component, which in turn delegates most of it job to > the SitemapLanguage which also is a component that is managed by the > CocoonBeanFactory. A fun exercise for the interested is to try to > figure out how and where the Cocoon component is configured and created. :-) > Now, I don't see any reason at all for Cocoon and SitemapLanguage to > be managed components, it just complicates everything. And for the > Cocoon component there is not much use anymore. Its responsibilities > are rather vague. I suggest that we just move whatever useful thing it > might do, to the main servlet and use Servlet instead of Processor as > top level interface (as discussed before, so many sitemap internal > details has been added to Processor that it is not useful as an > abstraction anymore anyway). Makes sense. The useful abstraction would be pipeline. > For the Cocoon main servlet I suggest that we start from the > SitemapServlet > http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java, > and modify it so that it gets the bean container from a servlet > context attribute instead of being injected. Makes sense also. The servlet specification states that servlet should have a no-arg constructor and get whatever then need to work in the init() method. So having servlets expecting dependencies to be injected by some external stuff makes them something that is no more exactly a servlet. Note that it can be circumvented somehow by having the init method grab the component container and do the injection process. > Also the sitemap path (for non default valiues) could be taken from > servlet config init parameter instead of the current mechanism. WDYM? > The SitemapServlet is rather minimal so some functionality from the > Cocoon component and the CocoonServlet could be moved to it. But I > think we should strive to keep it minimal. More advanced functionality > like multi part mime handling could preferably be moved to servlet > filters. Yup. > The suggested architecture will make it much easier to maintain and > understand Cocoon, and will also make it simpler to reuse and to add > new controllers to (a Flowscript controller or a RoR inspired > convention controller e.g.). The CLI and Portlet environment will need > some refactoring if we follow the above path. But the CLI need some > work anyway and for the Portlet environment I would guess that getting > closer to the servlet standards just should simplify things. > > WDYT? Sounds good! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Simplifying setup
Please provide a concrete example of what you are proposing before checking anything in. Then we can discuss this. Daniel Fagerstrom wrote: People, I'm fed up with the sickening complicated setup sequence in Cocoon. Much of the complication is related to setting up the component manager and general over componentization. I'd like to remove the component container setup from the concern area of Cocoon. The component container should instead be setup by the servlet container using a ServletContextListener and made available to the Cocoon main servlet through a servlet context attribute (the details will be slightly different in the blocks context). Furthermore the setup contains a number of classes and components with fairly overlapping and fuzzy concern areas: The CocoonServlet creates a CoreUtil which creates a CocoonBeanFactory which in turn is used to get the Cocoon component, which in turn delegates most of it job to the SitemapLanguage which also is a component that is managed by the CocoonBeanFactory. A fun exercise for the interested is to try to figure out how and where the Cocoon component is configured and created. Now, I don't see any reason at all for Cocoon and SitemapLanguage to be managed components, it just complicates everything. And for the Cocoon component there is not much use anymore. Its responsibilities are rather vague. I suggest that we just move whatever useful thing it might do, to the main servlet and use Servlet instead of Processor as top level interface (as discussed before, so many sitemap internal details has been added to Processor that it is not useful as an abstraction anymore anyway). For the Cocoon main servlet I suggest that we start from the SitemapServlet http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java, and modify it so that it gets the bean container from a servlet context attribute instead of being injected. Also the sitemap path (for non default valiues) could be taken from servlet config init parameter instead of the current mechanism. The SitemapServlet is rather minimal so some functionality from the Cocoon component and the CocoonServlet could be moved to it. But I think we should strive to keep it minimal. More advanced functionality like multi part mime handling could preferably be moved to servlet filters. The suggested architecture will make it much easier to maintain and understand Cocoon, and will also make it simpler to reuse and to add new controllers to (a Flowscript controller or a RoR inspired convention controller e.g.). The CLI and Portlet environment will need some refactoring if we follow the above path. But the CLI need some work anyway and for the Portlet environment I would guess that getting closer to the servlet standards just should simplify things. WDYT? /Daniel
AW: Desparately seeking help with pipeline implementation
| That's the idea, but you have some bugs here since when you remove a
| transformer, you should also remove the corresponding selector and
| parameters:
|
| for (int i = 0; i < this.transformers.size(); /* do not increment here */)
| {
| if (trashTransformerAt(i)) {
| // Release what needs to be
| Transformer transf = (Transformer)this.transformers.get(i);
| ComponentSelector selector =
| (ComponentSelector)this.transformerSelectors.get(i);
| selector.release(transf);
| this.newManager.release(selector);
|
| // Update lists
| this.transformers.remove(i);
| this.transformerSelectors.remove(i);
| this.transformerParams.remove(i);
| this.transformerSources.remove(i);
| } else {
| i++;
| }
| }
I finally chose your way - it's easier and has the better performance. I
also tried to implement the whole thing by overloading addTransformer(),
which - of course - is possible. It seems even much more easy, but I need
the environment for my adaptation logic. Isn't the environment available at
this time of pipeline building, or can I get it from somewhere?
Stefan
RE: VNU Europe moves to Cocoon...
> We just finished launching the first of the EU countries here > at VNU, powered by Cocoon: Italy. Congratulations, guys!! Cocoon livesites gogogo :-) Kind regards, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl / [EMAIL PROTECTED] --
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote:
People, I'm fed up with the sickening complicated setup sequence in
Cocoon. Much of the complication is related to setting up the component
manager and general over componentization.
I'd like to remove the component container setup from the concern area
of Cocoon. The component container should instead be setup by the
servlet container using a ServletContextListener and made available to
the Cocoon main servlet through a servlet context attribute (the details
will be slightly different in the blocks context).
Furthermore the setup contains a number of classes and components with
fairly overlapping and fuzzy concern areas: The CocoonServlet creates a
CoreUtil which creates a CocoonBeanFactory which in turn is used to get
the Cocoon component, which in turn delegates most of it job to the
SitemapLanguage which also is a component that is managed by the
CocoonBeanFactory. A fun exercise for the interested is to try to figure
out how and where the Cocoon component is configured and created.
hehe ;-)
Now, I don't see any reason at all for Cocoon and SitemapLanguage to be
managed components, it just complicates everything. And for the Cocoon
component there is not much use anymore. Its responsibilities are rather
vague. I suggest that we just move whatever useful thing it might do, to
the main servlet and use Servlet instead of Processor as top level
interface (as discussed before, so many sitemap internal details has
been added to Processor that it is not useful as an abstraction anymore
anyway).
For the Cocoon main servlet I suggest that we start from the
SitemapServlet
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java,
and modify it so that it gets the bean container from a servlet context
attribute instead of being injected. Also the sitemap path (for non
default valiues) could be taken from servlet config init parameter
instead of the current mechanism.
The SitemapServlet is rather minimal so some functionality from the
Cocoon component and the CocoonServlet could be moved to it. But I think
we should strive to keep it minimal. More advanced functionality like
multi part mime handling could preferably be moved to servlet filters.
The suggested architecture will make it much easier to maintain and
understand Cocoon, and will also make it simpler to reuse and to add new
controllers to (a Flowscript controller or a RoR inspired convention
controller e.g.). The CLI and Portlet environment will need some
refactoring if we follow the above path. But the CLI need some work
anyway and for the Portlet environment I would guess that getting closer
to the servlet standards just should simplify things.
WDYT?
After stepping through the code together with you I agree with your analysis and
your suggestions.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
AW: AW: AW: Desparately seeking help with pipeline implementation
| -Ursprüngliche Nachricht-
| Von: Sylvain Wallez [mailto:[EMAIL PROTECTED]
| Gesendet: Montag, 1. Mai 2006 11:11
| An: dev@cocoon.apache.org
| Betreff: Re: AW: AW: Desparately seeking help with pipeline implementation
|
| Stefan Pietschmann wrote:
| > Hi Sylvain (and others),
| >
| > thank you for the quick response which finally helped me understand how
| the
| > pipeline is used at runtime.
| >
|
| Great! The main point about pipelines is that they are basically empty
| shells that are filled with components by the sitemap engine, and
| cleaned up after the pipeline has been executed.
|
| They don't keep component between different requests, since the actual
| components used and their parameters can change for every request, even
| for the same URL.
|
| The fact that pipelines are recyclable (i.e. poolable) is just here to
| avoid having to go through the Avalon initialization stuff on each
| request. Now there initialization is so simple that they actually could
| be SingleThreaded rather than Recyclable and thus created anew at each
| request rather than pooled.
|
| > What I do is to throw transformers out depending on their attributes
| (it's a
| > bit more complicated, but anyway..). Now that I see that the
| transformerlist
| > is built anew for every request I do not need to backup the original
| list
| > and load it everytime.
|
| Right.
|
| > I thought it would be built only once at the beginning.
| >
|
| At the beginning of what? ;-)
|
| > So my choices now are to overload the addTransformer() method, only
| adding a
| > transformer under certain circumstances, or leave my current
| implementation
| > which goes through this.transformers, this.transformerSources and
| > this.transformerParams, checks the parameters and throws the
| transformers,
| > sources and parameters out of the lists.
| > The first way seems easier, but it means that I have to copy the whole
| > method from the super class to my pipeline and change it there - I don't
| > like that because you I have to check for changes with every Cocoon
| update.
| > With the second way I can simply outsource the code going through the
| lists
| > to my own method and call it at the beginning of setupPipeline().
| >
|
| Why would you have to copy the superclass source code? Just call
| super.addTransformer() if you need to and that's all, isn't it?
|
| public void addTransformer(String role, String source, Parameters param,
| Parameters hintParam) {
| if (keepTransformer(role, source, params, hintParam) {
| super.addTransformer(role, source, params, hintParam);
| }
| }
Right, this would be sufficient if I only had conditional transformers, but
my transformers have adaptable attributes as well which I would have to
check and adapt within addTransformer().
| Another option, if you need to do some complex computation on the
| transformer list is to overload setSerializer(). When this method is
| called, all transformers in the pipeline are there.
|
| > I do have one more question - to make it right this time. If I prevent a
| > transformer from being added to the list in addTransformer(), or if I
| kick
| > it out in my method, I see I have to release it.
|
| Yes.
|
| > This is done by the following in AbstractProcessingPipeline:
| >
| > int size = this.transformerSelectors.size();
| > for (int i = 0; i < size; i++) {
| > final ComponentSelector selector = (ComponentSelector)
| > this.transformerSelectors.get(i);
| > selector.release((Component) this.transformers.get(i));
| > this.newManager.release(selector);
| > }
| >
| > In my method it would look like:
| >
| > Iterator transformerItt = this.transformers.iterator();
| > ...
| > int i = 0;
| > while (transformerItt.hasNext()) {
| > Transformer trans = (Transformer) transformerItt.next();
| > ...
| > // check if the transformer should be run
| > ..
| > // kick it out
| > transformerItt.remove();
| > // release transformer
| > final ComponentSelector selector = (ComponentSelector)
| > this.transformerSelectors.get(i);
| > selector.release((Component) trans);
| > this.newManager.release(selector);
| > i++;
| > }
| >
| > Right?
| >
|
| That's the idea, but you have some bugs here since when you remove a
| transformer, you should also remove the corresponding selector and
| parameters:
|
| for (int i = 0; i < this.transformers.size(); /* do not increment here */)
| {
| if (trashTransformerAt(i)) {
| // Release what needs to be
| Transformer transf = (Transformer)this.transformers.get(i);
| ComponentSelector selector =
| (ComponentSelector)this.transformerSelectors.get(i);
| selector.release(transf);
| this.newManager.release(selector);
|
| // Update lists
| this.transformers.remove(i);
| this.transformerSelectors.remove(i);
| this.transformerParams.remove(i);
| this.transformerSources.remove(i);
| } else {
|
Re: AW: AW: Desparately seeking help with pipeline implementation
Stefan Pietschmann wrote:
> Hi Sylvain (and others),
>
> thank you for the quick response which finally helped me understand how the
> pipeline is used at runtime.
>
Great! The main point about pipelines is that they are basically empty
shells that are filled with components by the sitemap engine, and
cleaned up after the pipeline has been executed.
They don't keep component between different requests, since the actual
components used and their parameters can change for every request, even
for the same URL.
The fact that pipelines are recyclable (i.e. poolable) is just here to
avoid having to go through the Avalon initialization stuff on each
request. Now there initialization is so simple that they actually could
be SingleThreaded rather than Recyclable and thus created anew at each
request rather than pooled.
> What I do is to throw transformers out depending on their attributes (it's a
> bit more complicated, but anyway..). Now that I see that the transformerlist
> is built anew for every request I do not need to backup the original list
> and load it everytime.
Right.
> I thought it would be built only once at the beginning.
>
At the beginning of what? ;-)
> So my choices now are to overload the addTransformer() method, only adding a
> transformer under certain circumstances, or leave my current implementation
> which goes through this.transformers, this.transformerSources and
> this.transformerParams, checks the parameters and throws the transformers,
> sources and parameters out of the lists.
> The first way seems easier, but it means that I have to copy the whole
> method from the super class to my pipeline and change it there - I don't
> like that because you I have to check for changes with every Cocoon update.
> With the second way I can simply outsource the code going through the lists
> to my own method and call it at the beginning of setupPipeline().
>
Why would you have to copy the superclass source code? Just call
super.addTransformer() if you need to and that's all, isn't it?
public void addTransformer(String role, String source, Parameters param,
Parameters hintParam) {
if (keepTransformer(role, source, params, hintParam) {
super.addTransformer(role, source, params, hintParam);
}
}
Another option, if you need to do some complex computation on the
transformer list is to overload setSerializer(). When this method is
called, all transformers in the pipeline are there.
> I do have one more question - to make it right this time. If I prevent a
> transformer from being added to the list in addTransformer(), or if I kick
> it out in my method, I see I have to release it.
Yes.
> This is done by the following in AbstractProcessingPipeline:
>
> int size = this.transformerSelectors.size();
> for (int i = 0; i < size; i++) {
> final ComponentSelector selector = (ComponentSelector)
> this.transformerSelectors.get(i);
> selector.release((Component) this.transformers.get(i));
> this.newManager.release(selector);
> }
>
> In my method it would look like:
>
> Iterator transformerItt = this.transformers.iterator();
> ...
> int i = 0;
> while (transformerItt.hasNext()) {
> Transformer trans = (Transformer) transformerItt.next();
> ...
> // check if the transformer should be run
> ..
> // kick it out
> transformerItt.remove();
> // release transformer
> final ComponentSelector selector = (ComponentSelector)
> this.transformerSelectors.get(i);
> selector.release((Component) trans);
> this.newManager.release(selector);
> i++;
> }
>
> Right?
>
That's the idea, but you have some bugs here since when you remove a
transformer, you should also remove the corresponding selector and
parameters:
for (int i = 0; i < this.transformers.size(); /* do not increment here */) {
if (trashTransformerAt(i)) {
// Release what needs to be
Transformer transf = (Transformer)this.transformers.get(i);
ComponentSelector selector =
(ComponentSelector)this.transformerSelectors.get(i);
selector.release(transf);
this.newManager.release(selector);
// Update lists
this.transformers.remove(i);
this.transformerSelectors.remove(i);
this.transformerParams.remove(i);
this.transformerSources.remove(i);
} else {
i++;
}
}
Be careful also that depending on the class you extend, there are a
couple of other lists to update as well:
- transformerRoles in AbstractCachingProcessingPipeline
- isCachePoint in CachingPointPipeline
Sylvain
--
Sylvain Wallez - http://bluxte.net
[RT] Simplifying setup
People, I'm fed up with the sickening complicated setup sequence in Cocoon. Much of the complication is related to setting up the component manager and general over componentization. I'd like to remove the component container setup from the concern area of Cocoon. The component container should instead be setup by the servlet container using a ServletContextListener and made available to the Cocoon main servlet through a servlet context attribute (the details will be slightly different in the blocks context). Furthermore the setup contains a number of classes and components with fairly overlapping and fuzzy concern areas: The CocoonServlet creates a CoreUtil which creates a CocoonBeanFactory which in turn is used to get the Cocoon component, which in turn delegates most of it job to the SitemapLanguage which also is a component that is managed by the CocoonBeanFactory. A fun exercise for the interested is to try to figure out how and where the Cocoon component is configured and created. Now, I don't see any reason at all for Cocoon and SitemapLanguage to be managed components, it just complicates everything. And for the Cocoon component there is not much use anymore. Its responsibilities are rather vague. I suggest that we just move whatever useful thing it might do, to the main servlet and use Servlet instead of Processor as top level interface (as discussed before, so many sitemap internal details has been added to Processor that it is not useful as an abstraction anymore anyway). For the Cocoon main servlet I suggest that we start from the SitemapServlet http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java, and modify it so that it gets the bean container from a servlet context attribute instead of being injected. Also the sitemap path (for non default valiues) could be taken from servlet config init parameter instead of the current mechanism. The SitemapServlet is rather minimal so some functionality from the Cocoon component and the CocoonServlet could be moved to it. But I think we should strive to keep it minimal. More advanced functionality like multi part mime handling could preferably be moved to servlet filters. The suggested architecture will make it much easier to maintain and understand Cocoon, and will also make it simpler to reuse and to add new controllers to (a Flowscript controller or a RoR inspired convention controller e.g.). The CLI and Portlet environment will need some refactoring if we follow the above path. But the CLI need some work anyway and for the Portlet environment I would guess that getting closer to the servlet standards just should simplify things. WDYT? /Daniel
Re: [continuum] BUILD FAILURE: Portal Block Implementation
Note that this report is outdated. The portal block impl is currently not building because of failing tests. http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=384&id=97 Jorg [EMAIL PROTECTED] wrote: > Online report : > http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/97/buildId/255 > Build statistics: > State: Failed > Previous State: Failed > Started at: Sun, 30 Apr 2006 21:36:11 + > Finished at: Sun, 30 Apr 2006 21:36:19 + > Total time: 7s > Build Trigger: Forced > Exit code: 1 > Building machine hostname: cocoon.zones.apache.org > Operating system : SunOS(unknown) > Java version : 1.4.2_06(Sun Microsystems Inc.) > > Changes > No files changed > > > Output: > > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Portal Block Implementation > [INFO]task-segment: [install] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [WARNING] POM for 'org.apache.pluto:pluto:pom:1.0.1' is invalid. It will be > ignored for artifact resolution. Reason: Not a v4.0.0 POM. > Downloading: > http://ibiblio.org/maven2/wsrp4j/wsrp4j-consumer/0.3-dev/wsrp4j-consumer-0.3-dev.pom > [WARNING] Unable to get resource from repository central > (http://ibiblio.org/maven2) > Downloading: > http://cvs.apache.org/maven-snapshot-repository/wsrp4j/wsrp4j-consumer/0.3-dev/wsrp4j-consumer-0.3-dev.pom > [WARNING] Unable to get resource from repository apache-maven2 > (http://cvs.apache.org/maven-snapshot-repository) > Downloading: > http://cvs.apache.org/repository/wsrp4j/poms/wsrp4j-consumer-0.3-dev.pom > [WARNING] Unable to get resource from repository apache-cvs > (http://cvs.apache.org/repository) > Downloading: > http://snapshots.maven.codehaus.org/maven2//wsrp4j/wsrp4j-consumer/0.3-dev/wsrp4j-consumer-0.3-dev.pom > [WARNING] Unable to get resource from repository maven-snapshot > (http://snapshots.maven.codehaus.org/maven2/) > [WARNING] > Artifact junit:junit:jar:3.8.1 retains local scope 'test' overriding > broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > > [WARNING] > Artifact javax.servlet:servlet-api:jar:2.3 retains local scope > 'provided' overriding broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > > [WARNING] POM for 'portlet-api:portlet-api:pom:1.0' is invalid. It will be > ignored for artifact resolution. Reason: Not a v4.0.0 POM. > Downloading: > http://ibiblio.org/maven2/wsrp4j/wsrp4j-shared/0.3-dev/wsrp4j-shared-0.3-dev.pom > [WARNING] Unable to get resource from repository central > (http://ibiblio.org/maven2) > Downloading: > http://cvs.apache.org/maven-snapshot-repository/wsrp4j/wsrp4j-shared/0.3-dev/wsrp4j-shared-0.3-dev.pom > [WARNING] Unable to get resource from repository apache-maven2 > (http://cvs.apache.org/maven-snapshot-repository) > Downloading: > http://cvs.apache.org/repository/wsrp4j/poms/wsrp4j-shared-0.3-dev.pom > [WARNING] Unable to get resource from repository apache-cvs > (http://cvs.apache.org/repository) > Downloading: > http://snapshots.maven.codehaus.org/maven2//wsrp4j/wsrp4j-shared/0.3-dev/wsrp4j-shared-0.3-dev.pom > [WARNING] Unable to get resource from repository maven-snapshot > (http://snapshots.maven.codehaus.org/maven2/) > [INFO] snapshot org.apache.cocoon:cocoon-authentication-fw:1-SNAPSHOT: > checking for updates from central > [INFO] snapshot org.apache.cocoon:cocoon-authentication-fw:1-SNAPSHOT: > checking for updates from apache-maven2 > [INFO] snapshot org.apache.cocoon:cocoon-authentication-fw:1-SNAPSHOT: > checking for updates from apache-cvs > [INFO] snapshot org.apache.cocoon:cocoon-authentication-fw:1-SNAPSHOT: > checking for updates from maven-snapshot > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [WARNING] POM for 'org.apache.pluto:pluto:pom:1.0.1' is invalid. It will be > ignored for artifact resolution. Reason: Not a v4.0.0 POM. > [WARNING] POM for 'portlet-api:portlet-api:pom:1.0' is invalid. It will be > ignored for artifact resolution. Reason: Not a v4.0.0 POM. > Downloading: > http://cvs.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/cocoon-core-2.2.0-20060427.020413-1-tests.jar > [INFO] > > [ERROR] BUILD ERROR > [INF
AW: AW: Desparately seeking help with pipeline implementation
Hi Sylvain (and others),
thank you for the quick response which finally helped me understand how the
pipeline is used at runtime.
What I do is to throw transformers out depending on their attributes (it's a
bit more complicated, but anyway..). Now that I see that the transformerlist
is built anew for every request I do not need to backup the original list
and load it everytime. I thought it would be built only once at the
beginning.
So my choices now are to overload the addTransformer() method, only adding a
transformer under certain circumstances, or leave my current implementation
which goes through this.transformers, this.transformerSources and
this.transformerParams, checks the parameters and throws the transformers,
sources and parameters out of the lists.
The first way seems easier, but it means that I have to copy the whole
method from the super class to my pipeline and change it there - I don't
like that because you I have to check for changes with every Cocoon update.
With the second way I can simply outsource the code going through the lists
to my own method and call it at the beginning of setupPipeline().
I do have one more question - to make it right this time. If I prevent a
transformer from being added to the list in addTransformer(), or if I kick
it out in my method, I see I have to release it. This is done by the
following in AbstractProcessingPipeline:
int size = this.transformerSelectors.size();
for (int i = 0; i < size; i++) {
final ComponentSelector selector = (ComponentSelector)
this.transformerSelectors.get(i);
selector.release((Component) this.transformers.get(i));
this.newManager.release(selector);
}
In my method it would look like:
Iterator transformerItt = this.transformers.iterator();
...
int i = 0;
while (transformerItt.hasNext()) {
Transformer trans = (Transformer) transformerItt.next();
...
// check if the transformer should be run
..
// kick it out
transformerItt.remove();
// release transformer
final ComponentSelector selector = (ComponentSelector)
this.transformerSelectors.get(i);
selector.release((Component) trans);
this.newManager.release(selector);
i++;
}
Right?
Stefan
| -Ursprüngliche Nachricht-
| Von: Sylvain Wallez [mailto:[EMAIL PROTECTED]
| Gesendet: Montag, 1. Mai 2006 00:01
| An: dev@cocoon.apache.org
| Betreff: Re: AW: Desparately seeking help with pipeline implementation
|
| Stefan Pietschmann wrote:
| > | -Ursprüngliche Nachricht-
| > | Von: Sylvain Wallez [mailto:[EMAIL PROTECTED]
| > | Gesendet: Sonntag, 30. April 2006 14:00
| > | An: dev@cocoon.apache.org
| > | Betreff: Re: Desparately seeking help with pipeline implementation
| > |
| > | Stefan Pietschmann wrote:
| > | >
| > | > Hi guys,
| > | >
| > | > for my thesis I have implemented a custom pipeline, which modifies
| the
| > | > list of transformers to be run during pipeline setup. This is done
| > | > with every request in setupPipeline(), so I need to reset to the
| > | > original every time, before I modify again.
| > | >
| > |
| > | Why do you need that? Can't it be done by overloading one of
| > | setGenerator/addTransformer/setSerializer?
| >
| > I adapt the pipeline with every request according to some external data.
| > Isn't addTransformer() called only once when the pipeline is built? If
| it
| > is, I couldn't use it, because this would mean I adapt the pipeline
| once,
| > and all subsequent requests use the adapted one.
| > However, if this.transformers (and the other ArrayLists with the sources
| and
| > parameters) is built anew for every request, then this might be an easy
| way
| > out.
| >
|
| The contents of a pipeline is not reused across requests! All components
| are releases and cleared in recycle(), which occurs once the pipeline
| has been executed.
|
| The setGenerator/addTransformer/setSerializer are called by the sitemap
| engine when executing , and
| respectively.
|
| This is probably a good place if you want to automatically add some
| components to the pipeline, particularly considering that pipeline cache
| key and validity computation happens after these methods. Now if you
| remove some of the components that were already in the pipeline, don't
| forget to release them or you may encounter some memory leaks in object
| pools (see the code in AbstractProcessingPipeline)
So my
|
| > | Giving more details about the errors you obtain would be useful, but I
| > | guess this is more related to component pools than to multithreading.
| >
| > I can attach some stacktraces if that helps...
| >
|
| Yes, it always helps.
|
| > I only see that I only get problems when using multiple threads. The
| problem
| > might be related to anything else - I don't seem to understand how a
| > pipeline is used by multiple threads. I thought - since it's recycleable
| -
| > that each thread gets its own pipeline object.
| >
|
| Yes, pipelines
