RE: RE: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[Eduardo Guadalupe]

https://central.sonatype.com/artifact/org.apache.commons/commons-fileupload2/2.0.0-M1

On 2023/07/21 16:27:33 je...@mercedes-benz.com.INVALID wrote:
> Hello Gary,
>
> does that include Milestone releases as well or not?
>
> Regards
>   Jeremias
>
> -Original Message-
> From: Gary Gregory 
> Sent: Friday, 21 July 2023 17:08
> To: Commons Developers List 
> Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
>
> [**EXTERNAL E-MAIL**]
>
> All releases go to MC.
>
> Gary
>
> On Fri, Jul 21, 2023, 10:47 
> wrote:
>
> > Hello Gary,
> >
> > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven
> > Central as well?
> > That would make the testing easier.
> >
> > Regards
> >   Jeremias
> >
> > -Original Message-
> > From: Gary Gregory 
> > Sent: Friday, 21 July 2023 15:43
> > To: Commons Developers List 
> > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
> >
> > [**EXTERNAL E-MAIL**]
> >
> > This is a milestone release because we might not have the gotten the
> > API just right for a major release. This gives up the opportunity to
> > receive feedback and adjust the API for what will be 2.0.0. All lot of
> > folks will not try a snapshot build, which then leaves us in the dark.
> >
> > WRT to the missing data, I'll adjust that but it won't show up on the
> > site until the next version is published.
> >
> > HTH,
> > Gary
> >
> >
> > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger 
> > wrote:
> >
> > > Hi Gary!
> > >
> > > Thank you for this release and thanks to all the diligent
contributors!
> > > Having a new release with new features, cleaned-up interfaces, and
> > > updated dependencies is much appreciated!
> > > I also learned from the recent discussion whether FileUpload is
> > > still a good idea [1].
> > >
> > >  > The Apache Commons FileUpload Parent team is pleased to announce
> > > the  > release of Apache Commons FileUpload Parent 2.0.0-M1.
> > >
> > > Why is the release called "-M1" and not plain 2.0.0?
> > >
> > > When I follow
> > >   https://commons.apache.org/proper/commons-fileupload/
> > > the top release entry in the Downloading section for version 2.0.0
> > > lacks the release date.
> > >
> > > Kind regards,
> > > Christoph
> > >
> > >
> > > [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9
> > >
> > > 
> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> > If you are not the addressee, please inform us immediately that you
> > have received this e-mail by mistake, and delete it. We thank you for
> > your support.
> >
> >
>
> If you are not the addressee, please inform us immediately that you have
received this e-mail by mistake, and delete it. We thank you for your
support.
>
>

Re: [FileUpload] Major version 2

[Glavo]

+1 for Java 17.

Glavo

On Fri, Jul 21, 2023 at 10:18 PM Gary Gregory 
wrote:

> Now that 2.0.0-M1 is out the door, let's talk about Java platform
> requirements.
>
> I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not
> 17.
>
> If you are going to ask why, see my reply in the [pool] thread
> (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [FileUpload] Major version 2

[Romain Manni-Bucau]

+1 for java 17, requirement is java 21 as the new requirement for
jakartaee, anything in between is already migrated or will not be migrated
so 17 seems already low to me.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 21 juil. 2023 à 18:28, Richard Zowalla  a
écrit :

> From a spec view:
>
> Baseline for Jakarta EE 10 would be Java 11. Jakarta EE 9 is still Java 8
> (namespace Change only)
>
> Gruß
> Richard
>
>
> Am 21. Juli 2023 18:10:48 MESZ schrieb Elliotte Rusty Harold <
> elh...@ibiblio.org>:
> >Absolutely not Java 17. There are really big companies still on Java
> >11, and I have no idea how many smaller ones.
> >
> >There are many still on Java 8.
> >
> >Unless you actually **need** something from Java 11+ I wouldn't bother.
> >
> >On Fri, Jul 21, 2023 at 10:18 AM Gary Gregory 
> wrote:
> >>
> >> Now that 2.0.0-M1 is out the door, let's talk about Java platform
> requirements.
> >>
> >> I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if
> not 17.
> >>
> >> If you are going to ask why, see my reply in the [pool] thread
> >> (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
> >>
> >> Gary
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >
> >--
> >Elliotte Rusty Harold
> >elh...@ibiblio.org
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [pool] Another source compatibility break in 2.x

[Phil Steitz]

On Fri, Jul 21, 2023 at 5:17 AM Elliotte Rusty Harold 
wrote:

> On Thu, Jul 20, 2023 at 8:27 PM Phil Steitz  wrote:
> >
> > We have a minor source compat break still in 2.x
> >
> > The change to have BaseGenericObjectPool implement Autocloseable forced
> > addition of an abstract close method.  Technically, that could break
> > subclass implementations that don't implement close.  I see three options
> > here.  Maybe someone else has a better idea.
> >
> > 0) Ignore the problem.  Unlikely to actually impact anyone.
> > 1) Add a default implementation that
> > a) throws UnsupportedOperationException
> > b) No-Ops
> > c) does 
> > 2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...)
> instead
> > 3) Revert the change for 2.x
> >
>
> Weak vote for 1b. That maintains source compatibility and the API you
> want and doesn't seem likely to cause problems in any situation I can
> think of.
>

