cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: JNet integration
Date Tue, 25 Mar 2008 14:03:08 GMT
Reinhard Poetz pisze:
> Are there any other use cases for releasing a source than the
> SitemapSource (cocoon:/ protocol)?

Hmmm. CachingSource has non-trivial release() method as well. Anyway, I agree that most Sources
not need to be released at all.

> 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 anything.
> What's so special in the case of Excalibur source?

I agree with you reasoning but I have a feeling that JDK API does not have its counterparts
for the
most basic functionality found in Source/SourceFactory:

  * exists() - no counterpart
  * getInputStream() - openInputStream()
  * getURI() - toExternalForm() ???? (Javadocs suggest it's not a counterpart but practice
something else...)
  * getLastModified() - no counterpart

Dropping usage of JDK API only to resolve relative URI into absolute form feels strange. You
need to do that no matter where, in Corona (think caching pipelines), in SSF and anywhere
else you
do something non-trivial with Sources.

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

Current way of installing JNet through init() method of dummy Spring bean is a very, very
dirt hack.
Morever, since there is no way to resolve blockcontext: path into absolute ones I still need
obtain underlying Source instance. If it's the case, I don't see how all these hacks pay off.

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

Yep, until caching comes in. Or until you want to log path of file being processed in /absolute/
form. ;-)

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

I think little bit more should be expected. See above...


View raw message