commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: Jelly and a new beta release
Date Tue, 07 Sep 2004 20:16:59 GMT
Pfffiou... that's not a small buglist.

Dear S. Schrem,

I think releasing a beta would actually have prevented most of these 
bugs you encounter to have occurred as you would have taken the beta. I 
think we should consider your report as a +1!

Anyways... My [+1] btw.

Many of the bugs you seem to be reporting have been (maybe partially) 
tackled and it would be great to get working together...
Using a big of scripting wizardy (or maybe only a drop or rsync), it 
sounds easy to to update your source-tree, sadly most probably with 
conflicts, so that you could submit patches...

Btw, BeanUtils has had a refactoring started since jelly-beta-3 release 
(by Robert Burrell Donkin) and I know we could take advantage of it 
into Jelly...


Le 7 sept. 04, à 19:10, Dion Gillard a écrit :

> 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
> sounds).
> 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:

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

View raw message