[jira] [Commented] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817704#comment-17817704
]
K P commented on TEXT-233:
--
I tested adding the following property to the commons-text pom.xml:
{code:java}
org.apache.commons.lang3;version="3.14",
org.apache.commons.lang3.time;version="3.14",
*
{code}
And I can confirm that this correctly generates the following Import-Package
header in the MANIFEST.MF
{code:java}
Import-Package: org.apache.commons.lang3;version="3.14",org.apache.com
mons.lang3.time;version="3.14",javax.script,javax.xml.xpath,org.xml.s
ax{code}
(an alternative choice for the property would be specifying a version range
"{_}[3.14,4){_}" instead of the open range "{_}3.14{_}").
The resulting commons-text snapshot jar would then only resolve against
commons-lang3 3.14.0 or higher in OSGi. Ensuring that its code will get the
expected up-to-date commons-lang3 classes in its classpath.
If there's no fix for this old outstanding issue in the maven-bundle-plugin,
then at least this simple workaround allows to generate commons-text jars that
have the required version ranges in their MANIFEST.MF. And then at least this
would build a commons-text jar that won't break unexpectedly at runtime in an
OSGi environment.
Drawback is that these versions ranges are not updated automatically based on
the maven dependencies... Updating the property _commons.osgi.import_ is then a
manual process, easy to forget.
(Although forgetting to bump up the version in these OSGi headers isn't always
problematic. Problems arise when a commons-text change requires something new
in a specific minimal commons-lang3 version. Like this case where commons-text
started using Range.of(...) instead of Range.between(...) and therefore
_requires_ that OSGi resolves against commons-lang3 3.13.0 or higher. However,
if the commons-text source code would still be backward compatible with an
older commons-lang3 version, forgetting to bump up the version in the
Import-Package, wouldn't be that harmful.)
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
>
[jira] [Comment Edited] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817445#comment-17817445
]
K P edited comment on TEXT-233 at 2/14/24 4:40 PM:
---
I've been searching around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property? (I couldn't verify this yet...)
was (Author: belpk):
I've been search around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property?
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
>
[jira] [Commented] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817445#comment-17817445
]
K P commented on TEXT-233:
--
I've been search around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property?
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
> satisfied by that package and resolve and link its import-package requirement
> against the 3.12.0 version.
> So when loading these OSGi bundles, all will look fine. The OSGi will nicely
> resolve everything without complaining at this point.
> However in the above example environment, maybe much much later, when at a
> given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g.
> some of the StringEscapeUtils method being called by user code) is invoked,
> then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0
> version of the Range class in its classpath. It will try to invoke the method
> Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
> the Range class.
> Which will fail with a NoSuchMethodError:
>
> {noformat}
> java.lang.NoSuchMethodError:
> org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
> at
>
[jira] [Created] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
K P created TEXT-233:
Summary: Missing OSGi import-package commons-lang3 version can
make commons-text unusable in OSGi
Key: TEXT-233
URL: https://issues.apache.org/jira/browse/TEXT-233
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.11.0
Reporter: K P
Since commons-text 1.11.0, there's commons-text codes that requires the
presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
this requirement is not enforced due to shortcoming an the commons-text 1.11.0
MANIFEST.MF, which may lead to unpredictable, uncontrollable failure when
trying to use commons-text 1.11.0.
Some more detail:
Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
*Range.{_}+of+{_}(...)* in commons-lang3 :
{code:java}
private NumericEntityEscaper(final int below, final int above, final boolean
between) {
this.range = Range.of(below, above);
this.between = between;
}{code}
Method Range.of(...) was added in *commons-lang3 3.13.0* :
{code:java}
* @since 3.13.0
*/
public static > Range of(final T
fromInclusive, final T toInclusive) {{code}
Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use of
the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now marked
as deprecated since commons-lang3 3.13.0)
{code:java}
private NumericEntityEscaper(final int below, final int above, final boolean
between) {
this.range = Range.between(below, above);
this.between = between;
}{code}
This is all fine in a non-OSGi environment.
However, to always resolve this correctly in an OSGi environment, some
essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
The commons-text 1.11.0 declares the following *Import-Package* in its manifest:
{noformat}
Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
g.apache.commons.lang3.time,org.xml.sax
{noformat}
Notice how this indeed imports the required package
"{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
version number{+}.
When an OSGi package is not qualified by a version number or version range,
then during package resolution, OSGi may resolve this import against whatever
version of commons-lang3 it can find and that exports this package.
In other words, because there's no version restriction in this import as far as
OSGi is concerned : if you have an OSGi environment where also an older version
older version of commons-lang3 is already present, e.g. commons-lang "3.12.0",
then the import-package of commons-text 1.11.0 will happily be satisfied by
that package and resolve and link its import-package requirement against the
3.12.0 version.
So when loading these OSGi bundles, all will look fine. The OSGi will nicely
resolve everything without complaining at this point.
However in the above example environment, maybe much much later, when at a
given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g. some
of the StringEscapeUtils method being called by user code) is invoked,
then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0 version
of the Range class in its classpath. It will try to invoke the method
Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
the Range class.
Which will fail with a NoSuchMethodError:
{noformat}
java.lang.NoSuchMethodError:
org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
at
org.apache.commons.text.translate.NumericEntityEscaper.(NumericEntityEscaper.java:97)
~[?:?]{noformat}
To avoid this, it is +required+ that the commons-text 1.11.0 *MANIFEST.MF*
correctly specifies the minimally required version of the commons-lang3 package
in its Import-Package:
E.g. by adding a version directive: *{{;version="3.13"}}* : in OSGi, 1 single
version number means a minimal version number, i.e. an open range 3.13.0 or
higher.
Example:
{code:java}
Import-Package:
javax.script,javax.xml.xpath,org.apache.commons.lang3;version="3.13",or
g.apache.commons.lang3.time;version="3.13",org.xml.sax{code}
That way, when OSGi resolves commons-text 1.11.0, it will now only be satisifed
by version 3.13 of those package, or higher, and therefore be guaranteed to
link its org.apache.commons.lang3 Import-Package against the package from
commons-lang3 3.13.0 or higher.
Then at runtime, whenever the NumericEntityEscaper calls a method on the Range
class, it sees a 3.13.0 (or higher) version of the Range class, where the
method Range.of(...) exists.
(Note: a manifst example from another Apache Project:
this snippet is from the MANIFEST.MF of the Apache Velocity Engine jar:
{code:java}
Import-Package: javax.naming,javax.sql,org.apache.commons.lang3;versio
n="[3.11,4)",
{code}
Notice how they've specified a version range, which
[jira] [Created] (IO-793) StringInputStream.java source only in test sources?
K P created IO-793: -- Summary: StringInputStream.java source only in test sources? Key: IO-793 URL: https://issues.apache.org/jira/browse/IO-793 Project: Commons IO Issue Type: Bug Components: Streams/Writers Affects Versions: 2.12.0 Reporter: K P In the change report of the new commons-io 2.12.0, I read: "Add StringInputStream" as a new feature. Now I went looking for it in the 2.12.0 javadoc and binary, and didn't find it. However, I did find that source file in the "test" sources, instead of the normal sources. [https://github.com/apache/commons-io/blob/master/src/test/java/org/apache/commons/io/input/StringInputStream.java] Is this intentional? If this is, then the change report is rather confusing. If it's not intentional, then maybe this source was committed in the wrong location or had to move to the normal sources? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TEXT-209) LookupTranslator returns count of chars consumed, not of codepoints consumed
K P created TEXT-209:
Summary: LookupTranslator returns count of chars consumed, not of
codepoints consumed
Key: TEXT-209
URL: https://issues.apache.org/jira/browse/TEXT-209
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.9
Reporter: K P
The contract of {{abstract method translate(CharSequence }}{{input, int index,
Writer out)}} in the class CharSequenceTranslator, and therefore also in the
inherited LookupTranslator, is to return the "_int count of codepoints
consumed_".
Cf. their javadoc.
However, LookupTranslator returns the number of chars.
This can be seen in its source, in its implementation of the abstract method,
where it returns "i", which is the length _in chars_ of the longest matching
substring.
Test to reproduce:
Define a mapping where a String with 1 supplementary character is mapped to 1
(basic) char.
{code:java}
/* Key: string with Mathematical double-struck capital A (U+1D538) */
String symbol = new StringBuilder().appendCodePoint(0x1D538).toString();
/* Map U+1D538 to "A" */
Map map = new HashMap<>();
map.put(symbol, "A");
LookupTranslator translator = new LookupTranslator(map);
String translated = translator.translate(symbol + "=A");
/* Fails: instead of "A=A", we get "AA". */
assertEquals("A=A", translated);
{code}
So when doing the translation, the supplementary character got mapped, but then
you notice that the LookupTranslator erroneously +_swallowed_ the following "="
character+.
That is because its translate method returns the count of matched _chars_ (i.e.
2 = the high and low surrogate code unit (chars) that form the surrogate pair)
, instead of the count of matched _codepoints_ (i.e. which is 1, and which the
javadoc claims to return)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COLLECTIONS-704) GrowthList: ambiguity in constructor argument
K P created COLLECTIONS-704:
---
Summary: GrowthList: ambiguity in constructor argument
Key: COLLECTIONS-704
URL: https://issues.apache.org/jira/browse/COLLECTIONS-704
Project: Commons Collections
Issue Type: Improvement
Components: List
Affects Versions: 4.2, 4.0
Reporter: K P
The javadoc of constructor
{{[GrowthList|https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/list/GrowthList.html#GrowthList-int-](int
initialSize)}}
states:
{{initialSize}} - the initial size of the ArrayList
However, this is confusing terminology: As the initialSize argument is passed
directly to the internal ArrayList constructor, this is effectively the initial
+capacity+. The +capacity+ is NOT the same as the actual list +size+. So after
this constructor is called, the actual list.size() is still 0. This is
identical to the normal ArrayList constructor's behavior of course.
However, the GrowthList javadoc is confusing by explicitly claiming this is the
"_initial size_", which may lead the reader to think that this constructor
effectively grows the initial list to an actual given size - size in the sense
the word is used everywhere else in the javadoc of this class. As opposed to
the javadoc of Java's ArrayList, where they clear use the terminology "_the
initial capacity of the list_", to avoid any confusion between the notion of
internal array capacity and the list size.
If, long ago, this GrowthList constructor was once intended to really set the
ini**tial size, then is clearly not what the code does.
However, if this never was the intention, and this was just intended to be an
initial capacity, as the normal ArrayList, then the javadoc of GrowthList
should be slightly reworded, to avoid ambiguity or misunderstanding, and make
clear this is just the initial _capacity_ of the underlying ArrayList; not the
initial _size_ of the list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
