[jira] [Closed] (DBUTILS-134) Why not BeanListHandler extends AbstractListHandler?
[ https://issues.apache.org/jira/browse/DBUTILS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n3verl4nd closed DBUTILS-134. - Resolution: Duplicate > Why not BeanListHandler extends AbstractListHandler? > > > Key: DBUTILS-134 > URL: https://issues.apache.org/jira/browse/DBUTILS-134 > Project: Commons DbUtils > Issue Type: Wish >Reporter: n3verl4nd > > Why not BeanListHandler extends AbstractListHandler? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DBUTILS-134) Why not BeanListHandler extends AbstractListHandler?
n3verl4nd created DBUTILS-134: - Summary: Why not BeanListHandler extends AbstractListHandler? Key: DBUTILS-134 URL: https://issues.apache.org/jira/browse/DBUTILS-134 Project: Commons DbUtils Issue Type: Wish Reporter: n3verl4nd Why not BeanListHandler extends AbstractListHandler? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IMAGING-204) reading monochrome TIFF leads to unhandled exception
Thomas Elsner created IMAGING-204:
-
Summary: reading monochrome TIFF leads to unhandled exception
Key: IMAGING-204
URL: https://issues.apache.org/jira/browse/IMAGING-204
Project: Commons Imaging
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0
Reporter: Thomas Elsner
reading monochrome TIFF doesn't work.
wrong function getSamplesAsBytes(bis, samples);
Here with having 1 Bit per Pixel it returns value samples[0] = 255 instead of 1.
Then photometricInterpreter.interpretPixel(imageBuilder, samples, x, y); has a
problem
public void interpretPixel(final ImageBuilder imageBuilder, final int[]
samples, final int x,
final int y) throws ImageReadException, IOException {
imageBuilder.setRGB(x, y, indexColorMap[samples[0]]);
}
as the indexColorMaps only has two entries (black and white), but not 256
entries
The same problem will occur as the colour does not have 8 Bit.
The fix seems simple:
In routine
void getSamplesAsBytes(final BitInputStream bis, final int[] result) throws
IOException {
for (int i = 0; i < bitsPerSample.length; i++) {
final int bits = bitsPerSample[i];
int sample = bis.readBits(bits);
if (bits < 8) {
final int sign = sample & 1;
sample = sample << (8 - bits); // scale to byte.
if (sign > 0) {
sample = sample | ((1 << (8 - bits)) - 1); // extend to byte
}
}...
if 'sign>0' don't fill up to 8 bits, but to 'bits' amount of '1'.
I am not sure about other side effects, so I post this suggestion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JELLY-293) Accommodate toggling off DTD external entities.
[
https://issues.apache.org/jira/browse/JELLY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139912#comment-16139912
]
Rob Tompkins commented on JELLY-293:
Code is in SVN under the following commit:
{code}
svn commit -m "JELLY-293: accommodating toggling off DTD external entities"
Sending.
Sendingbuild.xml
Adding pom.xml
Sendingsrc/java/org/apache/commons/jelly/JellyContext.java
Sendingsrc/java/org/apache/commons/jelly/parser/XMLParser.java
Adding src/test/org/apache/commons/jelly/TestDoctypeDefinitionXXE.java
Adding src/test/org/apache/commons/jelly/doctypeDefinitionXXE.jelly
Sendingxdocs/changes.xml
Transmitting file data ...done
Committing transaction...
Committed revision 1806026.
{code}
> Accommodate toggling off DTD external entities.
> ---
>
> Key: JELLY-293
> URL: https://issues.apache.org/jira/browse/JELLY-293
> Project: Commons Jelly
> Issue Type: Bug
> Components: core / taglib.core
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.0.1
>
>
> We want the ability to configure whether or not jelly files can be declared
> such that the doctype definition at the beginning of the XML can call out to
> external entities under the parsing by SAX in the xerces project.
> The suggested fix is to add
> {code:java}
> if (!allowDtdToCallExternalEntities) {
>
> reader.setFeature("http://xml.org/sax/features/external-general-entities;,
> false);
>
> reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
> false);
>
> reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
> false);
> }
> {code}
> immediately following this line:
> https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JELLY-293) Accommodate toggling off DTD external entities.
[
https://issues.apache.org/jira/browse/JELLY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated JELLY-293:
---
Assignee: Rob Tompkins
> Accommodate toggling off DTD external entities.
> ---
>
> Key: JELLY-293
> URL: https://issues.apache.org/jira/browse/JELLY-293
> Project: Commons Jelly
> Issue Type: Bug
> Components: core / taglib.core
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.0.1
>
>
> We want the ability to configure whether or not jelly files can be declared
> such that the doctype definition at the beginning of the XML can call out to
> external entities under the parsing by SAX in the xerces project.
> The suggested fix is to add
> {code:java}
> if (!allowDtdToCallExternalEntities) {
>
> reader.setFeature("http://xml.org/sax/features/external-general-entities;,
> false);
>
> reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
> false);
>
> reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
> false);
> }
> {code}
> immediately following this line:
> https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JELLY-293) Accommodate toggling off DTD external entities.
[
https://issues.apache.org/jira/browse/JELLY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated JELLY-293:
---
Description:
We want the ability to configure whether or not jelly files can be declared
such that the doctype definition at the beginning of the XML can call out to
external entities under the parsing by SAX in the xerces project.
The suggested fix is to add
{code:java}
if (!allowDtdToCallExternalEntities) {
reader.setFeature("http://xml.org/sax/features/external-general-entities;,
false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
false);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
false);
}
{code}
immediately following this line:
https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
was:
We want the ability to configure whether or not jelly files can be declared
such that the doctype definition at the beginning of the XML can call out to
external entities under the parsing by SAX in the xerces project.
The suggested fix is to add
{code:java}
if (!allowDtdToCallExternalEntities) {
reader.setFeature("http://xml.org/sax/features/external-general-entities;,
false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
false);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
false);
}
{code}
immediately following this line:
https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
> Accommodate toggling off DTD external entities.
> ---
>
> Key: JELLY-293
> URL: https://issues.apache.org/jira/browse/JELLY-293
> Project: Commons Jelly
> Issue Type: Bug
> Components: core / taglib.core
>Affects Versions: 1.0
>Reporter: Rob Tompkins
> Fix For: 1.0.1
>
>
> We want the ability to configure whether or not jelly files can be declared
> such that the doctype definition at the beginning of the XML can call out to
> external entities under the parsing by SAX in the xerces project.
> The suggested fix is to add
> {code:java}
> if (!allowDtdToCallExternalEntities) {
>
> reader.setFeature("http://xml.org/sax/features/external-general-entities;,
> false);
>
> reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
> false);
>
> reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
> false);
> }
> {code}
> immediately following this line:
> https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JELLY-293) Accommodate toggling off DTD external entities.
Rob Tompkins created JELLY-293:
--
Summary: Accommodate toggling off DTD external entities.
Key: JELLY-293
URL: https://issues.apache.org/jira/browse/JELLY-293
Project: Commons Jelly
Issue Type: Bug
Components: core / taglib.core
Affects Versions: 1.0
Reporter: Rob Tompkins
Fix For: 1.0.1
We want the ability to configure whether or not jelly files can be declared
such that the doctype definition at the beginning of the XML can call out to
external entities under the parsing by SAX in the xerces project.
The suggested fix is to add
{code:java}
if (!allowDtdToCallExternalEntities) {
reader.setFeature("http://xml.org/sax/features/external-general-entities;,
false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities;,
false);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd;,
false);
}
{code}
immediately following this line:
https://github.com/apache/commons-jelly/blob/commons-jelly-1.0/src/java/org/apache/commons/jelly/parser/XMLParser.java#L496
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139746#comment-16139746
]
L commented on VFS-640:
---
Well, if it is called recursively for layered filesystems, it is *different*
provider, I guess.
And as for the original case: it was an SFTP provider where the server had a
lot of files (like more than 2000) in the root directory for the user.
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
> Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139702#comment-16139702
]
Bernd Eckenfels commented on VFS-640:
-
@L can younger us what provider in your original case caused the delay, maybe
we should fix that anyway and move the connect to doAttach
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
> Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139696#comment-16139696
]
Bernd Eckenfels commented on VFS-640:
-
We need to be careful in case it is called recursively for layered filesystems.
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
> Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139687#comment-16139687
]
L edited comment on VFS-640 at 8/24/17 7:19 AM:
Avoiding slow connection would be nice but unfortunately we do not have that
luxury.
I have created a patch for our internal use, see attachment. Some notes:
# The patch is based on 2.1 release and not on trunk.
# I tried to keep the code style but I did not verify it.
# It is indeed a lock keyed by the same key as the FileSystem. Its lifetime is
almost the same as lifetime of the corresponding FileSystem: it is created
before the FileSystem but is normally destroyed together with the FileSystem in
AbstractFileProvider.closeFileSystem()
# The lock is ref-counted to support scenarios when creating a FileSystem
fails. In this case the lock is destroyed when ref count goes to 0.
# All the lock management happens under in AbstractFileProvider synchronized
(fileSystems), no new synchronization objects are created.
# There is no deadlock. There are only two lock patterns: either "synchronized
(fileSystems)" or "synchronized (newLock), synchronized (fileSystems)"
# There is also a test (ParallelConnTest.java). The test has two methods, to
test the sequential behavior (the same key) and the parallel behavior
(different keys).
was (Author: klv_m72):
Avoiding slow connection would be nice but unfortunately we do not have that
luxury.
I have created a patch for our internal use, see attachment. Some notes:
# The patch is based on 2.1 release and not on trunk.
# I tried to keep the code style but I did not verify it.
# It is indeed a lock keyed by the same key as the FileSystem. Its lifetime is
almost the same as lifetime of the corresponding FileSystem: it is created
before the FileSystem but is normally destroyed together with the FileSystem in
AbstractFileProvider.closeFileSystem()
# The lock is ref-counted to support scenarios when creating a FileSystem
fails. In this case the lock is destroyed when ref count goes to 0.
# All the lock management happens under in AbstractFileProvider synchronized
(fileSystems), no new synchronization objects are created.
# There is no deadlock. There are only two lock patterns: either "synchronized
(fileSystems)" or "synchronized (newLock), synchronized (fileSystems)"
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
> Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
L updated VFS-640:
--
Attachment: patch_VFS640.diff
ParallelConnTest.java
patch_VFS640.diff: the patch
ParallelConnTest.java: the test
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
> Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
[
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139687#comment-16139687
]
L commented on VFS-640:
---
Avoiding slow connection would be nice but unfortunately we do not have that
luxury.
I have created a patch for our internal use, see attachment. Some notes:
# The patch is based on 2.1 release and not on trunk.
# I tried to keep the code style but I did not verify it.
# It is indeed a lock keyed by the same key as the FileSystem. Its lifetime is
almost the same as lifetime of the corresponding FileSystem: it is created
before the FileSystem but is normally destroyed together with the FileSystem in
AbstractFileProvider.closeFileSystem()
# The lock is ref-counted to support scenarios when creating a FileSystem
fails. In this case the lock is destroyed when ref count goes to 0.
# All the lock management happens under in AbstractFileProvider synchronized
(fileSystems), no new synchronization objects are created.
# There is no deadlock. There are only two lock patterns: either "synchronized
(fileSystems)" or "synchronized (newLock), synchronized (fileSystems)"
> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> ---
>
> Key: VFS-640
> URL: https://issues.apache.org/jira/browse/VFS-640
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: L
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
> protected synchronized FileSystem getFileSystem(final FileName rootName,
> final FileSystemOptions fileSystemOptions)
> throws FileSystemException
> {
> FileSystem fs = findFileSystem(rootName, fileSystemOptions);
> if (fs == null)
> {
> // Need to create the file system, and cache it
> fs = doCreateFileSystem(rootName, fileSystemOptions);
> addFileSystem(rootName, fs);
> }
> return fs;
> }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow
> server that is being accessed first time will block *all* other threads
> trying to access some other resources via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
> do not mind the thread trying to access this method taking that long, but
> because of that "synchronized" we end up having multiple threads accessing
> unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same
> "provider-scoped" lock is present in AbstractLayeredFileProvider,
> TemporaryFileProvider, and UrlFileProvider
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
