date:20070819

Re: Cocoon Spring configurator

2007-08-19 Thread Carsten Ziegeler

Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>>> /META-INF/cocoon/spring when using Cocoon Spring configurator
>>> independently from
>>> Cocoon. It's probably not that hard to change but we should do it before
>>> propagating it :)
>> There are constants defined in
>> org.apache.cocoon.spring.configurator.impl.Constants.
>>
>> So changing this is very simple. The whole loading is done through own
>> xml elements (the "settings" element). Most classes in
>> org.apache.cocoon.spring.configurator.impl deals with this stuff.
> 
> That means that we can make this a configuration option of the settings
> element and its default value is "META-INF/cocoon/spring", right?
The best thing is that we already have this :)
you can embed "include-beans" and "include-properties" in the settings
element which allow you to read the configuration from additional locations.

Carsten


-- 
Carsten Ziegeler
[EMAIL PROTECTED]

Re: FYI: New Continuum instance

2007-08-19 Thread Reinhard Poetz


Grzegorz Kossakowski wrote:

Grzegorz Kossakowski pisze:

As for now, do you want me to change our setup?


After another batch e-mails I decided to remove all projects except 
Apache Cocoon that builds whole Cocoon recursively.


Thanks :-)

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: FYI: New Continuum instance

2007-08-19 Thread Felix Knecht

Grzegorz Kossakowski schrieb:
> Grzegorz Kossakowski pisze:
>> As for now, do you want me to change our setup?
> 
> After another batch e-mails I decided to remove all projects except
> Apache Cocoon that builds whole Cocoon recursively.
> 

+1 Thanks Grzegorz

Re: Pipeline components and Object Model issues

2007-08-19 Thread Joerg Heinicke


On 19.08.2007 18:12 Uhr, Grzegorz Kossakowski wrote:

But as you say it has to happen for EACH SAX event. I don't think it's 
lightweight. It happens hundreds times even for simple HTML pages - 
per component!


Correct me if I'm wrong but I thought that every pipeline component 
handles (even if it's simple forwarding) every single SAX event, right?


Yes.


If so performance loss would at the most two times slower.


What does this mean? This sentence makes no sense to me ;)


If you take into account components that actually do something the
performance loss could be less noticeable I think.


It's about complexity calculations [1]. Your approach is of O(m*n) with 
m = number of SAX events and n = number of components. The environment 
change has to be executed m*n times. With my approach it was only 
O(1*n). Ignore the number of components it's O(m) vs. O(1) - and number 
of SAX events can be huge. That's why it is not lightweight.


Why do you go this low-level approach and instead of just implementing 
a MethodInterceptor applied with Spring's AOP. That makes it 
independent from Spring itself since the interceptor can be applied 
differently later.


I'm not Spring specialist, BeanPostProcessor was the first thing I found 
in docs (chapter 3) that fitted my needs. I'll adjust my code tomorrow.


Auto-proxying only starts in chapter 7.9 [2] :)

You can probably just move the code of ScopeChangerProxy straight to a 
subclass of AbstractAdvisorAutoProxyCreator (which would be coupled to 
Spring as a BeanPostProcessor is, actually it is a BeanPostProcessor as 
well but does the proxying for you) or to a MethodInterceptor.


What original transformer writer could expect is that it's current state 
of it's Object Model (wrapper) is visible to the Bar component as it is 
derived from the transformer. As you guessed it, only unwrapped Object 
Model will be visible to the Bar component.


I see. The best lightweight approach is useless if it does not meet the 
requirements ;) Let me thnk about it ...


Joerg

[1] http://en.wikipedia.org/wiki/Computational_complexity_theory
[2] 
http://static.springframework.org/spring/docs/2.0.x/reference/aop-api.html#aop-autoproxy

Re: New expressions' syntax

2007-08-19 Thread Joerg Heinicke


On 17.08.2007 14:15 Uhr, Grzegorz Kossakowski wrote:

This leads us to small but very important question: how we wrap new 
expressions? If I'm not wrong, current preference  has been to wrap new 
expressions in {}, Daniel confirms[1] this view.


