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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
