cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: DispatcherServlet
Date Fri, 18 May 2007 13:27:27 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
>>> I wonder why we really need new source in this case at all. 
>>> Possibility to reference bean by bean id instead of connection name 
>>> was already discussed:
>>> Why do we need to invent new source?
>> The important part is that "servlets:/" is listable and give a listing 
>> of all servlet services. The above thing is because the listed servlet 
>> services must have own URIs to be usable. If that could be done by 
>> extending the ordinary servlet: protocol I'm fine with that as well. 
>> But extending the servlet: protocol has the problem that you use the 
>> same URI part for two distinct uses, both for servlet service relative 
>> names and for some kind of global naming scheme like bean id. There is 
>> some small risk that they are going to collide.
> 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

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.

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?

>>> Do you mean that servlet will be able to construct it's connection at 
>>> runtime or it will be able to reference resources from servlets that 
>>> it is not connected to?
>>> Does second option fits to our design of servlet-service-fw?
>> I'm not able to parse the above paragraphs at all. Could you please be 
>> a little bit more verbose, so that I can understand what all the uses 
>> of "servlet" and "it" refers to ;)
> Hehe ;-)
> My English sometimes really limits me and that's the reason why I don't 
> write [RT] e-mails even though I have some ideas. It's not that bad in 
> the end because I have to focus on the work instead of depicting a 
> glowing vision of the future ;-)

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.

> Returning back to the topic:
> Let's assume we have servlet A that get list of the other servlet beans' 
> ids and want to know if it has some samples. So servlet A must make list 
> of calls:
> servlet:B's-id:/some_file
> servlet:B'C-id:/some_file
> ...
> But none of these servlets are registered as connections of servlet A so 
> I would like to know if we are going to make it possible to request 
> resources from servlets that another servlet is not connected to?

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.

Also servlet service discovery could be really useful for tooling 
webapps, e.g. block configuration webapps.


View raw message