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: https://issues.apache.org/jira/browse/COCOON-2044
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
http://tools.ietf.org/html/rfc3986.
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.
/Daniel
