Re: Doubting OGNL
On Sep 12, 2013, at 11:34 AM, Ken McWilliams ken.mcwilli...@gmail.com wrote:
prefix, IE: OGNL: or EL:
I've long argued that %{}, #{}, ${} provides this already, and that this
wrapping should therefore not be optional in preparation for when something
other than %{} might be functional.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: processing of multipart request
On Nov 17, 2012, at 5:13 AM, Fastupload fastupl...@outlook.com wrote: Here are fast upload API usage and performance https://sourceforge.net/p/fastupload/wiki/Performance%20Comparison/ It seems odd that these measurements start at 1MB...is it at least as fast for smaller files? On Nov 17, 2012, at 7:14 AM, Fastupload fastupl...@outlook.com wrote: the Action has to use File object to access multipart data of HTTP request. It doesn't *have* to. I don't recall whether the action property gets set by the core framework or an interceptor, but your plugin can use reflection to find the type that the appropriate setter is expecting, and then set the appropriate type of data. So to fully utilize your plugin, someone would have to include the plugin, possibly reconfigure the interceptor stack, and update the type their action expects. Importantly it should still work when the first two steps have been done, but not yet the third. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
On 7/13/11 5:06 AM, Christian Grobmeier wrote: In addition to that I would like to see another content type in the response then application/json if it is in commented mode, like text/ext-json. Since there's no right answer to what that alternative mime-type should be, I would suggest it be configurable so developers can set it to use whatever response type they want it to have. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
The patch applied is not backwards compatible, and will break existing sites if they upgrade. Both JSONResult and JSONInterceptor support a wrapWithComments parameter...I think it most sensible to put the same parameter on JSONValidationInterceptor. If we don't do that and default it to true, we should add instructions about this change to a new 2.2 - 2.3 upgrade tips wiki page. Lukasz, you committed the patch, would you mind tweaking it? If you don't have time I can probably work up a patch this weekend. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
On 7/10/11 4:34 AM, Christian Grobmeier wrote: Maybe there are other exploits, but only know what you sent as links. And those are saying you need a JSON array because JSON objects are not valid js statements. You clearly didn't read all the links I included, or do your own search as I suggested. The following statements are from another page in that short list of links I included: Yesterday, I blogged about how to steal data from JSON by overriding the Array constructor. Today, we break into Objects too. ... So now you can steal data from any JSON object I just checked: http://api.jquery.com/jQuery.ajax/ jQuery does XHR (wrapped in jqXHR object), but I would not have a clue how I could remove that comments. Then maybe you should find a clue. JavaScript is an incredibly dynamic language. It is a more philosphical debatte. Agreed. The core of the debate are who are the users that we as framework developers should be protecting. I claim that they are the people using the applications built using the framework, not the people developing those applications. You are free to develop insecure tools for those users using this framework if you so choose, but I want you to have to make a concrete decision to do so. Your statement If I care, I can always read the security docs of Struts. illustrates that there are plenty of developers that won't bother to read the docs unless something isn't working as they expect, and therefore if we default to an insecure mechanism, their users' data will be insecure and they won't know anything about it, and at the end of the day the framework will get blamed for it. you should write a page about it I will not claim that the documentation of this feature exists or is clear, but that is a separate question than that of how it should behave. Struts is an open source project. If you think there should be a page that doesn't yet exist, please write it and contribute it. Is the configuration POST or GET by default? The configuration of your struts.xml which specifies the interceptors and result types that your actions will use does not by default include json. If you want to add in those interceptors or results, you should learn how they work, and configure them appropriately. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
If I recall correctly, this was done to help address information leakage. Meaning if you're logged into a web application and also visiting a page on another website, that other page could have a script tag pointing at your web application, resulting in that data being added to the page scope, which other scripts on that page could then read. Having the resulting json data wrapped in a comment prevents that data from being automatically executed by the browser and added to scope, but doesn't prevent valid XHR requests (which enforce the same-host policy) from getting the result, stripping off a few characters and the exec'ing to get the data. So by resolving this issue you've just made all apps built on top of it less secure. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
Below are a few (of many that I found with a simple google search) explaining the issue in detail. Basically the problem is that script / tags don't abide by the same-origin policy, so if your response to a GET request is a valid json object, that data can be fetched by a script tag in pages on other sites, and then sent back to that other site without the user knowing. Wrapping the response in a comment protects that data. -Dale http://directwebremoting.org/blog/joe/2007/03/06/json_is_not_as_safe_as_people_think_it_is_part_2.html http://haacked.com/archive/2009/06/25/json-hijacking.aspx http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx http://www.yuiblog.com/blog/2007/04/10/json-and-browser-security/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Comments in JSON
On 7/9/11 2:36 PM, Christian Grobmeier wrote: - don't use javascript arrays to return as a json string It really doesn't matter if it's an array or object, if it's valid json that the browser will attempt to execute it's vulnerable. - don't use GET as your method I believe that would protect your data from this script tag attack vector. You mentioned to put everything into a js comment. This breaks the protocol definition and will cause jQuery to fail (and probably others). If it's doing XHR, I'm certain you can insert a filter to make it work either way, but making the result configurable doesn't seem to be an unreasonable request. I still suggest that the default behavior is to protect users' data. In addition a Struts json plugin should allow crossdomain ajax by default for POST only, GET should be enabled by user interaction. The plugin doesn't care, it's the configuration that determines when you use the interceptor or result. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Move deprecated plugins to archive
On 6/27/11 10:09 AM, Martin Gainty wrote: I vote leave dojo as un-deprecated Too late. It's been deprecated since the first 2.1 release, and that conversation happened nearly 3 ago: http://struts.1045723.n5.nabble.com/PROPOSAL-Deprecate-or-remove-Dojo-plugin-td3535027.html This conversation is not about whether or not it should be deprecated, but whether or not it should be excised from the first 2.3 release. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Move deprecated plugins to archive
On 6/27/11 9:02 AM, Johannes Geppert wrote: What you all think about moving deprecated plugins to archive for the 2.3 release? And the Dojo plugin... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Unit test error for xwork-core in trunk
On Jun 5, 2011, at 2:37 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: one struts-core instead of struts-core and xwork-core - but we still discussing the best option. For example, should the package structure change drastically? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Unit test error for xwork-core in trunk
On Jun 5, 2011, at 3:09 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: package structure change drastically? Yeah, from com.opensymphony.xwork to org.apache.struts, but that's inevitable sooner or later ... That's a name change but if a 1-1 mapping still not really a structural change. My question is if stuff should be folded together even more, and touches on Dave's question of how to do that w/o losing the non-web users of xwork to a fork of old code. Should we still produce two jars, one struts(w/xwork) and a another a subset xwork (w/o struts)? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Unit test error for xwork-core in trunk
I assume you meant losing instead of using? -Dale On Jun 5, 2011, at 3:17 PM, Dave Newton davelnew...@gmail.com wrote: I'm nervous about using the clean delineation between the web and non-web bits. I like that separation. Dave - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Enhancements to JSON plugin
On 10/15/10 2:21 AM, Lukasz Lenart wrote: https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestI d=12314570 The filter must be public to be accessible by others. I had the same problem, but just listing the open ones that he's reported works, too: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truereporterSelect=specificuserreporter=jafl5272 Of course as soon as I got that the phone rang, so I've yet to look at any of them myself... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Dojo plugin
On 8/21/10 11:51 AM, Dave Newton wrote: Should the Dojo plugin be removed from the distro now? Wasn't it deprecated in 2.1? Doesn't that mean we can just kill it in 2.2? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.2.1 Question
On 7/19/10 1:03 PM, Johannes Geppert wrote: after upgrading a project i get an error Javassist library is missing in classpath! Please add missed dependency! on tomcat. Release notes: * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.2.1] Javassist dependency was excluded in OGNL, you must remember to include it, except when you are lunching an application on JBoss server -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.2.1 Question
On 7/17/10 6:15 PM, Frans Thamura wrote: is this version, we can mix .action and REST? Yes, you can use org.apache.struts2.dispatcher.mapper.PrefixBasedActionMapper to cause different portions of the url space to be mapped to actions/parameters by different action mappers. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.2.0 Vote
On 6/29/10 3:02 PM, Lukasz Lenart wrote: Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [X] General Availability (GA) +1 non-binding. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Velocity?
https://issues.apache.org/jira/browse/WW-3422 upgraded velocity, but it doesn't show any specific motivation for doing so. I'm having difficulty with struts-menu and the most recent velocity engine/tools, so I'm considering backing out that upgrade in my webapp. Does anyone know if there are any issues within struts that are likely to re-emerge due to this change? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Velocity?
On 6/30/10 7:31 PM, Matt Raible wrote: In regards to Struts Menu, I tried to upgrade it to the Velocity 1.5 a couple of years ago, but there was a bug that prevented me from doing so. More details at the following URL: http://issues.appfuse.org/browse/APF-684 http://issues.apache.org/jira/browse/VELOCITY-532 was marked cannot reproduce against the 1.6 codebase, so I'm guessing that wouldn't be an issue with 1.6 (although others may surface). I had been using 1.5 for quite a while, but since I've done such extensive rewriting to the .vm's that I use I assume I've been working around that $velocityCount bug (I recall that I fought it at one point, but don't remember exactly what the resolution was -- the fact I just upgraded from 1.5 instead of from 1.4 seems to indicate at least partial success :-). With the 1.6.3 (/ 2.0 for tools) upgrade it works for a while, then just stops altogether, so I'm assuming it's some sort of engine configuration issue (with the engine not having the right lifespan or somesuch). Rather than tracking it down right now I'm reverting back to 1.5 (unless someone can point to a struts issue that this would re-introduce). -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.2
On 6/23/10 8:43 AM, Lukasz Lenart wrote: Input file does not exist: target/maven-shared-archive-resources/META-INF/DEPENDENCIES~ target/maven-shared-archive-resources/META-INF/LICENSE~ target/maven-shared-archive-resources/META-INF/NOTICE~ Some editors save backup versions of files in filename~...is it possible some of those transient files were committed to a repository, or are listed in some table of contents somewhere? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
current xwork?
I finally figured out how to work around what seemed like an OGNL bug, and in trying to track it down to submit a patch/JIRA issue, found that it's already been fixed by Musachy and checked in last November 6th in the opensymphony xwork svn, (revision 2075). In fact, the method causing me grief has never even been in the apache svn version of xwork. The issue was fixed during cleanup Musachy did as related to this issue: https://issues.apache.org/jira/browse/WW-3306 But we still have no release including that fix. I recognize that I've not helped resolve any outstanding JIRA issues that would help us get 2.2 out the door (and that I've even contributed to the delays as the author one of the 5 remaining unresolved issues that is mostly awaiting unit test code I should have submitted with the issue in the first place (WW-3260) https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12311041versionId=12314680showOpenIssuesOnly=true ) so please don't see this message as just another When's the next release coming? whine. I'm posting this more to ask for people's opinion of the state of the trunk, with the xwork package migration already done. Are there any real regressions? That short list of outstanding issues doesn't appear to include any that would effect me, so is there any real reason for me to avoid just doing a local build and developing against that? Given that I've a workaround in place for this specific bug in the released 2.1.8.1's xwork 2.1.6, is there really any reason to develop against the trunk rather than that release? Has anyone started working on 2.1 - 2.2 upgrade instructions yet? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: New release
Thanks for working on this, Łukasz! -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: New release
Lukasz Lenart wrote: Andreas Joseph Krogh asked: Can you post a link to changes in 3.0? http://jira.opensymphony.com/secure/IssueNavigator.jspa?reset=truepid=10090fixfor=21770 except 145 - I thing it's a work for future 151 and 157 appear to have fixes in the issues...any chance we can incorporate them, too? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google code donation? (was Re: svn commit: r903559 - in /struts/sandbox/trunk/struts2-gxp-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/ap
Lukasz Lenart wrote: What about that code [1], can I include it if author marked for inclusion to ASF? [1] https://issues.apache.org/jira/browse/WW-3260 I'm the author of the code attached to WW-3260 (which is unrelated to the code this thread was previously discussing), and I've also previously filed a CLA. If there's anything else needed from me to clear this code (only one class, IIRC), please let me know. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Documentation versions?
Wendy Smoak wrote: How (technically) would you do that? I don't know. I was hoping someone with knowledge of the wiki export process might be able to help us answer that question. There are fundamental parts of the documentation export process about which I'm not aware -- for example, is it done once at release time, or is this export automated and run periodically? Once the export has happened, is it served via wiki software, or are static pages generated and served from there forward? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2 Documentation - Revised Tutorials
phillips1021 wrote:
I certainly respect everyone's ideas and suggestions and appreciate people
providing feedback.
You're the one doing the work, so you certainly have the right to
disagree with me/us and do it however you'd like. Therefore I won't
respond to stuff that's a matter of opinion, just items I believe to be
false.
2. The published Struts 2 books (Struts In Action, Using Apache Struts
2) don't commonly use the %{ } syntax and most examples published on the web
don't use the %{ } syntax.
I was a reviewer for the latter, and I stressed throughout my reviews
that I thought it would be a better idea to be explicit about the OGNL
expressions. I don't recall the reasoning, but I guess my suggestions
were ignored there, too :-)
5. For better or worse the current widespread usage of Struts 2 by Java
developers is usage that doesn't use %{ } unless necessary.
From where do you derive this conclusion? I've mentioned this
suggestion on the user's list a number of times over the last several
years, and I have often gotten responses of the form I agree, and I
have my whole team do this, etc. So while you may be right, I
certainly hope not, and moreover I don't know how to validate either
conclusion.
6. My plan for these tutorials is after I've taken the user through
common use cases (form submission, validation, use of Service classes, use
of Spring) to have a few tutorials on OGNL.
I guess context is the most important factor. For tutorials it might
make sense to have controlled exposure to complex topics. For
reference examples, though, I think that argument does not hold and we
should still be explicit.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2 Documentation - Revised Tutorials
Musachy Barroso wrote:
I think it would come handy an explanation of why some attributes are
expected to be strings, while other are values, like:
s:input name=somestring /
vs
s:property value=somevalue /
I think in the tutorials, documentation, etc. we should use the %{}
syntax explicitly everyplace. If someone wants a string, for example,
and not to a lookup, it is quite confusing to a new struts user that
they need to change value=FOO to value=%{'FOO'}, but if they're used
to seeing value=%{FOO} then it isn't so confusing.
This also might make the progression from OGNL to JUEL or something else
(should that ever happen :-) cause less of the documentation to break.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork has landed!
I thought we had reached consensus on this back in August: http://old.nabble.com/Re%3A-Let%27s-kill-xwork-%28was-Re%3A-2.1.8-release-%29-p24966742.html -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Chris Pratt wrote: That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. If the link followed in such a way is from one page of the wizard to another, you're right. If the link followed in such a way is to the start wizard page, presumably that (or even in the submission of the first form of a wizard) is where a new conversation is created, so the two windows could be part of two parallel wizards. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: 2.1.8.1: Change in escaping
Chris Pratt wrote: Or even better, add an escape attribute that takes as it's values html, xml, or javascript. It would be very nice to have it be able to properly encode at least single and double quotes in JavaScript as well as HTML and XML, and using a more generic and extensible attribute name is always a good idea. For example, it could even be implemented such that an attribute escape=javascript,xml allows the specification of multiple escape mechanisms including an ordering in which they'll be applied. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: 2.1.8.1: Change in escaping
Musachy Barroso wrote: that sounds good, can someone open a jira ticket so we don't depend on my short term memory :)? I modified https://issues.apache.org/struts/browse/WW-3332 (although there didn't appear to be a way for me to change the resolution, so maybe this was a mistake... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
Chris Pratt wrote:
In the struts.xml file you can use ${} to run an OGNL expression and access
things from the Action (actually the value stack, but we're trying to keep
it simple here)
JSYK, %{} now works as expected in struts.xml.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: deserializable ActionSupport
Lukasz Lenart wrote: As I know, ActionSupport is a part of XWork (common purpose action framework) that is used by example in WebLogic 8.1 to manage multiple tasks with WorkManager - they can be queued and distributed over the network - maybe that was the reason Yet another good reason to leave xwork where it is so that other codebases can continue to use it, and to migrate a fork into the struts2 codebase so we can make changes to it. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: sitemesh problem in 2.1.8
Christian Stone wrote: It isn't a problem if you use the filter bundled with Sitemesh. However, it doesn't work if you use the plugin filters... Does that include com.opensymphony.module.sitemesh.filter.PageFilter ? I use .jsp decorators and use s: tags within them (by putting the sitemesh filter in between the StrutsPrepareFilter / StrutsExecuteFilter pair). -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: sitemesh problem in 2.1.8
I use struts 2.1.8 with freemarker 2.3.15 and sitemesh 2.4.2...I haven't witnessed any problems, but besides the freemarker that struts uses to expand tags I don't use freemarker in my project. Are there issues that I've not noticed, or do those issues only arise when using freemarker more exetensively? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Bug: Struts 2.1.8 and multipart/form-data
Alex Siman wrote: I use [2.1.8]. Just read the version of Struts in a Subject of this thread. Whoops--my bad. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Bug: Struts 2.1.8 and multipart/form-data
Alex Siman wrote: The issue has gone away, after I removed plugin [struts2-fileupload-plugin-2.1.7-SNAPSHOT.jar]. But this plugin works correctly w/ Struts 2.1.6. And how about 2.1.8? If you haven't event checked it against the released version it's not fair to make someone else go track it down for you. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: How to get value of tag attribute from OGNL?
Alex Siman wrote: I switched off the JSTL-EL (as it was recomended in Struts2 wiki) Can you please point me to that? Seems quite strange to me... Read the section JSP 2.1 here: http://struts.apache.org/2.1.8/docs/ognl.html That was added by Ted Husted on 3/23/2007. What are the problems that this addresses? It seems that the cure is worse than the disease of having to escape a few #'s here and there (none in my codebase), especially after we've since restricted all the struts tags with rtexprvalue=false... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: How to get value of tag attribute from OGNL?
Musachy Barroso wrote:
that's only a problem for defining maps in ognl, which used the
#{a:b} syntax, which made the jstl el complain. The solution is just
to use the alternative map syntax:
#...@java.util.linkedhashmap@{ foo : foo value, bar : bar value }
http://www.opensymphony.com/ognl/html/LanguageGuide/collectionConstruction.html#mapConstruction
I have places in my current codebase where I use the #{a:b} syntax
without issue. Does jstl-el not complain because I added those since
the rtexprvalue=false change? If so, anyone mind if I remove that
portion of the wiki page (replacing it with a link to the ognl
mapContruction link)?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: How to get value of tag attribute from OGNL?
Musachy Barroso wrote: hum, yeah after rtexprvalue=false it should work fine, please edit the wiki :) Done. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.1.8 Vote
On Thu, Sep 24, 2009 at 1:03 PM, Wes Wannemacher w...@wantii.com wrote: There is a brief summary of the 'new' things. http://cwiki.apache.org/WW/version-notes-218.html Here is a link on that page to see everything that has been fixed since 2.1.6... https://issues.apache.org/struts/secure/ReleaseNote.jspa?projectId=10030styleName=Htmlversion=21920 My eyes started to glaze over partway through the second link, and I wonder if I missed anything important...does anyone think that there's something on that second page that should be on the first but is not? -Dale P.S.: I wonder about the query that generates that report...specifically https://issues.apache.org/struts/browse/WW-3105 is listed, but that ticket has Resolution: Won't Fix... - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
2.1 - 2.2 ?
Musachy Barroso (JIRA) wrote: Musachy Barroso updated WW-3260: Fix Version/s: 2.1.9 Assuming that 2.1.8 becomes GA, and we're able to get the xwork code base through the IP clearance process, are we planning on continuing development on 2.1, or are we planning on switching to 2.2 so we can eliminate the external xwork dependency? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork 2.1.6 released
On Saturday 19 September 2009 09:41:06 am Rainer Hermanns wrote: finally done, XWork 2.1.6 is on its way to the mirrors and should be available soon... Any release notes of note? http://jira.opensymphony.com/secure/ReleaseNote.jspa?version=21826styleName=HtmlprojectId=10050Create=Create doesn't seem to suggest anything that should require changes other than a .jar replacement... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts 2.1.8 Vote
This build includes commons-logging-1.0.4 and commons-digester-2.0. Digester 2.0 (while it says It is also possible to use Logging 1.0.x) has commons-logging-1.1.1 as a recommended dependency. (and commons-logging-api-1.1, which presumably should also be commons-logging-api-1.1.1) I don't think this is a big deal, but I figured it was worth asking... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
[OT] Was Re: Class reloading
Martin Gainty wrote: a small flood a few weeks back when my HW tank blew..not fun http://newfield.org/dale/flood/ -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [OT] Was Re: Class reloading
Chris Pratt wrote: Holy Carp! How big is your water heater? =9^D Funny you should mention that--yes, I've been finding dead fish all over the place. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Wes Wannemacher wrote: @Dale - which container / JDK are you running when you get the error? I was using glassfish / 1.5 (on a mac PPC, so no 1.6 available), and while I *think* I saw the error on a clean launch of glassfish, I *know* I saw it on a redeploy. I did have a completely screwed up struts filter setup in my web.xml at the time, though...(and since I added a setting in my struts.properties that masks the problem -- when next I test I'll remove that setting). Can you try the newer jars from the nightly build? I'm digging out from yesterday's flooding, so not yet. I'll let y'all know when I've tested it. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Maven version
Wes Wannemacher wrote: if you build with maven 2.0.x the unit test in the embedded JSP plugin will fail... But, if you are using 2.2.1, the test succeeds. Using java5 instead of java6 will result in the same symptom. Do you know what version of java hudson or bamboo compile with? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso musa...@gmail.com wrote: did you figure it out? My current web app has been having severe issues, and has been broken for about a month (half the time I was out of town, so it's not as bad as it sounds :-). In trying to back out a number of changes to track down the source of my problems, I think I found a bug in your documentation: http://cwiki.apache.org/confluence/display/WW/Spring+Plugin says that struts.class.reloading.reloadConfig defaults to false, but I found not specifying led to the context failing to start with the following message: com.opensymphony.xwork2.inject.ContainerImpl$MissingDependencyException: No mapping found for dependency [type=java.lang.String, name='struts.class.reloading.reloadConfig'] in public org.apache.struts2.spring.StrutsSpringObjectFactory(java.lang.String,java.lang.String,java.lang.String,javax.servlet.ServletContext,java.lang.String,java.lang.String,java.lang.String,java.lang.String). So I'm thinking it doesn't actually have a default value. (yes, I'm using xwork and struts2 SNAPSHOT updated today, and since I'm on an apple still running 10.4, I don't have java6, so it took some pom hacking just to get it to compile). -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: that's weird, it is defined in struts-plugin.xml in the spring plugin. Can you check if you have it there? It is there: constant name=struts.class.reloading.reloadConfig value=false / Does it matter that I've been setting these values in a struts.properties file instead of through XML? I don't know what's going on. I just know that I'm spinning my wheels like crazy trying to get stuff working again. Serves me right for not doing more frequent svn commits, I guess :-( -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: that should not matter, maybe it is not loading your .properties file. It is loading it, because once I added a value (false) in my .properties file it got past that error and began to load. I'm not claiming that class reloading isn't working. I'm not claiming that struts2 isn't working. I'm saying I don't use maven, but rather ant so updating dependencies can be tricky. Between a failed ACEGI - Spring Security upgrade, some changes attempting to make the login accept username or email address, a bunch of other dependency updates, code updates, switching to 2.1.8-SNAPSHOT, changing from org.apache.struts2.dispatcher.FilterDispatcher/ActionContextCleanUp to org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/StrutsPrepareFilter, and who knows what other changes I've managed to completely break my application. I'm attempting to back out various of those changes to get it working again (and was just trying to turn off the reloading bit so that I knew that had nothing to do with it), but I can't even display the login form right now. Make sure you do an mvn clean install..just to satisfy the maven dark gods I did have to skip the tests to get xwork to compile, too--now that I think about the error I bet it was a java5/java6 thing, too... http://www.codeodor.com/images/works-on-my-machine-starburst.png :) Yeah. I guess it would be nice if xwork/struts HEAD could get released (and hopefully go GA) so I would know my java5 compilation environment isn't screwing up anything important. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Clearly my attempt at clarification has failed (by 1 character!), as
it's needed much restating to be precise (and accurate :-). Let me try
this again:
Struts 2.{0,1} branch depends upon external xwork with (mostly)
non-matching version numbers
Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
Struts 2.2.x is proposed to depend upon a forked, internal jar named
struts2-xwork that will get generated as another artifact within the
struts2 release, and thus will share version numbers with struts2.2
releases.
Struts 3.x is proposed to not depend upon any xwork component, as the
two codebases will be merged into one.
Is there any dissent from this plan?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Move JSON plugin to trunk
Musachy Barroso wrote: I think the JSON plugin is ready to be moved to trunk, here is my +1. (non-committer's non-binding) +1 -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: I added struts.class.reloading.acceptClasses, so now I can make the reloading class loader handle only action classes, so I don't get ClassCastException(s) I also added support for the relative paths, @Dale, take it for a spin and let me know how it works. I don't think I've yet managed to see this work :-( Initializing Struts-Spring integration... Watching [/CORRECT_PATH_TO_DEPLOYED_APP/WEB-INF/classes/com/MUMBLE/webapp/action] for changes Class reloading is enabled. Make sure this is not used on a production environment! Change detected in file [/CORRECT_PATH_TO_DEPLOYED_APP/WEB-INF/classes/com/MUMBLE/webapp/action], reloading class loader It detects a change right out of the gate, but never appears to do so again... ...have others successfully tested this new functionality? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: I am, I am using it with convention and spring. Of course I meant anyone other than you -- I assumed you had it working, or you wouldn't have checked it in :-) if you touch the files, do you see any message about detecting a change? No. Should that detection/reload happen even if there are currently no active requests, or will it only notice when the next request comes in? (No, in my case it doesn't notice then, either.) -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: touche :). The FAM starts a thread that watches the dir, so it will callback ClassReloadingXMLWebApplicationContext.onFileChange as soon as a file is changed(set a breakpoint there and see if it is stopping, there is also a log statement there). I included a log message generated from there in my previous post. It does get called as soon as the spring context is set up, but never again. Are you using relative or absolute paths for struts.class.reloading.watchList? I haven't tested relative paths yet. I'm using relative paths. I've been trying to test changes to my app by just copying the new .class file over the old one, but it doesn't seem to get noticed. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
Musachy Barroso musa...@gmail.com wrote: With the bytecode stuff out the way I am inclined to just upgrade to 2.7.3 at once, and upgrade freemarker also. +1 -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: Dale, take it for a spin and let me know how it works. Sorry I've been banging my head against JNI stuff and not working on the web side of my current application lately, so I've not yet gotten a chance to test any of this... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: I could test the path as an absolute path, if it exist, use it, otherwise try it as a relative path to context root, sounds good? Almost. The File interface can tell you whether or not a given instance (path) isAbsolute(). Clearly if the (absolute or relative) file does not exist it should not be loaded, but existence shouldn't help you decide which way to interpret the path. This does bring up the question: If the given (.class or .jar) file does not exist at deployment time, will creation of it/changes to it later trigger reloading? Either way, just to avoid confusion that bit of info should be added to the documentation. (Hrm--looking at FilesystemAlterationListener and ClassReloadingXMLWebApplicationContext suggests that if the file exists at deployment time we should notice in onFileChange as you currently do, but if it did not exist (and we want to support later adding of classes/jars) we could be paying attention to onFileCreate/onDirectoryCreate events, too.) Oh, and once again: Musachy++ Lately it seems like Struts is improving more due to the heroic effort of a few individuals than as a result of a community effort. (I have a feeling that this has fairly consistently been the case throughout the lifetime of struts v1 and v2.) I'm happy that struts is improving, so I'm not trying to discourage heroic effort, but I'm wondering if anyone has any suggestions for how to get more involvement? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: Ok I committed my changes to the spring plugin, Now I'm looking forward even more to 2.1.8 :-) * Set struts.class.reloading.watchList to a comma separated list of directories, or jar files (absolute paths) Does that have to be absolutely absolute? Meaning this must know the deployment directory? Any way to make relative paths be relative to the context root, so you can just add 'WEB-INF/classes' without knowing the deployment path? (Sorry to nit pick, I'm excited about this, just trying to make it easy to use, too :-). -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Class reloading
Musachy Barroso wrote: I get my action classes reloaded after compilation, from jar files and normal dirs. If anyone is interested I could add this to the Spring plugin That seems great, but something that should only kick in if devMode is true. Is that possible? -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: confused about OGNL
Musachy Barroso wrote: It seems like we wont be able to use the new OGNL byte code Oh, well. I think it's been too long since you've received public kudos, Musachy, for all the work you've put in of late to support the struts community: Musachy++! -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: confused about OGNL
Musachy Barroso wrote: OGNL 2.7 can compile expressions into java code which gives a very nice performance boost, so I am big +1 for upgrading. I am trying to figure if the changes in 2.6 mate it into 2.7 or not. alias svndiff='svn diff --diff-cmd /usr/bin/diff --extensions -u -b -B -w' svndiff http://svn.opensymphony.com/svn/ognl/tags/ognl_2-6-10 http://svn.opensymphony.com/svn/ognl/tags/ognl_2-6-11 | less I believe that this shows a single semantic change to a .java file, and I believe that the contents of the block that had synchronized (method) added around it in the 2.6.10 - 2.6.11 transition also is synchronized the same way in 2.7.2. This is not a comprehensive comparison, but it appears to indicate that the answer to your question might be yes. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: confused about OGNL
Musachy Barroso wrote: I did some more checking and it looks good. I would say after 2.1.8 gets released, we create the 2.1 branch and start working on 2.2, which would use OGNL 2.7, how does that sound? I'm gonna start using 2.7(.3) now. I think I had reverted from 2.7 to 2.6 as a result of this exchange: http://www.nabble.com/Slow-performance-with-Struts2-td18092204.html . I thought we were already updating lots of other dependencies for 2.1.8? I understand that there might be code changes in struts that would allow us to benefit from some of the speedups in 2.7 (which would best go into 2.2), but if it neither breaks anything nor slows anything down with just a jar change, any reason to wait? (Your caching issue is one, but adding that doNotCache flag seems like a reasonable workaround for now...) -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts 2.1.7 Vote
Al Sutton wrote: ** Out of date jars (newer versions may have bug fixes which would be useful) ** commons-io-1.3.2 (There is a 1.4, but I'm not sure of API compatibility). http://commons.apache.org/io/upgradeto1_4.html says: Compatibility with 1.3.2 Binary compatible - Yes Source compatible - Yes Semantic compatible - Yes Check the bug fixes section for semantic bug fixes Commons IO 1.4 introduces four new implementations which depend on JDK 1.4 features (CharSequenceReader, FileWriterWithEncoding, IOExceptionWithCause and RegexFileFilter). It has been built with the JDK source and target options set to JDK 1.3 and, except for those implementations, can be used with JDK 1.3 (see IO IO-127). So while I've not yet tested it, it sounds like we should be able to jump to 1.4 if we're moving at all. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: getting to 2.1.7
Philip Luppens wrote: You should file a CLA (contact Martin C. for that or check out the pages at the Apache site). I'm pretty sure I faxed in one of these like 6-9 months ago, but never heard any followup... -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: getting to 2.1.7
Martin Cooper wrote: I've confirmed that an iCLA is on file for you, and have given you corresponding access to the wiki. Thanks! -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: getting to 2.1.7
Chris Pratt wrote:
Using Thread.wait()/Thread.notify() comes to mind.
wait() and notify() are methods of Object, and are what I'm looking for.
Thread happens to be a class object and therefore you can call
Thread.wait()/Thread.notify() but it probably won't be the
synchronization you're looking for.
I think the following patches are the right ones, but beware: while I've
confirmed this compiles, I have yet to test it.
+ protected boolean initializationComplete = false;
+ private Object lock = new Object(); // used for synchronization
public OpenSessionBackgroundProcess(String name, ActionInvocation
invocation, int threadPriority, SessionFactory factory) {
super(name, invocation, threadPriority);
sessionFactory = factory;
+initializationComplete = true;
+synchronized (lock) {
+ lock.notify();
+}
}
@Override
protected void beforeInvocation() throws Exception {
+while (!initializationComplete) {
+ try {
+synchronized (lock) {
+ lock.wait(100);
+}
+ } catch (InterruptedException e) {
+// behavior ignores cause of re-awakening.
+ }
+}
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: getting to 2.1.7
I don't know if running a static code analysis tool over the codebase is part of the release process (getting ready for 2.1.7), so just for the hell of it I just ran struts2 trunk through findbugs. It found 37 bugs. Most of them are not bugs (but rather not quite best practices), but many could be easily addressed. The patches attached to https://issues.apache.org/struts/browse/WW-3102 address those that didn't require too much domain knowledge :-). I *believe* that the patches don't have any semantic effect on the codebase (except maybe to improve bugs in obscure log messages), and they reduce the number of issues raised by findbugs from 37 to 11. One issue findbugs points out is that the BackgroundProcess constructor starts it's thread before returning, which means that any subclass won't get to finish it's constructor before the thread is started. This is relevant to the solution offered at http://cwiki.apache.org/WW/hibernateandspringenabledexecuteandwaitinterceptor.html and I'm not sure if it's really an issue or how to fix it (but I'm interested since I use something like that in my current project :-). -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: getting to 2.1.7
Wes Wannemacher wrote: One issue findbugs points out is that the BackgroundProcess constructor starts it's thread before returning, which means that any subclass won't get to finish it's constructor before the thread is started. This is relevant to the solution offered at http://cwiki.apache.org/WW/hibernateandspringenabledexecuteandwaitintercept or.html and I'm not sure if it's really an issue or how to fix it (but I'm interested since I use something like that in my current project :-). I'm looking at BackgroundProcess and it looks like the only thing that happens after .start() is some exception handling logic... I'm not sure as I haven't had to deal with multithreading issues for a long time (and I don't even think I was using Java the last time I had to think about it). But, it doesn't seem like a real issue to me. Of course, I'd concede if someone more fluent jumped in and pointed out that I'm wrong. After looking at this a bit more I believe that the struts2 code is correct, but that OpenSessionBackgroundProcess on that wiki page has a race condition. The problem is that the constructor of this object starts another thread that immediately starts interacting with this object, potentially before this object's constructor is even done running. As you said, t.start() is the last thing that happens in the constructor of BackgroundProcess, but the one line left in the constructor of OpenSessionBackgroundProcess is recording a useful piece of information (sessionFactory) that is assumed to already be set at the beginning of beforeInvocation(), but might not be set yet when beforeInvocation is invoked. I believe the dumb fix is as simple as adding a member initialized to OpenSessionBackgroundProcess that starts at false and is set to true as the new last line of OpenSessionBackgroundProcesssessionFactory's constructor, and adding a busy-wait loop at the beginning of beforeInvocation() that calls Thread.yield() until the initialized field goes true. I'm certain that there's a better solution than a busy-wait loop, but it's past my bed time, so I'll think about that more in the morning. The obvious solution (synchronized methods) won't work to avoid simultaneous execution of both the constructor and beforeInvocation, because a constructor cannot be synchronized. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSON plugin 0.33 and Struts 2.1.6 (integrated with Spring 2.5)
Gregory Slonim wrote:
interceptor-ref name=json
param name=enableSMDtrue/param
/interceptor-ref
Is this a stack defined elsewhere or just a single interceptor? If the
latter, you're not *adding* this interceptor, you're using *just* this
interceptor.
public final ListString getPayPlanTypes()
{
return payPlanTypes;
}
public final void setPayPlanTypes(ListString payPlanTypes)
{
this.payPlanTypes = payPlanTypes;
}
I recognize that final for methods is an attempt to make this
not-over-ridable, but I wonder if that's not causing grief. (Maybe the
compiler is in-lining them, but that means it's not visible in the
reflection api that's used to find the appropriate attributes?)
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSON plugin 0.33 and Struts 2.1.6 (integrated with Spring 2.5)
Dave Newton wrote:
Dale Newfield wrote:
public final ListString getPayPlanTypes() {
return payPlanTypes;
}
public final void setPayPlanTypes(ListString payPlanTypes) {
this.payPlanTypes = payPlanTypes;
}
I recognize that final for methods is an attempt to make this
not-over-ridable, but I wonder if that's not causing grief. (Maybe
the compiler is in-lining them, but that means it's not visible in the
reflection api that's used to find the appropriate attributes?)
?!
Is that true? I've never seen or heard anything like that before; that
seems like it would completely break everything JavaBean-ish ever.
I have no idea. I was just throwing out random theories of what might
have been causing this guy grief. Since he was getting a valid value
for this attribute ([] although he was expecting ['TEST1', 'TEST2'])
I think I'm wrong here. Sounds like you *know* that I'm wrong here, so
I'll withdraw the idea as bone-headed :-) (But if the action class is
somehow hidden in his call stack by a proxy class through AOP or
something, maybe?)
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: [struts-dev] [PROPOSAL] Deprecate or remove Dojo plugin
Frank W. Zammetti wrote: Think about all you're taking for granted when you write $(#content).load(url); It largely boils down to differences between how developers think the dom/language works and how it really works. The time it takes to have your developers watch Crockford's three lectures is *well* worth it. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote: Fair enough. My only other issue with this extra try/catch block is that it seems too broad. The inner catch is for Exception, which I think means the outer catch for IOException can never be triggered... The URI constructor of File says the argument must be An absolute, hierarchical URI with a scheme equal to file, a non-empty path component, and undefined authority, query, and fragment components and if not, it throws IllegalArgumentException. We're still not checking all those conditions, so if it's a bad URI getting handed to the File constructor that we're trying to protect ourselves from, making that catch specific for IllegalArgumentException seems like a good choice. At least if it were trimmed down to RuntimeException, then a valid IOException would get out of the inner try/catch block appropriately... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote:
I think file.equalsIgnoreCase(uri.getScheme()) already covers that,
doesn't it?
No. All that checks is that it has a scheme (and is thus not relative),
and that scheme is file.
Here's the values returned by that iterator for my app running under
glassfish on XP:
file:/C:/Sun/SDK/
file:/C:/Sun/SDK/domains/domain1/lib/classes/
file:/C:/Sun/SDK/domains/domain1/applications/j2ee-modules/myApp/WEB-INF/classes/
file:C:/Sun/SDK/domains/domain1/generated/ejb/j2ee-modules/myApp/
They are all file: urls, but since the last one is missing a slash
before C:, the File constructor fails complaining URI is not
hierarchical. According to the URI javadoc: A hierarchical URI is
either an absolute URI whose scheme-specific part begins with a slash
character, or a relative URI, that is, a URI that does not specify a
scheme. Since it also says that An opaque URI is an absolute URI
whose scheme-specific part does not begin with a slash character
('/')., then ensuring that it is also not opaque will ensure that it is
hierarchical, and thus that File won't barf on it.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote: Yes, try/catching errors there is a good idea. I will fix it, and log the exception. Thank you for adding that. Can I lobby you also modify your make sure it's a file uri check to be make sure it's a non-opaque file uri? (I.E.: Also check for !uri.isOpaque() .) This will prevent a bunch of cryptic stack traces from entering the logs (possibly MANY times) for many users. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classpath issues...
I recognize that this isn't specifically an xwork question, but I'm investigating a bug that's tickled by xwork code, and I was hoping someone might be able to point to where I should be asking this question... I'm trying to get my struts2 app running under Sun's glassfish distribution on a windows box (XP, SP3). Pages seem to render fine when not logged in, but when logged in instead I wind up with pages and pages of exceptions, seemingly all rooted in an exception (URI is not hierarchical) thrown at com.opensymphony.xwork2.validator.DefaultValidatorFactory.parseValidators (Possibly due to an additional component only included for logged-in users, which happens to include a form that is being added to the page in a recursively called .tag file.) I had thought that the patch applied for XW-611 is what uncovered the problem, but I just tested rolling back that change, and it did not help. After quite a bit of digging I've found that the cause is a malformed URL (missing the initial '/') included in the results of Thread.currentThread().getContextClassLoader().getResources() file:/C:/Sun/SDK/ file:/C:/Sun/SDK/domains/domain1/lib/classes/ file:/C:/Sun/SDK/domains/domain1/applications/j2ee-modules/myApp/WEB-INF/classes/ file:C:/Sun/SDK/domains/domain1/generated/ejb/j2ee-modules/myApp/ I've done a bunch of searching to try to find where that classpath is constructed, or any other reports of similar issues, but found neither. I seem to be going in circles. Can anyone here point me in another direction? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] classpath issues...
Musachy Barroso wrote: I've done a bunch of searching to try to find where that classpath is constructed, or any other reports of similar issues, but found neither. In ClassLoaderUtil probably. ClassLoaderUtil is an xwork class. While looking at it earlier today I did find a bug (submitted a JIRA issue w/patch), but the fact that it was never detected before makes me think that code path never gets executed. It mostly just passes along URIs that it learns about by asking a series of class loaders. The missing slash uri that it passes along came from one of those class loaders (the first one searched). Are you suggesting that I should add special case checking code in there to validate/fix any URI before returning it? Seems like a hack, but I could do that... ...but it doesn't fix the fact that glassfish/the jvm/something appears to be supplying either an invalid classpath, or a broken class loader... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
parameter vagaries...
In Struts2.1.X there are now multiple interceptors for setting parameters from different sources on the action, but these don't also add those parameters into the map stored in ActionContext so that they are included in the map set when implementing ParameterAware... I can try to work up some patches to address this (I think it'll require both xwork2 and struts2 changes), but I'm confused right out of the gate, because I can't find where the setParameters method of ActionContext is initially called... ...can anyone offer guidance here? -Dale Newfield [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] S2 2.1.1 race condition passing request params: bug?
Giovanni Azua wrote: The race-condition happens only because my simulation process uses the execAndWait interceptor The execAndWait interceptor has a restriction that it can only support a single long running task per action name per session. It is this restriction that allows follow-up requests to be paired with the appropriate long running task. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] S2 2.1.1 race condition passing request params: bug?
Giovanni Azua wrote: Hah!! I wish these restrictions would pop up on my face rather than having to discover them in the hard way :) http://struts.apache.org/2.x/docs/execute-and-wait-interceptor.html sez: This interceptor works on a per-session basis. That means that the same action name (myLongRunningAction, in the above example) cannot be run more than once at a time in a given session. Giovanni Azua wrote: Could this restriction be overcome? maybe finding a way to pair the requests, maybe using a request id in the Session ... can I make an improvement request perhaps also work on it? I'd suggest adding some sort of token that is handed back and forth from server to client to server in order to correlate requests and their corresponding threads. Be very careful how you try to use the session here, though: http://struts.apache.org/2.x/docs/execute-and-wait-interceptor.html sez: Important: Because the action will be running in a seperate thread, you can't use ActionContext because it is a ThreadLocal. This means if you need to access, for example, session data, you need to implement SessionAware rather than calling ActionContext.getSesion(). I looked into this last year at some point and found it was less trivial than I had hoped :-). I don't currently have the time to dig in and fix it, but we would of course all appreciate someone trying to remove this limitation. (Maybe if the token is not available it could display a wait-list page that lists links to the corresponding action's threads associated with the current session?) Whether or not you can provide patches to fix this, it can't hurt to add a JIRA request detailing the issues involved. Of course a workaround/hack you could use to sidestep this would be to replicate your action with different names... I'm not sure exactly what the restriction is--maybe you can define a wildcarded action so that there are multiple available? action name=someAction-* class=com.examples.SomeAction interceptor-ref name=completeStack/ interceptor-ref name=execAndWait/ result name=waitlongRunningAction-wait.jsp/result result name=successlongRunningAction-success.jsp/result /action -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
struts2-api-2.1.2.jar ?
This appears to be missing from the 2.1.2 candidate... Is this file no longer relevant? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] struts2-api-2.1.2.jar ?
Musachy Barroso wrote: It was moved to the sandbox as it was never finished. D'oh! I just confirmed--I've been including it but not using anything from it for quite a while. Whoops. Thanks for the clarification. OK, how 'bout this? Why does the release (at least the lib version) contain these two seemingly mismatched pair of .jar files? commons-logging-1.0.4.jar commons-logging-api-1.1.jar -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Alternate submit tag...
Antonio Petrelli wrote: 2008/3/17, Dale Newfield [EMAIL PROTECTED]: We can avoid the JS requirement if we make the submit button's submitted value complex enough to encode the names of the namespace and actionname. The problem is that the value of the submit button is what the users sees. The value, but not the name. We could have s:submit action=fred/ result in: input type=submit name=replacementAction:/namespace/fred value=Make it Fred!/ which would result in http://app-server/application/namespace/barney.do?replacementAction:/namespace/fred=Make+it+Fred%21 which would cause the action mapper to select the barney action, but then drop it on the floor and instead return the fred action. There is the need of a js function that modifies it before submitting. We've got lots of struts2 tags that require javascript. Has a chart ever been drawn up so that folks that need their applications to work on browsers either w/o javascript capabilities or w/o javascript enabled? If the only current tags that require JS are funky ones like optiontransferselect, then that's a strong reason not to add the restriction to something as fundamental as the submit tag. If the js requirements are already widespread, then that argument doesn't hold much water. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Alternate submit tag...
Antonio Petrelli wrote: Sincerely I don't like to put js where it is not necessary. Agreed, although I'm much less worried about this today than I was 5 years ago. If you don't know it, Struts 1 has LookupDispatchAction that makes a reverse-lookup in a resource bundle to retrieve the key and then maps it to a method. See: http://struts.apache.org/1.x/apidocs/org/apache/struts/actions/LookupDispatchAction.html I did not know--thanks for pointing it out. If the only thing different between two concrete action definitions is the method, then both this mechanism and the one we're currently using will work. If you have either multiple explicit action definitions, or use wildcard mappings, or probably other mechanisms I'm missing, this can result in a selected action definition that simply does not appear as a valid choice in your specification. (Because instead of selecting a new one, a modification of the first selected one is returned.) What I'm really arguing for is to make developers always refer to actions by namepacename, so that we can always select the correct valid action specification. We can avoid the JS requirement if we make the submit button's submitted value complex enough to encode the names of the namespace and actionname. Instead of returning a modification of an action mapping, the action mapper then could completely ignore the action mapping it would normally select and select a different one based on these two strings. This wouldn't help with WW-2316/WW-2363/XW-595/XW-594, but it would fix this validation problem... -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alternate submit tag...
As evidenced by the diffulties described on the user list in Wildcard mapping should not suck (but does), I propose that instead of having a method attribute on the submit tag that works w/o js in the client, but requires some black magic on the server side, we add an action attribute to the submit tag that uses js on the client to change the form target before submitting. This will enable the usage pattern that I believe developers want and reduces the dispatcher complexity. Thoughts? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Alternate submit tag...
Jeromy Evans wrote: Shouldn't validation just be fixed? What you really want to say in the s:submit tag is run this action instead what we're currently saying is run this method instead. Because of this, you're getting different validation than you want because changing the method doesn't change the action selection. This isn't a validation problem, it's a problem in the ActionMapper. In fact, it's part of the tag library that is implemented in the DefaultActionMapper code, but I believe it is moreover a result of a unfortunately chosen specification. If we want the s:submit tag to work as currently specified, and validation to work correctly as you'd like, here's the process that must happen: o Use normal mechanisms for selecting action mapping. o Notice extra parameter, and modify that action mapping (which may or may not yield an action mapping that your specification considers legal/valid). o Re-look up (backwards) what action mapping would have been chosen had the input been a value that would have resulted in this newly described action mapping. More importantly than this being a difficult to describe/implement process even once, it is in a component of the system that is undergoing wonderful refinement/replacement with custom action mappers of various flavors (many folks have written for clients, as well as a number of plugins, etc.) each of which need to do this same strange dance to keep the current s:submit working, a complexity that we have no reason to want to add to developers shoulders. (And a place where I would bet many ActionMappers will get it wrong.) The current s:submit implementation is also causing difficulty in the code base because it's been recognized as a possible security issue when used with URL-based authorization checking, and while a solution has been worked on, fully realizing it would require a change to the struts.xml spec to add allowable alternate method white-lists to the action mapping specification. All this can be cleaned up if we allow ActionMappers to do their jobs without this over-specification. If we always named actions by the same name, then the right action will always be looked up and usable in it's full specification. If you allow both action selection by name and then action modification, other things that need the correct information from the action specification (like the validator) are likely to get the wrong data. Is it really that difficult to change your submit tag from s:submit method=pageTwo key=next/ to s:submit action=wizard_pageTwo key=next/ ? That's what you name the action everywhere else (in Wizard-wizard_pageTwo-validation.xml for example). It would solve your validation problem and many more simultaneously. The only cost is that it makes the s:submit tag only work correctly if the client has javascript enabled. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Andrea Vettori wrote:
can someone explain why it's bad practice to do something like this in a
jsp page :
sometaglib:sometag var=result/
s:hidden name=property value=${result}”/
Because the value of ${result} will then be evaluated as an OGNL expression.
So let's say this sometaglib:sometag tag finds the current user's
username and sticks it in the var attribute.
If I can change my username to [EMAIL PROTECTED]@exit()}, ${result}
will evaluate to [EMAIL PROTECTED]@exit(-1)} which will then be
evaluated as OGNL, taking down your application server.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Chris Pratt wrote: Only if we allow the container to process the JSTL EL. If we turn the container off and process the JSTL EL inside of the Struts tag library, the security hole vanishes. Right--if you replace OGNL with EL in struts, the security issues that come from executing both go away. Saying that doesn't make the changes trivial. So if you would you like to help develop that, please read through the following page and post patches to the following xwork issue: http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement http://jira.opensymphony.com/browse/XW-461 -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Andrea Vettori wrote: That's true but should't the app do some input checking ? What you're suggesting is that we make this framework vulnerable to poorly written applications? I'd say the framework should be written so that even poorly written applications can't compromise it. It's the same as SQL injection... In fact, it's OGNL injection, and the way to avoid it is not to evaluate user provided strings as OGNL expressions. Turning off EL is part of how that's been accomplished. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Chris Pratt wrote:
The proposed flow (with rtexprvaluefalse/rtexprvalue):
The bit you're missing is that if you have a tag attribute with
rtexprvalue set to false that contains what the container thinks is an
EL expression (i.e., ${foo}), the jsp compilation will fail, so it
will never execute and pass the string ${foo} on to your tag. As
previous posters suggested, I believe the only way to prevent this is to
tell the container to never evaluate these el expressions, which has the
previously mentioned down-sides.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Chris Pratt wrote:
I don't know about other containers, but this works great on Resin. I
do it today.
Glad to learn I'm wrong! So the plugable EL version of the struts tags
should all be able to work with the same .tld, with rtexprvalue set to
false everywhere, and the tag attributes that should be evaluated can be
handed to the currently-plugged-in evaluation engine inside the tag.
Hell, if they were all distinguishable textually (like ${} vs %{}) it
could auto-select the appropriate el on an attribute by attribute basis,
then *everyone* would be happy, without even needing to globally select
one EL plugin... (And as you've been saying, since the string would be
evaluated by exactly one of these, we don't re-expose the previous
security risk.)
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [VOTE] Struts 2.0.11.1 Quality (fast track) - PROPOSED ANNOUNCEMENT
Wendy Smoak wrote: * ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.11.1 IMMEDIATELY! All developers using Struts 2 are ... ? I think we need to make it clear that Struts 1 apps are not affected. That's true, but since there may be people that see this notice and then update 2.0.9 or earlier deployments, I guess there should be a comment about the rtexpr changes, too? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [OT] Re: StrutsStatics...
CleverSwine wrote: auto-suggest IDEs... The combination of your assumption that all good coders use IDEs (and therefore none of us that still use vi could possibly by good coders), continued posting about the same issue without any additional contributions to the conversation (this would be an API change, which was recently talked to death and I think decided against unless there's a very good reason), and your refusal to identify yourself gives us all plenty of reason to ignore you. Since this is quite a generous group of people that develop/support Struts, I expect that should you wish to raise this same issue again, there's still a chance you'll get a receptive audience, but only if you do so politely, without repeating yourself, and non-anonymously. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Brian Pontarelli wrote:
I've been trying to catalog all of the cases where OGNL exists and where
it can be replaced.
Since different ELs specify different mechanisms to state this is an
expression to be evaluated, I wonder what we should do about the
delineating characters %{/} vs. ${/} vs. #{/}, etc.
Right now in result specifications in struts.xml (when the result
supports it, and when parsed) we use ${} to say this is an expression
to be evaluated even though it's currently ognl (which uses %{}). I'm
of several thoughts regarding this. One one hand since it's OGNL I
think it should be %{}. On the other hand if we're contemplating
switching ELs maybe it should not be EL-specific so that the EL can be
changed without modifying all the expressions.
So: Is it possible to have these change with the EL? Is it desirable?
If we want to use a single type for all ELs, which should it be?
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] First commit is a FAILURE!
Wes Wannemacher wrote: my surprise birthday party Happy Birthday! -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] html:form generates invalid xhml
Keith Winkler wrote: Which is not really valid xhtml on account of the un-escaped characters. The standard solution for this is wrapping your js code with the following javascript comments/xml CDATA declaration: script type=text/javascript //![CDATA[ code goes here. //]] /script Maybe this solution can be used to ensure xhtml conformance? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] [S2.1] One Step On.... the Dojo plugin tree problem
Al Sutton wrote: OK, it would appear that if any node in the tree has a null for the value of the child property the following error is reported by FreeMarker; This is really another example of a broader problem with many of the .ftl templates in the struts2 codebase. A previous example has a three character solution: https://issues.apache.org/struts/browse/WW-2383 , for this one it appears that a single ! may be sufficient. Excerpted from http://freemarker.org/docs/dgui_template_exp.html#dgui_template_exp_missing_default: If the default value is omitted, then it will be empty string and empty sequence and empty hash at the same time. Expression stack.findValue(parameters.childCollectionProperty.toString()) is undefined on line 24, column 8 in template/ajax/treenode-include.ftl. The problematic instruction: I'm not sure how to describe this well, but I'd suggest a broad jira ticket to look through and provide defaults in the .ftl templates for pretty much anywhere there's a stack.findValue() call... Now here's the question; Are we going to allow users to represent leaf nodes in the tree by having a null for the child property, or are we going to say that all nodes must return a valid instance of a java.util.Collection when the child property is fetched? This basically means all those db objects with collections as attributes need to replace the simple return FOO in their getters with if (FOO==null) return new mumble(); else return FOO. While this isn't a bad idea, I would hate to have the presentation layer break if it's not done.. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
