[jira] [Resolved] (CHAIN-68) SNAPSHOT tomcat plugin breaks the build
[
https://issues.apache.org/jira/browse/CHAIN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-68.
-
Resolution: Fixed
Fix Version/s: 2.0
fixed at [r1328084|http://svn.apache.org/viewvc?rev=1328084view=rev]
SNAPSHOT tomcat plugin breaks the build
---
Key: CHAIN-68
URL: https://issues.apache.org/jira/browse/CHAIN-68
Project: Commons Chain
Issue Type: Bug
Affects Versions: 2.0
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Critical
Fix For: 2.0
Attachments: tomcat_runnder.diff
the {{apps/cookbook-examples/pom.xml}} contains the {{tomcat7-maven-plugin}}
configured to version {{2.0-SNAPSHOT}} breaks the build on Continuum - see
dev@ ML.
--
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] (CHAIN-66) Updated Chain documentation to include new changes to the API
[ https://issues.apache.org/jira/browse/CHAIN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-66. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Simone Tripodi Thanks a lot for your patch Elijah, revised and successfully applied with minor changes, see r1327509 Thanks once again for contributing! Updated Chain documentation to include new changes to the API - Key: CHAIN-66 URL: https://issues.apache.org/jira/browse/CHAIN-66 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Assignee: Simone Tripodi Labels: documentaion Fix For: 2.0 Attachments: chain-66.diff Since the chain API is getting generics in the 2.0 release, we need to update the documentation so that it reflects the API update. -- 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=revisionrevision=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
[jira] [Resolved] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-163.
-
Resolution: Fixed
Assignee: Simone Tripodi
Thanks Torsten for the feedbacks and thanks Thomas for having a look at it!
I mark the issue as resolved and Torsten has to feel free to reopen it if
needed.
ConcurrentModificationException creating a new Digester via
loaderInstance.newDigester()
Key: DIGESTER-163
URL: https://issues.apache.org/jira/browse/DIGESTER-163
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Environment: Linux, JDK 6
Reporter: Torsten Krah
Assignee: Simone Tripodi
Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.txt, stack-next.txt,
stack-next2.txt
I am gettig a ConcurrentModificationException when trying to create new
Digester instance from a configured loader:
Trace is:
{code}
java.util.ConcurrentModificationException: null
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
~[na:1.6.0_27]
at java.util.LinkedList$ListItr.next(LinkedList.java:696) ~[na:1.6.0_27]
at
org.apache.commons.digester3.binder.FromBinderRuleSet.addRuleInstances(FromBinderRuleSet.java:130)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.addRules(DigesterLoader.java:581)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:568)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:516)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:475)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:462)
~[commons-digester3-3.2.jar:3.2]
{code}
The binder documentation (employee servlet) and the mailing list did confirm
to me, that the loader should be safe to be shared, so this should not happen.
--
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-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[ https://issues.apache.org/jira/browse/SANDBOX-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-401. Resolution: Fixed Assignee: Simone Tripodi patch applied on [r1300916|http://svn.apache.org/viewvc?rev=1300916view=rev], thanks [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable -- Key: SANDBOX-401 URL: https://issues.apache.org/jira/browse/SANDBOX-401 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-401.txt, SANDBOX-401v2.txt As discussed on the ML, we should store the hash code of AccessibleObjectDescriptor in a private member variable after it has been computed the first time. The computed value can be returned on subsequent invocations. Since AccessibleObjectDescriptor is immutable (all of its fields are final) the hash code can never change, once an AccessibleObjectDescriptor has been initialized. -- 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-369) Move logic for type compatibility checking from AccessibleObjectsRegistry to TypeUtils
[ https://issues.apache.org/jira/browse/SANDBOX-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-369. Resolution: Fixed Assignee: Simone Tripodi patch revised and applied, see r1300940 please pay attention on keeping out trailing spaces and empty lines ;) Move logic for type compatibility checking from AccessibleObjectsRegistry to TypeUtils -- Key: SANDBOX-369 URL: https://issues.apache.org/jira/browse/SANDBOX-369 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-369.txt As discussed on the ML, the logic for checking if two arrays of class objects are compatible, should be extracted from AccessibleObjectsRegistry.ConstructorsRegistry.resolve(...) and AccessibleObjectsRegistry.MethodsRegistry.resolve(...) to TypeUtils. -- 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-398) [BeanUtils2] Implement unit tests for BeanUtils.onClassName()
[ https://issues.apache.org/jira/browse/SANDBOX-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-398. Resolution: Fixed Assignee: Simone Tripodi charming patch, applied without any problem, see [r1300947|http://svn.apache.org/viewvc?rev=1300947view=rev] [BeanUtils2] Implement unit tests for BeanUtils.onClassName() - Key: SANDBOX-398 URL: https://issues.apache.org/jira/browse/SANDBOX-398 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-398.txt -- 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-403) [BeanUtils2] Refactor Unit tests for better readability
[ https://issues.apache.org/jira/browse/SANDBOX-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-403. Resolution: Fixed Assignee: Simone Tripodi patch applied, see [r1300952|http://svn.apache.org/viewvc?rev=1300952view=rev], thanks. please don't reorganize imports using wildcards, nobody uses it here, TIA. [BeanUtils2] Refactor Unit tests for better readability --- Key: SANDBOX-403 URL: https://issues.apache.org/jira/browse/SANDBOX-403 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-403.txt, SANDBOX-403v2.txt -- 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] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type
[
https://issues.apache.org/jira/browse/CHAIN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-67.
-
Resolution: Fixed
Assignee: Simone Tripodi
Hi Elijah,
patch applied, see r1297032 for more details!
I just adjusted minor signatures to get advantage from generics and avoid
string concatenation, but the rest is OK ;)
Thanks for contributing!
Refactor of explicit Exception throws to a RuntimeException type
Key: CHAIN-67
URL: https://issues.apache.org/jira/browse/CHAIN-67
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Assignee: Simone Tripodi
Priority: Minor
Labels: exception-handling
Fix For: 2.0
Attachments: chain-67.diff
Original Estimate: 2h
Remaining Estimate: 2h
As I've been working on the examples and the documentation for v2 of
chain, I've noticed that the API for exception handling of Command and
Chain is clunky.
When executing a command like:
{code:java}
ProfileContext context = new ProfileContext();
CommandString, Object, ProfileContext command = new ProfileCheck();
try {
command.execute(context);
}
catch (Exception e) {
throw new RuntimeException(e);
}
{code}
The user of chain has to explicitly catch Exception. If the desire was
to catch the most base error and force the user to deal with it, why
aren't we using Throwable? Anyways, this design leads to less than
elegant code and since we will be breaking the API in v2, I would like
to suggest a different approach.
I suggest that Command and Chain should throw a custom exception class
called ChainException that inherits from RuntimeException. And in the
CommandBase, ChainBase we wrap the catch of Exception in this runtime
exception. Moreover, we would attach to ChainException some optional
debug information about the Context invoked when the exception was
encountered.
--
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-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-400. Resolution: Fixed fixed on [r1296087|http://svn.apache.org/viewvc?rev=1296087view=rev] Switch the Base graph implementation underlying data structures to the thread safe version -- Key: SANDBOX-400 URL: https://issues.apache.org/jira/browse/SANDBOX-400 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Even if it won't help on shielding from race conditions, switching to Concurrent* version of adapted data structures would make current Graph implementations more consistent when working in a multi-thread environment -- 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] (CHAIN-55) split the huge project in submodules
[ https://issues.apache.org/jira/browse/CHAIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-55. - Resolution: Fixed fixed on r1295177 on trunk at the end I applied the Niall's suggestion of having 3 modules: * core * configuration * web without overengineering the modularization in the web package split the huge project in submodules Key: CHAIN-55 URL: https://issues.apache.org/jira/browse/CHAIN-55 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 2.0 As discussed in the [dev ML|http://markmail.org/message/pnyin5xzmxt2up5q], there is a general agreement between people interested on chain, on splitting the huge component in small submodules, in order to have a lightweight, dependencies-less (unless the logging library, if required) and self-contained core module, and users interested on core APIs only don't need to bring unused code in their applications. SUggested modules are: * core APIs; * XML configuration APIs (depends from Digester); * servlet (depends from Servlet APIs); * portlet (depends from Portlet APIs); * faces (depends from Faces APIs). -- 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] (CHAIN-65) Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain
[ https://issues.apache.org/jira/browse/CHAIN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-65. - Resolution: Fixed Assignee: Simone Tripodi Thanks for contributing Elijah, your patch has been successfully applied, see r1294379 Rename package org.apache.commons.chain to org.apache.commons.chain2 for v2 of chain Key: CHAIN-65 URL: https://issues.apache.org/jira/browse/CHAIN-65 Project: Commons Chain Issue Type: Task Affects Versions: 2.0 Reporter: Elijah Zupancic Assignee: Simone Tripodi Fix For: 2.0 Attachments: CHAIN-65.patch Since we are breaking binary compatibility in chain 2.0, we will rename the package so that users of the 1.0 libraries are not adversely affected. -- 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-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-396.
Resolution: Fixed
Assignee: Simone Tripodi
v2 looked much better, applied on
[r1293663|http://svn.apache.org/viewvc?rev=1293663view=rev], thanks for
contributing
[BeanUtils2] Implement clone() on DefaultBeanAccessor
-
Key: SANDBOX-396
URL: https://issues.apache.org/jira/browse/SANDBOX-396
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-396.txt, SANDBOX-396v2.txt
Implement {{clone()}} on DefaultBeanAccessor:
* create a new instance of the same type as the bean encapsulated by the
Accessor
* create a {{DefaultBeanAccessor}} for the new instance
* call populate on the new {{DefaultBeanAccessor}} with {{this.describe()}}
as argument
* return the clone
--
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] (DIGESTER-162) ObjectCreateRule doesn't allow create objects wich type is specified in attributeName only
[
https://issues.apache.org/jira/browse/DIGESTER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-162.
-
Resolution: Fixed
fixed on /trunk, see
[r1293698|http://svn.apache.org/viewvc?rev=1293698view=rev]
ObjectCreateRule doesn't allow create objects wich type is specified in
attributeName only
--
Key: DIGESTER-162
URL: https://issues.apache.org/jira/browse/DIGESTER-162
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.3
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Current {{ObjectCreateRule}} implementation doesn't allow create objects wich
type are specified in {{attributeName}} only.
--
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] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-58.
-
Resolution: Fixed
Assignee: Simone Tripodi
Fixed on [r1243699|http://svn.apache.org/viewvc?rev=1243699view=rev] thanks
Elijah for your efforts!
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Assignee: Simone Tripodi
Fix For: 2.0
Attachments: CHAIN-58-working-context-generics.patch,
chain-58-improved-context-generic.diff, chain-58-with-context-generic.diff,
chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
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-390) [BeanUtils2] Make sure that the internal package does not get exported when packaging as OSGi bundle
[ https://issues.apache.org/jira/browse/SANDBOX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-390. Resolution: Fixed Assignee: Simone Tripodi fixed on [r1243715|http://svn.apache.org/viewvc?rev=1243715view=rev] thanks for the contribution! [BeanUtils2] Make sure that the internal package does not get exported when packaging as OSGi bundle Key: SANDBOX-390 URL: https://issues.apache.org/jira/browse/SANDBOX-390 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-390.txt As discussed on the ML, the internal package should not be one of the exported packages in the generated MANIFEST file. Solution (adopted from http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin#Sharing%20Packages): * exclude the internal package from the exported packages bei using the neglect notion for the apache felix maven plugin ** overwrite the commons.osgi.export property from parent pom * add the internal package to the private packages declaration ** overwrite the commons.osgi.private property from the parent pom -- 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-387) [BeanUtils2] Implement possibility to find out if a property readable and/or wirtable
[
https://issues.apache.org/jira/browse/SANDBOX-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-387.
Resolution: Fixed
Assignee: Simone Tripodi
patch applied on [r1243717|http://svn.apache.org/viewvc?rev=1243717view=rev]
thanks for the contribution Benedikt.
Please next time pay attention on new files where license header is located,
its proper location is before the {{import}} statements.
[BeanUtils2] Implement possibility to find out if a property readable and/or
wirtable
-
Key: SANDBOX-387
URL: https://issues.apache.org/jira/browse/SANDBOX-387
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-387.txt
Currently there is no possibility to find out, if a property is readable
and/or writable.
For example, one has to pass a value to
{{setProperty(name).withValue(argument)}} and hope, that the property is
writeable (because a {{NoSucheMethodExcpetion}} will be thrown, if it is
not). For this reason it would be nice, if one could do something like:
{code:java}
if (on(myBean).isWritable(writeableProperty) {
on(myBean).setProperty(writableProperty).withValue(This is a String
value!);
}
{code}
Solution:
* Add {{public boolean isWritable(String propertyName)}} and {{public boolean
isReadable(String propertyName)}} to {{BeanAccessor}}.
* in {{isWritable()}} check if a {{PropertyDescriptor}} can be obtained from
PropertyRegistry (if not, throw {{NoSuchMethodException}}).
** if so, return true, if {{propertyDescriptor.getWriteMethod() != null}} and
false otherwise.
* in {{isReadable()}} check if a {{PropertyDescriptor}} can be obtained from
PropertyRegistry (if not, throw {{NoSuchMethodException}}).
** if so, return true, if {{propertyDescriptor.getReadMethod() != null}} and
false otherwise.
--
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-389) [BeanUtils2] Implement populate() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-389.
Resolution: Fixed
Assignee: Simone Tripodi
Patch applied, see [r1243720|http://svn.apache.org/viewvc?rev=1243720view=rev]
but please:
* pay attention on new files where license header is located, its proper
location is {{before}} the import statements
* inverted logic in {{continue}} statements;
* *NO TABS* in pom XML;
* why did you think putting the {{commons-lang}} version as property would be
a benefit?
[BeanUtils2] Implement populate() on DefaultBeanAccessor
-
Key: SANDBOX-389
URL: https://issues.apache.org/jira/browse/SANDBOX-389
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-389.txt, SANDBOX-389v2.txt
Implement {{populate()}} as discussed on the ML (see
http://markmail.org/thread/niv47muvrms56pqr)
--
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-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-388.
Resolution: Fixed
Assignee: Simone Tripodi
You guys made me the happiest man in the world today, Thanks Steven Claudio!!!
I applied Claudio's patch that provides a more abstracted APIs, but *thank you*
Steven for the intuition!!!
Fixed on [r1241491|http://svn.apache.org/viewvc?rev=1241491view=rev], all the
best!
Generic Type inference doesn't work in Eclipse
--
Key: SANDBOX-388
URL: https://issues.apache.org/jira/browse/SANDBOX-388
Project: Commons Sandbox
Issue Type: Bug
Components: Graph
Environment: Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 1
Build id: 20110916-0149
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Blocker
Attachments: SANDBOX-388_FixForGenericTypesInEclipse.patch,
sandbox-388.txt
{{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
they reported that doesn't work if the code is compiled with Oracle JDK7.
One of the reported error in Eclipse is:
{quote}
Type mismatch: cannot convert from
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
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-385) Provide Edmonds-Karp algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-385.
Resolution: Fixed
Assignee: Simone Tripodi
Claudio,
amazing. Patch applied, check
[r1241056|http://svn.apache.org/viewvc?rev=1241056view=rev].
The only modification I applied, is transforming the {{FlowNetwork}} as class,
in simpler a method.
Thanks again for your contribution!!!
Provide Edmonds-Karp algorithm
--
Key: SANDBOX-385
URL: https://issues.apache.org/jira/browse/SANDBOX-385
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Marco Speranza
Assignee: Simone Tripodi
Attachments: SANDBOX-385_AddedEdmondsKarpImplementationAndTest.patch
Add the [Edmonds-Karp|http://en.wikipedia.org/wiki/Edmonds-Karp_algorithm]
algorithm into org.apache.commons.graph.flow package.
--
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-383) Add test for Connectivity
[ https://issues.apache.org/jira/browse/SANDBOX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-383. Resolution: Fixed Assignee: Simone Tripodi Tests now run fine, thanks, see [r1240513|http://svn.apache.org/viewvc?rev=1240513view=rev] Add test for Connectivity - Key: SANDBOX-383 URL: https://issues.apache.org/jira/browse/SANDBOX-383 Project: Commons Sandbox Issue Type: Sub-task Components: Graph Reporter: Marco Speranza Assignee: Simone Tripodi Attachments: SANDBOX-383_AddConnectivityTestCase.patch, SANDBOX-383_AddConnectivityTestCase_Modified.patch Add new test cases for Connectivity algorithm: * Test null graph * Test empty graph * Test a null argument for includingVertices() method -- 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-384) Add test for Flow Algorithm
[ https://issues.apache.org/jira/browse/SANDBOX-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-384. Resolution: Fixed Assignee: Simone Tripodi Patch applied, thanks! see [r1240515|http://svn.apache.org/viewvc?rev=1240515view=rev] Add test for Flow Algorithm --- Key: SANDBOX-384 URL: https://issues.apache.org/jira/browse/SANDBOX-384 Project: Commons Sandbox Issue Type: Sub-task Components: Graph Reporter: Marco Speranza Assignee: Simone Tripodi Attachments: SANDBOX-384_AddFlowTestCase.patch Add test cases for flow algorithm: * test null graph * test null start/end vertices * test Not Connected graph * test sparse graph -- 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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-379.
Resolution: Fixed
Assignee: Simone Tripodi
Patch (finally) applied, see
[r1240336|http://svn.apache.org/viewvc?rev=1240336view=rev], thanks for the
contribution.
I applied 2 minor modifications:
* misplaced {{DescribeTestCase}} license header;
* {{PropertyDescriptorsRegistry#makeMethodsAccessible}} can be static
[BeanUtils2] Implement describe() on DefaultBeanAccessor
-
Key: SANDBOX-379
URL: https://issues.apache.org/jira/browse/SANDBOX-379
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-379.txt, SANDBOX-379v2.txt
Implement the above mentioned method an corresponding unit tests
--
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-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-382.
Resolution: Fixed
Assignee: Simone Tripodi
Cool, patch applied, see
[r1240375|http://svn.apache.org/viewvc?rev=1240375view=rev], thanks!
I did a minor modification on the {{NotEnoughColorsException}}, since the
message was always the same.
Add new test for coloring
-
Key: SANDBOX-382
URL: https://issues.apache.org/jira/browse/SANDBOX-382
Project: Commons Sandbox
Issue Type: Sub-task
Components: Graph
Reporter: Marco Speranza
Assignee: Simone Tripodi
Attachments: SANDBOX-382_AddedColoringTestCase.patch,
SANDBOX-382_AddedColoringTestCase_Modified.patch,
SANDBOX-382_AddedColoringTestCase_Modified_2.patch,
SANDBOX-382_AddedColoringTestCase_Modified_3.patch
Add new test cases for backtracking and greedy algorithm:
* Test a Null graph
* test a null color list
* test an empty graph
--
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-381) [Graph] Unused class GraphColoringBacktraking
[ https://issues.apache.org/jira/browse/SANDBOX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-381. Resolution: Fixed Assignee: Simone Tripodi good catch, fixed on [r1239864|http://svn.apache.org/viewvc?rev=1239864view=rev] thanks! [Graph] Unused class GraphColoringBacktraking - Key: SANDBOX-381 URL: https://issues.apache.org/jira/browse/SANDBOX-381 Project: Commons Sandbox Issue Type: Bug Components: Graph Reporter: Marco Speranza Assignee: Simone Tripodi The class GraphColoringBacktraking is unused. the Backtracking algorithm is now implemented into DefaultColoringAlgorithmsSelector -- 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] (DIGESTER-161) Document thread-safety in javadoc of Rule class
[ https://issues.apache.org/jira/browse/DIGESTER-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-161. - Resolution: Fixed Assignee: Simone Tripodi fixed on [r1239129|http://svn.apache.org/viewvc?rev=1239129view=rev]. For future releases, please read the [On Contributing Patches |http://commons.apache.org/patches.html] short guide. Thanks for contributing Document thread-safety in javadoc of Rule class Key: DIGESTER-161 URL: https://issues.apache.org/jira/browse/DIGESTER-161 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.1 Reporter: Eduard Papa Assignee: Simone Tripodi Priority: Trivial Labels: rule, thread-safe Attachments: RuleJavadoc.txt Original Estimate: 1h Remaining Estimate: 1h I discovered a problem today with some code that was reusing a custom Rule in multiple threads, even though each thread was creating its own digester. It seems that Digester.addRule is calling rule.setDigester and if the rule is shared across multiple threads, the calls to begin/end can get tangled across threads. It is obvious that Rules are not meant to be shared, but the javadoc http://commons.apache.org/digester/apidocs/org/apache/commons/digester3/Rule.html seems to be implying the opposite and is confusing at best. It talks about the rules being stateless, even though the framework itself is changing its state with rule.setDigester(digester). It further states that since all state is part of the digester, the rule is safe under all cases, which is very misleading. ... Rule objects should be stateless, ie they should not update any instance member during the parsing process. A rule instance that changes state will encounter problems if invoked in a nested manner; this can happen if the same instance is added to digester multiple times or if a wildcard pattern is used which can match both an element and a child of the same element. The digester object stack and named stacks should be used to store any state that a rule requires, making the rule class safe under all possible uses. ... I think the statement above should be reworded to be more correct and avoid confusion. Down the line, maybe the digester accessed by the rule should be a ThreadLocal. -- 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-374) Kruskal's algorithm doesn't accept sparse graph
[
https://issues.apache.org/jira/browse/SANDBOX-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-374.
Resolution: Fixed
Assignee: Simone Tripodi
fixed on r1238355, thanks!
Kruskal's algorithm doesn't accept sparse graph
---
Key: SANDBOX-374
URL: https://issues.apache.org/jira/browse/SANDBOX-374
Project: Commons Sandbox
Issue Type: Bug
Components: Graph
Reporter: Marco Speranza
Assignee: Simone Tripodi
Attachments: SANDBOX-374-Kruskal-NotConnectGraph_problem.patch
Hi guys,
I found a little problem into Kruskal's algorithm when the input graph is not
connected and/or it's a graph without the edges.
I created a test case that produces the follow error:
{code}
Running org.apache.commons.graph.spanning.KruskalTestCase
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.096 sec
FAILURE!
verifyNotConnectedMinimumSpanningTree(org.apache.commons.graph.spanning.KruskalTestCase)
Time elapsed: 0.007 sec ERROR!
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:90)
at
org.apache.commons.graph.spanning.DefaultSpanningTreeAlgorithmSelector.applyingKruskalAlgorithm(DefaultSpanningTreeAlgorithmSelector.java:87)
{code}
ciao
Marco
--
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-375) Add Connected Components algorithms
[ https://issues.apache.org/jira/browse/SANDBOX-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-375. Resolution: Fixed Fixed on [r1238390|http://svn.apache.org/viewvc?rev=1238390view=rev], thanks for this patch! Add Connected Components algorithms --- Key: SANDBOX-375 URL: https://issues.apache.org/jira/browse/SANDBOX-375 Project: Commons Sandbox Issue Type: New Feature Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi SANDBOX-348 already contains a patch, contributed by Marco Speranza, providing connectivity algorithm -- 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-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-348.
Resolution: Fixed
Patch applied, see [r1238692|http://svn.apache.org/viewvc?rev=1238692view=rev]
for details.
Thanks for contributing!
Implement the Boruvka's algorithm
-
Key: SANDBOX-348
URL: https://issues.apache.org/jira/browse/SANDBOX-348
Project: Commons Sandbox
Issue Type: Sub-task
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Attachments: SANDBOX-348-ConnectivityAlgo.patch,
SANDBOX-348_Boruvka_algorithm_implementation.patch
The class {{org.apache.commons.graph.spanning.Boruvka}} contains an empty
implementation of
[Boruvka|http://en.wikipedia.org/wiki/Bor%C5%AFvka's_algorithm]'s algorithm,
that needs to be filled.
--
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-376) [BeanUtils2] Extract magic numbers in AccessibleObjectsRegistry.getObjectTransformationCosts(...) to constants
[
https://issues.apache.org/jira/browse/SANDBOX-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-376.
Resolution: Fixed
Assignee: Simone Tripodi
patch reviewed and applied, see
[r1238947|http://svn.apache.org/viewvc?rev=1238947view=rev].
As a side note: the internal constants {{TRANSFORMATION_COSTS_}} (why
plural?!?) prefix has been moved to {{_COST}} postfix
[BeanUtils2] Extract magic numbers in
AccessibleObjectsRegistry.getObjectTransformationCosts(...) to constants
--
Key: SANDBOX-376
URL: https://issues.apache.org/jira/browse/SANDBOX-376
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-376.txt
As discussed on the ML, the magic numbers in the above mentioned method
should be extracted to local constants.
--
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-377) [BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-377.
Resolution: Fixed
Assignee: Simone Tripodi
Patch reviewed and applied, thanks, see
[r1238950|http://svn.apache.org/viewvc?rev=1238950view=rev]
As a side note: these auto-generated comments
{code}
+/* (non-Javadoc)
+ * @see
org.apache.commons.beanutils2.BeanAccessor#invokeMethod(java.lang.String)
+ */
{code}
are not good, please next time pay attention on putting the right Javadoc
[BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
--
Key: SANDBOX-377
URL: https://issues.apache.org/jira/browse/SANDBOX-377
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-377.txt
On DefaultBeanAccessor implement:
* invokeMethod( String methodName )
* invokeExactMethod( String methodName )
--
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-378) [BeanUtils2] Extend StaticMethodsTestCase
[ https://issues.apache.org/jira/browse/SANDBOX-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-378. Resolution: Fixed Assignee: Simone Tripodi patch reviewed and applied, see [r1238953|http://svn.apache.org/viewvc?rev=1238953view=rev], thanks for contributing! As a side note: please pay attention, for future patches, on stripping out trailing spaces and trailing spaces on empty lines [BeanUtils2] Extend StaticMethodsTestCase - Key: SANDBOX-378 URL: https://issues.apache.org/jira/browse/SANDBOX-378 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Fix For: Nightly Builds Attachments: SANDBOX-378.txt Extend StaticMethodsTestCase: * Split test method into single test methods * add test methods for invokeExactStaticMethod() * add test methods for failure cases -- 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-370) GraphML format exporter
[
https://issues.apache.org/jira/browse/SANDBOX-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-370.
Resolution: Fixed
Patch applied, thanks for your efforts Matteo!!! see
[r1237585|https://svn.apache.org/viewvc?view=revisionrevision=1237585] for
more details!
While keeping the core implementation, I applied some minor modifications to
your patch, one of the purposes of exporters is be used via fluent APIs as
well, so tests now look like:
{code}
@Test
public void shouldPrintGraphMLFormat()
throws Exception
{
export( actual ).to( System.out ).usingGraphMLFormat();
}
{code}
As a side note: the {Basic} implementations shall not be used to check
Vertex/Edge type - we expect users will provide façades on their own data, so I
moved checks over Labeled/Weighted interfaces
GraphML format exporter
---
Key: SANDBOX-370
URL: https://issues.apache.org/jira/browse/SANDBOX-370
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Affects Versions: Nightly Builds
Reporter: Matteo Moci
Assignee: Simone Tripodi
Priority: Minor
Labels: export, graph, xml
Attachments: SANDBOX-370.patch
Original Estimate: 6h
Remaining Estimate: 6h
Commons-graph should have some way to read and write graph representations
encoded with GraphML - http://graphml.graphdrawing.org/
--
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-372) Make the org.apache.commons.graph.visit.GraphVisitHandler able to return objects
[
https://issues.apache.org/jira/browse/SANDBOX-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-372.
Resolution: Fixed
fixed on trunk, see
[r1237632|https://svn.apache.org/viewvc?view=revisionrevision=1237632]
Make the org.apache.commons.graph.visit.GraphVisitHandler able to return
objects
Key: SANDBOX-372
URL: https://issues.apache.org/jira/browse/SANDBOX-372
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Graph visit could produce output objects, taking inspiration form DbUtil's
[ResultSetHandler|http://commons.apache.org/dbutils/apidocs/org/apache/commons/dbutils/ResultSetHandler.html]
and AsyncHttpClient's
[AsyncHandler|http://sonatype.github.com/async-http-client/apidocs/com/ning/http/client/AsyncHandler.html]
it would be possible invoke:
{code}
final ListV visited = visit( inputGraph ).from( startVertex
).applyingDepthFirstSearch( new MyHandler() );
{code}
just adding a callback method in {{GraphVisitHandler}}, something like:
{code}
public interface GraphVisitHandlerV extends Vertex, E extends Edge, G
extends GraphV, E, O
{
[...]
O onCompleted();
}
{code}
--
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-373) [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor
[ https://issues.apache.org/jira/browse/SANDBOX-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-373. Resolution: Fixed Assignee: Simone Tripodi patch applied on r1237721 [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor Key: SANDBOX-373 URL: https://issues.apache.org/jira/browse/SANDBOX-373 Project: Commons Sandbox Issue Type: Task Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-373.txt Implement the above mentioned method: * check if a property of the given name is available * check if the property has a write method * create a new DefaultBeanPropertySetter with bean and the setter method as parameters * Implement DefaultBeanPropertySetter * In DefaultBeanPropertySetter.withValue(V value): ** check if the given value can be assigned to the value *** if property is primitive, throw IllegalArgumentException for null values *** if property is not primitive and value is not null, call TypeUtils.isAssignmentCompatible() ** invoke setter method on bean with value ** return a new DefaultBeanAccessor with bean as parameter * implement a SetPropertyTestCase -- 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-359) Move License Agreement to file top
[
https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-359.
Resolution: Fixed
Assignee: Simone Tripodi
fixed on r1237727; if you just run {{mvn checkstyle:checkstyle}}, pom's
settings are ignored; run {{svn up mvn site open
target/site/checkstyle.html}} instead
Move License Agreement to file top
--
Key: SANDBOX-359
URL: https://issues.apache.org/jira/browse/SANDBOX-359
Project: Commons Sandbox
Issue Type: Task
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Priority: Trivial
Currently, license agreements are located between package declaration and
import statements. To stick to conventions, the license agreements should be
moved up to the very top of each file.
--
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-368) [graph] change Dijkstra MST api for accept also Undirect Graph
[ https://issues.apache.org/jira/browse/SANDBOX-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-368. Resolution: Fixed Assignee: Simone Tripodi Hi Marco! Brilliant, patch applied, see [r1236194|https://svn.apache.org/viewvc?view=revisionrevision=1236194] One minor recommendation: when attaching patches, please add the SANDBOX-XXX prefix! Thanks once again for your patches! [graph] change Dijkstra MST api for accept also Undirect Graph -- Key: SANDBOX-368 URL: https://issues.apache.org/jira/browse/SANDBOX-368 Project: Commons Sandbox Issue Type: Bug Components: Graph Reporter: Marco Speranza Assignee: Simone Tripodi Attachments: DijkstraMST_Accepts_UndirectGraph.patch The Dijkstra Algorithm accepts also an undirected graph. In the attached patch I changed the API in that way. -- 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-350) Provide a Reverse-delete algorithm implementation
[
https://issues.apache.org/jira/browse/SANDBOX-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-350.
Resolution: Fixed
Assignee: Simone Tripodi
Well done, thanks, I applied your patch with minor modifications - your
algorithm has been merged in the fluent APIs and the comparator class is still
in the {{spanning}} package, we will extract it if needed somewhere else.
Code has still few problems in Eclipse - it is already working in CLI and
IntelliJ, its time is coming, it is just a matter of time (I hope)
see [r1236387|https://svn.apache.org/viewvc?view=revisionrevision=1236387]
thanks for your hard work!
Provide a Reverse-delete algorithm implementation
-
Key: SANDBOX-350
URL: https://issues.apache.org/jira/browse/SANDBOX-350
Project: Commons Sandbox
Issue Type: Sub-task
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Attachments: SANDBOX-350_Reverse_Delete_algo.patch
[Reverse-delete|http://en.wikipedia.org/wiki/Reverse-Delete_algorithm]
algorithm implementation is completely missing in
{{org.apache.commons.graph.spanning}} package
--
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-367) Move base implementations from test to main
[
https://issues.apache.org/jira/browse/SANDBOX-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-367.
Resolution: Fixed
Assignee: Simone Tripodi
Can you bet this was something I already had in mind? Providing basic
implementations for users that just need extending, is IMHO comfortable.
Patch applied, see
[r1235005|https://svn.apache.org/viewvc?view=revisionrevision=1235005].
Thanks once again!
Move base implementations from test to main
---
Key: SANDBOX-367
URL: https://issues.apache.org/jira/browse/SANDBOX-367
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Assignee: Simone Tripodi
Priority: Trivial
Labels: graph, implementations, main, model, test
Attachments: MoveBaseImplementationsFromTestToMain.patch,
SANDBOX-367_MoveBaseImplementationsFromTestToMain.patch
Hi,
very tiny patch to move default implementations from test (in package
{{model}}: {{BaseLabeledEdge}}, {{BaseLabeledWeightedEdge}} and
{{BaseLabeledVertex}}) to main. Needed for other implementations that require
manipulation of input graphs -- e.g. the upcoming Ford-Fulkerson ;)
--
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-364) Adding generic weight type to model
[
https://issues.apache.org/jira/browse/SANDBOX-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-364.
Resolution: Fixed
Assignee: Simone Tripodi
Thanks once again for your contributions Claudio, really appreciated!
After a first look I was a little in trouble on removing the {{Comparable}}
interface from {{WeightedEdge}}, but the super {{Monoid}} fills the gap in a
more elegant way - at least, under a Mathematical PoV the new version looks
much more elegant!!!
Patch applied, see
[r1234551|https://svn.apache.org/viewvc?view=revisionrevision=1234551]
I applied just 2 minor modifications to your patch:
* I didn't modify the {{FibonacciHeap}} wich is a general purpose queue;
* I moved the anonymous {{Comparator}} in {{Kruskal}} implementation in a
private static inner class
Thanks once again!
-Simo
Adding generic weight type to model
Key: SANDBOX-364
URL: https://issues.apache.org/jira/browse/SANDBOX-364
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Assignee: Simone Tripodi
Priority: Minor
Labels: generic, graph, weight, weightededge
Attachments: AddingGenericWeightTypeToModel.patch
Hello,
with this patch I introduce generic weight types in all the implementations
of the domain (mainly classes in the {{model}} packages both in {{main}} and
{{test}}). Consequently I updated tests and references to be fully generic.
One side effect is that {{WeightedEdge}} does not implement {{Comparable}}
anymore, because that would imply passing it a {{Comparator}} for weights as
an argument upon creation. Instead, without polluting {{WeightedEdge}}, I
changed the classes where it was needed to be {{Comparable}} (e.g. in
{{Kruskal}} there is a {{PriorityQueue}} that is now initialized with an
appropriate {{Comparator}} instead of relying on {{Comparable}} edges).
All tests are green. Hoping to help :-)
Claudio
--
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-365) Extend Assertions for checking null references in arrays
[ https://issues.apache.org/jira/browse/SANDBOX-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-365. Resolution: Fixed Assignee: Simone Tripodi patch applied, see [r1234607|https://svn.apache.org/viewvc?view=revisionrevision=1234607] thanks for contributing! Extend Assertions for checking null references in arrays Key: SANDBOX-365 URL: https://issues.apache.org/jira/browse/SANDBOX-365 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-365.txt As discussed at SANDBOX-363, Assertions should provide a method to make sure an input array does not contain any null references. -- 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-363) Check if value is of the correct type in Argument.argument( ClassT type, V value )
[
https://issues.apache.org/jira/browse/SANDBOX-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-363.
Resolution: Fixed
Assignee: Simone Tripodi
patch applied, see
[r1234616|https://svn.apache.org/viewvc?view=revisionrevision=1234616]
as a side note: {{Argument.getParameterTypes}} is an internal method, I moved
the checks in the higher level, as soon as arguments need to be checked,
because invoked in constructors or methods.
Thanks for contributing! ;)
Check if value is of the correct type in Argument.argument( ClassT type, V
value )
Key: SANDBOX-363
URL: https://issues.apache.org/jira/browse/SANDBOX-363
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Priority: Minor
Attachments: SANDBOX-363.txt, SANDBOX-363v2.txt
Although the compiler should check that value is always of the correct type,
a programmatic check should back this up.
--
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-361) Add fluent APIs to build mutable Graphes
[ https://issues.apache.org/jira/browse/SANDBOX-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-361. Resolution: Fixed fixed, see [r1233995|https://svn.apache.org/viewvc?view=revisionrevision=1233995] Add fluent APIs to build mutable Graphes Key: SANDBOX-361 URL: https://issues.apache.org/jira/browse/SANDBOX-361 Project: Commons Sandbox Issue Type: New Feature Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Actual MutableGraph APIs are really *verbose*, using a configuration/builder pattern a la google Guice it is possible to improve the MutableGraph code. That doesn't involve any modification, just additions. -- 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-360) Rename ConverterT, S to TransformerT, S
[ https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-360. Resolution: Fixed Assignee: Simone Tripodi Refactor successfully applied, thanks Benedikt and Matt for the hints! see [r1234122|https://svn.apache.org/viewvc?view=revisionrevision=1234122] Rename ConverterT, S to TransformerT, S --- Key: SANDBOX-360 URL: https://issues.apache.org/jira/browse/SANDBOX-360 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Priority: Minor Since org.apache.commons.beanutils2.Converter is essentially a from of a Transformer (see org.apache.commons.collections.Transformer), it should be named this way. The same applies for org.apache.commons.beanutils2.converters.AbstractConverterT,S. -- 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-356) Generic weight types and algorithms implementations based on wighted graphes
[
https://issues.apache.org/jira/browse/SANDBOX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-356.
Resolution: Fixed
Thanks Claudio for moving this topic forward!
There are just a couple of open issues on [graph], I don't know if you are
pleased to work on them... :P
Generic weight types and algorithms implementations based on wighted graphes
Key: SANDBOX-356
URL: https://issues.apache.org/jira/browse/SANDBOX-356
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Assignee: Simone Tripodi
Labels: generic, graph, shortestpath, type, weight
Attachments: GenericWeightTypeAlsoForAStar.patch,
GenericWeightTypesAndUpdatedShortestPathImplementations.patch,
SANDBOX-356_GenericWeightTypesForSpanningTreeAlgorithms.patch
Hello,
with this issue I propose quite a major improvement to the current version of
Apache Commons Graph, aimed at introducing generic types for weights (edge
weights, vertex weights, etc) and decoupling related properties and
operations using external classes. The proposed changes reflect observations
and proposals that have been evaluated on the dev mailing list, particularly
in the thread with title On graph weight type(s).
A new top level package {{weight}} contains a hierarchy of interfaces
representing different families of weights with their properties and
operations: {{Zero}}, {{Semigroup}}, {{Monoid}}, {{OrderedMonoid}}. These
interfaces are meant to be specified as input by different algorithms
depending on the properties needed: e.g. some only require an ordering on the
weights, some apply operations, etc. A subpackage called {{primitive}}
contains two implementations, {{DoubleWeight}} and {{IntegerWeight}},
respectively wrapping properties and operations on weights of type {{Double}}
and {{Integer}}.
In addition, some of the implementations in the package {{shortestpath}} have
been updated to take advantage of the new generic weight types. In particular
each of the three classes {{Dijkstra}}, {{BellmannFord}} and
{{FloydWarshall}} now has two public methods: a generic one (working with any
kind of weight, provided an {{OrderedMonoid}}) and a shortcut for weights
of type {{Double}}, which is basically identical to the current signature.
Other classes in the package were subject to minor changes to support the
improvements. As an exception, {{AStar}} is still tied to {{Double}} weights
for now: as a future step that could also use generic weights (but it needs
more thinking for the heuristics).
Further, in order to handle generic weight types, I got rid of
{{Double.POSITIVE_INFINITY}} as a way to represent unreachability between two
endpoints in a graph and replaced it with related boolean methods.
Finally, all the tests were updated for compatibility with the new
signatures, and they all run smoothly.
I hope this patch meets the approval of other developers/users. I am
available for discussion and clarification.
Ciao,
Claudio
--
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-346) DotExporter only exports weights that extend Number
[ https://issues.apache.org/jira/browse/SANDBOX-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-346. Resolution: Fixed Assignee: Simone Tripodi patch applied, see [r1221138|https://svn.apache.org/viewvc?view=revisionrevision=1221138] DotExporter only exports weights that extend Number --- Key: SANDBOX-346 URL: https://issues.apache.org/jira/browse/SANDBOX-346 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Claudio Squarcella Assignee: Simone Tripodi Priority: Minor Labels: dot, dotexporter, double, graph, weight Attachments: DotExporterOnlyExportsWeightsExtendingNumber.patch Hi, I propose a tiny patch for the DotExporter in order to print weight as an edge attribute only when the actual weight extends Number, using the method getDouble(). This is to be fully compliant with the DOT language specification on the attribute weight (see http://www.graphviz.org/content/attrs#aweight). Hope this helps, Claudio -- 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-345) Weighted as an interface with generic weight type
[
https://issues.apache.org/jira/browse/SANDBOX-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-345.
Resolution: Fixed
Assignee: Simone Tripodi
Simply amazing Claudio, thanks for the hard work!
I just applied your patch, see
[r1220522|http://svn.apache.org/viewvc?view=revisionrevision=1220522]
I just have modified a part in the DotExporter to avoid multiple checks - the
rest looks more than OK ;)
Thanks for contributing!
Weighted as an interface with generic weight type
-
Key: SANDBOX-345
URL: https://issues.apache.org/jira/browse/SANDBOX-345
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Assignee: Simone Tripodi
Priority: Minor
Labels: graph, weight, weighted
Attachments: WeightedAsAnInterfaceWithGenericWeightType.patch
Hello,
after recent discussions on the mailing list ([Graph] On graph weight
type(s)) I am proposing a first patch to enable support for generic weights
in the current implementation.
Main changes include:
- adding an interface WeightedW with method W getWeight()
- modifying WeightedEdge, WeightedPath, WeightedGraph etc. to implement the
new interface
- changing the implemented algorithms (at the moment they all still require
weights to be Double)
- changing the DOT exporter (prints the weight as an attribute only if it is
of type Double)
- incidentally also fixing a small bug in the DOT exporter ('weight' was part
of the label, now it is a proper attribute as documented in DOT language
specs http://www.graphviz.org/content/attrs#dweight)
This can be the first safe step to dig into different types and/or properties
of weights.
Please let me know if it looks good.
Cheers,
Claudio
--
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-344) No WeightedGraph in current method signatures
[
https://issues.apache.org/jira/browse/SANDBOX-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-344.
Resolution: Fixed
Assignee: Simone Tripodi
GREAT! Thanks a lot for contributing Claudio, you patch has been committed, see
[r1212887|https://svn.apache.org/viewvc?view=revisionrevision=1212887] :)
No WeightedGraph in current method signatures
-
Key: SANDBOX-344
URL: https://issues.apache.org/jira/browse/SANDBOX-344
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Assignee: Simone Tripodi
Priority: Minor
Labels: graph, patch, weightedgraph
Attachments: NoWeightedGraphInMethodSignatures.patch
Hello,
following a discussion on the mailing list (mainly with Simone) I am
providing a small patch to get rid of the interface {{WeightedGraph}} in
all the method signatures for the algorithms currently implemented, basically
replacing it with the equally expressive {{GraphV extends Vertex, We extends
WeightedEdge}}.
The main reason: keep it simple. So far none of the algorithms really needs
the {{WeightedGraph}} interface (e.g. no need for additional methods that
cannot be found in {{Graph}}). With that said I did NOT remove the
{{WeightedGraph}} interface.
Hoping to meet your agreement and waiting for comments,
Ciao
Claudio
--
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] (DIGESTER-160) provide an additional artifact with shaded dependencies
[ https://issues.apache.org/jira/browse/DIGESTER-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-160. - Resolution: Fixed fixed on /trunk, see [r1212338|https://svn.apache.org/viewvc?view=revisionrevision=1212338] provide an additional artifact with shaded dependencies --- Key: DIGESTER-160 URL: https://issues.apache.org/jira/browse/DIGESTER-160 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 an additional artifact with shaded dependencies would alleviate non-maven users the task to manage digester3 dependencies -- 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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-153. - Resolution: Fixed after having applied the Matt's patch that issue can be finally considered resolved :) Thanks Matt for the valuable help, I wouldn't know how to manage it without you! Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 Attachments: 153-ng.patch.txt As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-154) The DigesterBinder is not able to load primitive classes by name
[
https://issues.apache.org/jira/browse/DIGESTER-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-154.
-
Resolution: Fixed
fixed on /trunk, see
[r1210678|https://svn.apache.org/viewvc?view=revisionrevision=1210678]
The DigesterBinder is not able to load primitive classes by name
Key: DIGESTER-154
URL: https://issues.apache.org/jira/browse/DIGESTER-154
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
Since the Digester relies on the ClassLoader to load classes for name, when
passing strings like {{boolean}} or {{double}} it fails.
An idea in order to avoid to redesign the digester, could be façading the
{{Digetser#getClassLoader()}} instance, intercepting the {{loadClass( String
)}} method
--
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] (DIGESTER-159) */object-param-rule is not managed in the XML rules
[
https://issues.apache.org/jira/browse/DIGESTER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-159.
-
Resolution: Fixed
Fix Version/s: 3.2
fixed on trunk, see
[r1210032|https://svn.apache.org/viewvc?view=revisionrevision=1210032]
*/object-param-rule is not managed in the XML rules
---
Key: DIGESTER-159
URL: https://issues.apache.org/jira/browse/DIGESTER-159
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Critical
Fix For: 3.2
XML metaparser never matches {{*/object-param-rule}} rules in xmlrules
descriptors, neither the related {{ObjectCreateRule}} is managed.
What is weird is that tests have never failed before... :/
--
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] (EXEC-34) Race condition prevent watchdog working using ExecuteStreamHandler
[
https://issues.apache.org/jira/browse/EXEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved EXEC-34.
Resolution: Fixed
Fix Version/s: 1.1.1
Assignee: Simone Tripodi (was: Siegfried Goeschl)
Patch has been successfully applied, see
[r1208315|https://svn.apache.org/viewvc?view=revisionrevision=1208315] thanks
Kristian for submitting the patch!
Race condition prevent watchdog working using ExecuteStreamHandler
--
Key: EXEC-34
URL: https://issues.apache.org/jira/browse/EXEC-34
Project: Commons Exec
Issue Type: Bug
Environment: Windows Vista 64bit, dual core CPU
Reporter: Marco Ferrante
Assignee: Simone Tripodi
Priority: Minor
Fix For: 1.1.1
Attachments: EXEC34.patch
Consider this test case (in _DefaultExecutorTest_ class):
{noformat}
/**
* Start a async process using a stream handler and terminate it manually
* before the watchdog timeout occurs
*/
public void testExecuteAsyncWithStreamHandlerAndUserTermination() throws
Exception {
CommandLine cl = new CommandLine(foreverTestScript);
ExecuteWatchdog watchdog = new ExecuteWatchdog(Integer.MAX_VALUE);
PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
System.err);
exec.setStreamHandler(streamHanlder);
MockExecuteResultHandler handler = new MockExecuteResultHandler();
exec.execute(cl, handler);
// DON'T wait for script to run
//Thread.sleep(2000);
// teminate it
watchdog.destroyProcess();
assertTrue(Watchdog should have killed the
process,watchdog.killedProcess());
}
{noformat}
It fails (at least in my environment) because when
_watchdog.destroyProcess()_ is invoked the external process is not bound to
the watchdog yet.
Although there are possible several workarounds, but all of them seem to me
very intrusive in the code. So, I prefer some discussion before preparing and
submitting a patch.
IMHO, the watchdog should handle a reference to the thread running the
process, not to the process itself. In this way, interrupting signals can be
transport using default _interrupt()_ method of class _Thread_.
--
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] (DIGESTER-152) The org.apache.commons.digester3.binder.DigesterLoader doesn't allow binding a default org.xml.sax.Locator
[
https://issues.apache.org/jira/browse/DIGESTER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-152.
-
Resolution: Fixed
Fixed on trunk, see
[r1197908|https://svn.apache.org/viewvc?view=revisionrevision=1197908]
The org.apache.commons.digester3.binder.DigesterLoader doesn't allow binding
a default org.xml.sax.Locator
--
Key: DIGESTER-152
URL: https://issues.apache.org/jira/browse/DIGESTER-152
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
In {{org.apache.commons.digester3.binder.DigesterLoader}} there's no API to
set a default {{org.xml.sax.Locator}} to produced Digester instances
--
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] (DIGESTER-155) ClassLoader reference set to DigesterLoader not set in produced Digester instances
[
https://issues.apache.org/jira/browse/DIGESTER-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-155.
-
Resolution: Fixed
fixed on trunk, see
[r1197917|https://svn.apache.org/viewvc?view=revisionrevision=1197917]
ClassLoader reference set to DigesterLoader not set in produced Digester
instances
--
Key: DIGESTER-155
URL: https://issues.apache.org/jira/browse/DIGESTER-155
Project: Commons Digester
Issue Type: Bug
Reporter: Simone Tripodi
Assignee: Simone Tripodi
{{ClassLoader}} instance set to {{DigesterLoader}} is not referenced to
produced {{Digester}} instances. That would prevent {{Digester}} loading
dynamically classes by name that could be not found.
--
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] (DIGESTER-156) Make (Nested|Set)PropertiesBuilder#addAlias() fluent
[
https://issues.apache.org/jira/browse/DIGESTER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-156.
-
Resolution: Fixed
Fix Version/s: 3.2
fixed on trunk, see
[r1197969|https://svn.apache.org/viewvc?view=revisionrevision=1197969]
Make (Nested|Set)PropertiesBuilder#addAlias() fluent
Key: DIGESTER-156
URL: https://issues.apache.org/jira/browse/DIGESTER-156
Project: Commons Digester
Issue Type: Improvement
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
Actually {{(Nested|Set)PropertiesBuilder#addAlias(String,String)}} method is
inexpressive, taking inspiration from
{{ObjectCreateBuilder#addConstructorArgument(String).ofType(Class)}} APIs can
be made fluent.
--
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] (DIGESTER-157) Improve Set(Nested)PropertiesRuleAlias performances in the XML ruleset while binding rules
[
https://issues.apache.org/jira/browse/DIGESTER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-157.
-
Resolution: Fixed
Fixed on trunk, see
[r1197978|https://svn.apache.org/viewvc?view=revisionrevision=1197978]
Improve Set(Nested)PropertiesRuleAlias performances in the XML ruleset while
binding rules
--
Key: DIGESTER-157
URL: https://issues.apache.org/jira/browse/DIGESTER-157
Project: Commons Digester
Issue Type: Improvement
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
Taking inspiration from
{{org.apache.commons.digester3.xmlrules.ConstructorArgumentRule}},
performances for
{{org.apache.commons.digester3.xmlrules.Set(Nested)PropertiesAliasRule}} can
be performed, since they actually perform linear search in the RulesBinder.
--
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] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-153. - Resolution: Fixed fixed in trunk, see [r1197818|https://svn.apache.org/viewvc?view=revisionrevision=1197818] Add Constructor support to ObjectCreateRule --- Key: DIGESTER-153 URL: https://issues.apache.org/jira/browse/DIGESTER-153 Project: Commons Digester Issue Type: Improvement Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 As shown in the past, the stack method of Digester has some [limitations |http://markmail.org/message/wick27gw6n5weqk2] for fully support the Constructors - it basically cannot use elements in the body as constructor arguments - but it could support arguments extracted from attributes. -- 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] (DIGESTER-151) The org.apache.commons.digester3.binder.DigesterLoader doesn't allow binding a default org.xml.sax.ErrorHandler
[
https://issues.apache.org/jira/browse/DIGESTER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-151.
-
Resolution: Fixed
Fix Version/s: 3.2
Fixed on [r1197213|https://svn.apache.org/viewvc?view=revisionrevision=1197213]
The org.apache.commons.digester3.binder.DigesterLoader doesn't allow binding
a default org.xml.sax.ErrorHandler
---
Key: DIGESTER-151
URL: https://issues.apache.org/jira/browse/DIGESTER-151
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.2
a custom {{org.xml.sax.ErrorHandler}} can be set only to {{Digester}}
instance and not to {{DigesterLoader}}.
API has to be added to set a {{org.xml.sax.ErrorHandler}}.
--
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] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-61. - Resolution: Fixed Assignee: Simone Tripodi Fixed on /trunk, see [r1189035|https://svn.apache.org/viewvc?view=revisionrevision=1189035] Chain 2.0 trunk build is throwing many warnings as a result of generification changes - Key: CHAIN-61 URL: https://issues.apache.org/jira/browse/CHAIN-61 Project: Commons Chain Issue Type: Bug Affects Versions: 2.0 Reporter: Elijah Zupancic Assignee: Simone Tripodi Fix For: 2.0 Attachments: chain-61.diff Original Estimate: 2h Remaining Estimate: 2h When warnings on turned on for build, there are many unchecked conversion errors. These should be systematically investigated and fixed or given a @SuppressWarnings(unchecked) where needed. -- 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] (FUNCTOR-5) Complete the javadoc description of Limit
[ https://issues.apache.org/jira/browse/FUNCTOR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved FUNCTOR-5. -- Resolution: Fixed Assignee: Simone Tripodi patch applied, obrigado Bruno! Complete the javadoc description of Limit - Key: FUNCTOR-5 URL: https://issues.apache.org/jira/browse/FUNCTOR-5 Project: Commons Functor Issue Type: Task Reporter: Bruno P. Kinoshita Assignee: Simone Tripodi Priority: Trivial Attachments: FUNCTOR-5.patch As pointed by Emmanuel, the class Limit's javadoc says: A predicate that returns true the first n times it is invoked. While Offset's javadoc says: A predicate that returns false the first n times it is invoked, and true thereafter. The description of Limit could be updated to match with Offset. -- 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] (OGNL-23) Class.forName() usage is malicious inside OSGi
[
https://issues.apache.org/jira/browse/OGNL-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved OGNL-23.
Resolution: Fixed
Hi Adrian,
that is simply amazing, thanks for your contribution!
I just successfully committed your patch, see r1187867!
Class.forName() usage is malicious inside OSGi
--
Key: OGNL-23
URL: https://issues.apache.org/jira/browse/OGNL-23
Project: OGNL
Issue Type: Bug
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Attachments: patch-OGNL23-v2.txt, patch-OGNL23.txt
{{Class.forName()}} could make OGNL unusable [inside
OSGi|http://olegz.wordpress.com/2008/11/05/osgi-and-classforname/].
The fix would involve the {{ClassLoader.loadClass()}} method, allowing users
setting a custom {{ClassLoader}
Classes affected by that issues are:
* {{org.apache.commons.ognl.DefaultClassResolver}}
* {{org.apache.commons.ognl.OgnlRuntime}}
The {{org.apache.commons.ognl.ASTMap}} class is affected as well, even if
loading {{java.util.LinkedHashMap}} in that way should be safe.
--
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] (FUNCTOR-2) [functor] Improve Functor web page, removing Ant from building
[
https://issues.apache.org/jira/browse/FUNCTOR-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved FUNCTOR-2.
--
Resolution: Fixed
Thanks for contributing Bruno, the patches have been applied!
A recommendation for next patches you will submit: just provide a single patch
file named with the issue key, i.e. {{FUNCTOR-2.patch}} that would simplify the
committer work.
[functor] Improve Functor web page, removing Ant from building
--
Key: FUNCTOR-2
URL: https://issues.apache.org/jira/browse/FUNCTOR-2
Project: Commons Functor
Issue Type: Improvement
Environment: Ubuntu 11.10
Firefox 4
Sun JDK 1.6
Reporter: Bruno P. Kinoshita
Assignee: Simone Tripodi
Priority: Trivial
Attachments: building.patch, examples.patch
Hi all!
The Functor homepage (in SVN trunk) for building the project is a bit out of
date regarding maven and ant. I couldn't follow the maven instructions (it
mentioned Maven 1 -g option, and non-existent ant build properties).
I'm also following the examples in the website, I will revise them during
this weekend, but if someone thinks adding the examples of FUNCTOR- would be
helpful, I could try helping. Could someone with karma please review if these
changes are correct?
BR,
Bruno
--
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] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved OGNL-27. Resolution: Fixed Assignee: Simone Tripodi Patch successfully applied, see [r1184879|https://svn.apache.org/viewvc?view=revisionrevision=1184879], thanks a lot for this contribution! Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Assignee: Simone Tripodi Attachments: to_string_visitor1.patch, to_string_visitor2.patch, to_string_visitor_with_style_recommendations.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- 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] (CHAIN-60) In certain build configurations unit tests fail with the following message: testDefault: Correct command count expected:17 but was:19
[
https://issues.apache.org/jira/browse/CHAIN-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-60.
-
Resolution: Fixed
fixed on [r1178379|https://svn.apache.org/viewvc?view=revisionrevision=1178379]
In certain build configurations unit tests fail with the following message:
testDefault: Correct command count expected:17 but was:19
-
Key: CHAIN-60
URL: https://issues.apache.org/jira/browse/CHAIN-60
Project: Commons Chain
Issue Type: Bug
Affects Versions: 1.2, 1.3, 2.0
Environment: {noformat}
Operating system : Linux(unknown)
Java Home version :
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Builder version :
Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
Java version: 1.6.0_24
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_AU, platform encoding: UTF-8
OS name: linux version: 2.6.32-31-server arch: amd64 Family:
unix
{noformat}
Reporter: Elijah Zupancic
Assignee: Simone Tripodi
Fix For: 2.0
Attachments: chain-60.diff
This bug occurs only on *some* build configurations. On my laptop and on the
continuum build server it occurs every time, but when I try to replicate on
different boxes with the exact same jvm and operating system, it is not
repeatable. Moreover, this bug was happening in the 1.2 and 1.3 versions of
chain and was no a result of changes introduced in 2.0.
The full output of the bug is as follows:
{noformat}
/commons/proper/chain/trunk/pom.xml ( 1173817 )
/commons/proper/chain/trunk/src/assembly ( 1173817 )
/commons/proper/chain/trunk/src/main/assembly (from
/commons/proper/chain/trunk/src/assembly:1172686) ( 1173817 )
/commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml
( 1173817 )
/commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml
( 1173817 )
/commons/proper/chain/trunk/src/test/resources ( 1173817 )
/commons/proper/chain/trunk/src/test/resources/org ( 1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache ( 1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache/commons (
1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain (
1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config
( 1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config-2.xml
(from
/commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config-2.xml:1172686)
( 1173817 )
/commons/proper/chain/trunk/src/test/resources/org/apache/commons/chain/config/test-config.xml
(from
/commons/proper/chain/trunk/src/test/java/org/apache/commons/chain/config/test-config.xml:1172686)
( 1173817 )
Changed: simonetripodi @ Wed 21 Sep 2011 20:02:11 +
Comment: parent reference updated to version 22
Files changed:
/commons/proper/chain/trunk/pom.xml ( 1173818 )
Changed: simonetripodi @ Wed 21 Sep 2011 20:03:47 +
Comment: added missing release metadata
Files changed:
/commons/proper/chain/trunk/pom.xml ( 1173819 )
Changed: simonetripodi @ Wed 21 Sep 2011 20:05:35 +
Comment: 4 spaces replaced with 2 spaces, as generally adopted in commons
Files changed:
/commons/proper/chain/trunk/pom.xml ( 1173821 )
Dependencies Changes:
No dependencies changed
Build Definition:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)
Test Summary:
Tests: 125
Failures: 1
Errors: 0
Success Rate: 99
Total time: 1.1960001
Test Failures:
[jira] [Resolved] (DBUTILS-78) Add asynchronous batch, query, and update calls
[
https://issues.apache.org/jira/browse/DBUTILS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DBUTILS-78.
---
Resolution: Fixed
Assignee: Simone Tripodi
Thanks William for your help, I reintegrated the latest patch to r1176052 -
unfortunately I wasn't able to manage it via {{patch}} command, so I reapplied
mine first and then had a look at your modifications.
Thanks anyway for the new feature!
Add asynchronous batch, query, and update calls
---
Key: DBUTILS-78
URL: https://issues.apache.org/jira/browse/DBUTILS-78
Project: Commons DbUtils
Issue Type: New Feature
Reporter: William R. Speirs
Assignee: Simone Tripodi
Priority: Minor
Fix For: 1.4
Attachments: 08_16_2011.diff, AsyncQueryRunner.java,
AsyncQueryRunnerTest.java, DBUTILS-78_Future.patch,
DBUTILS-78_Future_v2.diff, DBUTILS-78_Future_v2.patch, async.diff, pom.diff
I propose a new QueryRunner class, AsyncQueryRunner, which changes the return
type of batch, query, and update methods. Instead of returning their
respective return types, the methods would return a RunnableFuture. This
would allow callers to either execute the RunnableFuture in a thread or via
an CompletionService like the ExecutorCompletionService.
I have attached a first cut at this class.
--
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
