date:20121023


[ 
https://issues.apache.org/jira/browse/LANG-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482231#comment-13482231
 ] 

Sebb commented on LANG-836:
---

Thanks, unfortunately the patch breaks binary compatibility.

 StrSubstitutor does not support StringBuilder or CharSequence
 -

 Key: LANG-836
 URL: https://issues.apache.org/jira/browse/LANG-836
 Project: Commons Lang
  Issue Type: Bug
Reporter: Sebb
 Attachments: LANG-836.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COMMONSSITE-72) Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled

Sebb created COMMONSSITE-72:
---

 Summary: Workround for MSITE-646/MSITE-660: relative Javadoc links 
are mangled
 Key: COMMONSSITE-72
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-72
 Project: Commons All
  Issue Type: Improvement
Reporter: Sebb


As reported in FUNCTOR-23, relative links to Javadoc methods are mangled by 
Doxia.

Since absolute links are not mangled, one work-round is to convert all such 
Javadoc links to absolute links. However that causes various problems.

An alternative work-round is to convert links to absolute, but using a fixed 
dummy host name prefix, and then remove the dummy prefix after the output has 
been processed by Doxia.

This is easy to do using the Velocity Macro stylesheet.

See attached patch to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COMMONSSITE-72) Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled


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

Sebb updated COMMONSSITE-72:


Attachment: COMMONSSITE-72.patch

 Workround for MSITE-646/MSITE-660: relative Javadoc links are mangled
 -

 Key: COMMONSSITE-72
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-72
 Project: Commons All
  Issue Type: Improvement
Reporter: Sebb
 Attachments: COMMONSSITE-72.patch


 As reported in FUNCTOR-23, relative links to Javadoc methods are mangled by 
 Doxia.
 Since absolute links are not mangled, one work-round is to convert all such 
 Javadoc links to absolute links. However that causes various problems.
 An alternative work-round is to convert links to absolute, but using a fixed 
 dummy host name prefix, and then remove the dummy prefix after the output has 
 been processed by Doxia.
 This is easy to do using the Velocity Macro stylesheet.
 See attached patch to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods

2012-10-23 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482280#comment-13482280
 ] 

Gilles commented on MATH-757:
-

The class is also more complicated than necessary by having public and 
protected setters for variables that are only set at construction. Removing 
those would allow making the corresponding fields private (and thus getting 
closer to the goal of thread-safety, by immutability).


 ResizableDoubleArray is not thread-safe yet has some synch. methods
 ---

 Key: MATH-757
 URL: https://issues.apache.org/jira/browse/MATH-757
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.1


 ResizableDoubleArray has several synchronised methods, but is not 
 thread-safe, because class variables are not always accessed using the lock.
 Is the class supposed to be thread-safe?
 If so, all accesses (read and write) need to be synch.
 If not, the synch. qualifiers could be dropped.
 In any case, the protected fields need to be made private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (IO-351) The Tailer keeps closing and re-opening file, leads to logs lost while file rotation.

2012-10-23 Thread Wally Qiao (JIRA)

Wally Qiao created IO-351:
-

 Summary: The Tailer keeps closing and re-opening file, leads to 
logs lost while file rotation.
 Key: IO-351
 URL: https://issues.apache.org/jira/browse/IO-351
 Project: Commons IO
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.4
 Environment: Linux/Win
Reporter: Wally Qiao


If reOpen is true, log texts reading lost while file rotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-226) Race condition with OgnlRuntime.getMethod

2012-10-23 Thread Johno Crawford (JIRA)


[ 
https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482354#comment-13482354
 ] 

Johno Crawford commented on OGNL-226:
-

PR with fix at https://github.com/jkuhnert/ognl/pull/4

 Race condition with OgnlRuntime.getMethod
 -

 Key: OGNL-226
 URL: https://issues.apache.org/jira/browse/OGNL-226
 Project: Commons OGNL
  Issue Type: Bug
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Johno Crawford
Priority: Minor
 Attachments: OgnlRuntimeTest.java


 If there are two consecutive calls to OgnlRuntime.getMethod before the result 
 is cached it may erroneously return null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OGNL-226) Race condition with OgnlRuntime.getMethod

2012-10-23 Thread Johno Crawford (JIRA)


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

Johno Crawford updated OGNL-226:


Flags: Patch

 Race condition with OgnlRuntime.getMethod
 -

 Key: OGNL-226
 URL: https://issues.apache.org/jira/browse/OGNL-226
 Project: Commons OGNL
  Issue Type: Bug
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Johno Crawford
Priority: Minor
 Attachments: OgnlRuntimeTest.java


 If there are two consecutive calls to OgnlRuntime.getMethod before the result 
 is cached it may erroneously return null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException

2012-10-23 Thread Charles Honton (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482367#comment-13482367
 ] 

