Stephan Michels wrote:
Can you elaborate ? I was meaning that a source has no defined lifecycle. Even the release that is managed by the factory and not the source itself.On Mon, 6 Jan 2003, Sylvain Wallez wrote:Stephan Michels wrote:
I disagree : the SourceResolver is used to get a Source from its URL,/** Return the parent source. Returns null if the source hasn't a parent. */ public Source getParentSource() throws ProcessingException, IOException; }I don't return Sources, because Sources can be Components, which must be resolved/released by the SourceResolver. So I think returning the URI instead of the Sources is a must-have.
but a Source is not a component : the component is the SourceFactory
that creates Source instances. A source itself is not managed by a
ServiceManager.
But can managed by the SourceResolver.
Can you elaborate again ? You can only manage a pool of equivalent objects that can be reused. Sources don't fall in this category, as a Source is intimately tied to its URI and the range of URIs is infinite.Also, having to hop through the SourceResolver to get parents orBut if the creation of the Sources is expensive, is is easier to create
children of a Source *really hits performance*, as each call to
resolve() looks up/releases the factory, asks it to create the source,
etc, etc.
a SourceResolver, which holds a pool of the sources.
Furthermore, managing a pool would not be very different performance-wise than going through the standard resolution mechanism.
Looking at all traversable sources I know of (Slide source and myThat can be, but a resolve/release has much cleaner lifecycle. For
yet-unpublished CVSSource and TraversableFileSource), getting the
children or parents Source objects is really trivial and lightweight
compared to the processing required if we go through the SourceResolver.
Furthermore, I'm really wondering now if we need to release() a Source,
as I can't find any implementation that actually does something of it.
And I don't think an implementation will ever use it : the point where
something has to be released in Sources is related to stream methods
(look at BlobSource.getInputStream()). Also, these methods can be called
several times during the lifetime of the Source object, and their result
can last longer than the Source object's lifetime (look at
XSLTProcessorImpl.resolve()).
And releasing a Source involves once more a look up/release of the
SourceFactory to actually do nothing...
So, considering that the SourceResolver is one of the most used
components, removing release() from this interface may lead to a
significant performance increase.
example, if the Source lookup for a component using the componentmanager,
which got the Source by the Composable contract, the component must
release the component, if the Source were disposed.
Sorry, I don't understand what you mean above :-/ Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
