Re: [OS-webwork] XWork: core concepts
Philipp Meier wrote: These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. [...] Just to make it clear: This is your needs, right? It doesn't prevents us from having a filter or servlet based dispatcher like webwork has now, right? They could even live happily together with one mapped to *.action and the other mapped to sth. else. My needs include a dispatcher like the current, so I'm happy to work on providing one. It could be possible to add a flag for whether includes are mandatory or not. /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] XWork: core concepts
Peter Kelley wrote: Good to have you back I'm not back. I'm trying to see whether it's any point in me restarting the XWork. Are views a core concept ? Tricky one. Yes, I guess they should be, somehow. The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) /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
[OS-webwork] Getting rid of thread locals
In effort to ditch the servlet paradigm, any thoughts on changing ActionContext from being a ThreadLocal to just a normal Map? I've got some code I can commit to CVS if you'd like to see how it would work. -Pat --- 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] XWork: core concepts
I'm looking into using Xworks mostly for actions with reuse of actions in all three settings. Main use: Swing/SWT application; secondly, webservices and web application. I'd be interested to see how the same action could be reused, with just switching of dispatcher/interceptor necessary for integration on each platform. My alternative is to roll my own action framework, with basically the same features that the core dispatcher and FactoryProxies has today (+ standard error reporting, transparent handling of Undo and some other things). I'm impressed by a lot of the stuff in WW today, so my guess is that it would in large parts be a rewrite of WW... But it would of course be preferrable to have a widely used framework instead (perhaps with readymade code for at least some of the usecases) ;-) cheers, /Måns -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg Sent: den 11 januari 2003 09:30 To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork: core concepts Peter Kelley wrote: Good to have you back I'm not back. I'm trying to see whether it's any point in me restarting the XWork. Are views a core concept ? Tricky one. Yes, I guess they should be, somehow. The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) /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
[OS-webwork] XWork cvs updated
A summary of the changes (read below for more): * Removed ActionContext ThreadLocal in favor of a simple context Map * Modified View, Action, and InterceptorChain interfaces/objects to have access to the context Map * Removed ActionFactory entirely in favor of interceptors * Removed GenericDispatcher in favor of a much simpler Dispatcher class * Removed original ValueStack in favor of an OgnlValueStack --- OK, I've updated the CVS stuff. The major thing here is that I got rid of ThreadLocals. Instead of a GenericDispatcher there is a Dispatcher object that can either re-use an existing context or create a new context. To run an action, you do: HashMap context = new HashMap(); context.put(xwork.action.name, Foo); new OgnlValueStack(context); Dispatcher d = new Dispatcher(context); d.executeAction(); That's it! I'll digest the lines one at a time: 1) Creates the context map 2) sets the action name 3) creates a value stack using Ognl and associates it with the context 4) instantiates a Dispacher based on this context 5) executes the action, including all interceptors The code above can actually be the follow, but I wanted to go over what was happening first: Dispatcher d = new Dispatcher(Foo); d.executeAction(); Basically, the other constructor of Dispatcher will set up the context accordingly. I've modifed Jason's interceptor code (which RULES by the way, I've already removed the ActionFactory entirely and created a ParametersInterceptor as well as ChainingInterceptor), such that the InterceptorChain object holds on to a reference of the context map and can give be accessed by the interceptors. Likewise, the View inteface now takes the context map as well. And lastly, so does the Action interface. They all take a single argument, Map context. Of course, all these changes I've made mean compatability is MUCH harder now. On the other hand, I think we're also MUCH closer to a kick ass framework. Let's not worry about compatability, right now I just want to keep going back and forth with various designs. Jason and I have started it, hopefully Rickard and others can also join in as well. -Pat --- 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] Getting rid of thread locals
Err, how is ThreadLocal servlet related? How would any of the context stuff work without it? On Saturday, January 11, 2003, at 03:56 AM, Patrick Lightbody wrote: In effort to ditch the servlet paradigm, any thoughts on changing ActionContext from being a ThreadLocal to just a normal Map? I've got some code I can commit to CVS if you'd like to see how it would work. -Pat --- 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] XWork: core concepts
+1 - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 6:29 AM Subject: Re: [OS-webwork] XWork: core concepts On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- 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] XWork: core concepts
It could be possible to add a flag for whether includes are mandatory or not. Seems like this is exactly what interceptors are for. You don't want to have actions accessible directly from a url? Then add the interceptor that prevents it. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- 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] XWork: core concepts
A little poll: As long as you are aware that any result from this poll is basically meaningless I'm fine with this. It was pretty obvious last time this type of thing was asked on the mailing list (URLTag) and it was acted on the result, that the response that was given was grossly misleading. Better safe then sorry, should be a design goal within OS just as minimising surprise is :P Now, to answer this myself: *) How many have actions that are used with more than one kind of dispatcher? I have at least two actions I want to execute also from a command line. *) How many are using WebWork in Swing apps? Not me, but I'd never touch Swing. I have from time to time considered using actions from SWT though. In my opinion, the only really solid argument for using WW over say Struts is that we are not locked up in a certain environment. I firmly believe that the core parts of XW can easily avoid being tied up to servlets, as WW does now. Note that this doesn't mean that the XW-servlet package, if you will, will be a lot easier to work with due to a number of features that simplify development. Drawing a line where servlet code can start in XW is very important, and since you don't really need to include ALL of XW in non-servlet code (after all you can't) this line doesn't need to be drawn so that the design is hampered in any way. The line is just so we can point to it and say: if you want to port this app to a non-servlet system don't cross this. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- 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] Getting rid of thread locals
ThreadLocal implies that you always have a single thread throughout the lifecycle of the action (prepare, execute, print results). This is true for a servlet container (single thread/request), but not so in other areas. If you look at the code, the context Map is being passed around. I don't really see it as that bad, but I guess that's all subjective. -Pat - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 4:15 AM Subject: Re: [OS-webwork] Getting rid of thread locals Err, how is ThreadLocal servlet related? How would any of the context stuff work without it? On Saturday, January 11, 2003, at 03:56 AM, Patrick Lightbody wrote: In effort to ditch the servlet paradigm, any thoughts on changing ActionContext from being a ThreadLocal to just a normal Map? I've got some code I can commit to CVS if you'd like to see how it would work. -Pat --- 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 --- 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] Getting rid of thread locals
On Sat, Jan 11, 2003 at 08:11:26AM -0800, Patrick Lightbody wrote: ThreadLocal implies that you always have a single thread throughout the lifecycle of the action (prepare, execute, print results). This is true for a servlet container (single thread/request), but not so in other areas. Can you please tell of any other case? I think it's not to bad to constrain the execution environment of an action the be a single thread. The sequence of execution is sth. like Client-Dispatcher-Action, so the real constraint would be that the Dispatcher ensures this. If you look at the code, the context Map is being passed around. I don't really see it as that bad, but I guess that's all subjective. The usage of ThreadLocals is two edged sword. On the one hand, Thread locals avoid to pass a context all around, but on the other hand, it takes some time to understand how to use them. However this would actually only affect XWork developer, not the users of XWork. IMHO Passing a context is no pain either because this could always done in the constructor of the Action, View or anything because theese are used only once in webwork. So this is a matter of taste. Personally I would vote for not using ThreadLocals, where possible. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01149/pgp0.pgp Description: PGP signature
Re: [OS-webwork] XWork: core concepts
boxed wrote: It could be possible to add a flag for whether includes are mandatory or not. Seems like this is exactly what interceptors are for. You don't want to have actions accessible directly from a url? Then add the interceptor that prevents it. Good point. That would work. /Rickard --- 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] Getting rid of thread locals
Patrick Lightbody wrote: ThreadLocal implies that you always have a single thread throughout the lifecycle of the action (prepare, execute, print results). This is true for a servlet container (single thread/request), but not so in other areas. No, it doesn't imply that. If the execution chain is broken, then one simply takes the context and reuse it whenever the chain is restarted. /Rickard --- 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] Getting rid of thread locals
I know, it is possible to do this, but it's a bit more complicated, if only because the user's (developers, whatever) don't actually _see_ the backing map without opening up some stack method that provides access to the ThreadLocal. If we pass the context around, all that happens is that execute() - execute(Map context). Before anyone shoots this down, I really want you to look at the code that is in CVS. It's not that bad and it makes things much simpler -- which is a primary goal of XWork. I really think this new code is more powerful and much simpler than the existing WebWork core. If you check out the source (especially with DispatcherTest as well as deploy the war and access Foo.action -- same thing), you'll find that it's pretty appealing (IMHO). :) -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 10:15 AM Subject: Re: [OS-webwork] Getting rid of thread locals Patrick Lightbody wrote: ThreadLocal implies that you always have a single thread throughout the lifecycle of the action (prepare, execute, print results). This is true for a servlet container (single thread/request), but not so in other areas. No, it doesn't imply that. If the execution chain is broken, then one simply takes the context and reuse it whenever the chain is restarted. /Rickard --- 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] XWork: core concepts
Making unnecessary changes, IMHO, is definitely 'making it unpleasant'. While I see that backward compatibility is too hard to keep (or so I'm told) given all that people want xwork to be, I really dislike the approach of change for changes sake. I deliberately avoided the very early versions of webwork because I knew it's rapidly changing, and I'm not the kind of person that is very tolerant of non-backward compatible changes or changes that go in due to 'coolness' factor or some highschool concept of what constitutes good design when it comes to 'real' work. However, at this point I have a rather large number of classes built off of webwork actions. I suspect that there are many other webwork users in the same boat. Now, some of these users are hobbyists and don't mind tinkering about for fun and spending a few days porting their apps to xwork so they can be on the cool side of the fence again. However, I suspect many of these users are in the same situation I'm in, and do not look forward to changing all their existing code to support a new API that after all is said and done, ends up doing pretty much the same things they always did without much in the way of advantages. I wrote this mainly in response to the switch to Maps from ThreadLocals. All things being equal, I couldn't care less which is used. However, given the lack of strong reasons for either case, my vote very strongly goes towards keeping things the same. xwork is supposed to be a better, easier more configurable version of webwork for all its users, not the patrickization of webwork. On Saturday, January 11, 2003, at 03:20 PM, Patrick Lightbody wrote: No one is going to make it unpleasant... you can be sure of that. It'll be easier and more pleasant for everything. If you look at the CVS, I think you'll agree. Today I'm going to put in an Interceptor that reads a components.xml file, which contains a list of components, and pulls three things from the file: --- 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
[OS-webwork] Slow performance using ww:iterator tag (version 1.2.1)?
Happy new year everyone! I have a simple question about the webwork:iterator tag and performance using WW 1.2.1. I have this list of countries that contains 245 entries. When I execute the following fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of you WW gurus have some pointers on making it faster? I can't simply cache the select list because the form is for an address book so the selected value is user specific. %@ taglib uri=webwork prefix=ww % %@ taglib uri=webwork prefix=ui % % long start, end = -1; % table width=100% tr !-- start cell with webwork components -- ww:action name='CountriesList' id=countrieslist/ % start = System.currentTimeMillis(); % ui:select label='Country' name='country' list=@countrieslist/countries listKey='countryCode' listValue='description'/ % end = System.currentTimeMillis(); % !-- end cell with webwork components -- /tr /table p Execution Time=%= ((double)end - start) / 1000.0 % sec /p Thanks, Kirk Rasmussen Lucasfilm Ltd. --- 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
[OS-webwork] IoC and ComponentInterceptor
I've added Joe Walnes' Component stuff and modified it to fit in the
Interceptor framework. It's really cool. I recommend that you check out the
sources and run the example-war target. As you can see, each time you
reload, the counter will increment. The cool thing is that if you look at
the code for SimpleCounter, you'll see it is just:
public String execute(Map context) {
counter.incrementCounter();
return SUCCESS;
}
The ComponentInterceptor automatically handles the rest based on the
information found in src/example/components.xml.
-Pat
---
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] XWork: core concepts
I agree here. I like having the safety of knowing that if we decide to re-architect the presentation layer of our app (and we're looking at re-doing some of it with Thinlets), then there could be a framework there to let us do that... -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 11, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork: core concepts I would highly recommend against going down this path. Otherwise, just focus on WebWork 1.4. Plus, even if all our actions are used for the web, remember that by making the core framework non-web-based, you also make testing much easier as well. -Pat - Original Message - From: matt baldree [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 5:34 AM Subject: Re: [OS-webwork] XWork: core concepts +1 - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 6:29 AM Subject: Re: [OS-webwork] XWork: core concepts On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- 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 =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
