Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates
 216.86.168.179 as permitted sender)
Message-ID: <47E9061C.5030105@tuffmail.com>
Date: Tue, 25 Mar 2008 15:03:08 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20070801)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JNet integration
References: <47E509B2.7050003@tuffmail.com> <47E50A75.8090001@apache.org>
 <47E51B61.2050701@tuffmail.com> <47E7F20D.3020308@tuffmail.com>
 <47E8A7CE.6040508@apache.org>
In-Reply-To: <47E8A7CE.6040508@apache.org>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit

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 do
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 suggests
something else...)
  * getLastModified() - no counterpart

Dropping usage of JDK API only to resolve relative URI into absolute form feels strange. You will
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 to
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...

-- 
Grzegorz