[jira] [Commented] (MATH-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and i
[
https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202115#comment-13202115
]
Sébastien Brisard commented on MATH-732:
Hi Kurt,
your implementation is amazingly faster. I think we definitely should go ahead
and replace the previous impl. We require all pieces of code (including private
methods) to be fully documented. I'll do that, no worries, but I might get back
to you (off-list) to get some more information, if you do not mind.
Unfortunately, I haven't had time to try and spot the weaknesses of the
previous implementation. I suspect this has to do with the use of {{Complex}}
arrays, instead of plain {{double}} arrays. Indeed, since {{Complex}} is
immutable, we end up creating *a lot* of small objects.
In fact, looking at your implementation, I'm wondering whether we should not
give up {{Complex[]}} arrays altogether. I would favour a more standard data
layout, in a {{double}} array, where {{data[2 * i]}} would be the real part,
and {{data[2 * i + 1]}} would be the imaginary part of the specified data.
Presently, your implementation takes the real and imaginary parts as two
separate arrays. What do you think?
I will post this question on the mailing list.
Best regards,
Sébastien
> Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x
> improvement). Preserved public API 100%. Removed unnecessary use of instance
> variables and instance state.
>
>
> Key: MATH-732
> URL: https://issues.apache.org/jira/browse/MATH-732
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Kurt Ostfeld
>Assignee: Sébastien Brisard
> Labels: api, perfomance
> Fix For: 3.0
>
> Attachments: DFTPerformanceWithPatch.png,
> DFTPerformanceWithoutPatch.png, FastFourierTransformer.java,
> FastFourierTransformerTest.java, Main.java
>
>
> I wrote my own Discrete Fourier Transform function in Java and ran some
> benchmarks and found that it ran dramatically faster than the Apache library
> implementation. This is a pretty straight forward implementation of the
> standard Cooley Tukey algorithm that I read out of a textbook. This passes
> all the Apache library test cases plus several I had written on my own. I
> created a source code library patch that preserves the public API completely
> while changing the internal implementation to achieve the performance
> improvement.
> In addition to the performance issue, I suggest that Discrete Fourier
> Transform functionality be provided as stateless pure functions (in Java this
> would be implemented with static methods) just like most other math
> functions. As-is, the library requires the user to instantiate a Transformer
> instance which maintains instance state, which is an unecessary complexity
> for a pure math function. I held off on this change since it would change the
> public API and affect existing code. However, I see similar backward
> compatability breaking API changes are already in the FastFourierTransformer
> class in the 3.0 code base.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202051#comment-13202051
]
Matt Benson commented on SANDBOX-388:
-
Yes; all I can say is "holy shit." :) I thought certainly type erasure would
have made these two methods identical and thus illegal, but yes, it does seem
to work here. Great catch, Steven!
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-440) library throws an exception in case the SYST command is not known or the result is not known by the implementation
[ https://issues.apache.org/jira/browse/NET-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-440. -- Resolution: Fixed Fix Version/s: 3.1 Added check for system property "org.apache.commons.net.ftp.systemType.default" if SYST commmand fails, > library throws an exception in case the SYST command is not known or the > result is not known by the implementation > -- > > Key: NET-440 > URL: https://issues.apache.org/jira/browse/NET-440 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0.1 >Reporter: s >Priority: Minor > Fix For: 3.1 > > > The FTP client uses the SYST command to determine the list output. > This can fail in two ways: > - a ParserInitializationException in case the response of the server is not > known by apache. > - When the response to SYST command is 502 command unknown (the command is > optional after all - http://www.ietf.org/rfc/rfc959.txt) the client throws an > IOException. > Can't it just default to UNIX for these type of ftp servers? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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] (NET-440) library throws an exception in case the SYST command is not known or the result is not known by the implementation
[ https://issues.apache.org/jira/browse/NET-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202022#comment-13202022 ] Sebb commented on NET-440: -- If the property "org.apache.commons.net.ftp.systemType" is defined, the code will use that as the system type, instead of relying on the return from SYST. If the SYST returns a value, but the value is not currently recognised, then you can create a property file "/systemType.properties" which maps system types to the parser type or parser class. Using the wrong parser won't necessarily cause a parse failure - it may just return incorrect results, which is why I don't think it is safe to have a built-in default. However, it would be possible to have an optional default system type which is used if the SYST command fails. > library throws an exception in case the SYST command is not known or the > result is not known by the implementation > -- > > Key: NET-440 > URL: https://issues.apache.org/jira/browse/NET-440 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0.1 >Reporter: s >Priority: Minor > > The FTP client uses the SYST command to determine the list output. > This can fail in two ways: > - a ParserInitializationException in case the response of the server is not > known by apache. > - When the response to SYST command is 502 command unknown (the command is > optional after all - http://www.ietf.org/rfc/rfc959.txt) the client throws an > IOException. > Can't it just default to UNIX for these type of ftp servers? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201992#comment-13201992
]
Ralph Goers commented on VFS-400:
-
Sorry to be a pain but do you happen to have a unit test that can verify the
functionality? That will save us from having to develop one.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {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] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201616#comment-13201616
]
Simone Tripodi commented on SANDBOX-388:
Hi Steven!!
simply amazing!!! Since you are an ASF committer, would you be pleased to be
granted to commit to Sandbox? Commons Sandbox is open to all ASF committers, I
would be more than glad if you could participate!
Many thanks in advance!
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201572#comment-13201572
]
Steven Dolg edited comment on SANDBOX-388 at 2/6/12 8:55 PM:
-
A quick workaround might be overloading the methods in question, using a type
of graph that allows to connect the disobedient generic to Graph in the type
parameters of the method header.
Like this:
{noformat}
public static , W, G extends
DirectedMutableWeightedGraph> FromHeadBuilder
findMaxFlow( G graph )
public static , W, G extends
DirectedGraph> FromHeadBuilder findMaxFlow( G graph )
{noformat}
and this
{noformat}
public static , W, G extends
UndirectedMutableWeightedGraph> SpanningTreeSourceSelector minimumSpanningTree( G graph )
public static , W, G extends
Graph> SpanningTreeSourceSelector minimumSpanningTree( G
graph )
{noformat}
This fixes all the compile error in my Eclipse (exact same version as mentioned
in the issue description).
Not sure if this works everywhere or if it is desirable at all, but I wanted to
mention it anyway.
was (Author: steven.dolg):
A quick workaround might be overloading the methods in question, using a
type of graph that allows to mention the disobedient generic in the type
parameters of the method header.
Like this:
{noformat}
public static , W, G extends
DirectedMutableWeightedGraph> FromHeadBuilder
findMaxFlow( G graph )
public static , W, G extends
DirectedGraph> FromHeadBuilder findMaxFlow( G graph )
{noformat}
and this
{noformat}
public static , W, G extends
UndirectedMutableWeightedGraph> SpanningTreeSourceSelector minimumSpanningTree( G graph )
public static , W, G extends
Graph> SpanningTreeSourceSelector minimumSpanningTree( G
graph )
{noformat}
This fixes all the compile error in my Eclipse (exact same version as mentioned
in the issue description).
Not sure if this works everywhere or if it is desirable at all, but I wanted to
mention it anyway.
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201572#comment-13201572
]
Steven Dolg commented on SANDBOX-388:
-
A quick workaround might be overloading the methods in question, using a type
of graph that allows to mention the disobedient generic in the type parameters
of the method header.
Like this:
{noformat}
public static , W, G extends
DirectedMutableWeightedGraph> FromHeadBuilder
findMaxFlow( G graph )
public static , W, G extends
DirectedGraph> FromHeadBuilder findMaxFlow( G graph )
{noformat}
and this
{noformat}
public static , W, G extends
UndirectedMutableWeightedGraph> SpanningTreeSourceSelector minimumSpanningTree( G graph )
public static , W, G extends
Graph> SpanningTreeSourceSelector minimumSpanningTree( G
graph )
{noformat}
This fixes all the compile error in my Eclipse (exact same version as mentioned
in the issue description).
Not sure if this works everywhere or if it is desirable at all, but I wanted to
mention it anyway.
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-387) [BeanUtils2] Implement possibility to find out if a property readable and/or wirtable
[
https://issues.apache.org/jira/browse/SANDBOX-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated SANDBOX-387:
Attachment: SANDBOX-387.txt
Patch for this issue created and attached.
I implemented checking for simple properties and for indexed properties.
Because there is no MappedPropertyDescriptor present in the Java API I did not
know how to handle mapped properties. I added TODO markers for that to the
methods.
> [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
> Attachments: SANDBOX-387.txt
>
>
> Currently there is no possibility to find out, if a property is readable
> and/or writable.
> For example, one has to pass a value to
> {{setProperty(name).withValue(argument)}} and hope, that the property is
> writeable (because a {{NoSucheMethodExcpetion}} will be thrown, if it is
> not). For this reason it would be nice, if one could do something like:
> {code:java}
> if (on(myBean).isWritable("writeableProperty") {
> on(myBean).setProperty("writableProperty").withValue("This is a String
> value!");
> }
> {code}
> Solution:
> * Add {{public boolean isWritable(String propertyName)}} and {{public boolean
> isReadable(String propertyName)}} to {{BeanAccessor}}.
> * in {{isWritable()}} check if a {{PropertyDescriptor}} can be obtained from
> PropertyRegistry (if not, throw {{NoSuchMethodException}}).
> ** if so, return true, if {{propertyDescriptor.getWriteMethod() != null}} and
> false otherwise.
> * in {{isReadable()}} check if a {{PropertyDescriptor}} can be obtained from
> PropertyRegistry (if not, throw {{NoSuchMethodException}}).
> ** if so, return true, if {{propertyDescriptor.getReadMethod() != null}} and
> false otherwise.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201478#comment-13201478
]
Simone Tripodi commented on SANDBOX-388:
the problem is that for {{findMaxFlow()}} method it never infers the {{W}}
type, even with valid graph :(
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DAEMON-240) Undocumented and inconsistent behaviour of multi-valued registry entries
[ https://issues.apache.org/jira/browse/DAEMON-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201358#comment-13201358 ] Mladen Turk edited comment on DAEMON-240 at 2/6/12 6:18 PM: Resolved by ensuring that --option rests the parser state. 1. In case --option ++option ... is used the resulting value will be overwritten with those command line (combined) 2. In case ++option ++option ... is used the resulting value will be appended to existing one. 3. ++option=a --option=b will cause that any options on the command line before last -- are dropped. No error or no warning is reported in that case. was (Author: mt...@apache.org): Resolved by disabling intermixing -- and ++ options on the same command line. This means that either --option or any number of ++option can be used, but not together > Undocumented and inconsistent behaviour of multi-valued registry entries > > > Key: DAEMON-240 > URL: https://issues.apache.org/jira/browse/DAEMON-240 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.8 >Reporter: Sebb > Fix For: 1.0.9 > > > The behaviour of option processing for multi-valued registry entries is > partly undocumented, and inconsistent. > --Option and ++Option are only documented in the context of a single > invocation of procrun. > The documentation should be updated to clarify that ++Option can be used in a > separate invocation of procrun (update service) to append values to the > registry. > == > The documentation implies that --Option resets the value. > This is only true if the ++Option is not used at the same time - if the > ++Option is used anywhere on the command-line, then all the options are > appended to any existing value in the registry. > The behaviour of mixed --Option and ++Option should either be fixed so that > --Option clears any existing settings, or the existing behaviour 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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201384#comment-13201384
]
Thomas Neidhart commented on SANDBOX-388:
-
A rather ugly but working solution would be to cast the input graph to an
unchecked DirectedGraph to circumvent type inference at all, like the following:
{code:title=FordFulkersonTest.java|borderStyle=solid}
@Test(expected=NullPointerException.class)
public void testNullGraphAndVertices()
{
findMaxFlow( (DirectedGraph) null ).from( null ).to( null
).applyingFordFulkerson( new IntegerWeight() );
}
{code}
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-385) Provide Edmonds-Karp algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-385.
Resolution: Fixed
Assignee: Simone Tripodi
Claudio,
amazing. Patch applied, check
[r1241056|http://svn.apache.org/viewvc?rev=1241056&view=rev].
The only modification I applied, is transforming the {{FlowNetwork}} as class,
in simpler a method.
Thanks again for your contribution!!!
> Provide Edmonds-Karp algorithm
> --
>
> Key: SANDBOX-385
> URL: https://issues.apache.org/jira/browse/SANDBOX-385
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Marco Speranza
>Assignee: Simone Tripodi
> Attachments: SANDBOX-385_AddedEdmondsKarpImplementationAndTest.patch
>
>
> Add the [Edmonds-Karp|http://en.wikipedia.org/wiki/Edmonds-Karp_algorithm]
> algorithm into org.apache.commons.graph.flow package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-240) Undocumented and inconsistent behaviour of multi-valued registry entries
[ https://issues.apache.org/jira/browse/DAEMON-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-240. Resolution: Fixed Fix Version/s: 1.0.9 Resolved by disabling intermixing -- and ++ options on the same command line. This means that either --option or any number of ++option can be used, but not together > Undocumented and inconsistent behaviour of multi-valued registry entries > > > Key: DAEMON-240 > URL: https://issues.apache.org/jira/browse/DAEMON-240 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.8 >Reporter: Sebb > Fix For: 1.0.9 > > > The behaviour of option processing for multi-valued registry entries is > partly undocumented, and inconsistent. > --Option and ++Option are only documented in the context of a single > invocation of procrun. > The documentation should be updated to clarify that ++Option can be used in a > separate invocation of procrun (update service) to append values to the > registry. > == > The documentation implies that --Option resets the value. > This is only true if the ++Option is not used at the same time - if the > ++Option is used anywhere on the command-line, then all the options are > appended to any existing value in the registry. > The behaviour of mixed --Option and ++Option should either be fixed so that > --Option clears any existing settings, or the existing behaviour 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] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201346#comment-13201346
]
Simone Tripodi commented on SANDBOX-388:
Hi Jörg, sorry for the ignorance, but... I don't know how to install Oracle
JDK7 on Mac Os X :(
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-385) Provide Edmonds-Karp algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-385:
---
Attachment: SANDBOX-385_AddedEdmondsKarpImplementationAndTest.patch
Hello,
I implemented Edmonds-Karp plus a test for it.
I also found a bug in the previous implementation of
{{DefaultVisitAlgorithmsSelector}} and fixed it: vertices are added to the
visit stack/queue only if the edge leading to them is actually discovered.
Finally I extracted common code in the {{FlowNetworkHandler}} creating a
utility class called {{FlowNetwork}}, that represents a directed graph with
flow capacity.
Hoping this helps,
Claudio
> 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
> Attachments: SANDBOX-385_AddedEdmondsKarpImplementationAndTest.patch
>
>
> Add the [Edmonds-Karp|http://en.wikipedia.org/wiki/Edmonds-Karp_algorithm]
> algorithm into org.apache.commons.graph.flow package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201327#comment-13201327
]
Joerg Schaible commented on SANDBOX-388:
@simo: If it's reported to fail with OraJDK 7, you should use that one with
Maven to proof something ... ;-)
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201320#comment-13201320
]
Simone Tripodi commented on SANDBOX-388:
what worries me is that Eclipse users would be reluctant on using our APIs
because of that issue... ;(
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201314#comment-13201314
]
Gary D. Gregory commented on SANDBOX-388:
-
Don't go bonkers Simo, Eclipse has its own Java compiler.
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-234) Allow the same jsvc binary executable to work with either libcap.so.1 or libcap.so.2 at runtime
[
https://issues.apache.org/jira/browse/DAEMON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mladen Turk resolved DAEMON-234.
Resolution: Fixed
Fix Version/s: 1.0.9
Implemented by dynamically loading libcap.so.
This means that the library is not linked to libcap.so.MAJOR
but it loads and resolves api symbols at run-time.
> Allow the same jsvc binary executable to work with either libcap.so.1 or
> libcap.so.2 at runtime
> ---
>
> Key: DAEMON-234
> URL: https://issues.apache.org/jira/browse/DAEMON-234
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Jsvc
>Affects Versions: 1.0.8
>Reporter: Phil Clay
> Fix For: 1.0.9
>
>
> From a recent mail thread on the commons user list...
> http://markmail.org/message/uvkfqd7nkqyhq5eg
> I would like to be able to use jsvc on both debian and redhat machines.
> Ideally, I'd like to be able to compile jsvc once, and use the same binary on
> both platforms.
> The problem I am encountering is that the version of libcap varies across
> machines.
> For example, if I compile jsvc on a RHEL 5.4 machine (which has libcap.so.1),
> and then attempt to run the same binary on a Debian 6 machine (which has
> libcap.so.2), then the execution fails with:
> jsvc: error while loading shared libraries: libcap.so.1: cannot open shared
> object file: No such file or directory
> In order to create a single jsvc executable that works whether or not
> libcap.so.1 or libcap.so.2 is available at runtime, the jsvc code should use
> dlopen("libcap.so") and then dlsym all API's instead linking.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201304#comment-13201304
]
Simone Tripodi commented on SANDBOX-388:
what is driving me crazy is that running from CLI
{quote}
$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
{quote}
doesn't report the same error :(
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201300#comment-13201300
]
Gary D. Gregory commented on SANDBOX-388:
-
Data point: I see this in 3.7.1.
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
[
https://issues.apache.org/jira/browse/SANDBOX-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201299#comment-13201299
]
Gary D. Gregory commented on SANDBOX-388:
-
Did you try the latest Eclipse 3.x AND 4.x?
> Generic Type inference doesn't work in Eclipse
> --
>
> Key: SANDBOX-388
> URL: https://issues.apache.org/jira/browse/SANDBOX-388
> Project: Commons Sandbox
> Issue Type: Bug
> Components: Graph
> Environment: Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
>Reporter: Simone Tripodi
>Priority: Blocker
>
> {{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
> simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum
> they reported that doesn't work if the code is compiled with Oracle JDK7.
> One of the reported error in Eclipse is:
> {quote}
> Type mismatch: cannot convert from
> SpanningTree,Object> to
> SpanningTree,Double>
> {quote}
> Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-388) Generic Type inference doesn't work in Eclipse
Generic Type inference doesn't work in Eclipse
--
Key: SANDBOX-388
URL: https://issues.apache.org/jira/browse/SANDBOX-388
Project: Commons Sandbox
Issue Type: Bug
Components: Graph
Environment: Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 1
Build id: 20110916-0149
Reporter: Simone Tripodi
Priority: Blocker
{{Flow}} and {{MST}} EDSL is affected by generic type inference issue, it
simply doesn't work in Eclipse. It works in IDEA, but in the Eclipse forum they
reported that doesn't work if the code is compiled with Oracle JDK7.
One of the reported error in Eclipse is:
{quote}
Type mismatch: cannot convert from
SpanningTree,Object> to
SpanningTree,Double>
{quote}
Looking for a solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-440) library throws an exception in case the SYST command is not known or the result is not known by the implementation
[ https://issues.apache.org/jira/browse/NET-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201240#comment-13201240 ] s commented on NET-440: --- That only works if known you the type of the server in advance. We use the library to connect to a lot of different FTP servers where the type of server is not known in advance. (And by server I mean devices in the field, with some unknown OS and FTP server which can be up to 20 years old). When it can not auto detect (for whatever reason), I'd say try some default formatting. You can always fail afterwards when parsing does not succeed? > library throws an exception in case the SYST command is not known or the > result is not known by the implementation > -- > > Key: NET-440 > URL: https://issues.apache.org/jira/browse/NET-440 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.0.1 >Reporter: s >Priority: Minor > > The FTP client uses the SYST command to determine the list output. > This can fail in two ways: > - a ParserInitializationException in case the response of the server is not > known by apache. > - When the response to SYST command is 502 command unknown (the command is > optional after all - http://www.ietf.org/rfc/rfc959.txt) the client throws an > IOException. > Can't it just default to UNIX for these type of ftp servers? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your 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-47) Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security manager
[
https://issues.apache.org/jira/browse/OGNL-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201235#comment-13201235
]
Maurizio Cucchiara commented on OGNL-47:
OK,
I enabled the SecurityManager on Tomcat, but instead of following exactly your
advice:
# I added to the default catalina.policy the following permission: {{permission
java.security.AllPermission}} (sorry but I have no time to check all security
vars to enable in order to allow Struts2 app to work out)
# I started tomcat with the following cmd: {{$(CATALINA_HOME)/bin/catalina.sh
run -security}}
I used [the blank
app|https://builds.apache.org/job/Struts2/lastBuild/org.apache.struts$struts2-blank/]
present on the latest Struts2 snapshot.
Unfortunately I'm not still able to reproduce this issue.
It would seem something related with your environment/configuration.
> Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security
> manager
> --
>
> Key: OGNL-47
> URL: https://issues.apache.org/jira/browse/OGNL-47
> Project: Commons OGNL
> Issue Type: Bug
>Reporter: kesava
>Priority: Blocker
>
> Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security
> manager
> Steps to reproduce
> 1.Enable security manager
> 2.Load the app
> {noformat}
> Caught an Ognl exception while getting property serviceProviders - Class:
> ognl.ObjectPropertyAccessor
> File: ObjectPropertyAccessor.java
> Method: getPossibleProperty
> Line: 69 - ognl/ObjectPropertyAccessor.java:69:-1
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:142)
> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2303)
> at ognl.ASTProperty.getValueBody(ASTProperty.java:114)
> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212)
> at ognl.SimpleNode.getValue(SimpleNode.java:258)
> at ognl.Ognl.getValue(Ognl.java:494)
> at ognl.Ognl.getValue(Ognl.java:458)
> at com.opensymphony.xwork2.ognl.OgnlUtil.getValue(OgnlUtil.java:213)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.getValueUsingOgnl(OgnlValueStack.java:277)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValue(OgnlValueStack.java:260)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.tryFindValueWhenExpressionIsNotNull(OgnlValueStack.java:242)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:222)
> at
> com.opensymphony.xwork2.ognl.OgnlValueStack.findValue(OgnlValueStack.java:284)
> at
> org.apache.struts2.views.velocity.StrutsVelocityContext.internalGet(StrutsVelocityContext.java:91)
> at
> org.apache.velocity.context.AbstractContext.get(AbstractContext.java:193)
> at
> org.apache.velocity.context.InternalContextAdapterImpl.get(InternalContextAdapterImpl.java:286)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:843)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:222)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:263)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
> at org.apache.velocity.Template.merge(Template.java:328)
> at org.apache.velocity.Template.merge(Template.java:235)
> at
> org.apache.struts2.dispatcher.VelocityResult.doExecute(VelocityResult.java:156)
> at
> org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:374)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:278)
> at
> com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.java:69)
> at
> com.sony.sce.producttool.web.CacheFlushFilterInterceptor$2.call(CacheFlushFilterInterceptor.j
[jira] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201233#comment-13201233
]
Simone Tripodi commented on SANDBOX-348:
Thank you Thomas, and welcome to the brotherhood! :)
> Implement the Boruvka's algorithm
> -
>
> Key: SANDBOX-348
> URL: https://issues.apache.org/jira/browse/SANDBOX-348
> Project: Commons Sandbox
> Issue Type: Sub-task
> Components: Graph
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Attachments: BoruvkaTestCase2.java,
> DefaultSpanningTreeAlgorithmSelector.java,
> SANDBOX-348-ConnectivityAlgo.patch,
> SANDBOX-348_Boruvka_algorithm_implementation.patch
>
>
> The class {{org.apache.commons.graph.spanning.Boruvka}} contains an empty
> implementation of
> [Boruvka|http://en.wikipedia.org/wiki/Bor%C5%AFvka's_algorithm]'s algorithm,
> that needs to be filled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-240) Undocumented and inconsistent behaviour of multi-valued registry entries
Undocumented and inconsistent behaviour of multi-valued registry entries Key: DAEMON-240 URL: https://issues.apache.org/jira/browse/DAEMON-240 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.8 Reporter: Sebb The behaviour of option processing for multi-valued registry entries is partly undocumented, and inconsistent. --Option and ++Option are only documented in the context of a single invocation of procrun. The documentation should be updated to clarify that ++Option can be used in a separate invocation of procrun (update service) to append values to the registry. == The documentation implies that --Option resets the value. This is only true if the ++Option is not used at the same time - if the ++Option is used anywhere on the command-line, then all the options are appended to any existing value in the registry. The behaviour of mixed --Option and ++Option should either be fixed so that --Option clears any existing settings, or the existing behaviour 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] (DAEMON-238) Behaviour of environment variables is not documented, and is unexpected
[ https://issues.apache.org/jira/browse/DAEMON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-238. - Resolution: Fixed Fix Version/s: 1.0.9 Updated doc. > Behaviour of environment variables is not documented, and is unexpected > --- > > Key: DAEMON-238 > URL: https://issues.apache.org/jira/browse/DAEMON-238 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Reporter: Sebb > Fix For: 1.0.9 > > > The documentation does not currently state whether environment variables are > processed before or after command-line options. > It appears that they are processed *after* any command-line options, at least > in 1.0.7 amd 1.0.8. > They completely override the corresponding command-line option in both > versions. > for example: > set PR_JVMOPTION=-Da=1 > prunsrv //US//Service --JvmOption -Da=2 ++JvmOption -Db=1 > results in -Da=1 only, as does > set PR_JVMOPTION=-Da=1 > prunsrv //US//Service --JvmOption -Da2=1 ++JvmOption -Db=1 > If this really is the intended behaviour, it should be documented as such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-348) Implement the Boruvka's algorithm
[
https://issues.apache.org/jira/browse/SANDBOX-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201226#comment-13201226
]
Thomas Neidhart commented on SANDBOX-348:
-
Ok, I have committed the changes with your suggestions in r1240978.
> 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] [Updated] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rikard Oxenstrand updated VFS-400:
--
Attachment: FileRegexSelector.java.patch
Draft implementation of the function.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {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] [Issue Comment Edited] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201188#comment-13201188
]
Rikard Oxenstrand edited comment on VFS-400 at 2/6/12 10:09 AM:
Draft implementation of the function. Uploaded as attachment.
was (Author: rikard.oxenstrand):
Draft implementation of the function.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
> Attachments: FileRegexSelector.java.patch
>
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {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] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201184#comment-13201184
]
Adrian Crum commented on VFS-400:
-
Please convert your code to a patch file and attach the patch file to this
issue. When attaching your file, be sure to grant the ASF permission to use
your code.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {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] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rikard Oxenstrand updated VFS-400:
--
Description:
In the long todo list there was a post about adding a file selector based on
regular expressions. I had need for that for a specific project so I built a
simple class that seems to work. I'm kind of new to open source contribution
though so I'm not sure if i should just commit it to trunk. Here is the code:
{code:title=FileRegexSelector.java|borderStyle=solid}
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.vfs2;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* A {@link FileSelector} that selects based on regular expressions matched
against base filename.
*
* @since 2.1
*/
public class FileRegexSelector implements FileSelector
{
/**
* The extensions to select.
*/
private Pattern pattern = null;
/**
* Creates a new selector for the given extensions.
*
* @param extensions
*The extensions to be included by this selector.
*/
public FileRegexSelector(String regex)
{
this.pattern = Pattern.compile(regex);
}
/**
* Determines if a file or folder should be selected.
* @param fileInfo
*The file selection information.
* @return true if the file should be selected, false otherwise.
*/
public boolean includeFile(final FileSelectInfo fileInfo)
{
if (this.pattern == null)
{
return false;
}
Matcher matcher =
this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
return matcher.matches();
}
/**
* Determines whether a folder should be traversed.
*
* @param fileInfo
*The file selection information.
* @return true if descendents should be traversed, fase otherwise.
*/
public boolean traverseDescendents(final FileSelectInfo fileInfo)
{
return true;
}
}
{code}
was:
In the long todo list there was a post about adding a file selector based on
regular expressions. I had need for that for a specific project so I built a
simple class that seems to work. I'm kind of new to open source contribution
though so I'm not sure if i should just commit it to trunk. Here is the code:
{code:title=Bar.java|borderStyle=solid}
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.vfs2;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* A {@link FileSelector} that selects based on regular expressions matched
against base filename.
*
* @since 2.1
*/
public class FileRegexSelector implements FileSelector
{
/**
* The extensions to select.
*/
private Pattern pattern = null;
/**
* Creates a new selector for the given extensions.
*
* @param extensions
*The extensions to be included by this selector.
*/
public FileRegexSelector(String regex)
{
this.pattern = Pattern.compile(regex);
}
/**
* Determines if a file or folder should be selected.
* @param fileInfo
*The file selection information.
* @return true if the file should be selected, false otherwise.
*/
public boolean includeFile(final FileSelectInfo fileInfo)
{
if (this.pattern == null)
{
[jira] [Created] (VFS-400) Selector based on regular expressions
Selector based on regular expressions
-
Key: VFS-400
URL: https://issues.apache.org/jira/browse/VFS-400
Project: Commons VFS
Issue Type: New Feature
Affects Versions: 2.1
Reporter: Rikard Oxenstrand
Priority: Minor
In the long todo list there was a post about adding a file selector based on
regular expressions. I had need for that for a specific project so I built a
simple class that seems to work. I'm kind of new to open source contribution
though so I'm not sure if i should just commit it to trunk. Here is the code:
{code:title=Bar.java|borderStyle=solid}
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.vfs2;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* A {@link FileSelector} that selects based on regular expressions matched
against base filename.
*
* @since 2.1
*/
public class FileRegexSelector implements FileSelector
{
/**
* The extensions to select.
*/
private Pattern pattern = null;
/**
* Creates a new selector for the given extensions.
*
* @param extensions
*The extensions to be included by this selector.
*/
public FileRegexSelector(String regex)
{
this.pattern = Pattern.compile(regex);
}
/**
* Determines if a file or folder should be selected.
* @param fileInfo
*The file selection information.
* @return true if the file should be selected, false otherwise.
*/
public boolean includeFile(final FileSelectInfo fileInfo)
{
if (this.pattern == null)
{
return false;
}
Matcher matcher =
this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
return matcher.matches();
}
/**
* Determines whether a folder should be traversed.
*
* @param fileInfo
*The file selection information.
* @return true if descendents should be traversed, fase otherwise.
*/
public boolean traverseDescendents(final FileSelectInfo fileInfo)
{
return true;
}
}
{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