Charles Honton commented on LANG-769:
-

Joshua Bloch's Item 60: Favor the use of standard exceptions (From Effective 
Java) is appropriate here.  I recommend using 
java.lang.UnsupportedOperationException and java.lang.IllegalStateException.  
If you need additional context, use a constructor that sets the detail message. 

 Please restore NotImplementedException and UnhandledException
 -

 Key: LANG-769
 URL: https://issues.apache.org/jira/browse/LANG-769
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.exception.*
Reporter: david cogen
Priority: Minor

 Why were these removed? I found these very useful and used them often. As the 
 version 2.6 api javadoc states, This exception supplements the standard 
 exception classes by providing a more semantically rich description of the 
 problem.
 Just want you to realize that these have found direct use outside the 
 library; not just internal use within commons-lang.
 I will define these missing classes myself, or maybe include both 
 commons-lang and commons-lang3 (but I really don't to do that). It would be 
 very nice to have these back.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException

2012-10-23 Thread Steve Gillam (JIRA)

[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482555#comment-13482555
]

Steve Gillam commented on LANG-769:
---

If we're down to quoting design principles G. Booch is God: An abstraction
denotes the essential characteristics of an object that distinguish it from all
other kinds of object and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer. (Object-Oriented Design With
Applications, Benjamin/Cummings, Menlo Park, California, 1991.)

Exception(NullPointer) (and synonyms) - NullPointerException
UnSupportedOperationException(NotImplemented) (and synonyms) -
NotImplementedException

Is it an abstraction relevant to the community at large? Not counting those in
this thread... .Net, IBM, Google, NetBeans, JBoss, Mozilla...(gave up counting)

Please restore NotImplementedException and UnhandledException
-

Key: LANG-769
URL: https://issues.apache.org/jira/browse/LANG-769
Project: Commons Lang
Issue Type: Improvement
Components: lang.exception.*
Reporter: david cogen
Priority: Minor

[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException


[ 
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482567#comment-13482567
 ] 

Gary Gregory commented on LANG-769:
---

I can see that there can be a subtle difference between 
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in 
favor of adding NotImplementedException back, which could also be named 
{{UnimplementedException }}

 Please restore NotImplementedException and UnhandledException
 -

 Key: LANG-769
 URL: https://issues.apache.org/jira/browse/LANG-769
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.exception.*
Reporter: david cogen
Priority: Minor

 Why were these removed? I found these very useful and used them often. As the 
 version 2.6 api javadoc states, This exception supplements the standard 
 exception classes by providing a more semantically rich description of the 
 problem.
 Just want you to realize that these have found direct use outside the 
 library; not just internal use within commons-lang.
 I will define these missing classes myself, or maybe include both 
 commons-lang and commons-lang3 (but I really don't to do that). It would be 
 very nice to have these back.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (LANG-769) Please restore NotImplementedException and UnhandledException


[ 
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482567#comment-13482567
 ] 

Gary Gregory edited comment on LANG-769 at 10/23/12 6:52 PM:
-

I can see that there can be a subtle difference between 
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in 
favor of adding {{NotImplementedException}} back, which could also be named 
{{UnimplementedException}}

  was (Author: garydgregory):
I can see that there can be a subtle difference between 
{{NotImplementedException}} and {{UnsupportedOperationException}}, so I am in 
favor of adding NotImplementedException back, which could also be named 
{{UnimplementedException }}
  
 Please restore NotImplementedException and UnhandledException
 -

 Key: LANG-769
 URL: https://issues.apache.org/jira/browse/LANG-769
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.exception.*
Reporter: david cogen
Priority: Minor

 Why were these removed? I found these very useful and used them often. As the 
 version 2.6 api javadoc states, This exception supplements the standard 
 exception classes by providing a more semantically rich description of the 
 problem.
 Just want you to realize that these have found direct use outside the 
 library; not just internal use within commons-lang.
 I will define these missing classes myself, or maybe include both 
 commons-lang and commons-lang3 (but I really don't to do that). It would be 
 very nice to have these back.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)


[ 
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482603#comment-13482603
 ] 

Gary Gregory commented on VFS-440:
--

Hi Benjamin,

Thank you, the new patch is easier to look at.

When I test the build with mvn test, it hangs, and I see the following on the 
console:

{noformat}
Running org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase
Sftp server started on port 63772
true
created threads still running:
#1: mainNioProcessor-17 not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#2: mainpool-11-thread-1not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#3: mainConnect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#4: mainThread-24   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#5: mainNioProcessor-13 not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#6: mainConnect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#7: mainThread-26   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#8: mainNioProcessor-14 not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#9: mainConnect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#10: main   Thread-28   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#11: main   NioProcessor-15 not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#12: main   Connect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#13: main   Thread-30   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#14: main   Thread-33   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#15: main   Thread-49   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#16: main   Thread-50   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#17: main   Thread-51   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem

created threads still running:
#1: mainConnect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#2: mainNioProcessor-17 not_a_daemonclass 
java.util.concurrent.ThreadPoolExecutor$Worker
#3: mainfrom nc daemon  class 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$7
#4: mainto nc   daemon  class 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$7
#5: mainConnect thread localhost sessiondaemon  class 
com.jcraft.jsch.Session
#6: mainThread-55   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
#7: mainThread-57   not_a_daemonclass 
org.apache.commons.vfs2.provider.sftp.test.SftpProviderTestCase$MySftpSubsystem
{noformat}

But... I am on Windows. My set up is:

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_35, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_35\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

Is the new test platform independent?

If not, it should be skipped for Windows and if run, it should return an error.

Is the issue that the embedded SFTP server is trying to run the nc command (and 
there is nc.exe on Windows)?

 [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
 -

 Key: VFS-440
 URL: https://issues.apache.org/jira/browse/VFS-440
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Benjamin Piwowarski
Priority: Minor
  Labels: proxy, sftp
 Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff


 What I propose is to add the possibility to connect to a remote SSH server 
 through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for 
 instance
 http://backdrift.org/transparent-proxy-with-ssh
 for a use case.
 This simulates a ProxyCommand where the command is run on a SSH host.
 The patch also contains a test for the new functionality. 
 Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
 {code:java}
 builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
 builder.setProxyCommand(opts,

[jira] [Commented] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes


[ 
https://issues.apache.org/jira/browse/OGNL-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482606#comment-13482606
 ] 

Lukasz Lenart commented on OGNL-224:


Done, I was able to merge the patch into current source code

 Performance - Locking and performance problem with 
 OgnlRuntime.findParameterTypes
 -

 Key: OGNL-224
 URL: https://issues.apache.org/jira/browse/OGNL-224
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Pelladi Gabor
Assignee: Lukasz Lenart
Priority: Minor
  Labels: patch, perfomance
 Attachments: OGNL-224.patch, OgnlRuntimeTest.java


 I am using struts2 and under heavy load (around 100 threads) many threads are 
 in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we 
 use have a generic superclass like:
 public class PersonalCaptureAction extends DataCaptureActionPersonalDTO
 OGNL handles this very bad, it enters
 synchronized (_genericMethodParameterTypesCache)
 all the time, at every property access of the Action. A possible workaround 
 is to introduce another layer of superclass that is not generic.
 I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, 
 but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git 
 tree I found:
 https://github.com/jkuhnert/ognl
 I will attach a patch and a testcase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OGNL-224) Performance - Locking and performance problem with OgnlRuntime.findParameterTypes


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

Lukasz Lenart resolved OGNL-224.


   Resolution: Fixed
Fix Version/s: 3.0

it'll be included with 3.0.6 release

 Performance - Locking and performance problem with 
 OgnlRuntime.findParameterTypes
 -

 Key: OGNL-224
 URL: https://issues.apache.org/jira/browse/OGNL-224
 Project: Commons OGNL
  Issue Type: Improvement
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Pelladi Gabor
Assignee: Lukasz Lenart
Priority: Minor
  Labels: patch, perfomance
 Fix For: 3.0

 Attachments: OGNL-224.patch, OgnlRuntimeTest.java


 I am using struts2 and under heavy load (around 100 threads) many threads are 
 in BLOCKED state because of OgnlRuntime.findParameterTypes(). The actions we 
 use have a generic superclass like:
 public class PersonalCaptureAction extends DataCaptureActionPersonalDTO
 OGNL handles this very bad, it enters
 synchronized (_genericMethodParameterTypesCache)
 all the time, at every property access of the Action. A possible workaround 
 is to introduce another layer of superclass that is not generic.
 I know that in current OGNL trunk (4.0-SNAPSHOT) caching has been rewritten, 
 but Struts2 is using 3.0.5, and maybe it could be fixed as 3.0.6 in the git 
 tree I found:
 https://github.com/jkuhnert/ognl
 I will attach a patch and a testcase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-226) Race condition with OgnlRuntime.getMethod


[ 
https://issues.apache.org/jira/browse/OGNL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482616#comment-13482616
 ] 

Lukasz Lenart commented on OGNL-226:


Pull request accepted, should it be applied to Apache OGNL ?

 Race condition with OgnlRuntime.getMethod
 -

 Key: OGNL-226
 URL: https://issues.apache.org/jira/browse/OGNL-226
 Project: Commons OGNL
  Issue Type: Bug
  Components: Core Runtime
Affects Versions: 3.0
Reporter: Johno Crawford
Priority: Minor
 Attachments: OgnlRuntimeTest.java


 If there are two consecutive calls to OgnlRuntime.getMethod before the result 
 is cached it may erroneously return null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods

2012-10-23 Thread Phil Steitz (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482623#comment-13482623
 ] 

Phil Steitz commented on MATH-757:
--

Good catch on the extraneous should Contract above.  That only has relevance in 
the addElementRolling method, so I would see the above change as safe.

On the other point, I disagree.  This class is by nature mutable - it maintains 
a dynamic data structure.  To make it threadsafe, we would have to protect all 
of the data members.  The protected methods are there to allow subclasses to 
override specific behaviors.  Eliminating mutability of exposed properties 
limits the functionality of the class.  We don't use that mutability now in 
[math], but the class is public and others may use it.  The key point is that 
making things like expansion factor and expansion mode immutable does little / 
nothing to move toward threadsafety, while limiting functionality.

 ResizableDoubleArray is not thread-safe yet has some synch. methods
 ---

 Key: MATH-757
 URL: https://issues.apache.org/jira/browse/MATH-757
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.1


 ResizableDoubleArray has several synchronised methods, but is not 
 thread-safe, because class variables are not always accessed using the lock.
 Is the class supposed to be thread-safe?
 If so, all accesses (read and write) need to be synch.
 If not, the synch. qualifiers could be dropped.
 In any case, the protected fields need to be made private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)

2012-10-23 Thread Benjamin Piwowarski (JIRA)


[ 
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482663#comment-13482663
 ] 

Benjamin Piwowarski commented on VFS-440:
-

Yes, the test should be platform independent (the nc command is built it into 
the SSH test server, so it shouldn't matter whether it is run on Windows or 
not). I will try latter to see what might be wrong. Can you see how many tests 
have been run?

 [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
 -

 Key: VFS-440
 URL: https://issues.apache.org/jira/browse/VFS-440
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Benjamin Piwowarski
Priority: Minor
  Labels: proxy, sftp
 Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff


 What I propose is to add the possibility to connect to a remote SSH server 
 through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for 
 instance
 http://backdrift.org/transparent-proxy-with-ssh
 for a use case.
 This simulates a ProxyCommand where the command is run on a SSH host.
 The patch also contains a test for the new functionality. 
 Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
 {code:java}
 builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
 builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
 builder.setProxyHost(opts, gate.way.host);
 builder.setProxyPort(opts, 22);
 builder.setProxyOptions(opts, proxyOptions);
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (VFS-440) [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)


[ 
https://issues.apache.org/jira/browse/VFS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482666#comment-13482666
 ] 

Gary Gregory commented on VFS-440:
--

Sadly no.

 [SFTP] Stream (e.g. netcat) proxy for Sftp file system (aka ProxyCommand)
 -

 Key: VFS-440
 URL: https://issues.apache.org/jira/browse/VFS-440
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Benjamin Piwowarski
Priority: Minor
  Labels: proxy, sftp
 Attachments: sftp-stream-proxy.diff, sftp-stream-proxy-v2.diff


 What I propose is to add the possibility to connect to a remote SSH server 
 through an SSH connection stream (instead of an HTTP or SOCKS proxy). See for 
 instance
 http://backdrift.org/transparent-proxy-with-ssh
 for a use case.
 This simulates a ProxyCommand where the command is run on a SSH host.
 The patch also contains a test for the new functionality. 
 Example of use (with the netcat command nc -q 0 HOSTNAME PORT)
 {code:java}
 builder.setProxyType(opts, SftpFileSystemConfigBuilder.PROXY_STREAM);
 builder.setProxyCommand(opts, SftpStreamProxy.NETCAT_COMMAND);
 builder.setProxyHost(opts, gate.way.host);
 builder.setProxyPort(opts, 22);
 builder.setProxyOptions(opts, proxyOptions);
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (MATH-882) Complete decomposition solver support in EigenDecomposition for complex eigenvalues

2012-10-23 Thread Thomas Neidhart (JIRA)

Thomas Neidhart created MATH-882:


 Summary: Complete decomposition solver support in 
EigenDecomposition for complex eigenvalues
 Key: MATH-882
 URL: https://issues.apache.org/jira/browse/MATH-882
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.1
Reporter: Thomas Neidhart
 Fix For: 4.0


The current DecompositionSolver in EigenDecomposition only supports real 
eigenvalues. With the recently added support for non-symmetric matrices, also 
complex eigenvalues are possible as result of the decomposition.

In such a case, an MathUnsupportedOperationException is thrown when trying to 
get a DecompositionSolver with getSolver().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (IO-352) Spelling fixes

2012-10-23 Thread JIRA

Ville Skyttä created IO-352:
---

 Summary: Spelling fixes
 Key: IO-352
 URL: https://issues.apache.org/jira/browse/IO-352
 Project: Commons IO
  Issue Type: Improvement
Reporter: Ville Skyttä
Priority: Minor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (LANG-845) Spelling fixes

2012-10-23 Thread JIRA

Ville Skyttä created LANG-845:
-

 Summary: Spelling fixes
 Key: LANG-845
 URL: https://issues.apache.org/jira/browse/LANG-845
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Ville Skyttä
Priority: Minor
 Attachments: 0001-Spelling-fixes.patch



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LANG-845) Spelling fixes

2012-10-23 Thread JIRA


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

Ville Skyttä updated LANG-845:
--

Attachment: 0001-Spelling-fixes.patch

 Spelling fixes
 --

 Key: LANG-845
 URL: https://issues.apache.org/jira/browse/LANG-845
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Ville Skyttä
Priority: Minor
  Labels: patch
 Attachments: 0001-Spelling-fixes.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException

2012-10-23 Thread Steve Gillam (JIRA)

[
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482741#comment-13482741
]

Steve Gillam commented on LANG-769:
---

Disambiguation/Accuracy of the semantic (and, thus, its name) is key here -
otherwise it will quickly lose it's worth and become a valid candidate for
disappearing again (as any such should be).

Whilst Not(Un)Implemented is the most often created it does not communicate the
semantic well and could well be confused with the permanent decision not to
implement an optionalAPI call.

It somehow needs to represent itself (and, thus, the response (human/systemic)
as being a function of the development lifecycle ('You told me you'd
finished!'). Perhaps others cleverer than I can propose a succinct
representation?

Obviously it needs to be a subclass of RuntimeException so we don't have to run
around polluting 'completed' code with throws clauses :)

Please restore NotImplementedException and UnhandledException
-

Key: LANG-769
URL: https://issues.apache.org/jira/browse/LANG-769
Project: Commons Lang
Issue Type: Improvement
Components: lang.exception.*
Reporter: david cogen
Priority: Minor

[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods

2012-10-23 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482806#comment-13482806
 ] 

Gilles commented on MATH-757:
-

Yes, the object is mutable; I actually meant to increase the degree of 
encapsulation by removing some bells and whistles that will hardly be used 
(what kind of situation would need a change of those contraction/expansion 
properties during the lifetime of the object?).
This class represents an array of primitive doubles that can adapt its size. 
Fine, but if CM does not use whatever refinement can be put into such a 
functionality, I don't see why we should maintain an overly complicated object. 
I'd guess that users would not look at CM for this kind of utility (which 
belongs to e.g. Commons Primitives). I can understand the existence of this 
class in CM given the no-dependencies requirement, but that leads us back to my 
point (why maintain functionality beyond what is used internally?). Of course, 
I do not suggest to remove the methods right now; just starting a discussion 
for 4.0. At this time, I'm not even sure that the synchronized keywords can 
be removed (wouldn't it break compatibility?).


 ResizableDoubleArray is not thread-safe yet has some synch. methods
 ---

 Key: MATH-757
 URL: https://issues.apache.org/jira/browse/MATH-757
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.1


 ResizableDoubleArray has several synchronised methods, but is not 
 thread-safe, because class variables are not always accessed using the lock.
 Is the class supposed to be thread-safe?
 If so, all accesses (read and write) need to be synch.
 If not, the synch. qualifiers could be dropped.
 In any case, the protected fields need to be made private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods


[ 
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482823#comment-13482823
 ] 

Sebb commented on MATH-757:
---

The synch. keyword does not affect binary or source compatibility.

 ResizableDoubleArray is not thread-safe yet has some synch. methods
 ---

 Key: MATH-757
 URL: https://issues.apache.org/jira/browse/MATH-757
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.1


 ResizableDoubleArray has several synchronised methods, but is not 
 thread-safe, because class variables are not always accessed using the lock.
 Is the class supposed to be thread-safe?
 If so, all accesses (read and write) need to be synch.
 If not, the synch. qualifiers could be dropped.
 In any case, the protected fields need to be made private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IO-352) Spelling fixes


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

Gary Gregory resolved IO-352.
-

   Resolution: Fixed
Fix Version/s: 2.5

Thank you for the patch. 2 files did not apply cleanly so I excluded those.

{noformat}
commit -m [IO-352] Spelling fixes. (17 paths specified)
SendingC:/svn/org/apache/commons/trunks-proper/io/RELEASE-NOTES.txt
SendingC:/svn/org/apache/commons/trunks-proper/io/build.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/changes/release-notes.vm
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/EndianUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/IOUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/ThreadMonitor.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/ExtensionFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/NameFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/comparator/PathFileComparator.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/filefilter/TrueFileFilter.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/input/ReversedLinesFileReader.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/main/java/org/apache/commons/io/output/ByteArrayOutputStream.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/site/xdoc/mail-lists.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/site/xdoc/upgradeto1_1.xml
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/test/java/org/apache/commons/io/DirectoryWalkerTestCase.java
Sending
C:/svn/org/apache/commons/trunks-proper/io/src/test/java/org/apache/commons/io/DirectoryWalkerTestCaseJava4.java
Transmitting file data ...
Committed revision 1401522.
{noformat}

 Spelling fixes
 --

 Key: IO-352
 URL: https://issues.apache.org/jira/browse/IO-352
 Project: Commons IO
  Issue Type: Improvement
Reporter: Ville Skyttä
Priority: Minor
  Labels: patch
 Fix For: 2.5

 Attachments: 0001-Spelling-fixes.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException


[ 
https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482875#comment-13482875
 ] 

Gary Gregory commented on LANG-769:
---

Interesting, NotImplementedException could mean, not yet or not ever. So 
expressing the intention in the positive could help: {{ToDoException}}, 
{{ToBeImplementedException}}, and the like. I could see usage like {{throw new 
ToDoException(LANG-987);}}

 Please restore NotImplementedException and UnhandledException
 -

 Key: LANG-769
 URL: https://issues.apache.org/jira/browse/LANG-769
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.exception.*
Reporter: david cogen
Priority: Minor

 Why were these removed? I found these very useful and used them often. As the 
 version 2.6 api javadoc states, This exception supplements the standard 
 exception classes by providing a more semantically rich description of the 
 problem.
 Just want you to realize that these have found direct use outside the 
 library; not just internal use within commons-lang.
 I will define these missing classes myself, or maybe include both 
 commons-lang and commons-lang3 (but I really don't to do that). It would be 
 very nice to have these back.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LANG-339) StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanese, etc.


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

Gary Gregory updated LANG-339:
--

Summary: StringEscapeUtils.escapeHtml() escapes multibyte characters like 
Chinese, Japanese, etc.  (was: StringEscapeUtils.escapeHtml() escapes multibyte 
characters like Chinese, Japanes, etc.)

 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, 
 Japanese, etc.
 

 Key: LANG-339
 URL: https://issues.apache.org/jira/browse/LANG-339
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.*
Affects Versions: 2.3
 Environment: Operating System: All
 Platform: All
Reporter: Guo Yong
 Fix For: 3.0


 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, 
 Japanes, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LANG-845) Spelling fixes


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

Gary Gregory resolved LANG-845.
---

   Resolution: Fixed
Fix Version/s: 3.2

Patch applied, thank you! The DateUtilsTest changes did not apply cleanly to 
trunk, so I excluded them.

{noformat}
commit -m [LANG-845] Spelling fixes. (16 paths specified)
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/changes/changes.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/ArrayUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/ClassUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/exception/ExceptionUtils.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/math/Fraction.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/text/StrBuilder.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/text/StrMatcher.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/main/java/org/apache/commons/lang3/time/StopWatch.java
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-1.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-2.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/resources/release-notes/RELEASE-NOTES-3.0.txt
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/developerguide.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/mail-lists.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/upgradeto2_0.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/upgradeto3_0.xml
Sending
C:/svn/org/apache/commons/trunks-proper/lang/src/site/xdoc/userguide.xml
Transmitting file data ...
Committed revision 1401523.
{noformat}

 Spelling fixes
 --

 Key: LANG-845
 URL: https://issues.apache.org/jira/browse/LANG-845
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Ville Skyttä
Priority: Minor
  Labels: patch
 Fix For: 3.2

 Attachments: 0001-Spelling-fixes.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-757) ResizableDoubleArray is not thread-safe yet has some synch. methods

2012-10-23 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482890#comment-13482890
 ] 

Gilles commented on MATH-757:
-

Wouldn't removing it break _usage_: from supposedly thread-safe to definitely 
unsafe?


 ResizableDoubleArray is not thread-safe yet has some synch. methods
 ---

 Key: MATH-757
 URL: https://issues.apache.org/jira/browse/MATH-757
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.1


 ResizableDoubleArray has several synchronised methods, but is not 
 thread-safe, because class variables are not always accessed using the lock.
 Is the class supposed to be thread-safe?
 If so, all accesses (read and write) need to be synch.
 If not, the synch. qualifiers could be dropped.
 In any case, the protected fields need to be made private.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-96) Full exif tag description ?

2012-10-23 Thread Damjan Jovanovic (JIRA)


[ 
https://issues.apache.org/jira/browse/IMAGING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482963#comment-13482963
 ] 

Damjan Jovanovic commented on IMAGING-96:
-

Through what API?

You can already do this:
{code}
TiffDirectory tiffDirectory = ...
int exposureProgram = 
tiffDirectory.getSingleFieldValue(ExifTagConstants.EXIF_TAG_EXPOSURE_PROGRAM);
switch (exposureProgram) {
case EXPOSURE_PROGRAM_VALUE_MANUAL: return manual;
}
{code}

 Full exif tag description  ?
 

 Key: IMAGING-96
 URL: https://issues.apache.org/jira/browse/IMAGING-96
 Project: Commons Imaging
  Issue Type: Question
  Components: Format: JPEG
