date:20080715


Reinhard Pötz wrote:


currently corona-pipeline (pipeline API, pipeline impls, SAX components) 
only has a dependency on commons-logging. Is this good enough for your 
needs?

:) Ok, that should be fine.

I've moved the action to the sitemap module and split up execute into 
setup and execute. I think we should specify in the contract that a 
modifiable map is passed to the components during setup. Any objections?


I'm wondering if we need the ErrorThrowingAction and the CustomException?

I'll add a setup/cleanup method to the components next.

Carsten


--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [Corona] PIpeline API


Carsten Ziegeler wrote:

Reinhard Pötz wrote:


currently corona-pipeline (pipeline API, pipeline impls, SAX 
components) only has a dependency on commons-logging. Is this good 
enough for your needs?

:) Ok, that should be fine.

I've moved the action to the sitemap module and split up execute into 
setup and execute. I think we should specify in the contract that a 
modifiable map is passed to the components during setup. Any objections?


Currently sitemap components get passed to maps:

 1. the input parameters (a map of all objects that you want to pass
to a pipeline)

 2. the configuration parameters (to provide a way to pass parameters
from the sitemap to the component - for API usage those parameters
are usually passed by constructor parameters or by setters).

Are you talking about passing the input parameters as parameters of the 
setup() method?


void setup(MapString, Object inputParameters)

I'd be fine by this.


I'm wondering if we need the ErrorThrowingAction and the CustomException?


That is only needed for some integration tests in corona-sample where 
they should be moved to.



I'll add a setup/cleanup method to the components next.


ok

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes

2008-07-15 Thread Christoph Gaffga (JIRA)

[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613580#action_12613580
]

Christoph Gaffga commented on COCOON-2216:
--

the patch fixes the DefaultIncludeCacheManager, so it can do parallel
includions, but their still is an issue with the ObjectModel that does not
support multi-threading. Resulting in random strange exceptions. Still need to
be fixed

IncludeCacheManager can not perfom parallel includes

Key: COCOON-2216
URL: https://issues.apache.org/jira/browse/COCOON-2216
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Christoph Gaffga
Attachments: ParallelInclusionProblem-cocoon_TRUNK.patch

Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
sources from other cocoon pipelines into one (similar to the aggregator) is
not working anymore.
We also posted our problem to the mailing list, got little feedback but it
brought us on the right way...
see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
I found out that it's a problem with the DefaultIncludeCacheManager, that can
not do parallel inclusion of cocoon-pipelines anymore. I checked several
classes where inclusion is used. In the aggregator parallel inclusion is not
an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
but it can't do parallel inclusion. In the new IncludeTransfomer parallel
inclusion is supported, but it does not use caching as it does not use the
IncludeCacheManager...
But we needed caching AND parallel processing, so I tried to find out what's
broken in the DefaultIncludeCacheManager:
and it seems that the ThreadLocal variables are not initialized for the child
threads that do the inclusion. Neither the spring context nor the old
environment stuff was initialized. And all the source resolving was done
outside the child thread and that way using the wrong thread context.
We were able to fix that issue by small changes to DefaultIncludeCacheManager
and IncludeCacheManagerSession. It would be great if somebody could apply
this patch so we don'T have to patch every cocoon version again and again...

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Spring Configurator - filter/include strategy


Hi Cocooners,

I would like to implement handling of pluggable include or filtering strategies for properties and 
beans definitions files in Spring Configurator.


Even if I strongly believe that usually it's better to stick to the conventions Configurator 
enforces or use wildcard patterns there are some situations when more sophisticated logic is needed. 
My use-case is that some Spring beans should be included only if appropriate license file is 
provided in the classpath. This way one can enable and disable modules depending on what license 
file provide. This can be generalized to use-case when one wants to include some beans depending on 
some configuration options.


The idea is to implement handling of include or filtering strategies that would be just a simple 
Java classes. For include strategy interface could look like:


public interface IncludeStrategy {
Set include();
}

where the set would contain URLs pointing to properties/beans need to be 
included.

On the other hand, filter would look like:
public interface FilterStrategy {
Set filter(Set urls);
}

so the Spring Configurator would first prepare a set of URLs of resources it wants to include and 
call the filter to filter them out. Actually, in the second approach there is nothing that enforces 
filtering behaviour on a class implementing the filter. There would be possibility to add any 
arbitrary URLs the class implementing the filter like.


Therefore I'm in favor of implementing the second approach option and initially allow to define only 
one filter in following way:


configurator:settings
  configurator:resource-filter class=org.sth.FilterClass/
/configurator:settings


