[jira] Updated: (WW-3115) Provide a way to inject file upload listener for JakartaMultipartRequest
[ 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)
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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.