[jira] [Created] (FUNCTOR-13) EachElement should be able to work on any Iterable
EachElement should be able to work on any Iterable -- Key: FUNCTOR-13 URL: https://issues.apache.org/jira/browse/FUNCTOR-13 Project: Commons Functor Issue Type: Improvement Reporter: Emmanuel Bourg from 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-12) improve test coverage
[
https://issues.apache.org/jira/browse/FUNCTOR-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190289#comment-13190289
]
Matt Benson commented on FUNCTOR-12:
Also most {{equals}}/{{hashCode}} methods are not tested.
> improve test coverage
> -
>
> Key: FUNCTOR-12
> URL: https://issues.apache.org/jira/browse/FUNCTOR-12
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>
> Specifically the composite package contains untested classes, 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] [Created] (FUNCTOR-12) improve test coverage
improve test coverage - Key: FUNCTOR-12 URL: https://issues.apache.org/jira/browse/FUNCTOR-12 Project: Commons Functor Issue Type: Improvement Reporter: Emmanuel Bourg Specifically the composite package contains untested classes, 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] [Created] (FUNCTOR-11) Reduce API clutter by removing or reducing scope of FunctorType.equals(FunctorType) methods
Reduce API clutter by removing or reducing scope of FunctorType.equals(FunctorType) methods --- Key: FUNCTOR-11 URL: https://issues.apache.org/jira/browse/FUNCTOR-11 Project: Commons Functor Issue Type: Improvement Reporter: Emmanuel Bourg >From 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] [Updated] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated FUNCTOR-10:
---
Description:
for better alignment with JSE, {{[lang]}}, etc. Currently
{{IllegalArgumentException}} is thrown.
Per http://markmail.org/message/ythw55yad5lrvqrj
was:for better alignment with JSE, {{[lang]}}, etc. Currently
{{IllegalArgumentException}} is thrown.
> 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
>
> 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] [Created] (FUNCTOR-10) throw NullPointerException for illegal null values
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
for better alignment with JSE, {{[lang]}}, etc. Currently
{{IllegalArgumentException}} is thrown.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189906#comment-13189906
]
Claudio Squarcella edited comment on SANDBOX-358 at 1/21/12 1:37 AM:
-
Hi,
so I actually changed signatures for methods in {{GraphVisitHandler}}:
* {{discoverVertex}} and {{discoverEdge}} now tell the algorithm if the
corresponding {{Vertex}} and {{Edge}} should be expanded (i.e. if their
neighbors should be added to the visit queue);
* {{finishVertex}} and {{finishEdge}} tell if the algorithm can be ended
prematurely (because the search is complete, e.g. the target element was found).
All tests still work. I hope you guys like this one :)
Claudio
was (Author: claudio.squarcella):
Hi,
so I actually changed signatures for methods in {{GraphVisitHandler}}:
* {{discoverVertex}} and {{discoverEdge}} now tell the algorithm if the
corresponding {{Vertex}} and {{Edge}} should be expanded (i.e. if their
neighbors should be added to the visit queue);
* {{finishVertex}} and {{finishEdge}} tell if the algorithm can be ended
prematurely (because the search is complete, e.g. before the target element was
found).
All tests still work. I hope you guys like this one :)
Claudio
> Early return/termination for graph visit
>
>
> Key: SANDBOX-358
> URL: https://issues.apache.org/jira/browse/SANDBOX-358
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
>Priority: Minor
> Labels: graph, visit, visithandler
> Attachments: EarlyTerminationAndSubgraphSkipForSearchAlgorithms.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Hello,
> the current implementations in the class {{Visit}} (package
> {{org.apache.commons.graph.visit}}) do not include the possibility to stop
> the search prematurely. That would be more natural (and faster) for many
> kinds of search, e.g. when looking for the first occurrence of a specific
> pattern (vertex, path with certain features, etc).
> The easiest solution: changing all method signatures in {{GraphVisitHandler}}
> from {{void}} to {{boolean}}, forcing the handler to answer the question:
> _should I continue?_
> I understand semantics get a bit entangled (well, not with an appropriate
> documentation!), so I am open to more verbose options: e.g. a method
> {{isSearchComplete}} to call after every step... but that would only be more
> verbose, wouldn't it?
> Waiting for feedback and ready to patch :-)
> Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JXPATH-139) Wrong xpath expression passed to extension function does not throw JXPathNotFoundException
[
https://issues.apache.org/jira/browse/JXPATH-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-139.
Resolution: Invalid
Hello, and sorry for the long wait. I have looked at this before, but have
finally realized that this issue is invalid. You must bear in mind that this
is xpath, so when you pass a path to a function, you are really passing the set
of nodes that matches that query, in this case "those nodes relative to the
current path (root) whose qname matches 'valueXXX'." This empty nodeset is
then converted to a string, yielding the value "". Unfortunately this does
mean that your jxpath expressions will not automatically break when
refactorings change property names.
> Wrong xpath expression passed to extension function does not throw
> JXPathNotFoundException
> --
>
> Key: JXPATH-139
> URL: https://issues.apache.org/jira/browse/JXPATH-139
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Petras
>
> If xpath expression, which do not map to bean properties, is passed to
> extension function, JXPathNotFoundException is not thrown. It seems
> inconsistent behaviour and it is difficult to test these expressions if they
> do not fail for example after code refactoring.
> Here is a test case:
> {code}
> // Extension function
> public static class StringFunctions {
> public static String left(String param, int len) {
> System.out.println("Received: '" + param + "'");
> if(param == null) return null;
> return param.substring(0, Math.min(len, param.length()));
> }
> }
> {code}
> {code}
> // Value object to use
> public class VO {
> String value = null;
> public String getValue() { return value; }
> public void setValue(String value) { this.value = value; }
> }
> {code}
> {code}
> @Test
> public void testLeftFunctionWrongPath() {
> VO vo = new VO();
> vo.setValue("1234567890");
> JXPathContext ctx = JXPathContext.newContext(vo);
> ctx.setFunctions(new ClassFunctions(StringFunctions.class, "util"));
>
> // OK, StringFunctions.left() receives "1234567890"
> path = "util:left(value, 5)";
> ctx.getValue(path);
>
> // JXPathNotFoundException is not thrown, StringFunctions.left()
> receives an empty string
> String wrongPath = "util:left(valueXXX, 5)";
> ctx.getValue(wrongPath);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-677) About package "transform"
[
https://issues.apache.org/jira/browse/MATH-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190111#comment-13190111
]
Sébastien Brisard commented on MATH-677:
In {{r1234136}}, added a new
{{RealTransformAbstractTest}} allowing for automatic testing of
{{RealTransformers}}, with various data sizes (not only powers of two and the
likes). This will ease testing procedures if we ever implement transforms for
other types of data sizes.
> About package "transform"
> -
>
> Key: MATH-677
> URL: https://issues.apache.org/jira/browse/MATH-677
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Sébastien Brisard
>Priority: Minor
> Labels: api-change
> Fix For: 3.0
>
>
> Classes in package "o.a.c.m.transform" might require some changes in order to
> conform to goals set for the next major release.
> Some observations:
> # Exceptions
> ## Should remove use of deprecated "MathRuntimeException"
> ## Should throw more specific "Math...Exception" instances instead of
> standard IAE
> # Interface "RealTransformer" (and implementations) contain non-conformant
> method names (e.g. "inversetransform" instead of "inverseTransform").
> {color:red}Fixed in {{r1208293}}.{color}
> # "FastFourierTransformer":
> ## Methods "mdfft" and "verifyDataSet" take an argument of type "Object" (to
> allow an argument with an unspecified number of dimensions)
> ## The "RootsOfUnity" helper class could be moved to the "complex" package
> ## For clarity, multidimensional transform should be moved to a class of its
> own (and I also wonder whether the "MultiDimensionalComplexMatrix" name is
> not misleading)
> # "FastFourierTransformer", "FastSineTranformer" and "FastCosineTranformer"
> define public methods "tranform2" and "inversetransform2" but they are not
> part of an interface. {color:red}As of {{r1213157}}, these methods have been
> removed, and replaced by factory methods {{create()}} and {{createUnitary()}}
> (FFT) or {{createOrthogonal()}} (FCT, FST).{color}
> # Code uses variables that start with an uppercase. {color:red}Fixed,
> together with various formatting issues.{color}
> # "FastHadamardTransformer" contains illegible developer documentation (see
> Javadoc for protected method "fht"). {color:red}Tried to improve things in
> {{r1208986}}, but things are still a bit obscure. Besides, the link provided
> is broken. Will look into that.{color}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-360) Rename Converter to Transformer
[ https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-360. Resolution: Fixed Assignee: Simone Tripodi Refactor successfully applied, thanks Benedikt and Matt for the hints! see [r1234122|https://svn.apache.org/viewvc?view=revision&revision=1234122] > Rename Converter to Transformer > --- > > Key: SANDBOX-360 > URL: https://issues.apache.org/jira/browse/SANDBOX-360 > Project: Commons Sandbox > Issue Type: Improvement > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Assignee: Simone Tripodi >Priority: Minor > > Since org.apache.commons.beanutils2.Converter is essentially a from of a > Transformer (see org.apache.commons.collections.Transformer), it should be > named this way. The same applies for > org.apache.commons.beanutils2.converters.AbstractConverter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190075#comment-13190075 ] Simone Tripodi commented on SANDBOX-362: Your contribution has been applied Benedikt, thanks a lot! see [r1234115|https://svn.apache.org/viewvc?view=revision&revision=1234115] I have to ask you anyway the favor of, for future contributions, read and follow the [On Contributing Patches|http://commons.apache.org/patches.html] guide, widely adopted in commons. For that case I applied the contribution since it is an addition class, but when modifying the original source code, the patch fits better because shows what has been modified. Dankeshön!!! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * TypeUtils -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-463) AbstractFileConfiguration.load(String filename) returns with current directory changed
[
https://issues.apache.org/jira/browse/CONFIGURATION-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-463.
Resolution: Fixed
Fix Version/s: 1.8
The Javadoc of the class and the load() methods was updated accordingly. Fixed
in revision 1234118.
> AbstractFileConfiguration.load(String filename) returns with current
> directory changed
> --
>
> Key: CONFIGURATION-463
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-463
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.6, 1.7
> Environment: Windows7, Linux (Fedora14)
>Reporter: James Garrison
> Fix For: 1.8
>
>
> {code:java}
> PropertiesConfiguration pc = new PropertiesConfiguration();
> ...
> for (String f : cl.getArgs())
> {
> pc.load(f);
> }
> {code}
> Invoked in directory /home/me/test with several relative paths, i.e.
> ./sub1/a.cfg ./sub2/b.cfg
> First file loads successfully. Upon return from the first invocation of
> pc.load(f), the current directory has been changed to the absolute path of
> the loaded file (/home/me/test/sub1). Thus, subsequent paths given as
> relative references to the original user.dir fail to be found.
> If this is the expected behavior, it should be documented.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-358.
Resolution: Fixed
Assignee: Simone Tripodi
thanks once again for your great contributions Claudio, your patch has been
successfully applied, see
[r1234109|https://svn.apache.org/viewvc?view=revision&revision=1234109]
> Early return/termination for graph visit
>
>
> Key: SANDBOX-358
> URL: https://issues.apache.org/jira/browse/SANDBOX-358
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
>Priority: Minor
> Labels: graph, visit, visithandler
> Attachments: EarlyTerminationAndSubgraphSkipForSearchAlgorithms.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Hello,
> the current implementations in the class {{Visit}} (package
> {{org.apache.commons.graph.visit}}) do not include the possibility to stop
> the search prematurely. That would be more natural (and faster) for many
> kinds of search, e.g. when looking for the first occurrence of a specific
> pattern (vertex, path with certain features, etc).
> The easiest solution: changing all method signatures in {{GraphVisitHandler}}
> from {{void}} to {{boolean}}, forcing the handler to answer the question:
> _should I continue?_
> I understand semantics get a bit entangled (well, not with an appropriate
> documentation!), so I am open to more verbose options: e.g. a method
> {{isSearchComplete}} to call after every step... but that would only be more
> verbose, wouldn't it?
> Waiting for feedback and ready to patch :-)
> Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-786) StringUtils equals() relies on undefined behavior
[
https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Trebbien updated LANG-786:
-
Attachment: equals.patch
Fix
This re-introduces StringUtils#equals(String, String) and changes
StringUtils#equals(CharSequence, CharSequence) to compare chars individually.
> StringUtils equals() relies on undefined behavior
> -
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
>Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the
> JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and
> hashCode methods. The result of comparing two objects that implement
> CharSequence is therefore, in general, undefined. Each object may be
> implemented by a different class, and there is no guarantee that each class
> will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from
> {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in
> R920543, the implementation still relied on calling
> CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as
> CharSequences, two objects represent equal sequences is when one object is an
> instance of {{javax.lang.model.element.Name}} and the other object is a
> String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-786) StringUtils equals() relies on undefined behavior
StringUtils equals() relies on undefined behavior
-
Key: LANG-786
URL: https://issues.apache.org/jira/browse/LANG-786
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0
Environment: java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Fedora 15 AMD64
Reporter: Daniel Trebbien
Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the
JavaDoc block has contained the following note:
{quote}
This interface does not refine the general contracts of the equals and hashCode
methods. The result of comparing two objects that implement CharSequence is
therefore, in general, undefined. Each object may be implemented by a different
class, and there is no guarantee that each class will be capable of testing its
instances for equality with those of the other.
{quote}
When the signature of the StringUtils equals() method was changed from
{{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in
R920543, the implementation still relied on calling CharSequence#equals(Object)
even though, in general, the result is undefined.
One example where {{equals(Object)}} returns {{false}} even though, as
CharSequences, two objects represent equal sequences is when one object is an
instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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] (VFS-307) VFS issues a lot of FTP commands when listing a directory
[ https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1319#comment-1319 ] Ibrahim Hasbini commented on VFS-307: - Hello Mario, I've been debugging an issue where folder creation was failing and found the method "FTPFile[] listFilesInDirectory(String relPath)" in FTPClientWrapper and this issue. It seems some FTP servers do not return an error code when the LIST command gets a path that contains space, but simply return an empty list of files and a success code. This causes solution 2 mentioned above to never fallback to "change directory + list", this later causes VFS to think that a folder does not exist while in reality it does (eventually causing an exception when we try to create that existing folder). Is it ok to always fallback to "change directory + list" when a path contains spaces? Thanks. > VFS issues a lot of FTP commands when listing a directory > - > > Key: VFS-307 > URL: https://issues.apache.org/jira/browse/VFS-307 > Project: Commons VFS > Issue Type: Improvement >Reporter: Mario Ivankovits > Fix For: Nightly Builds > > > Hello Mario, > > We at JetBrains are implementing support for (S)FTP sync in our IDEs using > Commons VFS. When looking at the performance, we noticed that FTP provider is > somewhat not perfect: see my discussion with Ralph. > > So the question is: why FtpClientWrapper changes the current directory to > issue 'LIST' command and restoring it back afterwards instead of issuing > single 'LIST '? > > Subversion says it was you who introduced this behavior far back in 2008. > Hope you remember those times and reason why you did this. > > Thanks a lot in advance, > > Kirill Safonov > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated SANDBOX-362: Attachment: ArgumentTest.zip I've attached a jUnit Test for Argument. Please let me know, what you think about it. I've not written test methods for getType() and getValue(), since those are backed up by the other 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 > > > 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] [Created] (SANDBOX-362) Create basic unit tests for all classes
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 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] [Resolved] (JXPATH-154) Resetting the default namespace causes a serious endless loop when requesting .asPath() on a node.
[
https://issues.apache.org/jira/browse/JXPATH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-154.
Resolution: Fixed
Fix Version/s: 1.4
> Resetting the default namespace causes a serious endless loop when requesting
> .asPath() on a node.
> --
>
> Key: JXPATH-154
> URL: https://issues.apache.org/jira/browse/JXPATH-154
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: jxpath eclipse plugin from orbit
>Reporter: Hugo de Almeida Cocharro
> Fix For: 1.4
>
>
> sample smaller case:
> {code}
> <...>
>
> a
>
>
>
> {code}
> when requesting .asPath() on the 'test' node, it loops in
> org.apache.commons.jxpath.ri.NamespaceResolver.getPrefix(NodePointer,
> String),
> and if it didn't loop it would create a wrong xpath '//b:fo/null:test'
> DOMNodePointer.asPath().
> So I think that the fix should be in
> org.apache.commons.jxpath.ri.model.dom.DOMNodePointer.asPath()
> {code}
>
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null) {
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
> should become
> {code}
> ...
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null || nsURI.length() == 0) { // check for
> empty string which means that the node doesn't have a namespace.
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JXPATH-154) Resetting the default namespace causes a serious endless loop when requesting .asPath() on a node.
[
https://issues.apache.org/jira/browse/JXPATH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189959#comment-13189959
]
Matt Benson commented on JXPATH-154:
It is a convention within JXPath code that the empty namespace be represented
as a Java {{null}}. Rather than check for {{""}} at the point you identified,
I have elected to modify DOMNodePointer to translate {{""}} to {{null}} when
returning its result. In this manner JXPath's DOM handling will function in
the same manner as its JDOM handling, and any other callers of the method will
be fixed as well.
Committed revision 1234036.
> Resetting the default namespace causes a serious endless loop when requesting
> .asPath() on a node.
> --
>
> Key: JXPATH-154
> URL: https://issues.apache.org/jira/browse/JXPATH-154
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: jxpath eclipse plugin from orbit
>Reporter: Hugo de Almeida Cocharro
>
> sample smaller case:
> {code}
> <...>
>
> a
>
>
>
> {code}
> when requesting .asPath() on the 'test' node, it loops in
> org.apache.commons.jxpath.ri.NamespaceResolver.getPrefix(NodePointer,
> String),
> and if it didn't loop it would create a wrong xpath '//b:fo/null:test'
> DOMNodePointer.asPath().
> So I think that the fix should be in
> org.apache.commons.jxpath.ri.model.dom.DOMNodePointer.asPath()
> {code}
>
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null) {
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
> should become
> {code}
> ...
> String ln = DOMNodePointer.getLocalName(node);
> String nsURI = getNamespaceURI();
> if (nsURI == null || nsURI.length() == 0) { // check for
> empty string which means that the node doesn't have a namespace.
> buffer.append(ln);
> buffer.append('[');
>
> buffer.append(getRelativePositionByName()).append(']');
> }
> else {
> String prefix =
> getNamespaceResolver().getPrefix(nsURI);
> if (prefix != null) {
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-171) createArchiveInputStream detects text files less than 100 bytes as tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Lowe updated COMPRESS-171: - Fix Version/s: (was: 1.1) 1.4 > createArchiveInputStream detects text files less than 100 bytes as tar > archives > --- > > Key: COMPRESS-171 > URL: https://issues.apache.org/jira/browse/COMPRESS-171 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.2, 1.3 > Environment: Windows 7/JDK 1.6 >Reporter: Daniel Lowe > Labels: detection, tar > Fix For: 1.4 > > Original Estimate: 1h > Remaining Estimate: 1h > > The fix for COMPRESS-117 which modified > ArchiveStreamFactory().createArchiveInputStream(inputstream) results in short > text files (empirically seems to be those <= 100 bytes) being detected as tar > archives which obviously is not desirable if one wants to know whether or not > the files are archives. > I'm not an expert on compressed archives but perhaps the heuristic that if a > stream is interpretable as a tar file without an exception being thrown > should only be applied on archives greater than 100 bytes? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-171) createArchiveInputStream detects text files less than 100 bytes as tar archives
createArchiveInputStream detects text files less than 100 bytes as tar archives --- Key: COMPRESS-171 URL: https://issues.apache.org/jira/browse/COMPRESS-171 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.3, 1.2 Environment: Windows 7/JDK 1.6 Reporter: Daniel Lowe Fix For: 1.1 The fix for COMPRESS-117 which modified ArchiveStreamFactory().createArchiveInputStream(inputstream) results in short text files (empirically seems to be those <= 100 bytes) being detected as tar archives which obviously is not desirable if one wants to know whether or not the files are archives. I'm not an expert on compressed archives but perhaps the heuristic that if a stream is interpretable as a tar file without an exception being thrown should only be applied on archives greater than 100 bytes? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-359) Move License Agreement to file top
[ https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189930#comment-13189930 ] Benedikt Ritter commented on SANDBOX-359: - Okay, I just looked through trunk of lang3 and collections and saw that they have it at the very top. It's just, what I have seen the most. > 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 Converter to Transformer
[ https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189919#comment-13189919 ] Benedikt Ritter commented on SANDBOX-360: - As I mentioned on the mailing list, to me it seems, that concepts like Transformer, Predicate, Closure, etc. are missing in Java, giving the fact that for example commons collections and guava define nearly the same interfaces. Adding another label for something that basically transforms an object of one type into another an object of another type, does not seem to be the best thing to do. I would rather call it a transformer, like other libraries do and hope to see a JSR one day to get rid of it ;-) I agree with you, that having the same interface defined in two projects is bad also. But I guess that is the price of having no dependencies. Maybe it would make sense to have a very minimal _commons essentials_ or _commons basics_ that has stuff like that in it. Some sort of base that really all projects share. Validation of input parameters is another thing that every project has to implement. But I think I'm drifting away... ;-) > Rename Converter to Transformer > --- > > Key: SANDBOX-360 > URL: https://issues.apache.org/jira/browse/SANDBOX-360 > Project: Commons Sandbox > Issue Type: Improvement > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Priority: Minor > > Since org.apache.commons.beanutils2.Converter is essentially a from of a > Transformer (see org.apache.commons.collections.Transformer), it should be > named this way. The same applies for > org.apache.commons.beanutils2.converters.AbstractConverter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-358:
---
Attachment: EarlyTerminationAndSubgraphSkipForSearchAlgorithms.patch
Hi,
so I actually changed signatures for methods in {{GraphVisitHandler}}:
* {{discoverVertex}} and {{discoverEdge}} now tell the algorithm if the
corresponding {{Vertex}} and {{Edge}} should be expanded (i.e. if their
neighbors should be added to the visit queue);
* {{finishVertex}} and {{finishEdge}} tell if the algorithm can be ended
prematurely (because the search is complete, e.g. before the target element was
found).
All tests still work. I hope you guys like this one :)
Claudio
> 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
> Attachments: EarlyTerminationAndSubgraphSkipForSearchAlgorithms.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Hello,
> the current implementations in the class {{Visit}} (package
> {{org.apache.commons.graph.visit}}) do not include the possibility to stop
> the search prematurely. That would be more natural (and faster) for many
> kinds of search, e.g. when looking for the first occurrence of a specific
> pattern (vertex, path with certain features, etc).
> The easiest solution: changing all method signatures in {{GraphVisitHandler}}
> from {{void}} to {{boolean}}, forcing the handler to answer the question:
> _should I continue?_
> I understand semantics get a bit entangled (well, not with an appropriate
> documentation!), so I am open to more verbose options: e.g. a method
> {{isSearchComplete}} to call after every step... but that would only be more
> verbose, wouldn't it?
> Waiting for feedback and ready to patch :-)
> Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-360) Rename Converter to Transformer
[ https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189901#comment-13189901 ] Matt Benson commented on SANDBOX-360: - The [collections] functors are all but deprecated; I wouldn't necessarily base other classes' names on theirs. I would argue that in a full-blown transformation framework e.g. Morph, "transformer" is a generalization of "converter" and "copier". My WIP object transformation library (which might become Morph 2) uses this type of nomenclature as well. > Rename Converter to Transformer > --- > > Key: SANDBOX-360 > URL: https://issues.apache.org/jira/browse/SANDBOX-360 > Project: Commons Sandbox > Issue Type: Improvement > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Priority: Minor > > Since org.apache.commons.beanutils2.Converter is essentially a from of a > Transformer (see org.apache.commons.collections.Transformer), it should be > named this way. The same applies for > org.apache.commons.beanutils2.converters.AbstractConverter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-360) Rename Converter to Transformer
[
https://issues.apache.org/jira/browse/SANDBOX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189894#comment-13189894
]
Simone Tripodi commented on SANDBOX-360:
I agree and like it, I was using the {{Converter}} keyword just because in the
old API was named in that way :P
Just the time to leave the office and once get back home, will be done :)
Thanks!
> Rename Converter to Transformer
> ---
>
> Key: SANDBOX-360
> URL: https://issues.apache.org/jira/browse/SANDBOX-360
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
>Priority: Minor
>
> Since org.apache.commons.beanutils2.Converter is essentially a from of a
> Transformer (see org.apache.commons.collections.Transformer), it should be
> named this way. The same applies for
> org.apache.commons.beanutils2.converters.AbstractConverter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-359) Move License Agreement to file top
[ https://issues.apache.org/jira/browse/SANDBOX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189893#comment-13189893 ] Simone Tripodi commented on SANDBOX-359: which convention? the code follows the Maven code style format (see checkstyle configuration) wich allows the license header in the place that is already :) > Move License Agreement to file top > -- > > Key: SANDBOX-359 > URL: https://issues.apache.org/jira/browse/SANDBOX-359 > Project: Commons Sandbox > Issue Type: Task > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter >Priority: Trivial > > Currently, license agreements are located between package declaration and > import statements. To stick to conventions, the license agreements should be > moved up to the very top of each file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-361) Add fluent APIs to build mutable Graphes
[ https://issues.apache.org/jira/browse/SANDBOX-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-361. Resolution: Fixed fixed, see [r1233995|https://svn.apache.org/viewvc?view=revision&revision=1233995] > Add fluent APIs to build mutable Graphes > > > Key: SANDBOX-361 > URL: https://issues.apache.org/jira/browse/SANDBOX-361 > Project: Commons Sandbox > Issue Type: New Feature > Components: Graph >Reporter: Simone Tripodi >Assignee: Simone Tripodi > > Actual MutableGraph APIs are really *verbose*, using a configuration/builder > pattern "a la google Guice" it is possible to improve the MutableGraph code. > That doesn't involve any modification, just additions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-361) Add fluent APIs to build mutable Graphes
Add fluent APIs to build mutable Graphes Key: SANDBOX-361 URL: https://issues.apache.org/jira/browse/SANDBOX-361 Project: Commons Sandbox Issue Type: New Feature Components: Graph Reporter: Simone Tripodi Assignee: Simone Tripodi Actual MutableGraph APIs are really *verbose*, using a configuration/builder pattern "a la google Guice" it is possible to improve the MutableGraph code. That doesn't involve any modification, just additions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-360) Rename Converter to Transformer
Rename Converter to Transformer --- Key: SANDBOX-360 URL: https://issues.apache.org/jira/browse/SANDBOX-360 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Priority: Minor Since org.apache.commons.beanutils2.Converter is essentially a from of a Transformer (see org.apache.commons.collections.Transformer), it should be named this way. The same applies for org.apache.commons.beanutils2.converters.AbstractConverter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-359) Move License Agreement to file top
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] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189872#comment-13189872
]
Gilles commented on MATH-725:
-
Fine then.
Eldar,
Would you provide a patch along those lines ("static" initializations + getter
methods)?
Thanks.
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-301) Add IOUtils.closeQuietly(Selector)
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-301. Resolution: Fixed Patch applied, thank you. Also added a test to get test code coverage to 100% for the new method. > Add IOUtils.closeQuietly(Selector) > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-301) Add IOUtils.closeQuietly(Selector)
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-301: --- Summary: Add IOUtils.closeQuietly(Selector) (was: commons-io: IOUtils.closeQuietly(Selector) necessary ) > Add IOUtils.closeQuietly(Selector) > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189862#comment-13189862
]
Sebb commented on MATH-725:
---
AFAIK, getters will be inlined by optimising compilers.
So they won't be noticeably slower than direct access.
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your 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] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189860#comment-13189860
]
Gilles commented on MATH-725:
-
The problem is that arrays are _mutable_. If they are made "static", a buggy or
malicious subclass of {{AbstractWell}} will be able to affect all instances.
We could do that if the arrays are never exposed, i.e. they would become
"private" and their contents must be accessed through methods. Not sure whether
it won't be slower in the end...
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189804#comment-13189804
]
J-L commented on DAEMON-235:
Well, yes I have. But I'm trying to get these people as much information as
possible.
I don't think asking this in the place where the only different component is
made is that crazy. Currently it is powered by something that runs a service
from a .bat file. As far I can tell that works.
Understanding how the procrun process differs from a standard Java process is
quite interesting information. Might also help clarify why Win 7 and XP act
differently.
I just would like to get this to work, otherwise moving to procrun could be
undermined altogether. :(
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflec
[jira] [Updated] (MATH-729) Add an implementation for Holt-Winters triple exponential smoothing
[ https://issues.apache.org/jira/browse/MATH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-729: Affects Version/s: (was: 3.1) Fix Version/s: 3.1 > Add an implementation for Holt-Winters triple exponential smoothing > --- > > Key: MATH-729 > URL: https://issues.apache.org/jira/browse/MATH-729 > Project: Commons Math > Issue Type: New Feature >Reporter: Nishant Chandra > Labels: exponential, smoothing, triple > Fix For: 3.1 > > > Add an implementation for Holt-Winters triple exponential smoothing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189755#comment-13189755
]
Sebb commented on DAEMON-235:
-
Have you tried showing the C++ developers the stack trace?
Should be enough to give a clue as to the cause.
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j
> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
> j
> sun.rmi.server.UnicastServerRef.dispatch(Ljava/rmi/Remote;Ljava/rmi/server/RemoteCall;)V+242
> j sun.rmi.transport.Transport$1.run()Ljava/lang/Object;+23
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189688#comment-13189688
]
J-L commented on DAEMON-235:
I do expect the JNI called code has something to do with it.
So far JBoss and Tomcat are spinning with procrun, and they communicate over
RMI.
Could you shed some light on what these 'security settings' are and how they
would differ between Win XP an Win 7. The ideal would be that I can get XP to
behave the same way as Win 7. But in either case, something to communicate back
to the developer of the C++ code would be interesting.
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j
> java.lang.reflect.Meth
[jira] [Commented] (SANDBOX-358) Early return/termination for graph visit
[
https://issues.apache.org/jira/browse/SANDBOX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189681#comment-13189681
]
Simone Tripodi commented on SANDBOX-358:
Ciao Claudio!
go ahead on changing all method signatures in {{GraphVisitHandler}} from
{{void}} to {{boolean}}, this is the cleaner solution I can see ATM.
Thanks in advance!!!
> Early return/termination for graph visit
>
>
> Key: SANDBOX-358
> URL: https://issues.apache.org/jira/browse/SANDBOX-358
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Priority: Minor
> Labels: graph, visit, visithandler
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Hello,
> the current implementations in the class {{Visit}} (package
> {{org.apache.commons.graph.visit}}) do not include the possibility to stop
> the search prematurely. That would be more natural (and faster) for many
> kinds of search, e.g. when looking for the first occurrence of a specific
> pattern (vertex, path with certain features, etc).
> The easiest solution: changing all method signatures in {{GraphVisitHandler}}
> from {{void}} to {{boolean}}, forcing the handler to answer the question:
> _should I continue?_
> I understand semantics get a bit entangled (well, not with an appropriate
> documentation!), so I am open to more verbose options: e.g. a method
> {{isSearchComplete}} to call after every step... but that would only be more
> verbose, wouldn't it?
> Waiting for feedback and ready to patch :-)
> Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