What are your opinions on this idea? I would like to start implementing this 
tomorrow.

Of course, this change (bringing some new functionality) will bump version number of both 
Configurator API and Spring Configurator to 1.1.x.


--
Best regards,
Grzegorz Kossakowski

Re: Spring Configurator - filter/include strategy


Hi,

I'm not sure what the best way is - but the jetspeed folks followed a 
different road and added conditionals inside the configuration files.
So only if a criteria is met something is added. I tried to convince 
them to use the spring configurator and add the logic here...

So perhaps this is something we could add on top of the configurator now?

Carsten

Grzegorz Kossakowski wrote:

Hi Cocooners,

I would like to implement handling of pluggable include or filtering 
strategies for properties and beans definitions files in Spring 
Configurator.


Even if I strongly believe that usually it's better to stick to the 
conventions Configurator enforces or use wildcard patterns there are 
some situations when more sophisticated logic is needed. My use-case is 
that some Spring beans should be included only if appropriate license 
file is provided in the classpath. This way one can enable and disable 
modules depending on what license file provide. This can be generalized 
to use-case when one wants to include some beans depending on some 
configuration options.


The idea is to implement handling of include or filtering strategies 
that would be just a simple Java classes. For include strategy interface 
could look like:


public interface IncludeStrategy {
Set include();
}

where the set would contain URLs pointing to properties/beans need to be 
included.


On the other hand, filter would look like:
public interface FilterStrategy {
Set filter(Set urls);
}

so the Spring Configurator would first prepare a set of URLs of 
resources it wants to include and call the filter to filter them out. 
Actually, in the second approach there is nothing that enforces 
filtering behaviour on a class implementing the filter. There would be 
possibility to add any arbitrary URLs the class implementing the filter 
like.


Therefore I'm in favor of implementing the second approach option and 
initially allow to define only one filter in following way:


configurator:settings
  configurator:resource-filter class=org.sth.FilterClass/
/configurator:settings


What are your opinions on this idea? I would like to start implementing 
this tomorrow.


Of course, this change (bringing some new functionality) will bump 
version number of both Configurator API and Spring Configurator to 1.1.x.





--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [Corona] PIpeline API

2008-07-15 Thread Joerg Heinicke

Carsten Ziegeler cziegeler at apache.org writes:

  c) Pre and post processing
  As the pipeline interfaces are not tied to sax or any other model 
  (which is ok), there is no explicit notion of indicating that the 
  processing starts or is finished - the latter is especially 
  interesting for cleanup. So I think we should add these two lifecycle 
  methods to the pipeline component interface.
  
  I don't see any problem either. Being curious, what are your use cases?
 I've some pipeline components that open/close resources, like a JCR 
 session for instance. If the contract includes that the pre and post 
 processing methods are always called, the post processing method acts 
 like kind of a disposal method where I can close my session.
 I've other - in this sense rather obscure - use cases where the pipeline 
 components need to pass information back to the caller before the 
 processing starts. So the caller calls the pre processing method where 
 the pipeline component adds something to the map, the caller can pick it 
 up and then start the processing based in this information.

Isn't that a rather specific use case? It feels kinda wrong when lifecycle
methods will now pollute the pipeline interfaces rather than letting pipeline
components implement lifecycle interfaces. Doesn't Spring show how to do these
kind of things with templates or aspects?

And is there actually something like start and end in a pipeline? How do you
determine that? It's rather easy with SAX since there is startDocument() and
endDocument() but in general?

It's not an objection, just some thoughts ...

Joerg

Re: Spring Configurator - filter/include strategy


Carsten Ziegeler pisze:

Hi,

I'm not sure what the best way is - but the jetspeed folks followed a 
different road and added conditionals inside the configuration files.
So only if a criteria is met something is added. I tried to convince 
them to use the spring configurator and add the logic here...

So perhaps this is something we could add on top of the configurator now?


Hi Carsten,

I fail to follow you on your answer so I have a couple of questions:
1. What logic you wanted to added here? Support for some syntax of conditional includes? If so, 
how this would look like?

2. What do you mean by adding something on top of configurator?
3. What's your opinion about my proposal itself?

I'm really with you when it comes to increasing number of users of Spring Configurator but I need 
little bit more clear strategy here. ;-)


--
Best regards,
Grzegorz Kossakowski

Re: Spring Configurator - filter/include strategy


Grzegorz Kossakowski wrote:

Carsten Ziegeler pisze:

Hi,

I'm not sure what the best way is - but the jetspeed folks followed a 
different road and added conditionals inside the configuration files.
So only if a criteria is met something is added. I tried to convince 
them to use the spring configurator and add the logic here...

So perhaps this is something we could add on top of the configurator now?


Hi Carsten,

I fail to follow you on your answer so I have a couple of questions:
1. What logic you wanted to added here? Support for some syntax of 
conditional includes? If so, how this would look like?

2. What do you mean by adding something on top of configurator?
3. What's your opinion about my proposal itself?

I'm really with you when it comes to increasing number of users of 
Spring Configurator but I need little bit more clear strategy here. ;-)



Fair enough :)

Now I was very brief as I'm not 100% sure how the final solution in 
jetspeed looks like.


Ok, our spring configurator includes all files located at a specific 
location and adds all bean definitions found there.

The jetspeed guys enhanced the spring bean configuration format to have
conditionals inside a bean xml definition, so something like (don't 
quote me on the syntax):

j:if test=database.derby
  bean name=database ...the derby bean
j:if
j:else
  bean name=database ...the hsqldb bean
/j:else

This allows to have all relevant bean definitions at one single place 
and at runtime it's decided which beans to use.

So this is somthing on top of the configurator as this doesn't effect
the current configurator code but is just additional stuff.

But rereading your use case, I assume that you want to skip whole jar 
files, right? So this would be something in the spring configurator of

course.

Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: Spring Configurator - filter/include strategy


Carsten Ziegeler pisze:

Fair enough :)

Now I was very brief as I'm not 100% sure how the final solution in 
jetspeed looks like.


Ok, our spring configurator includes all files located at a specific 
location and adds all bean definitions found there.


Yep, and currently you have no option to filter out something depending on some 
results from runtime.


The jetspeed guys enhanced the spring bean configuration format to have
conditionals inside a bean xml definition, so something like (don't 
quote me on the syntax):

j:if test=database.derby
  bean name=database ...the derby bean
j:if
j:else
  bean name=database ...the hsqldb bean
/j:else

This allows to have all relevant bean definitions at one single place 
and at runtime it's decided which beans to use.

So this is somthing on top of the configurator as this doesn't effect
the current configurator code but is just additional stuff.


Yes, agreed but still I cannot help my feeling that such conditionals are simply a bad idea. Having 
everything in one place is a benefit of course but on the other hand I would prefer to use 
directories or file name patterns (known from file systems) to distinguish between various, separate 
options. That feels much more natural for me.


Then you would still need to have some conditional processing but that could be a simple Java class 
that picks up the right resources.


It's maybe a matter of a taste but introduction of any logic to the configuration is wrong. 
Configuration should be always declarative not imperative, IMHO.


But rereading your use case, I assume that you want to skip whole jar 
files, right? So this would be something in the spring configurator of

course.


Yes. At least, I need something that will let me to skip some inclusions and what should be skipped 
must be calculated at runtime. That's why I want to introduce the idea of filter to the Spring 
Configurator.


--
Grzegorz Kossakowski

Re: Spring Configurator - filter/include strategy


Grzegorz Kossakowski wrote


Yes, agreed but still I cannot help my feeling that such conditionals 
are simply a bad idea. Having everything in one place is a benefit of 
course but on the other hand I would prefer to use directories or file 
name patterns (known from file systems) to distinguish between various, 
separate options. That feels much more natural for me.


Then you would still need to have some conditional processing but that 
could be a simple Java class that picks up the right resources.


It's maybe a matter of a taste but introduction of any logic to the 
configuration is wrong. Configuration should be always declarative not 
imperative, IMHO.

Hehe, I actually suggested the same approach to the jetspeed people as
I think it's clearer to have separate files and you just choose at 
runtime which files to use. But as you say, it's a matter of taste.




But rereading your use case, I assume that you want to skip whole jar 
files, right? So this would be something in the spring configurator of

course.


Yes. At least, I need something that will let me to skip some inclusions 
and what should be skipped must be calculated at runtime. That's why I 
want to introduce the idea of filter to the Spring Configurator.



Yeah, that's fine.

Carsten

--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: Spring Configurator - filter/include strategy


Grzegorz Kossakowski wrote:
Of course, this change (bringing some new functionality) will bump 
version number of both Configurator API and Spring Configurator to 1.1.x.


Because of our latest refactorings (move block deployment into its own 
module), we have to release 1.1.0 anyway.


As I wrote in my mail last week, I'd like to create the release 
artifacts for all subprojects next week (~ Wednesday). Would this 
schedule be fine by you?


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Spring Configurator - filter/include strategy


Carsten Ziegeler wrote:

Grzegorz Kossakowski wrote


