You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Rice Yeh <ri...@gmail.com> on 2007/06/17 15:06:57 UTC
Interblock communication
Hi,
With current servlet-service implementation, inter-block communication
become a hard problem. I have used servlet-serivce in my project. I use
block inheritance and association. However, because each request passed to
the associated block is a newly created (instead of the original one gotten
from client), many informations of request are lost in the called
servlet-service, like parameters, locale, ..etc. Servlet-service is quite
powerful on its function. But there are many functions still not complete
yet. Cocoon 2.2 is now in RC, will Interblock communication problems be
solved before 2.2 final release?
Rice
Re: Interblock communication
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Daniel Fagerstrom schrieb:
> A third possibility would be to make your "data" available as REST-style
> web services. Then the "view blocks" can access the data through servlet
> service protocol calls.
This is a great idea we want to implement in Mindquarry for quite some time
(but other things need more attention...). Our sitemaps have grown quite
large and it's hard to keep the bird's eye view. So our idea is to split up
our sitemaps (we already have different sitemaps for each functional block
of our application) each into a data sitemap and a presentation sitemap.
The data sitemap contains all the basic XML, Forms, flowscript processing,
data fetching/storing etc. It provides a REST interface with XML content.
Then you put the presentation sitemap on top of it - it effectively contains
various pipelines that transform the XML data into HTML or PDF for example.
The connection is done by the servlet protocol - so it's easily possible to
let other HTTP/REST based-clients access the data sitemap directly - this
gives you a very good API at no cost, because you have already designed it
for you presentation layer and can simply reuse it by publishing it. It's
also a classical separation of concerns.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Interblock communication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Ralph Goers wrote:
>> Daniel Fagerstrom wrote:
>>> Letting all blocks share the same global session would lead to code
>>> that would be hard to debug and reuse, so that would not be such a
>>> good idea. We could think about having a local session for each
>>> servlet service, but that is not implemented yet.
>>>
>>> What you currently do is that you have a "main" servlet service that
>>> contain session handling etc and that calls other servlet services
>>> that does there work without sessions. For me that is enough, but if
>>> other people have use cases that require more, we can find some way
>>> to extend it.
>>>
>>> /Daniel
>> Thanks for this info. This does raise concern although perhaps it is
>> misplaced. I am working on a project that heavily uses portlets. The
>> current portlet spec makes it difficult to share session attributes
>> across the web application. The downside is that it leads to all
>> kinds of kludges and performance problems. For example, you would
>> like to call a single business service and have its data available to
>> multiple portlets as each might simply provide different views of the
>> data. I could easily see the same sort of requirement with blocks.
>>
>> In general, the isolation is probably the correct approach, but only
>> if there is a way to explicitly declare that certain objects should
>> be shared.
>
> I'm not sure if it is directly helpful for your problem, but Spring
> 2.x offers request, session and global-session scoped beans
> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>
>
That is one possibility. And as the Spring container is global another
possibility is to let your multiple "view blocks" access the Spring bean
directly.
A third possibility would be to make your "data" available as REST-style
web services. Then the "view blocks" can access the data through servlet
service protocol calls.
Then we could of course create some mechanism such that each servlet
service has a local session that in some way extends and overrides the
global one. Maybe using some special syntax for global session attribute
names.
/Daniel
Re: Interblock communication
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
> On 20.06.2007 11:40, Carsten Ziegeler wrote:
>
>> Not sure if it helps and don't know how it works, but you can share a
>> parent spring context between web apps. For sure, this might create
>> deployment problems in some environments where you can deploy wars
>> only. But perhaps it makes sense to further investigate there?
>
> Do you have that ContextSingletonBeanFactoryLocator [1] in mind? It does
> not look that complicated. I had nearly tried it out myself some days
> ago, but found another solution to work around a particular problem I had.
>
I haven't looked into the article at all - I just saw this headline some
days ago and thought that it might be relevant for this thread :)
http://blog.interface21.com/main/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
Carsten
Re: Interblock communication
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.06.2007 11:40, Carsten Ziegeler wrote:
> Not sure if it helps and don't know how it works, but you can share a
> parent spring context between web apps. For sure, this might create
> deployment problems in some environments where you can deploy wars only.
> But perhaps it makes sense to further investigate there?
Do you have that ContextSingletonBeanFactoryLocator [1] in mind? It does
not look that complicated. I had nearly tried it out myself some days
ago, but found another solution to work around a particular problem I had.
Joerg
[1] http://www.codechimp.net/?p=22
Re: Interblock communication
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom schrieb:
> Ralph Goers skrev:
>> Unfortunately, that will only let you share the session amongst
>> portlets in the same war. portlets in different wars, as well as
>> servlet filters running ahead of the portal won't have access to it.
> For the blocks and servlet services we don't have this problem, all the
> blocks are in the same war, shares the same global Spring container and
> classloader. I would rather say that the problem in general for our
> framework might rather be to little isolation. Neither the less we must
> of course make the framework convenient to work with. I had some
> suggestions about what to do when you need to share data between servlet
> services in my previous post.
Not sure if it helps and don't know how it works, but you can share a
parent spring context between web apps. For sure, this might create
deployment problems in some environments where you can deploy wars only.
But perhaps it makes sense to further investigate there?
Carsten
Re: Interblock communication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ralph Goers skrev:
>
>
> Reinhard Poetz wrote:
>> Ralph Goers wrote:
>>>
>>>
>>> Reinhard Poetz wrote:
>>>> I'm not sure if it is directly helpful for your problem, but Spring
>>>> 2.x offers request, session and global-session scoped beans
>>>> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>>>>
>>> Thanks, but that doesn't help. A portal typically consists of the
>>> portal webapp and several portlet wars. The session variables have
>>> to be shared across theses various webapps. However, the portlet
>>> spec mandates that they each have their own session. Most portal
>>> vendors provide proprietary ways around this. Also, in this
>>> environment each portlet war will have its own Spring container. The
>>> beans can't be shared without getting ClassLoader errors.
>>>
>>> These are the types of issues you want to avoid creating.
>>
>> hmmm, just wondering what the globalSession scope of Spring is good
>> for then? According to the Spring documentation it solves exactly
>> this problem.
> Unfortunately, that will only let you share the session amongst
> portlets in the same war. portlets in different wars, as well as
> servlet filters running ahead of the portal won't have access to it.
For the blocks and servlet services we don't have this problem, all the
blocks are in the same war, shares the same global Spring container and
classloader. I would rather say that the problem in general for our
framework might rather be to little isolation. Neither the less we must
of course make the framework convenient to work with. I had some
suggestions about what to do when you need to share data between servlet
services in my previous post.
/Daniel
Re: Interblock communication
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Ralph Goers wrote:
>>
>>
>> Reinhard Poetz wrote:
>>> I'm not sure if it is directly helpful for your problem, but Spring
>>> 2.x offers request, session and global-session scoped beans
>>> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>>>
>> Thanks, but that doesn't help. A portal typically consists of the
>> portal webapp and several portlet wars. The session variables have to
>> be shared across theses various webapps. However, the portlet spec
>> mandates that they each have their own session. Most portal vendors
>> provide proprietary ways around this. Also, in this environment each
>> portlet war will have its own Spring container. The beans can't be
>> shared without getting ClassLoader errors.
>>
>> These are the types of issues you want to avoid creating.
>
> hmmm, just wondering what the globalSession scope of Spring is good
> for then? According to the Spring documentation it solves exactly this
> problem.
Unfortunately, that will only let you share the session amongst portlets
in the same war. portlets in different wars, as well as servlet filters
running ahead of the portal won't have access to it.
Ralph
Re: Interblock communication
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.06.2007 09:45, Reinhard Poetz wrote:
> hmmm, just wondering what the globalSession scope of Spring is good for
> then? According to the Spring documentation it solves exactly this problem.
It solves the session problem within one web application (war). We use
the global session for state management in our portal, but only have one
webapp besides the portal webapp. Using Tomcat's emptySessionPath
property it's also possible to let servlets in the same webapp access
the same session as the portlets. But there is still one independent
session per webapp.
Joerg
Re: Interblock communication
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
>
>
> Reinhard Poetz wrote:
>> I'm not sure if it is directly helpful for your problem, but Spring
>> 2.x offers request, session and global-session scoped beans
>> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>>
> Thanks, but that doesn't help. A portal typically consists of the portal
> webapp and several portlet wars. The session variables have to be shared
> across theses various webapps. However, the portlet spec mandates that
> they each have their own session. Most portal vendors provide
> proprietary ways around this. Also, in this environment each portlet
> war will have its own Spring container. The beans can't be shared
> without getting ClassLoader errors.
>
> These are the types of issues you want to avoid creating.
hmmm, just wondering what the globalSession scope of Spring is good for then?
According to the Spring documentation it solves exactly this problem.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Interblock communication
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.06.2007 08:43, Ralph Goers wrote:
> A portal typically consists of the portal
> webapp and several portlet wars. The session variables have to be shared
> across theses various webapps. However, the portlet spec mandates that
> they each have their own session.
It's worse. The *servlet* spec prohibits that.
Joerg
Re: Interblock communication
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> I'm not sure if it is directly helpful for your problem, but Spring
> 2.x offers request, session and global-session scoped beans
> (http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
>
Thanks, but that doesn't help. A portal typically consists of the portal
webapp and several portlet wars. The session variables have to be shared
across theses various webapps. However, the portlet spec mandates that
they each have their own session. Most portal vendors provide
proprietary ways around this. Also, in this environment each portlet
war will have its own Spring container. The beans can't be shared
without getting ClassLoader errors.
These are the types of issues you want to avoid creating.
Ralph
Re: Interblock communication
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Daniel Fagerstrom wrote:
>> Letting all blocks share the same global session would lead to code
>> that would be hard to debug and reuse, so that would not be such a
>> good idea. We could think about having a local session for each
>> servlet service, but that is not implemented yet.
>>
>> What you currently do is that you have a "main" servlet service that
>> contain session handling etc and that calls other servlet services
>> that does there work without sessions. For me that is enough, but if
>> other people have use cases that require more, we can find some way to
>> extend it.
>>
>> /Daniel
> Thanks for this info. This does raise concern although perhaps it is
> misplaced. I am working on a project that heavily uses portlets. The
> current portlet spec makes it difficult to share session attributes
> across the web application. The downside is that it leads to all kinds
> of kludges and performance problems. For example, you would like to call
> a single business service and have its data available to multiple
> portlets as each might simply provide different views of the data. I
> could easily see the same sort of requirement with blocks.
>
> In general, the isolation is probably the correct approach, but only if
> there is a way to explicitly declare that certain objects should be shared.
I'm not sure if it is directly helpful for your problem, but Spring 2.x offers
request, session and global-session scoped beans
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-other).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Interblock communication
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
> Letting all blocks share the same global session would lead to code
> that would be hard to debug and reuse, so that would not be such a
> good idea. We could think about having a local session for each
> servlet service, but that is not implemented yet.
>
> What you currently do is that you have a "main" servlet service that
> contain session handling etc and that calls other servlet services
> that does there work without sessions. For me that is enough, but if
> other people have use cases that require more, we can find some way to
> extend it.
>
> /Daniel
Thanks for this info. This does raise concern although perhaps it is
misplaced. I am working on a project that heavily uses portlets. The
current portlet spec makes it difficult to share session attributes
across the web application. The downside is that it leads to all kinds
of kludges and performance problems. For example, you would like to call
a single business service and have its data available to multiple
portlets as each might simply provide different views of the data. I
could easily see the same sort of requirement with blocks.
In general, the isolation is probably the correct approach, but only if
there is a way to explicitly declare that certain objects should be shared.
Ralph
Re: Interblock communication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ralph Goers skrev:
...
> Can someone please describe how this is all supposed to work? (Hopefully
> with as few words as possible)
It is intended to be a plugin based service oriented architecture.
In a little bit more detail: Each block (plugin) can provide servlet
services, that other servlet services can use.
In Stefano's original vision he wanted the blocks to be rather isolated.
We tried to achieve that by using OSGi, but it was a little bit early
back then and to much work, so it seemed better to have less isolation
and get something that people can use faster. So in the current
architecture all blocks share classloader and Spring container.
For the servlet services I thought it was better to start simplistic
with a high degree of isolation and add communication based on peoples
use cases.
> Also, it seems silly to me to ask why a web app would need a session -
> or maybe I misread your answer? Frankly, I don't think it would be
> possible for the portal block to function without a session. Heck, don't
> continuations require one too?
Letting all blocks share the same global session would lead to code that
would be hard to debug and reuse, so that would not be such a good idea.
We could think about having a local session for each servlet service,
but that is not implemented yet.
What you currently do is that you have a "main" servlet service that
contain session handling etc and that calls other servlet services that
does there work without sessions. For me that is enough, but if other
people have use cases that require more, we can find some way to extend it.
/Daniel
Re: Interblock communication
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Rice Yeh skrev:
> The following is my understanding about the current and would-be
> functions of servlet-serivce:
>
> Servlet-serivce is to have a web application divided into many blocks
> but each of them behaves like a web application; It has its own context,
> request, response and session. When a block s1 calls another block s2,
> it is like that s1 is calling another web application; it creates
> another request, have another response, even have another session in s2.
> Attribute values (here attribute refers to the general meaning, it
> includes the parameters, headers and attributes in request and the
> attributes in session and context) in s2 can override values in s1. For
> example the value of an attribute a1 is vs1 in s1, when s1 call s2, s2
> might have attribute a1 with value vs2 because a1 is overridden (here, I
> am not sure whether it is correct to use the word 'override'). However,
> for another block s3 called by s1 which does not override a1, the value
> of a1 is still vs1. Repeat again, attributes here refers to general
> meaning. Such overriding mechanism is not implemented yet.
Great summary of how things works and what needs to be done next! As
Grek wrote, we have recently found a way to make the request object of
the caller available in the request object of the callee, so now it is
possible to start to implement what you describe above.
> Then in servlet-service, it is allowed to have a block extend another
> block. Lets say s3 extends s0. When s1 calls s3 with request r1 for a
> function f1 which is implemented in s0. Is it still needed to create
> another request for s3 to call s0 for f1? For present implementation,
> there is no difference in calling a super and no-super block. However,
> in object-oriented thinking, just directly passing r1 is more
> reasonable. Since servlet-service is not like a OO language to have a
> complier, to judge whether f1 exists in s3 or s0 might not be an easy
> way. Bug cocoon-2038 approaches this issue.
We haven't discussed this before, but I think you are completely right,
we need to differ between ordinary servlet service calls and super
calls. And super calls should probably be considered as an internal
redirection where the request object of the caller is kept (including
its session and request attributes). The URI probably needs to be
overidden, but not much more.
> Anyone, please comments. I like to know whether my understanding is correct?
Your understanding is right on the spot, as far as I can tell.
/Daniel
Re: Interblock communication
Posted by Rice Yeh <ri...@gmail.com>.
The following is my understanding about the current and would-be functions
of servlet-serivce:
Servlet-serivce is to have a web application divided into many blocks but
each of them behaves like a web application; It has its own context,
request, response and session. When a block s1 calls another block s2, it is
like that s1 is calling another web application; it creates another request,
have another response, even have another session in s2. Attribute values
(here attribute refers to the general meaning, it includes the parameters,
headers and attributes in request and the attributes in session and context)
in s2 can override values in s1. For example the value of an attribute a1 is
vs1 in s1, when s1 call s2, s2 might have attribute a1 with value vs2
because a1 is overridden (here, I am not sure whether it is correct to use
the word 'override'). However, for another block s3 called by s1 which does
not override a1, the value of a1 is still vs1. Repeat again, attributes here
refers to general meaning. Such overriding mechanism is not implemented yet.
Then in servlet-service, it is allowed to have a block extend another block.
Lets say s3 extends s0. When s1 calls s3 with request r1 for a function f1
which is implemented in s0. Is it still needed to create another request for
s3 to call s0 for f1? For present implementation, there is no difference in
calling a super and no-super block. However, in object-oriented thinking,
just directly passing r1 is more reasonable. Since servlet-service is not
like a OO language to have a complier, to judge whether f1 exists in s3 or
s0 might not be an easy way. Bug cocoon-2038 approaches this issue.
Anyone, please comments. I like to know whether my understanding is correct?
Rice
On 6/19/07, Grzegorz Kossakowski <gk...@apache.org> wrote:
>
> Hi Ralph,
>
> Ralph Goers pisze:
> > I guess now I know why so few people are working on 2.2
> > a) it is pretty crazy to answer a question like the one asked by
> > pointing them to a thread with dozens of posts on several parallel
> threads.
>
> Yes, that thread is *big* but I guess it's only place where some aspects
> where discussed.
>
> > b) I actually tried reading most of the posts and to be honest I
> > understood very little of it. Trying to "grasp the basic idea" by
> > reading it just left me more conused. I suspect I am not alone.
>
> If you have not been following recent development of servlet-service-fw
> it's very likely that you are confused. My time is limited these
> days so
> could you direct me at things/concepts that confuse you the most? I would
> not like to explain what you already know.
>
> > Can someone please describe how this is all supposed to work? (Hopefully
> > with as few words as possible)
>
> I hope to do it this evening.
>
> > Also, it seems silly to me to ask why a web app would need a session -
> > or maybe I misread your answer? Frankly, I don't think it would be
> > possible for the portal block to function without a session. Heck, don't
>
> > continuations require one too?
>
> Yes, there are cases where passing session is required but as far as I
> understand servlet-service-fw design principles we should strive to
> build stateless services. I'm not sure how far we can reach with such a
> principle but I can imagine that even you need/want a session for
> some reason you can always extract needed data from the that session and
> pass the called servlet everything it needs as parameters or XML if
> you call servlet service. Isn't it at a peace with so fashionable REST
> architecture? It's just a wild thinking...
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
>
Re: Interblock communication
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Hi Ralph,
Ralph Goers pisze:
> I guess now I know why so few people are working on 2.2
> a) it is pretty crazy to answer a question like the one asked by
> pointing them to a thread with dozens of posts on several parallel threads.
Yes, that thread is *big* but I guess it's only place where some aspects where discussed.
> b) I actually tried reading most of the posts and to be honest I
> understood very little of it. Trying to "grasp the basic idea" by
> reading it just left me more conused. I suspect I am not alone.
If you have not been following recent development of servlet-service-fw it's very likely that you are confused. My time is limited these
days so
could you direct me at things/concepts that confuse you the most? I would not like to explain what you already know.
> Can someone please describe how this is all supposed to work? (Hopefully
> with as few words as possible)
I hope to do it this evening.
> Also, it seems silly to me to ask why a web app would need a session -
> or maybe I misread your answer? Frankly, I don't think it would be
> possible for the portal block to function without a session. Heck, don't
> continuations require one too?
Yes, there are cases where passing session is required but as far as I understand servlet-service-fw design principles we should strive to
build stateless services. I'm not sure how far we can reach with such a principle but I can imagine that even you need/want a session for
some reason you can always extract needed data from the that session and pass the called servlet everything it needs as parameters or XML if
you call servlet service. Isn't it at a peace with so fashionable REST architecture? It's just a wild thinking...
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Interblock communication
Posted by Ralph Goers <Ra...@dslextreme.com>.
I guess now I know why so few people are working on 2.2
a) it is pretty crazy to answer a question like the one asked by
pointing them to a thread with dozens of posts on several parallel threads.
b) I actually tried reading most of the posts and to be honest I
understood very little of it. Trying to "grasp the basic idea" by
reading it just left me more conused. I suspect I am not alone.
Can someone please describe how this is all supposed to work? (Hopefully
with as few words as possible)
Also, it seems silly to me to ask why a web app would need a session -
or maybe I misread your answer? Frankly, I don't think it would be
possible for the portal block to function without a session. Heck, don't
continuations require one too?
Ralph
Grzegorz Kossakowski wrote:
> Rice Yeh pisze:
>> I hope I can do this if I can really understand the present design of
>> servlet-service.
>
> Yeah, documentation is lacking... That's on the top of my priority
> list, I'll take care after passing all exams at University. The exams'
> session ends at 26th of June.
>
>> First off, I do not understand why a newly created request is needed.
>> Why not just pass the original one?
>
> Because every servlet call must be new request, containing new (local)
> URL that you can match in the matcher. I think we wanted to start from
> scratch (not passing anything) to keep everything simple and
> separated. It's obvious that we have to forward some of original
> request's attributes. Here I use general meaning of "attribute" word,
> so request's attribute is a parameter, header, etc. The tricky part is
> to demarcate boundaries because we relly strive to keep servlet as
> separated as possible.
>
>> When looking for the current BlockCallHttpServletRequest
>> implementation, it even creates a new HttpSession when method
>> getSession() is called. What is the basic idea in designing
>> servlet-serivce in this way?
>
> Why do you need a session in called servlet? Is it really
> indispensable? I guess you should grasp basic idea by reading above
> explanation.
>
> If you want really detailed view take a look at this thread:
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/73088
>
> I know, it's terribly long discussion but there is a lot of knowledge
> and you can always skip some branches.
>
> If you have more questions don't hestitate to ask.
>
Re: Interblock communication
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Rice Yeh pisze:
> I hope I can do this if I can really understand the present design of
> servlet-service.
Yeah, documentation is lacking... That's on the top of my priority list, I'll take care after passing all exams at
University. The exams' session ends at 26th of June.
> First off, I do not understand why a newly created
> request is needed. Why not just pass the original one?
Because every servlet call must be new request, containing new (local) URL that you can match in the matcher. I think we
wanted to start from scratch (not passing anything) to keep everything simple and separated. It's obvious that we have
to forward some of original request's attributes. Here I use general meaning of "attribute" word, so request's attribute
is a parameter, header, etc. The tricky part is to demarcate boundaries because we relly strive to keep servlet as
separated as possible.
> When looking for
> the current BlockCallHttpServletRequest implementation, it even creates
> a new HttpSession when method getSession() is called. What is the basic
> idea in designing servlet-serivce in this way?
Why do you need a session in called servlet? Is it really indispensable? I guess you should grasp basic idea by reading
above explanation.
If you want really detailed view take a look at this thread:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/73088
I know, it's terribly long discussion but there is a lot of knowledge and you can always skip some branches.
If you have more questions don't hestitate to ask.
--
Grzegorz Kossakowski
Re: Interblock communication
Posted by Rice Yeh <ri...@gmail.com>.
I hope I can do this if I can really understand the present design of
servlet-service. First off, I do not understand why a newly created request
is needed. Why not just pass the original one? When looking for the current
BlockCallHttpServletRequest implementation, it even creates a new
HttpSession when method getSession() is called. What is the basic idea in
designing servlet-serivce in this way?
Rice
On 6/18/07, Grzegorz Kossakowski <gk...@apache.org> wrote:
>
> Rice Yeh pisze:
> > Hi,
> > With current servlet-service implementation, inter-block communication
> > become a hard problem. I have used servlet-serivce in my project. I use
> > block inheritance and association. However, because each request passed
> > to the associated block is a newly created (instead of the original one
> > gotten from client), many informations of request are lost in the called
> > servlet-service, like parameters, locale, ..etc. Servlet-service is
> > quite powerful on its function. But there are many functions still not
> > complete yet. Cocoon 2.2 is now in RC, will Interblock communication
> > problems be solved before 2.2 final release?
>
> The issue you describe is related to
> https://issues.apache.org/jira/browse/COCOON-2066. Fix for COCOON-2066
> makes old request object
> available for newly created request object for servlet call so it's just
> matter of implementing all necessary methods that will return
> values obtained from original request object.
>
> I think that it's quite trivial task now and I would be glad to see your
> patches submitted to JIRA :-)
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
>
Re: Interblock communication
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Rice Yeh pisze:
> Hi,
> With current servlet-service implementation, inter-block communication
> become a hard problem. I have used servlet-serivce in my project. I use
> block inheritance and association. However, because each request passed
> to the associated block is a newly created (instead of the original one
> gotten from client), many informations of request are lost in the called
> servlet-service, like parameters, locale, ..etc. Servlet-service is
> quite powerful on its function. But there are many functions still not
> complete yet. Cocoon 2.2 is now in RC, will Interblock communication
> problems be solved before 2.2 final release?
The issue you describe is related to https://issues.apache.org/jira/browse/COCOON-2066. Fix for COCOON-2066 makes old request object
available for newly created request object for servlet call so it's just matter of implementing all necessary methods that will return
values obtained from original request object.
I think that it's quite trivial task now and I would be glad to see your patches submitted to JIRA :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/