cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Re: [C2] [Pooling] Proxies and target JDKs
Date Mon, 11 Dec 2000 00:28:47 GMT
Paul Russell <> wrote:
>Need to pick your brains. We've been talking off and on about
>component pooling etc, and how to achieve it in Cocoon2. At the
>moment, the components are retrieved from their pools, but they
>are never returned, negating the usefulness of the pools (except
>in the sitemap itself, where components are explicitly returned
>by their ComponentHolders).
>I have tried to implement this using SoftReferences to recover
>the components when they aren't in use, and this doesn't appear
>to work -- I'm not entirely sure why.

In a number of VMs, e.g. both Hotspots included with Linux JDK1.3, 
SoftReferences are cleared overzealously. This can be fixed by passing the 
-classic command line option to the VM. The bug report for this at is marked "closed, fixed in a non-public release".

>Another option is to use
>the Proxy architecture to dynamically build a component proxy
>which automatically returns a component to the pool when it is
>garbage collected.

I'm not sure how that would work. Could you please elaborate.

>The trouble with this is that the proxy
>architecture is only available in JDK1.3. I could write a new
>implementation of the proxy architecture specifically for cocoon,
>but this seems overkill if there's an easier way of achieving

As you probably realise... it is possible, though non-trivial, to introspect 
a class and then create arbitrary classes/interfaces at runtime and then 
load them in - without using javac. has an open source - 
Apache-compatible-license - set of classes for writing class files (it's 
listed on ). This could make it possible to reimplement the 
Proxy class in JDK1.2. In fact that might be quite a fun little project - 
after all, it's only glue code. :-)

[In fact even XSP with javac might be acceptable in terms of speed if the 
proxy classes didn't need to be generated that often.]

I'm sure licensing would be no problem. Either just include the jars (no 
problem at all), or just add the Cocoon license to the top of the source 
files - two licenses then, but they're compatible (and essentially the 
same), so no problem.

>What do we think the target VM for Cocoon2 should be? JDK1.3 is
>fairly prevelent these days, but I suspect (I've not checked
>yet) it's not available for *BSD or Macintosh.

It will be / is included in OS X, but as for *BSD, ha ha, you've gotta be 

Get more from the Web.  FREE MSN Explorer download :

View raw message