[jira] Updated: (WW-3115) Provide a way to inject file upload listener for JakartaMultipartRequest

2009-06-01 Thread Dharshana (JIRA)

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

Dharshana updated WW-3115:
--

Attachment: JakartaMultiPartRequest.java

Hello I have herewith attached my modification. Please have a look at it

 Provide a way to inject file upload listener for JakartaMultipartRequest
 

 Key: WW-3115
 URL: https://issues.apache.org/struts/browse/WW-3115
 Project: Struts 2
  Issue Type: Improvement
  Components: Core Interceptors
Affects Versions: 2.1.6
 Environment: ALL
Reporter: Dharshana
Priority: Minor
 Fix For: 2.1.7

 Attachments: JakartaMultiPartRequest.java


 I'd like to have a way to have a configurable upload listener to be used by 
 JakartaMultipartRequest so any application can monitor the progress of a file 
 upload without having to write own uploader classes or using any plugins
 listener can be attached to the uploader on the following lines on per upload 
 basis
88   ServletFileUpload upload = new ServletFileUpload(fac);
89   upload.setSizeMax(maxSize);
 e.g.
 String monitorKey  = request.getParameter(UPLOAD_MONITOR_KEY);
 if (monitorKey  != null){
 //Create a progress listener using the configuration information, this is 
 what I need from this feature request
 ProgressListener progressListener = createProgressListener();
 upload.setProgressListener(progressListener );
 request.getSession.putAttribute(monitorKey  ,progressListener );
//Now the application will be able to monitor the upload progress 
 asynchronously
   
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-3040) Context supplied through convertValue to custom converter is missing many key-value pairs (including ServletContext)

2009-06-01 Thread David Mansfield (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46297#action_46297
 ] 

David Mansfield commented on WW-3040:
-

the valuestack present during type conversions that take place during the 
parametersinterceptor is a fake stack created to prevent some security 
problems.  the fake stack doesn't contain almost any of the things the real 
stack has, including what you need.  

i'm not sure there's a way to get what you're looking for, but for reference, 
here's a previous report similar to yours:

http://jira.opensymphony.com/browse/XW-670

 Context supplied through convertValue to custom converter is missing many 
 key-value pairs (including ServletContext)
 

 Key: WW-3040
 URL: https://issues.apache.org/struts/browse/WW-3040
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.6
 Environment: Windows Vista x64, Tomcat 6.0.18, Eclipse 3.4.1
