[jira] Commented: (IO-137) Added method for getting InputStream from ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation and copy
[ https://issues.apache.org/jira/browse/IO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556358#action_12556358 ] Henri Yandell commented on IO-137: -- >From Niall on [EMAIL PROTECTED]: "I looked at this a while back and using the baos buffers directly in an InputStream raises a safety issue (if the baos is modified while the InputStream is being read) - do we care about that?" I agree that that's the big question here - do we consider the reallocation necessary or unnecessary in the original java.io.BAOS class. Have you seen substantial performance gains from this in your use case, Nikunj? > Added method for getting InputStream from ByteArrayOutputStream & IOUtils > avoiding unnecessary array allocation and copy > > > Key: IO-137 > URL: https://issues.apache.org/jira/browse/IO-137 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers, Utilities >Affects Versions: 1.3.2 > Environment: Any OS with appropriate JVM >Reporter: Nikunj Trivedi > Fix For: 1.4 > > Attachments: baos_to_inputstream.patch, baos_toIstream.patch > > > Patch inclues following two methods and test cases for both. > 1) New Method: ByteArrayOutputStream.toInputStream > ByteArrayOutputStream exposes its byte buffers by toByteArray(), which > creates a fresh buffer and copy existing data to it. > A new method toInputStream() available in patch returns the current contents > of baos, as an InputStream, avoiding unnecessary allocation and copying. > 2) New Method: IOUtils.toFullyBufferedInputStream > There are situations where the InputStream source is available and it has to > be passed to different modules for processing. > It is needed to fetch the full contents of the InputStream in internal > buffer(IOUtils.toByteArray() ), convert this buffer to ByteArrayInputStream > and use that stream instead. But this is wasteful since toByteArray() > requires one fresh allocation and copy operation. > New method copies InputStream to ByteArrayOutputStream and returns > baos.toInputStream(), avoiding unnecessary memory allocation and copy. > Testcases are available in respective classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated IO-153: -- Attachment: io-FileWriterWithEncoding.patch Class and test case > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-153) FileWriter that accepts an encoding
FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (POOL-119) GenericObjectPool: Provide option to create new objects serial
GenericObjectPool: Provide option to create new objects serial -- Key: POOL-119 URL: https://issues.apache.org/jira/browse/POOL-119 Project: Commons Pool Issue Type: New Feature Affects Versions: 1.4 Reporter: Christoph Kutzinski As discussed on the Commons-Dev mailing list: In certain scenarios it is desirable to serialize creation of new objects, if the pool needs to grow. This has 2 main advantages: - help keeping load away from the engine creating the objects (e.g. the database server) during high load situations - avoid unnecessary object creation if objects where returned to pool while multiple 'new' objects are requested from the pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-119) GenericObjectPool: Provide option to create new objects serial
[ https://issues.apache.org/jira/browse/POOL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kutzinski updated POOL-119: - Attachment: patch.txt Patch to GenericObjectPool and TestGenericObjectPool to fix the described issue with a new option 'serialObjectCreation' which defaults to false. > GenericObjectPool: Provide option to create new objects serial > -- > > Key: POOL-119 > URL: https://issues.apache.org/jira/browse/POOL-119 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Christoph Kutzinski > Attachments: patch.txt > > > As discussed on the Commons-Dev mailing list: > In certain scenarios it is desirable to serialize creation of new objects, if > the pool needs to grow. This has 2 main advantages: > - help keeping load away from the engine creating the objects (e.g. the > database server) during high load situations > - avoid unnecessary object creation if objects where returned to pool while > multiple 'new' objects are requested from the pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-119) GenericObjectPool: Provide option to create new objects serial
[ https://issues.apache.org/jira/browse/POOL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556379#action_12556379 ] Christoph Kutzinski commented on POOL-119: -- Some comments on the patch: - the field _serialObjectCreation needs to be volatile because it is read from an unsynchronized block - object creation was refactored into a private method createObject() where also a re-check is done if a different object was returned meanwhile - I created 3 new test-methods in TestGenericObjectPool to verify the new behaviour. Unfortunately they rely on Thread.sleep, so they might fail spuriously under certain conditions. I couldn't find a way to test it without he sleep. Maybe someone else has a better idea? - I created a simple Latch class in the test sources to keep the test methods simpler (IMHO). > GenericObjectPool: Provide option to create new objects serial > -- > > Key: POOL-119 > URL: https://issues.apache.org/jira/browse/POOL-119 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Christoph Kutzinski > Attachments: patch.txt > > > As discussed on the Commons-Dev mailing list: > In certain scenarios it is desirable to serialize creation of new objects, if > the pool needs to grow. This has 2 main advantages: > - help keeping load away from the engine creating the objects (e.g. the > database server) during high load situations > - avoid unnecessary object creation if objects where returned to pool while > multiple 'new' objects are requested from the pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SANDBOX-206) backslash before quote character gives an error
[ https://issues.apache.org/jira/browse/SANDBOX-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556386#action_12556386 ] Yonik Seeley commented on SANDBOX-206: -- The last patch broke whitespace handling around escape chars... I just committed that fix, in addition to an option to not ignore trailing whitespace (both excel and mysql have significant leading and trailing whitespace). The excel strategy was changed to reflect this. > backslash before quote character gives an error > --- > > Key: SANDBOX-206 > URL: https://issues.apache.org/jira/browse/SANDBOX-206 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV > Environment: Windows, SOLR 1.2 >Reporter: Michael Lackhoff > Attachments: csv_escape.patch > > > A CSV-field with the contents "This is text with a \""quoted"" string" gives > the error > "invalid char between encapsualted token end delimiter". If the backslash is > not immediately before the double quote, everything is fine. > The same error occurs when the backslash is the last character in the field > (directly before the delimiter), like: > "This is a text with a backslash \". > Here the reason might be that the backslash also works as an escape character > like in > "This is a field with a \"quoted\" text" (no error, just the quotes in the > resulting field) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-395) annotations based builders
annotations based builders
--
Key: LANG-395
URL: https://issues.apache.org/jira/browse/LANG-395
Project: Commons Lang
Issue Type: New Feature
Affects Versions: LangTwo 1.0
Reporter: Jörg Gottschling
Fix For: LangTwo 1.0
What about enabling the builders (ToStringBuilder, EqualsBuilder, etc.) that
use reflection to use annotations to find the field to include?
Something like:
ToStringBuilder.annotationsBasedToString(Object object, Class
class, Class reflectUpToClass)
One could use the JPA-Annotation @ID for example, espescially for Equals- and
HashCodeBuilder. There should also be some default annotation comming with
LangTwo.
Usage:
public class User
{
@StringRepresentation
@EqualsAndHashCode
private String name
@StringRepresentation
private String email;
private String password;
// ...
@Override
public String toString()
{
return annotationsBasedToString(this);
}
@Override
public boolean equals(Object other)
{
return annotationsBasedEquals(this, other);
}
@Override
public int hashCode()
{
return annotationsBasedHashCode(this);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-395) annotations based builders
[
https://issues.apache.org/jira/browse/LANG-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Gottschling updated LANG-395:
--
Fix Version/s: (was: LangTwo 1.0)
> annotations based builders
> --
>
> Key: LANG-395
> URL: https://issues.apache.org/jira/browse/LANG-395
> Project: Commons Lang
> Issue Type: New Feature
>Affects Versions: LangTwo 1.0
>Reporter: Jörg Gottschling
>
> What about enabling the builders (ToStringBuilder, EqualsBuilder, etc.) that
> use reflection to use annotations to find the field to include?
> Something like:
> ToStringBuilder.annotationsBasedToString(Object object, Class
> class, Class reflectUpToClass)
> One could use the JPA-Annotation @ID for example, espescially for Equals- and
> HashCodeBuilder. There should also be some default annotation comming with
> LangTwo.
> Usage:
> public class User
> {
> @StringRepresentation
> @EqualsAndHashCode
> private String name
> @StringRepresentation
> private String email;
> private String password;
> // ...
> @Override
> public String toString()
> {
> return annotationsBasedToString(this);
> }
> @Override
> public boolean equals(Object other)
> {
> return annotationsBasedEquals(this, other);
> }
> @Override
> public int hashCode()
> {
> return annotationsBasedHashCode(this);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-152) Add ByteArrayOutputStream.readFrom(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556413#action_12556413 ] Jukka Zitting commented on IO-152: -- The method is essentially the opposite of writeTo, and I wanted to reflect that in the method name. Where writeTo _writes to_ a given OutputStream, readFrom _reads from_ a given InputStream. The alternative is of course to think of the method as an alternative to the various write() methods, in which case naming it write(InputStream) makes sense. However, I think there's one detail that makes the proposed readFrom() different from the normal write() methods. The write() methods inherited from OutputStream are declared to throw IOExceptions if the method fails to _write_ to the stream (of course ByteArrayOutputStream doesn't declare the exceptions). The readFrom() method on the other hand can throw IOExceptions, but only if the method fails to _read_ from the given stream. It's a small difference, but IMHO worth using different method names. I also thought about writeFrom, but that doesn't sound right and IMHO works with neither write() nor writeTo(). Anyway, I'm not too tied to the name, so I'm fine with renaming the method if the above didn't convince you. :-) > Add ByteArrayOutputStream.readFrom(InputStream) > --- > > Key: IO-152 > URL: https://issues.apache.org/jira/browse/IO-152 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: IO-152.patch > > > It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) > method to mirror the existing writeTo(OutputStream) method. A call like > baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), > but would avoid an extra in-memory copy of the stream contents, as it could > read bytes from the input stream directly into the internal > ByteArrayOutputStream buffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-137) Added method for getting InputStream from ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation and copy
[ https://issues.apache.org/jira/browse/IO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556414#action_12556414 ] Jukka Zitting commented on IO-137: -- I was thinking about adding a "copyOnReset" flag (or something) that would make the reset() method start with a newly allocated buffer. The toInputStream() method could set that flag to make sure that writes to the ByteArrayOutputStream never modify the state as seen by the created InputStreams. > Added method for getting InputStream from ByteArrayOutputStream & IOUtils > avoiding unnecessary array allocation and copy > > > Key: IO-137 > URL: https://issues.apache.org/jira/browse/IO-137 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers, Utilities >Affects Versions: 1.3.2 > Environment: Any OS with appropriate JVM >Reporter: Nikunj Trivedi > Fix For: 1.4 > > Attachments: baos_to_inputstream.patch, baos_toIstream.patch > > > Patch inclues following two methods and test cases for both. > 1) New Method: ByteArrayOutputStream.toInputStream > ByteArrayOutputStream exposes its byte buffers by toByteArray(), which > creates a fresh buffer and copy existing data to it. > A new method toInputStream() available in patch returns the current contents > of baos, as an InputStream, avoiding unnecessary allocation and copying. > 2) New Method: IOUtils.toFullyBufferedInputStream > There are situations where the InputStream source is available and it has to > be passed to different modules for processing. > It is needed to fetch the full contents of the InputStream in internal > buffer(IOUtils.toByteArray() ), convert this buffer to ByteArrayInputStream > and use that stream instead. But this is wasteful since toByteArray() > requires one fresh allocation and copy operation. > New method copies InputStream to ByteArrayOutputStream and returns > baos.toInputStream(), avoiding unnecessary memory allocation and copy. > Testcases are available in respective classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-153: --- Attachment: FileWriterWithEncoding.java I have a few comments/questions: - I don't understand why encoding is optional and there are four constructors without an encoding parameter. To use the default encoding people could/should just use FileWriter directly rather than this impl - Why not use the FileOutputStream constructor which takes a File rather than passing file.getAbsolutePath() to its String constructor? - We could use ProxyWriter and pass a dummy lock/writer to the constructor and reset "lock" and "out" (protected) variables after calling super - This only deals with String characterset names - would be good to provide Charset and CharsetEncoder constructors as well. I realize these require JDK 1.4 - but we already have three JDK 1.4 dependant implementations in this release. Attaching a suggested alternative version with the above points. Currently only has "File" constructors - may want to add String file name constructors as well for convenience. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-152) Add ByteArrayOutputStream.readFrom(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556429#action_12556429 ] Niall Pemberton commented on IO-152: I understand the logical symmetry, but it still seems wrong that what is essentially a "write" method method is named "read" rather than "write" and I do think it fits in eactly with all the other "write" methods. On the IOException point then we should make this clear in the javadocs > Add ByteArrayOutputStream.readFrom(InputStream) > --- > > Key: IO-152 > URL: https://issues.apache.org/jira/browse/IO-152 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: IO-152.patch > > > It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) > method to mirror the existing writeTo(OutputStream) method. A call like > baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), > but would avoid an extra in-memory copy of the stream contents, as it could > read bytes from the input stream directly into the internal > ByteArrayOutputStream buffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556430#action_12556430 ] Stephen Colebourne commented on IO-153: --- * The non-encoding parameters exist as I copied it from LocakbleFileWriter. While it could be argued that having the constructors allows a single class to be used for all purposes, I think that removing the no-encoding constructors is probably sensible. * The constructor uses file.getAbsolutePath() for JDK1.3 compatability. * I'm not sure that anything is gained by subclassing ProxyWriter (in fact it is more complex) - what we really want is to subclass FileWriter, but I can't see a way to do that. * I wanted this to be JDK1.3 compatible. I would hope that the next release will be Java 5 after all ;-) > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (POOL-120) maxActive can be exceeded by one
maxActive can be exceeded by one Key: POOL-120 URL: https://issues.apache.org/jira/browse/POOL-120 Project: Commons Pool Issue Type: Bug Affects Versions: 1.2 Reporter: Phil Steitz Priority: Blocker Fix For: 1.4 For GenericObjectPool, when numIdle > 0 and the idle object evictor is set to run (timeBetweenEvictionRunsMillis > 0), a race condition can occur between the Evictor and a borrowing thread, wherein the Evictor initiates a makeObject in ensureMinIdle and before the newly created object is placed in the pool, the borrowing thread initiates another makeObject that makes the number of instances in circulation = maxActive + 1. This issue does not affect pool 1.3, since addObject is syncrhonized in that version. It does affect 1.4-RC1 (unreleased snapshot) and the code currently in the 1.4 release branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-152) Add ByteArrayOutputStream.write(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated IO-152: - Description: It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) method to mirror the existing writeTo(OutputStream) method. A call like baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), but would avoid an extra in-memory copy of the stream contents, as it could read bytes from the input stream directly into the internal ByteArrayOutputStream buffers. [update: renamed the method to write(InputStream) as discussed below] was:It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) method to mirror the existing writeTo(OutputStream) method. A call like baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), but would avoid an extra in-memory copy of the stream contents, as it could read bytes from the input stream directly into the internal ByteArrayOutputStream buffers. Summary: Add ByteArrayOutputStream.write(InputStream) (was: Add ByteArrayOutputStream.readFrom(InputStream)) OK, let's name it write(InputStream). I'll commit the new method in a moment. > Add ByteArrayOutputStream.write(InputStream) > > > Key: IO-152 > URL: https://issues.apache.org/jira/browse/IO-152 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: IO-152.patch > > > It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) > method to mirror the existing writeTo(OutputStream) method. A call like > baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), > but would avoid an extra in-memory copy of the stream contents, as it could > read bytes from the input stream directly into the internal > ByteArrayOutputStream buffers. > [update: renamed the method to write(InputStream) as discussed below] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-152) Add ByteArrayOutputStream.write(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved IO-152. -- Resolution: Fixed Assignee: Jukka Zitting ByteArrayOutputStream.write(InputStream) added in revision 609421. > Add ByteArrayOutputStream.write(InputStream) > > > Key: IO-152 > URL: https://issues.apache.org/jira/browse/IO-152 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: IO-152.patch > > > It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) > method to mirror the existing writeTo(OutputStream) method. A call like > baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), > but would avoid an extra in-memory copy of the stream contents, as it could > read bytes from the input stream directly into the internal > ByteArrayOutputStream buffers. > [update: renamed the method to write(InputStream) as discussed below] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556438#action_12556438 ] Niall Pemberton commented on IO-153: On the JDK 1.3 compatibility the majority agreed with moving to JDK 1.4 for the IO 1.4 release (see IO-127) - however we haven't actually done that, but instead retained JDK 1.3 compatibility for all but three (and this would be a fourth) new implementations. I could understand it i it for this implementation if it was just the FileOutputStream constructor, which gains nothing from using it - but theres an opportunity to support the new Charset and CharsetEncoder features in this impl - so I think we should do that. I don't understand you saying that using ProxyWriter is more complex - doing so removes the need for the writer variable and the following seven methods: - write(int) - write(char[]) - write(char[], int, int) - write(String) - write(String, int, int) - flush() - close() ...and replaces that with a "dummy" object in the super constructor and initializing one additional variable (i.e. "lock") - how is that more complex? Another point is that JDK 1.5 introduces new append() methods in JDK 1.5 which I suggested we should add to ProxyWriter when we move to JDK 1,5 (see IO-140) - which with no effort this impl. would inherit - although maybe delegating to the proxy's append() methods compared to letting the default Writer append methods (which call write()) is a minor point. The main one is no duplicating code around. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-119) GenericObjectPool: Provide option to create new objects serial
[ https://issues.apache.org/jira/browse/POOL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-119: - Fix Version/s: 1.5 > GenericObjectPool: Provide option to create new objects serial > -- > > Key: POOL-119 > URL: https://issues.apache.org/jira/browse/POOL-119 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Christoph Kutzinski > Fix For: 1.5 > > Attachments: patch.txt, patch2.txt > > > As discussed on the Commons-Dev mailing list: > In certain scenarios it is desirable to serialize creation of new objects, if > the pool needs to grow. This has 2 main advantages: > - help keeping load away from the engine creating the objects (e.g. the > database server) during high load situations > - avoid unnecessary object creation if objects where returned to pool while > multiple 'new' objects are requested from the pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-119) GenericObjectPool: Provide option to create new objects serial
[ https://issues.apache.org/jira/browse/POOL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kutzinski updated POOL-119: - Attachment: patch2.txt I just realized that during re-check if an object was returned, a synchronized-block on 'this' was missing. Added a 2nd patch just for GenericObjectPool > GenericObjectPool: Provide option to create new objects serial > -- > > Key: POOL-119 > URL: https://issues.apache.org/jira/browse/POOL-119 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Christoph Kutzinski > Fix For: 1.5 > > Attachments: patch.txt, patch2.txt > > > As discussed on the Commons-Dev mailing list: > In certain scenarios it is desirable to serialize creation of new objects, if > the pool needs to grow. This has 2 main advantages: > - help keeping load away from the engine creating the objects (e.g. the > database server) during high load situations > - avoid unnecessary object creation if objects where returned to pool while > multiple 'new' objects are requested from the pool -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-120) maxActive can be exceeded by one
[ https://issues.apache.org/jira/browse/POOL-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556446#action_12556446 ] Phil Steitz commented on POOL-120: -- The problem occurs because addObject does not update pool statistics before kicking off the makeObject, so a thread executing borrowObject sees neither an available idle object nor an increment to _numActive. The simplest fix for this is a) synchronize (fully) addObject, as in 1.3. Alternatives are b) introduce a flag indicating that addObject has a makeObject in progress and make borrowObject check that flag before initiating makeObject c) introduce a _numTotal field that accurately tracks all objects in circulation, follow the pattern increment before makeObject, decrement after destroyObject and enforce the invariant _numTotal < _maxActive. My inclination is a), since it minimizes code change and affects only addObject / ensureMinIdle. > maxActive can be exceeded by one > > > Key: POOL-120 > URL: https://issues.apache.org/jira/browse/POOL-120 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Phil Steitz >Priority: Blocker > Fix For: 1.4 > > > For GenericObjectPool, when numIdle > 0 and the idle object evictor is set to > run (timeBetweenEvictionRunsMillis > 0), a race condition can occur between > the Evictor and a borrowing thread, wherein the Evictor initiates a > makeObject in ensureMinIdle and before the newly created object is placed in > the pool, the borrowing thread initiates another makeObject that makes the > number of instances in circulation = maxActive + 1. > This issue does not affect pool 1.3, since addObject is syncrhonized in that > version. It does affect 1.4-RC1 (unreleased snapshot) and the code currently > in the 1.4 release branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-148) IOException with constructors which take a cause
[ https://issues.apache.org/jira/browse/IO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-148. Resolution: Fixed Assignee: Gary Gregory > IOException with constructors which take a cause > > > Key: IO-148 > URL: https://issues.apache.org/jira/browse/IO-148 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Gary Gregory >Priority: Minor > Fix For: 1.4 > > > Add an IOException implementation that has constructors which take a cause > (see TIKA-104). Constructors which take a cause (Throwable) were not added to > IOException until JDK 1.6 but the initCause() method was added to Throwable > in JDK 1.4. > We should copy the Tika implementation and test case here: > http://svn.apache.org/repos/asf/incubator/tika/trunk/src/main/java/org/apache/tika/exception/CauseIOException.java > http://svn.apache.org/repos/asf/incubator/tika/trunk/src/test/java/org/apache/tika/exception/CauseIOExceptionTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-105) Add a FileUtils copyDirectory method that makes use of FileFilter
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-105: --- Assignee: Niall Pemberton Priority: Minor (was: Major) Summary: Add a FileUtils copyDirectory method that makes use of FileFilter (was: Add a FileUtils.copyDirectoryStructure method) > Add a FileUtils copyDirectory method that makes use of FileFilter > - > > Key: IO-105 > URL: https://issues.apache.org/jira/browse/IO-105 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Henri Yandell >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: IO-105-FileUtils_copyDirectory_filtered.patch > > > For potential source, see: > https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-105) Add a FileUtils copyDirectory method that makes use of FileFilter
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-105. Resolution: Fixed Fixed: http://svn.apache.org/viewvc?view=rev&revision=609471 > Add a FileUtils copyDirectory method that makes use of FileFilter > - > > Key: IO-105 > URL: https://issues.apache.org/jira/browse/IO-105 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Henri Yandell >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: IO-105-FileUtils_copyDirectory_filtered.patch > > > For potential source, see: > https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-381) NumberUtils.min(floatArray) returns wrong value if floatArray[0] happens to be Float.NaN
[
https://issues.apache.org/jira/browse/LANG-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-381.
--
Resolution: Fixed
svn ci -m "Applying third patch from LANG-381. Fixes the minimum(float[]) type
methods to correctly return NaN when it is in the array, and adds an
IEEE754rUtils class that obeys the IEEE 754r update in which NaN in min/max
methods should be ignored unless all values are NaN. " src
Adding src/java/org/apache/commons/lang/math/IEEE754rUtils.java
Sendingsrc/java/org/apache/commons/lang/math/NumberUtils.java
Adding src/test/org/apache/commons/lang/math/IEEE754rUtilsTest.java
Sendingsrc/test/org/apache/commons/lang/math/NumberUtilsTest.java
Transmitting file data
Committed revision 609475.
> NumberUtils.min(floatArray) returns wrong value if floatArray[0] happens to
> be Float.NaN
>
>
> Key: LANG-381
> URL: https://issues.apache.org/jira/browse/LANG-381
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Thomas Vandahl
> Fix For: 2.4
>
> Attachments: LANG-381-both.patch, LANG-381-IEEE-754r.patch,
> LANG-381-JDK.patch
>
>
> The min() method of NumberUtils returns the wrong result if the first value
> of the array happens to be Float.NaN. The following code snippet shows the
> behaviour:
> float a[] = new float[] {(float) 1.2, Float.NaN, (float) 3.7, (float)
> 27.0, (float) 42.0, Float.NaN};
> float b[] = new float[] {Float.NaN, (float) 1.2, Float.NaN, (float)
> 3.7, (float) 27.0, (float) 42.0, Float.NaN};
>
> float min = NumberUtils.min(a);
> System.out.println("min(a): " + min); // output: 1.2
> min = NumberUtils.min(b);
> System.out.println("min(b): " + min); // output: NaN
> This problem may exist for double-arrays as well.
> Proposal: Use Float.compare(float, float) or NumberUtils.compare(float,
> float) to achieve a consistent result.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-395) annotations based builders
[
https://issues.apache.org/jira/browse/LANG-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-395:
---
Fix Version/s: LangTwo 1.0
Affects Version/s: (was: LangTwo 1.0)
> annotations based builders
> --
>
> Key: LANG-395
> URL: https://issues.apache.org/jira/browse/LANG-395
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Jörg Gottschling
> Fix For: LangTwo 1.0
>
>
> What about enabling the builders (ToStringBuilder, EqualsBuilder, etc.) that
> use reflection to use annotations to find the field to include?
> Something like:
> ToStringBuilder.annotationsBasedToString(Object object, Class
> class, Class reflectUpToClass)
> One could use the JPA-Annotation @ID for example, espescially for Equals- and
> HashCodeBuilder. There should also be some default annotation comming with
> LangTwo.
> Usage:
> public class User
> {
> @StringRepresentation
> @EqualsAndHashCode
> private String name
> @StringRepresentation
> private String email;
> private String password;
> // ...
> @Override
> public String toString()
> {
> return annotationsBasedToString(this);
> }
> @Override
> public boolean equals(Object other)
> {
> return annotationsBasedEquals(this, other);
> }
> @Override
> public int hashCode()
> {
> return annotationsBasedHashCode(this);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556457#action_12556457 ] Stephen Colebourne commented on IO-153: --- I was simply trying to avoid JDK1.4 if possible, until the jump to 1.5. Personally, I use 1.5, so I'll go with the 1.4 for new classes approach. On ProxyWriter, I find the use of any dummy objects confusing, and try to use classes as they were designed. However, if you want to check in your version, I'm certainly not going to block it, its simply not the approach I would choose. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (POOL-118) build.xml uses to run JUnit
[ https://issues.apache.org/jira/browse/POOL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved POOL-118. -- Resolution: Fixed Patch applied to 1.4 release branch. Thanks! > build.xml uses to run JUnit > -- > > Key: POOL-118 > URL: https://issues.apache.org/jira/browse/POOL-118 > Project: Commons Pool > Issue Type: Bug >Reporter: Henri Yandell > Fix For: 1.4 > > Attachments: POOL-118.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556459#action_12556459 ] Niall Pemberton commented on IO-153: Your're right the dummy object isn't using it as designed so probably not a good idea and it doesn't change how it works anyway so not worth arguing over (sorry!). How about you commit what you have - if that includes the Charset etc. stuff great, if not I'll modify it after. > FileWriter that accepts an encoding > --- > > Key: IO-153 > URL: https://issues.apache.org/jira/browse/IO-153 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 1.4 > > Attachments: FileWriterWithEncoding.java, > io-FileWriterWithEncoding.patch > > > Amazingly, even in JDK6 there are no constructors on FileWriter that accept > an encoding. > Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (POOL-120) maxActive can be exceeded by one
[ https://issues.apache.org/jira/browse/POOL-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved POOL-120. -- Resolution: Fixed Fixed in r609487 by restoring synchronization to addObject. > maxActive can be exceeded by one > > > Key: POOL-120 > URL: https://issues.apache.org/jira/browse/POOL-120 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Phil Steitz >Priority: Blocker > Fix For: 1.4 > > > For GenericObjectPool, when numIdle > 0 and the idle object evictor is set to > run (timeBetweenEvictionRunsMillis > 0), a race condition can occur between > the Evictor and a borrowing thread, wherein the Evictor initiates a > makeObject in ensureMinIdle and before the newly created object is placed in > the pool, the borrowing thread initiates another makeObject that makes the > number of instances in circulation = maxActive + 1. > This issue does not affect pool 1.3, since addObject is syncrhonized in that > version. It does affect 1.4-RC1 (unreleased snapshot) and the code currently > in the 1.4 release branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