Reporter: Piotr Czajka

 Is it possible to get a full exif tag description ?
 e.g.
 Simple output from Imaging:
 //...
 ExposureProgram : 1 
 //...
 In exif tagg spec. I found :
 ExposureProgram
 The specification defines these values:
 0 = Not defined
 1 = Manual
 2 = Normal program
 3 = Aperture priority
 4 = Shutter priority
 5 = Creative program (biased toward depth of field)
 6 = Action program (biased toward fast shutter speed)
 7 = Portrait mode (for closeup photos with the background out of focus)
 8 = Landscape mode (for landscape photos with the background in focus) 
 Can I receive description in that form : 
 ExposureProgram : Manual  ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-177) 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-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482964#comment-13482964
 ] 

Lukasz Lenart commented on OGNL-177:


Is it related to WW-3746 ? If so the problem is already solved with OGNL 3.0.5 
- https://github.com/jkuhnert/ognl

 Unable to use Struts 2.3.1.2 application with OGNL 3.0.4 by enabling security 
 manager 
 --

 Key: OGNL-177
 URL: https://issues.apache.org/jira/browse/OGNL-177
 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.java:1)
   at 
 com.sony.sce.producttool.web.CacheFlushFilterInterceptor.callWithHandling(CacheFlushFilterInterceptor.java:79)
   at 
 com.sony.sce.producttool.web.CacheFlushFilterInterceptor.intercept(CacheFlushFilterInterceptor.java:67)
   at 
 com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
   at 
 com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:145)
   at 
 com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
   at

