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]
