The multiple thread thing is simple/trivial to solve using AOP. I'm not sure this would cause any performance issue though.
--- Jason Carreira <[EMAIL PROTECTED]> wrote: > It's not that it's difficult to keep it "Swing compatible" and it's not a > choice of loosing features. The new features, the biggest one being > Interceptors, IMHO, are in no way involved in this. This is really a question > of cleaning up some (IMO) ugliness in the original code that was put in to > keep backward compatibility. > > Actions were originally spec'd to have a method, execute(), with no > parameters. That was back when we had ServletAware, etc., and the context > information would be made available to the Action before it was executed. > When it was decided to get rid of these interfaces, to decouple Webwork from > Servlets, it was decided to move to ActionContext, which uses a ThreadLocal > to save the execution context for the Action in a way that is easily > available, local to the current execution, and doesn't have to be passed as a > parameter. Unfortunately, if you want Action preparation, execution, etc, to > be able to be run from multiple threads, ThreadLocals are, at the very least, > very difficult to use, and, at the worst, unworkable. > > Is this a huge deal? No, not really. Would it be nice to be able to do this > the right way? Yes. But, if it is a requirement that old Actions not have to > change their method signature and be able to get the params from the > ActionContext ThreadLocal, then this is a limitation that can be documented > and worked around. > > Just my $0.02 > > Jason > > > -----Original Message----- > > From: Robert Carlens [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 12, 2003 1:11 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] Reflection > > > > > > I have been following this list for quite some time with > > great interest. I really like all the new ideas for XWork. I > > think it would be sad not to see those ideas become > > implemented only because it would be difficult to keep it > > "Swing compatible". If an alternative is to break Webwork and > > XWork into two different projects I think it would be > > unfortunate, however, considering the alternative (miss out > > on all the great new functionality) I still think it would be > > worth it, but that's just my thinking for all it's worth. > > > > /Robert > > > > -----Original Message----- > > From: Rickard Öberg <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Sun, 12 Jan 2003 14:24:26 +0100 > > Subject: Re: [OS-webwork] Reflection > > > > Erik Beeson wrote: > > > Rickard, as I understood, XWork was to break away from J2EE, hence > > > removing "web" from the name. If new versions with strong > > web ties are > > > going to remain, shouldn't they remain under the original WebWork > > > name? > > > > That is something I wanted to gauge by my last couple of emails. I > > personally do not believe (at this point) that making the web part > > "optional" is going to work very well. I certainly don't > > believe that it > > is going to be feasible, or even a good idea, to make a > > framework that > > allows code to be written for both Swing and the web. They're > > different > > beasts with different requirements, with completely different > > thinking > > behind how code gets written. We have a lot of Swing code in our > > project, and when I look at it I simply don't see how something like > > XWork would fit in, or why it would be useful. > > > > What *is* useful is to allow actions to be called without a servlet > > environment, but more or less *only* for testing/debugging purposes. > > Executing actions as a response to asynchronous messages > > could work too. > > But that's about it. I do not believe that actions (except > > for maybe 1% > > of special cases) can be reused in so different spaces. I > > remain open to > > the *possibility* of it, but so far I just haven't seen it. > > > > So, given all of this, my resignation from XWork still holds. The > > requirements that have been voiced the last few days are not > > mine, and I > > don't think they're compatible with my goals, at least not without > > serious compromises that will only hurt the end result. The question > > then becomes: would it be useful to do *both* XWork and > > WebWork, but as > > separate projects with these different goals? > > > > /Rickard > > > > -- > > Rickard Öberg > > [EMAIL PROTECTED] > > Senselogic > > > > Got blog? I do. http://dreambean.com > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld omething 2 > > See! http://www.vasoftware.com > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 > > See! http://www.vasoftware.com > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
