Minimum Java version for PDFBox 3.x

[axh]

Hi,

I am developing a software that relies heavily on Apache PdfBox. It uses the 
current the current PDFBox 3.0.0 from trunk, with some patches.

I wanted to know what your thoughts are about raising the minimum Java version 
for PDFBox 3.x to Java 11. I know some might say "we are still on JDK 8 and 
will be for the foreseeable future“. But then you could probably stay on the 
2.x line of PDFBox, since you won’t be able to update most of your technology 
stack to recent versions anyway:

 - Spring BOOT 3 requires Java 17
 - WildFly 27 dropped support for Java 8, and while I don’t have access to the 
Redhat docs, I think so will JBOSS 8
 - Hibernate 6 requires at least Java 11
 - Apache Tomcat 6 requires at least Java 11, 6.1 even requires 17
 - Apache Lucene 9.5 requires Java 11

IMHO, the next major version a.k.a. PDFBox 3.0.0 would be the right moment to 
increase the required Java version.

- PDFBox uses classes and methods that are deprecated in newer Java versions.
- IMHO it will also be harder to get contributors.
- Some things have to be done in a cumbersome and less performant way to 
maintain Java 8 compatibility because functionality introduced in newer JDKs 
cannot be used to keep Java 8 compatibility:
Java 8 (current implementation):
public static byte[] toByteArray(InputStream in) throws IOException
{
ByteArrayOutputStream baout = new ByteArrayOutputStream();
copy(in, baout);
return baout.toByteArray();
}
public static long copy(InputStream input, OutputStream output) throws 
IOException
{
byte[] buffer = new byte[4096];
long count = 0;
int n = 0;
while (-1 != (n = input.read(buffer)))
{
output.write(buffer, 0, n);
count += n;
}
return count;
}
Java 11:
public static byte[] toByteArray(InputStream in) throws IOException {
return in.readAllBytes();
}
public static long copy(InputStream input, OutputStream output) throws 
IOException {
return input.transferTo(output);
}

I would like to contribute to PDFBox, but would really suggest to bump the 
required Java version to Java 11. I personally would be OK with going directly 
to 17 like Spring framework did, but I can see that Java 11 compatibility might 
be a serious issue for some.

What are your thoughts on this matter?

Axel

[GitHub] [pdfbox] xzel23 opened a new pull request, #157: Fix log issues

[via GitHub]

xzel23 opened a new pull request, #157:
URL: https://github.com/apache/pdfbox/pull/157

   I fixed some smaller problems with logging in trunk:
   - GlyphRenderer conditions and logging calls did not match leading to 
unnecessary string formatting when log level is debug
   - BidiTest logger was initialized with the wrong class
   - InvalidFileTest used a non-static, non-final logger without reason


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [pdfbox] xzel23 opened a new pull request, #158: small code cleanups

[via GitHub]

xzel23 opened a new pull request, #158:
URL: https://github.com/apache/pdfbox/pull/158

   - in some places, unnecessary explicit boxing/unboxing was done
   - I replaced some XXX.valueOf(String) calls with the corresponding 
XXX.parseXXX(String) calls. XXX.valueOf() always returns a boxed value, but 
when that is assigned to a primitive, the boxing/unboxing is needless.
   - added generics information or the diamond operator ('<>') so that IDEs 
keep silent about using raw types
   - replaced explicit generic parameters with diamond operator where applicable
   - changed String.indexOf(...)==0 with String.contains(...) in one place


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

Validation issue involving AATL/EUTL certificates

[Constantine Dokolas]

Hello everyone.

I'm trying to validate a PDF that involves the AATL (Adobe Approved Trust
List). Acrobat says "Source of trust obtained from Adobe Approved Trust
List  (AATL)". I'm using the Apache CXF 2.4.9 example validation code. This
is the first time it could not verify the signature, throwing a "No root
certificate in the chain".

I can see the comment in SigUtils mentioning that trusted lists are not
being taken into account and mentioning PDFBOX-3017.

As a note, I've managed to figure out how to retrieve the AATL/EUTL
certificates.

Any suggestions?
Constantine

Re: Minimum Java version for PDFBox 3.x

[Andreas Lehmkuehler]

Am 17.03.23 um 10:09 schrieb axh:

Hi,

I am developing a software that relies heavily on Apache PdfBox. It uses the 
current the current PDFBox 3.0.0 from trunk, with some patches.

I wanted to know what your thoughts are about raising the minimum Java version for 
PDFBox 3.x to Java 11. I know some might say "we are still on JDK 8 and will be 
for the foreseeable future“. But then you could probably stay on the 2.x line of 
PDFBox, since you won’t be able to update most of your technology stack to recent 
versions anyway:

  - Spring BOOT 3 requires Java 17
  - WildFly 27 dropped support for Java 8, and while I don’t have access to the 
Redhat docs, I think so will JBOSS 8
  - Hibernate 6 requires at least Java 11
  - Apache Tomcat 6 requires at least Java 11, 6.1 even requires 17

Has to be a typo, Tomcat 9 or 10 are the recent to be used. ;-)


  - Apache Lucene 9.5 requires Java 11

IMHO, the next major version a.k.a. PDFBox 3.0.0 would be the right moment to 
increase the required Java version.
Yes, but I don't see any reason to do so. The trunk version works fine with java 
19 and 20. As long as we don't really need any java9 or later feature I tend to 
stick with java8. We don't have to switch just because others are doing so ;-)


Andreas



- PDFBox uses classes and methods that are deprecated in newer Java versions.
- IMHO it will also be harder to get contributors.
- Some things have to be done in a cumbersome and less performant way to 
maintain Java 8 compatibility because functionality introduced in newer JDKs 
cannot be used to keep Java 8 compatibility:
 Java 8 (current implementation):
 public static byte[] toByteArray(InputStream in) throws IOException
 {
 ByteArrayOutputStream baout = new ByteArrayOutputStream();
 copy(in, baout);
 return baout.toByteArray();
 }
 public static long copy(InputStream input, OutputStream output) throws 
IOException
 {
 byte[] buffer = new byte[4096];
 long count = 0;
 int n = 0;
 while (-1 != (n = input.read(buffer)))
 {
 output.write(buffer, 0, n);
 count += n;
 }
 return count;
 }
 Java 11:
 public static byte[] toByteArray(InputStream in) throws IOException {
 return in.readAllBytes();
 }
 public static long copy(InputStream input, OutputStream output) throws 
IOException {
 return input.transferTo(output);
 }

I would like to contribute to PDFBox, but would really suggest to bump the 
required Java version to Java 11. I personally would be OK with going directly 
to 17 like Spring framework did, but I can see that Java 11 compatibility might 
be a serious issue for some.

What are your thoughts on this matter?

Axel





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

Re: Minimum Java version for PDFBox 3.x

[axh]

Hi Andreas,

you are right about the typo, it’s Tomcat 9.1 that drops Java 8 support and 
requires at least Java 11.

What I tried to point out with that list is that IMHO there’s no benefit in 
maintaining compatibility with an outdated Java version.

I think reasons to update are:
 - code can be shorter and more concise in many places
 - it will be easier to find contributors
 - functionality available in newer versions of the JDK does not have to be 
reproduced and later maintained
 - functionality provided by the JDK implementations will in most cases be 
better tested and often more performant
 - functionality deprecated after Java 8 cannot be used because it would impact 
compatibility with newer Java versions while new functionality cannot be used 
because it impacts compatibility with Java 8

Public updates for Java 8 have stopped in march 2022, now one year ago, and 
keeping PDFBox compatible with that version does not come at no cost (see the 
points above), so what’s the point of still supporting it?

And yes, there are more things to brush up. For example Apache commons logging 
has not seen an update in 9 years, is missing functionality, and IMHO should be 
replaced by SLF4J 2 or log4j. But that’s another point (and yes, I’d volunteer 
to do the transition provided there’s a chance to get it in).

Cheers,
Axel


> Am 17.03.2023 um 20:06 schrieb Andreas Lehmkuehler :
> 
> Am 17.03.23 um 10:09 schrieb axh:
>> Hi,
>> I am developing a software that relies heavily on Apache PdfBox. It uses the 
>> current the current PDFBox 3.0.0 from trunk, with some patches.
>> I wanted to know what your thoughts are about raising the minimum Java 
>> version for PDFBox 3.x to Java 11. I know some might say "we are still on 
>> JDK 8 and will be for the foreseeable future“. But then you could probably 
>> stay on the 2.x line of PDFBox, since you won’t be able to update most of 
>> your technology stack to recent versions anyway:
>>  - Spring BOOT 3 requires Java 17
>>  - WildFly 27 dropped support for Java 8, and while I don’t have access to 
>> the Redhat docs, I think so will JBOSS 8
>>  - Hibernate 6 requires at least Java 11
>>  - Apache Tomcat 6 requires at least Java 11, 6.1 even requires 17
> Has to be a typo, Tomcat 9 or 10 are the recent to be used. ;-)
> 
>>  - Apache Lucene 9.5 requires Java 11
>> IMHO, the next major version a.k.a. PDFBox 3.0.0 would be the right moment 
>> to increase the required Java version.
> Yes, but I don't see any reason to do so. The trunk version works fine with 
> java 19 and 20. As long as we don't really need any java9 or later feature I 
> tend to stick with java8. We don't have to switch just because others are 
> doing so ;-)
> 
> Andreas
> 
>> - PDFBox uses classes and methods that are deprecated in newer Java versions.
>> - IMHO it will also be harder to get contributors.
>> - Some things have to be done in a cumbersome and less performant way to 
>> maintain Java 8 compatibility because functionality introduced in newer JDKs 
>> cannot be used to keep Java 8 compatibility:
>> Java 8 (current implementation):
>> public static byte[] toByteArray(InputStream in) throws IOException
>> {
>> ByteArrayOutputStream baout = new ByteArrayOutputStream();
>> copy(in, baout);
>> return baout.toByteArray();
>> }
>> public static long copy(InputStream input, OutputStream output) throws 
>> IOException
>> {
>> byte[] buffer = new byte[4096];
>> long count = 0;
>> int n = 0;
>> while (-1 != (n = input.read(buffer)))
>> {
>> output.write(buffer, 0, n);
>> count += n;
>> }
>> return count;
>> }
>> Java 11:
>> public static byte[] toByteArray(InputStream in) throws IOException {
>> return in.readAllBytes();
>> }
>> public static long copy(InputStream input, OutputStream output) throws 
>> IOException {
>> return input.transferTo(output);
>> }
>> I would like to contribute to PDFBox, but would really suggest to bump the 
>> required Java version to Java 11. I personally would be OK with going 
>> directly to 17 like Spring framework did, but I can see that Java 11 
>> compatibility might be a serious issue for some.
>> What are your thoughts on this matter?
>> Axel
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org 
> 
> For additional commands, e-mail: dev-h...@pdfbox.apache.org 
> 

[jira] [Created] (PDFBOX-5572) fix some logging inconsistencies

[Axel Howind (Jira)]

Axel Howind created PDFBOX-5572:
---

 Summary: fix some logging inconsistencies
 Key: PDFBOX-5572
 URL: https://issues.apache.org/jira/browse/PDFBOX-5572
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 3.0.0 PDFBox
Reporter: Axel Howind


problems with logging:
- in GlyphRenderer, logging calls with level 'Trace' are guarded by 
'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
- the BidiTest logger is initialized with an unrelated class
- InvalidFileTest uses a non-static, non-final logger without reason




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[GitHub] [pdfbox] xzel23 commented on pull request #157: Fix log issues

[via GitHub]

xzel23 commented on PR #157:
URL: https://github.com/apache/pdfbox/pull/157#issuecomment-1474484847

   created [PDFBOX-5572](https://issues.apache.org/jira/browse/PDFBOX-5572) for 
this. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[jira] [Commented] (PDFBOX-5572) fix some logging inconsistencies

[Axel Howind (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702020#comment-17702020
 ] 

Axel Howind commented on PDFBOX-5572:
-

PR with fixes: https://github.com/apache/pdfbox/pull/157

> fix some logging inconsistencies
> 
>
> Key: PDFBOX-5572
> URL: https://issues.apache.org/jira/browse/PDFBOX-5572
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 3.0.0 PDFBox
>Reporter: Axel Howind
>Priority: Minor
>
> problems with logging:
> - in GlyphRenderer, logging calls with level 'Trace' are guarded by 
> 'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
> - the BidiTest logger is initialized with an unrelated class
> - InvalidFileTest uses a non-static, non-final logger without reason



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (PDFBOX-5572) fix some logging inconsistencies

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702054#comment-17702054
 ] 

ASF subversion and git services commented on PDFBOX-5572:
-

Commit 1908464 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1908464 ]

PDFBOX-5572: fix some logging inconsistencies, by Axel Howind

> fix some logging inconsistencies
> 
>
> Key: PDFBOX-5572
> URL: https://issues.apache.org/jira/browse/PDFBOX-5572
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 3.0.0 PDFBox
>Reporter: Axel Howind
>Priority: Minor
>
> problems with logging:
> - in GlyphRenderer, logging calls with level 'Trace' are guarded by 
> 'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
> - the BidiTest logger is initialized with an unrelated class
> - InvalidFileTest uses a non-static, non-final logger without reason



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (PDFBOX-5572) fix some logging inconsistencies

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702055#comment-17702055
 ] 

ASF subversion and git services commented on PDFBOX-5572:
-

Commit 1908465 from Tilman Hausherr in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1908465 ]

PDFBOX-5572: fix some logging inconsistencies, by Axel Howind

> fix some logging inconsistencies
> 
>
> Key: PDFBOX-5572
> URL: https://issues.apache.org/jira/browse/PDFBOX-5572
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 3.0.0 PDFBox
>Reporter: Axel Howind
>Priority: Minor
>
> problems with logging:
> - in GlyphRenderer, logging calls with level 'Trace' are guarded by 
> 'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
> - the BidiTest logger is initialized with an unrelated class
> - InvalidFileTest uses a non-static, non-final logger without reason



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (PDFBOX-5572) fix some logging inconsistencies

[Tilman Hausherr (Jira)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-5572:

Affects Version/s: 2.0.27

> fix some logging inconsistencies
> 
>
> Key: PDFBOX-5572
> URL: https://issues.apache.org/jira/browse/PDFBOX-5572
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.27, 3.0.0 PDFBox
>Reporter: Axel Howind
>Priority: Minor
>
> problems with logging:
> - in GlyphRenderer, logging calls with level 'Trace' are guarded by 
> 'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
> - the BidiTest logger is initialized with an unrelated class
> - InvalidFileTest uses a non-static, non-final logger without reason



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (PDFBOX-5572) fix some logging inconsistencies

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702057#comment-17702057
 ] 

ASF subversion and git services commented on PDFBOX-5572:
-

Commit 1908467 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1908467 ]

PDFBOX-5572: fix some logging inconsistencies, by Axel Howind

> fix some logging inconsistencies
> 
>
> Key: PDFBOX-5572
> URL: https://issues.apache.org/jira/browse/PDFBOX-5572
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.27, 3.0.0 PDFBox
>Reporter: Axel Howind
>Priority: Minor
>
> problems with logging:
> - in GlyphRenderer, logging calls with level 'Trace' are guarded by 
> 'isDebugEnabled()' leading to unnecessary formatting when log level is 'Debug'
> - the BidiTest logger is initialized with an unrelated class
> - InvalidFileTest uses a non-static, non-final logger without reason



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Build failed in Jenkins: PDFBox » PDFBox-trunk #1578

[Apache Jenkins Server]

See 


Changes:

[Tilman Hausherr] PDFBOX-5572: fix some logging inconsistencies, by Axel Howind

[Tilman Hausherr] PDFBOX-5572: fix some logging inconsistencies, by Axel Howind


--
Started by user Tilman Hausherr
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on builds36 (ubuntu) in workspace 

Cleaning up 
Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 
Deleting 

Deleting 

Deleting 
Deleting 

Deleting 

Updating http://svn.apache.org/repos/asf/pdfbox/trunk at revision 
'2023-03-18T04:40:05.448 +' --quiet
At revision 1908467

Parsing POMs
Established TCP socket on 43327
maven35-agent.jar already up to date
maven35-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[PDFBox-trunk] $ /home/jenkins/tools/java/latest1.8/bin/java -cp 
/home/jenkins/maven35-agent.jar:/home/jenkins/tools/maven/apache-maven-3.8.7/boot/plexus-classworlds-2.6.0.jar:/home/jenkins/tools/maven/apache-maven-3.8.7/conf/logging
 jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/apache-maven-3.8.7 
/home/jenkins/agent.jar /home/jenkins/maven35-interceptor.jar 
/home/jenkins/maven3-interceptor-commons.jar 43327
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher has been compiled by a more recent version of the Java 
Runtime (class file version 55.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:425)
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:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:136)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:66)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
at hudson.slaves.Channels.forProcess(Channels.java:121)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:296)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:802)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
at hudson.model.Run.execute(Run.java:1900)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)
Archiving artifacts

-

Build failed in Jenkins: PDFBox » PDFBox-2.0.x #956

[Apache Jenkins Server]

See 


Changes:

[Tilman Hausherr] PDFBOX-5572: fix some logging inconsistencies, by Axel Howind


--
Started by user Tilman Hausherr
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on builds24 (ubuntu) in workspace 

Cleaning up 
Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 
Deleting 

Deleting 

Deleting 

Deleting 

Updating https://svn.apache.org/repos/asf/pdfbox/branches/2.0 at revision 
'2023-03-18T04:40:03.278 +' --quiet
At revision 1908467

Parsing POMs
Established TCP socket on 38605
maven35-agent.jar already up to date
maven35-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[PDFBox-2.0.x] $ /home/jenkins/tools/java/latest1.8/bin/java -cp 
/home/jenkins/jenkins-agent/maven35-agent.jar:/home/jenkins/tools/maven/apache-maven-3.8.6/boot/plexus-classworlds-2.6.0.jar:/home/jenkins/tools/maven/apache-maven-3.8.6/conf/logging
 jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/apache-maven-3.8.6 
/home/jenkins/jenkins-agent/agent.jar 
/home/jenkins/jenkins-agent/maven35-interceptor.jar 
/home/jenkins/jenkins-agent/maven3-interceptor-commons.jar 38605
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher has been compiled by a more recent version of the Java 
Runtime (class file version 55.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:425)
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:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:136)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:66)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
at hudson.slaves.Channels.forProcess(Channels.java:121)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:296)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:802)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
at hudson.model.Run.execute(Run.java:1900)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)
Archiving artifacts

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

Re: Validation issue involving AATL/EUTL certificates

[Tilman Hausherr]

On 17.03.2023 15:58, Constantine Dokolas wrote:

Hello everyone.

I'm trying to validate a PDF that involves the AATL (Adobe Approved Trust
List). Acrobat says "Source of trust obtained from Adobe Approved Trust
List  (AATL)". I'm using the Apache CXF 2.4.9 example validation code. This
is the first time it could not verify the signature, throwing a "No root
certificate in the chain".


Can you share the PDF? ShowSignature tries to retrieve missing issuer 
certificates from URLs in the certificates. The related code is based on 
an older Apache CXF version (because they seemed to have discontinued 
that part) which I later improved.




I can see the comment in SigUtils mentioning that trusted lists are not
being taken into account and mentioning PDFBOX-3017.

As a note, I've managed to figure out how to retrieve the AATL/EUTL
certificates.


I'd be interested in getting AATL certificates. I do have some code that 
takes EUTL certificates, but the weird thing is that not all of them are 
root certificates.


Tilman




Any suggestions?
Constantine




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