Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
...
But there are important use cases for run time discovery of servlet
services as well.
definitly. For the use cases that *I* have, a generator will be good
enough - I don't think that I need a source for them:
<map:generate type="servlets" src="data/myconfig.xml"/>
This could return something like this:
<servlets>
<service-A>
<config>...</config>
</service->
<service-B>
<config>...</config>
</service-B>
</servlets>
What are the usecases for implementing a servlets: protocol at all?
(Maybe I'm overlooking something important here ...)
In the above output from your generator, you need to reference the
actual resources of the listed servlet services. And to be able to do
that you need an URI.
The URI is data/myconfig.xml, resolved against all available servlet services.
And right now we have not any protocol that is suitable for that.
AFAIU we only have to create ServletConnection objects. Currently the
constructor expects the connection name as parameter but it shouldn't be
difficult to create those objects by implementing a second constructor that uses
the bean id or a bean reference.
For the use case we are discussing, the assumption is that the caller of
the servlets generator is not connected to all the servlet services.
Thus we cannot use the servlet: protocol that by design assumes an
explicit named connection.
So we need a protocol that allows (webapp) global servlet service URIs
anyway. And then we could as well make it listable as a source is usable
in more contexts than a generator.
ok. What I still don't understand is, why we want to make the bean id being part
of this URI at all? Or do I misinterpret your discussion with Grek here?
Isn't having an URI
servlets:/data/myconfig.xml
good enough to configure a listable source? The getChildren() method of the
created source will return all child sources that return true on
childSource().exists().
I don't see the need to lookup not configured servlet services by their name.
The only use case I can think of is optional servlet services. To solve it, I'd
rather introduce an "optional" parameter for servlet service configurations.
However, I'm not convinced that we need this feature at all if we can resolve
servlets:/data/myconfig.xml URIs which would return servlet service sources that
are unknow in the context of the current servlet service.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
