You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2004/01/05 23:44:05 UTC
Re: [BeanUtils] WrapDynaBean Enhacement Request
hi niall
i'll take a look at this sometime soonish.
- robert
On 30 Dec 2003, at 13:14, Niall Pemberton wrote:
> I submitted a bugzilla a while ago to enhace
> WrapDynaBean/WrapDynaClass:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23690
>
>
> The changes were
>
> 1) Implement a getInstance() method in WrapDynaBean so that the
> "original" wrapped bean can be retrieved.
> 2) Implement a newInstance() method in WrapDynaClass to generate new
> "wrapped" beans.
> 3) Change the get(name) and set(name, value) methods to make them more
> efficient and provide more usefull exception messages.
>
>
> Is there any chance on getting some feedback and/or indication whether
> there is any interest in applying it?
>
> Thanks
>
> Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] WrapDynaBean Enhacement Request
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Jan 2004, at 03:27, Craig R. McClanahan wrote:
> Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
<snip>
>> 3 seems to me to be a symptom of a bigger issue (which has been known
>> for some time). the exception handling in beanutils is painful and
>> confusing to many users. i'd be very reluctant to break backwards
>> compatibility (even for symantics) and i suspect that the proposed
>> patch does. we've talked before about the possibility of factoring out
>> the exception handling and possible it might be better to fix this
>> rather than the symptom. so maybe a little more talk and thought is
>> needed about this one.
>>
>
> I'm on general principles opposed to breaking backward compatibility
> on method
> names -- but I don't have any problem with efficiency improvements, or
> usability improvements (i.e. error messages that point you at what the
> real
> issue is). I haven't had time to look at your patch yet (slightly
> busy with
> JavaServer Faces at the moment ;-), but agree with Robert's general
> point that
> an overall review of how BeanUtils is put together as a whole is
> probably
> overdue. Indeed, that sort of thing would make sense in the context
> of a
> BeanUtils 2.0 type discussion, perhaps having 2.x releases while we
> continue
> bugfixes on the 1.x track and keep compatibility there.
>
> BeanUtils is a very widely used package, so we have to be even more
> careful than
> is typical in j-c about compatibility. But it's also time to do some
> innovation again, and these sorts of discussions might be a good
> kickoff for
> that.
+1
i have an idea that there are a number of much requested features that
it might be possible to add without breaking backwards compatibility.
there will be a price to pay in terms of introducing more strategy
plug-ins and greater complexity but i believe that the advantages of
being able to drop in more sophisticated functionality would be great.
now the main package has been beanified, it might be possible to allow
users to tweak existing applications without being forced to upgrade.
exception handling is one that's been talked about frequently. many
users find the current exception handling strategy confusing. there has
been talk about whether it'd be possible to factor out. i'm not sure
whether this would be possible or whether it'd solve niall's problems
but maybe it's something we might think about.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] WrapDynaBean Enhacement Request
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Jan 2004, at 05:44, Niall Pemberton wrote:
> My problem is I built a framework to just generate, process and spit
> out
> DynaBeans and then got it to also do POJ beans afterwards when I
> discovered
> your "Wrapped" DynaBeans .
>
> 1) WrapDynaClass.newInstance()
> The framework generates DynaBeans (from Excel files). I am storing the
> DynaClasses and using newInstance() to generate DynaBeans as it needs
> them.
> It just made adapting my framework to generate ordinary JavaBeans via
> "Wrapped" dynabeans v.easy with WrapDynaClass.newInstance() working
> the same
> as other DynaClasses. I agree with you, if I hadn't built it
> initiallly just
> for DynaBeans I could have done it differently.
>
> Also if WrapDyanClass doesn't implement the newInstance() method then
> it
> doesn't fulfill its contract as a DynaClass type - shouldn't it do it
> anyway, even if there are other ways to generate the WrapDynaBean -
> otherwise it has to be catered for as special case.
this seems like a reasonable use case. i'm in favour of adding this
method (with some more documentation giving advice about the most
typical use case). i'll probably go ahead and add this one unless
sometime soonish.
> 2) WrapDynaBean.getInstance()
> The framework runs out of the box to generate DynaBeans from Excel
> spreadsheets using XML configuration. If I can get the original
> JavaBean out
> of the Wrapper, I don't have to worry about modifying my existing
> framework.
> I think this is a good use case - have a system where you can plug in a
> Factory to generate whatever flavor of DynaBeans are required, process
> them
> and then spit them out to a downstreams system (which has no reference
> to
> those POJ Beans) which can then "UnWrap" them and use them as it likes.
being able to obtain a reference to the wrapped bean seems reasonable
to me. again, this kind of thing is probably not appropriate for the
most common use cases but would be useful for some kinds of design.
i'll probably go ahead and add it (with some appropriate documentation)
sometime soonish.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] WrapDynaBean Enhacement Request
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
My problem is I built a framework to just generate, process and spit out
DynaBeans and then got it to also do POJ beans afterwards when I discovered
your "Wrapped" DynaBeans .
1) WrapDynaClass.newInstance()
The framework generates DynaBeans (from Excel files). I am storing the
DynaClasses and using newInstance() to generate DynaBeans as it needs them.
It just made adapting my framework to generate ordinary JavaBeans via
"Wrapped" dynabeans v.easy with WrapDynaClass.newInstance() working the same
as other DynaClasses. I agree with you, if I hadn't built it initiallly just
for DynaBeans I could have done it differently.
Also if WrapDyanClass doesn't implement the newInstance() method then it
doesn't fulfill its contract as a DynaClass type - shouldn't it do it
anyway, even if there are other ways to generate the WrapDynaBean -
otherwise it has to be catered for as special case.
2) WrapDynaBean.getInstance()
The framework runs out of the box to generate DynaBeans from Excel
spreadsheets using XML configuration. If I can get the original JavaBean out
of the Wrapper, I don't have to worry about modifying my existing framework.
I think this is a good use case - have a system where you can plug in a
Factory to generate whatever flavor of DynaBeans are required, process them
and then spit them out to a downstreams system (which has no reference to
those POJ Beans) which can then "UnWrap" them and use them as it likes.
Thanks for your time and comments.
Niall
> Quoting Craig R. McClanahan <cr...@apache.org>>
> >
> > 1+2 it seemed clear that craig intended no constructors to be available
> > (and he usually has good reasons for his design decisions) but i think
> > that allowing WrapDynaClass and WrapDynaBean to fit better into
> > DynaBean frameworks seems like a strong argument for providing this
> > functionality. unless someone else speaks up, i'll likely commit
> > something along these lines.
> >
>
> This design was indeed deliberate. Whether it makes sense is certainly
open to
> discussion :-).
>
> The design intent for WrapDynaBean{,Class} was that you'd create new
> WrapDynaBean instances by saying:
>
> Object aJavaBean = ...;
> DynaBean db = new WrapDynaBean(aJavaBean);
>
> which (if it hasn't been done already) causes a WrapDynaBeanClass instance
to be
> created for you ... 1:1 with the underlying Class instance. I don't see a
> compelling need for making the WrapDynaBeanClass constructor public, but
> wouldn't be opposed to that if there was a good use case.
>
> For WrapDynaClass.newInstance(), though, it doesn't make sense to ask for
a new
> instance of WrapDynaBean without having it already wrapping some real
bean --
> and there's no way to specify one without a new method signature on
newInstance
> that passes in the bean to be wrapped. Doesn't that tie you very closely
to
> this particular implementation of DynaBean?
>
> Same argument applies to WrapDynaBean.getInstance() -- I'm not strongly
opposed
> to that, but my thinking was, once you've made the effort to wrap it,
you'd be
> using DynaBean APIs from now forward in any applications that actually use
> these beans. If you tie yourself to explicitly to the WrapDynaBean
(instead of
> the generic DynaBean) contract, doesn't that prevent you from switching
> DynaBean implementations later on if you find something better/faster?
>
> > 3 seems to me to be a symptom of a bigger issue (which has been known
> > for some time). the exception handling in beanutils is painful and
> > confusing to many users. i'd be very reluctant to break backwards
> > compatibility (even for symantics) and i suspect that the proposed
> > patch does. we've talked before about the possibility of factoring out
> > the exception handling and possible it might be better to fix this
> > rather than the symptom. so maybe a little more talk and thought is
> > needed about this one.
> >
>
> I'm on general principles opposed to breaking backward compatibility on
method
> names -- but I don't have any problem with efficiency improvements, or
> usability improvements (i.e. error messages that point you at what the
real
> issue is). I haven't had time to look at your patch yet (slightly busy
with
> JavaServer Faces at the moment ;-), but agree with Robert's general point
that
> an overall review of how BeanUtils is put together as a whole is probably
> overdue. Indeed, that sort of thing would make sense in the context of a
> BeanUtils 2.0 type discussion, perhaps having 2.x releases while we
continue
> bugfixes on the 1.x track and keep compatibility there.
>
> BeanUtils is a very widely used package, so we have to be even more
careful than
> is typical in j-c about compatibility. But it's also time to do some
> innovation again, and these sorts of discussions might be a good kickoff
for
> that.
>
> > comments welcome
> >
> > - robert
> >
>
> Craig
>
>
> ---------------------------------------------------------------------
> 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: [BeanUtils] WrapDynaBean Enhacement Request
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
>
> 1+2 it seemed clear that craig intended no constructors to be available
> (and he usually has good reasons for his design decisions) but i think
> that allowing WrapDynaClass and WrapDynaBean to fit better into
> DynaBean frameworks seems like a strong argument for providing this
> functionality. unless someone else speaks up, i'll likely commit
> something along these lines.
>
This design was indeed deliberate. Whether it makes sense is certainly open to
discussion :-).
The design intent for WrapDynaBean{,Class} was that you'd create new
WrapDynaBean instances by saying:
Object aJavaBean = ...;
DynaBean db = new WrapDynaBean(aJavaBean);
which (if it hasn't been done already) causes a WrapDynaBeanClass instance to be
created for you ... 1:1 with the underlying Class instance. I don't see a
compelling need for making the WrapDynaBeanClass constructor public, but
wouldn't be opposed to that if there was a good use case.
For WrapDynaClass.newInstance(), though, it doesn't make sense to ask for a new
instance of WrapDynaBean without having it already wrapping some real bean --
and there's no way to specify one without a new method signature on newInstance
that passes in the bean to be wrapped. Doesn't that tie you very closely to
this particular implementation of DynaBean?
Same argument applies to WrapDynaBean.getInstance() -- I'm not strongly opposed
to that, but my thinking was, once you've made the effort to wrap it, you'd be
using DynaBean APIs from now forward in any applications that actually use
these beans. If you tie yourself to explicitly to the WrapDynaBean (instead of
the generic DynaBean) contract, doesn't that prevent you from switching
DynaBean implementations later on if you find something better/faster?
> 3 seems to me to be a symptom of a bigger issue (which has been known
> for some time). the exception handling in beanutils is painful and
> confusing to many users. i'd be very reluctant to break backwards
> compatibility (even for symantics) and i suspect that the proposed
> patch does. we've talked before about the possibility of factoring out
> the exception handling and possible it might be better to fix this
> rather than the symptom. so maybe a little more talk and thought is
> needed about this one.
>
I'm on general principles opposed to breaking backward compatibility on method
names -- but I don't have any problem with efficiency improvements, or
usability improvements (i.e. error messages that point you at what the real
issue is). I haven't had time to look at your patch yet (slightly busy with
JavaServer Faces at the moment ;-), but agree with Robert's general point that
an overall review of how BeanUtils is put together as a whole is probably
overdue. Indeed, that sort of thing would make sense in the context of a
BeanUtils 2.0 type discussion, perhaps having 2.x releases while we continue
bugfixes on the 1.x track and keep compatibility there.
BeanUtils is a very widely used package, so we have to be even more careful than
is typical in j-c about compatibility. But it's also time to do some
innovation again, and these sorts of discussions might be a good kickoff for
that.
> comments welcome
>
> - robert
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] WrapDynaBean Enhacement Request
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Robert
Thanks for taking the time to look at this and giving feedback. I take the
hint about the test cases - I'll have to get into how its done in jakarta
some time.
On point 3, I agree about fixing the exception handling in the right place,
rather than in this specific instance. The other point about this change was
a performance improvement. When the WrapDyanClass is constructed it
introspects to discover and store the PropertyDescriptors for the bean, but
WrapDyanBean uses the get/setSimpleProperty methods in PropertyUtilsBean
which means this introspection is repeated for every get/set. This seems a
shame and must be faster just to introspect once . Maybe the answer is to
split PropertyUtilsBean get/setSimpleProperty methods each into two methods
so that WrapDyanBean could take advantage of the stored PropertyDescriptors
while leaving PropertyUtilsBean processing unchanged. I include example
setSimpleProperty methods below.
Anyway 2 out of 3 would be a good result for me, I'd rather use as close to
a "vanilla" flavor of beanutils as possible - so anthing that gets into the
code base is great.
Niall
=========>Example:
public void setSimpleProperty(Object bean,
String name, Object value)
throws IllegalAccessException, InvocationTargetException,
NoSuchMethodException {
setSimpleProperty(bean, name, value, null);
}
public void setSimpleProperty(Object bean,
String name, Object value,
PropertyDescriptor propertyDescriptor)
throws IllegalAccessException, InvocationTargetException,
NoSuchMethodException {
if (bean == null) {
throw new IllegalArgumentException("No bean specified");
}
if (name == null) {
throw new IllegalArgumentException("No name specified");
}
// Validate the syntax of the property name
if (name.indexOf(PropertyUtils.NESTED_DELIM) >= 0) {
throw new IllegalArgumentException
("Nested property names are not allowed");
} else if (name.indexOf(PropertyUtils.INDEXED_DELIM) >= 0) {
throw new IllegalArgumentException
("Indexed property names are not allowed");
} else if (name.indexOf(PropertyUtils.MAPPED_DELIM) >= 0) {
throw new IllegalArgumentException
("Mapped property names are not allowed");
}
// Handle DynaBean instances specially
if (bean instanceof DynaBean) {
DynaProperty descriptor =
((DynaBean) bean).getDynaClass().getDynaProperty(name);
if (descriptor == null) {
throw new NoSuchMethodException("Unknown property '" +
name + "'");
}
((DynaBean) bean).set(name, value);
return;
}
// Retrieve the property setter method for the specified property
PropertyDescriptor descriptor = propertyDescriptor == null ?
getPropertyDescriptor(bean, name) : propertyDescriptor;
if (descriptor == null) {
throw new NoSuchMethodException("Unknown property '" +
name + "'");
}
Method writeMethod = getWriteMethod(descriptor);
if (writeMethod == null) {
throw new NoSuchMethodException("Property '" + name +
"' has no setter method");
}
// Call the property setter method
Object values[] = new Object[1];
values[0] = value;
if (log.isTraceEnabled()) {
String valueClassName =
value == null ? "<null>" : value.getClass().getName();
log.trace("setSimpleProperty: Invoking method " + writeMethod
+ " with value " + value + " (class " + valueClassName
+ ")");
}
invokeMethod(writeMethod, bean, values);
}
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Tuesday, January 06, 2004 8:32 PM
Subject: Re: [BeanUtils] WrapDynaBean Enhacement Request
> hi niall
>
> patches are much more likely to get promptly applied if they come with
> unit tests (hint, hint ;)
>
> 1+2 it seemed clear that craig intended no constructors to be available
> (and he usually has good reasons for his design decisions) but i think
> that allowing WrapDynaClass and WrapDynaBean to fit better into
> DynaBean frameworks seems like a strong argument for providing this
> functionality. unless someone else speaks up, i'll likely commit
> something along these lines.
>
> 3 seems to me to be a symptom of a bigger issue (which has been known
> for some time). the exception handling in beanutils is painful and
> confusing to many users. i'd be very reluctant to break backwards
> compatibility (even for symantics) and i suspect that the proposed
> patch does. we've talked before about the possibility of factoring out
> the exception handling and possible it might be better to fix this
> rather than the symptom. so maybe a little more talk and thought is
> needed about this one.
>
> comments welcome
>
> - robert
>
> On 6 Jan 2004, at 00:17, Niall Pemberton wrote:
>
> > Thanks, feedback would be much appreciated.
> >
> > Niall
> > ----- Original Message -----
> > From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Monday, January 05, 2004 10:44 PM
> > Subject: Re: [BeanUtils] WrapDynaBean Enhacement Request
> >
> >
> >> hi niall
> >>
> >> i'll take a look at this sometime soonish.
> >>
> >> - robert
> >>
> >> On 30 Dec 2003, at 13:14, Niall Pemberton wrote:
> >>
> >>> I submitted a bugzilla a while ago to enhace
> >>> WrapDynaBean/WrapDynaClass:
> >>>
> >>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23690
> >>>
> >>>
> >>> The changes were
> >>>
> >>> 1) Implement a getInstance() method in WrapDynaBean so that the
> >>> "original" wrapped bean can be retrieved.
> >>> 2) Implement a newInstance() method in WrapDynaClass to generate new
> >>> "wrapped" beans.
> >>> 3) Change the get(name) and set(name, value) methods to make them
> >>> more
> >>> efficient and provide more usefull exception messages.
> >>>
> >>>
> >>> Is there any chance on getting some feedback and/or indication
> >>> whether
> >>> there is any interest in applying it?
> >>>
> >>> Thanks
> >>>
> >>> Niall
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> 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: [BeanUtils] WrapDynaBean Enhacement Request
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi niall
patches are much more likely to get promptly applied if they come with
unit tests (hint, hint ;)
1+2 it seemed clear that craig intended no constructors to be available
(and he usually has good reasons for his design decisions) but i think
that allowing WrapDynaClass and WrapDynaBean to fit better into
DynaBean frameworks seems like a strong argument for providing this
functionality. unless someone else speaks up, i'll likely commit
something along these lines.
3 seems to me to be a symptom of a bigger issue (which has been known
for some time). the exception handling in beanutils is painful and
confusing to many users. i'd be very reluctant to break backwards
compatibility (even for symantics) and i suspect that the proposed
patch does. we've talked before about the possibility of factoring out
the exception handling and possible it might be better to fix this
rather than the symptom. so maybe a little more talk and thought is
needed about this one.
comments welcome
- robert
On 6 Jan 2004, at 00:17, Niall Pemberton wrote:
> Thanks, feedback would be much appreciated.
>
> Niall
> ----- Original Message -----
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, January 05, 2004 10:44 PM
> Subject: Re: [BeanUtils] WrapDynaBean Enhacement Request
>
>
>> hi niall
>>
>> i'll take a look at this sometime soonish.
>>
>> - robert
>>
>> On 30 Dec 2003, at 13:14, Niall Pemberton wrote:
>>
>>> I submitted a bugzilla a while ago to enhace
>>> WrapDynaBean/WrapDynaClass:
>>>
>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23690
>>>
>>>
>>> The changes were
>>>
>>> 1) Implement a getInstance() method in WrapDynaBean so that the
>>> "original" wrapped bean can be retrieved.
>>> 2) Implement a newInstance() method in WrapDynaClass to generate new
>>> "wrapped" beans.
>>> 3) Change the get(name) and set(name, value) methods to make them
>>> more
>>> efficient and provide more usefull exception messages.
>>>
>>>
>>> Is there any chance on getting some feedback and/or indication
>>> whether
>>> there is any interest in applying it?
>>>
>>> Thanks
>>>
>>> Niall
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] WrapDynaBean Enhacement Request
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Thanks, feedback would be much appreciated.
Niall
----- Original Message -----
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, January 05, 2004 10:44 PM
Subject: Re: [BeanUtils] WrapDynaBean Enhacement Request
> hi niall
>
> i'll take a look at this sometime soonish.
>
> - robert
>
> On 30 Dec 2003, at 13:14, Niall Pemberton wrote:
>
> > I submitted a bugzilla a while ago to enhace
> > WrapDynaBean/WrapDynaClass:
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23690
> >
> >
> > The changes were
> >
> > 1) Implement a getInstance() method in WrapDynaBean so that the
> > "original" wrapped bean can be retrieved.
> > 2) Implement a newInstance() method in WrapDynaClass to generate new
> > "wrapped" beans.
> > 3) Change the get(name) and set(name, value) methods to make them more
> > efficient and provide more usefull exception messages.
> >
> >
> > Is there any chance on getting some feedback and/or indication whether
> > there is any interest in applying it?
> >
> > Thanks
> >
> > Niall
>
>
> ---------------------------------------------------------------------
> 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