cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: JNet integration
Date Tue, 25 Mar 2008 07:20:46 GMT
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>>> AFAIU, you call
>>> Installer.setURLStreamHandlerFactory(new
>>> SourceURLStreamHandlerFactory());
>>> at the startup of your application.
>>> Then you can use the SourceFactoriesManager to install and uninstall 
>>> source factories.
>> Yes, but when and where should I call SourceFactoriesManager to install
>> SourceFactories? That's the main problem here.
> Ok, somehow "solved" and committed. The stuff I committed should be
> considered as experimental (even though it works...) so don't be surprised
> seeing lots of hacks.
> After playing with JNet idea for a while I'm more and more doubtful about the
> direction we have taken. I really like Source, SourceFactory interfaces, they
> are clean, focused and obvious to use contrary to the URL machinery from Java
> API. Look at what I committed, there is no way to release underlying Source
> object if InputStream was not been obtained.

Are there any other use cases for releasing a source than the SitemapSource 
(cocoon:/ protocol)?

> Moreover, if you need some advanced functionality (e.g. traversable source)
> you still need switch back to Excalibur interfaces. Same goes for modifiable,
> postable etc.

What's the problem with that? If you are happy with that what the URL object can 
do for you, you don't need to depend on any external stuff. If you want more, 
you have to add some more dependencies to your code.

This sounds to me very familiar: If I want to use "advanced" logging, I have to 
add e.g. log4j. If I'm happy with that what the JDK offers, I don't have to do 

What's so special in the case of Excalibur source?

> I'm going to invest my energy into implementation of my original idea of
> providing default SourceResolver for SSF internal needs so we can release SSF
> 1.1.0 ASAP. I'll wait with JNet integration until someone (Carsten?) else
> chimes in and explains how everything should be glued.

I don't understand this. From a quick glance at your code I see that there we 
are able to set the servlet context in the SSF without depending on Excalibur 
sourceresolve or Excalibur source.

Why and what exactly do you want to change?

> Abstract description explaining what are _real_ benefits of integrating JNet
> into SSF and Cocoon (Corona?) in general would be good. 

With JNet being set up correctly, Corona doesn't depend on any third-party 
library. E.g. if you want to create a simple pipeline, you don't have to provide 
a SourceResolver - using URLs us enough.

> I really need to get
> some roadmap if I'm going to continue.

I think that the main goal is making SSF implementation useable for the usage 
without Cocoon core (2.2) and IMHO without having to setup a SourceResolver. A 
test case for this is when you can do

URL u = new URL("servlet:otherService:/a/b/c");

from within Corona and you get the expected inputstream afterwards.

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message