Re: [text] On the value of idempotent string escape methods?

[sebb]

On 21 February 2017 at 04:40, Sampanna Kahu  wrote:
> Hi Guys,
> Very good points are being made above. Please allow me to add my two cents
> :-)
>
> What if the string contains syntactically valid HTML characters/tags and
> our aim is to prevent rendering these tags in the browser when this string
> is being served via a web application? Or prevent the execution of harmful
> embedded scripts when serving it? The 'escapeOnce' method could be useful
> here, right?

I don't think so.

> To explain better, let's consider an example of the specific use-case that
> I had in mind when building the 'escapeOnce' method:
> Consider the scenario of a simple restful web application where users can
> manipulate their text using simple crud operations. Lets assume that we do
> not have the 'escapeOnce' method yet.
> 1. A user comes and submits his string. We escape it and store it in our
> database. If the string had any HTML characters, they would have gotten
> escaped.
>
> 2. After some time, the same user fetches his string, adds some more HTML
> characters and submits it. At this point, although the escape method would
> correctly escape the freshly added HTML characters, it would escape the
> older escaped HTML characters again! (for example > would become
> >)
> And this effect gets magnified if step number 2 above is repeated.

Of course, that is my point.

Also remember that you want to show the original string to the user.
That's not possible in general if you use this approach.

Suppose they originally entered

"To code ampersand (&) in HTML, use '&'"

Using escapeOnce, this would become:

"To code ampersand (&) in HTML, use '&'"

You can either show that directly to the user, or use an unescapeOnce
and show them:

"To code ampersand (&) in HTML, use '&'"

Neither makes any sense.

> How do we solve the above problem without the 'escapeOnce' method?

Store the raw string in the database and escape it just before display.

If you are using Javascript, then use an approach such as this to escape it:

document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));

See:

http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/

This has a good discussion of some of the problems.

==

Sorry, but it's not possible in general to do what you want, because
one cannot reliably determine if a string has been escaped just from
looking at the string.

The most one can do is to sanitise the string by escaping anything
that is unescaped.
However that process corrupts the input - a browser won't display the
proper output.

> On 20 February 2017 at 21:40, sebb  wrote:
>
>> On 20 February 2017 at 15:36, Rob Tompkins  wrote:
>> >
>> >> On Feb 20, 2017, at 10:30 AM, sebb  wrote:
>> >>
>> >> On 20 February 2017 at 14:55, Rob Tompkins  wrote:
>> >>>
>>  On Feb 20, 2017, at 4:31 AM, sebb  wrote:
>> 
>>  On 19 February 2017 at 14:29, Raymond DeCampo > > wrote:
>> > I am trying to see how having the proposed unescape() method leads
>> to an a
>> > useful escape method.
>> >
>> > E.g. clearly unescape("&") would evaluate to "&".  So would
>> > unescape("&").  That means the proposed escape() method
>> would also
>> > have the same output for "&" and "&".
>> >
>> > I think a better approach for an idempotent escape would be to just
>> > unescape the string once, and then run the traditional escape.
>> 
>>  That does not eliminate the problems, as you state below.
>> 
>> > You will
>> > still have issues if the user intended to escape the string "&"
>> but you
>> > are never going to crack that without some kind of state saving.
>> 
>>  That is my exact point.
>> 
>>  Since it's not possible for the function to work reliably, we should
>>  not mislead users by pretending that there is a magic method that
>>  works.
>> 
>> > Than given that the functionality is available via to consecutive
>> calls to
>> > existing methods, I would probably be disinclined to include it in
>> the
>> > library.
>> 
>>  +1
>> >>>
>> >>> I’m a (+1) for removal as well.
>> >>>
>> >>> Also, I didn’t mean for my example to sound like a proposal. I merely
>> was trying to get to a potentially valuable stateless idempotent string
>> escape function. Its contrivance it quite clear.
>> >>>
>> >>> Any other comments out there?
>> >>>
>> >>> We could provide a stateful escaper (that figures out how many escapes
>> a string is in), or a method that returns the number of escapes in a string
>> is. Again, I’m not all that sure on the value of such methods.
>> >>
>> >> I don't think it's possible to work out the number of times a string
>> >> has been escaped.
>> >
>> > That may indeed be true, but it is possible to return the number of
>> times unescape need be run before subsequent unescapes yield the same
>> result.
>>
>> That in itself is potentially ambiguous.
>> Does the

[ANNOUNCE] Apache Commons Validator 1.6 released

[sebb]

The Apache Commons Team is pleased to announce the release of Apache
Commons Validator 1.6

Apache Commons Validator provides the building blocks for both client side
validation and server side data validation. It may be used standalone or
with a framework like Struts.

The main changes are:

* Modulus Ten Check Digit Implementation
* Generic CreditCard validation (syntax and checkdigit only; does not check IIN)
* CreditCard validation specification by numeric range

Details of all the changes in 1.6 can be found in the changelog:

http://commons.apache.org/proper/commons-validator/changes-report.html

1.6 is fully binary compatible to the last release. No client code
changes are required to migrate from version 1.4.x (or later) to 1.6.
The minimum required JDK version for this release is 1.6.

However note that the Javascript code has been dropped, see
https://issues.apache.org/jira/browse/VALIDATOR-371

Source and binary distributions are available for download from the Apache
Commons download site:

http://commons.apache.org/proper/commons-validator/download_validator.cgi

When downloading, please verify signatures using the KEYS file available at

http://www.apache.org/dist/commons/KEYS

Alternatively the release can be fetched from Maven Central:


  commons-validator
  commons-validator
  1.6


For complete information on Commons Validator, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Validator website:

http://commons.apache.org/proper/commons-validator/

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

Re: [ALL][RNG] Update Apache projects description file

[Gilles]

On Mon, 20 Feb 2017 14:08:40 +, sebb wrote:
On 20 February 2017 at 13:06, Gilles  
wrote:

Hi.

Can someone with the privilege to update this file


AFAIK you should be able to do this yourself ...


Right; I had done the checkout from "http://"; instead of "https://";.

Sorry for the noise,
Gilles


[...]



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

Build failed in Jenkins: commons-validator #38

[Apache Jenkins Server]

See 


Changes:

[sebb] 1.6 Released

[sebb] Fix layout

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-1 (ubuntu) in workspace 

Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk at 
revision '2017-02-21T12:05:11.635 +'
U RELEASE-NOTES.txt
U src/changes/changes.xml
U pom.xml
At revision 1783877

Parsing POMs
Established TCP socket on 51758
Copied maven32-agent.jar
Copied maven32-interceptor.jar
maven3-interceptor-commons.jar already up to date
[commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
-Xms256m -cp 
/home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
 jenkins.maven3.agent.Maven32Main /home/jenkins/tools/maven/apache-maven-3.2.5 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven32-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 51758
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
at hudson.slaves.Channels.forProcess(Channels.java:115)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1728)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)

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

Re: [text] On the value of idempotent string escape methods?

[Rob Tompkins]

> On Feb 21, 2017, at 6:02 AM, sebb  wrote:
> 
> On 21 February 2017 at 04:40, Sampanna Kahu  > wrote:
>> Hi Guys,
>> Very good points are being made above. Please allow me to add my two cents
>> :-)
>> 
>> What if the string contains syntactically valid HTML characters/tags and
>> our aim is to prevent rendering these tags in the browser when this string
>> is being served via a web application? Or prevent the execution of harmful
>> embedded scripts when serving it? The 'escapeOnce' method could be useful
>> here, right?
> 
> I don't think so.
> 
>> To explain better, let's consider an example of the specific use-case that
>> I had in mind when building the 'escapeOnce' method:
>> Consider the scenario of a simple restful web application where users can
>> manipulate their text using simple crud operations. Lets assume that we do
>> not have the 'escapeOnce' method yet.
>> 1. A user comes and submits his string. We escape it and store it in our
>> database. If the string had any HTML characters, they would have gotten
>> escaped.
>> 
>> 2. After some time, the same user fetches his string, adds some more HTML
>> characters and submits it. At this point, although the escape method would
>> correctly escape the freshly added HTML characters, it would escape the
>> older escaped HTML characters again! (for example > would become
>> >)
>> And this effect gets magnified if step number 2 above is repeated.
> 
> Of course, that is my point.
> 
> Also remember that you want to show the original string to the user.
> That's not possible in general if you use this approach.
> 
> Suppose they originally entered
> 
> "To code ampersand (&) in HTML, use '&'"
> 
> Using escapeOnce, this would become:
> 
> "To code ampersand (&) in HTML, use '&'"
> 
> You can either show that directly to the user, or use an unescapeOnce
> and show them:
> 
> "To code ampersand (&) in HTML, use '&'"
> 
> Neither makes any sense.
> 
>> How do we solve the above problem without the 'escapeOnce' method?
> 
> Store the raw string in the database and escape it just before display.
> 
> If you are using Javascript, then use an approach such as this to escape it:
> 
> document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));
> 
> See:
> 
> http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/ 
> 
> 
> This has a good discussion of some of the problems.
> 
> ==
> 
> Sorry, but it's not possible in general to do what you want, because
> one cannot reliably determine if a string has been escaped just from
> looking at the string.

Another thought occurred to me (again despite potential lack of value). 

We should be able to quickly verify if there are any escape strings in the 
string in question. A single application of unescape followed by checking 
string equality with the original input would yield a predicate on the 
existence of escape’s present in the input in question. From there we could: 
(1) escape if no escapes were present in the original, or (2) throw an 
exception if there were escapes present in the original string.

Again, this feels contrived, so I’m not really suggesting that we add it. I’m 
just playing with ideas here that could accomplish what Sampanna is going for.

-Rob

> 
> The most one can do is to sanitise the string by escaping anything
> that is unescaped.
> However that process corrupts the input - a browser won't display the
> proper output.
> 
>> On 20 February 2017 at 21:40, sebb  wrote:
>> 
>>> On 20 February 2017 at 15:36, Rob Tompkins  wrote:
 
> On Feb 20, 2017, at 10:30 AM, sebb  wrote:
> 
> On 20 February 2017 at 14:55, Rob Tompkins  wrote:
>> 
>>> On Feb 20, 2017, at 4:31 AM, sebb  wrote:
>>> 
>>> On 19 February 2017 at 14:29, Raymond DeCampo >> > wrote:
 I am trying to see how having the proposed unescape() method leads
