[jira] [Updated] (JEXL-135) using map as script parameter or local variable

2012-07-05 Thread Henri Biestro (JIRA)

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

Henri Biestro updated JEXL-135:
---

Fix Version/s: 2.1.2

 using map as script parameter or local variable
 ---

 Key: JEXL-135
 URL: https://issues.apache.org/jira/browse/JEXL-135
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Henri Biestro
Assignee: Henri Biestro
 Fix For: 2.1.2, 3.0


 On behalf of Tomas Kukosa:
 Hello, 
 I use jexl 2.1.1 and I can not access map passed as a script parameter. 
 When I have the script with 'stat' parameter and following code: 
   var a = state;  ## OK 
   var b = state[3];  ## ERROR 
 the first assignment works OK but the second fails with the reason 'undefined 
 variable state' 
 Also I can see that the interpreter tried to get 'state' variable from 
 context. 
 The same result is seen if parameter is assigned to local variable and then 
 it is accessed through it. 
 Is it a bug or intentional behavior? 
 Regards, 
 Tomas 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (JEXL-135) using map as script parameter or local variable

2012-07-05 Thread Henri Biestro (JIRA)

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

Henri Biestro resolved JEXL-135.


Resolution: Fixed

Committed 1332806.
Fix in parser.jjt, identifiers used in array access expression were not checked 
against local variables.

 using map as script parameter or local variable
 ---

 Key: JEXL-135
 URL: https://issues.apache.org/jira/browse/JEXL-135
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Henri Biestro
Assignee: Henri Biestro
 Fix For: 2.1.2, 3.0


 On behalf of Tomas Kukosa:
 Hello, 
 I use jexl 2.1.1 and I can not access map passed as a script parameter. 
 When I have the script with 'stat' parameter and following code: 
   var a = state;  ## OK 
   var b = state[3];  ## ERROR 
 the first assignment works OK but the second fails with the reason 'undefined 
 variable state' 
 Also I can see that the interpreter tried to get 'state' variable from 
 context. 
 The same result is seen if parameter is assigned to local variable and then 
 it is accessed through it. 
 Is it a bug or intentional behavior? 
 Regards, 
 Tomas 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (JEXL-133) String matching Operator short-hand inspired by CSS3

2012-07-05 Thread Henri Biestro (JIRA)

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

Henri Biestro resolved JEXL-133.


Resolution: Fixed

Added the '=^' as startsWith and '=$' as endsWith operators.
They both work on String and on any class that exposes startsWith/endsWith 
methods (duck-type).

 String matching Operator short-hand inspired by CSS3
 

 Key: JEXL-133
 URL: https://issues.apache.org/jira/browse/JEXL-133
 Project: Commons JEXL
  Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Alfred Reibenschuh
Assignee: Henri Biestro
Priority: Trivial
 Fix For: 3.0


 like the perl inspired shorthand =~, css3 also has some nice shorthands 
 http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors
 for startsWith the shorthand could be expr1 ^= expr2
 for endsWith the shorthand could be expr1 $= expr2
 it could be that the ^= operator already collides with xor and assign 
 which i haven't looked at as of now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-05 Thread Bogdan Drozdowski (JIRA)

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

Bogdan Drozdowski updated NET-468:
--

Attachment: sockclient-proxy4.diff

OK, the last version. This time created with the svn diff command. If you wish 
to receive only such patches, write that on the 
http://commons.apache.org/net/code-standards.html page. If you don't want to 
receive patches, simply disable this functionality or make this JIRA private. 
If you don't like this patch, simply say rejected and don't bother 
explaining. I also have other things to do in my spare time.

 Request for native support for socks proxy routing with Commons net FTP
 ---

 Key: NET-468
 URL: https://issues.apache.org/jira/browse/NET-468
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 1.4, 2.0, 3.0.1, 3.1
 Environment: We use commons net  in out products for all 
 communication to an FTP server. OS : All. No other environment specifications.
Reporter: Ramya Rajendiran
 Attachments: sockclient-proxy3.diff, sockclient-proxy4.diff


 Commons net currently does not natively support connection to an FTP server 
 via a socks proxy. The only way of achieving this would be to work at the 
 socket level as observed here 
 http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM 
 properties socksProxyPort and socksProxyPortHost)
 However, a major side effect of this all connections on this JVM will go 
 through the socks proxy since this setting is at the JVM level. This is 
 sometimes undesirable as the business requirements are such that only certain 
 applications on the JVM need to go through the socks proxy. There are no 
 existing workarounds to conditionally prevent other applications to not be 
 routed through the socks proxy. This makes our application which consumes the 
 commons net unusable for such businesses.
 Providing native support for socks proxy with commons net for FTP, will go a 
 long way in supporting such common scenarios and business continuity. 
 Therefore raising this enhancement request. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-05 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407197#comment-13407197
 ] 

Gary D. Gregory commented on NET-468:
-

Simpler: Read http://commons.apache.org/patches.html

 Request for native support for socks proxy routing with Commons net FTP
 ---

 Key: NET-468
 URL: https://issues.apache.org/jira/browse/NET-468
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 1.4, 2.0, 3.0.1, 3.1
 Environment: We use commons net  in out products for all 
 communication to an FTP server. OS : All. No other environment specifications.
Reporter: Ramya Rajendiran
 Attachments: sockclient-proxy3.diff, sockclient-proxy4.diff


 Commons net currently does not natively support connection to an FTP server 
 via a socks proxy. The only way of achieving this would be to work at the 
 socket level as observed here 
 http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM 
 properties socksProxyPort and socksProxyPortHost)
 However, a major side effect of this all connections on this JVM will go 
 through the socks proxy since this setting is at the JVM level. This is 
 sometimes undesirable as the business requirements are such that only certain 
 applications on the JVM need to go through the socks proxy. There are no 
 existing workarounds to conditionally prevent other applications to not be 
 routed through the socks proxy. This makes our application which consumes the 
 commons net unusable for such businesses.
 Providing native support for socks proxy with commons net for FTP, will go a 
 long way in supporting such common scenarios and business continuity. 
 Therefore raising this enhancement request. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-05 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407198#comment-13407198
 ] 

Gary D. Gregory commented on NET-468:
-

Also: version 3 had a test, which is not in version 4.

 Request for native support for socks proxy routing with Commons net FTP
 ---

 Key: NET-468
 URL: https://issues.apache.org/jira/browse/NET-468
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 1.4, 2.0, 3.0.1, 3.1
 Environment: We use commons net  in out products for all 
 communication to an FTP server. OS : All. No other environment specifications.
Reporter: Ramya Rajendiran
 Attachments: sockclient-proxy3.diff, sockclient-proxy4.diff


 Commons net currently does not natively support connection to an FTP server 
 via a socks proxy. The only way of achieving this would be to work at the 
 socket level as observed here 
 http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM 
 properties socksProxyPort and socksProxyPortHost)
 However, a major side effect of this all connections on this JVM will go 
 through the socks proxy since this setting is at the JVM level. This is 
 sometimes undesirable as the business requirements are such that only certain 
 applications on the JVM need to go through the socks proxy. There are no 
 existing workarounds to conditionally prevent other applications to not be 
 routed through the socks proxy. This makes our application which consumes the 
 commons net unusable for such businesses.
 Providing native support for socks proxy with commons net for FTP, will go a 
 long way in supporting such common scenarios and business continuity. 
 Therefore raising this enhancement request. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira