[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240805#comment-13240805 ] Mark Mindenhall commented on POOL-213: -- I spoke too soon. The current 1.6 release (that can be downloaded) has exactly the same problem with the invalidateObject method: {code} public void invalidateObject(T obj) throws Exception { try { if (_factory != null) { _factory.destroyObject(obj); } } finally { synchronized (this) { _numActive--; } allocate(); } } {code} When you suggested version 1.6, I looked at the version of GenericObjectPool in trunk, which fixes the problem. What's the status of that release? It looks like a major refactoring (even the package name has changed from org.apache.commons.pool to org.apache.commons.pool2). > _numActive can go negative > -- > > Key: POOL-213 > URL: https://issues.apache.org/jira/browse/POOL-213 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Mark Mindenhall > > I'm working on a project that uses Hector (Cassandra client). Hector uses > commons-pool (we're using 1.5.4) to pool connections to hosts within a > Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" > property, which is the cumulative call to retrieve numActive from all of the > individual connection pools. When querying this property via JMS on our > production servers, we often see negative values. For example, on a server > that has three connection pools, the "NumActive" property reported was -3899. > I know this issue has been reported before (POOL-29), and was supposedly > fixed. The fix discussed there was to merely check the value of _numActive > to prevent it from going negative. However, that does not fix the real > problem here, which is that it is possible to decrement _numActive more than > once for each activated object. > For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), > it would be possible to do the following: > 1) Create a pool with 10 objects. > 2) Borrow all 10 objects from the pool. > 3) Call getNumActive (returns 10). > 4) Call invalidateObject for ONE of the objects 11 times. > 5) Call getNumActive (returns -1). > The invalidateObject method calls the _factory to destroy the object, and > subsequent calls to destroy the same object may or may not result in an > exception. Regardless, _numActive is decremented within a finally block, and > therefore would always be decremented even if the object had already been > invalidated and destroyed. > I'd like to suggest using a HashSet instead of a counter to keep track of > active objects. If borrowing an object added it to a HashSet, and returning > or invaliding the object removed it from the HashSet (subsequent removes > would be no-ops), the example given above would not result in an incorrect > value when getNumActive is called (it would just return the current size of > the HashSet). > Note that although unrelated to this bug, it might also be wise to use a > HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240755#comment-13240755 ] Karsten Tinnefeld commented on CODEC-137: - Ok, let's change the description to "outdated javadoc should be replaced by proper stable current api and link properly labeled". > Main documentation page links wrong javadocs > > > Key: CODEC-137 > URL: https://issues.apache.org/jira/browse/CODEC-137 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: Chrome 18, but I guess any browser >Reporter: Karsten Tinnefeld >Priority: Minor > Labels: documentation > Original Estimate: 1h > Remaining Estimate: 1h > > http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but > in fact links 1.4 javadocs. Thus, some prominent new features are not > properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
[ https://issues.apache.org/jira/browse/DAEMON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240711#comment-13240711 ] Elias Ross commented on DAEMON-248: --- Basically, the bug is a request. I need another way to attach to these processes. It might be that command line matching is done using Sigar. I may or may not develop a fix for this. > jsvc does not expose java.rt.vmArgs monitor information for Java Attach API > --- > > Key: DAEMON-248 > URL: https://issues.apache.org/jira/browse/DAEMON-248 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.2 >Reporter: Elias Ross > Attachments: Test.java > > > Run a process using jsvc.exec > Then use the Attach API to locate the process. > Note that java.rt.vmArgs are not available. See the attached program. > monitoredhost = MonitoredHost.getMonitoredHost(new > HostIdentifier((String) null)); > set = monitoredhost.activeVms(); > ... iterate > MonitoredVm monitoredvm = > monitoredhost.getMonitoredVm(new VmIdentifier(s)); > List l = monitoredvm.findByPattern(".*"); > for (Monitor m : l) { >System.out.println("> " + m.getName() + " " + > m.getValue()); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
[ https://issues.apache.org/jira/browse/DAEMON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elias Ross updated DAEMON-248: -- Attachment: Test.java Test program. Run a process with jsvc first. > jsvc does not expose java.rt.vmArgs monitor information for Java Attach API > --- > > Key: DAEMON-248 > URL: https://issues.apache.org/jira/browse/DAEMON-248 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.2 >Reporter: Elias Ross > Attachments: Test.java > > > Run a process using jsvc.exec > Then use the Attach API to locate the process. > Note that java.rt.vmArgs are not available. See the attached program. > monitoredhost = MonitoredHost.getMonitoredHost(new > HostIdentifier((String) null)); > set = monitoredhost.activeVms(); > ... iterate > MonitoredVm monitoredvm = > monitoredhost.getMonitoredVm(new VmIdentifier(s)); > List l = monitoredvm.findByPattern(".*"); > for (Monitor m : l) { >System.out.println("> " + m.getName() + " " + > m.getValue()); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
jsvc does not expose java.rt.vmArgs monitor information for Java Attach API --- Key: DAEMON-248 URL: https://issues.apache.org/jira/browse/DAEMON-248 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.2 Reporter: Elias Ross Run a process using jsvc.exec Then use the Attach API to locate the process. Note that java.rt.vmArgs are not available. See the attached program. monitoredhost = MonitoredHost.getMonitoredHost(new HostIdentifier((String) null)); set = monitoredhost.activeVms(); ... iterate MonitoredVm monitoredvm = monitoredhost.getMonitoredVm(new VmIdentifier(s)); List l = monitoredvm.findByPattern(".*"); for (Monitor m : l) { System.out.println("> " + m.getName() + " " + m.getValue()); } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240660#comment-13240660 ] Mark Mindenhall commented on POOL-213: -- Thanks, I'll try that...I figured something would break if I just dropped in the generics version. > _numActive can go negative > -- > > Key: POOL-213 > URL: https://issues.apache.org/jira/browse/POOL-213 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Mark Mindenhall > > I'm working on a project that uses Hector (Cassandra client). Hector uses > commons-pool (we're using 1.5.4) to pool connections to hosts within a > Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" > property, which is the cumulative call to retrieve numActive from all of the > individual connection pools. When querying this property via JMS on our > production servers, we often see negative values. For example, on a server > that has three connection pools, the "NumActive" property reported was -3899. > I know this issue has been reported before (POOL-29), and was supposedly > fixed. The fix discussed there was to merely check the value of _numActive > to prevent it from going negative. However, that does not fix the real > problem here, which is that it is possible to decrement _numActive more than > once for each activated object. > For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), > it would be possible to do the following: > 1) Create a pool with 10 objects. > 2) Borrow all 10 objects from the pool. > 3) Call getNumActive (returns 10). > 4) Call invalidateObject for ONE of the objects 11 times. > 5) Call getNumActive (returns -1). > The invalidateObject method calls the _factory to destroy the object, and > subsequent calls to destroy the same object may or may not result in an > exception. Regardless, _numActive is decremented within a finally block, and > therefore would always be decremented even if the object had already been > invalidated and destroyed. > I'd like to suggest using a HashSet instead of a counter to keep track of > active objects. If borrowing an object added it to a HashSet, and returning > or invaliding the object removed it from the HashSet (subsequent removes > would be no-ops), the example given above would not result in an incorrect > value when getNumActive is called (it would just return the current size of > the HashSet). > Note that although unrelated to this bug, it might also be wise to use a > HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240654#comment-13240654 ] Gary D. Gregory commented on POOL-213: -- You can just replace the 1.5 jar with the 1.6 jar without changing any source code. > _numActive can go negative > -- > > Key: POOL-213 > URL: https://issues.apache.org/jira/browse/POOL-213 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Mark Mindenhall > > I'm working on a project that uses Hector (Cassandra client). Hector uses > commons-pool (we're using 1.5.4) to pool connections to hosts within a > Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" > property, which is the cumulative call to retrieve numActive from all of the > individual connection pools. When querying this property via JMS on our > production servers, we often see negative values. For example, on a server > that has three connection pools, the "NumActive" property reported was -3899. > I know this issue has been reported before (POOL-29), and was supposedly > fixed. The fix discussed there was to merely check the value of _numActive > to prevent it from going negative. However, that does not fix the real > problem here, which is that it is possible to decrement _numActive more than > once for each activated object. > For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), > it would be possible to do the following: > 1) Create a pool with 10 objects. > 2) Borrow all 10 objects from the pool. > 3) Call getNumActive (returns 10). > 4) Call invalidateObject for ONE of the objects 11 times. > 5) Call getNumActive (returns -1). > The invalidateObject method calls the _factory to destroy the object, and > subsequent calls to destroy the same object may or may not result in an > exception. Regardless, _numActive is decremented within a finally block, and > therefore would always be decremented even if the object had already been > invalidated and destroyed. > I'd like to suggest using a HashSet instead of a counter to keep track of > active objects. If borrowing an object added it to a HashSet, and returning > or invaliding the object removed it from the HashSet (subsequent removes > would be no-ops), the example given above would not result in an incorrect > value when getNumActive is called (it would just return the current size of > the HashSet). > Note that although unrelated to this bug, it might also be wise to use a > HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240652#comment-13240652 ] Mark Mindenhall commented on POOL-213: -- It looks like 1.6 would solve the problem, but using 1.6 would require me to refactor the Hector code to use generics. > _numActive can go negative > -- > > Key: POOL-213 > URL: https://issues.apache.org/jira/browse/POOL-213 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Mark Mindenhall > > I'm working on a project that uses Hector (Cassandra client). Hector uses > commons-pool (we're using 1.5.4) to pool connections to hosts within a > Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" > property, which is the cumulative call to retrieve numActive from all of the > individual connection pools. When querying this property via JMS on our > production servers, we often see negative values. For example, on a server > that has three connection pools, the "NumActive" property reported was -3899. > I know this issue has been reported before (POOL-29), and was supposedly > fixed. The fix discussed there was to merely check the value of _numActive > to prevent it from going negative. However, that does not fix the real > problem here, which is that it is possible to decrement _numActive more than > once for each activated object. > For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), > it would be possible to do the following: > 1) Create a pool with 10 objects. > 2) Borrow all 10 objects from the pool. > 3) Call getNumActive (returns 10). > 4) Call invalidateObject for ONE of the objects 11 times. > 5) Call getNumActive (returns -1). > The invalidateObject method calls the _factory to destroy the object, and > subsequent calls to destroy the same object may or may not result in an > exception. Regardless, _numActive is decremented within a finally block, and > therefore would always be decremented even if the object had already been > invalidated and destroyed. > I'd like to suggest using a HashSet instead of a counter to keep track of > active objects. If borrowing an object added it to a HashSet, and returning > or invaliding the object removed it from the HashSet (subsequent removes > would be no-ops), the example given above would not result in an incorrect > value when getNumActive is called (it would just return the current size of > the HashSet). > Note that although unrelated to this bug, it might also be wise to use a > HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240626#comment-13240626 ] Gary D. Gregory commented on POOL-213: -- Can you try the latest version (1.6)? > _numActive can go negative > -- > > Key: POOL-213 > URL: https://issues.apache.org/jira/browse/POOL-213 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Mark Mindenhall > > I'm working on a project that uses Hector (Cassandra client). Hector uses > commons-pool (we're using 1.5.4) to pool connections to hosts within a > Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" > property, which is the cumulative call to retrieve numActive from all of the > individual connection pools. When querying this property via JMS on our > production servers, we often see negative values. For example, on a server > that has three connection pools, the "NumActive" property reported was -3899. > I know this issue has been reported before (POOL-29), and was supposedly > fixed. The fix discussed there was to merely check the value of _numActive > to prevent it from going negative. However, that does not fix the real > problem here, which is that it is possible to decrement _numActive more than > once for each activated object. > For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), > it would be possible to do the following: > 1) Create a pool with 10 objects. > 2) Borrow all 10 objects from the pool. > 3) Call getNumActive (returns 10). > 4) Call invalidateObject for ONE of the objects 11 times. > 5) Call getNumActive (returns -1). > The invalidateObject method calls the _factory to destroy the object, and > subsequent calls to destroy the same object may or may not result in an > exception. Regardless, _numActive is decremented within a finally block, and > therefore would always be decremented even if the object had already been > invalidated and destroyed. > I'd like to suggest using a HashSet instead of a counter to keep track of > active objects. If borrowing an object added it to a HashSet, and returning > or invaliding the object removed it from the HashSet (subsequent removes > would be no-ops), the example given above would not result in an incorrect > value when getNumActive is called (it would just return the current size of > the HashSet). > Note that although unrelated to this bug, it might also be wise to use a > HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-213) _numActive can go negative
_numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive" property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the "NumActive" property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[ https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CODEC-96: -- Attachment: CODEX-96-2.patch Supersedes CODEX-96.patch > Base64 encode() method is no longer thread-safe, breaking clients using it as > a shared BinaryEncoder > > > Key: CODEC-96 > URL: https://issues.apache.org/jira/browse/CODEC-96 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Matt Ryall >Assignee: Julius Davies > Fix For: 1.x > > Attachments: CODEC-96.patch, CODEX-96-2.patch, > codec-96-3rd-attempt.patch > > > Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69. > This introduced instance variables to Base64 which means the class can no > longer be used as a shared BinaryEncoder instance. > For example, BinaryEncoder has an interface which could be (and was) used > like this with Base64: > {code:java} > class Example { > private BinaryEncoder encoder = new Base64(); > byte[] someMethod(byte[] data) { > try { > return encoder.encode(data); > } > catch (EncoderException e) { > throw new RuntimeException(e); > } > } > } > {code} > Base64 is no longer thread-safe in commons-codec 1.4, so code like the above > which is accessed by multiple threads can throw NullPointerException: > {noformat} > java.lang.NullPointerException > at org.apache.commons.codec.binary.Base64.encode(Base64.java:469) > at org.apache.commons.codec.binary.Base64.encode(Base64.java:937) > at ... (application code) > {noformat} > Looking at the implementation of Base64, I think making it thread-safe for > this kind of usage would be quite tricky. I haven't attempted to prepare a > patch. > I would be happy if it was indicated in the Javadoc that Base64 is not > thread-safe and should not be shared. However, some other users of > commons-codec might be more worried about this regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[ https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240566#comment-13240566 ] Thomas Neidhart commented on CODEC-96: -- {quote} That's a separate issue; this patch only addresses the thread-safety aspects. {quote} That's true, I just realised that problem when reviewing your patch. Should we create a new issue, or fix it together? > Base64 encode() method is no longer thread-safe, breaking clients using it as > a shared BinaryEncoder > > > Key: CODEC-96 > URL: https://issues.apache.org/jira/browse/CODEC-96 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Matt Ryall >Assignee: Julius Davies > Fix For: 1.x > > Attachments: CODEC-96.patch, CODEX-96-2.patch, > codec-96-3rd-attempt.patch > > > Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69. > This introduced instance variables to Base64 which means the class can no > longer be used as a shared BinaryEncoder instance. > For example, BinaryEncoder has an interface which could be (and was) used > like this with Base64: > {code:java} > class Example { > private BinaryEncoder encoder = new Base64(); > byte[] someMethod(byte[] data) { > try { > return encoder.encode(data); > } > catch (EncoderException e) { > throw new RuntimeException(e); > } > } > } > {code} > Base64 is no longer thread-safe in commons-codec 1.4, so code like the above > which is accessed by multiple threads can throw NullPointerException: > {noformat} > java.lang.NullPointerException > at org.apache.commons.codec.binary.Base64.encode(Base64.java:469) > at org.apache.commons.codec.binary.Base64.encode(Base64.java:937) > at ... (application code) > {noformat} > Looking at the implementation of Base64, I think making it thread-safe for > this kind of usage would be quite tricky. I haven't attempted to prepare a > patch. > I would be happy if it was indicated in the Javadoc that Base64 is not > thread-safe and should not be shared. However, some other users of > commons-codec might be more worried about this regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240562#comment-13240562 ] Gary D. Gregory commented on CODEC-137: --- The link should have said "1.6", not "1.5", for 1.7 it will say "1.7". Older Javadocs will not be referenced. > Main documentation page links wrong javadocs > > > Key: CODEC-137 > URL: https://issues.apache.org/jira/browse/CODEC-137 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: Chrome 18, but I guess any browser >Reporter: Karsten Tinnefeld >Priority: Minor > Labels: documentation > Original Estimate: 1h > Remaining Estimate: 1h > > http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but > in fact links 1.4 javadocs. Thus, some prominent new features are not > properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
[ https://issues.apache.org/jira/browse/DBCP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ortwin Glück resolved DBCP-378. --- Resolution: Invalid ManagedDataSource behaves correctly. The test is wrong (it compares null with null) > ManagedDataSource returns uses the same underlying DB connection across JTA tx > -- > > Key: DBCP-378 > URL: https://issues.apache.org/jira/browse/DBCP-378 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Ortwin Glück >Priority: Critical > > It seems that when more than one JTA transaction is used within the same > thread (suspend/resume transaction), the ManagedDataSource always uses the > same underlying DB connection. This scenario is common in EJB containers! If > the same DB connection is used the JTA suspend/resume actions have no effect. > The JTA semantics is violated this behaviour. > Use the following code to setup a unit test that works in your environment > // DS setup > XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); > ... > TransactionManager tm = ... > DataSourceXAConnectionFactory cf = new > DataSourceXAConnectionFactory(tm, ods); > > AbandonedConfig ab = new AbandonedConfig(); > ab.setLogAbandoned(false); > ab.setRemoveAbandoned(true); > ab.setRemoveAbandonedTimeout(15*60); > > connPool = new GenericObjectPool(null); > > // registers itself on the pool > KeyedObjectPoolFactory stmtPool = = new > StackKeyedObjectPoolFactory(5); > new PoolableManagedConnectionFactory(cf, connPool, stmtPool, > null, 5, > (Collection) null, // init > sql > false, // read-only > false, // auto-commit > > Connection.TRANSACTION_READ_COMMITTED, > (String) null, // catalog > ab); > ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); > // Unit test > tm.begin(); > Connection c1 = source.getConnection(); > Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); > c1.close(); > > Transaction tx = tm.suspend(); > tm.begin(); > c2 = source.getConnection(); > ic2 = ((ManagedConnection) c2).getInnermostDelegate(); > c2.close(); > > assertNotSame("Pool must NOT use identical connection across tx", > ic1, ic2); > tm.commit(); > tm.resume(tx); > tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[ https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240542#comment-13240542 ] Sebb commented on CODEC-96: --- bq. BaseNCodec has a member xcontext which is never used Sorry, looks like a bit of debug code I left in bq. some fields in the Context class are protected, others package private Should probably all be package private I'll create an amended patch. bq. for the BaseNCodecInputStream, the mark/markSupported/reset methods should be implemented That's a separate issue; this patch only addresses the thread-safety aspects. > Base64 encode() method is no longer thread-safe, breaking clients using it as > a shared BinaryEncoder > > > Key: CODEC-96 > URL: https://issues.apache.org/jira/browse/CODEC-96 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Matt Ryall >Assignee: Julius Davies > Fix For: 1.x > > Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch > > > Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69. > This introduced instance variables to Base64 which means the class can no > longer be used as a shared BinaryEncoder instance. > For example, BinaryEncoder has an interface which could be (and was) used > like this with Base64: > {code:java} > class Example { > private BinaryEncoder encoder = new Base64(); > byte[] someMethod(byte[] data) { > try { > return encoder.encode(data); > } > catch (EncoderException e) { > throw new RuntimeException(e); > } > } > } > {code} > Base64 is no longer thread-safe in commons-codec 1.4, so code like the above > which is accessed by multiple threads can throw NullPointerException: > {noformat} > java.lang.NullPointerException > at org.apache.commons.codec.binary.Base64.encode(Base64.java:469) > at org.apache.commons.codec.binary.Base64.encode(Base64.java:937) > at ... (application code) > {noformat} > Looking at the implementation of Base64, I think making it thread-safe for > this kind of usage would be quite tricky. I haven't attempted to prepare a > patch. > I would be happy if it was indicated in the Javadoc that Base64 is not > thread-safe and should not be shared. However, some other users of > commons-codec might be more worried about this regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[ https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240530#comment-13240530 ] Thomas Neidhart commented on CODEC-96: -- I have reviewed the patch, which looks good in general, just a few minor things I have noticed: * BaseNCodec has a member xcontext which is never used * some fields in the Context class are protected, others package private * for the BaseNCodecInputStream, the mark/markSupported/reset methods should be implemented, see below We may opt for not supporting it: * mark does nothing * markSupported returns false * reset throws IOException That would mimick the InflaterInputStream, otoh we could support it like that: * markSupported: depends on the underlying stream * mark: if supported, saves the context, and marks underlying stream * reset: restores the context and resets underlying stream Thomas > Base64 encode() method is no longer thread-safe, breaking clients using it as > a shared BinaryEncoder > > > Key: CODEC-96 > URL: https://issues.apache.org/jira/browse/CODEC-96 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Matt Ryall >Assignee: Julius Davies > Fix For: 1.x > > Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch > > > Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69. > This introduced instance variables to Base64 which means the class can no > longer be used as a shared BinaryEncoder instance. > For example, BinaryEncoder has an interface which could be (and was) used > like this with Base64: > {code:java} > class Example { > private BinaryEncoder encoder = new Base64(); > byte[] someMethod(byte[] data) { > try { > return encoder.encode(data); > } > catch (EncoderException e) { > throw new RuntimeException(e); > } > } > } > {code} > Base64 is no longer thread-safe in commons-codec 1.4, so code like the above > which is accessed by multiple threads can throw NullPointerException: > {noformat} > java.lang.NullPointerException > at org.apache.commons.codec.binary.Base64.encode(Base64.java:469) > at org.apache.commons.codec.binary.Base64.encode(Base64.java:937) > at ... (application code) > {noformat} > Looking at the implementation of Base64, I think making it thread-safe for > this kind of usage would be quite tricky. I haven't attempted to prepare a > patch. > I would be happy if it was indicated in the Javadoc that Base64 is not > thread-safe and should not be shared. However, some other users of > commons-codec might be more worried about this regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-797) StringEscapeUtils.escapeJson
StringEscapeUtils.escapeJson Key: LANG-797 URL: https://issues.apache.org/jira/browse/LANG-797 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.6 Reporter: Joe Littlejohn Priority: Minor It would be great to offer a StringEscapeUtils.escapeJson method which is similar to StringEscapeUtils.escapeJavaScript but will not escape apostrophe (single-quote) chars. The current escapeJavaScript method does escape single-quote chars, but this produces invalid JSON. A good description of the problem can be found here: http://stackoverflow.com/questions/2275359/jquery-single-quote-in-json-response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-136. --- Resolution: Fixed In svn. > Use Charset objects when possible, create Charsets class for required > character encodings > - > > Key: CODEC-136 > URL: https://issues.apache.org/jira/browse/CODEC-136 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.7 > > > Use Charset objects when possible, create Charsets for required character > encodings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-136: -- Summary: Use Charset objects when possible, create Charsets class for required character encodings (was: Use Charset objects when possible, create Charsets for required character encodings) > Use Charset objects when possible, create Charsets class for required > character encodings > - > > Key: CODEC-136 > URL: https://issues.apache.org/jira/browse/CODEC-136 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.7 > > > Use Charset objects when possible, create Charsets for required character > encodings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (Collection) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame("Pool must NOT use identical connection across tx", ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-84) Clarify comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-84. - Resolution: Fixed Fixed test case, docs and code > Clarify comment handling > > > Key: CSV-84 > URL: https://issues.apache.org/jira/browse/CSV-84 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.0 > > > Comment handling is not currently fully documented / tested. > There are several possible situations: > 1) trailing comment following one or more values > 2) comment marker starts in the first column > 3) comment marker starts in the first non-whitespace column > How should these be handled? > 1) The trailing comment should be ignored > 2) Entire line should be ignored, i.e. don't treat it as a blank line > 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat > as 1, i.e. there is a single value containing whitespace > It might also be useful to consider returning comments to the application > program as part of CSVRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240351#comment-13240351 ] Sebb commented on CODEC-137: As a work-round the current Javadocs (i.e. 1.6) are available from the "Javadoc (SVN latest)" at present. > Main documentation page links wrong javadocs > > > Key: CODEC-137 > URL: https://issues.apache.org/jira/browse/CODEC-137 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.5 > Environment: Chrome 18, but I guess any browser >Reporter: Karsten Tinnefeld >Priority: Minor > Labels: documentation > Original Estimate: 1h > Remaining Estimate: 1h > > http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but > in fact links 1.4 javadocs. Thus, some prominent new features are not > properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-137) Main documentation page links wrong javadocs
Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[ https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240303#comment-13240303 ] Claudio Squarcella commented on SANDBOX-416: Hi, I saw you implemented the proposed improvements before I had the time to do so myself. Thanks for that! :) Ciao, Claudio > Improve DFS/BFS visit detecting multiple states and related actions instead > of just stop/continue > - > > Key: SANDBOX-416 > URL: https://issues.apache.org/jira/browse/SANDBOX-416 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Simone Tripodi >Assignee: Claudio Squarcella > > As discussed in > [ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E], > {{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return > {{boolean}} flags can be sometimes not so intuitive. > The proposal is replacing {{boolean}} flags return statements with an > enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify > * visit has to be immediately terminated > * visit can continue; > * current node children visit can be skipped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JXPATH-155) iteratePointers give the wrong pointers
[ https://issues.apache.org/jira/browse/JXPATH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Busch updated JXPATH-155: Description: I have a xml structur like these: {code:xml} 2 10 3 10 6 10 16 10 {code} I get an iterator for the "Kondtion" tags: {code:java} JXPathContext context = JXPathContext.newContext(in); Iterator it_konditionen = (Iterator) context.iteratePointers("/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition"); while (it_konditionen != null && it_konditionen.hasNext()) { Pointer p = it_konditionen.next(); System.out.println(p); } {code} The output to System.out looks like: /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] As we can see it start with [2] (which is not the problem) but it iterates over 2-4 twice! And this IS a problem. Very strange is that the call of "it_konditionen.hasNext()" increase the iterator one step. Best regards Martin Busch was: I have a xml structur like these: 2 10 3 10 6 10 16 10 I get an iterator for the "Kondtion" tags: JXPathContext context = JXPathContext.newContext(in); Iterator it_konditionen = (Iterator) context.iteratePointers("/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition"); while (it_konditionen != null && it_konditionen.hasNext()) { Pointer p = it_konditionen.next(); System.out.println(p); } The output to System.out looks like: /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] As we can see it start with [2] (which is not the problem) but it iterates over 2-4 twice! And this IS a problem. Very strange is that the call of "it_konditionen.hasNext()" increase the iterator one step. Best regards Martin Busch > iteratePointers give the wrong pointers > --- > > Key: JXPATH-155 > URL: https://issues.apache.org/jira/browse/JXPATH-155 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.3 > Environment: jdk 1.5 >Reporter: Martin Busch > > I have a xml structur like these: > {code:xml} > > > > > > 2 > 10 > > > 3 > 10 > > > 6 > 10 > > > 16 > 10 > >
[jira] [Created] (JXPATH-155) iteratePointers give the wrong pointers
iteratePointers give the wrong pointers --- Key: JXPATH-155 URL: https://issues.apache.org/jira/browse/JXPATH-155 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.3 Environment: jdk 1.5 Reporter: Martin Busch I have a xml structur like these: 2 10 3 10 6 10 16 10 I get an iterator for the "Kondtion" tags: JXPathContext context = JXPathContext.newContext(in); Iterator it_konditionen = (Iterator) context.iteratePointers("/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition"); while (it_konditionen != null && it_konditionen.hasNext()) { Pointer p = it_konditionen.next(); System.out.println(p); } The output to System.out looks like: /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3] /request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4] As we can see it start with [2] (which is not the problem) but it iterates over 2-4 twice! And this IS a problem. Very strange is that the call of "it_konditionen.hasNext()" increase the iterator one step. Best regards Martin Busch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[ https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240293#comment-13240293 ] Thomas Neidhart commented on LANG-796: -- The whole idea of DateUtils is to provide convenience methods when manipulating Date objects. The use-case that you describe, and I assume that's quite a common one, requires a properly configured Calendar object. Now we could add a method like this: {noformat} public static Date add(Date date, int calendarField, int amount, Calendar cal) { cal.setTime(date); cal.add(calendarField, amount); return cal.getTime(); } {noformat} But what's the point of it? If you already have the Calendar that you want to use, why not just do it straight-away? The fix that you propose would only support the UTC timezone, and will return wrong results for different timezones in case of a DST. While you are right, when you say that a Date object is not influenced by DST, any manipulation of it is in fact (or better could, depending on the timezone). When you need to operate in UTC time, always use proper configured Calendars (and also Formatters) for the UTC timezone (or set your local timezone to UTC). > DateUtils.addDays does not work properly with daylight saving time (DST) > > > Key: LANG-796 > URL: https://issues.apache.org/jira/browse/LANG-796 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Affects Versions: 2.6 >Reporter: Nicola Barbiero > > DateUtils.addDays does not work properly with daylight saving time. > The signature of the method is > Date addDays(Date date, int amount) > and the javadocs says "Adds a number of days to a date returning a new > object. The original date object is unchanged", > so if X=date.getTime() is the number of milliseconds of the date in input, > the expected behaviour is that the returned Date has a number of milliseconds > equal to X+amount*(8640), where 8640 is the number of milliseconds in > one day. > But when the calculation goes across the DST change date, the number of > milliseconds added does not correspond to whole days. > For example, here in Brussels, this code fragment: >Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[] > { "dd-MM-_HH:mm" }); >Date output = DateUtils.addDays(input, 1); > will give: > 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime() > equals to 133263000 > 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime() > equals to 133271280 > where 133271280-133263000=8280 < 8640 > (in fact 8280 is equivalent to 23h). > Since addDays is working with objects Date, it should not be influenced by > events like the DST. > Proposed solution: replace the current implementation > public static Date add(Date date, int calendarField, int amount) { > if (date == null) { > throw new IllegalArgumentException("The date must not be null"); > } > Calendar c = Calendar.getInstance(); > c.setTime(date); > c.add(calendarField, amount); > return c.getTime(); > } > based on Calendar with an implementation that works only with Date objects, > for example: > public static Date add(Date date, int calendarField, int amount) { > if (date == null) { > throw new IllegalArgumentException("The date must not be null"); > } > return new Date(input.getTime() + amount * 8640l); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[ https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240283#comment-13240283 ] Nicola Barbiero commented on LANG-796: -- That's the point: DateUtils.addDays receives in input a Date, that is an absolute time, so it should not be influenced by DST. Using a Calendar configured for the UTC timezone means to not use DateUtils.addDays, since there is no overloading method that receives a Calendar in input. As Thomas said, the method uses internally the default Calendar instance, that is set to the local timezone of the server where the code is running, and this is quite problematic in those time of cloud computing, because the code will work differently if the server is located in a zone where DST is applied or not (some countries do not implement any DST at all). Summarizing, for me the issue is that the user of this method is affected by the TimeZone but he has no way to set this TimeZone, because always the default Calendar instance and the local timezone are used. > DateUtils.addDays does not work properly with daylight saving time (DST) > > > Key: LANG-796 > URL: https://issues.apache.org/jira/browse/LANG-796 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Affects Versions: 2.6 >Reporter: Nicola Barbiero > > DateUtils.addDays does not work properly with daylight saving time. > The signature of the method is > Date addDays(Date date, int amount) > and the javadocs says "Adds a number of days to a date returning a new > object. The original date object is unchanged", > so if X=date.getTime() is the number of milliseconds of the date in input, > the expected behaviour is that the returned Date has a number of milliseconds > equal to X+amount*(8640), where 8640 is the number of milliseconds in > one day. > But when the calculation goes across the DST change date, the number of > milliseconds added does not correspond to whole days. > For example, here in Brussels, this code fragment: >Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[] > { "dd-MM-_HH:mm" }); >Date output = DateUtils.addDays(input, 1); > will give: > 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime() > equals to 133263000 > 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime() > equals to 133271280 > where 133271280-133263000=8280 < 8640 > (in fact 8280 is equivalent to 23h). > Since addDays is working with objects Date, it should not be influenced by > events like the DST. > Proposed solution: replace the current implementation > public static Date add(Date date, int calendarField, int amount) { > if (date == null) { > throw new IllegalArgumentException("The date must not be null"); > } > Calendar c = Calendar.getInstance(); > c.setTime(date); > c.add(calendarField, amount); > return c.getTime(); > } > based on Calendar with an implementation that works only with Date objects, > for example: > public static Date add(Date date, int calendarField, int amount) { > if (date == null) { > throw new IllegalArgumentException("The date must not be null"); > } > return new Date(input.getTime() + amount * 8640l); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[ https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-416. Resolution: Fixed issue resolved according to [r1306016|http://svn.apache.org/viewvc?view=revision&revision=1306016] by Claudio - well done, mate! > Improve DFS/BFS visit detecting multiple states and related actions instead > of just stop/continue > - > > Key: SANDBOX-416 > URL: https://issues.apache.org/jira/browse/SANDBOX-416 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Simone Tripodi >Assignee: Claudio Squarcella > > As discussed in > [ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E], > {{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return > {{boolean}} flags can be sometimes not so intuitive. > The proposal is replacing {{boolean}} flags return statements with an > enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify > * visit has to be immediately terminated > * visit can continue; > * current node children visit can be skipped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira