[GitHub] commons-lang pull request: Optimization of getLevenshteinDistance ...

[jontejj]

GitHub user jontejj opened a pull request:

https://github.com/apache/commons-lang/pull/118

Optimization of getLevenshteinDistance with a threshold

If the string lengths differ more than the threshold,
there's no need for the algoritm to begin allocating
arrays etc.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jontejj/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/118.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #118


commit 29eb271b133b40295fb798545f30b3b4f5b0080c
Author: Jonatan Jönsson 
Date:   2015-11-26T09:23:15Z

Optimization of getLevenshteinDistance with a threshold

If the string lengths differ more than the threshold,
there's no need for the algoritm to begin allocating
arrays etc.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (LANG-1188) lang3/StringUtils.java:3302: warning: [unchecked] Possible heap pollution from parameterized vararg type T

[Simon KRAMER (JIRA)]

Simon KRAMER created LANG-1188:
--

 Summary: lang3/StringUtils.java:3302: warning: [unchecked] 
Possible heap pollution from parameterized vararg type T
 Key: LANG-1188
 URL: https://issues.apache.org/jira/browse/LANG-1188
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.*
Affects Versions: 3.4
 Environment: javac 1.8.0_25
Reporter: Simon KRAMER
Priority: Minor
 Fix For: 3.4


commons-lang3-3.4-src/src/main/java/org/apache/commons/lang3/StringUtils.java:3302:
 warning: [unchecked] Possible heap pollution from parameterized vararg type T
public static  String join(final T... elements) {
 ^

usage: String.join(" ", stringarray)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028820#comment-15028820
 ] 

Michael Osipov commented on JXPATH-183:
---

That is a terrible piece of code which creates 16000 new integer objects. 
[{{Integer#valueOf}}|http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf%28int%29].
 should give a better performance here.

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JEXL-180) Documentation - suggests using float for financials

[Dmitri Blinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028825#comment-15028825
 ] 

Dmitri Blinov commented on JEXL-180:


Could you give a brief overview of what is needed to produce an official 
release?

> Documentation - suggests using float for financials
> ---
>
> Key: JEXL-180
> URL: https://issues.apache.org/jira/browse/JEXL-180
> Project: Commons JEXL
>  Issue Type: Bug
>Reporter: Kimball Robinson
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> The examples page:
> https://commons.apache.org/proper/commons-jexl/reference/examples.html
> Uses a Float type to represent dollar amounts.  This is a bad idea--floating 
> point values are not large enough to represent larger transactions and this 
> could teach developers bad habits, especially in enterprise environments.
> At the least you should use the Double class in your example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-184) Update to Java 7

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028841#comment-15028841
 ] 

Sebb commented on JXPATH-184:
-

bq. Changed the group/artifact id to the new style of Apache Commons

This can only be done if the package name is changed at the same time.
Otherwise classpath issues can result

> Update to Java 7
> 
>
> Key: JXPATH-184
> URL: https://issues.apache.org/jira/browse/JXPATH-184
> Project: Commons JXPath
>  Issue Type: Task
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028858#comment-15028858
 ] 

Sebb commented on JXPATH-183:
-

It's also really bad to catch Throwable.

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Ganna Shmatova (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028872#comment-15028872
 ] 

Ganna Shmatova commented on JXPATH-183:
---

Is in the logs. The expression searches for all instances of LOB. With
//LOB. So yes it would probably search there.



> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-184) Update to Java 7

[Michele Vivoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028926#comment-15028926
 ] 

Michele Vivoda commented on JXPATH-184:
---

bq. I would rather finalize 1.4, publish and the focus on 2.0.

I agree

About 1.7, other examples: Spring Framework:
bq. JDK 6+ for Spring Framework 4.x JDK 5+ for Spring Framework 3.x

Hibernate 4.x
bq. Java 6 or higher (building Hibernate from source requires JDK 7 due to a 
bug in the JDK 6 compiler).

In my opinion the issue is about the JDK a potential client library must 
support. If a developer makes a library with tools for Spring 4.x he must 
target jdk6 and it wont' be able to use JXPath as it nees jdk7. I am in this 
situation, but I think many others are.

I would say start a new JXPath 2 with jdk6 and then see what happens, wait to 
see if there is a real need of jdk7 and introduce it for an actual need.



> Update to Java 7
> 
>
> Key: JXPATH-184
> URL: https://issues.apache.org/jira/browse/JXPATH-184
> Project: Commons JXPath
>  Issue Type: Task
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Michele Vivoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028951#comment-15028951
 ] 

Michele Vivoda commented on JXPATH-183:
---

yes, see JXPATH-186

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Michele Vivoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028953#comment-15028953
 ] 

Michele Vivoda commented on JXPATH-183:
---

Even worse, is calling 16000 times a method with reflection because it expects 
the method to throw exception if out of bounds. If is the timezone method to be 
called I know that timezone retrieval can be expensive and that being the int 
an offset is ok to pass from 0 to 16000.

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-184) Update to Java 7

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028971#comment-15028971
 ] 

Michael Osipov commented on JXPATH-184:
---

Thanks for pointing this out. Forgot it completely.

> Update to Java 7
> 
>
> Key: JXPATH-184
> URL: https://issues.apache.org/jira/browse/JXPATH-184
> Project: Commons JXPath
>  Issue Type: Task
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-186) JXPath catches Throwable

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028975#comment-15028975
 ] 

Michael Osipov commented on JXPATH-186:
---

I fully agree. We should never catch {{Throwable}} but {{Exception}} only.

> JXPath catches Throwable
> 
>
> Key: JXPATH-186
> URL: https://issues.apache.org/jira/browse/JXPATH-186
> Project: Commons JXPath
>  Issue Type: Bug
>Reporter: Michele Vivoda
>Priority: Minor
>
> JXPath catches Throwable in 12 places, it could be a bad practice 
> http://stackoverflow.com/a/16027430/1536382
> In most places it just rethrows but in a couple also does some logic, like in 
> PropertyIterator where returns a NullPropertyPointer object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Michele Vivoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028982#comment-15028982
 ] 

Michele Vivoda commented on JXPATH-183:
---

Not sure why this feature exists, to support [indexed 
poperties|http://da2i.univ-lille1.fr/doc/tutorial-java/javabeans/properties/indexed.html]
  I think, there is one test about it {{BeanModelTest}}, not sure if there are 
use cases for it, for me is a not so common pattern.

I think that guessing in this way is risky as came out from this issue, the 
method could have also more side effects than just waiting.  If it were for me  
I would remove this feature in a next release for the risks it creates, or at 
least disable it by default.

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-183) XMLGregorianCalendar existence adding a lot of performance penalty

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029001#comment-15029001
 ] 

Sebb commented on JXPATH-183:
-

If the test really is required, it would probably be possible to speed it up a 
lot by using a binary chop method.

> XMLGregorianCalendar existence adding a lot of performance penalty
> --
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
>Reporter: Ganna Shmatova
>  Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a 
> valid date it gets transformed from a SOAP message into Java objects. When 
> this happens JXPath queries suddenly take 1-8 seconds more (depending on 
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java 
> for now)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JXPATH-186) JXPath catches Throwable

[Michele Vivoda (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029002#comment-15029002
 ] 

Michele Vivoda commented on JXPATH-186:
---

Yes, where the exception is rethrown we can safely just catch {{Exception}}. 

I put here the cases I found where no rethrow, this is 
PropertyIterator#getNodePointer()

{noformat}
try {
return propertyNodePointer.getValuePointer();
}
catch (Throwable t) {
propertyNodePointer.handle(t);
NullPropertyPointer npp =
new NullPropertyPointer(
propertyNodePointer.getImmediateParentPointer());
npp.setPropertyName(propertyNodePointer.getPropertyName());
npp.setIndex(propertyNodePointer.getIndex());
return npp.getValuePointer();
}
{noformat}

This is in PropertyIterator#getLength

{noformat}
try {
length = propertyNodePointer.getLength(); // TBD: cache length
}
catch (Throwable t) {
propertyNodePointer.handle(t);
length = 0;
}
{noformat}

Something rarely seen in SimpleCharStream ;-)