>>> to an a
 useful escape method.
 
 E.g. clearly unescape("&") would evaluate to "&".  So would
 unescape("&").  That means the proposed escape() method
>>> would also
 have the same output for "&" and "&".
 
 I think a better approach for an idempotent escape would be to just
 unescape the string once, and then run the traditional escape.
>>> 
>>> That does not eliminate the problems, as you state below.
>>> 
 You will
 still have issues if the user intended to escape the string "&"
>>> but you
 are never going to crack that without some kind of state saving.
>>> 
>>> That is my exact point.
>>> 
>>> Since it's not possible for the function to work reliably, we should
>>> not mislead users by pretending that there is a magic method that
>>> works.
>>> 
 Than given that the functionality is available via to consecutive
>>> calls t

Re: [text] On the value of idempotent string escape methods?

[sebb]

On 21 February 2017 at 12:40, Rob Tompkins  wrote:
>
>> On Feb 21, 2017, at 6:02 AM, sebb  wrote:
>>
>> On 21 February 2017 at 04:40, Sampanna Kahu > > wrote:
>>> Hi Guys,
>>> Very good points are being made above. Please allow me to add my two cents
>>> :-)
>>>
>>> What if the string contains syntactically valid HTML characters/tags and
>>> our aim is to prevent rendering these tags in the browser when this string
>>> is being served via a web application? Or prevent the execution of harmful
>>> embedded scripts when serving it? The 'escapeOnce' method could be useful
>>> here, right?
>>
>> I don't think so.
>>
>>> To explain better, let's consider an example of the specific use-case that
>>> I had in mind when building the 'escapeOnce' method:
>>> Consider the scenario of a simple restful web application where users can
>>> manipulate their text using simple crud operations. Lets assume that we do
>>> not have the 'escapeOnce' method yet.
>>> 1. A user comes and submits his string. We escape it and store it in our
>>> database. If the string had any HTML characters, they would have gotten
>>> escaped.
>>>
>>> 2. After some time, the same user fetches his string, adds some more HTML
>>> characters and submits it. At this point, although the escape method would
>>> correctly escape the freshly added HTML characters, it would escape the
>>> older escaped HTML characters again! (for example > would become
>>> >)
>>> And this effect gets magnified if step number 2 above is repeated.
>>
>> Of course, that is my point.
>>
>> Also remember that you want to show the original string to the user.
>> That's not possible in general if you use this approach.
>>
>> Suppose they originally entered
>>
>> "To code ampersand (&) in HTML, use '&'"
>>
>> Using escapeOnce, this would become:
>>
>> "To code ampersand (&) in HTML, use '&'"
>>
>> You can either show that directly to the user, or use an unescapeOnce
>> and show them:
>>
>> "To code ampersand (&) in HTML, use '&'"
>>
>> Neither makes any sense.
>>
>>> How do we solve the above problem without the 'escapeOnce' method?
>>
>> Store the raw string in the database and escape it just before display.
>>
>> If you are using Javascript, then use an approach such as this to escape it:
>>
>> document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));
>>
>> See:
>>
>> http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/ 
>> 
>>
>> This has a good discussion of some of the problems.
>>
>> ==
>>
>> Sorry, but it's not possible in general to do what you want, because
>> one cannot reliably determine if a string has been escaped just from
>> looking at the string.
>
> Another thought occurred to me (again despite potential lack of value).
>
> We should be able to quickly verify if there are any escape strings in the 
> string in question. A single application of unescape followed by checking 
> string equality with the original input would yield a predicate on the 
> existence of escape’s present in the input in question.

Again, what does unescape mean in this context?
Does it ignore incomplete escape sequences, or throw an error?

> From there we could: (1) escape if no escapes were present in the original, 
> or (2) throw an exception if there were escapes present in the original 
> string.
> Again, this feels contrived, so I’m not really suggesting that we add it. I’m 
> just playing with ideas here that could accomplish what Sampanna is going for.

The request is impossible to fulfill reliably, and does not deserve to
be added to a Commons library.

I don't know why this is still being discussed.

> -Rob
>
>>
>> The most one can do is to sanitise the string by escaping anything
>> that is unescaped.
>> However that process corrupts the input - a browser won't display the
>> proper output.
>>
>>> On 20 February 2017 at 21:40, sebb  wrote:
>>>
 On 20 February 2017 at 15:36, Rob Tompkins  wrote:
>
>> On Feb 20, 2017, at 10:30 AM, sebb  wrote:
>>
>> On 20 February 2017 at 14:55, Rob Tompkins  wrote:
>>>
 On Feb 20, 2017, at 4:31 AM, sebb  wrote:

 On 19 February 2017 at 14:29, Raymond DeCampo >>> > wrote:
> I am trying to see how having the proposed unescape() method leads
 to an a
> useful escape method.
>
> E.g. clearly unescape("&") would evaluate to "&".  So would
> unescape("&").  That means the proposed escape() method
 would also
> have the same output for "&" and "&".
>
> I think a better approach for an idempotent escape would be to just
> unescape the string once, and then run the traditional escape.

 That does not eliminate the problems, as you state below.

> You will
> still have issues if the user intended to escape 

Build failed in Jenkins: commons-validator #39

[Apache Jenkins Server]

See 

--
Started by user sebb
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-1 (ubuntu) in workspace 

Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk at 
revision '2017-02-21T15:00:12.349 +'
At revision 1783899

No changes for https://svn.apache.org/repos/asf/commons/proper/validator/trunk 
since the previous build
Parsing POMs
Established TCP socket on 32827
maven32-agent.jar already up to date
maven32-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
-Xms256m -cp 
/home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
 jenkins.maven3.agent.Maven32Main /home/jenkins/tools/maven/apache-maven-3.2.5 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven32-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
at hudson.slaves.Channels.forProcess(Channels.java:115)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1728)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)

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

Re: Build failed in Jenkins: commons-validator #39

[sebb]

Seems to be a bug in Jenkins - this is before Maven is even invoked,
and Validator used to build fine with 1.6.
Raised INFRA-13556

On 21 February 2017 at 15:00, Apache Jenkins Server
 wrote:
> See 
>
> --
> Started by user sebb
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-1 (ubuntu) in workspace 
> 
> Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk at 
> revision '2017-02-21T15:00:12.349 +'
> At revision 1783899
>
> No changes for 
> https://svn.apache.org/repos/asf/commons/proper/validator/trunk since the 
> previous build
> Parsing POMs
> Established TCP socket on 32827
> maven32-agent.jar already up to date
> maven32-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
> -Xms256m -cp 
> /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
>  jenkins.maven3.agent.Maven32Main 
> /home/jenkins/tools/maven/apache-maven-3.2.5 
> /home/jenkins/jenkins-slave/slave.jar 
> /home/jenkins/jenkins-slave/maven32-interceptor.jar 
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> hudson/remoting/Launcher : Unsupported major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
> at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
> at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
> ERROR: Failed to parse POMs
> java.io.EOFException: unexpected stream termination
> at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
> at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
> at hudson.slaves.Channels.forProcess(Channels.java:115)
> at 
> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
> at hudson.maven.ProcessCache.get(ProcessCache.java:236)
> at 
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
> at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
> at hudson.model.Run.execute(Run.java:1728)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
> at hudson.model.ResourceController.execute(ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:404)
>
> -
> 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: Build failed in Jenkins: commons-validator #39

[Rob Tompkins]

I actually get this error when I attempt any maven execution on my machine OS X 
10.12.3 using maven 3.3.9 and:

$java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)

It feels to me like a java-1.6/maven incompatibility.

