headers
Grzegorz Kossakowski | 1 Dec 13:37
Picon
Favicon

Re: Servlet service request

Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>> 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.

It may sound controversial but I think that things like information about user locale or preferences
(Continue reading)

Permalink | Reply | 31 comments |
headers
Ralph Goers | 1 Dec 19:08
Favicon

Re: Servlet service request


Grzegorz Kossakowski wrote:
>
>
> It may sound controversial but I think that things like information about user locale or preferences
> should be kept in URL (preferably in path part or in request parameters). If data set is too big,
> URL should contain an unique identifier of this data set. I mean, instead of using following URL:
> /blog/posts/1
> and passing following information: Locale=pl-PL, Username=gkossakowski, Skin=red
> it's better to have following URL:
> /blog/languages/pl-PL/skins/red/posts/1
>   
You would never be able to build a large, scalable application doing 
this. It also would violate security requirements if I had to put a 
users account number in the url. The session exists for a reason.
>
> Getting back to the topic, I tried above to proof that having a session is not essential part of web
> application creation process.
>   
It is.
>   
>
> Whenever I think about Servlet Services Framework design first spec I have in mind is HTTP (+
> publications about REST that made me think about HTTP in more appropriate way). Always and ever. The
> fact that we follow servlet specification as much as we can instead of reinventing the wheel is good
> of course. Nevertheless, I keep HTTP and REST over servlet spec.
>
> I think it's worth to remind KISS rule as it fits very well in this case. If we let a session to be
> shared at this point there will be probably no way back. Apart from SSF being a really nice idea, I
> like to work on it becuase, in contrary to cocoon protocol, it allows much less thus code is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Grzegorz Kossakowski | 1 Dec 20:43
Picon
Favicon

Re: Servlet service request

Ralph Goers pisze:
> You would never be able to build a large, scalable application doing
> this. 

Why?

> It also would violate security requirements if I had to put a
> users account number in the url. The session exists for a reason.

Do you mean number of users' bank account? If so, you would never need to IMO. If it's just user id,
I wonder how it violates security.

Maybe I'm missing something but I'm really seeking for this reason of session existence.

>> Getting back to the topic, I tried above to proof that having a
>> session is not essential part of web
>> application creation process.
>>   
> It is.

I have given my arguments, could you give yours, please?

> I think the answer is simple. The session needs to be shared with all
> servlets in a webapp just as the servlet spec provides. Anything less is
> going to confuse the heck out of users, lead to nothing but trouble in
> the long run and give the impression that Cocoon just tries to make
> everything hard on purpose.

Seems like you trying to say "If you want to persuade others to like your ideas preach them but not
build the walls". If it's the case, I can understand but I'm still lacking the idea why it's needed.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralph Goers | 1 Dec 22:38
Favicon

Re: Servlet service request


Grzegorz Kossakowski wrote:
> Ralph Goers pisze:
>   
>> You would never be able to build a large, scalable application doing
>> this. 
>>     
>
> Why?
>   
Because there are lots of pieces of information you need for a user to 
build an application. For example, what groups, roles and permissions 
they are associated with. With the portal you have the whole set of 
pages the user can view. There is just a bunch of stuff that needs to be 
anchored in the session. If you try to recreate it on every request your 
application would never scale.
>   
>> It also would violate security requirements if I had to put a
>> users account number in the url. The session exists for a reason.
>>     
>
> Do you mean number of users' bank account? If so, you would never need to IMO. If it's just user id,
> I wonder how it violates security.
>
> Maybe I'm missing something but I'm really seeking for this reason of session existence.
>   
In our internet banking application every user needs the list of 
accounts that they are associated with for virtually every transaction. 
This data comes from the user's bank - which may not have a very fast 
connection to our data center, or it comes from the database. In either
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Ziegeler | 1 Dec 23:47
Picon
Favicon

Re: Servlet service request

Grzegorz Kossakowski wrote:
> 
> It may sound controversial but I think that things like information about user locale or preferences
> should be kept in URL (preferably in path part or in request parameters). If data set is too big,
> URL should contain an unique identifier of this data set. I mean, instead of using following URL:
> /blog/posts/1
> and passing following information: Locale=pl-PL, Username=gkossakowski, Skin=red
> it's better to have following URL:
> /blog/languages/pl-PL/skins/red/posts/1
> 
> Or, if username is needed for other reasons (like we need to access other preferences):
> /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1
> 
Yes, following the REST principle is a good way to build web
applications (and their URLs) - but that's not always possible/desired.
There is information you definitly don't want to put into the URL for
security reasons (Ralph outlined some of them) - and a URL has a maximum
length - and sooner or later you'll hit this limitation if you want to
put everything into the URL.

> 
> Ok, you may think it's academic speaking (yes, I'm a student spending most of my time at very high
> levels of abstraction) but I really believe it may work and scale very, very well. It goes in
> harmony with REST principles, and... there is no session needed. All user preferences all in
> persisted all the time.
> 
Yes, it's possible to build applications following these principles -
but it's also impossible to build all applications going this road.

> Getting back to the topic, I tried above to proof that having a session is not essential part of web
(Continue reading)