{noformat}
 catch (Throwable t)
 {
throw new Error(t.getMessage());
 }
{noformat}

> JXPath catches Throwable
> 
>
> Key: JXPATH-186
> URL: https://issues.apache.org/jira/browse/JXPATH-186
> Project: Commons JXPath
>  Issue Type: Bug
>Reporter: Michele Vivoda
>Priority: Minor
>
> JXPath catches Throwable in 12 places, it could be a bad practice 
> http://stackoverflow.com/a/16027430/1536382
> In most places it just rethrows but in a couple also does some logic, like in 
> PropertyIterator where returns a NullPropertyPointer object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-559) FTPClientWrapper is not robust against some failures

[L (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029007#comment-15029007
 ] 

L commented on VFS-559:
---

Yes, the error is fixed.

> FTPClientWrapper is not robust against some failures
> 
>
> Key: VFS-559
> URL: https://issues.apache.org/jira/browse/VFS-559
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: L
>
> The goal of the class is stated in javadoc:
> A wrapper to the FTPClient to allow automatic reconnect on connection loss.
> A lot of its methods look like :
> try
> {
> do something...
> }
> catch (final IOException e)
> {
> disconnect();
> try to repeat the operation...
> }
> Unfortunately disonnect() can fail for the same reason as the original "do 
> something". In my case it as a "connection reset". So instead of the original 
> exception I was getting more or less the same exception from 
> getFtpClient().quit();
> So the wrapper did not help at all.
> I guess all the disconnect() invocations must also be inside try/catch so 
> that even if disconnect() throws, the method goes on to the next step:  try 
> to repeat the operation...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JEXL-181) Cannot create inline Map with array or function call as the key

[Balazs Zsoldos (JIRA)]

Balazs Zsoldos created JEXL-181:
---

 Summary: Cannot create inline Map with array or function call as 
the key
 Key: JEXL-181
 URL: https://issues.apache.org/jira/browse/JEXL-181
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Balazs Zsoldos


It seems that inline maps can be created only if:

 - the keys are string literals or a numbers
 - the keys are variables

The followings throw exception:

{code}
{ ['1', '2'] : someValue }
{ myVar.callFunction() : someValue }
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JEXL-181) Cannot create inline Map with array or function call as the key

[Balazs Zsoldos (JIRA)]

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

Balazs Zsoldos updated JEXL-181:

Description: 
It seems that inline maps can be created only if:

 - the keys are string literals or a numbers
 - the keys are variables

The followings throw exception:

{code}
{ ['1', '2'] : someValue }
{ myVar.callFunction() : someValue }
{code}

Example stacktrace for expression: { 'step'.toString() : [1, 2] }