Hey guys, you are starting to confuse me. Up to recently I thought we 
are moving to ${}. That's why I asked few days ago. Now it is {}. And 
Daniel's proposal of JSR-245 points to ${} again. Yes, of course it is 
pluggable, but at some point we have to decide for a default one.


Actually I'm ok with both as long as it is "unified". Be it JSTL style 
or AVT style (attribute value template of XSLT).


If choose {} as wrapping characters everything put between 
this characters will be considered as expression.



We would need to escape {} wrapping characters:



It's ugly, don't you think?


That's probably why it is only *attribute* value template in XSLT. It 
works only in attributes and {} in attributes is highly unlikely. But 
I'm ok with {{ for escaping.



We could come up with %{}, !{} or whatever is not used yet.


I want to have fewer not more! ;)

Joerg

Re: Pipeline components and Object Model issues

2007-08-19 Thread Grzegorz Kossakowski

Joerg Heinicke pisze:

On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:

Same goes for all other SAX events. It's actually one extra get and
two puts calls on Map. Rather lightweight, yes?

But as you say it has to happen for EACH SAX event. I don't think it's
lightweight. It happens hundreds times even for simple HTML pages - per
component!

Correct me if I'm wrong but I thought that every pipeline component handles (even if it's simple
forwarding) every single SAX event, right? If so performance loss would at the most two times
slower. If you take into account components that actually do something the performance loss could be
less noticeable I think.

Why do you go this low-level approach and instead of just implementing a
MethodInterceptor applied with Spring's AOP. That makes it independent
from Spring itself since the interceptor can be applied differently later.

I'm not Spring specialist, BeanPostProcessor was the first thing I found in docs (chapter 3) that
fitted my needs. I'll adjust my code tomorrow.

I wonder if that's a requirement at all. IMO a properly scoped OM *is*
part of the component setup. So I would not even care if the
corresponding code has to be touched.

Anyway, I can't see where the simple wrapper approach fails. We'll get
kind of a hierarchical OM similar to Spring's hierarchical application
contexts. Creating the wrapped OM can happen in the same AOP/
BeanPostProcessor way, but it happens only on setup time and once, not
for each SAX event by intercepting the setObjectModel() method:

on setObjectModel(parentOM) on component xy
do xy.setObjectModel(new ObjectModelWrapper(parentOM))

The ObjectModelWrapper holds a map of local vars and delegates to the
parent OM if it can not find a value in its local vars.

Ok, so component (let it be transformer) has wrapped OM puts local variable on wrapper only. Now
imagine that transformer is BeanFactoryAware that uses some other component (let it be a Foo
component) to transform some elements. Foo components depends on Bar component, that in turn depends
on Object Model.

What original transformer writer could expect is that it's current state of it's Object Model
(wrapper) is visible to the Bar component as it is derived from the transformer. As you guessed it,
only unwrapped Object Model will be visible to the Bar component.

I hope that you understand now why scope and it's changing is needed.

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails
***
*** regularly and my work will be somehow irregular.
***
*** I'm already trying to switch ISP but it will take handful amount of time.
***

Re: Pipeline components and Object Model issues

2007-08-19 Thread Joerg Heinicke


On 17.08.2007 2:45 Uhr, Grzegorz Kossakowski wrote:

Not entirely true. ObjectModel can be modified during component's 
execution at random times, really. It happens all the time in template 
generator where Object Model is passed almost everywhere and it depends 
on incoming SAX events if OM will be modified. So it's predictable 
during setup phase but not during execution.


What I meant was that this modification of the OM happens in a 
predictable way (though potentially overly complex to predict). You can 
interrupt the processing at let's say the 100th SAX event and you know 
exactly how it looks like. Doing exactly the same on a second request 
there will be no difference.


Thread execution is not predictable at all.

I could agree with you that introduction of scope does not make sense in 
1:1-relationship but since component can make internal requests and if 
we want to provide some environment forwarding/sharing (see 
COCOON-2050[1] and [RT] The big picture of Servlet Service Framework 
e-mail[2] for examples where it could be needed) we will need to obtain 
OM and we should get exactly the same OM component making a request have.


I can't see how the environment changer approach is different than the 
simple wrapper in this regard. Somewhere you have to put the logic for 
environment forwarding/sharing anyway.


Actually this whole problem reminds me of session attributes in 
portlet environment.


 From my purist point of view I would say: just don't even think about 
it! ;)


That was just an idea. In the wrapper approach the difference is just 
about making the parent OM access read-only or also writeable.


It won't take much time until the first user is asking for this 
requirement though I bet ;)


Joerg

Re: New expressions' syntax

2007-08-19 Thread Grzegorz Kossakowski


Rainer Pruy pisze:

Daniel Fagerstrom schrieb:

Grzegorz Kossakowski skrev:

Daniel Fagerstrom pisze:

...


Simply choosing {} is not a solution because there will be no smooth
migration path for two reasons:
  a) some JX may break as proved above
  b) it's all or nothing situation, if someone (or we) decides to
switch to new expressions their existing applications simply break

Such radical step has its own benefits but I'm not sure if it's
exactly what you would agree with.

We are not forcing anyone to use the new unified ELs, we just offer
people to do that if they feel like it. It is just a configuration setting.

/Daniel


Hmm, leaving me wonder, whether such configuration can be decided upon
on a per block basis.
Otherwise, if I'd choose using "new" EL I would be prevented from using
blocks that stick to "old" world and vice-versa?


I'm not sure if we have mechanism for per block configuration but I fear you may be right. AFAIK, 
main merit of Cocoon's (future) OSGi integration is blocks isolation.


That's why I had this intuitive to enable people mix old and new syntax. Any 
thoughts?

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: FYI: New Continuum instance

2007-08-19 Thread Grzegorz Kossakowski


Grzegorz Kossakowski pisze:

As for now, do you want me to change our setup?


After another batch e-mails I decided to remove all projects except Apache Cocoon that builds whole 
Cocoon recursively.


--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails 
***
*** regularly and my work will be somehow irregular.  
***
*** I'm already trying to switch ISP but it will take handful amount of time. 
***

Re: Pipeline components and Object Model issues

2007-08-19 Thread Joerg Heinicke


On 19.08.2007 16:30 Uhr, Daniel Fagerstrom wrote:

We could do something similar for sitemap components and 
maybe go further and have convention based autoviring so e.g. a set 
method that takes a ServletRequest automatically get the one from the 
call injetcted.


No auto-wiring in Spring - it's considered to be evil ;) And what you 
call convention-based auto-wiring is supported by Spring anyway, so 
there is no need to do anything. Spring supports auto-wiring by type and 
by name [1]. So if anybody really wants that, he can activate it.


(With exception of the request since it is not available as Spring bean. 
So you have to invent something else anyway.)


Joerg

[1] 
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-autowire

Re: Default Expression Language

2007-08-19 Thread Ralph Goers

Actually, now that you mention it one of the things I've disliked about 
flow is that you can only specify a single interpreter per sitemap. One 
should be able to have a single sitemap that uses multiple expression 
languages, possibly even in the same pipeline.


Alfred Nathaniel wrote:

On Sun, 2007-08-19 at 21:20 +0200, Daniel Fagerstrom wrote:
  
Thanks to Grzegorz efforts, we are now close to be able to use the same 
exprssion language and object model both in the sitemap and in templates.


The whole thing is plugable, so those who have large investments in the 
current syntax and models can continue using them.


But while flexibillity is good for back compability it is confusing for 
new users. So we should try hard to decide what should be the default 
expression language and expression syntax.


Once I preffered JXPath as my webapps where XML-centric and I used XSLT 
and XPath everywhere. But now my webapps is more Java based, so JEXL or 
JS seem more natural. Of these I prefer JEXL as JS is a little bit to 
powerful as an EL for my taste.


