[jira] [Resolved] (DIGESTER-164) RulesBase performance optimization

[Simone Tripodi (Resolved) (JIRA)]

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

Simone Tripodi resolved DIGESTER-164.
-

   Resolution: Fixed
Fix Version/s: 3.3
 Assignee: Simone Tripodi

Patch applied at [r1328103|http://svn.apache.org/viewvc?rev=1328103&view=rev], 
thanks for contributing Frank!

> RulesBase performance optimization
> --
>
> Key: DIGESTER-164
> URL: https://issues.apache.org/jira/browse/DIGESTER-164
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: 3.2
>Reporter: Frank David Martinez
>Assignee: Simone Tripodi
>Priority: Minor
>  Labels: patch
> Fix For: 3.3
>
> Attachments: rulesbase.patch, rulesbase2.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> RulesBase iterates over all patterns looking for the longest key. It could be 
> optimized with a separate cache of wildcards.

--
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-68) SNAPSHOT tomcat plugin breaks the build

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1328084&view=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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

[Simone Tripodi (Resolved) (JIRA)]

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

Simone Tripodi resolved SANDBOX-416.


Resolution: Fixed

issue resolved according to 
[r1306016|http://svn.apache.org/viewvc?view=revision&revision=1306016] by 
Claudio - well done, mate!

> Improve DFS/BFS visit detecting multiple states and related actions instead 
> of just stop/continue
> -
>
> Key: SANDBOX-416
> URL: https://issues.apache.org/jira/browse/SANDBOX-416
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Graph
>Reporter: Simone Tripodi
>Assignee: Claudio Squarcella
>
> As discussed in 
> [ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
>  {{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return 
> {{boolean}} flags can be sometimes not so intuitive.
> The proposal is replacing {{boolean}} flags return statements with an 
> enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
>  * visit has to be immediately terminated
>  * visit can continue;
>  * current node children visit can be skipped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-403) [BeanUtils2] Refactor Unit tests for better readability

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1300952&view=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] (SANDBOX-398) [BeanUtils2] Implement unit tests for BeanUtils.onClassName()

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1300947&view=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-369) Move logic for type compatibility checking from AccessibleObjectsRegistry to TypeUtils

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1300916&view=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] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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();
>Command 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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1296087&view=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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] (DIGESTER-162) ObjectCreateRule doesn't allow create objects wich type is specified in attributeName only

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1293698&view=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] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1293663&view=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] (SANDBOX-389) [BeanUtils2] Implement populate() on DefaultBeanAccessor

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1243720&view=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-387) [BeanUtils2] Implement possibility to find out if a property readable and/or wirtable

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1243717&view=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-390) [BeanUtils2] Make sure that the internal package does not get exported when packaging as OSGi bundle

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1243715&view=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] (CHAIN-58) Update Chain Context interface to use K,V generics

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1243699&view=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 Map {
> {noformat}
> to:
> {noformat}
> public interface Context extends Map {
> {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-388) Generic Type inference doesn't work in Eclipse

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1241491&view=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 
> SpanningTree,Object> to 
> SpanningTree,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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1241056&view=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-384) Add test for Flow Algorithm

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1240515&view=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-383) Add test for Connectivity

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1240513&view=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-382) Add new test for coloring

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1240375&view=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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1240336&view=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-381) [Graph] Unused class GraphColoringBacktraking

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1239864&view=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1239129&view=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 
> 
>  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-378) [BeanUtils2] Extend StaticMethodsTestCase

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1238953&view=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-377) [BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1238950&view=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-376) [BeanUtils2] Extract magic numbers in AccessibleObjectsRegistry.getObjectTransformationCosts(...) to constants

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1238947&view=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-348) Implement the Boruvka's algorithm

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1238692&view=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-375) Add Connected Components algorithms

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=1238390&view=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-374) Kruskal's algorithm doesn't accept sparse graph

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-359) Move License Agreement to file top

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-373) [BeanUtils2] Implement setProperty( String name ) on DefaultBeanAccessor

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-371) [BeanUtils2] Make sure that a property is readable in DefaultBeanAccessor.getProperty( String name )

[Simone Tripodi (Resolved) (JIRA)]

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

Simone Tripodi resolved SANDBOX-371.


Resolution: Fixed
  Assignee: Simone Tripodi

fixed on r1237703

> [BeanUtils2] Make sure that a property is readable in 
> DefaultBeanAccessor.getProperty( String name )
> 
>
> Key: SANDBOX-371
> URL: https://issues.apache.org/jira/browse/SANDBOX-371
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
>Assignee: Simone Tripodi
> Attachments: SANDBOX-371.txt
>
>
> Problem: The following statement in line 50 in DefaultBeanAccessor may cause 
> a NullPointerException, because getReadMethod() will return null, if no 
> getter for the property is present: 
> {code:java}Object newBean = propertyDescriptor.getReadMethod().invoke( bean 
> ); {code}
> Solution: throw a NoSuchMethodException, if the property is write only.
> {code:java}
> if ( propertyDescriptor.getReadMethod() == null )
> {
> throw new NoSuchMethodException( String.format( "Bean of type %s does not 
> provide a getter for property '%s'!",
>  bean.getClass().getName(), 
> name ) );
> }{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-372) Make the org.apache.commons.graph.visit.GraphVisitHandler able to return objects

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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 List visited = visit( inputGraph ).from( startVertex 
> ).applyingDepthFirstSearch( new MyHandler() );
> {code}
> just adding a callback method in {{GraphVisitHandler}}, something like:
> {code}
> public interface GraphVisitHandler extends Graph, 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-370) GraphML format exporter

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-350) Provide a Reverse-delete algorithm implementation

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-368) [graph] change Dijkstra MST api for accept also Undirect Graph

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-367) Move base implementations from test to main

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-363) Check if value is of the correct type in Argument.argument( Class type, V value )

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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( Class 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-365) Extend Assertions for checking null references in arrays

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-364) Adding generic weight type to model

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-360) Rename Converter to Transformer

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=1234122]

> Rename Converter to Transformer
> ---
>
> 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.AbstractConverter.

--
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-358) Early return/termination for graph visit

[Simone Tripodi (Resolved) (JIRA)]

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

Simone Tripodi resolved SANDBOX-358.


Resolution: Fixed
  Assignee: Simone Tripodi

thanks once again for your great contributions Claudio, your patch has been 
successfully applied, see 
[r1234109|https://svn.apache.org/viewvc?view=revision&revision=1234109]

> Early return/termination for graph visit
> 
>
> Key: SANDBOX-358
> URL: https://issues.apache.org/jira/browse/SANDBOX-358
> Project: Commons Sandbox
>  Issue Type: Improvement
>  Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
>Priority: Minor
>  Labels: graph, visit, visithandler
> Attachments: EarlyTerminationAndSubgraphSkipForSearchAlgorithms.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Hello,
> the current implementations in the class {{Visit}} (package 
> {{org.apache.commons.graph.visit}}) do not include the possibility to stop 
> the search prematurely. That would be more natural (and faster) for many 
> kinds of search, e.g. when looking for the first occurrence of a specific 
> pattern (vertex, path with certain features, etc).
> The easiest solution: changing all method signatures in {{GraphVisitHandler}} 
> from {{void}} to {{boolean}}, forcing the handler to answer the question: 
> _should I continue?_ 
> I understand semantics get a bit entangled (well, not with an appropriate 
> documentation!), so I am open to more verbose options: e.g. a method 
> {{isSearchComplete}} to call after every step... but that would only be more 
> verbose, wouldn't it?
> Waiting for feedback and ready to patch :-)
> 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-361) Add fluent APIs to build mutable Graphes

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-356) Generic weight types and algorithms implementations based on wighted graphes

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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 Weighted 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] (POOL-194) replace synchronized blocks in PoolUtils with Read/Write locks

[Simone Tripodi (Resolved) (JIRA)]

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

Simone Tripodi resolved POOL-194.
-

Resolution: Fixed

fixed on /trunk, see 
[r1213398|https://svn.apache.org/viewvc?view=revision&revision=1213398]

> replace synchronized blocks in PoolUtils with Read/Write locks
> --
>
> Key: POOL-194
> URL: https://issues.apache.org/jira/browse/POOL-194
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 2.0
>
>
> all synchronized Pools implementation in PoolUtils are designed to be fully 
> synchronized, they can be improved by replacing using synchronized blocks 
> with a Read/Write lock policy. 

--
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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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 {{Graph 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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-157) Improve Set(Nested)PropertiesRuleAlias performances in the XML ruleset while binding rules

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-156) Make (Nested|Set)PropertiesBuilder#addAlias() fluent

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-155) ClassLoader reference set to DigesterLoader not set in produced Digester instances

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-152) The org.apache.commons.digester3.binder.DigesterLoader doesn't allow binding a default org.xml.sax.Locator

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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-153) Add Constructor support to ObjectCreateRule

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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] (FUNCTOR-2) [functor] Improve Functor web page, removing Ant from building

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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-23) Class.forName() usage is malicious inside OSGi

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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] (OGNL-27) Move "toString" implementations into visitor pattern.

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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>

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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=revision&revision=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.1960

[jira] [Resolved] (DBUTILS-78) Add asynchronous batch, query, and update calls

[Simone Tripodi (Resolved) (JIRA)]

 [ 
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