commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Gilde <>
Subject RE: [jelly] should caching be configurable ?
Date Wed, 29 Sep 2004 02:42:23 GMT
Well... I can't say that I've thought out the semantics of reloading and
such, the way you're describing. The current implementation of UseBeanTag
and ComponentTag (extends UseBeanTag) never reuse a bean. They always create
a new bean every time they're run.

The original impetus for clearing the bean after a run was the fact that the
bean would never, ever be reused anyway.

If we want to implement functionality the way you describe, we should make
it optional. I personally find the create-new-bean-every-time to be the
perfect pattern for my own use.

It would be quite easy to extend ComponentTag to do what you're saying.

It would work like this:

Override newInstance() to look in a context variable. If there's a bean,
reuse it, else create it and put it in the variable.

To re-invoke the tag using your "reload" tag, just navigate to the level
that's one above your target level, then call invokeBody.

-----Original Message-----
From: Paul Libbrecht [] 
Sent: Tuesday, September 28, 2004 2:39 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] should caching be configurable ?

Le 28 sept. 04, à 02:02, Hans Gilde a écrit :

> Here's the memory "leak" that was fixed by nulling out the component. 
> It's not so much of a leak as a "holding on to references that should 
> be available to the GC":
> I might want to build several instances of a JFrame from the same 
> Jelly script. But, I may not. I may simply keep that Script around but 
> never end up using it again.
> Let's say that my frame uses lots of memory. I build a frame using my 
> script. Now that script has a reference to my frame. I dispose of the 
> frame, but I don't end up creating another one.
> I expected that my frame would be available for GC, but it wasn't 
> because it's still referenced by the script that I'm keeping around 
> just in case.

I'd rather find the converse natural:
- the script should be rebuilt if need be
- but if the script (or some snippets) is re-run, I'd like it to re-run 
with its original beans...

My little reload-tag does the following and I think it's quite 
appropriate. Basically, it considers each component-tag as a browser 

  <!-- some content -->
  <swing:button><swing:action name="Do">
	<swing:reload level="2"/>

When the Do button is pressed, my reload tag empties the content of the 
panel and re-runs the body-script which re-populates the panel 
depending on an XML-document which got updated by this GUI.
(I am using Xwing, a typical example is to have a forEach inside the 
panel that iterates on children, the reload is wished when you add 
something and where the forEach should be re-run).

I know there are ways out differently (instead of the reload, actually 
execute a tag or function which does the population) it's just, much 
more elegant, I feel!


PS: there's a taste of browser-DOM-connection out there... maybe it's 
good, or not...

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message