cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Doing our own cleaning up.
Date Tue, 19 Sep 2000 18:08:55 GMT
Hi All,

We've been talking recently about including the Avalon component
pooling in Cocoon2 both in cocoon itself and within the (dynamicly
generated) sitemap classes. My first thought was that we could use
phantom references to persuade the GC to grab components that
people had finished with and bring tham back into the pool.
Sadly I was totally wrong (hey, it happens to the best of us.
and me. ;). It seems that there's no way of getting the reference
architecture to enqueue objects that aren't reachable through
hard references without first marking them as finalizable (which
renders them useless to us). If anyone knows otherwise, speak
up now.

If I've not missed anything, and this is indeed the case, we have
a little problem. At present, components are not returned to a
pool, they're obtained from a component manager and then allowed
to become unreferenceable and finalized. If we're going to pool
components, we can't do this, sadly - we need to tidy up after
ourselves and put out toys back in their boxes afterwards.

At the moment, we use the Avalon Component, Composer and
ComponentManager interfaces to build up the hieracy of components
which forms the bulk of Cocoon. What I can't visualise is how
this extends to pooling. I'm half tempted to suggest suggest to
the Avalon team that ComponentManagers should have a 'recycle'
method to allow Composers to recycle components they've finished
with. This however isn't really an option, as it's an interface
modification, which is, generally speaking A Really Bad Idea.
Therefore, do we need an equivalent of Composer and ComponentManager
for Poolable components? Thoughts/flames/comments?

Another thing which has come up in recent discussion is the
need for an easily extendable URLStreamHandler system which
allows us to define custom URLStreamHandlers reasonably easily
and without breaking anybody else. It seems sensible to use
URL(URL,String,URLStreamHandler), but this still leaves us
with the question of how to actually define the URLStreamHandlers
inside Cocoon. I don't know what you guys think, but I think
this could make a good addition to Avalon's util package.

/** Provides an interface for handling custom URL
 * semantics within the Avalon framework.
 * <p><em>Needs a new name!</em></p>
 */
public interface URLStreamHandler {
	/** Returns a realization of the URLStreamHandler
	 * abstract class implementing this protocol.
	 */
	public URLStreamHandler getURLStreamHandler();

	/** Return the prefix associated with this URL
	* schema (http, cvs or ftp for example).
	*/
	public String getPrefix();
}

Thoughts on the above two issues?

Cheers all!


Paul
-- 
Paul Russell                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.

Mime
View raw message