Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
...
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?
I guess that main reason is that we need unique URIs.
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().
What would "servlets:" source return if getInputStream() was called for
"servlets:/data/myconfig.xml" URI?
probably an exception, like the FileSource which is also a TraversableSource or
an aggregated view.
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.
I can't parse the above. What does mean "to lookup not configured
servlet services by their name"? How they can be not configured?
I mean a servlet service that is not configured as an entry of
servlet:connections of the servlet service bean definition.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
