Re: Apache Commons CLI Issue CLI-317

[Sruteesh Kumar]

Hi,

I replied to your comment in the ticket. Kindly look into it once

Thank you,
Sruteesh Kumar

 Original Message 
On 16 Aug 2023, 3:13 am, Gary Gregory wrote:

> Hi, Please see my comment in the ticket. Gary On Sun, Aug 13, 2023, 9:04 AM 
> Sruteesh Kumar  wrote: > > Hi Gary, the unit test is already provided as a 
> comment in the JIRA issue > CLI-317. Go through the following link for the 
> same > > > 
> https://issues.apache.org/jira/projects/CLI/issues/CLI-317?filter=allopenissues
>  > > > --- Original Message --- > On Sunday, August 13th, 2023 at 
> 5:51 PM, Gary Gregory garydgreg...@gmail.com> wrote: > > > > Hello, > > > > 
> It would be helpful to understand the upshot of this if you could express > > 
> your explanation as a failing unit test. > > > > TY, > > Gary > > > > On Sat, 
> Aug 12, 2023, 1:44 AM Sruteesh Kumar > > sruteesh@protonmail.com.invalid 
> wrote: > > > > > In the DefaultParser class, we are using handleOption method 
> which is > > > defined as following > > > > > > 
> privatevoidhandleOption(Optionoption)throwsParseException{ > > > > > > // 
> check the previous option before handling the next one > > > > > > 
> checkRequiredArgs(); > > > > > > option=(Option)option.clone(); > > > > > > 
> updateRequiredOptions(option); > > > > > > cmd.addOption(option); > > > > > > 
> if(option.hasArg()){ > > > > > > currentOption=option; > > > > > > }else{ > > 
> > > > > currentOption=null; > > > > > > } > > > > > > } > > > > > > 
> option.hasArg() returns true only when argCount is greater than 0 or is > > > 
> UNLIMITED_VALUES. > > > But, if our option is built with optionalArg(true), 
> then argCount seems > > > UNINITIALIZED. > > > So, if our option is built 
> with optionalArg(true), handleOption(option) > > > sets currentOption to null 
> which we aren't handling at DefaultParser > class > > > LIne 484 > > 
> - > To 
> unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional 
> commands, e-mail: dev-h...@commons.apache.org > >

Re: Apache Commons CLI Issue CLI-317

[Gary Gregory]

Hi,

Please see my comment in the ticket.

Gary

On Sun, Aug 13, 2023, 9:04 AM Sruteesh Kumar
 wrote:

>
> Hi Gary, the unit test is already provided as a comment in the JIRA issue
> CLI-317. Go through the following link for the same
>
>
> https://issues.apache.org/jira/projects/CLI/issues/CLI-317?filter=allopenissues
>
>
> --- Original Message ---
> On Sunday, August 13th, 2023 at 5:51 PM, Gary Gregory <
> garydgreg...@gmail.com> wrote:
>
>
> > Hello,
> >
> > It would be helpful to understand the upshot of this if you could express
> > your explanation as a failing unit test.
> >
> > TY,
> > Gary
> >
> > On Sat, Aug 12, 2023, 1:44 AM Sruteesh Kumar
> > sruteesh@protonmail.com.invalid wrote:
> >
> > > In the DefaultParser class, we are using handleOption method which is
> > > defined as following
> > >
> > > privatevoidhandleOption(Optionoption)throwsParseException{
> > >
> > > // check the previous option before handling the next one
> > >
> > > checkRequiredArgs();
> > >
> > > option=(Option)option.clone();
> > >
> > > updateRequiredOptions(option);
> > >
> > > cmd.addOption(option);
> > >
> > > if(option.hasArg()){
> > >
> > > currentOption=option;
> > >
> > > }else{
> > >
> > > currentOption=null;
> > >
> > > }
> > >
> > > }
> > >
> > > option.hasArg() returns true only when argCount is greater than 0 or is
> > > UNLIMITED_VALUES.
> > > But, if our option is built with optionalArg(true), then argCount seems
> > > UNINITIALIZED.
> > > So, if our option is built with optionalArg(true), handleOption(option)
> > > sets currentOption to null which we aren't handling at DefaultParser
> class
> > > LIne 484
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [FileUpload] Major version 2