> On Feb 21, 2017, at 10:07 AM, sebb  wrote:
> 
> Seems to be a bug in Jenkins - this is before Maven is even invoked,
> and Validator used to build fine with 1.6.
> Raised INFRA-13556
> 
> On 21 February 2017 at 15:00, Apache Jenkins Server
>  wrote:
>> See 
>> 
>> --
>> Started by user sebb
>> [EnvInject] - Loading node environment variables.
>> Building remotely on ubuntu-1 (ubuntu) in workspace 
>> 
>> Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk at 
>> revision '2017-02-21T15:00:12.349 +'
>> At revision 1783899
>> 
>> No changes for 
>> https://svn.apache.org/repos/asf/commons/proper/validator/trunk since the 
>> previous build
>> Parsing POMs
>> Established TCP socket on 32827
>> maven32-agent.jar already up to date
>> maven32-interceptor.jar already up to date
>> maven3-interceptor-commons.jar already up to date
>> [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
>> -Xms256m -cp 
>> /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
>>  jenkins.maven3.agent.Maven32Main 
>> /home/jenkins/tools/maven/apache-maven-3.2.5 
>> /home/jenkins/jenkins-slave/slave.jar 
>> /home/jenkins/jenkins-slave/maven32-interceptor.jar 
>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
>> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
>> hudson/remoting/Launcher : Unsupported major.minor version 51.0
>>at java.lang.ClassLoader.defineClass1(Native Method)
>>at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>>at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>>at 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>>at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>>at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>>at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>>at java.security.AccessController.doPrivileged(Native Method)
>>at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>>at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
>>at 
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
>>at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>>at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
>>at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>>at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
>>at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
>> ERROR: Failed to parse POMs
>> java.io.EOFException: unexpected stream termination
>>at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
>>at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
>>at hudson.slaves.Channels.forProcess(Channels.java:115)
>>at 
>> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
>>at hudson.maven.ProcessCache.get(ProcessCache.java:236)
>>at 
>> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
>>at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
>>at hudson.model.Run.execute(Run.java:1728)
>>at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
>>at hudson.model.ResourceController.execute(ResourceController.java:98)
>>at hudson.model.Executor.run(Executor.java:404)
>> 
>> -
>> 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
> 


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

Re: Build failed in Jenkins: commons-validator #39

[sebb]

On 21 February 2017 at 15:20, Rob Tompkins  wrote:
> I actually get this error when I attempt any maven execution on my machine OS 
> X 10.12.3 using maven 3.3.9 and:
>
> $java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
>
> It feels to me like a java-1.6/maven incompatibility.

Maven 3.3.9 requires Java 1.7

However that job uses Maven 2.2.5 and it used to work until a few days ago.

The failure occurs before Maven is started.

>> On Feb 21, 2017, at 10:07 AM, sebb  wrote:
>>
>> Seems to be a bug in Jenkins - this is before Maven is even invoked,
>> and Validator used to build fine with 1.6.
>> Raised INFRA-13556
>>
>> On 21 February 2017 at 15:00, Apache Jenkins Server
>>  wrote:
>>> See 
>>>
>>> --
>>> Started by user sebb
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on ubuntu-1 (ubuntu) in workspace 
>>> 
>>> Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk at 
>>> revision '2017-02-21T15:00:12.349 +'
>>> At revision 1783899
>>>
>>> No changes for 
>>> https://svn.apache.org/repos/asf/commons/proper/validator/trunk since the 
>>> previous build
>>> Parsing POMs
>>> Established TCP socket on 32827
>>> maven32-agent.jar already up to date
>>> maven32-interceptor.jar already up to date
>>> maven3-interceptor-commons.jar already up to date
>>> [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
>>> -Xms256m -cp 
>>> /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
>>>  jenkins.maven3.agent.Maven32Main 
>>> /home/jenkins/tools/maven/apache-maven-3.2.5 
>>> /home/jenkins/jenkins-slave/slave.jar 
>>> /home/jenkins/jenkins-slave/maven32-interceptor.jar 
>>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
>>> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
>>> hudson/remoting/Launcher : Unsupported major.minor version 51.0
>>>at java.lang.ClassLoader.defineClass1(Native Method)
>>>at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>>>at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>>>at 
>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>>>at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>>>at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>>>at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>>>at java.security.AccessController.doPrivileged(Native Method)
>>>at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>>>at 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
>>>at 
>>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
>>>at 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>>>at 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
>>>at 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>>>at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
>>>at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
>>> ERROR: Failed to parse POMs
>>> java.io.EOFException: unexpected stream termination
>>>at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
>>>at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
>>>at hudson.slaves.Channels.forProcess(Channels.java:115)
>>>at 
>>> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
>>>at hudson.maven.ProcessCache.get(ProcessCache.java:236)
>>>at 
>>> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
>>>at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
>>>at hudson.model.Run.execute(Run.java:1728)
>>>at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
>>>at 
>>> hudson.model.ResourceController.execute(ResourceController.java:98)
>>>at hudson.model.Executor.run(Executor.java:404)
>>>
>>> -
>>> 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: d

Re: Build failed in Jenkins: commons-validator #39

[Rob Tompkins]

> On Feb 21, 2017, at 10:48 AM, sebb  wrote:
> 
> On 21 February 2017 at 15:20, Rob Tompkins  > wrote:
>> I actually get this error when I attempt any maven execution on my machine 
>> OS X 10.12.3 using maven 3.3.9 and:
>> 
>> $java -version
>> java version "1.6.0_65"
>> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
>> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
>> 
>> It feels to me like a java-1.6/maven incompatibility.
> 
> Maven 3.3.9 requires Java 1.7
> 
> However that job uses Maven 2.2.5 and it used to work until a few days ago.

It looks like it’s using Maven 3.2.5:

"/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging 
jenkins.maven3.agent.Maven32Main"

> 
> The failure occurs before Maven is started.
> 
>>> On Feb 21, 2017, at 10:07 AM, sebb  wrote:
>>> 
>>> Seems to be a bug in Jenkins - this is before Maven is even invoked,
>>> and Validator used to build fine with 1.6.
>>> Raised INFRA-13556
>>> 
>>> On 21 February 2017 at 15:00, Apache Jenkins Server
>>>  wrote:
 See 
 
 --
 Started by user sebb
 [EnvInject] - Loading node environment variables.
 Building remotely on ubuntu-1 (ubuntu) in workspace 
 
 Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk 
 at revision '2017-02-21T15:00:12.349 +'
 At revision 1783899
 
 No changes for 
 https://svn.apache.org/repos/asf/commons/proper/validator/trunk since the 
 previous build
 Parsing POMs
 Established TCP socket on 32827
 maven32-agent.jar already up to date
 maven32-interceptor.jar already up to date
 maven3-interceptor-commons.jar already up to date
 [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
 -Xms256m -cp 
 /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
  jenkins.maven3.agent.Maven32Main 
 /home/jenkins/tools/maven/apache-maven-3.2.5 
 /home/jenkins/jenkins-slave/slave.jar 
 /home/jenkins/jenkins-slave/maven32-interceptor.jar 
 /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
 Exception in thread "main" java.lang.UnsupportedClassVersionError: 
 hudson/remoting/Launcher : Unsupported major.minor version 51.0
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
   at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
   at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
   at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
   at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
   at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
 ERROR: Failed to parse POMs
 java.io.EOFException: unexpected stream termination
   at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
   at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
   at hudson.slaves.Channels.forProcess(Channels.java:115)
   at 
 hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
   at hudson.maven.ProcessCache.get(ProcessCache.java:236)
   at 
 hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
   at 
 hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
   at hudson.model.Run.execute(Run.java:1728)
   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
   at 
 hudson.model.ResourceController.execute(ResourceController.java:98)
   at hudson.model.Executor.run(Executor.java:404)
 
 -
 To un

Re: Build failed in Jenkins: commons-validator #39

[sebb]

On 21 February 2017 at 15:53, Rob Tompkins  wrote:
>
>> On Feb 21, 2017, at 10:48 AM, sebb  wrote:
>>
>> On 21 February 2017 at 15:20, Rob Tompkins > > wrote:
>>> I actually get this error when I attempt any maven execution on my machine 
>>> OS X 10.12.3 using maven 3.3.9 and:
>>>
>>> $java -version
>>> java version "1.6.0_65"
>>> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
>>> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
>>>
>>> It feels to me like a java-1.6/maven incompatibility.
>>
>> Maven 3.3.9 requires Java 1.7
>>
>> However that job uses Maven 2.2.5 and it used to work until a few days ago.
>
> It looks like it’s using Maven 3.2.5:
>
> "/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging 
> jenkins.maven3.agent.Maven32Main"
>

Sorry typo, 3.2.5 is what I meant.
It still only requires Java 1.6

http://maven.apache.org/docs/history.html

>>
>> The failure occurs before Maven is started.
>>
 On Feb 21, 2017, at 10:07 AM, sebb  wrote:

 Seems to be a bug in Jenkins - this is before Maven is even invoked,
 and Validator used to build fine with 1.6.
 Raised INFRA-13556

 On 21 February 2017 at 15:00, Apache Jenkins Server
  wrote:
> See 
>
> --
> Started by user sebb
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-1 (ubuntu) in workspace 
> 
> Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk 
> at revision '2017-02-21T15:00:12.349 +'
> At revision 1783899
>
> No changes for 
> https://svn.apache.org/repos/asf/commons/proper/validator/trunk since the 
> previous build
> Parsing POMs
> Established TCP socket on 32827
> maven32-agent.jar already up to date
> maven32-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
> -Xms256m -cp 
> /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
>  jenkins.maven3.agent.Maven32Main 
> /home/jenkins/tools/maven/apache-maven-3.2.5 
> /home/jenkins/jenkins-slave/slave.jar 
> /home/jenkins/jenkins-slave/maven32-interceptor.jar 
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
> hudson/remoting/Launcher : Unsupported major.minor version 51.0
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>   at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
>   at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>   at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
>   at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
> ERROR: Failed to parse POMs
> java.io.EOFException: unexpected stream termination
>   at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
>   at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
>   at hudson.slaves.Channels.forProcess(Channels.java:115)
>   at 
> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
>   at hudson.maven.ProcessCache.get(ProcessCache.java:236)
>   at 
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
>   at hudson.model.Run.execute(Run.java:1728)
>   at 
> hudson.maven.MavenModuleSetBuild.run(MavenM

Re: Build failed in Jenkins: commons-validator #39

[Rob Tompkins]

> On Feb 21, 2017, at 11:04 AM, sebb  wrote:
> 
>> On 21 February 2017 at 15:53, Rob Tompkins  wrote:
>> 
>>> On Feb 21, 2017, at 10:48 AM, sebb  wrote:
>>> 
>>> On 21 February 2017 at 15:20, Rob Tompkins >> > wrote:
 I actually get this error when I attempt any maven execution on my machine 
 OS X 10.12.3 using maven 3.3.9 and:
 
 $java -version
 java version "1.6.0_65"
 Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
 Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)
 
 It feels to me like a java-1.6/maven incompatibility.
>>> 
>>> Maven 3.3.9 requires Java 1.7
>>> 
>>> However that job uses Maven 2.2.5 and it used to work until a few days ago.
>> 
>> It looks like it’s using Maven 3.2.5:
>> 
>> "/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging 
>> jenkins.maven3.agent.Maven32Main"
>> 
> 
> Sorry typo, 3.2.5 is what I meant.
> It still only requires Java 1.6
> 
> http://maven.apache.org/docs/history.html

Fair, feels like something changed in that maven install then. 

> 
>>> 
>>> The failure occurs before Maven is started.
>>> 
> On Feb 21, 2017, at 10:07 AM, sebb  wrote:
> 
> Seems to be a bug in Jenkins - this is before Maven is even invoked,
> and Validator used to build fine with 1.6.
> Raised INFRA-13556
> 
> On 21 February 2017 at 15:00, Apache Jenkins Server
>  wrote:
>> See 
>> 
>> --
>> Started by user sebb
>> [EnvInject] - Loading node environment variables.
>> Building remotely on ubuntu-1 (ubuntu) in workspace 
>> 
>> Updating https://svn.apache.org/repos/asf/commons/proper/validator/trunk 
>> at revision '2017-02-21T15:00:12.349 +'
>> At revision 1783899
>> 
>> No changes for 
>> https://svn.apache.org/repos/asf/commons/proper/validator/trunk since 
>> the previous build
>> Parsing POMs
>> Established TCP socket on 32827
>> maven32-agent.jar already up to date
>> maven32-interceptor.jar already up to date
>> maven3-interceptor-commons.jar already up to date
>> [commons-validator] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g 
>> -Xms256m -cp 
>> /home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
>>  jenkins.maven3.agent.Maven32Main 
>> /home/jenkins/tools/maven/apache-maven-3.2.5 
>> /home/jenkins/jenkins-slave/slave.jar 
>> /home/jenkins/jenkins-slave/maven32-interceptor.jar 
>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 32827
>> Exception in thread "main" java.lang.UnsupportedClassVersionError: 
>> hudson/remoting/Launcher : Unsupported major.minor version 51.0
>>  at java.lang.ClassLoader.defineClass1(Native Method)
>>  at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>>  at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>>  at 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>>  at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>>  at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>>  at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
>>  at 
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
>>  at 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
>>  at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
>>  at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
>> ERROR: Failed to parse POMs
>> java.io.EOFException: unexpected stream termination
>>  at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
>>  at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
>>  at hudson.slaves.Channels.forProcess(Channels.java:115)
>>  at 
>> hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
>>  at hudson.maven.ProcessCache.get(ProcessCache.java:236)
>>  at 
>> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)

Re: [text] On the value of idempotent string escape methods?

[Bhowmik, Bindul]

On Tue, Feb 21, 2017 at 7:55 AM, sebb  wrote:
> On 21 February 2017 at 12:40, Rob Tompkins  wrote:
>>
>>> On Feb 21, 2017, at 6:02 AM, sebb  wrote:
>>>
>>> On 21 February 2017 at 04:40, Sampanna Kahu >> > wrote:
 Hi Guys,
 Very good points are being made above. Please allow me to add my two cents
 :-)

 What if the string contains syntactically valid HTML characters/tags and
 our aim is to prevent rendering these tags in the browser when this string
 is being served via a web application? Or prevent the execution of harmful
 embedded scripts when serving it? The 'escapeOnce' method could be useful
 here, right?
>>>
>>> I don't think so.
>>>
 To explain better, let's consider an example of the specific use-case that
 I had in mind when building the 'escapeOnce' method:
 Consider the scenario of a simple restful web application where users can
 manipulate their text using simple crud operations. Lets assume that we do
 not have the 'escapeOnce' method yet.
 1. A user comes and submits his string. We escape it and store it in our
 database. If the string had any HTML characters, they would have gotten
 escaped.

 2. After some time, the same user fetches his string, adds some more HTML
 characters and submits it. At this point, although the escape method would
 correctly escape the freshly added HTML characters, it would escape the
 older escaped HTML characters again! (for example > would become
 >)
 And this effect gets magnified if step number 2 above is repeated.
>>>
>>> Of course, that is my point.
>>>
>>> Also remember that you want to show the original string to the user.
>>> That's not possible in general if you use this approach.
>>>
>>> Suppose they originally entered
>>>
>>> "To code ampersand (&) in HTML, use '&'"
>>>
>>> Using escapeOnce, this would become:
>>>
>>> "To code ampersand (&) in HTML, use '&'"
>>>
>>> You can either show that directly to the user, or use an unescapeOnce
>>> and show them:
>>>
>>> "To code ampersand (&) in HTML, use '&'"

I have had this use case in a project (enclosing XML/HTML content in a
XML stream) and the expected output for escapeOnce in this case would
be:
"To code ampersand (&) in HTML, use '&'"

And similarly unsecape once would generate back:
"To code ampersand (&) in HTML, use '&'"

Just my two cents, as I have had to write this code.

>>>
>>> Neither makes any sense.
>>>
 How do we solve the above problem without the 'escapeOnce' method?
>>>
>>> Store the raw string in the database and escape it just before display.
>>>
>>> If you are using Javascript, then use an approach such as this to escape it:
>>>
>>> document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));
>>>
>>> See:
>>>
>>> http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/ 
>>> 
>>>
>>> This has a good discussion of some of the problems.
>>>
>>> ==
>>>
>>> Sorry, but it's not possible in general to do what you want, because
>>> one cannot reliably determine if a string has been escaped just from
>>> looking at the string.
>>
>> Another thought occurred to me (again despite potential lack of value).
>>
>> We should be able to quickly verify if there are any escape strings in the 
>> string in question. A single application of unescape followed by checking 
>> string equality with the original input would yield a predicate on the 
>> existence of escape’s present in the input in question.
>
> Again, what does unescape mean in this context?
> Does it ignore incomplete escape sequences, or throw an error?
>
>> From there we could: (1) escape if no escapes were present in the original, 
>> or (2) throw an exception if there were escapes present in the original 
>> string.
>> Again, this feels contrived, so I’m not really suggesting that we add it. 
>> I’m just playing with ideas here that could accomplish what Sampanna is 
>> going for.
>
> The request is impossible to fulfill reliably, and does not deserve to
> be added to a Commons library.
>
> I don't know why this is still being discussed.
>
>> -Rob
>>
>>>
>>> The most one can do is to sanitise the string by escaping anything
>>> that is unescaped.
>>> However that process corrupts the input - a browser won't display the
>>> proper output.
>>>
 On 20 February 2017 at 21:40, sebb  wrote:

