cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Broken caching of servlet: source in some cases
Date Wed, 25 Apr 2007 09:47:04 GMT
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 Another alternative would 
be to make it work better with the 
Spring framework. Unfortunately both alternatives have their set of 

The URLConnection is possible to extend with new protocols by using 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.


View raw message