[Gary Gregory]

Right now, I plan on doing milestone releases until we are OK with the API.
I plan on the next release being 2.0.0-M2 and requiring Java 11, as we have
now in git master. The majority of opinions in this thread has been for
Java 17, so I'd like to go with Java 17 for 2.0.0-M3 and see how that goes,
but we're not there yet ;-)

Gary


On Mon, Aug 14, 2023, 4:53 PM Jim Showalter 
wrote:

> Good point. But then why stop at 11? Spring ripped the bandage off in their
> latest by requiring 17.
>
> On Mon, Aug 14, 2023, 1:36 PM Gary Gregory  wrote:
>
> > Based on my experience, once an app is at legacy status in an enterprise,
> > your are not allowed to touch it and even less update its dependencies
> > (except for critical security updates). A new major version of a library
> is
> > out of scope anyway and especially in this case since it requires source
> > updates.
> >
> > Gary
> >
> > On Mon, Aug 14, 2023, 4:30 PM Jim Showalter  >
> > wrote:
> >
> > > Libraries should be kept on the oldest safe (LTS) version forever,
> IMHO,
> > to
> > > avoid stranding legacy services.
> > >
> > > On Mon, Aug 14, 2023, 9:15 AM James Reeves 
> > > wrote:
> > >
> > > > I'd very much prefer 11, unless 17 is necessary. I have a library
> that
> > > > currently depends on FileUpload 1.5, and only requires Java 8. For
> > > various
> > > > reasons, I've been very conservative with the required Java version.
> I
> > > was
> > > > already planning to make the jump to Java 11, so if FileUpload 2.0.0
> > > moves
> > > > to Java 11 that doesn't affect me; but if it moves to 17, then I'd
> have
> > > to
> > > > either move to 17 as well, or think about temporarily forking
> > FileUpload.
> > > >
> > > > On Mon, 24 Jul 2023, at 9:26 AM, Eugene Grybinnyk wrote:
> > > > > +1 for 17
> > > > >
> > > > > On Sat, Jul 22, 2023 at 12:43 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le sam. 22 juil. 2023 à 11:00, Gary Gregory <
> > garydgreg...@gmail.com>
> > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Java 21 is not GA.
> > > > > > >
> > > > > >
> > > > > > FU neither and calendar looks like it can match.
> > > > > >
> > > > > > Main pro being to move to a more reactive programming at some
> point
> > > > which
> > > > > > could justify a 2.0 IMHO.
> > > > > >
> > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Sat, Jul 22, 2023, 04:48 Jean-Louis MONTEIRO <
> > > jeano...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'd say compile low and run high.
> > > > > > > > So unless there is really something you need from Java 17 or
> > 21,
> > > > why
> > > > > > not
> > > > > > > > compiling lower?
> > > > > > > >
> > > > > > > > It would open the release to be used more widely in my
> opinion.
> > > > > > > >
> > > > > > > > Now I agree that making sure it runs on java 17 and 21 at
> least
> > > is
> > > > > > great.
> > > > > > > >
> > > > > > > > Le ven. 21 juil. 2023, 18:40, Glavo  a
> > > écrit
> > > > :
> > > > > > > >
> > > > > > > > > +1 for Java 17.
> > > > > > > > >
> > > > > > > > > Glavo
> > > > > > > > >
> > > > > > > > > On Fri, Jul 21, 2023 at 10:18 PM Gary Gregory <
> > > > > > garydgreg...@gmail.com>
> > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > [image: Backbase] *Eugene Grybinnyk*
> > > > > Backend Developer · R Business Banking · Amsterdam
> > > > > +31 (0) 62 992 3609
> > > > >
> > > >
> > > > --
> > > > James Reeves
> > > >
> > > >
> > >
> >
>

Re: [IO] Unintuitive behavior in BoundedInputStream.onMaxLength

[Gary Gregory]

Better documentation is quite reasonable :-) feel free to submit a PR

Thank you!
Gary

On Tue, Aug 15, 2023, 10:13 AM James Reeves  wrote:

> I was looking into a bug in FileUpload 2.0.0-M1 and tracked it down to a
> misuse of BoundedInputStream.onMaxLength. The reason I'm sending this email
> before submitting a patch to FileUpload is that I believe this behavior is
> unexpected enough to warrant a little extra in the onMaxLength docstring.
>
> The onMaxLength method's docs say:
>
> > A caller has caused a request that would cross the {@code maxLength}
> boundary.
>
> This is correct, but it may not be immediately obvious that checking an
> EOF counts as crossing the boundary. This means that onMaxLength will
> trigger if the length of the stream is *equal* to the maxLength.
>
> This is unavoidable without a buffer, as you always need to read one more
> byte to determine whether the stream has ended. If you have a stream of 6
> bytes, you need to read 7 in order to check whether the last byte is an EOF
> or not.
>
> So perhaps the documentation could be modified to something like:
>
> > A caller has caused a request that would cross the {@code maxLength}
> boundary. This includes reads that return end of stream. Therefore streams
> whose length is exactly equal to maxLength will also trigger this method.
>
> --
> James Reeves

[IO] Unintuitive behavior in BoundedInputStream.onMaxLength

[James Reeves]

I was looking into a bug in FileUpload 2.0.0-M1 and tracked it down to a misuse 
of BoundedInputStream.onMaxLength. The reason I'm sending this email before 
submitting a patch to FileUpload is that I believe this behavior is unexpected 
enough to warrant a little extra in the onMaxLength docstring.

The onMaxLength method's docs say:

> A caller has caused a request that would cross the {@code maxLength} boundary.

This is correct, but it may not be immediately obvious that checking an EOF 
counts as crossing the boundary. This means that onMaxLength will trigger if 
the length of the stream is *equal* to the maxLength.

This is unavoidable without a buffer, as you always need to read one more byte 
to determine whether the stream has ended. If you have a stream of 6 bytes, you 
need to read 7 in order to check whether the last byte is an EOF or not.

So perhaps the documentation could be modified to something like:

> A caller has caused a request that would cross the {@code maxLength} 
> boundary. This includes reads that return end of stream. Therefore streams 
> whose length is exactly equal to maxLength will also trigger this method.

--
James Reeves

Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others

[Daniel Watson]

I've incorporated some of the recommendations from this thread into the
Case api. Have a couple additional things to ask for thoughts on...

1) The current caseutils is just in org.apache.commons.text, but given that
this is multiple classes, I put the code into
"org.apache.commons.text.cases" ("case" is reserved). Thoughts?
2) Although I don't propose removing/deprecating the existing CaseUtils,
does it make sense to try and test against the use cases that overlap i.e.
validating that they produce the same output? Or is that just an
unnecessary link?

- Dan

On Fri, Aug 11, 2023 at 11:31 AM Daniel Watson  wrote:

> If no instance of Thing1Case can be reconfigured, then that holds true,
> right? The fact that it extends something like DelimitedCase doesn't break
> the spec I wouldn't think?
>
>
>
> On Fri, Aug 11, 2023, 11:23 AM Gary Gregory 
> wrote:
>
>> Hm, I too, would expect Thing1Case to mean one thing and one thing only...
>> hence this specification exercise 
>>
>> Gary
>>
>> On Wed, Aug 9, 2023, 9:52 PM Daniel Watson  wrote:
>>
>> > I would think it's possible to hide that "configuration" from the user
>> such
>> > that the implementation can only be reconfigured via extension. But I'm
>> not
>> > in love with the configurable base class either way. It was convenient
>> to
>> > have the common functionality in one place, but it's not a big deal to
>> > handle that differently.
>> >
>> > The tradeoff in having the Cases be pure functions is that it makes it
>> more
>> > difficult for a user to extend them with additional functionality. And
>> to
>> > me the need for extension is apparent even when just looking at the 4
>> basic
>> > cases. Two of them are character delimited, and 2 of them are uppercase
>> > delimited. There's two bits of shared functionality just in the 4 most
>> > basic cases.
>> >
>> > Back to the exception topic, I don't think the tokens "my" "component"
>> and
>> > "1" can be formatted in PascalCase in a way that they could be parsed
>> back
>> > out into 3 tokens. So the question is less about whether it's possible
>> to
>> > format them and more about whether the API should format output that
>> cannot
>> > be parsed back into the same input. I think it makes sense to enforce
>> that
>> > consistency, or at the very least allow the user to enable it?
>> >
>> >
>> >
>> >
>> > On Wed, Aug 9, 2023, 9:14 PM Elliotte Rusty Harold 
>> > wrote:
>> >
>> > > On Wed, Aug 9, 2023 at 11:36 PM Daniel Watson 
>> > > wrote:
>> > > >
>> > > > Meant to add...
>> > > >
>> > > > The reason I would favor exceptions is that the underlying
>> > implementation
>> > > > can be easily customized. If the user needs to allow non
>> alphanumeric
>> > > > characters there is a boolean flag in the underlying abstract class
>> > > > (AbstractConfigurableCase) that will simply turn that validation
>> off.
>> > >
>> > > This is another point, but customizability is a bug, not a feature. I
>> > > don't want to guess what the method might be doing based on what flag
>> > > was set where. I want camel case to mean one thing and one thing only.
>> > > Ditto snake case, pascal case, and any other formats. Possibly there's
>> > > a reason to add additional subclasses, but the
>> > > CamelCase/SnakeCase/KebabCase classes should not emit different
>> > > strings depending on how they're configured. The public API should be
>> > > a pure function, not an object.
>> > >
>> > > --
>> > > 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] Concrete FileUpload class

[James Reeves]

Will do!

On Mon, 14 Aug 2023, at 6:09 PM, Gary Gregory wrote:
> Hi James,
> 
> Thank you for your email. I think this should be two PRs against git
> master, with unit tests of course ;-)
> 
> HTH,
> Gary
> 
> On Mon, Aug 14, 2023, 12:50 PM James Reeves  wrote:
> 
> > Hello!
> >
> > I currently maintain the HTTP server library (Ring) for the Clojure
> > programming language, which is a functional lisp for the JVM. In order to
> > parse multipart requests, I lean on FileUpload. In the past that's been
> > somewhat problematic, as 1.x had a hard dependency on Java servlets, so I
> > was happy to see that for 2.0.0, the core module of FileUpload has no such
> > dependencies.
> >
> > However, one element of Java that Clojure handles somewhat poorly are
> > abstract classes. It's nothing insurmountable,  and I understand that
> > FileUpload is a Java library first and foremost, but it would help if there
> > was an implementation of AbstractFileUpload that operated directly on the
> > RequestContext.
> >
> > To provide some context, at a high level, my usage is as follow:
> >
> > 1. Create an implementation of AbstractFileUpload, and stub out the
> > abstract methods with dummy code.
> > 2. Set the progressListener and fileSizeMax options.
> > 3. Create a RequestContext from the Clojure request map.
> > 4. Call getItemIterator and use the FileItemInputIterator to iterate over
> > the FileItemInput objects.
> > 5. Convert those objects into a Clojure-friendly structure.
> >
> > Obviously this means I'm only using a small slice of the API, and probably
> > in a rather unusual way compared to most users. However, I'm wondering if
> > there's some way of avoiding needing to create a stubbed out
> > AbstractFileUpload, as I don't actually need either of the abstract methods.
> >
> > Also, I'm not sure whether this deserves its own post, but I found that
> > fileSizeMax may have an off-by-one error. In my tests for FileUpload 1.5,
> > if I have a fileSizeMax of 9, and send a multipart item that is 9 bytes, it
> > passes without an exception. However, in 2.0.0, I needed to increase the
> > fileSizeMax to 10 in order to send the same 9 bytes.
> >
> > --
> > James Reeves
> >
> >
> 

--
James Reeves