> On 20 February 2017 at 15:36, Rob Tompkins  wrote:
>>
>>> On Feb 20, 2017, at 10:30 AM, sebb  wrote:
>>>
>>> On 20 February 2017 at 14:55, Rob Tompkins  wrote:

> On Feb 20, 2017, at 4:31 AM, sebb  wrote:
>
> On 19 February 2017 at 14:29, Raymond DeCampo  > wrote:
>> I am trying to see how having the proposed unescape() method leads
> to an a
>> useful escape method.
>>
>> E.g. cle

Build failed in Jenkins: commons-validator #40

[Apache Jenkins Server]

See 

--
Started by user pono
[EnvInject] - Loading node environment variables.
ERROR: SEVERE ERROR occurs
org.jenkinsci.lib.envinject.EnvInjectException: 
hudson.remoting.ChannelClosedException: channel is already closed
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:79)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:80)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:42)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:572)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:492)
at hudson.model.Run.execute(Run.java:1728)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Caused by: hudson.remoting.ChannelClosedException: channel is already closed
at hudson.remoting.Channel.send(Channel.java:604)
at hudson.remoting.Request.call(Request.java:130)
at hudson.remoting.Channel.call(Channel.java:821)
at hudson.FilePath.act(FilePath.java:1080)
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvironmentVariablesNode(EnvironmentVariablesNodeLoader.java:48)
... 8 more
Caused by: java.io.IOException
at hudson.remoting.Channel.close(Channel.java:1284)
at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:115)
at hudson.remoting.PingThread.ping(PingThread.java:130)
at hudson.remoting.PingThread.run(PingThread.java:86)
Caused by: java.util.concurrent.TimeoutException: Ping started at 1487712527382 
hasn't completed by 1487712767383
... 2 more
[EnvInject] - [ERROR] - SEVERE ERROR occurs: channel is already closed

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

