cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Pipeline components and Object Model issues
Date Fri, 17 Aug 2007 06:45:43 GMT
Joerg Heinicke pisze:
> On 14.08.2007 12:26 Uhr, Grzegorz Kossakowski wrote:
> 
>> The problem is that Object Model is a signleton object (more 
>> precisely, with "call" scope defined in cocoon-servlet-service-impl)
> 
> So the problem is not with internal pipelines at all since they are 
> scoped anyway? Or does this apply only for servlet service? Do other 
> internal protocol still exist at all?

Yes, it's not problem with internal pipelines (internal requests made by servlet:) because
they are 
scoped. No,  it's general problem and if servlet service is not used this problem emerges
in 
internal requests, also (because scope is not used).

What internal proctol do you have in mind? A cocoon: I guess, so it still exists and it's
main 
reason for keeping complicated environment handling and complicated code of sitemap's treeprocessor.

Since servlet: protocol replaces (or is going to replace) all functionality of cocoon: we
need to 
start thinking about deprecating it in a future.

>> To elaborate on it further, the situation is similar to the situation 
>> when thread-unsafe component is used in two threads at the same time.
> 
> This comparison does not really apply. You don't get corrupted state but 
> some last-wins situation in case of conflicts. If two components in a 
> pipeline have the same parameter the last one added wins. So the result 
> is actually predictable - but unwanted of course.

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.

This fully establish analogy between thread-unsafe components and OM, IMO.

> I wonder if that "scope" makes much sense. It's a 1:1-relationship to 
> the component anyway. What we need is only a wrapper that delegates 
> read-only access to parent object model in case the child could not 
> serve the requested value. Maybe we just talk about the same ...

Yes, we talk about the same but I want OM to be casual Spring bean but scoped properly. This
way we 
get necessary wrapper but in transparent way so component's can take advantage of Dependency

Injection when it comes to OM.

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.

> Actually this whole problem reminds me of session attributes in portlet 
> environment. A portlet's session attributes work exactly like written 
> above - but all are stored within the global HTTP session though by 
> prefixing the session attribute names with a portlet-unique string. And 
> I wonder how fast we will observe another requirement: "I know that I 
> might break something but I WANT make this attribute globally 
> available." This concept is known in portlet session attributes. You can 
> enforce writing an attribute straight to the global session. See the 
> corresponding methods on PortletSession [1] (actually they call it 
> "scope" as well).

 From my purist point of view I would say: just don't even think about it! ;)
However, I know that from time to time we have bend the rules and the solution already exists
with 
current design. OM can be extended by implementing ObjectModelProvider interface so some entries
are 
added to OM during it's creation. Now you can reference to such bean (that should have prototype

scope for example) in pipeline component and modify it directly bypassing all OM mechanisms.
This 
way you lost all protection but you are not limited by any scopes and so on.

But I'll repeat: don't do this and if you insist on doing it don't be surprised if something
does 
not work.

> How is the object model injected into such a sitemap component? Still 
> via setup()?

As I said earlier, OM is just a Spring bean so it's going to be injected using Spring's mechanisms.

-- 
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. ***

Mime
View raw message