You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Dion Gillard <di...@gmail.com> on 2004/08/31 06:46:24 UTC
Jelly and a new beta release
>From JIRA there is one issue remaining for beta 4 :
http://issues.apache.org/jira/browse/JELLY-47
which seems to be a dom4j related issue.
I'd like to do a new release of Jelly ASAP and start planning the next beta.
If anyone has bugs they'd like fixed for the beta or *urgent* new
functionality, please say so ASAP so we can finalize this release.
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Brett Porter <br...@apache.org>.
I'm a strong +1 on this.
Should we start working towards a release candidate next? What sort of new
features/major issues are there outstanding?
- Brett
Quoting Dion Gillard <di...@gmail.com>:
> >From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
> --
> http://www.multitask.com.au/people/dion/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
I'll wait a few more days for feedback from this email, and unless
there's a blocker in jira, the plan is to release beta-4 early next
week, and then start work on RC1, with the focus on bug fixes for core
only.
Once core goes into RC1, the plan is to do the same for all taglibs as
well, so that they can be released independently.
On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard <di...@gmail.com> wrote:
> From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
The CDATA test case fails on dom4j 1.5-rc1 because the CDATA test is
escaped and we explicitly ask for it not to be.
This is a bug, and I'm happy delaying the use of dom4j, or working
with them to fix the bug for 1.5.
On Tue, 31 Aug 2004 12:28:53 +0300, Paul Libbrecht <pa...@activemath.org> wrote:
> How important is it ?
> I think the current behaviour is just of "swallowing" CDATA sections
> which isn't an XML offense...
> How about delaying this for a further version where lexical data is
> kind of working ?
>
> paul
>
> Le 31 août 04, à 09:34, Dion Gillard a écrit :
>
> >> I remember I couldn't entirely switch to rc1 because of some entity
> >> stories...
> >
> > We need to check the CDATA test case if we switch to rc1 from the beta.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Paul Libbrecht <pa...@activemath.org>.
How important is it ?
I think the current behaviour is just of "swallowing" CDATA sections
which isn't an XML offense...
How about delaying this for a further version where lexical data is
kind of working ?
paul
Le 31 août 04, à 09:34, Dion Gillard a écrit :
>> I remember I couldn't entirely switch to rc1 because of some entity
>> stories...
>
> We need to check the CDATA test case if we switch to rc1 from the beta.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
On Tue, 31 Aug 2004 08:43:20 +0300, Paul Libbrecht <pa...@activemath.org> wrote:
> I would try to close it but I can't...
> This was dom4j related, there's a unit-test in there for it now.
> It is fixed since we're using dom4j 1.5.
> Sadly, however, taglibs and core don't use the same version and this
> could be an issue...
I fixed the taglibs and core being out of synch with dom4j. Do you
know where the unit test is?
> I remember I couldn't entirely switch to rc1 because of some entity
> stories...
We need to check the CDATA test case if we switch to rc1 from the beta.
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Paul Libbrecht <pa...@activemath.org>.
I would try to close it but I can't...
This was dom4j related, there's a unit-test in there for it now.
It is fixed since we're using dom4j 1.5.
Sadly, however, taglibs and core don't use the same version and this
could be an issue...
I remember I couldn't entirely switch to rc1 because of some entity
stories...
paul
Le 31 août 04, à 07:46, Dion Gillard a écrit :
> From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next
> beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Brett Porter <br...@apache.org>.
do you really need to ask? :)
+1
- Brett
Quoting Dion Gillard <di...@gmail.com>:
> Ok,
>
> all known issues for beta-4 have been completed.
>
> I'd like to do a beta release in the next day or so. Please vote on
> the beta release:
>
> [ ] +1 - Yes release
> [ ] +0 - Release, I have minor issues which can wait....
> [ ] -1 - No, don't release! Here's why....
>
>
> On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard <di...@gmail.com>
> wrote:
> > From JIRA there is one issue remaining for beta 4 :
> >
> > http://issues.apache.org/jira/browse/JELLY-47
> >
> > which seems to be a dom4j related issue.
> >
> > I'd like to do a new release of Jelly ASAP and start planning the next
> beta.
> >
> > If anyone has bugs they'd like fixed for the beta or *urgent* new
> > functionality, please say so ASAP so we can finalize this release.
> > --
> > http://www.multitask.com.au/people/dion/
> >
>
>
>
> --
> http://www.multitask.com.au/people/dion/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
Cool.
I'll file the classloader issue as a bug to be fixed for the beta
release, and once done, get it happening.
Thanks for participating!
On Thu, 9 Sep 2004 06:41:47 -0700 (PDT), S Schrem <ss...@yahoo.com> wrote:
> I don't check the list as often as I could.
> Second, although I'm an old-timer, I haven't yet
> participated in an open-source project nor am I used
> to submitting bug reports or feature requests.
>
> With respect to the beta release, I'm most interested
> in the ClassLoader issue, as I would otherwise have to
> patch a lot of the code in the beta.
>
> As for the other issues, they seem to be either fixed,
> require that I check the beta candidate, or
> explain/justify them more seriously/thoroughly and
> which shouldn't hold up the beta since I can't do it
> in a short period of time.
>
> Serge
>
> --- Dion Gillard <di...@gmail.com> wrote:
>
> > I'm figuring by the silence and lack of issues
> > raised in Jira that you
> > don't have the time / motivation to get back to us,
> > or I did a bad job
> > explaining where we're at with Jelly.
> >
> > I'll go ahead with the new beta release and we can
> > always pick these
> > issues up for the next beta or release.
> >
> >
> > On Wed, 8 Sep 2004 03:10:31 +1000, Dion Gillard
> > <di...@gmail.com> wrote:
> > > On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem
> > <ss...@yahoo.com> 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
> >
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Paul Libbrecht <pa...@activemath.org>.
Dion,
I'm pretty sure the release of a beta will, itself, bring new
interests. I've met quite many people, even in my little research
community, which have considered jelly as a serious candidate but have
stopped at some time or another because of the non-arriving release...
Jelly was a biest, at least from its maven aspect, and you have done
quite a good job, I think, into making the jelly project in better
shape for its build and overall exterior appearance. The amount of bugs
left has been well reduced and I think we all have a better
possibility, now, to go towards a release.
thanks for that!
paul
Le 9 sept. 04, à 15:08, Dion Gillard a écrit :
> I'm figuring by the silence and lack of issues raised in Jira that you
> don't have the time / motivation to get back to us, or I did a bad job
> explaining where we're at with Jelly.
>
> I'll go ahead with the new beta release and we can always pick these
> issues up for the next beta or release.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by S Schrem <ss...@yahoo.com>.
I don't check the list as often as I could.
Second, although I'm an old-timer, I haven't yet
participated in an open-source project nor am I used
to submitting bug reports or feature requests.
With respect to the beta release, I'm most interested
in the ClassLoader issue, as I would otherwise have to
patch a lot of the code in the beta.
As for the other issues, they seem to be either fixed,
require that I check the beta candidate, or
explain/justify them more seriously/thoroughly and
which shouldn't hold up the beta since I can't do it
in a short period of time.
Serge
--- Dion Gillard <di...@gmail.com> wrote:
> I'm figuring by the silence and lack of issues
> raised in Jira that you
> don't have the time / motivation to get back to us,
> or I did a bad job
> explaining where we're at with Jelly.
>
> I'll go ahead with the new beta release and we can
> always pick these
> issues up for the next beta or release.
>
>
> On Wed, 8 Sep 2004 03:10:31 +1000, Dion Gillard
> <di...@gmail.com> wrote:
> > On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem
> <ss...@yahoo.com> 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
I'm figuring by the silence and lack of issues raised in Jira that you
don't have the time / motivation to get back to us, or I did a bad job
explaining where we're at with Jelly.
I'll go ahead with the new beta release and we can always pick these
issues up for the next beta or release.
On Wed, 8 Sep 2004 03:10:31 +1000, Dion Gillard <di...@gmail.com> wrote:
> On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <ss...@yahoo.com> 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.
>
>
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
if necessary, it should be easy to retrofit dynabean support to
whatever jelly ends up using.
dynabeans are cool - in fact clazz with it's custom meta-data takes
dynabeans a stage further. what would be very cool is support for
pluggable introspection meta-data.
- robert
On 14 Sep 2004, at 04:53, Hans Gilde wrote:
> I agree about JEXL being an alternative BQL.
>
> But, Beanutils also gives us dynabeans. In theory, dynabeans give us an
> implementation for two types of tags: tags that take all their
> properties
> through setXXXX and getXXXX and tags that are more dynamic.
>
> The beanutils package detects dynabeans and handles them just like
> regular
> beans. In theory. Apparently, something about dynabeans didn't work in
> an
> earlier beanutils because jelly doesn't use dynabeans quite right. If
> it
> did, the code would be lots cleaner. I'm actually filing this as an
> issue in
> jira now.
>
> Now, the facts are that a) we don't use dynabeans exactly correctly
> and b)
> we could probably squeeze a little more speed out of dynamic tags if we
> directly use a Map of properties rather than dynabeans.
>
> Now to add a twist: beanutils will also query the tag (either dyna or
> regular bean) and give you a list of all the bean properties, and
> hence all
> the possible XML attributes, for documentation purposes. This *could*
> be a
> pre-built path to auto-documenting dynamic tag libraries like Swing.
> The
> only part that's not handled by beanutils is the part about attaching
> a text
> description to properties found from each tag.
>
> So... to summarize. We could easily replace beanutils/BQL with JEXL if
> we're
> willing to give up dynabeans. Giving up dynabeans would probably allow
> for a
> fairly small performance increase when compiling all tags and when
> running
> dynamic tags. The question is, what would we use instead of dynabeans?
>
> -----Original Message-----
> From: robert burrell donkin
> [mailto:robertburrelldonkin@blueyonder.co.uk]
> Sent: Monday, September 13, 2004 4:32 PM
> To: Jakarta Commons Users List
> Subject: Re: Jelly and a new beta release
>
> On 12 Sep 2004, at 21:27, Hans Gilde wrote:
>
>> When you say "allowing tag libraries to declare bindings", do you mean
>> Java
>> tag libs declaring Java constructs, Java tag libs declaring XDoclet
>> constructs or a separate descriptor for each tag lib? Or a combination
>> of
>> the above?
>
> i have no good, clear preferences about implementation...
>
>>
>> On the bean query language thing:
>>
>> A construct like ${bean.array[2].property} would use JEXL, which might
>> use
>> BQL for all I know. But Jelly would not use BQL directly in this case.
>
> i thought that would be the case.
>
> (on the subject of nomenclacture, i'd describe both JEXL and beanutils
> as embedding bean query languages as opposed to beanutils having the
> BQL.)
>
>> When converting XML attributes to bean properties, Jelly currently
>> uses
>> BeanUtils.populate. Now, BeanUtils recommends using copyProperties
>> instead
>> of populate. I was thinking of changing to copyProperties recently,
>> until I
>> noticed a somewhat odd side effect of populate: If you declare an XML
>> attribute a.b="foo", the string "a.b" will be passed to populate as
>> the
>> property name. populate will use BQL, and this single XML property
>> will
>> result in bean.getA().setB("foo"). So, in this case, BQL is used. I
>> don't
>> know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
>> complain. I also don't know if we want an XML attribute a.b to resolve
>> to
>> getA().setB() but... it makes the whole thing a little more
>> complicated.
>
> populate is a specialization aimed at processing HTTP requests. i
> suspect that james chose this because xml<->object is also
> text<->object. choosing just one system does have limitations.
>
> you're example is a good illustration of the absence of a general
> solution. in some cases, a.b would be best interpreted as a bean query
> language phrase and in other cases, it would be better passed without
> conversion to the bean. i suspect that one size doesn't fit all and
> that it might be better for conversions to be specified by each tag
> library (possible using beanutils as a default). JEXL should provide
> sufficient query language glue.
>
>> Also, the "set" tag (sets a bean property on a parent bean tag) relies
>> on
>> BeanUtils to resolve the property name and BeanUtils uses BQL, which
>> we
>> definitely want.
>
> i don't think that anyone objects to beanutils tag libs: it's the core
> embedding that's more arguable.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Jelly and a new beta release
Posted by Hans Gilde <hg...@earthlink.net>.
I agree about JEXL being an alternative BQL.
But, Beanutils also gives us dynabeans. In theory, dynabeans give us an
implementation for two types of tags: tags that take all their properties
through setXXXX and getXXXX and tags that are more dynamic.
The beanutils package detects dynabeans and handles them just like regular
beans. In theory. Apparently, something about dynabeans didn't work in an
earlier beanutils because jelly doesn't use dynabeans quite right. If it
did, the code would be lots cleaner. I'm actually filing this as an issue in
jira now.
Now, the facts are that a) we don't use dynabeans exactly correctly and b)
we could probably squeeze a little more speed out of dynamic tags if we
directly use a Map of properties rather than dynabeans.
Now to add a twist: beanutils will also query the tag (either dyna or
regular bean) and give you a list of all the bean properties, and hence all
the possible XML attributes, for documentation purposes. This *could* be a
pre-built path to auto-documenting dynamic tag libraries like Swing. The
only part that's not handled by beanutils is the part about attaching a text
description to properties found from each tag.
So... to summarize. We could easily replace beanutils/BQL with JEXL if we're
willing to give up dynabeans. Giving up dynabeans would probably allow for a
fairly small performance increase when compiling all tags and when running
dynamic tags. The question is, what would we use instead of dynabeans?
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Monday, September 13, 2004 4:32 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release
On 12 Sep 2004, at 21:27, Hans Gilde wrote:
> When you say "allowing tag libraries to declare bindings", do you mean
> Java
> tag libs declaring Java constructs, Java tag libs declaring XDoclet
> constructs or a separate descriptor for each tag lib? Or a combination
> of
> the above?
i have no good, clear preferences about implementation...
>
> On the bean query language thing:
>
> A construct like ${bean.array[2].property} would use JEXL, which might
> use
> BQL for all I know. But Jelly would not use BQL directly in this case.
i thought that would be the case.
(on the subject of nomenclacture, i'd describe both JEXL and beanutils
as embedding bean query languages as opposed to beanutils having the
BQL.)
> When converting XML attributes to bean properties, Jelly currently uses
> BeanUtils.populate. Now, BeanUtils recommends using copyProperties
> instead
> of populate. I was thinking of changing to copyProperties recently,
> until I
> noticed a somewhat odd side effect of populate: If you declare an XML
> attribute a.b="foo", the string "a.b" will be passed to populate as the
> property name. populate will use BQL, and this single XML property will
> result in bean.getA().setB("foo"). So, in this case, BQL is used. I
> don't
> know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
> complain. I also don't know if we want an XML attribute a.b to resolve
> to
> getA().setB() but... it makes the whole thing a little more
> complicated.
populate is a specialization aimed at processing HTTP requests. i
suspect that james chose this because xml<->object is also
text<->object. choosing just one system does have limitations.
you're example is a good illustration of the absence of a general
solution. in some cases, a.b would be best interpreted as a bean query
language phrase and in other cases, it would be better passed without
conversion to the bean. i suspect that one size doesn't fit all and
that it might be better for conversions to be specified by each tag
library (possible using beanutils as a default). JEXL should provide
sufficient query language glue.
> Also, the "set" tag (sets a bean property on a parent bean tag) relies
> on
> BeanUtils to resolve the property name and BeanUtils uses BQL, which we
> definitely want.
i don't think that anyone objects to beanutils tag libs: it's the core
embedding that's more arguable.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 12 Sep 2004, at 21:27, Hans Gilde wrote:
> When you say "allowing tag libraries to declare bindings", do you mean
> Java
> tag libs declaring Java constructs, Java tag libs declaring XDoclet
> constructs or a separate descriptor for each tag lib? Or a combination
> of
> the above?
i have no good, clear preferences about implementation...
>
> On the bean query language thing:
>
> A construct like ${bean.array[2].property} would use JEXL, which might
> use
> BQL for all I know. But Jelly would not use BQL directly in this case.
i thought that would be the case.
(on the subject of nomenclacture, i'd describe both JEXL and beanutils
as embedding bean query languages as opposed to beanutils having the
BQL.)
> When converting XML attributes to bean properties, Jelly currently uses
> BeanUtils.populate. Now, BeanUtils recommends using copyProperties
> instead
> of populate. I was thinking of changing to copyProperties recently,
> until I
> noticed a somewhat odd side effect of populate: If you declare an XML
> attribute a.b="foo", the string "a.b" will be passed to populate as the
> property name. populate will use BQL, and this single XML property will
> result in bean.getA().setB("foo"). So, in this case, BQL is used. I
> don't
> know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
> complain. I also don't know if we want an XML attribute a.b to resolve
> to
> getA().setB() but... it makes the whole thing a little more
> complicated.
populate is a specialization aimed at processing HTTP requests. i
suspect that james chose this because xml<->object is also
text<->object. choosing just one system does have limitations.
you're example is a good illustration of the absence of a general
solution. in some cases, a.b would be best interpreted as a bean query
language phrase and in other cases, it would be better passed without
conversion to the bean. i suspect that one size doesn't fit all and
that it might be better for conversions to be specified by each tag
library (possible using beanutils as a default). JEXL should provide
sufficient query language glue.
> Also, the "set" tag (sets a bean property on a parent bean tag) relies
> on
> BeanUtils to resolve the property name and BeanUtils uses BQL, which we
> definitely want.
i don't think that anyone objects to beanutils tag libs: it's the core
embedding that's more arguable.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Jelly and a new beta release
Posted by Hans Gilde <hg...@earthlink.net>.
When you say "allowing tag libraries to declare bindings", do you mean Java
tag libs declaring Java constructs, Java tag libs declaring XDoclet
constructs or a separate descriptor for each tag lib? Or a combination of
the above?
On the bean query language thing:
A construct like ${bean.array[2].property} would use JEXL, which might use
BQL for all I know. But Jelly would not use BQL directly in this case.
When converting XML attributes to bean properties, Jelly currently uses
BeanUtils.populate. Now, BeanUtils recommends using copyProperties instead
of populate. I was thinking of changing to copyProperties recently, until I
noticed a somewhat odd side effect of populate: If you declare an XML
attribute a.b="foo", the string "a.b" will be passed to populate as the
property name. populate will use BQL, and this single XML property will
result in bean.getA().setB("foo"). So, in this case, BQL is used. I don't
know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
complain. I also don't know if we want an XML attribute a.b to resolve to
getA().setB() but... it makes the whole thing a little more complicated.
Also, the "set" tag (sets a bean property on a parent bean tag) relies on
BeanUtils to resolve the property name and BeanUtils uses BQL, which we
definitely want.
So, in short, Jelly uses BQL in some cases but not in most cases. And it
behaves the same in any case.
Hans
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Sunday, September 12, 2004 12:03 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release
a few comments (in no particular order)...
allowing tag libraries to declare bindings sounds like the way to go.
in addition to the advantages already outlined, it might allow the
possibility of generate a concrete binding implementation for a tag
library. generated bindings are quicker than dynamic ones that use
reflection.
there are two real parts to beanutils: the bean query language and the
conversions. i suspect that since jelly has JEXL, it doesn't need to
use the beanutils bean query language. does anyone know whether this is
correct?
it'd probably be better to factor the bridging conversion code into
jelly (rather than beanutils). that way, anyone who wants to create a
tag library that uses some custom mechanism can do so more easier. this
would allow a jelly specific interface rather than a generic one.
- robert
On 11 Sep 2004, at 01:32, Hans Gilde wrote:
> I like this idea. At the moment, we do have subclass-based attribute
> conversion.
>
> What I really like is the automatic documentation aspect, although the
> declarative part sounds good too.
>
> Whatever the solution, we could provide a Java-only version so that
> tags
> don't have to use the declarative syntax if they don't want to. The
> Java-only version would let tags avoid a speed problem with loading
> mappers.
>
>
> So, a set of mappers would be needed per tag library (Swing's mappings
> aren't SWT's mappings) and possible per bean class. Mappers would
> intercept
> a get/set for a specific bean property name and apply the conversion.
>
> But, it gets more complicated because lots of libraries have methods
> like
> setSize(int x, int y), which we want to "convert" from a single XML
> attribute "size".
>
> This sort of fits in with the idea of having an XML "config" file for
> every
> tag library.
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@activemath.org]
> Sent: Friday, September 10, 2004 5:14 PM
> To: Jakarta Commons Users List
> Subject: Re: Jelly and a new beta release
>
> The problem with this approach, I think, is that it could be done much
> more declaratively thus providing support for tag-documentation...
>
> Mapping constants to integer could, for example, easily be done such.
>
> The declarative way that I was believing to be good would be to make a
> conversion-context class, presumably in beanutils, which would be a set
> of mappers. It could be called for copy (or set)Property just the
> static calls currently except, it could be configurable!
>
> Now, maybe such mappers would actually be slow things to load... I
> don't know...
>
> Instead we have subclass-based attribute-conversion parametrization
> currently as in UseBean, right ?
>
> paul
>
>
> Le 10 sept. 04, à 22:59, Hans Gilde a écrit :
>
>> This is supported in a generic way by the jelly UseBeanTag and used in
>> several places like the Swing tags. The way it's supported may look a
>> little inelegant in the code but I agree that it's certainly not due
>> to some huge deficiency in the BeanUtils.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
a few comments (in no particular order)...
allowing tag libraries to declare bindings sounds like the way to go.
in addition to the advantages already outlined, it might allow the
possibility of generate a concrete binding implementation for a tag
library. generated bindings are quicker than dynamic ones that use
reflection.
there are two real parts to beanutils: the bean query language and the
conversions. i suspect that since jelly has JEXL, it doesn't need to
use the beanutils bean query language. does anyone know whether this is
correct?
it'd probably be better to factor the bridging conversion code into
jelly (rather than beanutils). that way, anyone who wants to create a
tag library that uses some custom mechanism can do so more easier. this
would allow a jelly specific interface rather than a generic one.
- robert
On 11 Sep 2004, at 01:32, Hans Gilde wrote:
> I like this idea. At the moment, we do have subclass-based attribute
> conversion.
>
> What I really like is the automatic documentation aspect, although the
> declarative part sounds good too.
>
> Whatever the solution, we could provide a Java-only version so that
> tags
> don't have to use the declarative syntax if they don't want to. The
> Java-only version would let tags avoid a speed problem with loading
> mappers.
>
>
> So, a set of mappers would be needed per tag library (Swing's mappings
> aren't SWT's mappings) and possible per bean class. Mappers would
> intercept
> a get/set for a specific bean property name and apply the conversion.
>
> But, it gets more complicated because lots of libraries have methods
> like
> setSize(int x, int y), which we want to "convert" from a single XML
> attribute "size".
>
> This sort of fits in with the idea of having an XML "config" file for
> every
> tag library.
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@activemath.org]
> Sent: Friday, September 10, 2004 5:14 PM
> To: Jakarta Commons Users List
> Subject: Re: Jelly and a new beta release
>
> The problem with this approach, I think, is that it could be done much
> more declaratively thus providing support for tag-documentation...
>
> Mapping constants to integer could, for example, easily be done such.
>
> The declarative way that I was believing to be good would be to make a
> conversion-context class, presumably in beanutils, which would be a set
> of mappers. It could be called for copy (or set)Property just the
> static calls currently except, it could be configurable!
>
> Now, maybe such mappers would actually be slow things to load... I
> don't know...
>
> Instead we have subclass-based attribute-conversion parametrization
> currently as in UseBean, right ?
>
> paul
>
>
> Le 10 sept. 04, à 22:59, Hans Gilde a écrit :
>
>> This is supported in a generic way by the jelly UseBeanTag and used in
>> several places like the Swing tags. The way it's supported may look a
>> little inelegant in the code but I agree that it's certainly not due
>> to some huge deficiency in the BeanUtils.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Jelly and a new beta release
Posted by Hans Gilde <hg...@earthlink.net>.
I like this idea. At the moment, we do have subclass-based attribute
conversion.
What I really like is the automatic documentation aspect, although the
declarative part sounds good too.
Whatever the solution, we could provide a Java-only version so that tags
don't have to use the declarative syntax if they don't want to. The
Java-only version would let tags avoid a speed problem with loading mappers.
So, a set of mappers would be needed per tag library (Swing's mappings
aren't SWT's mappings) and possible per bean class. Mappers would intercept
a get/set for a specific bean property name and apply the conversion.
But, it gets more complicated because lots of libraries have methods like
setSize(int x, int y), which we want to "convert" from a single XML
attribute "size".
This sort of fits in with the idea of having an XML "config" file for every
tag library.
-----Original Message-----
From: Paul Libbrecht [mailto:paul@activemath.org]
Sent: Friday, September 10, 2004 5:14 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release
The problem with this approach, I think, is that it could be done much
more declaratively thus providing support for tag-documentation...
Mapping constants to integer could, for example, easily be done such.
The declarative way that I was believing to be good would be to make a
conversion-context class, presumably in beanutils, which would be a set
of mappers. It could be called for copy (or set)Property just the
static calls currently except, it could be configurable!
Now, maybe such mappers would actually be slow things to load... I
don't know...
Instead we have subclass-based attribute-conversion parametrization
currently as in UseBean, right ?
paul
Le 10 sept. 04, à 22:59, Hans Gilde a écrit :
> This is supported in a generic way by the jelly UseBeanTag and used in
> several places like the Swing tags. The way it's supported may look a
> little inelegant in the code but I agree that it's certainly not due
> to some huge deficiency in the BeanUtils.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Paul Libbrecht <pa...@activemath.org>.
The problem with this approach, I think, is that it could be done much
more declaratively thus providing support for tag-documentation...
Mapping constants to integer could, for example, easily be done such.
The declarative way that I was believing to be good would be to make a
conversion-context class, presumably in beanutils, which would be a set
of mappers. It could be called for copy (or set)Property just the
static calls currently except, it could be configurable!
Now, maybe such mappers would actually be slow things to load... I
don't know...
Instead we have subclass-based attribute-conversion parametrization
currently as in UseBean, right ?
paul
Le 10 sept. 04, à 22:59, Hans Gilde a écrit :
> This is supported in a generic way by the jelly UseBeanTag and used in
> several places like the Swing tags. The way it's supported may look a
> little inelegant in the code but I agree that it's certainly not due
> to some huge deficiency in the BeanUtils.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: Jelly and a new beta release
Posted by Hans Gilde <ha...@earthlink.net>.
BeanUtils looks good to me too, for generic bean operations. I can't see
replacing it, it seems to works great.
Jelly does have a few situations that want non-standard string-to-property
mappings, like int properties that want names instead of integer values in
the tag attributes.
This is supported in a generic way by the jelly UseBeanTag and used in
several places like the Swing tags. The way it's supported may look a little
inelegant in the code but I agree that it's certainly not due to some huge
deficiency in the BeanUtils.
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Thursday, September 09, 2004 3:34 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release
On 7 Sep 2004, at 21:16, Paul Libbrecht wrote:
<snip>
> 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...
FWIW i think that it's not beanutils that's the problem but
understanding what need it is satisfying in jelly. i'd recommend not
going down the creation-a-homegrown-beanutils-replacement route since
this has proved (in the past) to be very unlikely to produce anything
much better but is likely to be a lot of work.
beanutils (surprisingly enough) isn't so slow (at least with the modern
JVMs from sun). unless jelly's needs have been well analyzed, there a
risk of losing quite a lot of functionality for minimal real life
performance gain.
IMHO the real problem with beanutils is more a lack of flexibility,
configurability and tunability (rather than straight speed). it may be
that it'd be better for jelly to address these shortcomings by
factoring out based on it's needs (rather than just ripping out
beanutils).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Sep 2004, at 21:16, Paul Libbrecht wrote:
<snip>
> 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...
FWIW i think that it's not beanutils that's the problem but
understanding what need it is satisfying in jelly. i'd recommend not
going down the creation-a-homegrown-beanutils-replacement route since
this has proved (in the past) to be very unlikely to produce anything
much better but is likely to be a lot of work.
beanutils (surprisingly enough) isn't so slow (at least with the modern
JVMs from sun). unless jelly's needs have been well analyzed, there a
risk of losing quite a lot of functionality for minimal real life
performance gain.
IMHO the real problem with beanutils is more a lack of flexibility,
configurability and tunability (rather than straight speed). it may be
that it'd be better for jelly to address these shortcomings by
factoring out based on it's needs (rather than just ripping out
beanutils).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Paul Libbrecht <pa...@activemath.org>.
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...
paul
Le 7 sept. 04, à 19:10, Dion Gillard a écrit :
> On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <ss...@yahoo.com>
> 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.
> --
> http://www.multitask.com.au/people/dion/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <ss...@yahoo.com> 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.
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
that's a fine list :)
in short, since it's a beta we're talking about, i'd say: ship it now!
but let's resolve as many as possible for the next beta. i now
routinely take release branches even if the release is intended to be
just a short way off since it allows coding to continue at it's pace.
- robert
On 9 Sep 2004, at 01:42, Dion Gillard wrote:
> Any comments?
>
>
> On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <ss...@yahoo.com>
> 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.
>>
>> I'll list a few here as best I can in no particular
>> order:
>>
>> 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
>>
>> org.apache.commons.jelly.tags.core.ArgTag
>> Register ArgTag's converters with
>> ConvertUtilsBean's singleton.
>> Use converters registered with ConvertUtilsBean's
>> singleton.
>>
>> org.apache.commons.jelly.tags.core.IncludeTag
>> Fixed setExport
>>
>> org.apache.commons.jelly.JellyContext
>> runScript(), inherit flag seemed to clobber
>> existing variables
>>
>> org.apache.commons.jelly.tags.core.UseBeanTag
>> doTag(), remover 'var' attribute so it doesnt get
>> passed to setBeanProperties
>> Added a new 'ref' attribute which is
>> systematically set to the bean instance before tag
>> body is invoked.
>>
>> 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.
>>
>> org.apache.commons.jelly.tags.swing.ActionTag
>> doTag(), call invokeBody immdediately if 'class'
>> or 'action' attribute is specified.
>>
>> org.apache.commons.jelly.tags.swing.FontTag
>> Made it actually work.
>> Now supports java.awt.font.TextAttribute.
>>
>> org.apache.commons.jelly.tags.swing.GbcTag
>> Made it Java 1.3 compatible.
>>
>> 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.
>>
>> 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)
>>
>> 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).
>>
>> Make Jelly Java 1.3 compatible.
>>
>> Add instance and static member access to JEXL.
>>
>> org.apache.commons.jelly.JellyContext
>> Should discern between variables with a value of
>> null and variables that don't exits.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> --- Dion Gillard <di...@gmail.com> wrote:
>>
>>> Ok,
>>>
>>> all known issues for beta-4 have been completed.
>>>
>>> I'd like to do a beta release in the next day or so.
>>> Please vote on
>>> the beta release:
>>>
>>> [ ] +1 - Yes release
>>> [ ] +0 - Release, I have minor issues which can
>>> wait....
>>> [ ] -1 - No, don't release! Here's why....
>>>
>>>
>>> On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard
>>> <di...@gmail.com> wrote:
>>>> From JIRA there is one issue remaining for beta 4
>>> :
>>>>
>>>> http://issues.apache.org/jira/browse/JELLY-47
>>>>
>>>> which seems to be a dom4j related issue.
>>>>
>>>> I'd like to do a new release of Jelly ASAP and
>>> start planning the next beta.
>>>>
>>>> If anyone has bugs they'd like fixed for the beta
>>> or *urgent* new
>>>> functionality, please say so ASAP so we can
>>> finalize this release.
>>>> --
>>>> http://www.multitask.com.au/people/dion/
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.multitask.com.au/people/dion/
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> commons-user-help@jakarta.apache.org
>>>
>>>
>>
>> __________________________________
>> Do you Yahoo!?
>> New and Improved Yahoo! Mail - Send 10MB messages!
>> http://promotions.yahoo.com/new_mail
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
>
> --
> http://www.multitask.com.au/people/dion/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
Any comments?
On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <ss...@yahoo.com> 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.
>
> I'll list a few here as best I can in no particular
> order:
>
> 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
>
> org.apache.commons.jelly.tags.core.ArgTag
> Register ArgTag's converters with
> ConvertUtilsBean's singleton.
> Use converters registered with ConvertUtilsBean's
> singleton.
>
> org.apache.commons.jelly.tags.core.IncludeTag
> Fixed setExport
>
> org.apache.commons.jelly.JellyContext
> runScript(), inherit flag seemed to clobber
> existing variables
>
> org.apache.commons.jelly.tags.core.UseBeanTag
> doTag(), remover 'var' attribute so it doesnt get
> passed to setBeanProperties
> Added a new 'ref' attribute which is
> systematically set to the bean instance before tag
> body is invoked.
>
> 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.
>
> org.apache.commons.jelly.tags.swing.ActionTag
> doTag(), call invokeBody immdediately if 'class'
> or 'action' attribute is specified.
>
> org.apache.commons.jelly.tags.swing.FontTag
> Made it actually work.
> Now supports java.awt.font.TextAttribute.
>
> org.apache.commons.jelly.tags.swing.GbcTag
> Made it Java 1.3 compatible.
>
> 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.
>
> 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)
>
> 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).
>
> Make Jelly Java 1.3 compatible.
>
> Add instance and static member access to JEXL.
>
> org.apache.commons.jelly.JellyContext
> Should discern between variables with a value of
> null and variables that don't exits.
>
> 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.
>
> 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.
>
> 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.
>
> --- Dion Gillard <di...@gmail.com> wrote:
>
> > Ok,
> >
> > all known issues for beta-4 have been completed.
> >
> > I'd like to do a beta release in the next day or so.
> > Please vote on
> > the beta release:
> >
> > [ ] +1 - Yes release
> > [ ] +0 - Release, I have minor issues which can
> > wait....
> > [ ] -1 - No, don't release! Here's why....
> >
> >
> > On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard
> > <di...@gmail.com> wrote:
> > > From JIRA there is one issue remaining for beta 4
> > :
> > >
> > > http://issues.apache.org/jira/browse/JELLY-47
> > >
> > > which seems to be a dom4j related issue.
> > >
> > > I'd like to do a new release of Jelly ASAP and
> > start planning the next beta.
> > >
> > > If anyone has bugs they'd like fixed for the beta
> > or *urgent* new
> > > functionality, please say so ASAP so we can
> > finalize this release.
> > > --
> > > http://www.multitask.com.au/people/dion/
> > >
> >
> >
> >
> > --
> > http://www.multitask.com.au/people/dion/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-user-help@jakarta.apache.org
> >
> >
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by S Schrem <ss...@yahoo.com>.
[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.
I'll list a few here as best I can in no particular
order:
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
org.apache.commons.jelly.tags.core.ArgTag
Register ArgTag's converters with
ConvertUtilsBean's singleton.
Use converters registered with ConvertUtilsBean's
singleton.
org.apache.commons.jelly.tags.core.IncludeTag
Fixed setExport
org.apache.commons.jelly.JellyContext
runScript(), inherit flag seemed to clobber
existing variables
org.apache.commons.jelly.tags.core.UseBeanTag
doTag(), remover 'var' attribute so it doesnt get
passed to setBeanProperties
Added a new 'ref' attribute which is
systematically set to the bean instance before tag
body is invoked.
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.
org.apache.commons.jelly.tags.swing.ActionTag
doTag(), call invokeBody immdediately if 'class'
or 'action' attribute is specified.
org.apache.commons.jelly.tags.swing.FontTag
Made it actually work.
Now supports java.awt.font.TextAttribute.
org.apache.commons.jelly.tags.swing.GbcTag
Made it Java 1.3 compatible.
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.
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)
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).
Make Jelly Java 1.3 compatible.
Add instance and static member access to JEXL.
org.apache.commons.jelly.JellyContext
Should discern between variables with a value of
null and variables that don't exits.
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.
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.
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.
--- Dion Gillard <di...@gmail.com> wrote:
> Ok,
>
> all known issues for beta-4 have been completed.
>
> I'd like to do a beta release in the next day or so.
> Please vote on
> the beta release:
>
> [ ] +1 - Yes release
> [ ] +0 - Release, I have minor issues which can
> wait....
> [ ] -1 - No, don't release! Here's why....
>
>
> On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard
> <di...@gmail.com> wrote:
> > From JIRA there is one issue remaining for beta 4
> :
> >
> > http://issues.apache.org/jira/browse/JELLY-47
> >
> > which seems to be a dom4j related issue.
> >
> > I'd like to do a new release of Jelly ASAP and
> start planning the next beta.
> >
> > If anyone has bugs they'd like fixed for the beta
> or *urgent* new
> > functionality, please say so ASAP so we can
> finalize this release.
> > --
> > http://www.multitask.com.au/people/dion/
> >
>
>
>
> --
> http://www.multitask.com.au/people/dion/
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
Ok,
all known issues for beta-4 have been completed.
I'd like to do a beta release in the next day or so. Please vote on
the beta release:
[ ] +1 - Yes release
[ ] +0 - Release, I have minor issues which can wait....
[ ] -1 - No, don't release! Here's why....
On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard <di...@gmail.com> wrote:
> From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
I'll wait a few more days for feedback from this email, and unless
there's a blocker in jira, the plan is to release beta-4 early next
week, and then start work on RC1, with the focus on bug fixes for core
only.
Once core goes into RC1, the plan is to do the same for all taglibs as
well, so that they can be released independently.
On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard <di...@gmail.com> wrote:
> From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jelly and a new beta release
Posted by Dion Gillard <di...@gmail.com>.
Ok,
all known issues for beta-4 have been completed.
I'd like to do a beta release in the next day or so. Please vote on
the beta release:
[ ] +1 - Yes release
[ ] +0 - Release, I have minor issues which can wait....
[ ] -1 - No, don't release! Here's why....
On Tue, 31 Aug 2004 14:46:24 +1000, Dion Gillard <di...@gmail.com> wrote:
> From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JELLY-47
>
> which seems to be a dom4j related issue.
>
> I'd like to do a new release of Jelly ASAP and start planning the next beta.
>
> If anyone has bugs they'd like fixed for the beta or *urgent* new
> functionality, please say so ASAP so we can finalize this release.
> --
> http://www.multitask.com.au/people/dion/
>
--
http://www.multitask.com.au/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org