[Geoserver-devel] (GEOS-6868) Upgrading commons-lang version - add tests?

tbarsballe · February 5, 2015, 8:04pm

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

jive · February 5, 2015, 9:49pm

I guess under LDAP authentication? Sounds like it is our only exposure to the issue …

···

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

jive · February 5, 2015, 10:03pm

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

···

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

tbarsballe · February 5, 2015, 10:15pm

Adding Kevin to this conversation at request of Ben.

Jody: I am mainly just concerned with adding a test for the bug that prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer functionality (namely LDAP authentication) requires more recent versions, such as commons-lang-2.4.jar.

With the older version, you can get errors like this:

Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String; 
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250)

The LDAP Authentication module definately seems like the best place for such a test.

**Ben**: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

···

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

–
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Benjamin_Trigona-Har · February 5, 2015, 10:19pm

It can be reproduced by following the steps in the LDAP documentation: http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html. The failure occurs at step 9 when you save the changes to the Authentication Chain.

···

On 5 February 2015 at 14:15, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Adding Kevin to this conversation at request of Ben.

Jody: I am mainly just concerned with adding a test for the bug that prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer functionality (namely LDAP authentication) requires more recent versions, such as commons-lang-2.4.jar.

With the older version, you can get errors like this:
Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String; 
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250) 
The LDAP Authentication module definately seems like the best place for such a test. 
**Ben**: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

–

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

–
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Benjamin Trigona-Harany

Global Support Lead | Boundless

bosth@…3839…

+1-250-984-4141

@boundlessgeo

tbarsballe · February 6, 2015, 10:03pm

Ben: I was unable to reproduce this failure (local build, latest geoserver master, fresh maven repo).

Torben

···

On Thu, Feb 5, 2015 at 2:19 PM, Benjamin Trigona-Harany <bosth@anonymised.com> wrote:

It can be reproduced by following the steps in the LDAP documentation: http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html. The failure occurs at step 9 when you save the changes to the Authentication Chain.

On 5 February 2015 at 14:15, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Adding Kevin to this conversation at request of Ben.

Jody: I am mainly just concerned with adding a test for the bug that prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer functionality (namely LDAP authentication) requires more recent versions, such as commons-lang-2.4.jar.

With the older version, you can get errors like this:
Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String; 
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250) 
The LDAP Authentication module definately seems like the best place for such a test. 
**Ben**: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

–

Benjamin Trigona-Harany

Global Support Lead | Boundless

bosth@…3839…

+1-250-984-4141

@boundlessgeo

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

–
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

tbarsballe · February 6, 2015, 10:44pm

It looks like the actual failure mentioned in this ticket is fixed (?) in newer builds of geoserver, since the code in question is tested in existing test cases. Regardless, here is an update og geotools/geoserver to commons-lang-2.6 (latest 2.x version):

https://github.com/geotools/geotools/pull/728
https://github.com/geoserver/geoserver/pull/914

Both changes have been tested against a full maven build/test; no failures.

Torben

···

On Fri, Feb 6, 2015 at 2:03 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Ben: I was unable to reproduce this failure (local build, latest geoserver master, fresh maven repo).

Torben

On Thu, Feb 5, 2015 at 2:19 PM, Benjamin Trigona-Harany <bosth@anonymised.com> wrote:

It can be reproduced by following the steps in the LDAP documentation: http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html. The failure occurs at step 9 when you save the changes to the Authentication Chain.

On 5 February 2015 at 14:15, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Adding Kevin to this conversation at request of Ben.

Jody: I am mainly just concerned with adding a test for the bug that prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer functionality (namely LDAP authentication) requires more recent versions, such as commons-lang-2.4.jar.

With the older version, you can get errors like this:
Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String; 
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250) 
The LDAP Authentication module definately seems like the best place for such a test. 
**Ben**: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

–

Benjamin Trigona-Harany

Global Support Lead | Boundless

bosth@…3839…

+1-250-984-4141

@boundlessgeo

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

–
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

jive · February 6, 2015, 11:09pm

Thanks for the fix, and the clear communication on the email lists.

···

On 6 February 2015 at 14:44, Torben Barsballe <tbarsballe@anonymised.com> wrote:

It looks like the actual failure mentioned in this ticket is fixed (?) in newer builds of geoserver, since the code in question is tested in existing test cases. Regardless, here is an update og geotools/geoserver to commons-lang-2.6 (latest 2.x version):

https://github.com/geotools/geotools/pull/728
https://github.com/geoserver/geoserver/pull/914