[jira] [Commented] (OGNL-170) OGNL Expression Take CPU of the application High


[ 
https://issues.apache.org/jira/browse/OGNL-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482966#comment-13482966
 ] 

Lukasz Lenart commented on OGNL-170:


Is it still related with the latest version of OGNL 3.x ?

 OGNL Expression Take CPU of the application High
 

 Key: OGNL-170
 URL: https://issues.apache.org/jira/browse/OGNL-170
 Project: Commons OGNL
  Issue Type: Bug
  Components: Infrastructure (website/etc)
 Environment: ALL
Reporter: Kaushik Lakshminarayanan
Assignee: Jesse Kuhnert
Priority: Blocker

 When running Struts with OGNL CPU is buring high.No threads are in Blocked 
 stage.
 We are using 3.0. Please advise latest stable version.
 JSTL is faster when we replace code instead of OGNL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-167) Critical performance issue in production environment as thread dumps are leading to OGNL 3.0 thread blocking! Website could be backed out!


[ 
https://issues.apache.org/jira/browse/OGNL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482971#comment-13482971
 ] 

Lukasz Lenart commented on OGNL-167:


Did you try to use the latest Struts2/OGNL ? The problem should be solved.

 Critical performance issue in production environment as thread dumps are 
 leading to OGNL 3.0 thread blocking! Website could be backed out!
 --

 Key: OGNL-167
 URL: https://issues.apache.org/jira/browse/OGNL-167
 Project: Commons OGNL
  Issue Type: Bug
 Environment: Struts 2.2.1
