commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] new StringBuffer +
Date Thu, 18 Dec 2003 19:59:58 GMT
Ah, so we /are/ talking about a wrapper/adapter class, which seems quite
fine. IMHO, we should then name it as such: StringBufferWrapper,
StringBufferAdaptor, or StringBufferDecorator.

> Finally, this class should probably aim to use the private
> constructors/methods on String via reflection (breaking access limits).

Let's be very careful with this one. If reflection is used, let's call the
class something like ReflectionStringBuffer. I am making this point because
breaking security access IS a problem when your code has to live in a J2EE
server. Forcing a J2EE admin to tweak security settings in order for such
code to function at runtime is not always a good thing. It is also a pain.

I hate to mention it but... there is always the performance thought. Using
reflection can be expensive and if you are using a StringBuffer or
StringBuffer replacement instead of "" + "", then you are probably thinking
efficiency, maybe.

I think we should consider a non-reflection StringBuffer-like class first.

pennies,
Gary
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, December 18, 2003 11:53
> To: Jakarta Commons Developers List
> Subject: Re: [lang] new StringBuffer +
> 
> The idea is to have a drop in replacement for StringBuffer for when you
> need
> more functionality. At work this class is called UStringBuffer. That
> implementation decorates a StringBuffer, but I suspect directly holding
> the
> String array would be more efficient.
> 
> Why? StringBuffer does annoying things, such as adding the text "null" if
> you pass in null (thus new method appendSilentNull()). It doesn't have
> many
> of the methods from String (or didn't in early JDKs), so this would aid
> consistency.
> 
> It could be written as a Utils class, but it is much nicer to write
> buf.append().appendSilentNull).append(). etc
> (OK, I know not everyone likes that style of coding, but quite a lot do.)
> 
> Finally, this class should probably aim to use the private
> constructors/methods on String via reflection (breaking access limits).
> 
> Stephen
> 
> 
> ----- Original Message -----
> From: "Inger, Matthew" <inger@Synygy.com>
> > My main question here is this:
> >
> > Are the operations you're planning on implementing able to
> > be implemented by accessing the appropriate API methods on
> > StringBuffer, or does it require access to the underlying data.
> >
> > The basic reason I ask is that if it's the first case, there's
> > no need for a constructable class, but rather a utility class which
> provided
> > static final methods to do your operations.
> >
> > If it requires access to the underlying data (ie. the char array
> > you'd be storing) then an actual class makes sense.  However, why
> > would you want to re-implement the methods that StringBuffer has already
> > implemented?  And if you're answer is that StringBufferPlus is going to
> > delegate to StringBuffer, i think the first principle applies here, in
> > which case a utility class is the answer.
> >
> > -----Original Message-----
> > From: Arun Thomas [mailto:arun.thomas@paybytouch.com]
> > Sent: Thursday, December 18, 2003 11:11 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: [lang] new StringBuffer +
> >
> >
> > +1
> >
> > Good idea....
> >
> > -AMT
> >
> > -----Original Message-----
> > From: ASHWIN Suresh [mailto:a.suresh@sigmatel.net.ma]
> > Sent: Thursday, December 18, 2003 4:35 AM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [lang] new StringBuffer +
> >
> >
> > How about StringBufferPlus ??
> >
> > It's not an abbreviation,
> > fits into Stephen's scheme of alphabetical order,
> > doesnt introduce any new terminology/concept,
> > and gives us a new convention (-Plus suffix) to denote our enhancement
> > classes.
> >
> > Ash
> >
> >
> >
> > > -----Original Message-----
> > > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > Sent: Thursday, December 18, 2003 08:06
> > >
> > >
> > >
> > > Sounds to me like what we have is:
> > >
> > > Enhanced/ImprovedStringBuffer
> > >
> > > if we really want to be extending StringBuffer and adding a few more
> > > methods.
> > >
> > > None of the other names seem to indicate what is actually
> > > being discussed.
> > >
> > > That said, do we really have enough new methods to justify
> > > the creation of
> > > a new class?
> > >
> > > Hen
> > >
> > > On Wed, 10 Dec 2003, Stephen Colebourne wrote:
> > >
> > > > Let confusion reign.....
> > > > Lang should not contain a replacement for String. But that isn't the
> > > > proposal (it was a typo).
> > > >
> > > > The class here is a replacement for StringBuffer. It should be a
> > > > substitutable replacement in all current uses, thus all the
> > > methods from
> > > > StringBuffer must be replicated exactly. However it can
> > > have additional
> > > > methods, such as
> > > >   appendSilentNull(Object obj) - which doesn't output the
> > > text 'null' if
> > > > null is passed in
> > > >   replace(String,String) - which IIRC isn't on the JDK version and
> > > > so on.
> > > >
> > > > BTW: MutableString is a bad name as it can imply a class
> > > that holds a String
> > > > and has a getString and setString method.
> > > >
> > > > Stephen
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Gary Gregory" <ggregory@seagullsw.com>
> > > > > Matthew,
> > > > >
> > > > > Please note that I am only replying to Ash's message in
> > > order to toss
> > > > ideas
> > > > > around. I am just trying to get to what Ash is really proposing.
I
> > > > > am not advocating for the addition of such a class, it
> > > certainly is not
> > > > > "my" class ;-)
> > > > >
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Inger, Matthew [mailto:inger@Synygy.com]
> > > > > > Sent: Wednesday, December 10, 2003 12:14
> > > > > > To: 'Jakarta Commons Developers List'
> > > > > > Subject: RE: [lang] new StringBuffer
> > > > > >
> > > > > > I would get no warm and fuzzy feeling from this.  It gains you
> > > > > > nothing, and will make code more confusing.  Being that
> > > String is
> > > > > > final, you can't make this a subclass, so you'd have to
> > > do conversions
> > > > > > all over the place between String and your class.
> > > > > >
> > > > > > IMHO, extending a class to add new functionality is not
> > > a good OOP
> > > > > > practice (Liskov substitution rule).  That's really what you're
> > > > > > trying to do here, even though you can't actually extend String.
> > > > > >
> > > > > > Utility methods are the way to go.  It's simple and
> > > concise, plus
> > > > > > there's no conversions needed.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gary Gregory [mailto:ggregory@seagullsw.com]
> > > > > > Sent: Wednesday, December 10, 2003 3:04 PM
> > > > > > To: 'Jakarta Commons Developers List'
> > > > > > Subject: RE: [lang] new StringBuffer
> > > > > >
> > > > > >
> > > > > > With a "replacement" String class, you can add to it
> > > all sorts of
> > > > goodies
> > > > > > now in StringUtils and pass instances of that around.
> > > The code would
> > > > look
> > > > > > a
> > > > > > little better than having static calls to StringUtils
> > > all over. I guess
> > > > it
> > > > > > is a matter a style. The more I think about it though,
> > > the less warm and
> > > > > > fuzzy I feel about it... (since you also need to
> > > toString() the object
> > > > > > before passing it to anything to needs a "real" String).
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Inger, Matthew [mailto:inger@Synygy.com]
> > > > > > > Sent: Wednesday, December 10, 2003 11:53
> > > > > > > To: 'Jakarta Commons Developers List'
> > > > > > > Subject: RE: [lang] new StringBuffer
> > > > > > >
> > > > > > > java.lang.String is already immutable.  Why would you
> > > want to create
> > > > an
> > > > > > > "ImmutableString" class?
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Gary Gregory [mailto:ggregory@seagullsw.com]
> > > > > > > Sent: Wednesday, December 10, 2003 2:51 PM
> > > > > > > To: 'Jakarta Commons Developers List'
> > > > > > > Subject: RE: [lang] new StringBuffer
> > > > > > >
> > > > > > >
> > > > > > > Ash,
> > > > > > >
> > > > > > > I am confused, are you talking about creating a
> > > better String or a
> > > > > > better
> > > > > > > StringBuffer? You mention "the replacement of
> > > StringBuffer", but then
> > > > > > > suggest "ImmutableString", these names (in "") are
> > > two very different
> > > > > > > things.
> > > > > > >
> > > > > > > It sure would be nice to have an ImmutableString
> > > class to use instead
> > > > of
> > > > > > > the
> > > > > > > plain old JRE String, but it is not a different
> > > StringBuffer. Or are
> > > > you
> > > > > > > saying that this new class should do both jobs? In
> > > which case, it
> > > > would
> > > > > > > not
> > > > > > > be immutable ;-)
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: ASHWIN Suresh [mailto:a.suresh@sigmatel.net.ma]
> > > > > > > > Sent: Wednesday, December 10, 2003 10:31
> > > > > > > > To: 'Jakarta Commons Developers List'
> > > > > > > > Subject: RE: [lang] new StringBuffer
> > > > > > > >
> > > > > > > > First off, in my conception of the replacement of
> > > StringBuffer,
> > > > > > > > I imagine error handling will take care of wrongly
> > > passed in values
> > > > > > > > in a manner similar to classes in cmmons.lang,
> > > rather than in
> > > > Standard
> > > > > > > > API. That is, it will change the erroneous inputs
> > > to benign values,
> > > > > > > > rather than throwing an exception. Please confirm
this.
> > > > > > > >
> > > > > > > > If Stephen meant that even erroneous input results
> > > in the same
> > > > > > behavior
> > > > > > > > as in java.lang.StringBuffer, then I would say, my
> > > understanding
> > > > > > > > of the intention of the replacement was in part to
> > > soften the
> > > > reaction
> > > > > > > > toward wrong argument input. Let me know.
> > > > > > > >
> > > > > > > > Talking about name, I would add my opinion that
> > > while it might be
> > > > > > > > nice to have a name for the replacer that is much
> > > like the replacee,
> > > > > > > > (StringBuf) one might prefer a more descriptive
> > > name at the expense
> > > > > > > > of this convenience: (ImmutableString).
> > > > > > > >
> > > > > > > > As a compromise between the two, the name Strand
> > > can be adopted
> > > > > > (Str...
> > > > > > > > so near the original one + can be defined to
> > > represent a mutable
> > > > > > > > string contrasted with "String" which, by virtue of
> > > the so-named
> > > > > > > > class in the API, is immutable.)
> > > > > > > >
> > > > > > > > Comments.
> > > > > > > > Ash
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Stephen Colebourne
> > > [mailto:scolebourne@btopenworld.com]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I remembered my favorite name - StringBuf. Its
> > > always nice if
> > > > > > > > > the class
> > > > > > > > > appears in Eclipse next to the one its replacing
:-)
> > > > > > > > >
> > > > > > > > > Stephen
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Ash .." <equinus100@hotmail.com>
> > > > > > > > > > Sounds good, I will then work on a StringBuffer
> > > > > > > > > replacement, and then
> > > > > > > > > > later on get on to providing it with an
XUtils.
> > > > > > > > > >
> > > > > > > > > > That way, we will also be able to optimize
the
> > > subsequent
> > > > > > > > > StringBufferUtils
> > > > > > > > > > implementation using package-private access.
> > > > > > > > > > I have always been a little disappointed
with
> > > the facilities
> > > > > > > > > > java.lang.StringBuffer
> > > > > > > > > > offered, and now I have a chance to do
> > > something abt it :)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > And now for the name game: I propose MutableString.
> > > > > > > > > >
> > > > > > > > > > Other possible name suggestions, some quite
> > > fancy, would be:
> > > > > > > > > >
> > > > > > > > > > Strand, CharStrand
> > > > > > > > > > Token,
> > > > > > > > > > Bead, CharBead,
> > > > > > > > > > CharGroup, CharBunch,
> > > > > > > > > > CharLot, StringLot....
> > > > > > > > > >
> > > > > > > > > > I find Strand especially useful because
that
> > > lets us talk
> > > > > > > > > about a mutable
> > > > > > > > > > string in a conceptually distinct manner.
Of course, its
> > > > > > > > > replacive role is
> > > > > > > > > > not immediate obvious by the name, and some
> > > might suggest that
> > > > it
> > > > > > is
> > > > > > > > > better
> > > > > > > > > > that the new name reflects its surrogate
nature wrt
> > > > > > > > > StringBuffer. However,
> > > > > > > > > a
> > > > > > > > > > new coin may be useful in the long term.
Just
> > > my 2 cents.
> > > > > > > > > >
> > > > > > > > > > Ash
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >-----Original Message-----
> > > > > > > > > > >From: Stephen Colebourne
> > > [mailto:scolebourne@btopenworld.com]
> > > > > > > > > > >Sent: Tuesday, December 09, 2003 22:15
> > > > > > > > > > >To: Jakarta Commons Developers List
> > > > > > > > > > >Subject: Re: [lang] StringBufferUtils
replacement for
> > > > > > > > > StringUtils --
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >Ah, I see what you mean. And no that
wasn't
> > > what I meant :-)
> > > > > > > > > > >
> > > > > > > > > > >There is the potential for a StringBufferUtils,
with
> > > > > > > > > similar methods to
> > > > > > > > > > >StringUtils, but where the first passed
in
> > > parameter is a
> > > > > > > > > StringBuffer.
> > > > > > > > > > >
> > > > > > > > > > >However, what I was thinking of (see
the todo list in
> > > > > > > > > status.html) is a
> > > > > > > > > new
> > > > > > > > > > >instantiable class
> > > > > > > > > > >
> > > > > > > > > > >public AStringBuffer() {
> > > > > > > > > > >   private char[] buffer = new char[32];
> > > > > > > > > > >   private int size = 0;
> > > > > > > > > > >
> > > > > > > > > > >   public AStringBuffer() {
> > > > > > > > > > >   }
> > > > > > > > > > >   public void append(Object obj) {
> > > > > > > > > > >     // copy to end of buffer
> > > > > > > > > > >   }
> > > > > > > > > > >}
> > > > > > > > > > >
> > > > > > > > > > >ie. a direct StringBuffer replacement.
> > > > > > > > > > >
> > > > > > > > > > >Both are good candidates for [lang].
> > > > > > > > > > >
> > > > > > > > > > >Stephen
> > > > > > > > > > >
> > > > > > > > > > >----- Original Message -----
> > > > > > > > > > >From: "ASHWIN Suresh" <a.suresh@sigmatel.net.ma>
> > > > > > > > > > > > With the one difference that the
methods here don't
> > > > > > > > > return aything,
> > > > > > > > > but
> > > > > > > > > > > > instead modify the StringBuffer
> > > > > > > > > > > > passed in, directly.
> > > > > > > > > > > > I will start work on it tonight.
> > > > > > > > > > > > Ash
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > From: Stephen Colebourne
> > > > > > [mailto:scolebourne@btopenworld.com]
> > > > > > > > > > > > > Sent: Tuesday, December 09,
2003 20:07
> > > > > > > > > > > > > To: Jakarta Commons Developers
List
> > > > > > > > > > > > > Subject: Re: [lang] String
Utils replacement for
> > > > > > > > > StringUtils -- was
> > > > > > > > > > > > > ([lang] StringUtils.split()
functionality wrt
> > > > > > > > > separator repeats)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The string buffer class needs
to begin by
> > > having all the
> > > > > > same
> > > > > > > > > > > > > methods as
> > > > > > > > > > > > > StringBuffer, and they should
do exactly
> > > the same. Then,
> > > > > > > > > > > > > methods to handle
> > > > > > > > > > > > > null would be added:
> > > > > > > > > > > > >  appendSilentNull()
> > > > > > > > > > > > >
> > > > > > > > > > > > > At that point, we could evaluate
it and
> > > see what else
> > > > > > > > > should be
> > > > > > > > > added.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Stephen
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > > From: "ASHWIN Suresh" <a.suresh@sigmatel.net.ma>
> > > > > > > > > > > > > > Incidentally (or perhaps
it was to
> > > come), I was about to
> > > > > > > > > > > > > send out another
> > > > > > > > > > > > > > email
> > > > > > > > > > > > > > proposing a StringUtils-like
class that handles
> > > > > > > > > > > > > StringBuffer instead.
> > > > > > > > > > > > > > I would be interested
in writing it,
> > > but I need to
> > > > > > evaluate
> > > > > > > > > > > > > how much time
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > can afford
> > > > > > > > > > > > > > to it (will let u know).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > In the meanwhile, assuming
I can go
> > > ahead, you can list
> > > > > > out
> > > > > > > > > > > > > right away
> > > > > > > > > > > > > what
> > > > > > > > > > > > > > differences
> > > > > > > > > > > > > > you see between StringUtils
and the StringBuffer
> > > > > > > > > > > > > counterpart. I can, for
> > > > > > > > > > > > > > now, perhaps cover the
> > > > > > > > > > > > > > simpler methods which
are similar to
> > > the StringUtils
> > > > ones.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Regarding tightening
admissibility of
> > > new methods to a
> > > > > > > > > > > > > class because it is
> > > > > > > > > > > > > > large, I
> > > > > > > > > > > > > > am of the opinion that
for a class of
> > > only static
> > > > methods
> > > > > > > > > > > > > such as this
> > > > > > > > > > > > > one,
> > > > > > > > > > > > > > why should there be
any hesitation.
> > > StringUtils is but a
> > > > > > > > > > > > > repository of all
> > > > > > > > > > > > > > such
> > > > > > > > > > > > > > features, so as long
as we have clear
> > > documentation, I
> > > > see
> > > > > > > > > > > > > no reason why
> > > > > > > > > > > > > > largeness
> > > > > > > > > > > > > > should lead to limits
to having more methods.
> > > > > > > > > > > > > > Let me know.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Ash
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > > > From: Stephen Colebourne
> > > > > > > > > [mailto:scolebourne@btopenworld.com]
> > > > > > > > > > > > > > > Sent: Monday, December
08, 2003 22:05
> > > > > > > > > > > > > > > To: Jakarta Commons
Developers List
> > > > > > > > > > > > > > > Subject: Re: [lang]
> > > StringUtils.split() functionality
> > > > > > wrt
> > > > > > > > > > > > > separator
> > > > > > > > > > > > > > > repeats
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With StringUtils,
we now face tough decisions.
> > > > > > > > > The class is
> > > > > > > > > > > > > > > already very
> > > > > > > > > > > > > > > large, and adding
more and more methods is not
> > > > > > necessarily
> > > > > > > > > > > > > > > the answer. I am
> > > > > > > > > > > > > > > now applying a
fairly high level of
> > > justification to
> > > > new
> > > > > > > > > > > > > additions to
> > > > > > > > > > > > > > > StringUtils. ATM
more split methods
> > > or overloads
> > > > > > > > > don't meet
> > > > > > > > > > > > > > > what I'm looking
> > > > > > > > > > > > > > > for.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > That said, there
are still some
> > > misisng methods in
> > > > > > > > > > > > > > > StringUtils, notably
> > > > > > > > > > > > > > > startsWith, endsWith
and concat/append. (all
> > > > null-safe).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > In addition, a
StringBuffer
> > > replacement needs writing,
> > > > > > if
> > > > > > > > > > > > > > > you're interested
> > > > > > > > > > > > > > > ;-)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Stephen
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > > --------------------------------------------------------------------
> > > > > > -
> > > > > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------
> > > > > > > > > >
> > > > > > > > > > Run, rabbit run.
> > > > > > > > > > Dig that hole, forget the sun,
> > > > > > > > > > And when at last the work is done
> > > > > > > > > > Don't sit down it's time to dig another
one.
> > > > > > > > > >
> > > > > > > > > >
> > > > _________________________________________________________________
> > > > > > > > > > Stay in touch with absent friends - get
MSN Messenger
> > > > > > > > > > http://www.msn.co.uk/messenger
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > > --------------------------------------------------------------------
> > > > > > -
> > > > > > > > > > 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
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message