Both changes have been tested against a full maven build/test; no failures.

Torben

–
Jody Garnett

On Fri, Feb 6, 2015 at 2:03 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Ben: I was unable to reproduce this failure (local build, latest geoserver master, fresh maven repo).

Torben

On Thu, Feb 5, 2015 at 2:19 PM, Benjamin Trigona-Harany <bosth@anonymised.com…> wrote:

It can be reproduced by following the steps in the LDAP documentation: http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html. The failure occurs at step 9 when you save the changes to the Authentication Chain.

On 5 February 2015 at 14:15, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Adding Kevin to this conversation at request of Ben.

Jody: I am mainly just concerned with adding a test for the bug that prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer functionality (namely LDAP authentication) requires more recent versions, such as commons-lang-2.4.jar.

With the older version, you can get errors like this:
Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String; 
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250) 
The LDAP Authentication module definately seems like the best place for such a test. 
**Ben**: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

–

Benjamin Trigona-Harany

Global Support Lead | Boundless

bosth@…3839…

+1-250-984-4141

@boundlessgeo

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I guess I am trying to say it is not worth introducing some new commons-lang functionality just to ensure we are working with the new version. The only thing I see that is fun is in commons-lang 3 (where Java 6 is a requirement).

–
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version. So far a strait update (in both geotools and geoserver) has not broken anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg LDAP authentication), where would it be appropriate to add a regression test for the new commons-lang functionallity?

Thanks,

Torben Barsballe

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Bart_van_den_Eijnde1 · February 7, 2015, 12:48am

Thanks for that. I spotted an old commons-lang version hiding out in the online app-schema tests and see that you fixed it as well.

Kind regards,
Ben.

On 07/02/15 11:44, Torben Barsballe wrote:

It looks like the actual failure mentioned in this ticket is fixed (?) in
newer builds of geoserver, since the code in question is tested in existing
test cases. Regardless, here is an update og geotools/geoserver to
commons-lang-2.6 (latest 2.x version):

https://github.com/geotools/geotools/pull/728
https://github.com/geoserver/geoserver/pull/914

Both changes have been tested against a full maven build/test; no failures.

Torben

On Fri, Feb 6, 2015 at 2:03 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Ben: I was unable to reproduce this failure (local build, latest geoserver
master, fresh maven repo).

Torben

On Thu, Feb 5, 2015 at 2:19 PM, Benjamin Trigona-Harany <
bosth@anonymised.com> wrote:

It can be reproduced by following the steps in the LDAP documentation:
http://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html.
The failure occurs at step 9 when you save the changes to the
Authentication Chain.

On 5 February 2015 at 14:15, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Adding Kevin to this conversation at request of Ben.

*Jody*: I am mainly just concerned with adding a test for the bug that
prompted this fix. From the JIRA ticket:

GeoServer is using commons-lang-2.1.jar but some GeoServer
functionality (namely LDAP authentication) requires more recent versions,
such as commons-lang-2.4.jar.

With the older version, you can get errors like this:

Caused by: java.lang.NoSuchMethodError: org.apache.commons.lang.StringUtils.replaceEach(Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/String;)Ljava/lang/String;
at org.springframework.ldap.core.DistinguishedName.unmangleCompositeName(DistinguishedName.java:250)

The LDAP Authentication module definately seems like the best place for such a test.

*Ben*: You initially reported this bug. Do you happen to have a more complete stack trace, or steps to reproduce?

On Thu, Feb 5, 2015 at 2:03 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I guess I am trying to say it is not worth introducing some new
commons-lang functionality just to ensure we are working with the new
version. The only thing I see that is fun is in commons-lang 3 (where Java
6 is a requirement).

--
Jody Garnett

On 5 February 2015 at 12:04, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-6868

I am in the process of upgrading the commons-lang to a newer version.
So far a strait update (in both geotools and geoserver) has not broken
anything (mvn clean install runs with no build or test failures)

Given that the existing version of commons-lang causes some issues (eg
LDAP authentication), where would it be appropriate to add a regression
test for the new commons-lang functionallity?

Thanks,
Torben Barsballe

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media,
is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more.
Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

Benjamin Trigona-Harany

Global Support Lead | Boundless <http://boundlessgeo.com>

bosth@anonymised.com

+1-250-984-4141

@boundlessgeo <http://twitter.com/boundlessgeo/>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ben Caradoc-Davies <ben@anonymised.com>
Software Engineer
Transient Software <http://transient.nz>
New Zealand