Reporter: Shishir Kumar Bala
Assignee: Jesse Kuhnert
Priority: Blocker

 My web application based on Struts 2.2.1 is using OGNL 3.0. This web 
 application is rolled into production; however, due to serious performance 
 considerations the website is in danger of being rolled back. The thread 
 dumps indicate 'BLOCKING' at 
 ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804). 
 The thread trace is as:
 quot;httpSSLWorkerThread-6357-6quot; daemon prio=3 tid=0x01a07000 nid=0xa6 
 waiting for monitor entry [0xb6d79000..0xb6d7faf0]
java.lang.Thread.State: BLOCKED (on object monitor)
   at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:804)
   - waiting to lock lt;0xcca6d328gt; (a java.lang.reflect.Method)
   at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434)
   at 
 ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60)
   at 
 ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:147)
   at 
 com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.getProperty(ObjectAccessor.java:17)
   at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230)
   at 
 com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:137)
   at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:2230)
   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 sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
 
 quot;httpSSLWorkerThread-6357-4quot; daemon prio=3 tid=0x01a56800 nid=0xa4 
 runnable [0xb6f79000..0xb6f7fbf0]
java.lang.Thread.State: RUNNABLE
   at java.security.AccessController.$$YJP$$doPrivileged(Native Method)
   at java.security.AccessController.doPrivileged(AccessController.java)
   at 
 com.sun.enterprise.security.provider.PolicyFile.addPermissions(PolicyFile.java:1333)
   at 
 com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1290)
   at 
 com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1256)
   at 
 com.sun.enterprise.security.provider.PolicyFile.getPermissions(PolicyFile.java:1198)
   at 
 com.sun.enterprise.security.provider.PolicyFile.implies(PolicyFile.java:1153)
   at 
 com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:383)
   at 
 com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:237)
   at java.security.ProtectionDomain.implies(ProtectionDomain.java:213)
   at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:301)
   at 
 java.security.AccessController.checkPermission(AccessController.java:546)
   at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
   at 
 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
   at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:839)
   - locked lt;0xcca6d328gt; (a java.lang.reflect.Method)
   at ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:1434)
   at 
 ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:60)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (IMAGING-91) ByteSourceInputStream.streamLength could be a long

