Doing our own cleaning up.

[Paul Russell <pa...@luminas.co.uk>]

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                               <pa...@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.

Re: Doing our own cleaning up.

[Giacomo Pati <Gi...@pwr.ch>]

Paul Russell wrote:
> 
> 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?

Fore the sitemap components (which are different from general
components) I can handle that because the generated sitemap controlls
the access and can release them in a clean way. For that I'm writing a
concrete SitemapComponentManager (SCM) that can

1. be hierachical organized like the sitemaps itself. So each sitemap
   has it own SCM and that may have a parent SCM. We need this to be
able to
   a) reduce verbosity in the subsitemaps by inheriting
Sitemapcomponents
      from parent sitemaps.
   b) to make the system more scalable in means of having many cascading 
      levels of subsitemaps.

2. respect the interfaces (ie. Poolable, Sharable, Recyclable, none of 
   these) that SitemapComponents can implement to show their behaviours
   because of the SAX model most of the SitemapComonent can't be written 
   as thread safe classes.

> 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();
> }

If you read at
http://developer.java.sun.com/developer/onlineTraining/protocolhandlers/
you don't define the in cocoon itself except you can't start your JVM
with the needed properties. Then you need to use the method you metioned
above URL(URL,String,URLStreamHandler) and this AFAIU forces you to sign
your code and grant some access into your java.policy file. I personally
prefer the first variant to say "If you want to use a ie. CVS protocol
handler for your C2 sitemap you have to define the right properties at
JVM startup"

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen                    Mailto:Giacomo.Pati@pwr.ch
                                          Web:   http://www.pwr.ch