Permalink | Reply | 27 comments |
headers
Alfred Nathaniel (JIRA | 2 Dec 01:06
Picon
Favicon

[jira] Closed: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount


     [
https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alfred Nathaniel closed COCOON-1990.
------------------------------------

                     Resolution: Fixed
                  Fix Version/s: 2.1.11-dev (Current SVN)
    Affects version (Component): Parent values: Components: Sitemap(10152). 
        Fix version (Component): Parent values: Components: Sitemap(10229). 

Fixed in 2.1.11-dev.
Never was an issue for 2.2.

> Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
> ------------------------------------------------------------------
>
>                 Key: COCOON-1990
>                 URL: https://issues.apache.org/jira/browse/COCOON-1990
>             Project: Cocoon
>          Issue Type: Bug
>          Components: * Cocoon Core
>    Affects Versions: 2.1.10
>            Reporter: Robert Hoffmann
>            Assignee: Alfred Nathaniel
>             Fix For: 2.1.11-dev (Current SVN)
>
>
> Hi cocoon developers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Goers | 2 Dec 04:11
Favicon

Re: Servlet service request

Carsten Ziegeler wrote:
> Grzegorz Kossakowski wrote:
>   
>> It may sound controversial but I think that things like information about user locale or preferences
>> should be kept in URL (preferably in path part or in request parameters). If data set is too big,
>> URL should contain an unique identifier of this data set. I mean, instead of using following URL:
>> /blog/posts/1
>> and passing following information: Locale=pl-PL, Username=gkossakowski, Skin=red
>> it's better to have following URL:
>> /blog/languages/pl-PL/skins/red/posts/1
>>
>> Or, if username is needed for other reasons (like we need to access other preferences):
>> /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1
>>
>>     
> Yes, following the REST principle is a good way to build web
> applications (and their URLs) - but that's not always possible/desired.
> There is information you definitly don't want to put into the URL for
> security reasons (Ralph outlined some of them) - and a URL has a maximum
> length - and sooner or later you'll hit this limitation if you want to
> put everything into the URL.
>   
I suppose REST is fine for some trivial applications on the web tier, 
but many modern web frameworks (i.e. JSF, Spring Webflow, Wicket) 
require that state be maintained on the server simply because they have 
a requirement that pages be accessed in specific orders. I believe even 
flowscript and Javaflow require this to preserve the continuations.  
REST between the web tier and the business tier is a different matter. 
The business tier should always be stateless and REST (as a concept) 
works very, very well for that. However, when you start talking REST vs
(Continue reading)

Permalink | Reply | 26 comments |
headers
Reinhard Poetz | 2 Dec 16:05
Picon
Favicon

Re: Servlet service request

Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Grzegorz Kossakowski wrote:
>>  
>>> It may sound controversial but I think that things like information 
>>> about user locale or preferences
>>> should be kept in URL (preferably in path part or in request 
>>> parameters). If data set is too big,
>>> URL should contain an unique identifier of this data set. I mean, 
>>> instead of using following URL:
>>> /blog/posts/1
>>> and passing following information: Locale=pl-PL, 
>>> Username=gkossakowski, Skin=red
>>> it's better to have following URL:
>>> /blog/languages/pl-PL/skins/red/posts/1
>>>
>>> Or, if username is needed for other reasons (like we need to access 
>>> other preferences):
>>> /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1
>>>
>>>     
>> Yes, following the REST principle is a good way to build web
>> applications (and their URLs) - but that's not always possible/desired.
>> There is information you definitly don't want to put into the URL for
>> security reasons (Ralph outlined some of them) - and a URL has a maximum
>> length - and sooner or later you'll hit this limitation if you want to
>> put everything into the URL.
>>   
> I suppose REST is fine for some trivial applications on the web tier,
(Continue reading)

Permalink | Reply | 18 comments |
headers
Carsten Ziegeler | 2 Dec 16:09
Picon
Favicon

Re: Servlet service request

Ralph Goers wrote:
> I suspected that you might make that switch, although I'm not really
> sure what the benefits are. Will it allow coplets to be individual
> blocks with the portal being a separate block? If so, that would be
> great.  In that case it might be possible to make JSR 286 portlets be
> blocks as well (in addition to the requirement that they be separate war
> files).
I don't know if there are any benefits for the portal to switch from
cocoon to servlet - but as we are talking about deprecating the cocoon
portal, it might make sense...

Yes, the portal should be an own block and coplets could be contained in
separate blocks as well. I'm also planning to make the portal run in an
OSGi environment *and* to run JSR 286 portlets locally - perhaps through
blocks perhaps "directly". But these things are on the bottom of my
portal list. Currently I'm trying to finish all the refactorings and get
the samples working again.

Carsten

--

-- 
Carsten Ziegeler
cziegeler <at> apache.org
Permalink | Reply | 6 comments |
headers
Grzegorz Kossakowski | 2 Dec 19:03
Picon
Favicon

Re: Servlet service request

Reinhard Poetz pisze:
> Ralph Goers wrote:
>> Carsten Ziegeler wrote:
>> I suppose REST is fine for some trivial applications on the web tier, 
> 
> I disagree with this statement. REST is an architectural style and I'm
> sure, following those principles will help you to build applications
> from trivial to very complex.
> 
> I also think that the mentioned "without sessions your apps don't scale"
> argument is bogus. If that was true, HTTP (which is the most prominent
> implementation of REST) wouldn't scale.
> 
>> but many modern web frameworks (i.e. JSF, Spring Webflow, Wicket)
>> require that state be maintained on the server simply because they
>> have a requirement that pages be accessed in specific orders. 
> 
> Using sessions for that purpose is just one way to implement it.
> 
> If you implement a RESTful web tier, your clients (e.g. web browsers)
> have to become more powerful. In times of mature Ajax frameworks, Flex
> etc. this isn't as much of a problem like a few years ago.
> 
> It took me a bit longer than Stefano, but in the meantime I also think
> that web framworks as we know today have already passed their zenith.
> Next generation web frameworks will make it simple to implement your
> webapps following REST and I think that Cocoon with its XML pipelines
> can shine again.
> 
>> I believe even flowscript and Javaflow require this to preserve the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane