Re: A plea - WAS Re: [OS-webwork] Reflection
On Tue, 2003-01-14 at 21:17, Robert Nicholson wrote: Why does it have to be a MDB? Can't you just make a listener? What will an MDB buy you? In a word: transactions (oh also instance caching for tuning but that would be more than 1 word :) ) We use a lot of MDBs in our app for these reasons. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Reflection
boxed wrote: The problem is not right or wrong, the problem is the pro's and con's of the various approaches, and AFAICT the explicit approach has some limitations, whereas the non-explicit approach has no limitations. I can think of an example right now when the explicit solution is much more flexible than the ThreadLocal solution: Action1 creates two sets of data and starts off two threads, executes Action2 and Action3 with these two maps as parameters, then joins on the threads and continues on with its own execution. Did I miss something here? Would this be easier to implement with ThreadLocal (with JNDI?)? If the threading is done by XWork it would be equally simple. /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 = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: A plea - WAS Re: [OS-webwork] Reflection
On Mon, Jan 13, 2003 at 08:30:17AM +0100, Rickard Öberg wrote: Mike Cannon-Brookes wrote: Some points that people seem to be forgetting: - Xwork is in the SANDBOX and is eXperimental (if you like the X for that) - Nothing in Xwork can't be changed, these are ideas, prototypes - Xwork will be better for 'web work' than WebWork is! - Xwork will be better for 'non web work' than WebWork is, _WITHOUT_ impacting people who don't care for 'non web work' That WebWork turned out to be a generic command pattern was more of an accident then by design. Because of this genericity WebWork is not optimally designed for doing web work. Some of the plumbing needs to be done by actions themselves, instead of having it be done by the framework. I want to make WebWork/XWork *better* suited for the web, because that is what *I* *need*. I want to get more for less. I don't give a damn about making it work well in Swing. If it does, then whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point where I need to decide between keeping genericity, or making it work better for the web, the latter is a given. My recent emails have explained some of what I want to do in this area (introducing packages and components for example). Some of those are VERY web-centric, and that *IS THE POINT*. I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01183/pgp0.pgp Description: PGP signature
RE: [OS-webwork] Reflection
Can you explain? I'd like to know. -Original Message- From: Heng Sin Low [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 8:48 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Reflection The multiple thread thing is simple/trivial to solve using AOP. I'm not sure this would cause any performance issue though. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Reflection
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Why is it difficult? Whenever there's a thread disconnect you just get the state, and then re-set it when you want to restart the execution. What exactly is the difficulty? I'm not as familiar with the non-common usages of ThreadLocals as you are. I understand how they can be gotten and set, but how do you get them from another thread to set into this thread, when a new thread is kicked off (or a new thread, like the event handler in Swing, is suddenly being used)? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: A plea - WAS Re: [OS-webwork] Reflection
After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: A plea - WAS Re: [OS-webwork] Reflection
Funny, we were just talking about this here today. We've got a simple command pattern implementation for running batch jobs now, and I was talking about how, if we moved to Webwork, we could make a MessageDrivenDispatcher (an MDB) that would run jobs asynchronously... -Original Message- From: Peter Kelley [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 5:28 PM To: [EMAIL PROTECTED] Subject: Re: A plea - WAS Re: [OS-webwork] Reflection After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
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 = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Reflection
What kind of real world example applications do you want? Wafer has a working webwork example... And docs? Who needs them - they're for people who aren't willing to roll their sleeves up and dig directly into the code, right? (Note droll humour.) On Sun, 12 Jan 2003, Heng Sin Low wrote: I think it might be beneficial to do both xwork and webwork as separate project at this point of time. At least, people will spent less time debating at mailing list and get things done. I guess there is no right or wrong here, it is just that people have different preference and needs. For instance, I only do webapp and certainly don't want all the extra complexity/coolness of xwork. IMHO, xwork if implemented base on idea presented here so far is a very different beast from existing webwork and might as well start off as a fresh project. Also, if we just concentrate all the efforts on xwork ( which will probably need sometime to mature ), we are neglecting the immediate need of existing webwork users. Look at webwork 1.3, it have been at rc1 for sometime and nobody seems to care about its status. Not to mention it still lack documentation, real world example application, have outstanding xdoclet bug, etc. --- Rickard_Öberg [EMAIL PROTECTED] wrote: 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 = 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 - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- 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
Re: [OS-webwork] Reflection
I think it might be beneficial to do both xwork and webwork as separate project at this point of time. At least, people will spent less time debating at mailing list and get things done. I guess there is no right or wrong here, it is just that people have different preference and needs. For instance, I only do webapp and certainly don't want all the extra complexity/coolness of xwork. IMHO, xwork if implemented base on idea presented here so far is a very different beast from existing webwork and might as well start off as a fresh project. Also, if we just concentrate all the efforts on xwork ( which will probably need sometime to mature ), we are neglecting the immediate need of existing webwork users. Look at webwork 1.3, it have been at rc1 for sometime and nobody seems to care about its status. Not to mention it still lack documentation, real world example application, have outstanding xdoclet bug, etc. --- Rickard_Öberg [EMAIL PROTECTED] wrote: 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 = 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
Re: 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 = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Reflection
I'm not sure I see the disconnect here. What's so different about Xwork? Views can still be JSP / Velocity / XSLT which generates HTML. It's still a great framework for web app development. If the ThreadLocal thing is the only sticking point, then lets talk about that. I'm personally for the changes Patrick made, as I think it makes the framework much more flexible. For instance, you could queue actions using JMS with all of the context (the ActionInvocation, or whatever Patrick has named it) carried along. However, that said, if it's such a big deal that people are talking about forking the code base and splitting Xwork and Webwork, then I think we should roll it back and discuss. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I think there are two directions here and I don't see any easy resolution at this stage. So, yes I think two projects make sense. My next question is Is there room for these two projects at OS? Does it make sense or will it be a distraction since they do have overlap? Should WW move back out on its own? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 7:24 AM 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 = Something 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
RE: [OS-webwork] Reflection
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
Re: [OS-webwork] Reflection
Amen (great point abot JMS, btw)! This is _sandbox_, PLEASE everyone stop making things so dramatic. All I'm doing is putting things in there for us to discuss and toy with. Then we talk. That's the idea: Write, talk, write some more. Not write, talk, abandon project ;) -Pat - Original Message - From: Jason Carreira [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 11:04 AM Subject: RE: [OS-webwork] Reflection I'm not sure I see the disconnect here. What's so different about Xwork? Views can still be JSP / Velocity / XSLT which generates HTML. It's still a great framework for web app development. If the ThreadLocal thing is the only sticking point, then lets talk about that. I'm personally for the changes Patrick made, as I think it makes the framework much more flexible. For instance, you could queue actions using JMS with all of the context (the ActionInvocation, or whatever Patrick has named it) carried along. However, that said, if it's such a big deal that people are talking about forking the code base and splitting Xwork and Webwork, then I think we should roll it back and discuss. -Original Message- From: matt baldree [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Reflection I think there are two directions here and I don't see any easy resolution at this stage. So, yes I think two projects make sense. My next question is Is there room for these two projects at OS? Does it make sense or will it be a distraction since they do have overlap? Should WW move back out on its own? -Matt - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 12, 2003 7:24 AM 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 = Something 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 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
Re: [OS-webwork] Reflection
On Sunday, January 12, 2003, at 08:24 AM, Rickard Öberg wrote: 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? Hmmm, That thought has occurred to me more than once in the last few days. I am certainly not feeling much love for the direction xwork is headed in. I'd bow out and not care or be interested, unfortunately I can't do that as I have a lot invested in webwork, and would rather use something that is maintained and suchlike. So why not have the xwork crowd go ahead and xwork, and maybe others could work on webwork 1.4/2.0? xwork need not care about backward compatibility or have web as its main focus. Webwork would be considerate to existing users and still focus on the web (while not ruling out non-web clients). Hani --- 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
RE: [OS-webwork] Reflection
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
