[jira] [Commented] (DIGESTER-164) RulesBase performance optimization
[ https://issues.apache.org/jira/browse/DIGESTER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (DIGESTER-164) RulesBase performance optimization
[
https://issues.apache.org/jira/browse/DIGESTER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (CSV-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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=revisionrevision=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] (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-tabpanelfocusedCommentId=13230124#comment-13230124 ] Simone Tripodi commented on SANDBOX-403: patch applied, see [r1300952|http://svn.apache.org/viewvc?rev=1300952view=rev], thanks. please don't reorganize imports using wildcards, nobody uses it here, TIA. [BeanUtils2] Refactor Unit tests for better readability --- Key: SANDBOX-403 URL: https://issues.apache.org/jira/browse/SANDBOX-403 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Reporter: Benedikt Ritter 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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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}
root
container
header
authors
authorAuthor 1/author
/authors
/header
/container
/root
{code}
while rules are configured like (despite the class renaming)
{code}
digester-rules
object-create-rule classname=org.apache.commons.digester3.binder.Entity
pattern=container/
!-- author --
call-method-rule methodname=setAuthor paramcount=1
pattern=container/header/authors/author/
/digester-rules
{code}
so we have two options:
* rules pattern are wrong;
* sample is wrong.
I am removing the {{root}} 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-tabpanelfocusedCommentId=13230201#comment-13230201
]
Simone Tripodi commented on DIGESTER-163:
-
Indeed, restructuring the XML to:
{code}
container
header
authors
authorAuthor 1/author
/authors
/header
/container
{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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13230593#comment-13230593
]
Simone Tripodi commented on DIGESTER-163:
-
I just committed [r1301217|http://svn.apache.org/viewvc?rev=1301217view=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 {{MonoidW}}).
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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (SANDBOX-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
WOorg.apache.commons.graph.shortestpath.AllVertexPairsShortestPathorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/KruskalTestCase.java:[71,77]
type parameters of
WOorg.apache.commons.graph.SpanningTreeorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/shortestpath/AStarTestCase.java:[98,65]
type parameters of
WOorg.apache.commons.graph.shortestpath.HeuristicBuilderorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,java.lang.Double,org.apache.commons.graph.model.UndirectedMutableWeightedGraphorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/ReverseDeleteTestCase.java:[53,67]
type parameters of
WOorg.apache.commons.graph.SpanningTreeorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/PrimTestCase.java:[71,77]
type parameters of
WOorg.apache.commons.graph.SpanningTreeorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/shortestpath/DijkstraTestCase.java:[69,68]
type parameters of
WOorg.apache.commons.graph.WeightedPathorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[ERROR]
/private/tmp/graph/src/test/java/org/apache/commons/graph/spanning/BoruvkaTestCase.java:[71,77]
type parameters of
WOorg.apache.commons.graph.SpanningTreeorg.apache.commons.graph.model.BaseLabeledVertex,org.apache.commons.graph.model.BaseLabeledWeightedEdgejava.lang.Double,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.Monoidjava.lang.Double,java.util.Comparatorjava.lang.Double
[INFO] 7 errors
[INFO] -
[INFO]
[INFO] BUILD FAILURE
[INFO]
[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-tabpanelfocusedCommentId=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 KosarajuSharirAlgorithmV, E, G( graph
).applyingKosarajuSharir( source );
+return new CheriyanMehlhornGabowAlgorithmV, E, G( graph
).applyingCheriyanMehlhornGabow();
+return new TarjanAlgorithmV, E, G( 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=1297872view=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-409) Drop Vertex/Edge marker interfaces
[
https://issues.apache.org/jira/browse/SANDBOX-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-404) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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) Simplify weight model
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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();
CommandString, Object, ProfileContext command = new ProfileCheck();
try {
command.execute(context);
}
catch (Exception e) {
throw new RuntimeException(e);
}
{code}
The user of chain has to explicitly catch Exception. If the desire was
to catch the most base error and force the user to deal with it, why
aren't we using Throwable? Anyways, this design leads to less than
elegant code and since we will be breaking the API in v2, I would like
to suggest a different approach.
I suggest that Command and Chain should throw a custom exception class
called ChainException that inherits from RuntimeException. And in the
CommandBase, ChainBase we wrap the catch of Exception in this runtime
exception. Moreover, we would attach to ChainException some optional
debug information about the Context invoked when the exception was
encountered.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-402) Add GraphML importer
[ https://issues.apache.org/jira/browse/SANDBOX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-402) Add GraphML importer
[
https://issues.apache.org/jira/browse/SANDBOX-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-404) merge Zero and Semigroup in the Monoid
[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (FUNCTOR-1) [functor] New components: summarize and aggregate
[
https://issues.apache.org/jira/browse/FUNCTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212981#comment-13212981
]
Simone Tripodi commented on SANDBOX-396:
patch looks good, anyway:
{quote}
+@SuppressWarnings( unchecked )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessorB cloneAccessor = new DefaultBeanAccessorB(
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-394) Check arguments
[
https://issues.apache.org/jira/browse/SANDBOX-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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 MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Object to
SpanningTreeBaseLabeledVertex,BaseLabeledWeightedEdgeDouble,Double
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (SANDBOX-385) Provide Edmonds-Karp algorithm
[ https://issues.apache.org/jira/browse/SANDBOX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-383) Add test for Connectivity
[
https://issues.apache.org/jira/browse/SANDBOX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 :
V,E,Gorg.apache.commons.graph.connectivity.ConnectivityBuilderV,E,G
{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-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 : V,E,Gorg.apache.commons.graph.coloring.ColorsBuilderV,E,G
[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 : V,E,Gorg.apache.commons.graph.coloring.ColorsBuilderV,E,G
[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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=13199238#comment-13199238 ] Simone Tripodi commented on SANDBOX-380: good! I applied the patch (see [r1239853|http://svn.apache.org/viewvc?rev=1239853view=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-382) Add new test for coloring
[
https://issues.apache.org/jira/browse/SANDBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-377) [BeanUtils2] Implement invoke(Exact)Method(...) on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=13191513#comment-13191513 ] Simone Tripodi commented on SANDBOX-362: Terrific :) I have already applied your patch, see [r1235012|https://svn.apache.org/viewvc?view=revisionrevision=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] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (SANDBOX-359) Move License Agreement to file top
[ https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-360) Rename ConverterT, S to TransformerT, S
[
https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ConverterT, S to TransformerT, S
---
Key: SANDBOX-360
URL: https://issues.apache.org/jira/browse/SANDBOX-360
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Priority: Minor
Since org.apache.commons.beanutils2.Converter is essentially a from of a
Transformer (see org.apache.commons.collections.Transformer), it should be
named this way. The same applies for
org.apache.commons.beanutils2.converters.AbstractConverterT,S.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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=revisionrevision=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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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=revisionrevision=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] (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-tabpanelfocusedCommentId=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-63) Replace Context with MapString, ? extends Object
[
https://issues.apache.org/jira/browse/CHAIN-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 MapString, ? extends Object
--
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(MapString, ? extends Object 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-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-tabpanelfocusedCommentId=13183544#comment-13183544
]
Simone Tripodi commented on CHAIN-58:
-
this is something evaluable, since {{C extends MapK, V}} 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 MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=13183594#comment-13183594
]
Simone Tripodi commented on SANDBOX-356:
cool, patch has been applied, see
[r1229746|https://svn.apache.org/viewvc?view=revisionrevision=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-62) Use of thread context ClassLoader under OSGi
[
https://issues.apache.org/jira/browse/CHAIN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (OGNL-43) OGNL Language Guide (Chinese Edition)
[ https://issues.apache.org/jira/browse/OGNL-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13180347#comment-13180347 ] Simone Tripodi commented on OGNL-43: Ni-hao Li, I would really like to put Chinese translation but I need to rearrange the documentation in xdoc - current documentation is exactly the old OpenSymphony one, with the difference that pieces have been rearranged in 3 pages instead of having multiple pages. Anyway, due to my lack in CHinese language, I am not really able to rearrange stuff :( Can you provide us a little more help, please? TIA, -Simo OGNL Language Guide (Chinese Edition) - Key: OGNL-43 URL: https://issues.apache.org/jira/browse/OGNL-43 Project: Commons OGNL Issue Type: Improvement Reporter: Li Ying Priority: Minor Labels: documentation, patch Attachments: OGNL-LanguageGuide-ch-20101115.zip, patch_for_site_xml.txt Hi all: My name is Li Ying. I am a newbie of this community. About the OGNL project. I have noticed that it is donated to Apache, and now it is a sub-project of Apache Commons. Last year, I translated the [OGNL Language Guide] document into Chinese. However, It is based on the original document: http://www.opensymphony.com/ognl/html/LanguageGuide/index.html but not the current Apache Commons OGNL document: http://commons.apache.org/ognl/language-guide.html I like to send this Chinese Edition to you, and if it can be put on the project site, I think it will be a little help to the OGNL users who speak Chinese. Thanks very much. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-346) DotExporter only exports weights that extend Number
[ https://issues.apache.org/jira/browse/SANDBOX-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173032#comment-13173032 ] Simone Tripodi commented on SANDBOX-346: having the Dot exporter conform to Dot specification is on top of requirements :) your patch has been applied, thanks for contributing! DotExporter only exports weights that extend Number --- Key: SANDBOX-346 URL: https://issues.apache.org/jira/browse/SANDBOX-346 Project: Commons Sandbox Issue Type: Improvement Components: Graph Reporter: Claudio Squarcella Priority: Minor Labels: dot, dotexporter, double, graph, weight Attachments: DotExporterOnlyExportsWeightsExtendingNumber.patch Hi, I propose a tiny patch for the DotExporter in order to print weight as an edge attribute only when the actual weight extends Number, using the method getDouble(). This is to be fully compliant with the DOT language specification on the attribute weight (see http://www.graphviz.org/content/attrs#aweight). Hope this helps, Claudio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-3) Import existing issues from old bug tracker
[ https://issues.apache.org/jira/browse/OGNL-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171877#comment-13171877 ] Simone Tripodi commented on OGNL-3: --- great, thanks for taking care of it Lukasz! Import existing issues from old bug tracker --- Key: OGNL-3 URL: https://issues.apache.org/jira/browse/OGNL-3 Project: OGNL Issue Type: Task Reporter: Simone Tripodi Assignee: Lukasz Lenart All old existing issues recorded on previous bug tracker have to be imported to ASF JIRA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-tabpanelfocusedCommentId=13170816#comment-13170816
]
Simone Tripodi commented on DIGESTER-158:
-
yes, definitively :)
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