{code}
org.apache.commons.jexl2.JexlException$Parsing: @1:21 parsing error near '... 
g() : [1,  ...'
 at org.apache.commons.jexl2.JexlEngine.parse(JexlEngine.java:1260)
 at org.apache.commons.jexl2.JexlEngine.createScript(JexlEngine.java:506)
 at 
org.everit.expression.jexl.JexlExpressionCompiler.compile(JexlExpressionCompiler.java:63)
 at 
org.everit.templating.html.internal.HTMLNodeVisitor.compileExpression(HTMLNodeVisitor.java:174)
 at 
org.everit.templating.html.internal.HTMLNodeVisitor.processEhtAttribute(HTMLNodeVisitor.java:406)
 at 
org.everit.templating.html.internal.HTMLNodeVisitor.fillEhtTagNodeWithAttribute(HTMLNodeVisitor.java:190)
 at 
org.everit.templating.html.internal.HTMLNodeVisitor.handleEWTNode(HTMLNodeVisitor.java:270)
 at 
org.everit.templating.html.internal.HTMLNodeVisitor.visitTag(HTMLNodeVisitor.java:634)
 at org.htmlparser.nodes.TagNode.accept(TagNode.java:700)
 at 
org.everit.templating.html.HTMLTemplateCompiler.compile(HTMLTemplateCompiler.java:125)
 at 
biz.everit.therapy.portal.WebTemplateRenderer.(WebTemplateRenderer.java:57)
 at 
biz.everit.therapy.series.demo.DemoSeriesServlet.(DemoSeriesServlet.java:46)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
 at java.lang.Class.newInstance(Class.java:442)
 at 
org.everit.osgi.ecm.component.ri.internal.ComponentContextImpl.starting(ComponentContextImpl.java:760)
 at 
org.everit.osgi.ecm.component.ri.internal.ComponentContextImpl.open(ComponentContextImpl.java:564)
 at 
org.everit.osgi.ecm.component.ri.internal.ComponentContainerImpl.open(ComponentContainerImpl.java:110)
 at 
org.everit.osgi.ecm.extender.ri.internal.ECMCapabilityTracker.addingBundle(ECMCapabilityTracker.java:105)
 at 
org.everit.osgi.ecm.extender.ri.internal.ECMCapabilityTracker.addingBundle(ECMCapabilityTracker.java:44)
 at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)
 at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1)
 at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
 at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
 at 
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
 at 
org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:902)
 at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
 at 
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)
 at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)
 at 
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)
 at org.eclipse.osgi.container.Module.publishEvent(Module.java:466)
 at org.eclipse.osgi.container.Module.start(Module.java:457)
 at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)
 at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:411)
 at 
org.everit.osgi.dev.richconsole.internal.upgrade.UpgradeProcess.finish(UpgradeProcess.java:243)
 at 
org.everit.osgi.dev.richconsole.internal.upgrade.UpgradeServiceImpl.deployBundles(UpgradeServiceImpl.java:116)
 at 
org.everit.osgi.dev.richconsole.internal.BundleDeployerFrame$6$1.run(BundleDeployerFrame.java:242)
 at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.commons.jexl2.parser.ParseException: parse error
 at 
org.apache.commons.jexl2.parser.Parser.generateParseException(Parser.java:3935)
 at 
org.apache.commons.jexl2.parser.Parser.jj_consume_token(Parser.java:3817)
 at org.apache.commons.jexl2.parser.Parser.Block(Parser.java:200)
 at 

[jira] [Resolved] (VFS-559) FTPClientWrapper is not robust against some failures

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels resolved VFS-559.
-
   Resolution: Fixed
 Assignee: Bernd Eckenfels
Fix Version/s: 2.1

Thanks for checking.

> FTPClientWrapper is not robust against some failures
> 
>
> Key: VFS-559
> URL: https://issues.apache.org/jira/browse/VFS-559
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: L
>Assignee: Bernd Eckenfels
> Fix For: 2.1
>
>
> The goal of the class is stated in javadoc:
> A wrapper to the FTPClient to allow automatic reconnect on connection loss.
> A lot of its methods look like :
> try
> {
> do something...
> }
> catch (final IOException e)
> {
> disconnect();
> try to repeat the operation...
> }
> Unfortunately disonnect() can fail for the same reason as the original "do 
> something". In my case it as a "connection reset". So instead of the original 
> exception I was getting more or less the same exception from 
> getFtpClient().quit();
> So the wrapper did not help at all.
> I guess all the disconnect() invocations must also be inside try/catch so 
> that even if disconnect() throws, the method goes on to the next step:  try 
> to repeat the operation...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JEXL-180) Documentation - suggests using float for financials

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029057#comment-15029057
 ] 

