Re: Servlet service request
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Carsten Ziegeler wrote:
Reinhard Poetz wrote: What happens if a sub request accesses the session?
Is an artifical one created?
The current implementation returns an unusable implementation of a session
which needs to fixed in some way.
After have been using the servlet-service framework for about 1/2 a year, I
have to say that I haven't been missing the access to sessions because a
child-request shouldn't affect a parent request. Whatever it has to return
to its parent, should be part of the response IMO instead of being passed
around indirectly.
I have exactly the same feelings as Reinhard on this. If you want to pass
something to child request use request parameters for simple values or POST
request (using postable source) for passing more complicated structures. The
same goes for passing data from sub-request to parent one.
Basic goal behind such design is to really, really avoid any possibility of
side-effects.
If we follow your arguments, we would also have to forbid passing request
attributes to sub requests. IMO this is too strict because this would cause a
lot of overhead, e.g. what about our flow implementations that allow passing
data objects (bizdata map) to the called pipeline (though it isn't possible to
call a servlet:/ URL directly ATM because always the cocoon:/ protocol is used,
but this restriction was introduced long before the servlet:/ protocol was
invented).?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Servlet service request
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: After have been using the servlet-service framework for about 1/2 a year, I have to say that I haven't been missing the access to sessions because a child-request shouldn't affect a parent request. Whatever it has to return to its parent, should be part of the response IMO instead of being passed around indirectly. I have exactly the same feelings as Reinhard on this. If you want to pass something to child request use request parameters for simple values or POST request (using postable source) for passing more complicated structures. The same goes for passing data from sub-request to parent one. Basic goal behind such design is to really, really avoid any possibility of side-effects Using sessions for passing information should be considered evil (I'm still being decontaminated and exorcised...). But what about data which is really relevant e.g. login data. Should it really passed every time? What if someone logs out? If te session is invalidated you're finished. With request still having login data you can't be sure you have left session completely. Florian
Re: Servlet service request
Reinhard Poetz pisze: Carsten Ziegeler wrote: Reinhard Poetz wrote: What happens if a sub request accesses the session? Is an artifical one created? The current implementation returns an unusable implementation of a session which needs to fixed in some way. After have been using the servlet-service framework for about 1/2 a year, I have to say that I haven't been missing the access to sessions because a child-request shouldn't affect a parent request. Whatever it has to return to its parent, should be part of the response IMO instead of being passed around indirectly. I have exactly the same feelings as Reinhard on this. If you want to pass something to child request use request parameters for simple values or POST request (using postable source) for passing more complicated structures. The same goes for passing data from sub-request to parent one. Basic goal behind such design is to really, really avoid any possibility of side-effects. Nevertheless, I'm also eager to hear others' opinions. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Commented: (COCOON-2032) [PATCH] Sort order in paginated repeater
[ https://issues.apache.org/jira/browse/COCOON-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547311 ] Antonio Gallardo commented on COCOON-2032: -- Would you provide a sample for the cocoon demo? [PATCH] Sort order in paginated repeater Key: COCOON-2032 URL: https://issues.apache.org/jira/browse/COCOON-2032 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Attachments: sort_repeater.patch Little improvement to the sort-by paginated repeater command. With this patch the command will togle between sorting ascending, descending and unsorted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Servlet service request
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: If we follow your arguments, we would also have to forbid passing request attributes to sub requests. IMO this is too strict because this would cause a lot of overhead, e.g. what about our flow implementations that allow passing data objects (bizdata map) to the called pipeline (though it isn't possible to call a servlet:/ URL directly ATM because always the cocoon:/ protocol is used, but this restriction was introduced long before the servlet:/ protocol was invented).? Hmmm, I have not considered flowscript when I was formulating my opinion on this subject and it was an obvious mistake. Your argument is of course valid and it seems that the best compromise between functionality, performance and separation is to provide access to the data from parent request but in read-only mode. It means we should allow sub-request to access request attributes of calling request. When it comes to session (even in read-only mode) I'm very circumspect. I believe that the best strategy is to allow as less as possible that still enable us to make full use of servlet service capabilities. WDYT? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Servlet service request
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: If we follow your arguments, we would also have to forbid passing request attributes to sub requests. IMO this is too strict because this would cause a lot of overhead, e.g. what about our flow implementations that allow passing data objects (bizdata map) to the called pipeline (though it isn't possible to call a servlet:/ URL directly ATM because always the cocoon:/ protocol is used, but this restriction was introduced long before the servlet:/ protocol was invented).? Hmmm, I have not considered flowscript when I was formulating my opinion on this subject and it was an obvious mistake. Your argument is of course valid and it seems that the best compromise between functionality, performance and separation is to provide access to the data from parent request but in read-only mode. It means we should allow sub-request to access request attributes of calling request. When it comes to session (even in read-only mode) I'm very circumspect. I believe that the best strategy is to allow as less as possible that still enable us to make full use of servlet service capabilities. WDYT? I'm not sure - creating an artificial and somehow unusable session for sub requests is imho no solution. It somehow doesn't neither make sense nor does it feel right. In the portal world, the session is shared between portlets and servlets residing in the same web application - there is no difference in terms of usability between a portlet or a servlet. The portlet spec does not want to impose restrictions, however it gives guidance to not mess up with the session and missuse it. For some applications, the session contains required information like the local or some preferences. You definitly don't want to pass them do sub requests by getting them from the session and putting them into the request. We are relying/basing on the servlet specification and it seems somehow wrong to me to explicitly disallow some things just because some of us think that this is evil - it doesn't matter if this is evil or not, it's the servlet spec in the end. And this spec states that the session is shared by all servlets etc. So I think we should give full access to the session but explicitly document the problems. If people want to mess up with it, well, that's their problem - if people know what they are doing and need (write) access to the session, they have it. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: svn commit: r599593 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/util/BlockCallHttpServletRequest.java
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Hi Reinhard, I would like to ask how your changes relate to https://issues.apache.org/jira/browse/COCOON-1831 ? I was searching for this patch but didn't find it because it is a sub-task in Jira. Looking now at it, I see that Rice' implementation goes further than what I did and my implementation is skipping request parameters passed as querystring which is definitly an error. I'm going to fix this ASAP. BTW, do you know why it is necessary to traverse the call stack? Why isn't it good enough to use the values from the calling request? Hmmm, I haven't spotted fragments traversing calling stack earlier. I'll investigate more tomorrow and I'll try to figure out if its really needed (my gut feeling is it's not needed). Also, are you planning to add test-cases for this functionality? It would be highly recommended to have them. Yes, actually I'm facing some subtle problems with servlet-services, e.g. when exceptions occur, that make the use of servlet-services sometimes really painful. What do you mean exactly? I will add some tests before the final release. Great, thanks! -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
