cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Broken caching of servlet: source in some cases
Date Wed, 25 Apr 2007 19:54:47 GMT
Daniel Fagerstrom pisze:
> 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 
> problems:
> 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.

Thanks Daniel for detailed explanation and historical background. :-)

> 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.

Even though, I agree with you on this, I think we should not invent our own API if there is
no strong need for one. The less APIs to learn
the more happiness is in the world ;-)

Grzegorz Kossakowski

View raw message