[jira] [Resolved] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr resolved PDFBOX-3938.
-
Resolution: Fixed

> Add test from PDFBOX-2079 to 2.0 and trunk
> --
>
> Key: PDFBOX-3938
> URL: https://issues.apache.org/jira/browse/PDFBOX-3938
> Project: PDFBox
>  Issue Type: Task
>  Components: Parsing
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.8, 3.0.0
>
>
> That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
> turned out that a regression was not detected. I am adding it to 2.0 and 
> trunk to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Jenkins build is back to normal : PDFBox-2.0.x #697

2017-09-20 Thread Apache Jenkins Server 
See 


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

Jenkins build is back to stable : PDFBox-trunk » Apache PDFBox #3562

2017-09-20 Thread Apache Jenkins Server 
See 



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

Jenkins build is back to stable : PDFBox-trunk #3562

2017-09-20 Thread Apache Jenkins Server 
See 



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

[jira] [Commented] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809058 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1809058 ]

PDFBOX-3938: create output directory

> Add test from PDFBOX-2079 to 2.0 and trunk
> --
>
> Key: PDFBOX-3938
> URL: https://issues.apache.org/jira/browse/PDFBOX-3938
> Project: PDFBox
>  Issue Type: Task
>  Components: Parsing
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.8, 3.0.0
>
>
> That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
> turned out that a regression was not detected. I am adding it to 2.0 and 
> trunk to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809057 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1809057 ]

PDFBOX-3938: create output directory

> Add test from PDFBOX-2079 to 2.0 and trunk
> --
>
> Key: PDFBOX-3938
> URL: https://issues.apache.org/jira/browse/PDFBOX-3938
> Project: PDFBox
>  Issue Type: Task
>  Components: Parsing
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.8, 3.0.0
>
>
> That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
> turned out that a regression was not detected. I am adding it to 2.0 and 
> trunk to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Jenkins build is unstable: PDFBox-trunk #3561

2017-09-20 Thread Apache Jenkins Server 
See 



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

Jenkins build is unstable: PDFBox-trunk » Apache PDFBox #3561

2017-09-20 Thread Apache Jenkins Server 
See 



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

Build failed in Jenkins: PDFBox-2.0.x #696

2017-09-20 Thread Apache Jenkins Server 
See 

--
[...truncated 11.10 KB...]
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
at 
org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
at 
org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1001)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:977)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:953)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2739)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3051)
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2782)
at 
org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$9.runSynchronized(SqlJetEngine.java:475)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:471)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:206)
... 28 more
ERROR: Subversion update failed
org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3051)
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2782)
at 
org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$9.runSynchronized(SqlJetEngine.java:475)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:471)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:206)
Caused: org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at

Build failed in Jenkins: PDFBox-2.0.x #695

2017-09-20 Thread Apache Jenkins Server 
See 

--
[...truncated 11.18 KB...]
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
at 
org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
at 
org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1001)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:977)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:953)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2739)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3051)
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2782)
at 
org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$9.runSynchronized(SqlJetEngine.java:475)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:471)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:206)
... 28 more
ERROR: Subversion update failed
org.tmatesoft.sqljet.core.SqlJetException: FULL: error code is FULL
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.openJournal(SqlJetPager.java:3051)
at 
org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.begin(SqlJetPager.java:2782)
at 
org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:931)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:561)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:55)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$9.runSynchronized(SqlJetEngine.java:475)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
at 
org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:471)
at 
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:206)
Caused: org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at

[jira] [Commented] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809054 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1809054 ]

PDFBOX-3938: add testcase from issue 2079 by Tim Allison

> Add test from PDFBOX-2079 to 2.0 and trunk
> --
>
> Key: PDFBOX-3938
> URL: https://issues.apache.org/jira/browse/PDFBOX-3938
> Project: PDFBox
>  Issue Type: Task
>  Components: Parsing
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.8, 3.0.0
>
>
> That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
> turned out that a regression was not detected. I am adding it to 2.0 and 
> trunk to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809053 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1809053 ]

PDFBOX-3938: add testcase from issue 2079 by Tim Allison

> Add test from PDFBOX-2079 to 2.0 and trunk
> --
>
> Key: PDFBOX-3938
> URL: https://issues.apache.org/jira/browse/PDFBOX-3938
> Project: PDFBox
>  Issue Type: Task
>  Components: Parsing
>Affects Versions: 2.0.7
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 2.0.8, 3.0.0
>
>
> That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
> turned out that a regression was not detected. I am adding it to 2.0 and 
> trunk to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PDFBOX-3938) Add test from PDFBOX-2079 to 2.0 and trunk

2017-09-20 Thread Tilman Hausherr (JIRA) 
Tilman Hausherr created PDFBOX-3938:
---

 Summary: Add test from PDFBOX-2079 to 2.0 and trunk
 Key: PDFBOX-3938
 URL: https://issues.apache.org/jira/browse/PDFBOX-3938
 Project: PDFBox
  Issue Type: Task
  Components: Parsing
Affects Versions: 2.0.7
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
 Fix For: 2.0.8, 3.0.0


That test from PDFBOX-2079 has been added to 1.8 in PDFBOX-3933 because it 
turned out that a regression was not detected. I am adding it to 2.0 and trunk 
to prevent any possible future work to produce an undetected regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809046 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1809046 ]

PDFBOX-2852: split long method

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

2017-09-20 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1809045 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1809045 ]

PDFBOX-2852: split long method

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PDFBOX-3933) PDFParser swallows a CR at the end of a stream

2017-09-20 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr resolved PDFBOX-3933.
-
   Resolution: Fixed
 Assignee: Tilman Hausherr
Fix Version/s: 1.8.14

> PDFParser swallows a CR at the end of a stream
> --
>
> Key: PDFBOX-3933
> URL: https://issues.apache.org/jira/browse/PDFBOX-3933
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing
>Affects Versions: 1.8.13
>Reporter: Petr Slaby
>Assignee: Tilman Hausherr
> Fix For: 1.8.14
>
> Attachments: Beispiel2.pdf, EndlinePrediction2.patch, 
> EndlinePrediction.patch
>
>
> I have a PDF which I cannot share at the moment, maybe later if I get a 
> permission from the customer. 
> The PDF is protected by an empty password, all streams are encrypted using 
> AES. The PDF consistently uses the LF character for line endings. One of the 
> streams looks like this:
> {code}
> 10 0 obj
> <>
> stream
> <0x0D><0x0A>
> endstream
> {code}
> i.e. Length field is a reference to an object, in the content, the length 
> object is stored immediately after the stream as
> {code}
> 9 0 obj
> 2624
> endobj
> {code}
> The byte <0x0D> belongs to the stream and is not to be treated as line 
> separator in this case. The parser is not able to read the length field so it 
> manually searches for the stream end in the class EndstreamOutputStream. This 
> class searches both for the pair <0x0D><0x0A> and the single <0x0A>, so it 
> strips off the <0x0D> from this particular stream content. Since the stream 
> is encrypted, PDFBox runs into a BadPaddingException later on when trying to 
> decrypt the stream.
> The problem is reproducible using org.apache.pdfbox.PDFToImage in current 
> 1.8.14-SNAPSHOT. The same works fine in current PDFBox 2.0.x, presumably 
> because it uses the non-sequential parser by default.
> The proposed fix is to analyze the PDF content while reading it and search 
> for the CR character only if it was ever encountered as a line separator 
> prior to the stream being parsed.
> Note: I do not exactly know or understand the usage of the other classes 
> inherited from BaseParser, like PDFObjectStreamParser. Maybe the line ending 
> heuristic should be kept "as before" in these classes, by setting the new 
> field BaseParser.hasCR to true already in the constructor.
> A patch is attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PDFBOX-3933) PDFParser swallows a CR at the end of a stream

2017-09-20 Thread Tilman Hausherr (JIRA) 

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

Tilman Hausherr commented on PDFBOX-3933:
-

Tests for sequential parser went fine.

I decided not to do the change for 2.0.*. The code would be different, 
skipWhiteSpaces() is done in the base class thanks to refactoring so we would 
have to either set some global variable (and break the "do one thing" rule) or 
copy the code into parseCOSStream(), which would be a step backwards. It is 
possible to create a file that would trigger the effect (e.g. by replacing the 
"L" in "/Length 9 0 R" in your file with "X"), there is no such file in the 
wild.

However I'll add the test from Tim Allison to 2.0+trunk in a separate issue. 
(Adding it here would result in a misleading release note entry)

> PDFParser swallows a CR at the end of a stream
> --
>
> Key: PDFBOX-3933
> URL: https://issues.apache.org/jira/browse/PDFBOX-3933
> Project: PDFBox
>  Issue Type: Bug
>  Components: Parsing
>Affects Versions: 1.8.13
>Reporter: Petr Slaby
> Attachments: Beispiel2.pdf, EndlinePrediction2.patch, 
> EndlinePrediction.patch
>
>
> I have a PDF which I cannot share at the moment, maybe later if I get a 
> permission from the customer. 
> The PDF is protected by an empty password, all streams are encrypted using 
> AES. The PDF consistently uses the LF character for line endings. One of the 
> streams looks like this:
> {code}
> 10 0 obj
> <>
> stream
> <0x0D><0x0A>
> endstream
> {code}
> i.e. Length field is a reference to an object, in the content, the length 
> object is stored immediately after the stream as
> {code}
> 9 0 obj
> 2624
> endobj
> {code}
> The byte <0x0D> belongs to the stream and is not to be treated as line 
> separator in this case. The parser is not able to read the length field so it 
> manually searches for the stream end in the class EndstreamOutputStream. This 
> class searches both for the pair <0x0D><0x0A> and the single <0x0A>, so it 
> strips off the <0x0D> from this particular stream content. Since the stream 
> is encrypted, PDFBox runs into a BadPaddingException later on when trying to 
> decrypt the stream.
> The problem is reproducible using org.apache.pdfbox.PDFToImage in current 
> 1.8.14-SNAPSHOT. The same works fine in current PDFBox 2.0.x, presumably 
> because it uses the non-sequential parser by default.
> The proposed fix is to analyze the PDF content while reading it and search 
> for the CR character only if it was ever encountered as a line separator 
> prior to the stream being parsed.
> Note: I do not exactly know or understand the usage of the other classes 
> inherited from BaseParser, like PDFObjectStreamParser. Maybe the line ending 
> heuristic should be kept "as before" in these classes, by setting the new 
> field BaseParser.hasCR to true already in the constructor.
> A patch is attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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