Henri Biestro commented on JEXL-180:


Please use the mailing list for such questions. Procedure is at 
https://commons.apache.org/releases/{prepare.html,release.html}



> Documentation - suggests using float for financials
> ---
>
> Key: JEXL-180
> URL: https://issues.apache.org/jira/browse/JEXL-180
> Project: Commons JEXL
>  Issue Type: Bug
>Reporter: Kimball Robinson
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> The examples page:
> https://commons.apache.org/proper/commons-jexl/reference/examples.html
> Uses a Float type to represent dollar amounts.  This is a bad idea--floating 
> point values are not large enough to represent larger transactions and this 
> could teach developers bad habits, especially in enterprise environments.
> At the least you should use the Double class in your example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate

[Sebb (JIRA)]

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

Sebb updated NET-579:
-
Fix Version/s: 3.4

> SSL/TLS SocketClients do not verify the hostname against the certificate
> 
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
>  Labels: security
> Fix For: 3.4
>
> Attachments: NET-579.patch, NET-579_2.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the 
> hostname of the server against the certificate. This means that any valid 
> certificate for any CA in the default trust store will be accepted without 
> error.
> SocketClient should be modified to store the hostname, and 
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating 
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if 
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate

[Sebb (JIRA)]

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

Sebb closed NET-579.


> SSL/TLS SocketClients do not verify the hostname against the certificate
> 
>
> Key: NET-579
> URL: https://issues.apache.org/jira/browse/NET-579
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP, IMAP, POP3, SMTP
>Affects Versions: 3.3
> Environment: Java 1.7 (earlier versions cannot verify the hostname)
>Reporter: Simon Arlott
>Priority: Critical
>  Labels: security
> Fix For: 3.4
>
> Attachments: NET-579.patch, NET-579_2.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Every subclass of SocketClient that does SSL/TLS will never verify the 
> hostname of the server against the certificate. This means that any valid 
> certificate for any CA in the default trust store will be accepted without 
> error.
> SocketClient should be modified to store the hostname, and 
> SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating 
> SSL/TLS.
> Java 1.7 has support for verifying the hostname if 
> SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (VALIDATOR-357) Upgrade BeanUtils

[Sebb (JIRA)]

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

Sebb updated VALIDATOR-357:
---
Fix Version/s: (was: 1.5.0)

> Upgrade BeanUtils
> -
>
> Key: VALIDATOR-357
> URL: https://issues.apache.org/jira/browse/VALIDATOR-357
> Project: Commons Validator
>  Issue Type: New Feature
>  Components: Framework
>Affects Versions: 1.1.3 Release, 1.2.0 Release, 1.3.0 Release, 1.3.1 
> Release, 1.4.0 Release, 1.4.1 Release
>Reporter: David Dillard
>Priority: Minor
>
> Validator 1.41 depends on BeanUtils 1.8.3.  This has a "potential security 
> issue", see 
> http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt
>   Also, see http://www.cvedetails.com/cve-details.php?t=1_id=cve-2014-0114
> Even if this issue doesn't affect Validator, BeanUtils should be upgraded so 
> that issue issue doesn't affect other users of BeanUtils given the screwy way 
> some builders (e.g. Maven) resolve conflicting dependencies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (VALIDATOR-358) Underscores in domain names are not supported

[Sebb (JIRA)]

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

Sebb updated VALIDATOR-358:
---
Fix Version/s: (was: 1.5.0)

> Underscores in domain names are not supported
> -
>
> Key: VALIDATOR-358
> URL: https://issues.apache.org/jira/browse/VALIDATOR-358
> Project: Commons Validator
>  Issue Type: Bug
>  Components: Routines
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: github
>
> Placeholder ticket for https://github.com/apache/commons-validator/pull/3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VFS-291) An zip archive is not properly closed after unzipping. And thous cannot be delted until the JVM dies