Reporter: Nikos Andreou

 I recently upgraded from Struts 2.0.11 to 2.1.6. I had a custom date 
 converter class. In the convertValue method, I had the code:
 ServletContext servletContext = (ServletContext) 
 context.get(StrutsStatics.SERVLET_CONTEXT);
 I was getting the servletContext and I was reading a param where I had my 
 date pattern. 
 With 2.0.11, the above code returns the servletContext. With 2.1.6, I get 
 null. Basically, the difference in the context provided through 
 public Object convertValue(Map context, Object value, Class toType) {}
 is this:
 2.0.11
 -
 Key= com.opensymphony.xwork2.dispatcher.HttpServletRequestValue= 
 org.apache.struts2.dispatcher.strutsrequestwrap...@196232
 Key= com.opensymphony.xwork2.ActionContext.localeValue= en_US
 Key= com.opensymphony.xwork2.util.ValueStack.ReportErrorsOnNoProp
 Value= true
 Key= com.opensymphony.xwork2.dispatcher.HttpServletResponseValue= 
 org.apache.catalina.connector.responsefac...@7dde6a
 Key= com.opensymphony.xwork2.ActionContext.nameValue= Transaction2
 Key= com.opensymphony.xwork2.ActionContext.applicationValue= 
 {org.apache.catalina.WELCOME_FILES=[Ljava.lang.String;@2a38be, blah-blah, 
 datePattern=-MM-dd}
 Key= last.property.accessedValue= null
 Key= com.opensymphony.xwork2.dispatcher.ServletContextValue= 
 org.apache.catalina.core.applicationcontextfac...@11656b
 Key= requestValue= 
 {struts.valuestack=com.opensymphony.xwork2.util.ognlvaluest...@13fb657}
 Key= last.bean.accessedValue= null
 Key= parametersValue= {amount=[Ljava.lang.String;@1dc0b6b, 
 transactionType=[Ljava.lang.String;@171c4b5, 
 accountId=[Ljava.lang.String;@2975fa, 
 transactionDate=[Ljava.lang.String;@754c}
 Key= __linkValue= [Ljava.lang.Object;@14e518
 Key= applicationValue= 
 {org.apache.catalina.WELCOME_FILES=[Ljava.lang.String;@2a38be, blah-blah, 
 datePattern=-MM-dd}
 Key= xwork.NullHandler.createNullObjectsValue= true
 Key= current.property.pathValue= null
 Key= conversion.property.fullNameValue= transactionDate
 Key= attrValue= org.apache.struts2.util.attribute...@1cca665
 Key= com.opensymphony.xwork2.ActionContext.sessionValue= {}
 Key= com.opensymphony.xwork2.ActionContext.actionInvocationValue= 
 com.opensymphony.xwork2.defaultactioninvocat...@c03c11
 Key= com.opensymphony.xwork2.util.ValueStack.ValueStackValue= 
 com.opensymphony.xwork2.util.ognlvaluest...@13fb657
 Key= sessionValue= {}
 Key= xwork.MethodAccessor.denyMethodExecutionValue= true
 Key= report.conversion.errorsValue= true
 Key= struts.actionMappingValue= 
 org.apache.struts2.dispatcher.mapper.actionmapp...@a79811
 Key= com.opensymphony.xwork2.ActionContext.parametersValue= 
 {amount=[Ljava.lang.String;@1dc0b6b, 
 transactionType=[Ljava.lang.String;@171c4b5, 
 accountId=[Ljava.lang.String;@2975fa, 
 transactionDate=[Ljava.lang.String;@754c}
 2.1.6
 ---
 Key= com.opensymphony.xwork2.util.ValueStack.ReportErrorsOnNoProp
 Value= true
 Key= xwork.NullHandler.createNullObjectsValue= true
 Key= current.property.pathValue= null
 Key= conversion.property.fullNameValue= transactionDate
 Key= last.property.accessedValue= null
 Key= report.conversion.errorsValue= true
 Key= xwork.MethodAccessor.denyMethodExecutionValue= true
 Key= last.bean.accessedValue= null
 Most key-value pairs are missing and at the moment my code fails to work and 
 I get an exception. I am wondering if this is a known issue and whether there 
 is a workaround. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at error level on IO and user generated errors

2009-06-01 Thread Dave Newton (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46298#action_46298
 ] 

Dave Newton commented on WW-3143:
-

We won't change the error logging levels for non-Struts projects--you'd need to 
file an issue with them (we're not responsible for commons fileupload; don't 
recall where JakartaMultiPartRequest comes from, but it's not Struts).

261/263/311 seem like real errors to me, which your comment seems to back up.

I don't see any issue w/ 318/325, but will wait to see if anybody else does.

Not sure why 228 is at error level; someone else may have a better handle on 
that one.

 JakartaMultiPartRequest and FileUploadInterceptor logging at error level on 
 IO and user generated errors
 --

 Key: WW-3143
 URL: https://issues.apache.org/struts/browse/WW-3143
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.2
 Environment: Tomcat 6.0.18
Reporter: Lucas Nelson

 Having just gone live using the multi-part forms and the 
 FileUploadInterceptor, we are getting noise in the logs coming from I/O 
 errors (eg. read timed out) and user generated errors (eg. file too large). 
 We have a production system where we alert on severe errors (error at fatal 
 on your Logger class). As a short-term measure, we've had to disable the log 
 messages from JakartaMultiPartRequest and FileUploadInterceptor, which is not 
 ideal.
 Would you please consider lowering the log level to at least warning, but 
 preferably lower for:
 (these line numbers are from 2.1.2)
 JakartaMultiPartRequest:138 - logs the exception raised from 
 org.apache.commons.fileupload.FileUploadBase#parseRequest, eg. read timeout
 FileUploadInterceptor:228 - logs each of the previous exception messages that 
 may have occurred.
 FileUploadInterceptor:261 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:263 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:311 - missing file, would seem to require an invalid 
 request
 FileUploadInterceptor:318 - file is over the size limit
 FileUploadInterceptor:325 - file is not one of the permitted content types
 Having those cases create an error for the user is entirely appropriate. 
 Having them log to the application logs is a pain in the butt for a highly 
 loaded production system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-2956) setting devMode value to true causes NullPointerException

2009-06-01 Thread Dave Newton (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46299#action_46299
 ] 

Dave Newton commented on WW-2956:
-

I still have to try with the latest--but just to add:

It's not *just* the Tomcat install directory--it's the app deploy directory. 
Under IntelliJ, for example, if I have a run config that creates an exploded 
app in a directory w/ spaces the error also happens, even though my Tomcat 
install itself isn't on a path with spaces. Same issue, but can get there in 
different ways.

 setting devMode value to true causes NullPointerException
 ---

 Key: WW-2956
 URL: https://issues.apache.org/struts/browse/WW-2956
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.6
 Environment: Windows 2003 Server SP2, JRE 1.6.0_07, Tomcat 6.0.18
Reporter: Semion Oshchepkov
Priority: Blocker
 Fix For: 2.1.7

 Attachments: WW-2956-1.patch, WW-2956.patch


 I enabled devMode in struts2-blank-2.1.6 application and it's caused such 
 deployment exception:
 org.apache.catalina.core.StandardContext filterStart
 SEVERE: Exception starting filter struts2
 java.lang.NullPointerException
   at 
 com.opensymphony.xwork2.util.FileManager$FileRevision.needsReloading(FileManager.java:209)
   at 
 com.opensymphony.xwork2.util.FileManager.fileNeedsReloading(FileManager.java:60)
   at 
 com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.needsReload(XmlConfigurationProvider.java:325)
   at 
 org.apache.struts2.config.StrutsXmlConfigurationProvider.needsReload(StrutsXmlConfigurationProvider.java:168)
   at 
 com.opensymphony.xwork2.config.ConfigurationManager.conditionalReload(ConfigurationManager.java:220)
   at 
 com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:61)
   at 
 org.apache.struts2.dispatcher.Dispatcher.getContainer(Dispatcher.java:774)
   at 
 org.apache.struts2.dispatcher.ng.InitOperations.initStaticContentLoader(InitOperations.java:77)
   at 
 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:49)
   at 
 org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
   at 
 org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
   at 
 org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:108)
   at 
 org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4363)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
   at 
 org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
   at 
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
   at 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
 Also struts2-showcase-2.1.6 (where devMode is default) throws same exception:
 org.apache.catalina.core.StandardWrapperValve invoke
 SEVERE: Servlet.service() for servlet jsp threw exception
 java.lang.NullPointerException
   at 
 com.opensymphony.xwork2.util.FileManager$FileRevision.needsReloading(FileManager.java:209)
   at 
 

[jira] Commented: (WW-3125) Incorrect reflection behavior while parameters setting

2009-06-01 Thread Wes Wannemacher (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46300#action_46300
 ] 

Wes Wannemacher commented on WW-3125:
-

Vladimir, you are going to have to provide more details, if you have both 
methods setMyValue(long) and setMyValue(Long) on your action class, I don't 
think we'd support it. If you are having trouble with the first, we'll need 
more details about which app server, jre, etc. since I can't seem to reproduce.

 Incorrect reflection behavior while parameters setting
 --

 Key: WW-3125
 URL: https://issues.apache.org/struts/browse/WW-3125
 Project: Struts 2
  Issue Type: Bug
  Components: Core Actions
Affects Versions: 2.1.0
 Environment: xwork-2.1.0 struts-2.1.0
Reporter: Vladimir Limansky
 Fix For: 2.1.8


 Incorrect reflection behavior while parameters setting:
 public class MyAction extends ActionSupport {
 void setMyValue(Long value) {//this method is NOT called
 this.value = value;
 }
 }
 public class MyAction extends ActionSupport {
 void setMyValue(long value) {//this method is called
 this.value = value;
 }
 }
 the url is 
 blah-blahmyValue=10
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (WW-3125) Incorrect reflection behavior while parameters setting

2009-06-01 Thread Wes Wannemacher (JIRA)

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

Wes Wannemacher updated WW-3125:


Fix Version/s: (was: 2.1.7)
   2.1.8

bumping while waiting on details.

 Incorrect reflection behavior while parameters setting
 --

 Key: WW-3125
 URL: https://issues.apache.org/struts/browse/WW-3125
 Project: Struts 2
  Issue Type: Bug
  Components: Core Actions
Affects Versions: 2.1.0
 Environment: xwork-2.1.0 struts-2.1.0
Reporter: Vladimir Limansky
 Fix For: 2.1.8


 Incorrect reflection behavior while parameters setting:
 public class MyAction extends ActionSupport {
 void setMyValue(Long value) {//this method is NOT called
 this.value = value;
 }
 }
 public class MyAction extends ActionSupport {
 void setMyValue(long value) {//this method is called
 this.value = value;
 }
 }
 the url is 
 blah-blahmyValue=10
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at error level on IO and user generated errors

2009-06-01 Thread Lucas Nelson (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46302#action_46302
 ] 

Lucas Nelson commented on WW-3143:
--

Would you please double check JakartaMultiPartRequest, I have it coming from:

struts-2.1.2/src/core/src/main/java/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.java

in my source archive, and javadoc'd here:

http://struts.apache.org/2.1.2/struts2-core/apidocs/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.html

 JakartaMultiPartRequest and FileUploadInterceptor logging at error level on 
 IO and user generated errors
 --

 Key: WW-3143
 URL: https://issues.apache.org/struts/browse/WW-3143
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.2
 Environment: Tomcat 6.0.18
Reporter: Lucas Nelson

 Having just gone live using the multi-part forms and the 
 FileUploadInterceptor, we are getting noise in the logs coming from I/O 
 errors (eg. read timed out) and user generated errors (eg. file too large). 
 We have a production system where we alert on severe errors (error at fatal 
 on your Logger class). As a short-term measure, we've had to disable the log 
 messages from JakartaMultiPartRequest and FileUploadInterceptor, which is not 
 ideal.
 Would you please consider lowering the log level to at least warning, but 
 preferably lower for:
 (these line numbers are from 2.1.2)
 JakartaMultiPartRequest:138 - logs the exception raised from 
 org.apache.commons.fileupload.FileUploadBase#parseRequest, eg. read timeout
 FileUploadInterceptor:228 - logs each of the previous exception messages that 
 may have occurred.
 FileUploadInterceptor:261 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:263 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:311 - missing file, would seem to require an invalid 
 request
 FileUploadInterceptor:318 - file is over the size limit
 FileUploadInterceptor:325 - file is not one of the permitted content types
 Having those cases create an error for the user is entirely appropriate. 
 Having them log to the application logs is a pain in the butt for a highly 
 loaded production system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at error level on IO and user generated errors

2009-06-01 Thread Dave Newton (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46303#action_46303
 ] 

Dave Newton commented on WW-3143:
-

Oh, yep, there it is; I finded the wrong thing.

 JakartaMultiPartRequest and FileUploadInterceptor logging at error level on 
 IO and user generated errors
 --

 Key: WW-3143
 URL: https://issues.apache.org/struts/browse/WW-3143
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.2
 Environment: Tomcat 6.0.18
Reporter: Lucas Nelson

 Having just gone live using the multi-part forms and the 
 FileUploadInterceptor, we are getting noise in the logs coming from I/O 
 errors (eg. read timed out) and user generated errors (eg. file too large). 
 We have a production system where we alert on severe errors (error at fatal 
 on your Logger class). As a short-term measure, we've had to disable the log 
 messages from JakartaMultiPartRequest and FileUploadInterceptor, which is not 
 ideal.
 Would you please consider lowering the log level to at least warning, but 
 preferably lower for:
 (these line numbers are from 2.1.2)
 JakartaMultiPartRequest:138 - logs the exception raised from 
 org.apache.commons.fileupload.FileUploadBase#parseRequest, eg. read timeout
 FileUploadInterceptor:228 - logs each of the previous exception messages that 
 may have occurred.
 FileUploadInterceptor:261 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:263 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:311 - missing file, would seem to require an invalid 
 request
 FileUploadInterceptor:318 - file is over the size limit
 FileUploadInterceptor:325 - file is not one of the permitted content types
 Having those cases create an error for the user is entirely appropriate. 
 Having them log to the application logs is a pain in the butt for a highly 
 loaded production system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at error level on IO and user generated errors

2009-06-01 Thread Wes Wannemacher (JIRA)

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

Wes Wannemacher updated WW-3143:


Fix Version/s: 2.1.7

might as well try to squeeze this in

 JakartaMultiPartRequest and FileUploadInterceptor logging at error level on 
 IO and user generated errors
 --

 Key: WW-3143
 URL: https://issues.apache.org/struts/browse/WW-3143
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.2
 Environment: Tomcat 6.0.18
Reporter: Lucas Nelson
 Fix For: 2.1.7


 Having just gone live using the multi-part forms and the 
 FileUploadInterceptor, we are getting noise in the logs coming from I/O 
 errors (eg. read timed out) and user generated errors (eg. file too large). 
 We have a production system where we alert on severe errors (error at fatal 
 on your Logger class). As a short-term measure, we've had to disable the log 
 messages from JakartaMultiPartRequest and FileUploadInterceptor, which is not 
 ideal.
 Would you please consider lowering the log level to at least warning, but 
 preferably lower for:
 (these line numbers are from 2.1.2)
 JakartaMultiPartRequest:138 - logs the exception raised from 
 org.apache.commons.fileupload.FileUploadBase#parseRequest, eg. read timeout
 FileUploadInterceptor:228 - logs each of the previous exception messages that 
 may have occurred.
 FileUploadInterceptor:261 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:263 - would seem to require an invalid HTTP request, 
 was not able to trigger from a browser
 FileUploadInterceptor:311 - missing file, would seem to require an invalid 
 request
 FileUploadInterceptor:318 - file is over the size limit
 FileUploadInterceptor:325 - file is not one of the permitted content types
 Having those cases create an error for the user is entirely appropriate. 
 Having them log to the application logs is a pain in the butt for a highly 
 loaded production system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (WW-3138) DWRValidator not working

2009-06-01 Thread J Alex (JIRA)

[ 
https://issues.apache.org/struts/browse/WW-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=46305#action_46305
 ] 

J Alex commented on WW-3138:


Wes,

Where can i find info on how to submit a patch..i am a newbie to SVN
and building Struts from source and all..but i can attempt one for
this since i know the problem.

Thanks,
Joseph

On Sat, May 30, 2009 at 12:03 AM, Wes Wannemacher (JIRA)


 DWRValidator not working
 

 Key: WW-3138
 URL: https://issues.apache.org/struts/browse/WW-3138
 Project: Struts 2
  Issue Type: Bug
  Components: Other
Affects Versions: 2.1.6
 Environment: Struts2.1.6, tested on Tomcat 6 and WAS 6.1
Reporter: J Alex
 Fix For: 2.1.7


 There are 2 issues , first the DWR validator is not functional  - i.e it 
 fails with a NPE when creating the action proxy.
 ActionProxy proxy = actionProxyFactory.createActionProxy(inv, namespace, 
 mapping.getName(), mapping.getMethod(), true, true);
 This can be resolved by using : 
 ActionProxy proxy = actionProxyFactory.createActionProxy(namespace, 
 mapping.getName(), mapping.getMethod(), ctx); 
 instead.
 Second, the mapping.getMethod() in the above call returns null; shouldn't it 
 be the method attribute specified in Action Mapping? 
 Discussion on this issue is at 
 http://www.nabble.com/DWRValidator-not-working-in-Struts-2.1.6-to23215316.html#a23215316

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (WW-3144) Label tag doesn't use key attribute properly

2009-06-01 Thread Dave Newton (JIRA)
Label tag doesn't use key attribute properly
--

 Key: WW-3144
 URL: https://issues.apache.org/struts/browse/WW-3144
 Project: Struts 2
  Issue Type: Bug
Affects Versions: 2.1.6
Reporter: Dave Newton
Priority: Minor


s:label name=foo/ works
s:label name=foo label=%{getText('foo')}/ works
s:label key=foo/ puts the foo msg into the not-label label.

Positively labelous.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.