[jira] [Commented] (DIGESTER-164) RulesBase performance optimization
[
https://issues.apache.org/jira/browse/DIGESTER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256427#comment-13256427
]
Simone Tripodi commented on DIGESTER-164:
-
It is not clear to me how {{Wildcard.rules}} is useful since it won't be read
after the Wildcard is created.
Can you please explain me that, please?
TIA and all the best
> 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
>Priority: Minor
> Labels: patch
> Attachments: rulesbase.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] [Commented] (DIGESTER-164) RulesBase performance optimization
[ https://issues.apache.org/jira/browse/DIGESTER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256415#comment-13256415 ] Simone Tripodi commented on DIGESTER-164: - Hola Frank, thanks a lot, looks good, I am going to test it. PS for future patches, can you please mind the original code format? TIA! > 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 >Priority: Minor > Labels: patch > Attachments: rulesbase.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] [Commented] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239975#comment-13239975
]
Simone Tripodi commented on SANDBOX-416:
very well done, I like the actual behavior :)
Issue can be IMHO resolved, the only thing I would suggest you to improve is,
when comparing values, putting expected values first, i.e. inetsad of
{code}
if ( stateAfterEdgeDiscovery != VisitState.CONTINUE )
{code}
it could be
{code}
if ( VisitState.CONTINUE != stateAfterEdgeDiscovery )
{code}
and constants could be statically imported. Not an issue, just a matter of
having clean code.
well done!
-Simo
> 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] [Commented] (SANDBOX-416) Improve DFS/BFS visit states
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238156#comment-13238156
]
Simone Tripodi commented on SANDBOX-416:
Good morning!
It looks very good, before resolving the issue I suggest to handle the
{{ABORT}} state in every method - maybe the user had enough of visiting the
graph and evaluated the visit is complete.
When {{ABORT}} is detected, it just stop visiting (different from {{SKIP}} that
should skip only the subtree) and invokes the {{onCompleted()}}.
TIA and well done,
-Simo
> Improve DFS/BFS visit states
>
>
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231722#comment-13231722
]
Simone Tripodi commented on DIGESTER-163:
-
Thanks to Thomas' observations, I opted to drop the lazy loading support -
please see r1301815
Can you do yet another test cycle, when having spare time, please? TIA!
> 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
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231658#comment-13231658
]
Simone Tripodi commented on DIGESTER-163:
-
you are a good observator Thomas ;)
when I coded {{createRuleSet}} the first time, I thought about lazy loading AND
to the fact that users can set different {{ClassLoader}}s - since classes
resolution by name can produce different results, I opted for checking it when
requesting new {{Digester}} instances.
I would like to avoid to add a {{synchronized}} block, even if producing
{{Digester}} instances is quietly fast that would be a bottleneck, thread-safe
behavior with concurrent accesses would be preferred.
Do you have any other suggestion?
TIA!!!
> 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
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231351#comment-13231351
]
Simone Tripodi commented on DIGESTER-163:
-
bad, bad, bad news... ;( investigating again... ;)
> 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
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231164#comment-13231164
]
Simone Tripodi commented on DIGESTER-163:
-
I committed r1301493, I hope this will fix that issue once for all!
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.txt, stack-next.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] [Commented] (CSV-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231157#comment-13231157
]
Simone Tripodi commented on CSV-68:
---
FWIW, +1 to builder and fluent APIs
> Use Builder pattern for CSVFormat
> -
>
> Key: CSV-68
> URL: https://issues.apache.org/jira/browse/CSV-68
> Project: Commons CSV
> Issue Type: Improvement
>Reporter: Sebb
> Attachments: CSV-68.patch
>
>
> Using a builder pattern to create CSVFormat instances would allow the
> settings to be validated at creation time and would eliminate the need to
> keep creating new CSVFormat instances whilst still allowing the class to be
> immutable.
> A possible API is as follows:
> {code}
> CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
> .withEncapsulator('"')
> .withLeadingSpacesIgnored(true)
> .withTrailingSpacesIgnored(true)
> .withEmptyLinesIgnored(true)
> .withLineSeparator("\r\n") // optional, as it would be the default
> .build();
> CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
> with pre-defined format
> .withSurroundingSpacesIgnored(false)
> .build();
> {code}
> Compare this with the current syntax:
> {code}
> // internal syntax; not easy to determine what all the parameters do
> CSVFormat DEFAULT1 = new CSVFormat(',', '"', DISABLED, DISABLED, true, true,
> false, true, CRLF);
> // external syntax
> CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
> {code}
> As a proof of concept I've written skeleton code which compiles (but needs
> completing).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231067#comment-13231067
]
Simone Tripodi commented on DIGESTER-163:
-
HA poor me, I see - the already bound check should be now per-thread, not
global, otherwise threads cannot load the same resource concurrently :S
I'll provide you a new fix attempt ASAP - Thanks for reporting!
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.txt, stack-next.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230593#comment-13230593
]
Simone Tripodi commented on DIGESTER-163:
-
I just committed [r1301217|http://svn.apache.org/viewvc?rev=1301217&view=rev],
can you check if it works in your environment please?
I adopted the strategy of loading the rules stream as soon as the loaders
methods are invoked... less performant but safer :P
Please let me know, thanks in advance!
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230546#comment-13230546
]
Simone Tripodi commented on DIGESTER-163:
-
OH I finally can see where the issue happens - the problem is in
{{org.apache.commons.digester3.xmlrules.FromXmlRulesModule}} where there is an
attempt to read the same {{InputSource}} multiple times ;(
I need to find an alternative {{InputSource}} loading method... otherwise I am
forced to discourage the {{FromXmlRulesModule}} use in a multiple-thread
context...
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230498#comment-13230498
]
Simone Tripodi commented on DIGESTER-163:
-
I just committed a potential fix for that issue - can I kindly ask you to
update your local copy and double check, please?
TIA!!! :)
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230484#comment-13230484
]
Simone Tripodi commented on DIGESTER-163:
-
Ahh I finally got it... :) Fix going to be committed in a short while!
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230479#comment-13230479
]
Simone Tripodi commented on DIGESTER-163:
-
wow, this is really wired, after applied the patch I still get a success:
{code}
Tests run: 210, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:15.049s
[INFO] Finished at: Thu Mar 15 20:55:02 CET 2012
[INFO] Final Memory: 17M/2039M
[INFO]
{code}
Investigating...
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230473#comment-13230473
]
Simone Tripodi commented on DIGESTER-163:
-
I'm reviewing it right now; if you intend to continue participating - I hope
so! - please, in future patches, don't reformat the original code when
providing functional modifications. I suggest you reading the [Contributing
Patches|http://commons.apache.org/patches.html] guideline. Dankeshön ;)
> 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
> Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
> stack-mvn.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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230226#comment-13230226
]
Simone Tripodi commented on DIGESTER-163:
-
Unfortunately, once test is modified, test still pass :(
{code}
Tests run: 209, Failures: 0, Errors: 0, Skipped: 0
{code}
this is my environment:
{code}
$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.3", arch: "x86_64", family: "mac"
{code}
if you just run:
{code}
https://svn.apache.org/repos/asf/commons/proper/digester/trunk commons-digester
&& cd commons-digester && svn test
{code}
you should see the test report...
Can you please let me know? TIA!
> 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
> Attachments: Digester163TestCase.java
>
>
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230201#comment-13230201
]
Simone Tripodi commented on DIGESTER-163:
-
Indeed, restructuring the XML to:
{code}
Author 1
{code}
I am going to commit the test - may I can kindly ask you to checkout the
[trunk|https://svn.apache.org/repos/asf/commons/proper/digester/trunk] and
modify the test there?
Many thanks in advance!
> 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
> Attachments: Digester163TestCase.java
>
>
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230197#comment-13230197
]
Simone Tripodi commented on DIGESTER-163:
-
Just to keep you updated my tests: I am getting {{NPE}}s because {{test.xml}}
looks like
{code}
Author 1
{code}
while rules are configured like (despite the class renaming)
{code}
{code}
so we have two options:
* rules pattern are wrong;
* sample is wrong.
I am removing the {{}} element and see what happens. let you know soon!
> 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
> Attachments: Digester163TestCase.java
>
>
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230186#comment-13230186
]
Simone Tripodi commented on DIGESTER-163:
-
two loaders created by different threads *have to* be allowed, of course, that
is why we are investigating about the problem. I am testing your modifications
right now, I hope to let you know good news ASAP :)
> 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
> Attachments: Digester163TestCase.java
>
>
> 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] [Commented] (SANDBOX-403) [BeanUtils2] Refactor Unit tests for better readability
[ https://issues.apache.org/jira/browse/SANDBOX-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230124#comment-13230124 ] Simone Tripodi commented on SANDBOX-403: 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 > 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230070#comment-13230070
]
Simone Tripodi commented on DIGESTER-163:
-
I imported a simplified version of your testcase in the Digester codebase, see
[r1300873|https://svn.apache.org/viewvc?view=revision&revision=1300873];
unfortunately I am not able to reproduce the issue :(
IIUC - apologize if I am wrong - the problem could be in your wrappers that
allows concurrency in the loader creation - using the {{{ConcurrentHashMap}}
you keep the data structure thread-safe but it doesn't shield from races and
concurrent accesses to the Loader creation...
Can you please check it? TIA!!!
> 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
>
> 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] [Commented] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229076#comment-13229076
]
Simone Tripodi commented on DIGESTER-163:
-
Can you kindly attach a testcase that reproduces the issue? Many thanks in
advance!
> 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
>
> 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] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226902#comment-13226902
]
Simone Tripodi commented on SANDBOX-404:
great, thanks a lot!!!
instead of enjoying vacations, can you please apply the same change on the
branch? It would simplify the future merge, if accepted.
TIA, all the best!
-Simo
PS I was obviously joking ;)
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226859#comment-13226859
]
Simone Tripodi commented on SANDBOX-404:
{quote}
Now, secondary issue: while looking for a solution I also noticed that
{{SpanningTree}} did not have a generic type for the type of weight operations
(i.e. the variable in {{MutableSpanningTree}} had explicit type {{Monoid}}).
So as a first attempt to fix the error I added {{WO}} as a generic type in
{{SpanningTree}} and modified all the classes using it.
{quote}
It is not an issue, it is not broken in my branch (at least).
Why should it matter which type of Monoid the spanning trees are using, at APIs
level? They don't add any value to execute algorithms.
If you can take a look at the experimental branch, I simplified a lot also the
chain builders signatures, getting rid of useless generic types.
For what I've experienced, the only types that really matter are Vertices
{{V}}, Edges {{E}} and Weights {{W}} (and {{Graph}} and its specializations)
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226589#comment-13226589
]
Simone Tripodi commented on SANDBOX-404:
Hi Claudio,
unfortunately the patch you committed doesn't work when launching tests from
CLI (OTOH works well inside eclipse), follows below the errors I got:
{code}
$ svn info
Path: .
URL: https://svn.apache.org/repos/asf/commons/sandbox/graph/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1299097
Node Kind: directory
Schedule: normal
Last Changed Author: cs
Last Changed Rev: 1298136
Last Changed Date: 2012-03-07 22:34:21 +0100 (Wed, 07 Mar 2012)
...
mvn clean test
...
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/shortestpath/BellmannFordTestCase.java:[77,63]
type parameters of
org.apache.commons.graph.shortestpath.AllVertexPairsShortestPath,java.lang.Double,WO>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/KruskalTestCase.java:[71,77]
type parameters of
org.apache.commons.graph.SpanningTree,java.lang.Double>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/shortestpath/AStarTestCase.java:[98,65]
type parameters of
org.apache.commons.graph.shortestpath.HeuristicBuilder,java.lang.Double,org.apache.commons.graph.model.UndirectedMutableWeightedGraph,java.lang.Double>,WO>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/ReverseDeleteTestCase.java:[53,67]
type parameters of
org.apache.commons.graph.SpanningTree,java.lang.Double>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/PrimTestCase.java:[71,77]
type parameters of
org.apache.commons.graph.SpanningTree,java.lang.Double>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/shortestpath/DijkstraTestCase.java:[69,68]
type parameters of
org.apache.commons.graph.WeightedPath,java.lang.Double>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/BoruvkaTestCase.java:[71,77]
type parameters of
org.apache.commons.graph.SpanningTree,java.lang.Double>
cannot be determined; no unique maximal instance exists for type variable WO
with upper bounds
java.lang.Object,org.apache.commons.graph.weight.Monoid,java.util.Comparator
[INFO] 7 errors
[INFO] -
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 47.856s
[INFO] Finished at: Sat Mar 10 00:23:30 CET 2012
[INFO] Final Memory: 16M/2039M
[INFO]
{code}
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VALIDATOR-306) DomainValidator accepts labels longer than 63 chars and domain name lengths exceeding 255 chars
[ https://issues.apache.org/jira/browse/VALIDATOR-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226033#comment-13226033 ] Simone Tripodi commented on VALIDATOR-306: -- OK, ack - can you provide a testcase with a fix proposal please? TIA! > DomainValidator accepts labels longer than 63 chars and domain name lengths > exceeding 255 chars > --- > > Key: VALIDATOR-306 > URL: https://issues.apache.org/jira/browse/VALIDATOR-306 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4.1 >Reporter: Jukka Timonen > > DomainValidator accepts labels longer than 63 chars and domain lengths that > exceed 255 characters. > Field max lengths are specified in http://www.ietf.org/rfc/rfc1034.txt > section 3. > Example string: > ssdfsdfsdsdfssdsdfsdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfss.com > 1.3.1 crashes at least when called form EmailValidator > current 1.4.1-SNAPSHOT thinks it's ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VALIDATOR-306) DomainValidator accepts labels longer than 63 chars and domain name lengths exceeding 255 chars
[ https://issues.apache.org/jira/browse/VALIDATOR-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226023#comment-13226023 ] Simone Tripodi commented on VALIDATOR-306: -- did you try to test it against 1.4.0, that is the lates released? TIA > DomainValidator accepts labels longer than 63 chars and domain name lengths > exceeding 255 chars > --- > > Key: VALIDATOR-306 > URL: https://issues.apache.org/jira/browse/VALIDATOR-306 > Project: Commons Validator > Issue Type: Bug > Components: Routines >Affects Versions: 1.4.1 >Reporter: Jukka Timonen > > DomainValidator accepts labels longer than 63 chars and domain lengths that > exceed 255 characters. > Field max lengths are specified in http://www.ietf.org/rfc/rfc1034.txt > section 3. > Example string: > ssdfsdfsdsdfssdsdfsdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfssdfsdfsdsdfssdsdfss.com > 1.3.1 crashes at least when called form EmailValidator > current 1.4.1-SNAPSHOT thinks it's ok -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-409) Drop Vertex/Edge marker interfaces
[
https://issues.apache.org/jira/browse/SANDBOX-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224105#comment-13224105
]
Simone Tripodi commented on SANDBOX-409:
Created branch on
https://svn.apache.org/repos/asf/commons/sandbox/graph/branches/drop-marker-interfaces-feature
> Drop Vertex/Edge marker interfaces
> --
>
> Key: SANDBOX-409
> URL: https://issues.apache.org/jira/browse/SANDBOX-409
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>
> As widely discussed in the ML, there is a general agreement on dropping the
> {{Vertex}} and {{Edge}} interface and allow {{Graph}} using whatever object
> as node/arc.
> Due to the large number of modifications involved, I intend working on it on
> a separate branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-352) Provide Cheriyan-Mehlhorn/Gabow's strongly connected component algorithm implementation
[
https://issues.apache.org/jira/browse/SANDBOX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224087#comment-13224087
]
Simone Tripodi commented on SANDBOX-352:
Nice to have the issue resolved - less nice the bunch of modifications involved.
The commit includes both the issue resolution AND a refactoring that is *not*
related to the current issue resolution - please next times split steps you
intend to perform ad *discuss first*.
Sentences like:
{code}
+return new KosarajuSharirAlgorithm( graph
).applyingKosarajuSharir( source );
+return new CheriyanMehlhornGabowAlgorithm( graph
).applyingCheriyanMehlhornGabow();
+return new TarjanAlgorithm( graph ).applyingTarjan();
{code}
why you have to explicitly call the method with the same name? It is a little
redundant, check [r1297872|http://svn.apache.org/viewvc?rev=1297872&view=rev]
out to see if you agree how I propose modifying the signatures.
As a side note: {{System.out.println}} should be removed, discuss on {{dev@}}
to add a logger if needed.
> Provide Cheriyan-Mehlhorn/Gabow's strongly connected component algorithm
> implementation
> ---
>
> Key: SANDBOX-352
> URL: https://issues.apache.org/jira/browse/SANDBOX-352
> Project: Commons Sandbox
> Issue Type: Sub-task
>Reporter: Simone Tripodi
>Assignee: Marco Speranza
>
> The {{CheriyanMehlhornGabow}} class contains and empty
> [Cheriyan-Mehlhorn/Gabow|http://en.wikipedia.org/wiki/Cheriyan%E2%80%93Mehlhorn/Gabow_algorithm]'s
> algorithm implementation that has 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] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223155#comment-13223155
]
Simone Tripodi commented on SANDBOX-404:
please don't shutdown because this is a matter of making the component good
software, not just writing code!
So I deduce that having an interface to define the behavior is not enough,
users are still able to create an {{Addition}} instance and implement the
multiplication operator inside - it doesn't matter how we call it... uh...
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223081#comment-13223081
]
Simone Tripodi commented on SANDBOX-404:
Hi Claudio!
I still don't understand how the rename simplifies the actual scenario design:
I suppose that users with the need to calculate a _Strongly Connected
Component_ on their graph data are enough educated that should understand basic
Algebra, if even a B.Sc. like me does I suppose everybody does :P
The only way to evaluate the _if and when_ condition is IMHO listing at least
one graph algorithm that requires a different Monoid to perform its execution,
otherwise no needs to model something unused.
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_FromMonoidToAddition.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[ https://issues.apache.org/jira/browse/SANDBOX-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222301#comment-13222301 ] Simone Tripodi commented on SANDBOX-401: I simply don't use wildcard imports and not sure how many of us use it - I suggest you not using it > [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 > 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] [Commented] (SANDBOX-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[
https://issues.apache.org/jira/browse/SANDBOX-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1366#comment-1366
]
Simone Tripodi commented on SANDBOX-401:
Just saw the patch and indeed you can do it better ;) Don't get crazy with
[Rube Goldber|http://www.rubegoldberg.com/?page=home]'s machines, just declare
the {{private int hashCode}} as {{final}} and compute it just after all fields
members are built. Why you do need {{computeHashCode()}}? Just to add another
piece in the machine? ;)
{{AccessbileObjectDescirptor}} is already immutable - I don't mind if init
takes longer - that op will be performed only once and acceding to that field
will be always linear.
Looking forward next patch, TIA.
> [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
> Attachments: SANDBOX-401.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] [Commented] (CHAIN-67) Refactor of explicit Exception throws to a RuntimeException type
[
https://issues.apache.org/jira/browse/CHAIN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1301#comment-1301
]
Simone Tripodi commented on CHAIN-67:
-
Patch looks more than good, I am going to apply it, thanks!
> 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
>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] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221906#comment-13221906
]
Simone Tripodi commented on SANDBOX-404:
Until there will be _real_ need of adding new Monoid implementations, I would
suggest to postpone the problem and keep *your* version of the patch.
Let's fight with the right weapons when we need, I wouldn't use a katana to
kill a fly (unless I am Bruce Willis and I'm in Pulp Fiction :P)
best and thanks!
-Simo
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221877#comment-13221877
]
Simone Tripodi commented on SANDBOX-404:
hola,
having a look at the patch I am not really happy on how signatures heavily
changed, once dropped the {{OrderedMonoid}}, but I can safety live with it.
The rename instead doesn't convince me at all: {{Monoid}} perfectly reflects
the monoid definition - it is an interface indeed - {{Addition}} is one monoid
*instance*. What is we have to add more Monoid operations? Do you intend to
create new monoid for each operation?
> Simplify weight model
> -
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-404) merge Zero and Semigroup in the Monoid
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221636#comment-13221636
]
Simone Tripodi commented on SANDBOX-404:
Ciao Claudio,
Thanks for the feedbacks, anyway I think it worths analyzing more deeply how to
disambiguate cases in wich our concrete implementations have the need to
implement more than Monoid at the same time, before applying the patch.
I hijacked specific discussion here because in the ML we were speaking about 2
different topics, having a spike to speak about should drive us in the right
direction.
going offline in a while until tonight, best and have a nice WE,
-Simo
> merge Zero and Semigroup in the Monoid
> --
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-402) Add GraphML importer
[
https://issues.apache.org/jira/browse/SANDBOX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221630#comment-13221630
]
Simone Tripodi commented on SANDBOX-402:
yes that is what I mean maybe poorly expresses, given that {{Graph}} is a data
structure wich generics, the importer should understand wich
{{Vertex}}/{{Edge}} type has to deserialize.
Under the fluent APIs PoV, I would suggest something like:
{code}
Graph g = CommonsGraph.import( "path/to/gml/file.xml" ).usingGraphML(); // or
DotNotation
{code}
maybe with few overloads:
{code}
import( "path/to/gml/file.xml" ).usingGraphML();
import( new File( "path/to/gml/file.xml" ) ).usingGraphML();
import( URI.create( "http://my.rst.server/graph.xml"; ) ).usingGraphML();
{code}
and so on... WDYT?
> Add GraphML importer
>
>
> Key: SANDBOX-402
> URL: https://issues.apache.org/jira/browse/SANDBOX-402
> Project: Commons Sandbox
> Issue Type: New Feature
> Components: Graph
>Reporter: Thomas Neidhart
>
> There is already an GraphML exporter and it would be nice to have an importer
> too, but for reasons of testing and convenience.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-402) Add GraphML importer
[ https://issues.apache.org/jira/browse/SANDBOX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221583#comment-13221583 ] Simone Tripodi commented on SANDBOX-402: It would be nice having the general one, what it's not clear to me is how binding parsed elements to target graph/vertex/edge, it would require factories, maybe... > Add GraphML importer > > > Key: SANDBOX-402 > URL: https://issues.apache.org/jira/browse/SANDBOX-402 > Project: Commons Sandbox > Issue Type: New Feature > Components: Graph >Reporter: Thomas Neidhart > > There is already an GraphML exporter and it would be nice to have an importer > too, but for reasons of testing and convenience. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-400) Switch the Base graph implementation underlying data structures to the thread safe version
[ https://issues.apache.org/jira/browse/SANDBOX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221257#comment-13221257 ] Simone Tripodi commented on SANDBOX-400: tests restored on r1296445 > 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] [Commented] (SANDBOX-397) [BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor with NoSuchMethodEceptions
[
https://issues.apache.org/jira/browse/SANDBOX-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217086#comment-13217086
]
Simone Tripodi commented on SANDBOX-397:
I still haven't had the time to take a look at your patches, we didn't even
agree on the proposed design that you already tracked all the roadmap? What if
I don't agree on one of the the proposed modifications?
_I think it is the right thing to do_ doesn't mean that *it is*.
I'll let you know as soon as I get the chance to have a look at your patches,
and provide you feedbacks.
> [BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor
> with NoSuchMethodEceptions
>
>
> Key: SANDBOX-397
> URL: https://issues.apache.org/jira/browse/SANDBOX-397
> Project: Commons Sandbox
> Issue Type: Task
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-397.txt, SANDBOX-397_SRP.txt,
> SANDBOX-397_SRPv2.txt
>
>
> At the moment, methods in {{DefaultBeanAccessor}} throw a
> {{NullPointerException}}, if no {{PropertyDescriptor}} for a given property
> name can be retrieved. As discussed on the ML (see
> http://markmail.org/thread/zlehclmybp5xgn5n) this behavior should be changed
> to throwing {{NoSuchMethodException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FUNCTOR-1) [functor] New components: summarize and aggregate
[
https://issues.apache.org/jira/browse/FUNCTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216357#comment-13216357
]
Simone Tripodi commented on FUNCTOR-1:
--
Hi Liviu,
thanks for the contribution, patch looks good. I have anyway few observations
before applying it:
* the name {{*AggregatorFunction_2_}} doesn't help since doesn't express any
semantic. Can you change them in a more self descriptive names?
* In the {{org.apache.commons.functor.aggregate.functions}} package I just see
the implementation for {{Double}} and one {{Integer}} related class - maybe you
forgot to {{svn add}} the other implementations?
* Could you provide implementations also for other primitive wrappers?
Documentaion under {{src/site/xdoc}} is more than fine and satisfies FUNCTOR-4
- feel free to enhance the doc adding more samples!
Thanks for the hard work, looking forward the next patch version!
-Simo
> [functor] New components: summarize and aggregate
> -
>
> Key: FUNCTOR-1
> URL: https://issues.apache.org/jira/browse/FUNCTOR-1
> Project: Commons Functor
> Issue Type: New Feature
> Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly
> 1.4 though I haven't tested).
>Reporter: Liviu Tudor
>Assignee: Simone Tripodi
>Priority: Minor
> Labels: features
> Attachments: commons-functor-aggregate+summarizer.zip,
> commons-functor.patch.bz2, functor.patch.bz2
>
>
> This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340
> -- as instructed I'm finally hoping to get the code in the right place and
> hopefully this is something that the functor component could do with.
> Whereas initially I just started with the summarizer component, I have added
> now the second one, the "aggregator" as they are somehow related. If this
> code proves to be useful to functor in any way, it would actually be good to
> get some feedback on these 2 to see if the class hierarchy can in fact be
> changed to share some common functionality as I feel (probably due to the
> similar needs that lead to writing/using these components) that somehow they
> should share a common base.
> In brief, the 2 components:
> * aggregator: this just allows for data to be aggregated in a user defined
> way (e.g. stored in a list for the purpose of averaging, computing the
> arithmetic median etc). The classes provided actually offer the
> implementation for storing data in a list and computing the above-mentioned
> values or summing up everything.
> * timed summarizer: this is another variation of the aggreator, however, it
> adds the idea of regular "flushes", so based on a timer it will reset the
> value and start summing/aggregating the data again. Rather than using an
> aggregator which would store the whole data series (possibly for applying
> more complex formulas), this component just computes on the fly on each
> request the formula and stores the result of it. (Which does mean things like
> computing arithmetic mean, median etc would be difficult to compute without
> knowing upfront how many calls will be received -- i.e. how many elements we
> will be required to summarize/aggregate.) So the memory footprint of running
> this is much smaller -- even though, as I said, it achieves similar results.
> I have only provided a summarizer which operates on integers, but obviously
> others for float, double etc can be created if we go ahead with this design.
> Hopefully the above make sense; this code has resulted from finding myself
> writing similar components to these a few times and because it's always been
> either one type (e.g. aggregator) or another (summarizer) I haven't given
> quite possibly enough thought to the class design to join these 2. Also,
> unfortunately, the time I sat down to make these components a bit more
> general and submitted issue 340 was nearly 3 months ago so I'm trying to
> remember myself all the ideas I had at a time so bear with me please if these
> are still a bit fuzzy :) However, if you can make use of these I'm quite
> happy to elaborate on areas that are unclear and obviously put some effort
> into getting these components to the standards required to put these into a
> release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-66) Updated Chain documentation to include new changes to the API
[ https://issues.apache.org/jira/browse/CHAIN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215971#comment-13215971 ] Simone Tripodi commented on CHAIN-66: - Sorry to join late the discussion Elijah, apologize. Do you have some spare time to help me on this? TIA, -Simo > 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 > Labels: documentaion > > 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] [Commented] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212981#comment-13212981
]
Simone Tripodi commented on SANDBOX-396:
patch looks good, anyway:
{quote}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{quote}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} that would
help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
> [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
> Attachments: SANDBOX-396.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] [Commented] (SANDBOX-395) Correct names for classes and variables related to operations on weights
[
https://issues.apache.org/jira/browse/SANDBOX-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212973#comment-13212973
]
Simone Tripodi commented on SANDBOX-395:
Hi Claudio,
please commit it! eventual modifications can be performed while working, I'm
confident you know very well the topic ;)
Best,
-Simo
> Correct names for classes and variables related to operations on weights
>
>
> Key: SANDBOX-395
> URL: https://issues.apache.org/jira/browse/SANDBOX-395
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Claudio Squarcella
>Priority: Minor
> Labels: graph, operations, weight
> Attachments:
> SANDBOX-395_CorrectClassAndVariableNamesForWeightOperations.patch
>
>
> Hi all,
> as discussed in ML already the current classes/variables that refer to
> operations on weights can be renamed for better expressiveness:
> * all the classes under {{weight.primitive}} should be renamed from {{XXX}}
> to {{XXXOperations}} because they actually contain operations on weights
> (they do not represent weights themselves);
> * in the actual algorithms, all variable names for weight operations should
> actually be something like {{weightOperations}} instead of the name of the
> interface (e.g. {{orderedMonoid}}).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-394) Check arguments
[ https://issues.apache.org/jira/browse/SANDBOX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211540#comment-13211540 ] Simone Tripodi commented on SANDBOX-394: go for it, looking forward the commit! > Check arguments > --- > > Key: SANDBOX-394 > URL: https://issues.apache.org/jira/browse/SANDBOX-394 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Marco Speranza >Assignee: Marco Speranza >Priority: Minor > > Add the assertion for classes *SourceSelector and check if the Vertex is > contained in the input Graph before selecting the algorithm to apply -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-394) Check arguments
[
https://issues.apache.org/jira/browse/SANDBOX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211370#comment-13211370
]
Simone Tripodi commented on SANDBOX-394:
go for it. in our "in-memory" implementation {{boolean containsVertex( Vertex v
) }} would mean shortcutting {{getAdjacencyList().containsKey( v )}}, but I
expect that {{Graph}} vendors would adopt a different strategy.
> Check arguments
> ---
>
> Key: SANDBOX-394
> URL: https://issues.apache.org/jira/browse/SANDBOX-394
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Marco Speranza
>Priority: Minor
>
> Add the assertion for classes *SourceSelector and check if the Vertex is
> contained in the input Graph before selecting the algorithm to apply
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-394) Check arguments
[ https://issues.apache.org/jira/browse/SANDBOX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1327#comment-1327 ] Simone Tripodi commented on SANDBOX-394: I'd say that that approach could be generally applied in every chained method for every entry point. Let's check algorithms input before starting any execution. > Check arguments > --- > > Key: SANDBOX-394 > URL: https://issues.apache.org/jira/browse/SANDBOX-394 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Marco Speranza >Priority: Minor > > Add the assertion for classes *SourceSelector and check if the Vertex is > contained in the input Graph before selecting the algorithm to apply -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207985#comment-13207985
]
Simone Tripodi commented on CHAIN-58:
-
it makes a lot of sense, thanks for the hint!
> 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] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206757#comment-13206757
]
Simone Tripodi commented on CHAIN-58:
-
Hi Elijah,
thanks for reviewing! I'll check in the modifications as soon as I get a cycle.
If you want to start taking care of the doc, it would be *really* appreciated -
I am not a native English speaker and sometimes my text is not good :P
Anyway, before releasing, I see important fixing the following issues:
* checking the binary backward compatibility;
* if the binary backward compatibility is no longer maintained (and I am sure
there is something broken), rename the package in {{org.apache.commons.chain2}}
and consequently update {{groupId}} in the POM;
* splitting the project in multi-module project.
WDYT?
-Simo
> 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
> 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] [Commented] (VALIDATOR-304) Support for additional Discovery Bins in the CreditCardValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206740#comment-13206740 ] Simone Tripodi commented on VALIDATOR-304: -- Harrhy, can you provide a patch with testcase to fix the issue, please? TIA! > Support for additional Discovery Bins in the CreditCardValidator > > > Key: VALIDATOR-304 > URL: https://issues.apache.org/jira/browse/VALIDATOR-304 > Project: Commons Validator > Issue Type: Improvement > Components: Framework >Affects Versions: 1.3.1 Release, 1.4 > Environment: All >Reporter: Harrhy Saladagu >Priority: Critical > Labels: patch > Fix For: 1.4 > > > Currently, The CreditCardValidator considers only cards having BINS "6011" as > Discovery Card. This limits the usage of newly supported BINs by Discovery > like "644" and "65". > So, we need to support the newly added BINs by Discovery in > CreditCardValidator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use Java6 annotation processing to generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205659#comment-13205659
]
Simone Tripodi commented on DIGESTER-158:
-
always *amazing* feedbacks from you, Matt!!!
I think that the suggested multi-module approach sounds the way to go! I will
take care of it as soon as I get a cycle to dedicate to Digester and moving
forward this issue from its status of problem to a feature :)
> Use Java6 annotation processing to generate RulesModule instances at
> compile-time
> -
>
> Key: DIGESTER-158
> URL: https://issues.apache.org/jira/browse/DIGESTER-158
> Project: Commons Digester
> Issue Type: New Feature
>Affects Versions: 3.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 3.3
>
>
> Implement a
> [http://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/Processor.html]
> to process Digester annotations rules and generate {{RulesModule}} instances
> at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201616#comment-13201616
]
Simone Tripodi commented on SANDBOX-388:
Hi Steven!!
simply amazing!!! Since you are an ASF committer, would you be pleased to be
granted to commit to Sandbox? Commons Sandbox is open to all ASF committers, I
would be more than glad if you could participate!
Many thanks in advance!
> 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
>Priority: Blocker
>
> {{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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201478#comment-13201478
]
Simone Tripodi commented on SANDBOX-388:
the problem is that for {{findMaxFlow()}} method it never infers the {{W}}
type, even with valid graph :(
> 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
>Priority: Blocker
>
> {{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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201346#comment-13201346
]
Simone Tripodi commented on SANDBOX-388:
Hi Jörg, sorry for the ignorance, but... I don't know how to install Oracle
JDK7 on Mac Os X :(
> 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
>Priority: Blocker
>
> {{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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201320#comment-13201320
]
Simone Tripodi commented on SANDBOX-388:
what worries me is that Eclipse users would be reluctant on using our APIs
because of that issue... ;(
> 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
>Priority: Blocker
>
> {{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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201304#comment-13201304
]
Simone Tripodi commented on SANDBOX-388:
what is driving me crazy is that running from CLI
{quote}
$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
{quote}
doesn't report the same error :(
> 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
>Priority: Blocker
>
> {{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] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201233#comment-13201233
]
Simone Tripodi commented on SANDBOX-348:
Thank you Thomas, and welcome to the brotherhood! :)
> 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: BoruvkaTestCase2.java,
> DefaultSpanningTreeAlgorithmSelector.java,
> 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] [Commented] (SANDBOX-387) [BeanUtils2] Implement possibility to find out if a property readable and/or wirtable
[
https://issues.apache.org/jira/browse/SANDBOX-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200953#comment-13200953
]
Simone Tripodi commented on SANDBOX-387:
BeanUtils2 has never been released, so no issues on breaking APIs.
-1 on your consideration about inconsistency, if someone calls {{on( String
argument )}} expects to call methods on the {{String}} instance.
I like the preconditions language idea, but I would prefer stay focused on
completing the TODOs beofore, and come back speaking once completed (it will be
easier reusing stuff)
> [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
>
> 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] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200949#comment-13200949
]
Simone Tripodi commented on SANDBOX-348:
Hi Thomas!
simply brilliant, thanks for your effort! There's no need to provide a patch,
since you are already a commons committer feel free to commit the modifications
and don't forget to add yourself in the developers list in the pom ;)
I have just 2 minor observations:
* There is no reason to keep 2 Boruvka implementations, so let's keep just the
fastest
* I just suggest to move the {{SuperVertex}} in its proper classfile, to
simplify the algorithms class.
Very well done, thanks!
> 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: BoruvkaTestCase2.java,
> DefaultSpanningTreeAlgorithmSelector.java,
> 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] [Commented] (SANDBOX-387) [BeanUtils2] Implement possibility to find out if a property readable and/or wirtable
[
https://issues.apache.org/jira/browse/SANDBOX-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200903#comment-13200903
]
Simone Tripodi commented on SANDBOX-387:
Good thought.
I honestly started to prefer much more compact and less explicit (and verbose)
sentences, like {{on( myBean ).set( "propertyName" ).with( valueObject )}},
(that involves actual APIs change) so {{on( myBean ).isReadble( "propertyName"
)}} is my preferred on.
Anyway,
{code}
if ( on( myBean ).isWritable( "propertyName" )
{
on( myBean ).setProperty( "propertyName" ).withValue( "This is a String
value!" );
}
{code}
looks less functional and redundant, we could move to a new option, something
like (more or less):
{code}
ifIsWritable( "propertyName" ).on( myBean ).set( "This is a String value!" );
{code}
> [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
>
> 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] [Commented] (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200383#comment-13200383 ] Simone Tripodi commented on LOGGING-124: If someone opens an issue, he has the reporter role, not the owner. If you resolved your own issue with a different approach, commons-logging will continue be affected by the same problem. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Christian Schneider > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200074#comment-13200074
]
Simone Tripodi commented on SANDBOX-382:
don't worry ;)
once applied your patch and executed the tests from CLI, I got the following
error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project commons-graph: Compilation failure:
Compilation failure:
[ERROR]
/Users/simonetripodi/Documents/workspace/commons-graph/src/test/java/org/apache/commons/graph/coloring/GraphColoringBackTrackingTestCase.java:[51,16]
incompatible types; inferred type argument(s)
org.apache.commons.graph.Vertex,org.apache.commons.graph.Edge,java.lang.Object
do not conform to bounds of type variable(s) V,E,G
[ERROR] found : org.apache.commons.graph.coloring.ColorsBuilder
[ERROR] required: java.lang.Object
[ERROR]
/Users/simonetripodi/Documents/workspace/commons-graph/src/test/java/org/apache/commons/graph/coloring/GraphColoringTestCase.java:[51,16]
incompatible types; inferred type argument(s)
org.apache.commons.graph.Vertex,org.apache.commons.graph.Edge,java.lang.Object
do not conform to bounds of type variable(s) V,E,G
[ERROR] found : org.apache.commons.graph.coloring.ColorsBuilder
[ERROR] required: java.lang.Object
{code}
hint: you should cast the {{null}} graph argument, or avoiding to chain next
methods on null graph
> 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
> Attachments: SANDBOX-382_AddedColoringTestCase.patch,
> SANDBOX-382_AddedColoringTestCase_Modified.patch,
> SANDBOX-382_AddedColoringTestCase_Modified_2.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] [Commented] (SANDBOX-383) Add test for Connectivity
[
https://issues.apache.org/jira/browse/SANDBOX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200054#comment-13200054
]
Simone Tripodi commented on SANDBOX-383:
Hi Marco,
after executed your tests from CLI, I got the following error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project commons-graph: Compilation failure
[ERROR]
/Users/simonetripodi/Documents/workspace/commons-graph/src/test/java/org/apache/commons/graph/connectivity/FindConnectedComponetTestCase.java:[45,30]
incompatible types; inferred type argument(s)
org.apache.commons.graph.Vertex,org.apache.commons.graph.Edge,java.lang.Object
do not conform to bounds of type variable(s) V,E,G
[ERROR] found :
org.apache.commons.graph.connectivity.ConnectivityBuilder
{code}
my environment is:
{code}
$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
{code}
did you experience the same?
TIA,
-Simo
> 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
> Attachments: SANDBOX-383_AddConnectivityTestCase.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] [Commented] (SANDBOX-385) Provide Edmonds-Karp algorithm
[ https://issues.apache.org/jira/browse/SANDBOX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200050#comment-13200050 ] Simone Tripodi commented on SANDBOX-385: Ciao Claudio, great, looking forward to apply your patch!!! > 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 > > 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] [Commented] (SANDBOX-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200049#comment-13200049
]
Simone Tripodi commented on SANDBOX-382:
Hi Marco,
looks like the {{NotEnoughColorsException}} implementation is not included in
the patch, maybe you missed the {{svn add}}...
Can you provide a new one, please?
TIA!
> 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
> Attachments: SANDBOX-382_AddedColoringTestCase.patch,
> SANDBOX-382_AddedColoringTestCase_Modified.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] [Commented] (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199986#comment-13199986 ] Simone Tripodi commented on LOGGING-124: JIRA the ASF issue tracker not a MailingList neither a Forum, so marking an Issue closed because you switched somewhere else, is a nonsense. The issue continues to exist, slf4j doesn't fix JCL OSGi issue. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Christian Schneider > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199626#comment-13199626
]
Simone Tripodi commented on SANDBOX-379:
{quote}
As I said above, {{describe()}}, {{populate()}}, {{clone()}}, etc are the
endpoints of a fluent call. So I thought putting them together in one test is a
good idea.
{quote}
I don't, each method could involve a good number of test. See your contribution
only for {{describe()}}.
{quote}
Okay, so do we create a test case for every method on {{BeanAccessor}}?
{quote}
Isn't what we are already doing? You already provided tests according to this...
{quote}
I think that would be a good idea. I don't like huge test classes. And a test
class for all methods on {{BeanAccessor}} would be gigantic (as you mentioned).
{quote}
At least we have an agreement, looking forward your patch!
> [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
> Attachments: SANDBOX-379.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] [Commented] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199620#comment-13199620
]
Simone Tripodi commented on SANDBOX-379:
We do have {{GetPropertyTestCase}}, {{MethodsTestCase}},
{{SetPropertyTestCase}}, can you explain what's the reason why the {{describe}}
tests have to be in {{BeanAccessorTestCase}}?
It would be more obvious creating a serie of {{DescribeTestCase}}
> [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
> Attachments: SANDBOX-379.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] [Commented] (SANDBOX-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199565#comment-13199565
]
Simone Tripodi commented on SANDBOX-382:
HI Marco,
patch looks good, 2 minor observation before applying it:
* {{GraphException}} is a runtime exception, so test methods shouldn't
explicitly throw it;
* I would suggets to create a proper layer exception that extends
{{GraphException}}, just like {{PathNotFoundException}} in the shortest path
algorithms.
Can you modify the patch please?
TIA!
> 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
> Attachments: SANDBOX-382_AddedColoringTestCase.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] [Commented] (SANDBOX-380) [graph] Add cobertura report and increase test coverage
[ https://issues.apache.org/jira/browse/SANDBOX-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199238#comment-13199238 ] Simone Tripodi commented on SANDBOX-380: good! I applied the patch (see [r1239853|http://svn.apache.org/viewvc?rev=1239853&view=rev]) and I'll keep the issue open for future subtasks. Thanks! > [graph] Add cobertura report and increase test coverage > --- > > Key: SANDBOX-380 > URL: https://issues.apache.org/jira/browse/SANDBOX-380 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Marco Speranza >Priority: Minor > Attachments: SANDBOX-380_Add-Cobertura_plugin.patch > > > Increase the test coverage and add new test cases. > Each testcase should test: > 1) Null input graph > 2) a sparse graph > 3) a complete 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] [Commented] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198681#comment-13198681
]
Simone Tripodi commented on SANDBOX-379:
hola,
{quote}
So I thought creating a new test for DefaultBeanAccessor would be a good idea,
regarding separation of concerns. What do you think?
{quote}
so split per-functionalities, {{DefaultBeanAccessor}} would contain the biggest
amount of tests
{quote}
I really liked the idea to have a dedicated test for a bug. To be honest, I was
thinking about proposing that in my company But if you don't like it, I'll
move it depending on your comment to the above mentioned topic.
{quote}
it's not a matter of taste, sometimes (depending on the bug) I do the same in
projects that have already been released, not in an experiment. The bug is
known and fixed in a previous version of the component, references in comments
are fine but don't see the advantage of dedicated test in a new version.
alles gute!
> [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
> Attachments: SANDBOX-379.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] [Commented] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198666#comment-13198666
]
Simone Tripodi commented on SANDBOX-379:
Just terminated to have a look at the patch, good, few observations before
applying it:
* {{BeanAccessorTestCase}} has only 1 test method that can be included in
{{BeanUtilsTest}}; the {{describes}} is {{protected}} (and there's no reason
why), it can be {{private final}}.
* Same thing for {{Jira157TestCase}}, test methods can be moved in the
{{BeanUtilsTest}} class; methods name have to be renamed stripping the
{{testIssue_BEANUTILS_157_BeanUtils}} prefix;
* {{AccessibleObjectsRegistry#getMethodsRegistry()}} can be referenced
statically in {{PropertyDescriptorsRegistry}};
* {{PropertyDescriptorsRegistry#makeMethodsAccessible}} returns the same
{{PropertyDescriptor}} input instance, there's no reason that method has a
return statement, signature can be changed to {{void}}.
Please modify the patch so I can apply it
> [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
> Attachments: SANDBOX-379.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] [Commented] (SANDBOX-377) [BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197648#comment-13197648
]
Simone Tripodi commented on SANDBOX-377:
{quote}
Why are they not good?
{quote}
because they are non-javadoc Eclipse-related only, and not everybody uses
Eclipse.
{quote}
My eclipse IDE wasn't able to retrieve the correct JavaDoc for methods with
that sort of comment. So do we just add no JavaDoc to implementation classes?
Or do we duplicate the JavaDoc from the interface? Or is something wrong with
eclipse?
{quote}
Internal javadoc won't anyway exposed, so {{{@inheritDoc}}} is fine.
> [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] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197195#comment-13197195
]
Simone Tripodi commented on SANDBOX-348:
Hi Thomas,
welcome in the graph brotherhood!!! ;)
Indeed, Boruvka is the less performant algorithm for the MST search, the reason
to keep it is that commons-graph aims to be a graph-pedia reference
implementation, so users are free to use the algorithm they prefer - I cannot
immagine why they would prefer Boruvka instead of Kruskal, but maybe there are
conditions under which it could work.
That means that, if you are interested on graph/have any proposal, please feel
free to fill an issue and provide an impl! Have a look also to current open
issues/task and, if you are using eclipse, there are some type inference errors
detected that need to be fixed ;)
As a side note: do you mind sharing the benchmarks you wrote on MST algos?
Many thanks in advance,
-Simo
> 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] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196836#comment-13196836
]
Simone Tripodi commented on SANDBOX-348:
I tracked the progress on SANDBOX-375, thanks for the patch!
> 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
>
>
> 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] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196827#comment-13196827
]
Simone Tripodi commented on SANDBOX-348:
maybe - even if related to the Boruvka's algorithm - that's the wrong location
:P
I 'll fill a new issue just to track the type of patch we are applying ;)
> 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
>
>
> 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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195446#comment-13195446 ] Simone Tripodi commented on SANDBOX-362: Hi Benedikt, great. Since classes will increase in therms of number, it would be better for, future contributions , to open subtasks and attach there patches, otherwise it is confusing to keept track which patches have been applied and which not. Thanks for your contributions! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Assignee: Simone Tripodi > Attachments: ArgumentTest.zip, SANDBOX-362-BeanUtilsTest.txt, > SANDBOX-362-ConstructorTestCase.txt, > SANDBOX-362-RefactoringOfArgumentTest.txt, > SANDBOX-362-RefactoringOfAssertionsTest.txt, SANDBOX-362-TypeUtilsTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194841#comment-13194841 ] Simone Tripodi commented on SANDBOX-362: Hi Benedikt, I think that redundancies are not evil but in that case they are not very helpful because they don't change the test coverage result. BeanUtils APIs tests purpose should be: * make sure null Class is not accepted * make sure null Object is not accepted * accepts a Class * accepts a Bean nothing more, unless we decide to add more public methods. > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, SANDBOX-362-BeanUtilsTest.txt, > SANDBOX-362-RefactoringOfArgumentTest.txt, > SANDBOX-362-RefactoringOfAssertionsTest.txt, SANDBOX-362-TypeUtilsTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194591#comment-13194591 ] Simone Tripodi commented on SANDBOX-362: very good patch Benedict, it has been successfully applied, see [r1236622|https://svn.apache.org/viewvc?view=revision&revision=1236622] thanks! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt, > SANDBOX-362-RefactoringOfAssertionsTest.txt, SANDBOX-362-TypeUtilsTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192999#comment-13192999
]
Simone Tripodi commented on SANDBOX-355:
Hi Doc,
that looks indeed a lot better, patch applied, thanks! ;) do {{svn up}}!
> Provide Flow algorithms
> ---
>
> Key: SANDBOX-355
> URL: https://issues.apache.org/jira/browse/SANDBOX-355
> Project: Commons Sandbox
> Issue Type: New Feature
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-355_FixBugInFordFulkerson.patch,
> SANDBOX-355_FordFulkersonImplementationAndTest.patch
>
>
> right now the {{org.apache.commons.graph.flow}} package contains an empty
> implementation of
> [Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
> algorithm, that needs to be filled.
> Other algorithms that work on resolving Flow-related problems, are welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192510#comment-13192510 ] Simone Tripodi commented on SANDBOX-362: thanks again for your contribution!!! patch has been successfully applied, see [r1235494|https://svn.apache.org/viewvc?view=revision&revision=1235494] looking forward to the next! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-TypeUtilsTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192501#comment-13192501 ] Simone Tripodi commented on SANDBOX-362: hey, I usually run tests before committing! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt, SANDBOX-362-TypeUtilsTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192127#comment-13192127
]
Simone Tripodi commented on SANDBOX-355:
Hi Claudio,
your patch has been applied, see [r1235238|], thanks!!!
Just as a side notes:
* I simplified the {{FlowNetworkHandler}} implementation, extending the
{{BaseGraphVisitHandler}} that already contains basic {{GraphVisitHandler}}
methods implementation that match with the actual needs.
* I think we could extract an interface from {{PredecessorsList}} and move the
implementation in the {{{model}} sub-package... WDYT?
I will let the issue open for future Flow-related algorithms patches.
Thanks for your hard work!
> Provide Flow algorithms
> ---
>
> Key: SANDBOX-355
> URL: https://issues.apache.org/jira/browse/SANDBOX-355
> Project: Commons Sandbox
> Issue Type: New Feature
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-355_FordFulkersonImplementationAndTest.patch
>
>
> right now the {{org.apache.commons.graph.flow}} package contains an empty
> implementation of
> [Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
> algorithm, that needs to be filled.
> Other algorithms that work on resolving Flow-related problems, are welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191513#comment-13191513 ] Simone Tripodi commented on SANDBOX-362: Terrific :) I have already applied your patch, see [r1235012|https://svn.apache.org/viewvc?view=revision&revision=1235012], thanks for contributing!!! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191462#comment-13191462
]
Simone Tripodi commented on FUNCTOR-10:
---
nice to hear the trick worked! The nicer thing is IMHO that names are still
valid Java identifier parts, but not all IDEs are good on recognizing them :P
Standard Eclipse, for example, doesn't resolve the Guice shaded internals,
while Sonatype's MavenIDE (an Eclipse mod) does.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191119#comment-13191119
]
Simone Tripodi commented on FUNCTOR-10:
---
We could shade the {{Validate}} class by renaming it in a way some IDEs (i.e.
Eclipse) is not able to resolve; Google Guice's folks use to do it by shading
the classes with {{$}} as first class name char, it would look like:
{{org.apache.commons.lang.$Validate}}
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-363) Check if value is of the correct type in Argument.argument( Class type, V value )
[
https://issues.apache.org/jira/browse/SANDBOX-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190482#comment-13190482
]
Simone Tripodi commented on SANDBOX-363:
thanks for your patch, I have few observations (and some work for you :P)
before applying it:
* {{type.isAssignableFrom(value.getClass()}} check is too silly indeed; have a
look at {{TypeUtils#isAssignmentCompatible(Class, Class)}} that
* {{checkNoneIsNull}} is a little too dense, it is better separating concerns:
array == null is a different check that a specific element is == null, moreover
it would be more helpful if they print the index in which the first null...
better if you take a look at Google Guava
[Preconditions|http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/base/Preconditions.html]
to see best practices on how manage arrays ;)
* do test methods marked with {{@Test}} really need the {{test}} prefix? isn't
it already explicit that it is a test method? doesn't sound it too redundant? :)
* it would be better if you can provide patches with the original code format,
without trailing spaces and spaces on empty lines, if you use Eclipse you can
download the
[codestyle|http://maven.apache.org/developers/maven-eclipse-codestyle.xml]
> 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
>Priority: Minor
> Attachments: SANDBOX-363.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] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190075#comment-13190075 ] Simone Tripodi commented on SANDBOX-362: Your contribution has been applied Benedikt, thanks a lot! see [r1234115|https://svn.apache.org/viewvc?view=revision&revision=1234115] I have to ask you anyway the favor of, for future contributions, read and follow the [On Contributing Patches|http://commons.apache.org/patches.html] guide, widely adopted in commons. For that case I applied the contribution since it is an addition class, but when modifying the original source code, the patch fits better because shows what has been modified. Dankeshön!!! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * 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] [Commented] (SANDBOX-360) Rename Converter to Transformer
[
https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189894#comment-13189894
]
Simone Tripodi commented on SANDBOX-360:
I agree and like it, I was using the {{Converter}} keyword just because in the
old API was named in that way :P
Just the time to leave the office and once get back home, will be done :)
Thanks!
> 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
>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] [Commented] (SANDBOX-359) Move License Agreement to file top
[ https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189893#comment-13189893 ] Simone Tripodi commented on SANDBOX-359: which convention? the code follows the Maven code style format (see checkstyle configuration) wich allows the license header in the place that is already :) > 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 >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] [Commented] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189681#comment-13189681
]
Simone Tripodi commented on SANDBOX-358:
Ciao Claudio!
go ahead on changing all method signatures in {{GraphVisitHandler}} from
{{void}} to {{boolean}}, this is the cleaner solution I can see ATM.
Thanks in advance!!!
> 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
>Priority: Minor
> Labels: graph, visit, visithandler
> 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] [Commented] (COMMONSSITE-65) Provide unified page layout for all commons projects
[ https://issues.apache.org/jira/browse/COMMONSSITE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187142#comment-13187142 ] Simone Tripodi commented on COMMONSSITE-65: --- +1 Gregory, it would be enough putting all of them in the parent > Provide unified page layout for all commons projects > > > Key: COMMONSSITE-65 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-65 > Project: Commons All > Issue Type: Improvement > Components: Site >Reporter: Benedikt Ritter > > Commons project pages use slightly different page layouts. This is bad, > because users to have to study every page layout all over again, when > browsing through the different projects. > To prevent this, all commons projects should use the same layout and sidebar > setup (as far as possible). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-356) Generic weight types and algorithms implementations based on wighted graphes
[
https://issues.apache.org/jira/browse/SANDBOX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184408#comment-13184408
]
Simone Tripodi commented on SANDBOX-356:
Ciao Claudio,
latest patch has been successfully applied, see
[r1230260|https://svn.apache.org/viewvc?view=revision&revision=1230260].
I'll let the issue open waiting for your confirmation that all weight-related
algorithms have been updated with monoid as weight.
Thanks for your efforts!
> 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] [Commented] (SANDBOX-356) Generic weight types and updated shortest path implementations
[
https://issues.apache.org/jira/browse/SANDBOX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183594#comment-13183594
]
Simone Tripodi commented on SANDBOX-356:
cool, patch has been applied, see
[r1229746|https://svn.apache.org/viewvc?view=revision&revision=1229746], thanks
for contributing!
As a side note: take the good practice of prefixing the patches with the issue
number, i.e. {{SANDBOX-356_GenericWeightTypeAlsoForAStar.patch}} that would
simplify the patch management in commons (people usually maintain more than one
component at once) ;)
I'll keep the issue open waiting for Spanning Trees algorithms :) TIA!
> Generic weight types and updated shortest path implementations
> --
>
> Key: SANDBOX-356
> URL: https://issues.apache.org/jira/browse/SANDBOX-356
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
> Labels: generic, graph, shortestpath, type, weight
> Attachments: GenericWeightTypeAlsoForAStar.patch,
> GenericWeightTypesAndUpdatedShortestPathImplementations.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] [Commented] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183544#comment-13183544
]
Simone Tripodi commented on CHAIN-58:
-
this is something evaluable, since {{C extends Map}} would allow
extensions - let's fix generics first, then evaluate a patch to move APIs
forward.
> 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
> Fix For: 2.0
>
> Attachments: 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] [Commented] (CHAIN-63) Replace Context with Map
[
https://issues.apache.org/jira/browse/CHAIN-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183403#comment-13183403
]
Simone Tripodi commented on CHAIN-63:
-
Don't worry, that is because you maybe misses some discussions in the dev@ ML -
we agreed on keeping the {{Context}} because users can still customize the
context behavior, (put|get) mrthods would not be enough for all situations.
Development is still on patch, there is a compilation issue discussed in
CHAIN-58, if you're interested on providing help you can apply the latest patch
locally and try to fix the error - remember that to be involved every kind of
contribution is always much more than welcome! :)
> Replace Context with Map
> --
>
> Key: CHAIN-63
> URL: https://issues.apache.org/jira/browse/CHAIN-63
> Project: Commons Chain
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Ales Dolecek
>Assignee: Simone Tripodi
>Priority: Minor
> Fix For: 2.0
>
>
> Hello,
> I always wandered why you *force* chain users to use the Context interface
> which adds nothing over Map. I would understand that if the Context would not
> inherit from map and only required
> Object put(String, Object)
> Object get(String)
> But since Context itself IS Map then you gain nothing while disallowing use
> of Map implementations. I know that sou suggest that Context shall implement
> "Attribute-Property Transparency" but it is only recomendation and is not
> forced by commons chains anyway.
> And if you define execute like
> Object execute(Map context)
> it can still accept Context instances and all its subclasses.
> The downside is that you would have to give up the retrieve method introduced
> to Context. And BTW the Context imposes hard restriction see my other bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-62) Use of thread context ClassLoader under OSGi
[
https://issues.apache.org/jira/browse/CHAIN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183348#comment-13183348
]
Simone Tripodi commented on CHAIN-62:
-
Great to see you contributing Ales! may I can ask you to provide please a patch
that includes a testcase that proves the correctness inside OSGi?
As a side note: code in the comment is not very human-friendly, do you mind of
taking care of formatting? You can use wiki-alike tags, press on the {{?}}
button help... TIA!
> Use of thread context ClassLoader under OSGi
>
>
> Key: CHAIN-62
> URL: https://issues.apache.org/jira/browse/CHAIN-62
> Project: Commons Chain
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: OSGi
>Reporter: Ales Dolecek
>Priority: Minor
> Attachments: CatalogFactory.patch
>
>
> The {{CatalogFactory#getInstance()}} is using thread context ClassLoader
> which gives undefined behavior under OSGi.
> This leads to problems with {{ConfigCatalogRule}} and especially
> {{LookupCommand}}.
> Two bundles wired to same commons chain may use different catalog factories
> when parsing commands from XML or looking up commands from catalog.
> I think that {{CatalogFactory#getClassLoader()}} might allow disabling use of
> thread context class loader - either
> a) detect that it is used inside OSGi framework, or
> b) provide static boolean flag to disable it
> Combination of both might be via use of bundle activator that would set the
> flag. The activator would be used only under OSGi acting as "auto-detection"
> and still some other bundle might revert to default if required.
> Ales
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-62) Use of thread context ClassLoader under OSGi
[
https://issues.apache.org/jira/browse/CHAIN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182397#comment-13182397
]
Simone Tripodi commented on CHAIN-62:
-
Good catch Ales,
what about if we provide 2 methods:
* {{CatalogFactory#getInstance(ClassLoader)}}
* {{CatalogFactory#getInstance()}} which uses
{{CatalogFactory.class.getClassLoader}}?
would it be helpful to be used inside an OSGi container?
> Use of thread context ClassLoader under OSGi
>
>
> Key: CHAIN-62
> URL: https://issues.apache.org/jira/browse/CHAIN-62
> Project: Commons Chain
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: OSGi
>Reporter: Ales Dolecek
>Priority: Minor
>
> The CatalogFactory#getInstance() is using thread context ClassLoader which
> gives undefined behavior under OSGi.
> This leads to problems with ConfigCatalogRule and especislly LookupCommand.
> Two bundles wired to same commons chain may use different catalog factories
> when parsing commands from XML or looking up commands from catalog.
> I think that CatalogFactory#getClassLoader() might allow disabling use of
> thread context class loader - either
> a) detect that it is used inside OSGi framework, or
> b) provide static boolean flag to disable it
> Combination of both might be via use of bundle activator that would set the
> flag. The activator would be used only under OSGi acting as "auto-detection"
> and still some other bundle might revert to default if required.
> Ales
--
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
