Re: [VOTE] Struts 2.0.1 Quality
Somewhat related (but mostly not) What parts (if any) of the new API (The bob_lee_api) will be in 2.0.1 (final)? Cheers, Eric On 10/23/06, Rene Gielen [EMAIL PROTECTED] wrote: [ X ] +1 Beta grade for 2.0.1 all Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Spring 2 for Struts 2?
+1 I've been using this combination (Spring 2 and Struts 2) with a high volume production service for a while now. It's backwards compatible so the folks still on spring 1.2.xx should just keep working... Cheers, Eric On 10/14/06, tm jee [EMAIL PROTECTED] wrote: Hey I am not so selfish; I was thinking about all those big companies for which an upgrade is taking a lot of time. Yup. I know, I'm just joking :-) Alexandru Popescu [EMAIL PROTECTED] wrote: On 10/14/06, tm jee wrote: I guess everybody knows the reasons ;-). Hmm... let me guess, infoq uses Spring 1.2.x ;-) Me too :-) Hey I am not so selfish; I was thinking about all those big companies for which an upgrade is taking a lot of time. ./alex -- .w( the_mindstorm )p. Alexandru Popescu wrote: On 10/14/06, Mark Menard wrote: On 10/13/06 5:36 PM, Ted Husted wrote: Since the reports are that Spring 2 works just fine with Struts 2, why don't we bite the bullet and update our dependencies? Not that I'm a s2 developer, and my vote doesn't matter, but I've been using it for a few weeks now with no issues. +1 I agree with this upgrade as long as the Spring 1.2 users will still be able to use Struts2 just by drop-in replacement of the Spring jar (and I think this is possible). If not, then we must figure out a way to have Struts2 working with both versions. I guess everybody knows the reasons ;-). ./alex -- .w( the_mindstorm )p. Mark -- Mark Menard Business: http://www.vitarara.net/ Personal: http://www.vitarara.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0.0 - STATUS
For Xdoclet just make sure you are using release 1.2.3 and download the 1.5-snapshot050611 version of xjavadoc. (All are on the files section of their SF.net page) http://sourceforge.net/project/showfiles.php?group_id=31602 Cheers, Eric On 8/28/06, Rainer Hermanns [EMAIL PROTECTED] wrote: I have a patched version of xdoclet around, that supports java 5 features... I do not remember where I actually found it on the net, but I could send it to one of you... hth, Rainer Yeah, I tried all that a few months ago, and reached the same conclusion. Either we have to use one of the javadoc processors that support java 5 or screw it altogether. As for Ant, if you can do it in ant, then just use the antrun plugin to run that. Don Ted Husted wrote: Actually, re-reading WW-1392 * https://issues.apache.org/struts/browse/WW-1392 the problem may be XDoclet and Java 5. * http://swik.net/xdoclet/XDoclet/Tip:XDoclet+1.2.3+does+not+work+with+Java+5.0/k0w In any event, Rene pinged me to say that he can try a simple Ant-based solution. Maybe once we have that, we can isolate the problem. Perhaps if we can point Ant at files that don't use J5 features like annotations, we can work around the problem. Worst case, for 2.0.0, we could go with a patched version of the WW 2.2.3 TLD that I committed a few days ago. -Ted. On 8/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/25/06, Ted Husted [EMAIL PROTECTED] wrote: The simplest thing might be to setup a very simple Ant build file that just called XDoclet to create the TLD. Then everything else falls into place. If we need to call it as a separate process for now, then so be it. I expect that eventually XDoclet will catch up to Maven 2, and we can dump the separate TLD build. If we can do it with Ant, we should be able to do it as part of the Maven build, using maven-antrun-plugin. So if someone can come up with that simple Ant build file, I'll try to integrate it in the Maven build. Shouldn't we be able to find it (or at least something to start with) in the old WW Ant build files? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Sping WebFlow Integration
Right now most of my work is on hold until I get moved and up to speed at my new job. Its been a while but when I tried SWF-76 it worked but I haven't looked at it recently. My current concentration has been updating the spring integration but even that's been a bit spotty lately. Cheers, Eric On 7/26/06, Ted Husted [EMAIL PROTECTED] wrote: Eric Molitor wrote: http://forums.opensymphony.com/thread.jspa?threadID=14251tstart=15A At The Spring Experience in Miami Keith Donald, Myself, and Matthew Porter worked out a way it could be done and it was pretty simple. Once SAF2 starts solidifying I'd like to start playing around with continuation support again but I'm less interested in RIFE's implementation and more interested in SWF's implementation. But you also have to consider Beehive (ASF) and probably some integration with OSWorkflow. I worked up some code that created a WebFlow action and diverted processing to SWF but didn't get much farther than that. However I believe there is code floating around to execute an action as a SWF step. YMMV Are you still working on this, Eric? Did you give the class Matt mentioned a try? * http://opensource.atlassian.com/projects/spring/browse/SWF-76 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simple patch to update to spring stable
I just created and attached a patch to WW-1394 to update SAF2 to use Spring 1.2.8. This should resolve some silly spring issues that exist in 1.2.6 (and 1.2.7). (I have a more complex patch to update some of the spring integration but that needs to wait for Spring 2.00) Someone should take a gander and apply if they like it... Cheers, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to remove Ant build from Struts 2
It realy comes down to managing the dependencies. I could forsee someone building an ant build that ran against the compiled code and dependencies. (Similar to Atlassians build system with JIRA.) However I personally dont think its appropriate to be part of the project. (At least not as a source level) As someone whom fought to keep ant (and even managed to supply a few patches to fix the unit tests and the build at the begining of SAF2) my feeling is that managing ant, ivy, and maven just isn't worth the effort. Any developer whom needs to patch the source is going to be able to handle maven. Just my .02. Cheers, Eric On 7/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Don Brown proposed: I'd like to remove the Ant build from Struts 2. I don't think it has worked for a little while and the new Maven 2 layout discourages it for any complex builds. Unless someone seriously wants to put the effort into keeping it up, I think it should be removed. From the peanut gallery, I would like to see a minimal Ant build kept so that users would be able to download the Struts 2 source, patch it for their needs, and build a working jar file. I think that Ant is much more commonly used than Maven 2, that it's valuable for users to be able to try small changes to suit their needs, and that requiring Maven 2 significantly raises the work required to do so. Perhaps I am wrong, and either maintaining such a minimal Ant build is prohibitively expensive or installing and learning Maven 2 is trivially easy. - George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to remove Ant build from Struts 2
What about using the Maven2 ant tasks and integrating that way? I just started reading http://maven.apache.org/ant-tasks.html this morning. artifact:dependencies filesetId=my.dependency.fileset verbose=true pom id=project file=pom.xml/ /artifact:dependencies Of course you'll need maven and ant... On 7/10/06, Don Brown [EMAIL PROTECTED] wrote: The one case I wouldn't mind seeing an Ant build is in the source distribution. Many times, I'm downloading source distros, and have to make some change, but I'm on a network where I don't have connectivity to the outside world. If we could make a source distro that was completely self-contained, complete with an Ant build, I'd be fine with that. Don Eric Molitor wrote: It realy comes down to managing the dependencies. I could forsee someone building an ant build that ran against the compiled code and dependencies. (Similar to Atlassians build system with JIRA.) However I personally dont think its appropriate to be part of the project. (At least not as a source level) As someone whom fought to keep ant (and even managed to supply a few patches to fix the unit tests and the build at the begining of SAF2) my feeling is that managing ant, ivy, and maven just isn't worth the effort. Any developer whom needs to patch the source is going to be able to handle maven. Just my .02. Cheers, Eric On 7/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Don Brown proposed: I'd like to remove the Ant build from Struts 2. I don't think it has worked for a little while and the new Maven 2 layout discourages it for any complex builds. Unless someone seriously wants to put the effort into keeping it up, I think it should be removed. From the peanut gallery, I would like to see a minimal Ant build kept so that users would be able to download the Struts 2 source, patch it for their needs, and build a working jar file. I think that Ant is much more commonly used than Maven 2, that it's valuable for users to be able to try small changes to suit their needs, and that requiring Maven 2 significantly raises the work required to do so. Perhaps I am wrong, and either maintaining such a minimal Ant build is prohibitively expensive or installing and learning Maven 2 is trivially easy. - George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (WW-1328) xhtml theme is hardcoded to use xhtml/controlfooter for all templates
When we discussed this issue in regards to 2.2.3 (and then pulled it
because of the significant number of changes) it seemed like option 2
not only solved this issue but other template inheritance issues as
well.
With the emphasis that is being put on templating, from multiple AJAX
templates to separating the tags/ui into their own projects, option 2
certainly feels like the right solution.
If you've ever created a custom template with the goal of extending an
existing template and just modifying a handful of template files
you've probably run into the issue that is covered by option 1. In my
opinion its a huge pain in the ass to copy the other template files
just to keep everything working. That level of redundancy sucks and
IMHO SAF2 should neither be a pain in the ass or suck.
My 2 cents :)
Cheers,
Eric
On 6/25/06, Rainer Hermanns (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/struts/browse/WW-1328?page=comments#action_37603
]
Rainer Hermanns commented on WW-1328:
-
Nope, it is not that trivial...
I tried it locally, but there is a problem with the parse directive, trying to
embed unavailable files within the different themes.
#parse does use the ${parameters.templateDir} but does not know what to use, if
the requested file is not available.
If we want to address this problem these might be pssoble solutions:
o every theme has to include all template files so that the above parameter
works as expected.
If a template is inherited, just use it as a wrapper for a parse call to the
correct ('super') theme template file.
o rewrite or implement an intelligent parse macro, that takes the
$parameters.templateDir as a default and tries to lookup
the theme inheritence hierarchy until the named file is found
What do you think?
Rainer
xhtml theme is hardcoded to use xhtml/controlfooter for all templates
-
Key: WW-1328
URL: http://issues.apache.org/struts/browse/WW-1328
Project: Struts Action 2
Type: Bug
Components: Views
Versions: WW 2.2.2
Reporter: Nick Hill
Assignee: Don Brown
Fix For: 2.0.0
If you look at one of the xhtml themes, for example, text.ftl, it is hard
coded to use the xhtml controlfooter. This poses a problem for overridding the
theme.
Example xhtml/text.ftl:
#include /${parameters.templateDir}/${parameters.theme}/controlheader.ftl
/
#include /${parameters.templateDir}/simple/text.ftl /
#include /${parameters.templateDir}/xhtml/controlfooter.ftl /
Notice the controlfooter does not use ${parameters.theme} but rather is hard
coded to xhtml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
My experience is that it's quite a bit faster than CVS (especially over a WAN) but to be honest the biggest advantages I've seen are with file moves, renames, and branching. SVN seems to handle them all relatively painlessly which is a significant improvement over CVS. Also the SVN support in IntelliJ seems to be better than the CVS support. Of course, YMMV. XWork isn't particularly large so I don't know what the overall impact would be. Cheers, Eric On 5/23/06, Jason Carreira [EMAIL PROTECTED] wrote: Why move it to SVN? What does it gain? Just wondering how I'm going to reconcile all these changes I've got that will be harder to do if we switch repositories... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61939#61939 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Staying on CVS is probably a smarter descision for now but... You could convert the repo to SVN, create a 1.xx branch and then you could import your local copy into the trunk. Never tried it but in theory it would work. Cheers, Eric On 5/23/06, Jason Carreira [EMAIL PROTECTED] wrote: It also may be wasted work if there's an idea that the whole repository may be moving again (that is, to Apache) in 6 months. Exactly, point #1. That said, I recall people generally saying that the SVN import-from-CVS tools work pretty well, and they also are able to preserve CVS history, addressing Rainer's question. I haven't ctually done such an import myself. If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. Exactly, point #2. But the problem is... If we're going to branch the old stuff, do I want to check in my XWork 2.0 changes and then port to SVN, then have us try to branch from a spot before I checked those in for 1.x? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61969#61969 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API updates and build fix...
The name changes resolve the ambiguities that I saw in the first draft so that is a definite positive. The Messages.Severity enum and other messaging improvements are a definite positive. (They satisfy my desire for a Log4J type usage but are still distinct enough to avoid confusion.) Since the last API discussion the Attribute stuff is quite a bit more clear and I do think it is an advancement over MAP based interactions with bound data. (Session, Application, Request, etc) The only question I have is about the ThreadLocalRequestContext. With XWork I currently have a custom XML Dispatcher that allows actions and parameters to be read and executed from an XML document. When invoked from a file upload I provide an option to use the existing context or create a new one via a bit of trickery with the threadLocal and ActionContext. With the new API I'm assuming I could use ThreadLocalRequestContext to store a context in a variable, create a new one and invoke an action (or actions) with the new context, then restore the original context and return back to the original dispatcher? Assuming the above is true it would seem pretty easy to use ThreadLocalRequestContext. to serialize the data and provide a simple implementation of Continuations. Or have I steered wrong somewhere? Cheers, Eric On 5/16/06, Bob Lee [EMAIL PROTECTED] wrote: We've been cleaning up and reorganizing the API to make it more intuitive and user friendly. Any feedback is much appreciated. Bob On 5/16/06, Paul Benedict [EMAIL PROTECTED] wrote: I don't remember an SPI being part of WW. Is this new to Action 2? --- Bob Lee [EMAIL PROTECTED] wrote: I've attached a patch with the API updates we discussed last week. I also fixed the Maven build to correctly build the API again. The latest Javadocs are here: http://www.crazybob.org/javadoc/ Thanks, Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Action2] STATUS - Documentation
On 5/8/06, Ted Husted [EMAIL PROTECTED] wrote: I haven't been able to get an export of the SAF2 wiki in any format. I've let the process run for over an hour, but it never seems to return. Smells like the same issue encountered when trying to export the WW 2.2.2 docs for release. Anybody know what Contegix did to get the docs to export? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Leveraging known constructs (was Public API first draft)
Happily XWork has no dependency on web development at all, I use it to provide a command pattern for autonomous path finding robots for instance. Anything less than complete abstraction at the action level would be vetoed by most of the existing developers. (At least I hope they would vote it down as a bad idea.) While you may see such interfaces as *Servlet which provide a convenient way to access the ServletSession their use is generally frowned upon. One of the driving factors that pushed me to WebWork, really XWork in this case, is that it has no hard dependencies on the Servet API's. There already exists code for invoking actions via SWING, XML, JMS, etc. You can just as easily use your actions in a service layer as well as in the web tier. (From various discussions I've come to the conclusion that there are two schools of thought on this. The Carreira model which says its quite fine to have your actions in the service tier, and the Porter(Lightbody?) model which says have your actions live above the service tier. However in both instances you still wouldn't be bound to the Servlet API) I would argue thought that since WebWork supports portlets already, removing support in SAF2 shouldn't be taken lightly. Cheers, Eric On 5/5/06, Paul Benedict [EMAIL PROTECTED] wrote: I will return to the boards shortly, I hope :-) But I've been reading and need to address this: Please be mindful not to buttonhole Struts into a servlet-only API. One of the large efforts of the Tiles refactoring is to remove all references of the Servlet API, so that it could be used in a portlet environment (as well as anything else I suppose). Struts 2.0 should be flexible enough that you can run this in a portlet environment too. By far, we don't have to support portlet functionality in 2.0, but if we design without this in mind, we will not be able to retrofit any API easily in 2.x. Also also to make sure the public API is not dependent upon JSP. There were too many 1.0 utility methods that required access to the JspContext to get things out of the request or session. Make sure that problem isn't duplicated here, because the UI could be anything, not just JSP. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Messages Round II (was Leveraging known constructs (was Public API first draft))
Addresses my concerns quite nicely and should be easy to refactor code against.
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish. Should Level extend Comparable?
- It has built in support for INFO, WARN, and ERROR along with
respective convenience methods.
- It provides a Map of field messages. It's not necessary for Messages
itself to implement both Map and List. Delegating to separate objects
is less confusing.
- Adding messages and checking for the presence of messages
(hasErrors()) should be dead simple. Getting the messages doesn't have
to be as convenient (at least not through the published API).
- Request-scoped is the wrong word. We're really talking about not
associated with a field. Page-scoped? Form-scoped? Global?
Thanks,
Bob
package org.apache.struts.action2;
import java.util.List;
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import java.io.Serializable;
/**
* Request and field-scoped messages. Uses keys instead of actual messages to
decouple code from messages. Messages
* may come from multiple actions and interceptors.
*
* @author [EMAIL PROTECTED] (Bob Lee)
*/
public interface Messages {
/**
* Message level.
*/
public interface Level {
/**
* Informational message level.
*/
public static final Level INFO = new LevelImpl(info);
/**
* Warning message level.
*/
public static final Level WARN = new LevelImpl(warn);
/**
* Error message level.
*/
public static final Level ERROR = new LevelImpl(error);
}
/**
* Adds request-scoped informational message.
*
* @param key message key
* @see Level.INFO
*/
void info(String key);
/**
* Adds request-scoped informational message.
*
* @param key message key
* @param arguments message arguments
* @see Level.INFO
*/
void info(String key, Object... arguments);
/**
* Adds field-scoped informational message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @see Level.INFO
*/
void info(String fieldName, String key);
/**
* Adds field-scoped informational message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @param arguments message arguments
* @see Level.INFO
*/
void info(String fieldName, String key, Object... arguments);
/**
* Adds request-scoped warning message.
*
* @param key message key
* @see Level.WARN
*/
void warn(String key);
/**
* Adds request-scoped warning message.
*
* @param key message key
* @param arguments message arguments
* @see Level.WARN
*/
void warn(String key, Object... arguments);
/**
* Adds field-scoped warning message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @see Level.WARN
*/
void warn(String fieldName, String key);
/**
* Adds field-scoped warning message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @param arguments message arguments
* @see Level.WARN
*/
void warn(String fieldName, String key, Object... arguments);
/**
* Adds request-scoped error message.
*
* @param key message key
* @see Level.ERROR
*/
void error(String key);
/**
* Adds request-scoped error message.
*
* @param key message key
* @param arguments message arguments
* @see Level.ERROR
*/
void error(String key, Object... arguments);
/**
* Adds field-scoped error message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @see Level.ERROR
*/
void error(String fieldName, String key);
/**
* Adds field-scoped error message.
*
* @param fieldName name of field to attach message to
* @param key message key
* @param arguments message arguments
* @see Level.ERROR
*/
void error(String fieldName, String key, Object... arguments);
/**
* Adds request-scoped message.
*
* @param level message level
* @param key message key
*/
void add(Level level, String key);
/**
* Adds request-scoped message.
*
* @param level message level
* @param key message key
* @param arguments
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Just as some people continue to use WebWork 1.xx (JIRA) I imagine people will continue to use SAF1 regardless of how easy the migration path is. I always assume it would take a day or two to convert existing WW code to SAF2 so at the end of the day just picking a direction is progress. :) Cheers, Eric On 5/5/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/5/06, Don Brown [EMAIL PROTECTED] wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. Don SAF1 could have future if migration to SAF2 were impossible or too complicated. But according to your plan, migration from SAF1 to SAF2 should take days. What is the point of keeping Action 1.x to be developed actively? I am not objecting, I am just asking. Trying to understand where I am ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
I guess I'm a bit confused but is this API the only supported route or are their plans to support existing WebWork/Xwork code? I'll be honest and say that I need to go through the API and consider each point before I make a complete judgement. However, at first glance, this deviates far enough from existing XWork actions to leave me a bit concerned. In regards to the implementation of the API where did ResponseAware go? While not elegant there are times where it is useful. (admittedly I use an interceptor for this for example http://confluence.twdata.org/display/WW/HTTPS+and+IE+Issues so it may be a mute point.) - Eric On 5/4/06, Gabe [EMAIL PROTECTED] wrote: I'm -1 on the draft proposal. The vast majority of the API as I read it is to support Bob's proposal of how to deal with XWork. As Patrick stated before (paraphrase) the three proposals are: 1) Move XWork over as a seperate project under the umbrella of Struts Action 2 (Webwork=Struts web and XWork=Struts core) 2) Create an adapter layer for Struts 2 developers to use without directly interfacing XWork (Bob's proposal) 3) Leave XWork where it is and use XWork's API directly in Struts Action 2 The public API presented mainly implements #2, which has not yet built a consensus that it should be used. In my view, the problems with #2 are: 1) It creates an adapter code layer that adds little functionality but requires maintenance. For example, if something is added in XWork, then a change in Struts 2 will generally be required for that change to be usable. 2) If it does add functionality, it blurs the traditional seperation of roles between XWork and Webwork. The adapter layer risks becoming a second judgement layer on what should or should not be in XWork. I think those decisions should be made in the XWork project directly. 3) If we are going to use XWork's API so directly and are worried about it being called opensymphony.xwork rather than apache.struts, we should simply move XWork over as in proposal #1. 4) It creates a divide of those things that are part of the Adapter pattern layer and those that are not. Those that are not become more obscure and undocumented. Thus, while I applaud Bob and Patrick for putting out a vision in code, since it appears to me that 90% of the API simply supports proposal #2, we should discuss that proposal instead first before creating an API that supports it. Gabe - Original Message From: Patrick Lightbody [EMAIL PROTECTED] To: dev@struts.apache.org Sent: Wednesday, May 3, 2006 10:01:58 PM Subject: [action2] Public API first draft Bob and I have been going over the new public API proposal. It has been designed to simplify Struts and abstract away XWork complexities that aren't needed. It is far from complete, but we wanted to get some early feedback. We'll likely be talking about this stuff a lot more during JavaOne, but we'd like to start the discussions now. The code is checked in under the action-api module. Assuming you've got the basic Maven build running, you can generate the JavaDocs (which might make seeing the API easier) by running: mvn javadoc:javadoc From the action-api directory. You must have run mvn install at least once before for that to work. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317messageID=56817#56817 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Public API first draft
I definitely agree that they should be isolated, but glancing through the api I saw RequestAware but not ResponseAware. (I`m reading the copy Don posted and not the version under source control.) On 5/4/06, Bob Lee [EMAIL PROTECTED] wrote: On 5/4/06, Eric Molitor [EMAIL PROTECTED] wrote: In regards to the implementation of the API where did ResponseAware go? org.apache.struts.action2.servlet.ServletResponseAware I put these interfaces in a sub package because users should avoid creating dependencies on the servlet API in their actions. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Public API first draft
Actually my point was the Servlet*Aware interfaces should be isolated as their use is generally a bad practice. There was some confusion as to what RequestAware was doing. If you have to implement 35 interfaces to implement an action then obviously this would not be a viable framework. In most cases you would be using few, if any, of the interfaces. Cheers, Eric On 5/4/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/4/06, Eric Molitor [EMAIL PROTECTED] wrote: I definitely agree that they should be isolated, but glancing through the api I saw RequestAware but not ResponseAware. (I`m reading the copy Don posted and not the version under source control.) ValidationAware, ErrrorAware, RequestAware, ResponseAware, SomeOtherStuffAware... Are you kidding? I might not understand something (heck, I haven't started with WW yet), but if all these interfaces are only meant to implement a callback method in a custom class for the framework to call, then... well, I do not like this. For the lifecycle, I want a clear definition of lifecycle call sequence and an option to call lifecycle methods explicitly. All of them. Like in SAF1, WW binds URL to a mapping to an action, so action is the endpoint which is guaranteed to be called. Fine. Then just pass control to that action and give me an option to call all (or some) lifecycle methods explicitly from the action. I will not need interceptors in this case, by the way. And I will not need to implement a bunch of intefaces. For the regular typecasting I agree, some interfaces are needed, to make certain methods available, but there should be a very limited number of these interfaces, and at best a particular class will need to implement only one interface. Um, does it make sense? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Leveraging known constructs (was Public API first draft)
The new Messages API could easily be mapped onto an implementation similar to that of Log4J. Why not embrace that idea and utilize familiar methods to provide access. such as... msgs.info(some.key); msgs.warn(some.warn.key); msgs.error(some.error.key); It does increase the number of methods but the argument is that the familiarity outweighs the effort of adding those methods. By default it only provides a small set of fixed levels, however custom levels should be easy to implement. I would even argue having a limited set of built in levels actually makes things easier for new developers. There are a few APIs that are known to almost all developers. By embracing a similar API a sense of familiarity is provided that should ease adoption and understanding. That's my rational at least and it usually serves me well. Cheers, Eric On 5/4/06, Bob Lee [EMAIL PROTECTED] wrote: I don't think it's a question of making things easier for the user or not vs. our effort. Are you saying you want arbitrary levels for messages (a la JSF)? Bob On 5/4/06, Don Brown [EMAIL PROTECTED] wrote: Don Brown wrote: re-education of developers. I want Struts Action Framework 2 to be seen as easy and powerful, not just from a feature standpoint, but also migration, education, and conceptual space one. I was talking to Eric on the ww dev chat, and he brought up a good point that resonated with me: we should be leveraging more known, common constructs in developing this API. For example, the Messages object, rather than leverage the familiar Log interface we all use every day. Messages are collected, much like logging messages and their levels are similar. Therefore, we'd have: msgs.info(some.key); msgs.warn(some.warn.key); msgs.error(some.error.key); We'd still keep the four different versions of the add function to handle field errors and parameters. Furthermore, Messages could implement Collection and Map, allowing it to be treated easily by existing tags and code built to handle these common constructs. Yes, this adds more methods but the value to the developer, I think, is worth it. I'd rather error on the side of making our job harder than require more work and learning on the part of the end developer. Martin Fowler calls it a Humane Interface pattern [1], and while I don't completely agree with that pattern (78 methods for a List?!), I do think we should be designing from the standpoint of the end developer, not from the framework developer. Let's make Struts Action 2 powerful, easy, and even _intuitive_. Don [1] http://www.martinfowler.com/bliki/HumaneInterface.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] /s /xwork.xml /action.xml
Even prior to the SAF merger I've always thought it should be action.xml. Only the action.vm feels a bit awkward to me. My preference would be default.vm, base.vm, or something like that. On 4/30/06, Ted Husted [EMAIL PROTECTED] wrote: Heretofore, the WebWork product was being distributed by OpenSymphony as WebWork 2. Now, the Action product is be distributed by Apache Struts as Action 2. In a prior discussion (XWork and Struts Action 2.0 ), there was a suggestion that we rename * xwork.xml to struts-action.xml which could lead to renaming * webwork.xml to struts-action-default.xml * webwork.vm to struts-action.vm * webwork.properties to struts-action.properties I would like to suggest that we use shorter names, and rename * xwork.xml to action.xml * webwork.xml to action-default.xml * webwork.properties to action.properties * default.properties to action-default.properties * webwork.vm to action.vm I'm not suggesting that we make additional source code changes until after we bring the codebase in from the incubator, but I would like to push forward on the documentation now. Just as a test, I've updated a few of the documentation pages to reflect the webwork==action scheme. * http://confluence.twdata.org/display/WW/Configuration+Files Of course, if we decide to go a different way, I'd update the pages accordingly. I would also do the work of any additional renaming of source code members and consequent changes. Thoughts? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
+1 (Not that my vote counts but it runs all my apps) On 4/28/06, Rainer Hermanns [EMAIL PROTECTED] wrote: +1 from me and a big thank you to everyone involved On Apr 28, 2006, at 20:19 , Don Brown wrote: I call a vote that the Struts PMC accept the WebWork 2 podling as having met the incubation requirements and thereby be accepted by the Apache Struts project as Struts Action 2. Status: http://incubator.apache.org/projects/webwork2.html [ ] +1 Let's bring it in, and I'm committed to the project [ ] +0 Let's bring it in, but I won't be involved [ ] -0 I'd rather not, but I'm not involved, and here's why... [ ] -1 Let's not, and here's why... We welcome votes from all community members, however, only the votes of Struts PMC members are binding. If this vote passes, the Incubator will need to vote for the graduation to be complete. Here is my +1 Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (WW-1281) Allow StreamResult parameters to be read from the stack
Rene, let me know what you think of this. I have a slightly different direction that I've been poking around with that takes the same idea a bit further. Too often I find myself wishing to just use a value on the stack for configuration and not poke around in the XML. I'd like a generic way to declare parameters that will automagically get pulled from the stack (If available). I probably need to put that under a nice to have but the more I work with complex logic in Webwork, the more I feel constrained by the XML. Cheers On 4/28/06, Rene Gielen (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/struts/browse/WW-1281?page=all ] Rene Gielen reassigned WW-1281: --- Assign To: Rene Gielen Allow StreamResult parameters to be read from the stack --- Key: WW-1281 URL: http://issues.apache.org/struts/browse/WW-1281 Project: Struts Action 2 Type: Improvement Components: Views, Configuration, Dispatch Versions: WW 2.2.2 Environment: Any Reporter: Eric Molitor Assignee: Rene Gielen Fix For: 2.0 Attachments: StreamResult.patch This patch allows the parameters for the stream result to be read from the stack. I seem to be having issues running the unit tests so none are included. (I'll probably work on some later). Precedence is given to values on the stack over values in the XML file. I plan to use the patch as follows In xwork.xml I create a global stream result.. result name=stream type=stream / Then in my actions I create getter methods for the various parameters (probably just contentDisposition, contentType, and contentLength) and then just return stream as the result of my execute method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Unit tests with ant/maven
Its not pretty but look at WW-1283 for the patch On 4/11/06, Eric Molitor [EMAIL PROTECTED] wrote: Well, I have them working but probably not in the way you want them too. I'll send the patch to both you and Rainer. Cheers, Eric On 4/11/06, Rene Gielen [EMAIL PROTECTED] wrote: Hey guys, I was about to work on the ant build now. So if I got you rigth, Eric, you already got things working? Then I'll wait for your patch... Regards, Rene Eric Molitor schrieb: It will have to be this evening (I'm -5 hours against UTC) as I dont have them on my work laptop. Cheers, Eric On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Eric, can you send your build patches over? Would get me started sooner. tia, Rainer On Apr 11, 2006, at 19:07 , Eric Molitor wrote: I hacked away at them last night to get them to work via ant and intellij. Wasn't pretty but only took an hour or so. Probably take two hours to do it right. On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Is anyone currently working on the build process with ant and maven? It looks like the test targets/goals are broken for now... Any update on this would be helpful to make the refactorings easier, thanks, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Unit tests with ant/maven
As always you are more than welcome. As my time frees up over the next few weeks I'll probably start posting more patches. Cheers, Eric On 4/12/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Thanks Eric, patches applied and fixed some left open issues with SiteGraphTest. I readded the -Dtestcase=yourtestcase switch as well. So, running the unit tests with ant is working again... cheers, Rainer On Apr 11, 2006, at 20:18 , Eric Molitor wrote: It will have to be this evening (I'm -5 hours against UTC) as I dont have them on my work laptop. Cheers, Eric On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Eric, can you send your build patches over? Would get me started sooner. tia, Rainer On Apr 11, 2006, at 19:07 , Eric Molitor wrote: I hacked away at them last night to get them to work via ant and intellij. Wasn't pretty but only took an hour or so. Probably take two hours to do it right. On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Is anyone currently working on the build process with ant and maven? It looks like the test targets/goals are broken for now... Any update on this would be helpful to make the refactorings easier, thanks, Rainer --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Action2] StreamResult Patch
WW-1281 created Once I get a chance to look at why the unit tests aren't running tI'll add a bit more. I've also been looking at an alternate approach that would allow any Result (anything that extends StrutsResultSupport) to recieve its parameters from the stack. Cheers, Eric On 4/10/06, James Mitchell [EMAIL PROTECTED] wrote: Any chance you could attach this to a jira ticket? That's the normal process, so that your contribution won't be forgotten. If you can't, I'll try add it to jira tomorrow. Thanks for your help. -- James Mitchell On Apr 10, 2006, at 2:37 AM, Eric Molitor wrote: This patch allows the parameters for the stream result to be read from the stack. I seem to be having issues running the unit tests so none are included. (I'll probably work on some later). Precedence is given to values on the stack over values in the XML file. I plan to use the patch as follows In xwork.xml I create a global stream result.. result name=stream type=stream / Then in my actions I create getter methods for the various parameters (probably just contentDisposition, contentType, and contentLength) and then just return stream as the result of my execute method. Cheers, Eric StreamResult.patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Unit tests with ant/maven
I hacked away at them last night to get them to work via ant and intellij. Wasn't pretty but only took an hour or so. Probably take two hours to do it right. On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Is anyone currently working on the build process with ant and maven? It looks like the test targets/goals are broken for now... Any update on this would be helpful to make the refactorings easier, thanks, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Unit tests with ant/maven
It will have to be this evening (I'm -5 hours against UTC) as I dont have them on my work laptop. Cheers, Eric On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Eric, can you send your build patches over? Would get me started sooner. tia, Rainer On Apr 11, 2006, at 19:07 , Eric Molitor wrote: I hacked away at them last night to get them to work via ant and intellij. Wasn't pretty but only took an hour or so. Probably take two hours to do it right. On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Is anyone currently working on the build process with ant and maven? It looks like the test targets/goals are broken for now... Any update on this would be helpful to make the refactorings easier, thanks, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Unit tests with ant/maven
Well, I have them working but probably not in the way you want them too. I'll send the patch to both you and Rainer. Cheers, Eric On 4/11/06, Rene Gielen [EMAIL PROTECTED] wrote: Hey guys, I was about to work on the ant build now. So if I got you rigth, Eric, you already got things working? Then I'll wait for your patch... Regards, Rene Eric Molitor schrieb: It will have to be this evening (I'm -5 hours against UTC) as I dont have them on my work laptop. Cheers, Eric On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Eric, can you send your build patches over? Would get me started sooner. tia, Rainer On Apr 11, 2006, at 19:07 , Eric Molitor wrote: I hacked away at them last night to get them to work via ant and intellij. Wasn't pretty but only took an hour or so. Probably take two hours to do it right. On 4/11/06, Rainer Hermanns [EMAIL PROTECTED] wrote: Is anyone currently working on the build process with ant and maven? It looks like the test targets/goals are broken for now... Any update on this would be helpful to make the refactorings easier, thanks, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Rainer Hermanns aixcept Neupforte 16 52062 Aachen - Germany w: http://aixcept.de/ t:+49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Action2] StreamResult Patch
This patch allows the parameters for the stream result to be read from
the stack. I seem to be having issues running the unit tests so none
are included. (I'll probably work on some later). Precedence is given
to values on the stack over values in the XML file.
I plan to use the patch as follows
In xwork.xml I create a global stream result..
result name=stream type=stream /
Then in my actions I create getter methods for the various parameters
(probably just contentDisposition, contentType, and contentLength) and
then just return stream as the result of my execute method.
Cheers,
Eric
Index: action/src/main/java/org/apache/struts/action2/dispatcher/StreamResult.java
===
--- action/src/main/java/org/apache/struts/action2/dispatcher/StreamResult.java (revision 392878)
+++ action/src/main/java/org/apache/struts/action2/dispatcher/StreamResult.java (working copy)
@@ -157,7 +157,27 @@
}
protected void doExecute(String finalLocation, ActionInvocation invocation) throws Exception {
+if(invocation.getStack().findString(contentDisposition) != null) {
+setContentDisposition(invocation.getStack().findString(contentDisposition));
+}
+if(invocation.getStack().findString(contentType) != null) {
+setContentType(invocation.getStack().findString(contentType));
+}
+
+if(invocation.getStack().findString(inputName) != null) {
+setInputName(invocation.getStack().findString(inputName));
+}
+
+if(invocation.getStack().findValue(contentLength, Integer.class) != null ) {
+setContentLength(((Integer) invocation.getStack().findValue(contentLength, Integer.class)).intValue());
+}
+
+if(invocation.getStack().findValue(bufferSize, Integer.class) != null) {
+setBufferSize(((Integer) invocation.getStack().findValue(bufferSize, Integer.class)).intValue());
+}
+
+
InputStream oInput = null;
OutputStream oOutput = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Ti] XWork?
This may be a dumb suggestion but why not implement a lightweight action class that's in StrutsAction and then if a user chooses they can use the full support of XWork. I'm not sure where you draw the line (you'd probably want validation) but I cant see why you couldn't implement a few of the interfaces. This kind of goes along with the POJO support for actions in WW 2.2 - Eric On 3/29/06, Don Brown [EMAIL PROTECTED] wrote: To add to that, Patrick and I were collaborating on phase 2 type features before we even thought of merging projects. After that brainstorming session, I started talking to Patrick about one of the ideas that came out of the conversion, like devMode, and Patrick implemented it in WebWork. He also went on to create QuickStart, which allows you to quickly prototype applications without a complication step. These were the types of ideas we were wanting to explore in Ti - ways to make the job easier for the developer. Don Ted Husted wrote: I think we're all still working off the original proposal. * http://wiki.apache.org/struts/StrutsTi Don is simply referring to phase 2, while most of us are still focused on phase 1. -Ted. On 3/30/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Don, I think this is totally at odds with a lot of the things I've been reading lately. Granted its been hard to separate the facts from the noise lately (through no fault of anyone involved with the merger), but even still... Can I make a suggestion? Certainly for the sake of the users in both communities, but also to be sure those doing the work are all on the same page, I think it would be a good idea for someone to write up what the plan actually is, and make sure everyone is on board with it. Maybe I'm speaking out of turn and such a thing already exists, but I really believe a lot of people are thinking this is just a Webwork rebranding, with some additions taken from Struts, and if that isn't the case I think it would be prudent to have a document than anyone can point to and say that's what we're doing, that's the plan!. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Ti] XWork?
Well what I've been toying with is two things the first isn't directly related but might be of interest. At the SpringExperience there were some discussions about integrating SpringWebflow into webwork and I started playing with some code. What I ended up with was a weird WebFlowAction that could (semi) invoke a webflow. It was far form perfect and I eventually lost interest. A week or so ago I took the same idea and started writing a StrutsAction Action. Basically the action just invokes the execute method of the struts action using ServletActionContext.getResponse() and ServletActionContext.getRequest() to supply the necessary parameters. There is a getActionForward() method for getting the Struts Action result and the return is hardcoded to SUCCESS. I don't know how valid this is but I've been able to execute some synthetic tests with positive results. The next bit I was planning on trying was using reflection to invoke all the getter methods on the Struts Action and then manually pushing them onto the stack. My reasoning for doing all of this was to provide a way to invoke StrutsActions within an unmodified WebWork 2.2. Now back to what you really asked for, any pojo is an action, why not just write a custom dispatcher for invoking legacy Struts Actions and maybe create a new execute method such as... Public String execute(ActionMapping mapping, ActionForm form) I probably should just start coding some of this up for people to look at as I communicate much better that way. After rereading the email I don't think I've clarified anything. But hey I'll send it anyway and try to get on the WebWork chat server later to try to explain it a bit more logically. - Eric On 3/30/06, Don Brown [EMAIL PROTECTED] wrote: On what framework would this solution you are describing run? Are you talking about running Struts 1.x actions inside Action 2? If so, that is something that has been started in the sandbox, but not fully developed. I'd like to hear more. Don Eric Molitor wrote: This may be a dumb suggestion but why not implement a lightweight action class that's in StrutsAction and then if a user chooses they can use the full support of XWork. I'm not sure where you draw the line (you'd probably want validation) but I cant see why you couldn't implement a few of the interfaces. This kind of goes along with the POJO support for actions in WW 2.2 - Eric On 3/29/06, Don Brown [EMAIL PROTECTED] wrote: To add to that, Patrick and I were collaborating on phase 2 type features before we even thought of merging projects. After that brainstorming session, I started talking to Patrick about one of the ideas that came out of the conversion, like devMode, and Patrick implemented it in WebWork. He also went on to create QuickStart, which allows you to quickly prototype applications without a complication step. These were the types of ideas we were wanting to explore in Ti - ways to make the job easier for the developer. Don Ted Husted wrote: I think we're all still working off the original proposal. * http://wiki.apache.org/struts/StrutsTi Don is simply referring to phase 2, while most of us are still focused on phase 1. -Ted. On 3/30/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Don, I think this is totally at odds with a lot of the things I've been reading lately. Granted its been hard to separate the facts from the noise lately (through no fault of anyone involved with the merger), but even still... Can I make a suggestion? Certainly for the sake of the users in both communities, but also to be sure those doing the work are all on the same page, I think it would be a good idea for someone to write up what the plan actually is, and make sure everyone is on board with it. Maybe I'm speaking out of turn and such a thing already exists, but I really believe a lot of people are thinking this is just a Webwork rebranding, with some additions taken from Struts, and if that isn't the case I think it would be prudent to have a document than anyone can point to and say that's what we're doing, that's the plan!. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
