cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: DispatcherServlet
Date Fri, 18 May 2007 18:40:58 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
>> What about omitting "/" part while asking for list of servlet bean ids?
>> It seems even more logical to me because the syntax will be:
>> servlet:[<bean id or connection name>:]/<rest of the path>
>> [] - means that it's optional part
> Doesn't seem that logical to me. For all other schemes directory URIs 
> ends with a "/". It will confuse people to have another convention in 
> this particular case. Furthermore it would not comply with 

You are right, it was a weak attempt.

> Thinking further on it. The URIs of current servlet protocol are only 
> valid within the scope of a specific servlet service, outside it it 
> lacks meaning. The URIs of the proposed servlets: protocol has a unique 
> meaning in the scope of the whole webapp. URIs with webapp scope is 
> needed both for the "global list" use case as well as for the "global 
> id" use case that you and Alexander have discussed.
> I think we make the servlet: protocol unnecessarily complicated if we 
> try to overload it with webapp global interpretations as well.

But we need to do that way. If Source returns globally unique URI it means that is must handle
it. That's why we must implement block id 
handling in the servlet: source.

> And as I asked before, how does the URI parser given e.g. 
> "servlet:foo/bar" know is "foo" is a servlet service local id or a 
> Spring bean id?

It should try both options or we could could introduce some syntax that makes it easy to distinguish
these two cases.

> Of course I'm very happy with all your coding. But if you would like to 
> write RTs, don't let your ideas about your English abilities limit you. 
> The fastest way to improve your ability to write good RTs, is to 
> actually write RTs ;) As long as the ideas interest people, they will 
> try to understand and give you feedback.

I will remember what you said but for now finishing already started things should have highest

> Servlets already are available for anyone coding Java, as they are 
> ordinary Spring beans. So we have not any protection of them anyway.
> For most blocks it is much preferable to use the current servlet service 
> wiring style as it clearly declares dependencies, and make it possible 
> for a user to compose and replace servlet services as they want.
> But there are important use cases for run time discovery of servlet 
> services as well. The current use case with a samples main page is one 
> example. I mean you want it to work both for a normal build and an 
> -Dallblocks build.

I see, thanks for clarification.

Grzegorz Kossakowski

View raw message