But is the rest of world really using JEXL, JS or JXPath as ELs? 
Wouldn't it be a better idea to use the Unified Expression Language (EL) 
of JSP 2.1 (JSR-245) 
(http://en.wikipedia.org/wiki/Unified_Expression_Language). To me it 
seem like a rather good EL and there are several Apache licenced 
implementations, Tomcat has one and there is another one called JUEL 
http://juel.sourceforge.net/.


WDYT?

/Daniel



Maybe there is no good default at all!

How about specifying in the sitemap which expression language is used in
it?  And if this specification is missing, the default is the good old
input module.

Cheers, Alfred.

Re: Default Expression Language

2007-08-19 Thread Alfred Nathaniel

On Sun, 2007-08-19 at 21:20 +0200, Daniel Fagerstrom wrote:
> Thanks to Grzegorz efforts, we are now close to be able to use the same 
> exprssion language and object model both in the sitemap and in templates.
> 
> The whole thing is plugable, so those who have large investments in the 
> current syntax and models can continue using them.
> 
> But while flexibillity is good for back compability it is confusing for 
> new users. So we should try hard to decide what should be the default 
> expression language and expression syntax.
> 
> Once I preffered JXPath as my webapps where XML-centric and I used XSLT 
> and XPath everywhere. But now my webapps is more Java based, so JEXL or 
> JS seem more natural. Of these I prefer JEXL as JS is a little bit to 
> powerful as an EL for my taste.
> 
> But is the rest of world really using JEXL, JS or JXPath as ELs? 
> Wouldn't it be a better idea to use the Unified Expression Language (EL) 
> of JSP 2.1 (JSR-245) 
> (http://en.wikipedia.org/wiki/Unified_Expression_Language). To me it 
> seem like a rather good EL and there are several Apache licenced 
> implementations, Tomcat has one and there is another one called JUEL 
> http://juel.sourceforge.net/.
> 
> WDYT?
> 
> /Daniel

Maybe there is no good default at all!

How about specifying in the sitemap which expression language is used in
it?  And if this specification is missing, the default is the good old
input module.

Cheers, Alfred.

Re: [VOTE] Division of Cocoon's JIRA project

2007-08-19 Thread Alfred Nathaniel

On Sun, 2007-08-19 at 17:44 +0200, Reinhard Poetz wrote:
> What I mean is that one release cycle should have one Jira project. As soon 
> as 
> we have two modules that have _different_ release cycles and managed by _one_ 
> Jira project, I don't understand what we gain compared to the status quo.

Personally, I don't believe that the idea of different release cycles
will fly for very long.  In the end there will be the same sort of
problems getting a grip on the version compatibilities which made the
Eclipse people invent the Callisto approach.

And with 100 open JIRA issues, I don't see the necessity of splitting
into smaller parts.  Splitting also assumes that the reporting user is
able to pinpoint the part where his particular problems stems from.  If
he makes a mistake there, we can correct it by changing the project to
which it refers -- but that breaks each time the URL.

So here's my -0.

Cheers, Alfred.

Re: Default Expression Language

2007-08-19 Thread Ralph Goers

For 2.2 I suggest that what we recommend should be the default. However, 
it should clearly be documented how to reconfigure to match 2.1.  As far 
as which one to choose, I would look at:

1. Compatible license
2. Documentation
3. Performance
4. Ease of integration. (i.e. doesn't have to be ripped from some other 
jar, doesn't have a lot of dependencies we don't already have, etc.)


Ralph

Daniel Fagerstrom wrote:
Thanks to Grzegorz efforts, we are now close to be able to use the 
same exprssion language and object model both in the sitemap and in 
templates.


The whole thing is plugable, so those who have large investments in 
the current syntax and models can continue using them.


But while flexibillity is good for back compability it is confusing 
for new users. So we should try hard to decide what should be the 
default expression language and expression syntax.


Once I preffered JXPath as my webapps where XML-centric and I used 
XSLT and XPath everywhere. But now my webapps is more Java based, so 
JEXL or JS seem more natural. Of these I prefer JEXL as JS is a little 
bit to powerful as an EL for my taste.


But is the rest of world really using JEXL, JS or JXPath as ELs? 
Wouldn't it be a better idea to use the Unified Expression Language 
(EL) of JSP 2.1 (JSR-245) 
(http://en.wikipedia.org/wiki/Unified_Expression_Language). To me it 
seem like a rather good EL and there are several Apache licenced 
implementations, Tomcat has one and there is another one called JUEL 
http://juel.sourceforge.net/.


WDYT?

/Daniel

Re: Pipeline components and Object Model issues

2007-08-19 Thread Daniel Fagerstrom


Grzegorz Kossakowski skrev:
[Snipping lots of technical details]
I want to create dynamic proxies around pipeline components. Actual 
wrapping would be performed by class implementing BeanPostProcessor 
interface. Taking one perspective one could say that this it's almost 
the way as discussed one paragraph above. However, going with this path 
makes whole pipeline scope completely *orthogonal* to the pipeline and 
its components' code. No existing class will be touched and there is no 
requirement on pipeline components' configuration files. No need for 
custom namespace in XML config, etc.


I feel proud of this solution as it solves non-trivial problem just in 
few lines of code and few config files in transparent way. 8-)


Seem like a neat solution.

Actually there are more that could be done with BeanPostProcessors.

As you know sitemap components has a rather involved life cycle, where 
they first are created by the container and then the setup method is 
called in the pipeline to insert the object model, the parameters and 
some other stuff. Now if these objects already are part of the sitemap 
scope, we could have a special SitemapModelComponent aware 
BeanPostProcessor that just takes the needed objects from the current 
scope and use the for setting up the sitemap component.


What is needed is that the right scope is set before looking up the 
sitemap component from the container. This will only work for prototype 
scoped beans as we must be sure that they actually are created in the 
scope where they are looked up. All Springified sitemap components are 
prototypes, (I don't know how it would work for the Avalon bridge 
handled components).


This far we only have a possible simplification of the setup mechanism. 
But with other BeanPostProcessors we could get the same style of 
interceptor based dependecy injection as in Struts2, where various 
request objects are injected in the action bean based on marker 
interfaces. We could do something similar for sitemap components and 
maybe go further and have convention based autoviring so e.g. a set 
method that takes a ServletRequest automatically get the one from the 
call injetcted.


We could use the same mechanism for a new type of actions that are 
created in prototype scope and get all dependencies injected by Spring 
in the sitemap scope.


/Daniel

Re: Pipeline components and Object Model issues

2007-08-19 Thread Joerg Heinicke


On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:

Same goes for all other SAX events. It's actually one extra get and two 
puts calls on Map. Rather lightweight, yes?


But as you say it has to happen for EACH SAX event. I don't think it's 
lightweight. It happens hundreds times even for simple HTML pages - per 
component!


I want to create dynamic proxies around pipeline components. Actual 
wrapping would be performed by class implementing BeanPostProcessor 
interface.


Why do you go this low-level approach and instead of just implementing a 
MethodInterceptor applied with Spring's AOP. That makes it independent 
from Spring itself since the interceptor can be applied differently later.



However, going with this path makes whole pipeline scope completely
*orthogonal* to the pipeline and its components' code.


I wonder if that's a requirement at all. IMO a properly scoped OM *is* 
part of the component setup. So I would not even care if the 
corresponding code has to be touched.


Anyway, I can't see where the simple wrapper approach fails. We'll get 
kind of a hierarchical OM similar to Spring's hierarchical application 
contexts. Creating the wrapped OM can happen in the same AOP/ 
BeanPostProcessor way, but it happens only on setup time and once, not 
for each SAX event by intercepting the setObjectModel() method:


on setObjectModel(parentOM) on component xy
do xy.setObjectModel(new ObjectModelWrapper(parentOM))

The ObjectModelWrapper holds a map of local vars and delegates to the 
parent OM if it can not find a value in its local vars.


Joerg

1 2 >

1 - 100 of 139 matches

Mail list logo