Re: [text] On the value of idempotent string escape methods?

[Chas Honton]

Not sufficiently useful to include in commons. 

Chas

> On Feb 21, 2017, at 1:31 PM, Bhowmik, Bindul  wrote:
> 
>> On Tue, Feb 21, 2017 at 7:55 AM, sebb  wrote:
>>> On 21 February 2017 at 12:40, Rob Tompkins  wrote:
>>> 
 On Feb 21, 2017, at 6:02 AM, sebb  wrote:
 
 On 21 February 2017 at 04:40, Sampanna Kahu >>> > wrote:
> Hi Guys,
> Very good points are being made above. Please allow me to add my two cents
> :-)
> 
> What if the string contains syntactically valid HTML characters/tags and
> our aim is to prevent rendering these tags in the browser when this string
> is being served via a web application? Or prevent the execution of harmful
> embedded scripts when serving it? The 'escapeOnce' method could be useful
> here, right?
 
 I don't think so.
 
> To explain better, let's consider an example of the specific use-case that
> I had in mind when building the 'escapeOnce' method:
> Consider the scenario of a simple restful web application where users can
> manipulate their text using simple crud operations. Lets assume that we do
> not have the 'escapeOnce' method yet.
> 1. A user comes and submits his string. We escape it and store it in our
> database. If the string had any HTML characters, they would have gotten
> escaped.
> 
> 2. After some time, the same user fetches his string, adds some more HTML
> characters and submits it. At this point, although the escape method would
> correctly escape the freshly added HTML characters, it would escape the
> older escaped HTML characters again! (for example > would become
> >)
> And this effect gets magnified if step number 2 above is repeated.
 
 Of course, that is my point.
 
 Also remember that you want to show the original string to the user.
 That's not possible in general if you use this approach.
 
 Suppose they originally entered
 
 "To code ampersand (&) in HTML, use '&'"
 
 Using escapeOnce, this would become:
 
 "To code ampersand (&) in HTML, use '&'"
 
 You can either show that directly to the user, or use an unescapeOnce
 and show them:
 
 "To code ampersand (&) in HTML, use '&'"
> 
> I have had this use case in a project (enclosing XML/HTML content in a
> XML stream) and the expected output for escapeOnce in this case would
> be:
> "To code ampersand (&) in HTML, use '&'"
> 
> And similarly unsecape once would generate back:
> "To code ampersand (&) in HTML, use '&'"
> 
> Just my two cents, as I have had to write this code.
> 
 
 Neither makes any sense.
 
> How do we solve the above problem without the 'escapeOnce' method?
 
 Store the raw string in the database and escape it just before display.
 
 If you are using Javascript, then use an approach such as this to escape 
 it:
 
 document.getElementById("whereItGoes").appendChild(document.createTextNode(unsafe_str));
 
 See:
 
 http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/ 
 
 
 This has a good discussion of some of the problems.
 
 ==
 
 Sorry, but it's not possible in general to do what you want, because
 one cannot reliably determine if a string has been escaped just from
 looking at the string.
>>> 
>>> Another thought occurred to me (again despite potential lack of value).
>>> 
>>> We should be able to quickly verify if there are any escape strings in the 
>>> string in question. A single application of unescape followed by checking 
>>> string equality with the original input would yield a predicate on the 
>>> existence of escape’s present in the input in question.
>> 
>> Again, what does unescape mean in this context?
>> Does it ignore incomplete escape sequences, or throw an error?
>> 
>>> From there we could: (1) escape if no escapes were present in the original, 
>>> or (2) throw an exception if there were escapes present in the original 
>>> string.
>>> Again, this feels contrived, so I’m not really suggesting that we add it. 
>>> I’m just playing with ideas here that could accomplish what Sampanna is 
>>> going for.
>> 
>> The request is impossible to fulfill reliably, and does not deserve to
>> be added to a Commons library.
>> 
>> I don't know why this is still being discussed.
>> 
>>> -Rob
>>> 
 
 The most one can do is to sanitise the string by escaping anything
 that is unescaped.
 However that process corrupts the input - a browser won't display the
 proper output.
 
>> On 20 February 2017 at 21:40, sebb  wrote:
>> 
>>> On 20 February 2017 at 15:36, Rob Tompkins  wrote:
>>> 
 On Feb 20, 2017, at 10:30 AM, sebb  wrote:
 
 On 20 February 2017 at 14:55, Rob Tompkins  wrote:
> 
>> On