[jira] [Commented] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351994#comment-16351994 ] Zhenliang Su commented on NET-654: -- I think the problem is, when I send a \r in my code, TelnetClient should send '\r\n' together. > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, sendb.png, sendcr.png, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351993#comment-16351993 ] Zhenliang Su edited comment on NET-654 at 2/5/18 2:26 AM: -- My OS is Microsoft windows. My code is Main.java [^Main.java] ^The net traffic I captured is TelnetClient.pcap^ ^[^telnetClient.pcap]^ ^!sendcr.png!^ ^!sendb.png!^ was (Author: suzl): My OS is microsoft windows. My code is Main.java [^Main.java] ^The net traffic I capturedis TelnetClient.pcap^ ^[^telnetClient.pcap]^ ^!sendcr.png!^ ^!sendb.png!^ > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, sendb.png, sendcr.png, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenliang Su updated NET-654: - Attachment: sendcr.png > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, sendb.png, sendcr.png, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351993#comment-16351993 ] Zhenliang Su commented on NET-654: -- My OS is microsoft windows. My code is Main.java [^Main.java] ^The net traffic I capturedis TelnetClient.pcap^ ^[^telnetClient.pcap]^ ^!sendcr.png!^ ^!sendb.png!^ > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, sendb.png, sendcr.png, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenliang Su updated NET-654: - Attachment: sendb.png > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, sendb.png, sendcr.png, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenliang Su updated NET-654: - Attachment: Main.java > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NET-654) auto add a LF before a command
[ https://issues.apache.org/jira/browse/NET-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenliang Su updated NET-654: - Attachment: telnetClient.pcap > auto add a LF before a command > -- > > Key: NET-654 > URL: https://issues.apache.org/jira/browse/NET-654 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.6 > Environment: all environment >Reporter: Zhenliang Su >Priority: Minor > Attachments: Main.java, telnetClient.pcap > > > I use TelnetClient to connect to my H3C router. When I type the first > command, it's ok. When I type the second command, TelnetClient automatically > add a LF character before my second command, i.e. send an empty command > before my second command. > I review the source code of TelnetOutputStream.java, in function write(int > ch). When I type the first character of my second command, variable > __lastWasCR is true, variable __convertCRtoCRLF is true, and because I set > nothing of TelnetOption.BINARY, __client._requestedWont(TelnetOption.BINARY) > also returns true。 lead to cause my issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1449) PolygonsSet.getBarycenter() returns incorrect value for empty region
[
https://issues.apache.org/jira/browse/MATH-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351970#comment-16351970
]
Matt Juntunen commented on MATH-1449:
-
Yes, I suppose it does look kind of strange with the tolerance. I didn't use
Double.isInfinite() because I wanted to distinguish between positive and
negative infinity. The tolerance value is just there to keep Assert happy. I
could rewrite it as
{code:java}
Assert.assertTrue(Double.POSITIVE_INFINITY == poly.getSize());
{code}
to make it clearer if needed.
Also, I disagree that the boolean statements read better with the
assertTrue/False methods in this case. When asserting a method return value, I
prefer to have the expected return value listed explicitly rather than encoded
in the name of the assertion method. I think it stands out better that way.
But, this is just a preference thing and really makes no difference otherwise.
Let me know if you'd like me to make either of these changes. Note that I'm
pretty sure I used both of the syntaxes you mentioned above all over my last
batch of unit test changes, so, if I do change these, I should probably update
the other tests as well to match.
> PolygonsSet.getBarycenter() returns incorrect value for empty region
>
>
> Key: MATH-1449
> URL: https://issues.apache.org/jira/browse/MATH-1449
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.6
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 4.0
>
>
> The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method
> returns the point (0, 0) when the region is empty. It should return (NaN,
> NaN) since the barycenter does not exist. This is the behavior of
> IntervalsSet and PolyhedronsSet.
>
> Pull request: https://github.com/apache/commons-math/pull/80
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-67) Add "pow" to "Fraction"
Gilles created NUMBERS-67:
-
Summary: Add "pow" to "Fraction"
Key: NUMBERS-67
URL: https://issues.apache.org/jira/browse/NUMBERS-67
Project: Commons Numbers
Issue Type: New Feature
Components: fraction
Reporter: Gilles
Assignee: Gilles
Fix For: 1.0
Attachments: pow.patch
Add a method {{pow(int n)}}.
A similar method exists in class {{BigFraction}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1449) PolygonsSet.getBarycenter() returns incorrect value for empty region
[
https://issues.apache.org/jira/browse/MATH-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351927#comment-16351927
]
Gilles commented on MATH-1449:
--
In the check
{code:java}
Assert.assertEquals(Double.POSITIVE_INFINITY, poly.getSize(), 1e-10);
{code}
using a tolerance looks a bit strange. Shouldn't it rather be
{code:java}
Assert.assertTrue(Double.isInfinite(poly.getSize()));
{code}
?
Also, statements such as
{code:java}
Assert.assertEquals(false, poly.isEmpty());
Assert.assertEquals(true, poly.isFull());
{code}
would read better as
{code:java}
Assert.assertFalse(poly.isEmpty());
Assert.assertTrue(poly.isFull());
{code}
> PolygonsSet.getBarycenter() returns incorrect value for empty region
>
>
> Key: MATH-1449
> URL: https://issues.apache.org/jira/browse/MATH-1449
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.6
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 4.0
>
>
> The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method
> returns the point (0, 0) when the region is empty. It should return (NaN,
> NaN) since the barycenter does not exist. This is the behavior of
> IntervalsSet and PolyhedronsSet.
>
> Pull request: https://github.com/apache/commons-math/pull/80
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-649) SMB v. 2 / 3 integration based on SMBJ
[ https://issues.apache.org/jira/browse/VFS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351880#comment-16351880 ] Michael commented on VFS-649: - Hi [~bonsu], Thanks for you commits, how can I download a jar with your commits, did you upload it into maven repository? do you know the realise date of vfs 2.3? Thanks for all you effort and work > SMB v. 2 / 3 integration based on SMBJ > -- > > Key: VFS-649 > URL: https://issues.apache.org/jira/browse/VFS-649 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: André Hauenstein >Priority: Minor > Labels: SMBv2 > > Hi, > based on this issue: [https://issues.apache.org/jira/browse/VFS-635] I > created an implementation of [https://github.com/hierynomus/smbj] into vfs 2.2 > I named the provider SMB2, so the scheme I used is also smb2. I dont know if > it's better to rename the existing smb to cifs and use smb for the smb v2+ > implementation. > All the tests from the ProviderTests pass but I had to remove the test > (exclude in pom.xml) because the test needs an external smb share. > Thanks for any feedback or further advice how to proceed with this pr, > André -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1449) PolygonsSet.getBarycenter() returns incorrect value for empty region
[ https://issues.apache.org/jira/browse/MATH-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated MATH-1449: Description: The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method returns the point (0, 0) when the region is empty. It should return (NaN, NaN) since the barycenter does not exist. This is the behavior of IntervalsSet and PolyhedronsSet. Pull request: https://github.com/apache/commons-math/pull/80 was:The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method returns the point (0, 0) when the region is empty. It should return (NaN, NaN) since the barycenter does not exist. This is the behavior of IntervalsSet and PolyhedronsSet. > PolygonsSet.getBarycenter() returns incorrect value for empty region > > > Key: MATH-1449 > URL: https://issues.apache.org/jira/browse/MATH-1449 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.6 >Reporter: Matt Juntunen >Priority: Major > Fix For: 4.0 > > > The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method > returns the point (0, 0) when the region is empty. It should return (NaN, > NaN) since the barycenter does not exist. This is the behavior of > IntervalsSet and PolyhedronsSet. > > Pull request: https://github.com/apache/commons-math/pull/80 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1449) PolygonsSet.getBarycenter() returns incorrect value for empty region
Matt Juntunen created MATH-1449: --- Summary: PolygonsSet.getBarycenter() returns incorrect value for empty region Key: MATH-1449 URL: https://issues.apache.org/jira/browse/MATH-1449 Project: Commons Math Issue Type: Bug Affects Versions: 3.6, 4.0 Reporter: Matt Juntunen Fix For: 4.0 The o.a.c.m.geometry.euclidean.twod.PolygonsSet.getBarycenter() method returns the point (0, 0) when the region is empty. It should return (NaN, NaN) since the barycenter does not exist. This is the behavior of IntervalsSet and PolyhedronsSet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JEXL-250) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-250:
---
Fix Version/s: 3.2
> Safe navigation operator
>
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-252) Allow for interpolated strings to be used in property access operators
[
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-252:
---
Fix Version/s: 3.2
> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Now we have a possibility to access an object property by specifying either
> {code}object.property{code} or {code}object."property"{code} expression, but
> not {code}object.`property`{code} expression. Since interpolated strings can
> be used anywhere in scripts as ordinal strings, it would be logical to allow
> them to be used in property access operators too. It would allow to have the
> property name not necessarily to be a constant, but to be evaluated without
> using the array access operator, since property access operator and array
> access operator could be implemented (overloaded) differently for the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-252) Allow for interpolated strings to be used in property access operators
[
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-252:
---
Assignee: Henri Biestro
> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Now we have a possibility to access an object property by specifying either
> {code}object.property{code} or {code}object."property"{code} expression, but
> not {code}object.`property`{code} expression. Since interpolated strings can
> be used anywhere in scripts as ordinal strings, it would be logical to allow
> them to be used in property access operators too. It would allow to have the
> property name not necessarily to be a constant, but to be evaluated without
> using the array access operator, since property access operator and array
> access operator could be implemented (overloaded) differently for the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-250) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-250:
---
Assignee: Henri Biestro
> Safe navigation operator
>
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-66) Conversion from polar to Cartesian coordinates
Gilles created NUMBERS-66: - Summary: Conversion from polar to Cartesian coordinates Key: NUMBERS-66 URL: https://issues.apache.org/jira/browse/NUMBERS-66 Project: Commons Numbers Issue Type: Improvement Components: complex Reporter: Gilles Factory methods * ofPolar * ofCis could perhaps benefit from optimizing the conversion to Cartesian "re" and "im" fields: cf. [http://eprints.maths.manchester.ac.uk/2235/1/paper.pdf] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VALIDATOR-387) Userinfo without colon should be valid in UrlValidator
[
https://issues.apache.org/jira/browse/VALIDATOR-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351789#comment-16351789
]
ASF GitHub Bot commented on VALIDATOR-387:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-validator/pull/5
> Userinfo without colon should be valid in UrlValidator
> --
>
> Key: VALIDATOR-387
> URL: https://issues.apache.org/jira/browse/VALIDATOR-387
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.5.0
>Reporter: Shumpei Akai
>Priority: Major
> Fix For: 1.6
>
>
> UrlValidator does not accept userinfo without ":".
> The following code returns false.
> {code}
> UrlValidator validator = new UrlValidator();
> validator.isValid("http://u...@www.apache.org:80/path;)
> {code}
> But it should be accepted.
> RFC of URI allows userinfo without colon.
> https://tools.ietf.org/html/rfc3986#section-3.2.1
> {quote}
> userinfo= *( unreserved / pct-encoded / sub-delims / ":" )
> {quote}
> RFC of URL also allows it.
> https://tools.ietf.org/html/rfc1738#section-3.1
> {quote}
> //:@:/
>Some or all of the parts ":@", ":",
>":", and "/" may be excluded.
> {quote}
> I created Pull Request.
> https://github.com/apache/commons-validator/pull/5
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (TEXT-112) Conditional expansion (variation of default value syntax)
[
https://issues.apache.org/jira/browse/TEXT-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher moved LANG-1378 to TEXT-112:
--
Fix Version/s: (was: 3.8)
Affects Version/s: (was: 3.7)
Component/s: (was: lang.text.*)
Workflow: jira (was: Default workflow, editable Closed status)
Key: TEXT-112 (was: LANG-1378)
Project: Commons Text (was: Commons Lang)
> Conditional expansion (variation of default value syntax)
> -
>
> Key: TEXT-112
> URL: https://issues.apache.org/jira/browse/TEXT-112
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Charles Fineman
>Priority: Major
>
> I'd like to propose an extension to the current syntax (and would consider
> submitting a PR for it if folks are in favor of the proposal)
> There is currently support for: ${undefined.number:-1234567890}
> I'm proposing adding: ${defined.number:?The number is ${defined.number}}
> My quick glance of the recursive interpolation makes me feel this would be
> relatively straightforward.
>
> Curious when the next version would be released (I asked because I could
> actually make use of this in something I'm working on right now)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1378) Conditional expansion (variation of default value syntax)
[
https://issues.apache.org/jira/browse/LANG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351726#comment-16351726
]
Pascal Schumacher commented on LANG-1378:
-
Thanks for the proposal.
I guess you are talking about StrSubstitutor? This class has been deprecated in
version 3.6 and is now maintained as part of commons-text.
I will therefore move this issue to commons-text.
> Conditional expansion (variation of default value syntax)
> -
>
> Key: LANG-1378
> URL: https://issues.apache.org/jira/browse/LANG-1378
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Affects Versions: 3.7
>Reporter: Charles Fineman
>Priority: Major
> Fix For: 3.8
>
>
> I'd like to propose an extension to the current syntax (and would consider
> submitting a PR for it if folks are in favor of the proposal)
> There is currently support for: ${undefined.number:-1234567890}
> I'm proposing adding: ${defined.number:?The number is ${defined.number}}
> My quick glance of the recursive interpolation makes me feel this would be
> relatively straightforward.
>
> Curious when the next version would be released (I asked because I could
> actually make use of this in something I'm working on right now)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