Thanks, Elliot.  The use case that I was worried about there was someone
assumes autoclosing for a pool that has not implemented close but uses some
other thing (like clear) to clean up resources and the no-op is
misleading.  I would rather get an exception in that case.  But it is kind
of far-fetched, so I am OK with the no-op default.

Phil

>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [FileUpload] Major version 2

[Richard Zowalla]

From a spec view:

Baseline for Jakarta EE 10 would be Java 11. Jakarta EE 9 is still Java 8 
(namespace Change only)

Gruß
Richard 


Am 21. Juli 2023 18:10:48 MESZ schrieb Elliotte Rusty Harold 
:
>Absolutely not Java 17. There are really big companies still on Java
>11, and I have no idea how many smaller ones.
>
>There are many still on Java 8.
>
>Unless you actually **need** something from Java 11+ I wouldn't bother.
>
>On Fri, Jul 21, 2023 at 10:18 AM Gary Gregory  wrote:
>>
>> Now that 2.0.0-M1 is out the door, let's talk about Java platform 
>> requirements.
>>
>> I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.
>>
>> If you are going to ask why, see my reply in the [pool] thread
>> (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
>>
>> Gary
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>-- 
>Elliotte Rusty Harold
>elh...@ibiblio.org
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>

RE: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[jeremias.eppler]

Hello Gary,

does that include Milestone releases as well or not?

Regards
  Jeremias

-Original Message-
From: Gary Gregory 
Sent: Friday, 21 July 2023 17:08
To: Commons Developers List 
Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[**EXTERNAL E-MAIL**]

All releases go to MC.

Gary

On Fri, Jul 21, 2023, 10:47 
wrote:

> Hello Gary,
>
> are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven
> Central as well?
> That would make the testing easier.
>
> Regards
>   Jeremias
>
> -Original Message-
> From: Gary Gregory 
> Sent: Friday, 21 July 2023 15:43
> To: Commons Developers List 
> Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
>
> [**EXTERNAL E-MAIL**]
>
> This is a milestone release because we might not have the gotten the
> API just right for a major release. This gives up the opportunity to
> receive feedback and adjust the API for what will be 2.0.0. All lot of
> folks will not try a snapshot build, which then leaves us in the dark.
>
> WRT to the missing data, I'll adjust that but it won't show up on the
> site until the next version is published.
>
> HTH,
> Gary
>
>
> On Fri, Jul 21, 2023, 08:53 Christoph Grüninger 
> wrote:
>
> > Hi Gary!
> >
> > Thank you for this release and thanks to all the diligent contributors!
> > Having a new release with new features, cleaned-up interfaces, and
> > updated dependencies is much appreciated!
> > I also learned from the recent discussion whether FileUpload is
> > still a good idea [1].
> >
> >  > The Apache Commons FileUpload Parent team is pleased to announce
> > the  > release of Apache Commons FileUpload Parent 2.0.0-M1.
> >
> > Why is the release called "-M1" and not plain 2.0.0?
> >
> > When I follow
> >   https://commons.apache.org/proper/commons-fileupload/
> > the top release entry in the Downloading section for version 2.0.0
> > lacks the release date.
> >
> > Kind regards,
> > Christoph
> >
> >
> > [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> If you are not the addressee, please inform us immediately that you
> have received this e-mail by mistake, and delete it. We thank you for
> your support.
>
>

If you are not the addressee, please inform us immediately that you have 
received this e-mail by mistake, and delete it. We thank you for your support.

Re: [FileUpload] Major version 2

[Elliotte Rusty Harold]

Absolutely not Java 17. There are really big companies still on Java
11, and I have no idea how many smaller ones.

There are many still on Java 8.

Unless you actually **need** something from Java 11+ I wouldn't bother.

On Fri, Jul 21, 2023 at 10:18 AM Gary Gregory  wrote:
>
> Now that 2.0.0-M1 is out the door, let's talk about Java platform 
> requirements.
>
> I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.
>
> If you are going to ask why, see my reply in the [pool] thread
> (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
>
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[Gary Gregory]

All releases go to MC.

Gary

On Fri, Jul 21, 2023, 10:47 
wrote:

> Hello Gary,
>
> are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven Central
> as well?
> That would make the testing easier.
>
> Regards
>   Jeremias
>
> -Original Message-
> From: Gary Gregory 
> Sent: Friday, 21 July 2023 15:43
> To: Commons Developers List 
> Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
>
> [**EXTERNAL E-MAIL**]
>
> This is a milestone release because we might not have the gotten the API
> just right for a major release. This gives up the opportunity to receive
> feedback and adjust the API for what will be 2.0.0. All lot of folks will
> not try a snapshot build, which then leaves us in the dark.
>
> WRT to the missing data, I'll adjust that but it won't show up on the site
> until the next version is published.
>
> HTH,
> Gary
>
>
> On Fri, Jul 21, 2023, 08:53 Christoph Grüninger 
> wrote:
>
> > Hi Gary!
> >
> > Thank you for this release and thanks to all the diligent contributors!
> > Having a new release with new features, cleaned-up interfaces, and
> > updated dependencies is much appreciated!
> > I also learned from the recent discussion whether FileUpload is still
> > a good idea [1].
> >
> >  > The Apache Commons FileUpload Parent team is pleased to announce
> > the  > release of Apache Commons FileUpload Parent 2.0.0-M1.
> >
> > Why is the release called "-M1" and not plain 2.0.0?
> >
> > When I follow
> >   https://commons.apache.org/proper/commons-fileupload/
> > the top release entry in the Downloading section for version 2.0.0
> > lacks the release date.
> >
> > Kind regards,
> > Christoph
> >
> >
> > [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> If you are not the addressee, please inform us immediately that you have
> received this e-mail by mistake, and delete it. We thank you for your
> support.
>
>

Re: [FileUpload] Major version 2

[Maxim Solodovnik]

+1 for java17 :)

On Fri, 21 Jul 2023 at 21:52, Mark Thomas  wrote:
>
> On 21/07/2023 16:18, Gary Gregory wrote:
> > Now that 2.0.0-M1 is out the door, let's talk about Java platform 
> > requirements.
> >
> > I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.
>
> +1 for Java 17
>
> Mark
>
>
> >
> > If you are going to ask why, see my reply in the [pool] thread
> > (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
> >
> > Gary
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


-- 
Best regards,
Maxim

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [FileUpload] Major version 2

[Mark Thomas]

On 21/07/2023 16:18, Gary Gregory wrote:

Now that 2.0.0-M1 is out the door, let's talk about Java platform requirements.

I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.


+1 for Java 17

Mark




If you are going to ask why, see my reply in the [pool] thread
(https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[jeremias.eppler]

Hello Gary,

are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven Central as 
well?
That would make the testing easier.

Regards
  Jeremias

-Original Message-
From: Gary Gregory 
Sent: Friday, 21 July 2023 15:43
To: Commons Developers List 
Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[**EXTERNAL E-MAIL**]

This is a milestone release because we might not have the gotten the API just 
right for a major release. This gives up the opportunity to receive feedback 
and adjust the API for what will be 2.0.0. All lot of folks will not try a 
snapshot build, which then leaves us in the dark.

WRT to the missing data, I'll adjust that but it won't show up on the site 
until the next version is published.

HTH,
Gary


On Fri, Jul 21, 2023, 08:53 Christoph Grüninger  wrote:

> Hi Gary!
>
> Thank you for this release and thanks to all the diligent contributors!
> Having a new release with new features, cleaned-up interfaces, and
> updated dependencies is much appreciated!
> I also learned from the recent discussion whether FileUpload is still
> a good idea [1].
>
>  > The Apache Commons FileUpload Parent team is pleased to announce
> the  > release of Apache Commons FileUpload Parent 2.0.0-M1.
>
> Why is the release called "-M1" and not plain 2.0.0?
>
> When I follow
>   https://commons.apache.org/proper/commons-fileupload/
> the top release entry in the Downloading section for version 2.0.0
> lacks the release date.
>
> Kind regards,
> Christoph
>
>
> [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

If you are not the addressee, please inform us immediately that you have 
received this e-mail by mistake, and delete it. We thank you for your support.

RE: [FileUpload] Major version 2

[jeremias.eppler]

Hello Gary,

Java 11 should be fine.

We need FileUpload 2.0, because we want to upgrade to Spring Boot 3.0 which 
requires Java 17 and uses JakartaEE:
https://github.com/mercedes-benz/sechub/issues/797

Regards
  Jeremias


-Original Message-
From: Gary Gregory 
Sent: Friday, 21 July 2023 16:18
To: Commons Developers List 
Subject: [FileUpload] Major version 2

[**EXTERNAL E-MAIL**]

Now that 2.0.0-M1 is out the door, let's talk about Java platform requirements.

I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.

If you are going to ask why, see my reply in the [pool] thread
(https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


If you are not the addressee, please inform us immediately that you have 
received this e-mail by mistake, and delete it. We thank you for your support.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[FileUpload] Major version 2

[Gary Gregory]

Now that 2.0.0-M1 is out the door, let's talk about Java platform requirements.

I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not 17.

If you are going to ask why, see my reply in the [pool] thread
(https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[Gary Gregory]

This is a milestone release because we might not have the gotten the API
just right for a major release. This gives up the opportunity to receive
feedback and adjust the API for what will be 2.0.0. All lot of folks will
not try a snapshot build, which then leaves us in the dark.

WRT to the missing data, I'll adjust that but it won't show up on the site
until the next version is published.

HTH,
Gary


On Fri, Jul 21, 2023, 08:53 Christoph Grüninger  wrote:

> Hi Gary!
>
> Thank you for this release and thanks to all the diligent contributors!
> Having a new release with new features, cleaned-up interfaces, and
> updated dependencies is much appreciated!
> I also learned from the recent discussion whether FileUpload is still a
> good idea [1].
>
>  > The Apache Commons FileUpload Parent team is pleased to announce the
>  > release of Apache Commons FileUpload Parent 2.0.0-M1.
>
> Why is the release called "-M1" and not plain 2.0.0?
>
> When I follow
>   https://commons.apache.org/proper/commons-fileupload/
> the top release entry in the Downloading section for version 2.0.0 lacks
> the release date.
>
> Kind regards,
> Christoph
>
>
> [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1

[Christoph Grüninger]

Hi Gary!

Thank you for this release and thanks to all the diligent contributors! 
Having a new release with new features, cleaned-up interfaces, and 
updated dependencies is much appreciated!
I also learned from the recent discussion whether FileUpload is still a 
good idea [1].


> The Apache Commons FileUpload Parent team is pleased to announce the
> release of Apache Commons FileUpload Parent 2.0.0-M1.

Why is the release called "-M1" and not plain 2.0.0?

When I follow
 https://commons.apache.org/proper/commons-fileupload/
the top release entry in the Downloading section for version 2.0.0 lacks 
the release date.


Kind regards,
Christoph


[1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [pool] Another source compatibility break in 2.x

[Gary Gregory]

1a or 1b seem fine and least intrusive.

Gary

On Thu, Jul 20, 2023, 20:28 Phil Steitz  wrote:

> We have a minor source compat break still in 2.x
>
> The change to have BaseGenericObjectPool implement Autocloseable forced
> addition of an abstract close method.  Technically, that could break
> subclass implementations that don't implement close.  I see three options
> here.  Maybe someone else has a better idea.
>
> 0) Ignore the problem.  Unlikely to actually impact anyone.
> 1) Add a default implementation that
> a) throws UnsupportedOperationException
> b) No-Ops
> c) does 
> 2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...) instead
> 3) Revert the change for 2.x
>
> I am leaning toward 1a but I would also be OK with 0.  I don't much like 2
> and I really don't like 3.  Option 2 could be remediated in pool 3, so the
> ugliness would be temporary.   Any better ideas?
>
> Phil
>

Re: [pool] Another source compatibility break in 2.x

[Elliotte Rusty Harold]

On Thu, Jul 20, 2023 at 8:27 PM Phil Steitz  wrote:
>
> We have a minor source compat break still in 2.x
>
> The change to have BaseGenericObjectPool implement Autocloseable forced
> addition of an abstract close method.  Technically, that could break
> subclass implementations that don't implement close.  I see three options
> here.  Maybe someone else has a better idea.
>
> 0) Ignore the problem.  Unlikely to actually impact anyone.
> 1) Add a default implementation that
> a) throws UnsupportedOperationException
> b) No-Ops
> c) does 
> 2) Add Implements Autocloseable to the subclasses (GOP, GKOP, ...) instead
> 3) Revert the change for 2.x
>

Weak vote for 1b. That maintains source compatibility and the API you
want and doesn't seem likely to cause problems in any situation I can
think of.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org