environment abstraction in Cocoon 2.2 (was: Cannot get JSPReader/JSPGenerator to work)

[Joerg Heinicke <jo...@gmx.de>]

On 07.10.2006 14:43, Laurent Perez wrote:

> I'm using JSPs an Cocoon 2.2, but I still don't understand if I did
> the "right" integration : basically, my usecase requires custom JSP
> tags to be able to retrieve XML from sitemap patterns. Under 2.1, I
> wrote an integration method starting up a CocoonBean instance and use
> resolveURI() on it, but it was quite ugly, so since I was already
> using Spring, I switched to 2.2 and what I did was to add a setter for
> a SourceResolver in my base custom tag class and then "dependency
> inject" it via my applicationContext.xml in spring/ folder (my base
> custom tag class uses a @Configurable to let the injections work).

This is indeed a really complex integration and goes beyond the standard 
case. You are using JSPs as templating language inside Cocoon which it 
was never targetted for, but only as XML producer decoupled from the 
rest of Cocoon.

> The wiring works, all my custom tags can use the injected resolver,
> but I HAD to enable the Cocoon JSPReader (map:match pattern="**.jsp",
> map:read src(...) type="jsp") to deliver my jsps, otherwise the called
> resolver would throw an exception saying it requires an Environment
> setup in order to work.
> 
> So, it looks like I'm still using a 2.2 environment abstraction, but
> your post confuses me : would the block:/ protocol ease my integration?

Wondering about your problem I had a look into the code - and the 
environment abstraction indeed still exists. I thought it already has 
been removed. I send this mail to dev list too, maybe somebody can 
comment on this (Daniel, Carsten ?)

For your integration (custom tags accessing Cocoon) the block protocol 
probably can't help. But instead of a CocoonBean you would be able to 
use the RequestProcessor, which should be much more lightweight.

Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: environment abstraction in Cocoon 2.2

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote
>> ... we can, though, introduce new behavior for new "cocoon:" scoped attributes. 
>> (Similarly, there is special processing going on for "cocoon:" prefixed request 
>> parameters).
>>
> You mean adding special handling for example for all request attributes
> using "org.apache.cocoon." as the prefix for their name?

Yep

Vadim

Re: environment abstraction in Cocoon 2.2

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote
> ... we can, though, introduce new behavior for new "cocoon:" scoped attributes. 
> (Similarly, there is special processing going on for "cocoon:" prefixed request 
> parameters).
> 
You mean adding special handling for example for all request attributes
using "org.apache.cocoon." as the prefix for their name?

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: environment abstraction in Cocoon 2.2

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> IIUC original issue was about adding "all request relevant information as 
>> attributes of the request object". Since for sub request those will be 
>> attributes of sub request, they will not interfere with parent request: sub 
>> request's "objectModel" (or "flowContext", etc) will mask parent's completely 
>> and thus won't allow modification of parent's "objectModel".
>>
> Unfortunately this is not the way it has been implemented. Currently the
> sub request uses an own request object but *shares* the attributes map
> with the parent request. And this means it can override and delete values.
> I'm not sure if we can change this (if people are relying on this
> behaviour it would break their code).

... we can, though, introduce new behavior for new "cocoon:" scoped attributes. 
(Similarly, there is special processing going on for "cocoon:" prefixed request 
parameters).

Vadim

Re: environment abstraction in Cocoon 2.2

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
> Peter Hunsberger wrote:
>> On 10/10/06, Vadim Gritsenko <va...@reverycodes.com> wrote:
>>> Peter Hunsberger wrote:
>>>> On 10/9/06, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>
>>>>>> But just adding all this stuff to request attributes is not that
>>>>>> easy as
>>>>>> unfortunately sub request are sharing the attributes with the main
>>>>>> request. So whenever you use the cocoon protocol the main request 
>>>>>> and
>>>>>> the sub request use the same set of attributes.
>>> Sub request by definition is the separate Request object with own set of
>>> attributes (potentially with ability to access parent or global request
>>> attributes - via special convention, may be?). Once sub request is 
>>> completed,
>>> all sub request attributes shall be discarded, leaving environment 
>>> only with
>>> parent attributes. Does it make sense?
>> It's the bit about "potentially with ability to access parent or
>> global request" that seems to be the issue really isn't it?  I can't
>> see how this would be optional?
> 
> IIUC original issue was about adding "all request relevant information as 
> attributes of the request object". Since for sub request those will be 
> attributes of sub request, they will not interfere with parent request: sub 
> request's "objectModel" (or "flowContext", etc) will mask parent's completely 
> and thus won't allow modification of parent's "objectModel".
> 
Unfortunately this is not the way it has been implemented. Currently the
sub request uses an own request object but *shares* the attributes map
with the parent request. And this means it can override and delete values.
I'm not sure if we can change this (if people are relying on this
behaviour it would break their code).

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: environment abstraction in Cocoon 2.2