2012-10-23 Thread Damjan Jovanovic (JIRA)


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

Damjan Jovanovic resolved IMAGING-91.
-

   Resolution: Fixed
Fix Version/s: 1.0

Thank you, it's fixed now :).

 ByteSourceInputStream.streamLength could be a long
 --

 Key: IMAGING-91
 URL: https://issues.apache.org/jira/browse/IMAGING-91
 Project: Commons Imaging
  Issue Type: Improvement
Reporter: Sebb
Priority: Trivial
 Fix For: 1.0


 ByteSourceInputStream.streamLength is currently a Long.
 Since it has to be positive, it could be converted to an long, e.g. using -1 
 as the equivalent of null.
 This would save some boxing/unboxing and instance creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-185) Performance issue on high load (thread blocking)


[ 
https://issues.apache.org/jira/browse/OGNL-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482977#comment-13482977
 ] 

Lukasz Lenart commented on OGNL-185:


This issue can be closed as the related Struts2 issues was already solved.

 Performance issue on high load (thread blocking)
 

 Key: OGNL-185
 URL: https://issues.apache.org/jira/browse/OGNL-185
 Project: Commons OGNL
  Issue Type: Bug
Reporter: Christian Grobmeier
Assignee: Maurizio Cucchiara
Priority: Critical
 Attachments: thread-dump-lock2.txt, thread-dump-lock.txt


 The Struts project is suffering from an issue occuring from OGNL on heavy 
 load.
 The issue in question (with details) is: 
 https://issues.apache.org/jira/browse/WW-3580
 A similar issues has been reported in the OpenSymphony bugtracker:
 https://issues.apache.org/jira/browse/WW-3580

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OGNL-148) @DatePicker is not working


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

