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