[Vadim Gritsenko <va...@reverycodes.com>]

Peter Hunsberger wrote:
> On 10/10/06, Vadim Gritsenko <va...@reverycodes.com> wrote:
>> Peter Hunsberger wrote:
>> > On 10/9/06, Carsten Ziegeler <cz...@apache.org> wrote:
>> >
>> >> > But just adding all this stuff to request attributes is not that
>> >> > easy as
>> >> > unfortunately sub request are sharing the attributes with the main
>> >> > request. So whenever you use the cocoon protocol the main request 
>> >> > and
>> >> > the sub request use the same set of attributes.
>>
>> Sub request by definition is the separate Request object with own set of
>> attributes (potentially with ability to access parent or global request
>> attributes - via special convention, may be?). Once sub request is 
>> completed,
>> all sub request attributes shall be discarded, leaving environment 
>> only with
>> parent attributes. Does it make sense?
> 
> It's the bit about "potentially with ability to access parent or
> global request" that seems to be the issue really isn't it?  I can't
> see how this would be optional?

IIUC original issue was about adding "all request relevant information as 
attributes of the request object". Since for sub request those will be 
attributes of sub request, they will not interfere with parent request: sub 
request's "objectModel" (or "flowContext", etc) will mask parent's completely 
and thus won't allow modification of parent's "objectModel".

This is similar to current wrapper behavior for parameters:

     public String getParameter(String name) {
         String value = this.parameters.getParameter(name);
         if (value == null && this.rawMode == false)
             return this.req.getParameter(name);
         else
             return value;
     }


Vadim

Re: environment abstraction in Cocoon 2.2

[Peter Hunsberger <pe...@gmail.com>]

On 10/10/06, Vadim Gritsenko <va...@reverycodes.com> wrote:
> Peter Hunsberger wrote:
> > On 10/9/06, Carsten Ziegeler <cz...@apache.org> wrote:
> >
> >> > But just adding all this stuff to request attributes is not that
> >> > easy as
> >> > unfortunately sub request are sharing the attributes with the main
> >> > request. So whenever you use the cocoon protocol the main request and
> >> > the sub request use the same set of attributes.
>
> Sub request by definition is the separate Request object with own set of
> attributes (potentially with ability to access parent or global request
> attributes - via special convention, may be?). Once sub request is completed,
> all sub request attributes shall be discarded, leaving environment only with
> parent attributes. Does it make sense?

It's the bit about "potentially with ability to access parent or
global request" that seems to be the issue really isn't it?  I can't
see how this would be optional?

-- 
Peter Hunsberger

Re: environment abstraction in Cocoon 2.2

[Vadim Gritsenko <va...@reverycodes.com>]

Peter Hunsberger wrote:
> On 10/9/06, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>> > But just adding all this stuff to request attributes is not that 
>> > easy as
>> > unfortunately sub request are sharing the attributes with the main
>> > request. So whenever you use the cocoon protocol the main request and
>> > the sub request use the same set of attributes.

Sub request by definition is the separate Request object with own set of 
attributes (potentially with ability to access parent or global request 
attributes - via special convention, may be?). Once sub request is completed, 
all sub request attributes shall be discarded, leaving environment only with 
parent attributes. Does it make sense?

Vadim

Re: environment abstraction in Cocoon 2.2

[Peter Hunsberger <pe...@gmail.com>]

On 10/9/06, Carsten Ziegeler <cz...@apache.org> wrote:

<snip/>

> > I think we have to change this as well and add all request relevant
> > information as attributes of the request object. This would then allow
> > to easily use other techniques/frameworks - like you could then just
> > forward your request from Cocoon flow to a JSP doing the rendering.
> > But just adding all this stuff to request attributes is not that easy as
> > unfortunately sub request are sharing the attributes with the main
> > request. So whenever you use the cocoon protocol the main request and
> > the sub request use the same set of attributes.
> >
> > I hoped to solve these problems for 2.2 but I never had a good idea -
> > but it's something we should definitly work on for the next releases.

No real solutions, just some ideas to get discussion going. I can see
two possible approaches, both of which have problems (and you've
probably already considered and discarded):