Lukasz Lenart resolved OGNL-148.


Resolution: Invalid

It has nothing to do with OGNL

 @DatePicker is not working
 --

 Key: OGNL-148
 URL: https://issues.apache.org/jira/browse/OGNL-148
 Project: Commons OGNL
  Issue Type: Bug
 Environment: Tapestry 4.1.3
Reporter: adapala venkta
Assignee: Jesse Kuhnert

 Hai, 
   i am facing a problem regarding DatePicker.I am using Tapestry 4.1.3 
 version. 
 When i am using DatePicker alone it is working fine but when i am using 
 inside  FloatingPlane it is giving an Javascript error and it is not 
 working.The error is calendar_DatePicker_7 is undefined  in IE 6 version. 
 Eventhough i cleared the cache in IE the same javascript error is found. 
 The sample code snippet is 
 div jwcid=@Any id=popin dojoType=FloatingPane 
 class=floatingPaneStyle hasShadow=true resizable=false  
 span jwcid=@DatePicker value=ognl:effectiveDate size=12 
 translator=translator:date,pattern=MM/dd/ /
 /div 
 Can anyone give some solution to this problem. 
 Thanks in advance.
 sasidhar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OGNL-153) OGNL is taking too much time while fetching values from stack, when 'mapname.key' is given for fetching values, which map been defined in the action class.


[ 
https://issues.apache.org/jira/browse/OGNL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482979#comment-13482979
 ] 

Lukasz Lenart commented on OGNL-153:


Is it related to Struts 2 ? Did you try to use the latest version ?

 OGNL is taking too much time while fetching values from stack, when 
 'mapname.key' is given for fetching values, which map been defined in the 
 action class.
 ---

 Key: OGNL-153
 URL: https://issues.apache.org/jira/browse/OGNL-153
 Project: Commons OGNL
  Issue Type: Bug
Affects Versions: 2.6.11
Reporter: sujin
Assignee: Jesse Kuhnert

 OGNL is taking too much time while fetching values from stack, when 
 'mapname.key' is given for fetching values, which map been defined in the 
 action class.
 sample:text name=cond.artistName / 
 TPS drastically comes down when map.key is used for fetching values.
 (Has this been fixed or a ptach been provided for this)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OGNL-225) Merge pull request - Avoid creating empty class array