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 14:53:13 GMT
Grzegorz Kossakowski wrote:
> 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...

Once again, my goal is that if you use e.g. Corona in its simplest form, I don't 
want to make everybody and his dog depend on JNet/SourceResolve/Source. E.g. see 
the FileGenerator. Using the URL object is enough for simple use cases of a 
pipeline API.

Yes, I understand that when it comes to caching pipelines, you need more, but 
not everybody needs caching pipelines. For that purpose there could be a 
CacheableFileGenerator, etc.

If you are right and it is difficult or even impossible to remove the 
dependencies on source/sourceresolve/xmlutils/jnet, then be it. I withdraw my 
example Url("servlet:...") from above. When we can switch to sourceresolve 3.0, 
the dependency graph will get smaller anyway.

The main benefit from using URLs (instead of the SourceResolver) comes from 
simple use cases, e.g. you need a pipeline in your Java application that reads 
in some XML file, performs some transformations and finally creates a PDF 
document. FWIW, using URLs should be all that you need.

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

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

View raw message