commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dion Gillard <>
Subject Re: Jelly and a new beta release
Date Tue, 07 Sep 2004 17:10:31 GMT
On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <> wrote:
> [x] -1 - No, don't release! Here's why....
> I've been developing with Jelly b3 (in isolation) for
> a while and have encountered and fixed various
> problems. These problems occur in the core
> implementation, core tags, Swing Tags, etc. I admit
> that I have not checked to see if these have been
> resolved in the CVS version.

That's a problem. If you're interested in getting things fixed in
Jelly, file these as bug reports. We'll help work through them.

> Throughout
>   Add to all occurences of code like:
>       ClassLoader classLoader = this.getClass
> ().getClassLoader () ;
>     the following
>       if (classLoader == null)
>         {
>         classLoader = ClassLoader.getSystemClassLoader
> () ;
>         }
>     as some JVMs (e.g. IBM's J9) return null if
> SystemClassLoader was used, in that case add explicit
> call to get SystemClassLoader

Sounds reasonable. File an issue for this one.

> org.apache.commons.jelly.tags.core.ArgTag
>     Register ArgTag's converters with
> ConvertUtilsBean's singleton.
>     Use converters registered with ConvertUtilsBean's
> singleton.

Functionally what does this provide?

> org.apache.commons.jelly.tags.core.IncludeTag
>     Fixed setExport

Done in CVS I think.

> org.apache.commons.jelly.JellyContext
>     runScript(), inherit flag seemed to clobber
> existing variables

File an issue, with a test case if you can.

> org.apache.commons.jelly.tags.core.UseBeanTag
>     doTag(), remover 'var' attribute so it doesnt get
> passed to setBeanProperties

Done in CVS.

>     Added a new 'ref' attribute which is
> systematically set to the bean instance before tag
> body is invoked.

Why? What does this give us?

> org.apache.commons.jelly.tags.swing.DialogTag
> org.apache.commons.jelly.tags.swing.ComponentTag
>     Refactored so that they share a new common parent
> class AbstractComponentTag.
>     Support layout constraints on contentPanes.

Layout constraints are fixed in CVS. Raise an issue for the other.

> org.apache.commons.jelly.tags.swing.ActionTag
>     doTag(), call invokeBody immdediately if 'class'
> or 'action' attribute is specified.

This may be fixed in CVS.

> org.apache.commons.jelly.tags.swing.FontTag
>     Made it actually work.
>     Now supports java.awt.font.TextAttribute.

I can't tell from this description whether it's fixed in CVS or not.

> org.apache.commons.jelly.tags.swing.GbcTag
>     Made it Java 1.3 compatible.

Done in CVS.

> org.apache.commons.jelly.tags.swt.*
>     Better parent widget management.
>     Including:
>     org.apache.commons.jelly.tags.swt.WidgetTag
>         WidgetTag used to be a class, I have made it
> an interface, DefaultWidgetTag is a copy of the
> original WidgetTag.
>         DefaultWidgetTag has better parent widget
> management.

Pretty sure this isn't done in CVS. File an issue please.

>     org.apache.commons.jelly.tags.swt.OnEventTag


> New Tags written:
>     Improved bean creation and property getter and
> setter tags that mirror 'core' tags.
>     W3C DOM Document Tag
>     TreeSelectionListenerTag
>     TreeUIManagerTag
>     more BorderTags
>     ActionListenerTag, unlike, JellySwing ActionTag,
> it adds itself to the immediate parent ComponentTag or
> ArgTagParent if 'var' is not specified.
>     JXPath tags (jXPathContext, jXPathIterator)
>     FormAttachmentTag (swt/jface)

I dont want to add more functionality to the beta. New taglibs etc can
wait till a release of the core.

> Requests:
> My number one request, jettison BeanUtils. It is slow
> but more importantly, does not indicate that a method
> has not been found via introspection (at least as used
> by Jelly).

Got a patch? File an issue for this one.

> Make Jelly Java 1.3 compatible.
All except the Jetty taglib are 1.3 compatible. The core definitely is.

> Add instance and static member access to JEXL.
Huh? Do you mean for fields? JEXL aint Jelly. JEXL has had a 1.0
release, and new functionality can be added to 1.1. I don't see this
as major for a Jelly beta release though. File an issue against JEXL
for this one anyway.

> org.apache.commons.jelly.JellyContext
>     Should discern between variables with a value of
> null and variables that don't exits.

Done in CVS.

> org.apache.commons.jelly.tags.core.UseBeanTag
>     Better management of bean storage. i.e. It is up
> to the subclass (in processbean, after invokeBody) to
> decide whether to store the bean or insert in in the
> tah hierarchy.

Sounds like a reasonable enhancement. File an issue.

> More controversial, have bean based tags look for a
> parent BeanSource with a bean of the approriate type
> rather that a parent Tag of a specified Type.
>     This is what I have done in a set of parallel
> 'core' tags I have developed.
Hmm...that's changing the scope of the 1.0 stream of Jelly I think.

> Again, I am not sure where Jelly b4 stands with
> respect to the above, but should it be of interest, I
> am willing to explain some of the above in more
> detail.

Hopefully I've given you an idea of where it stands.

I don't see anything mentioned above as a *blocker* for releasing the
beta though.

It would *really* help if you would work with us on Jelly and help
make it better. You have some good ideas (and implementations by the

I also think we would benefit from getting a stable Jelly 1.0 out the
door without functional rewrites and architectural changes. These
things can be done once the code has been released and we have a
better base to work from.

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

View raw message