Yes, agreed but still I cannot help my feeling that such conditionals 
are simply a bad idea. Having everything in one place is a benefit of 
course but on the other hand I would prefer to use directories or file 
name patterns (known from file systems) to distinguish between 
various, separate options. That feels much more natural for me.


Then you would still need to have some conditional processing but that 
could be a simple Java class that picks up the right resources.


It's maybe a matter of a taste but introduction of any logic to the 
configuration is wrong. Configuration should be always declarative not 
imperative, IMHO.

Hehe, I actually suggested the same approach to the jetspeed people as
I think it's clearer to have separate files and you just choose at 
runtime which files to use. But as you say, it's a matter of taste.


yes, I agree with you both. IMHO you have a design problem with your 
application when you have to introduce conditionals in configuration files.


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Spring Configurator - filter/include strategy


Reinhard Pötz pisze:

Grzegorz Kossakowski wrote:
Of course, this change (bringing some new functionality) will bump 
version number of both Configurator API and Spring Configurator to 1.1.x.


Because of our latest refactorings (move block deployment into its own 
module), we have to release 1.1.0 anyway.


Ah, right, forgot about your refactorings.

Are you sure that all of your changes (at least affecting Spring Configurator) are back-compatible? 
If not then we'll need to release 2.0.0 I guess.


As I wrote in my mail last week, I'd like to create the release 
artifacts for all subprojects next week (~ Wednesday). Would this 
schedule be fine by you?




Yes, that's totally fine by me. I should start my work today or tomorrow.

--
Best regards,
Grzegorz Kossakowski

Re: Spring Configurator - filter/include strategy

2008-07-15 Thread Ralph Goers


Carsten Ziegeler wrote:


Now I was very brief as I'm not 100% sure how the final solution in 
jetspeed looks like.


Ok, our spring configurator includes all files located at a specific 
location and adds all bean definitions found there.

The jetspeed guys enhanced the spring bean configuration format to have
conditionals inside a bean xml definition, so something like (don't 
quote me on the syntax):

j:if test=database.derby
  bean name=database ...the derby bean
j:if
j:else
  bean name=database ...the hsqldb bean
/j:else
Wow. It looks like Maven 1 jelly code. Next you will see for loops and 
ant tasks!


I'm not crazy about XML as a programming language. The information 
needed to make decisions should be in the XML, not the logic.


Ralph

Re: [Corona] PIpeline API

2008-07-15 Thread Peter Hunsberger

On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:

 Are you talking about passing the input parameters as parameters of the
 setup() method?

 void setup(MapString, Object inputParameters)

 I'd be fine by this.


I hate seeing Maps used as dumping grounds for randomly typed objects.
Could you use something that gives a little more strong typing?
Perhaps more like a ServletContext though I don't think I'd go that
far in this case?

-- 
Peter Hunsberger

Re: [Corona] PIpeline API


Reinhard Pötz wrote:

Carsten Ziegeler wrote:

Reinhard Pötz wrote:


currently corona-pipeline (pipeline API, pipeline impls, SAX 
components) only has a dependency on commons-logging. Is this good 
enough for your needs?

:) Ok, that should be fine.

I've moved the action to the sitemap module and split up execute into 
setup and execute. I think we should specify in the contract that a 
modifiable map is passed to the components during setup. Any objections?


Currently sitemap components get passed to maps:

 1. the input parameters (a map of all objects that you want to pass
to a pipeline)

 2. the configuration parameters (to provide a way to pass parameters
from the sitemap to the component - for API usage those parameters
are usually passed by constructor parameters or by setters).

Are you talking about passing the input parameters as parameters of the 
setup() method?


void setup(MapString, Object inputParameters)

I'd be fine by this.


Yes, this is what I did.

Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [Corona] PIpeline API


Peter Hunsberger wrote:

On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:


Are you talking about passing the input parameters as parameters of the
setup() method?

void setup(MapString, Object inputParameters)

I'd be fine by this.



I hate seeing Maps used as dumping grounds for randomly typed objects.
Could you use something that gives a little more strong typing?
Perhaps more like a ServletContext though I don't think I'd go that
far in this case?

I agree that strong typing would be great - but the pipeline api does 
not define any concrete key/object for the map. So this is use-case 
specific. Therefore I think a map is the best we can come up.


Carsten

--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [Corona] PIpeline API


Joerg Heinicke wrote:

Carsten Ziegeler cziegeler at apache.org writes:


c) Pre and post processing
As the pipeline interfaces are not tied to sax or any other model 
(which is ok), there is no explicit notion of indicating that the 
processing starts or is finished - the latter is especially 
interesting for cleanup. So I think we should add these two lifecycle 
methods to the pipeline component interface.

I don't see any problem either. Being curious, what are your use cases?
I've some pipeline components that open/close resources, like a JCR 
session for instance. If the contract includes that the pre and post 
processing methods are always called, the post processing method acts 
like kind of a disposal method where I can close my session.
I've other - in this sense rather obscure - use cases where the pipeline 
components need to pass information back to the caller before the 
processing starts. So the caller calls the pre processing method where 
the pipeline component adds something to the map, the caller can pick it 
up and then start the processing based in this information.


Isn't that a rather specific use case? It feels kinda wrong when lifecycle
methods will now pollute the pipeline interfaces rather than letting pipeline
components implement lifecycle interfaces. Doesn't Spring show how to do these
kind of things with templates or aspects?

And is there actually something like start and end in a pipeline? How do you
determine that? It's rather easy with SAX since there is startDocument() and
endDocument() but in general?

Hmm, someone starts the pipeline and at some point of time it ends :) As 
we have an execute() method on the pipeline, the contract is that if 
execute returns, the pipeline is finished. Therefore it's easy to call 
the according methods inside execute() - regardless which model is used 
between the pipeline components.

We have the pre-execution method already - thats the setup(Map) method.
I added now a finish method which is called by the pipeline implementation.
This keeps me free from any configuration hassels with the various 
containers. Some want to use spring, some others something different. 
And perhaps someone doesn't want to use a container at all, just 
instantiate the objects, run the pipeline and that's it.

Therefore I really think that these lifecycle methods belong to the api.
I see no other reliable way of closing resources.

Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: How to enable the Flowscript Debugger in C2.2 OR how to set properites on avalon components in C2.2?

2008-07-15 Thread Hugh Sparks


I made a very slight amount of progress getting the
flowscript interpreter to work.

First of all, it does not work for me at all when using jetty.
But with the following setup, I was able to get the
flowscript debugger window to appear running under
tomcat.

I extracted the cocoon-flowscript.xconf from the
current svn and put it in this directory:

tomcat\webapps\cocoon\WEB-INF\classes\META-INF\cocoon\avalon

This file was edited to enable debugging. I didn't bother
with using a parameter:

   ...
   debuggerenabled/debugger
   ...

When I fire up an application that uses flowscript, the
debugger window appears on the desktop. The controls
and menus are active but no source is shown. The application
throws up a list of error messages.

Here are some highlights of the traceback:

javax.servlet.ServletException:
   org.apache.cocoon.ProcessingException:
   Sitemap: error when calling sub-sitemap

org.apache.avalon.framework.service.ServiceException:
   Exception during lookup of component with
   'org.apache.cocoon.components.flow.Interpreter/javascript'.
   (Key='AvalonServiceManager')

root cause

org.springframework.beans.factory.BeanCreationException:
  Error creating bean with name
   'org.apache.cocoon.components.flow.Interpreter/javascript':
   Initialization of bean failed; nested exception is
   org.springframework.beans.factory.BeanCreationException:
   Unable to initialize Avalon component with role
   org.apache.cocoon.components.flow.Interpreter/javascript;
   nested exception is java.lang.IllegalStateException

org.springframework.beans.factory.BeanCreationException:
   Unable to initialize Avalon component with role
   org.apache.cocoon.components.flow.Interpreter/javascript;
   nested exception is java.lang.IllegalStateException

Perhaps this will help someone take the next step.

-Hugh Sparks, [EMAIL PROTECTED]

Re: [Corona] PIpeline API

2008-07-15 Thread Torsten Curdt



On Jul 15, 2008, at 18:33, Carsten Ziegeler wrote:


Peter Hunsberger wrote:
On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz  
[EMAIL PROTECTED] wrote:
Are you talking about passing the input parameters as parameters  
of the

setup() method?

void setup(MapString, Object inputParameters)

I'd be fine by this.

I hate seeing Maps used as dumping grounds for randomly typed  
objects.

Could you use something that gives a little more strong typing?
Perhaps more like a ServletContext though I don't think I'd go that
far in this case?
I agree that strong typing would be great - but the pipeline api  
does not define any concrete key/object for the map. So this is use- 
case specific. Therefore I think a map is the best we can come up.


The question if those configuration are needed in a generic form in  
the API. (I doubt it) As I would expect them to be implementation  
specific a configuration callback that sets up the pipeline might be a  
way around this?


Just my 2 cents

cheers
--
Torsten

Re: [Corona] PIpeline API