First, what about just some attribute container class that tracks the
attribute and parent/child attribute if present?  Something like:

class HierarchicalAttribute {
   Attribute attr;
   HierarchicalAttribute parentl;
}

Or swap parent with child depending on what semantics work best, but
the basic idea remains the same:  you've got a linked list of
attributes, as you work up or down the request and subrequests.
Alternately, just use a List that you can walk in whatever order you
want, maybe extended to have push/pop stack semantics.

The problem here is that this breaks the regular attribute access
semantics. You can't just get the attribute but rather you have to get
the attribute container and then get the real attribute from the
Hierarchy (or List, or whatever).  That means you've got to use some
Cocoon specific wrapper to access the real attribute if you want to
hide the implementation, but since access to the actual attribute is
Cocoon specific is that really a problem? I think yes...

The second approach seems even more of a hack, but removes the problem
for direct access.  Again you need a Cocoon specific wrapper, but this
time for adding the attributes instead of accessing them. In this
case, you first determine if the attribute is already present and if
so then you store it again with some new name and then store the
subrequest attributes as normal.  So, in this case if  you've got
something like "CocconAttr" it becomes "CocoonAttr-1"  when the second
instance is stored and if another subrequest comes along you get
"CocoonAttr-2", etc. The big problem with this approach is that you
need some way to automatically rename the attributes back to normal
when the subrequest ends and this seems problematic.

I'll go finish up my coffee now...

-- 
Peter Hunsberger

Re: environment abstraction in Cocoon 2.2

[Carsten Ziegeler <cz...@apache.org>]

[Resending to dev]

Carsten Ziegeler wrote:
> Joerg Heinicke schrieb:
>> Wondering about your problem I had a look into the code - and the 
>> environment abstraction indeed still exists. I thought it already has 
>> been removed. I send this mail to dev list too, maybe somebody can 
>> comment on this (Daniel, Carsten ?)
>>
> Yes, we still use the environment abstraction - mainly for
> compatibility. We had some discussion in the past to switch to the
> servlet req/response interfaces etc. While this is the right move, it
> creates big incompatibilities. So we either have to support two apis in
> parallel or wait until 3.0.
> 
> There are several problems with our abstraction; one of them is that we
> use our own apis (we can create wrappers for this to directly use the
> http servlet api) - but the other problem is that we are not using the
> request attributes to store additional request information.
> Unfortunately everything is stored in the objectModel map, e.g. the flow
> context etc. And even more: the request is an object stored in the
> objectModel.
> I think we have to change this as well and add all request relevant
> information as attributes of the request object. This would then allow
> to easily use other techniques/frameworks - like you could then just
> forward your request from Cocoon flow to a JSP doing the rendering.
> But just adding all this stuff to request attributes is not that easy as
> unfortunately sub request are sharing the attributes with the main
> request. So whenever you use the cocoon protocol the main request and
> the sub request use the same set of attributes.
> 
> I hoped to solve these problems for 2.2 but I never had a good idea -
> but it's something we should definitly work on for the next releases.
> 
> Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: environment abstraction in Cocoon 2.2

[Carsten Ziegeler <cz...@apache.org>]

Joerg Heinicke schrieb:
> Wondering about your problem I had a look into the code - and the 
> environment abstraction indeed still exists. I thought it already has 
> been removed. I send this mail to dev list too, maybe somebody can 
> comment on this (Daniel, Carsten ?)
> 
Yes, we still use the environment abstraction - mainly for
compatibility. We had some discussion in the past to switch to the
servlet req/response interfaces etc. While this is the right move, it
creates big incompatibilities. So we either have to support two apis in
parallel or wait until 3.0.

There are several problems with our abstraction; one of them is that we
use our own apis (we can create wrappers for this to directly use the
http servlet api) - but the other problem is that we are not using the
request attributes to store additional request information.
Unfortunately everything is stored in the objectModel map, e.g. the flow
context etc. And even more: the request is an object stored in the
objectModel.
I think we have to change this as well and add all request relevant
information as attributes of the request object. This would then allow
to easily use other techniques/frameworks - like you could then just
forward your request from Cocoon flow to a JSP doing the rendering.
But just adding all this stuff to request attributes is not that easy as
unfortunately sub request are sharing the attributes with the main
request. So whenever you use the cocoon protocol the main request and
the sub request use the same set of attributes.

I hoped to solve these problems for 2.2 but I never had a good idea -
but it's something we should definitly work on for the next releases.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org