[Bernd Eckenfels (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029123#comment-15029123
 ] 

Bernd Eckenfels commented on VFS-291:
-

Adding

getManager().closeFileSystem(fileOne.getFileSystem());

to the test makes it pass on Windows. (in current 2.1-SNAPSHOT trunk).

> An zip archive is not properly closed after unzipping. And thous cannot be 
> delted until the JVM dies
> 
>
> Key: VFS-291
> URL: https://issues.apache.org/jira/browse/VFS-291
> Project: Commons VFS
>  Issue Type: Bug
> Environment: Windows
>Reporter: Roman
>Priority: Critical
>  Labels: patch
> Attachments: AbstractFileObject.java.2.patch, 
> AbstractFileObject.java.patch, FileLockUnitTest.diff, ZipCloseBug.zip, 
> ZipFileObject.java, ZipFileObject.java.patch, vfs-291.diff
>
>
> Open a zip file with the ZipFileObject
> get an inputstream on its content
> try to delete it... 
> it fails.
> I have attached a possible solution to this bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (VFS-291) An zip archive is not properly closed after unzipping. And thous cannot be delted until the JVM dies

[Bernd Eckenfels (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029123#comment-15029123
 ] 

Bernd Eckenfels edited comment on VFS-291 at 11/26/15 5:20 PM:
---

Adding

> getManager().closeFileSystem(fileOne.getFileSystem());

to the test makes it pass on Windows. (in current 2.1-SNAPSHOT trunk).


was (Author: b.eckenfels):
Adding

getManager().closeFileSystem(fileOne.getFileSystem());

to the test makes it pass on Windows. (in current 2.1-SNAPSHOT trunk).

> An zip archive is not properly closed after unzipping. And thous cannot be 
> delted until the JVM dies
> 
>
> Key: VFS-291
> URL: https://issues.apache.org/jira/browse/VFS-291
> Project: Commons VFS
>  Issue Type: Bug
> Environment: Windows
>Reporter: Roman
>Priority: Critical
>  Labels: patch
> Attachments: AbstractFileObject.java.2.patch, 
> AbstractFileObject.java.patch, FileLockUnitTest.diff, ZipCloseBug.zip, 
> ZipFileObject.java, ZipFileObject.java.patch, vfs-291.diff
>
>
> Open a zip file with the ZipFileObject
> get an inputstream on its content
> try to delete it... 
> it fails.
> I have attached a possible solution to this bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (VFS-291) An zip archive is not properly closed after unzipping. And thous cannot be delted until the JVM dies

[Bernd Eckenfels (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029123#comment-15029123
 ] 

Bernd Eckenfels edited comment on VFS-291 at 11/26/15 5:20 PM:
---

Adding

{code}getManager().closeFileSystem(fileOne.getFileSystem());{code}

to the test makes it pass on Windows. (in current 2.1-SNAPSHOT trunk).


was (Author: b.eckenfels):
Adding

> getManager().closeFileSystem(fileOne.getFileSystem());

to the test makes it pass on Windows. (in current 2.1-SNAPSHOT trunk).

> An zip archive is not properly closed after unzipping. And thous cannot be 
> delted until the JVM dies
> 
>
> Key: VFS-291
> URL: https://issues.apache.org/jira/browse/VFS-291
> Project: Commons VFS
>  Issue Type: Bug
> Environment: Windows
>Reporter: Roman
>Priority: Critical
>  Labels: patch
> Attachments: AbstractFileObject.java.2.patch, 
> AbstractFileObject.java.patch, FileLockUnitTest.diff, ZipCloseBug.zip, 
> ZipFileObject.java, ZipFileObject.java.patch, vfs-291.diff
>
>
> Open a zip file with the ZipFileObject
> get an inputstream on its content
> try to delete it... 
> it fails.
> I have attached a possible solution to this bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JEXL-181) Cannot create inline Map with array or function call as the key

[Henri Biestro (JIRA)]

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

Henri Biestro resolved JEXL-181.

   Resolution: Fixed
Fix Version/s: 3.0

This is fixed in 3.0. The following test runs with no error.
{code}

@Test
public void testVariableMap() throws Exception {
JexlScript script = JEXL.createScript("{ ['1', '2'.toString()] : 
someValue }", "someValue");
Object result = script.execute(null, 42);
Assert.assertTrue(result instanceof Map);
Object key = null;
Object value = null;
for(Map.Entry e : ((Map) result).entrySet()) {
key = e.getKey();
value = e.getValue();
break;
}
Object gg = ((Map) result).get(key);
Assert.assertEquals(42, ((Number) gg).intValue());
Assert.assertEquals(value, ((Number) gg).intValue());
}
{code}

> Cannot create inline Map with array or function call as the key
> ---
>
> Key: JEXL-181
> URL: https://issues.apache.org/jira/browse/JEXL-181
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Balazs Zsoldos
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> It seems that inline maps can be created only if:
>  - the keys are string literals or a numbers
>  - the keys are variables
> The followings throw exception:
> {code}
> { ['1', '2'] : someValue }
> { myVar.callFunction() : someValue }
> {code}
> Example stacktrace for expression: { 'step'.toString() : [1, 2] }
> {code}
> org.apache.commons.jexl2.JexlException$Parsing: @1:21 parsing error near '... 
> g() : [1,  ...'
>  at org.apache.commons.jexl2.JexlEngine.parse(JexlEngine.java:1260)
>  at org.apache.commons.jexl2.JexlEngine.createScript(JexlEngine.java:506)
>  at 
> org.everit.expression.jexl.JexlExpressionCompiler.compile(JexlExpressionCompiler.java:63)
>  at 
> org.everit.templating.html.internal.HTMLNodeVisitor.compileExpression(HTMLNodeVisitor.java:174)
>  at 
> org.everit.templating.html.internal.HTMLNodeVisitor.processEhtAttribute(HTMLNodeVisitor.java:406)
>  at 
> org.everit.templating.html.internal.HTMLNodeVisitor.fillEhtTagNodeWithAttribute(HTMLNodeVisitor.java:190)
>  at 
> org.everit.templating.html.internal.HTMLNodeVisitor.handleEWTNode(HTMLNodeVisitor.java:270)
>  at 
> org.everit.templating.html.internal.HTMLNodeVisitor.visitTag(HTMLNodeVisitor.java:634)
>  at org.htmlparser.nodes.TagNode.accept(TagNode.java:700)
>  at 
> org.everit.templating.html.HTMLTemplateCompiler.compile(HTMLTemplateCompiler.java:125)
>  at 
> biz.everit.therapy.portal.WebTemplateRenderer.(WebTemplateRenderer.java:57)
>  at 
> biz.everit.therapy.series.demo.DemoSeriesServlet.(DemoSeriesServlet.java:46)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>  at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>  at java.lang.Class.newInstance(Class.java:442)
>  at 
> org.everit.osgi.ecm.component.ri.internal.ComponentContextImpl.starting(ComponentContextImpl.java:760)
>  at 
> org.everit.osgi.ecm.component.ri.internal.ComponentContextImpl.open(ComponentContextImpl.java:564)
>  at 
> org.everit.osgi.ecm.component.ri.internal.ComponentContainerImpl.open(ComponentContainerImpl.java:110)
>  at 
> org.everit.osgi.ecm.extender.ri.internal.ECMCapabilityTracker.addingBundle(ECMCapabilityTracker.java:105)
>  at 
> org.everit.osgi.ecm.extender.ri.internal.ECMCapabilityTracker.addingBundle(ECMCapabilityTracker.java:44)
>  at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)
>  at 
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:1)
>  at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>  at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>  at 
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
>  at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:902)
>  at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>  at 
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>  at 
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)
>  at 
>