Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
There is not that much reason to mimic the URLConnection API as long
as one don't actually use it, so the API could of course be modified
if there is a gain in doing it.
Did you mean that ServletConnection should not be used outside
ServletSource or that we should not mimic API that is usuable in
context of servlet calling, anyway?
What I mean is that I would find it preferable to use a more widespread
interface than the Excalibur source for making the servlet source
functionality available for users that only want to use the servlet
services. The problem here is what API to use. The most natural
candidate would be the java.net.URLConnection. Another alternative would
be org.springframework.core.io.Resource to make it work better with the
Spring framework. Unfortunately both alternatives have their set of
problems:
The URLConnection is possible to extend with new protocols by using
java.net.URL.setStreamHandlerFactory but it can only be called once in a
given JVM. And it might happen that the embedding servlet container
already have used it. Also it would be problematic to use it in a
container with several Cocoon webapps. It is still possible to use it as
OSGI shows. And at least Felix have some mechanism that make it possible
to have several parallel OSGi containers that use the URL service in the
same JVM. But while a low level framework like OSGi can be allowed to
such things I find it much to intrusive for a high level framework as
Cocoon. So for use of Cocoon in an OSGi container we could use the cutom
URLs but hardly otherwise. Also trying to create an URLConnection for a
non registered URL like the servlet: ones result in an Exception. So
when I refactored the blocks fw to non OSGi use, I had to remove the
URLConnection inheritance.
For the Resource interface from the Spring framework the situation also
is a little bit complicated. First, the Resource is not as full featured
as the Excalibur Source set of APIs. Second and worse there is no
configuration plugability of new protocols. I haven't studied the latest
minor versions of the Spring framework but at least for 2.0 the only way
to register new protocols is to extend an appropriate Spring context
class and override the getResourcePatterresolver. This is also rather
intrusive but it would make Spring Cocoon integration so much more
convenient so that it might be worthwhile to explore this path anyway.
So to conclude I would like to use the servlet protocol without the need
for using the Excalibur source set of APIs, but I have no good idea
about how to do it. I would still prefer to have the implementation of
the servlet protocol with the servlet-service-impl module and also that
this module has as few dependencies as possible. But what API the
servlet protocol has is not that important, so feel free to modify it if
there is any advantages doing that.
/Daniel
