Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
Greg Reddin ha scritto: Yep, that's come up before. Personally, I don't like the idea. Think about how complicated that could become with nested, nested defs. I don't see it so catastrophic. In certain cases it is better to see an entire structure as a tree instead of a lot of "see definition x". In my experience with Tiles, what I did very frequently is a base definition and a lot of extended definitions, one for each page. Probably nested (I called them "inline" but probably "nested" is a better term) definition in these cases are clearer. I'd prefer better support for including other definitions as a tile attribute. Maybe that support is there already and i just haven't tried it. Isn't there yet? Do you mean: I don't think it is what you mean, because this is already there. Can you clarify what you mean with an example? Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
Gary VanMatre ha scritto: Clay symbols are similar to the "put"s. The difference is that they are pushed to all nested definitions and not just a single level. They are scoped from the outer to the inner. They can be overridden at any level. This would be nice to have in Tiles, though I think this behaviour should be configurable, i.e. some flag that tells the Tiles engine to deliver or not to deliver the attribute to the innermost levels. I have to learn this Clay thing :-) Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (WW-1334) Showcase example does not work with JDK 5
Sorry guys, I missed out xwork-conversion.xml. I should really be more careful as this is the 2nd time within 2 months. :-P I'll commit in the missing file asap. Thx for looking into it, Don and Wendy. Owe you guys one . ;-) regards - Original Message From: Don Brown (JIRA) <[EMAIL PROTECTED]> To: issues@struts.apache.org Sent: Friday, 9 June, 2006 1:37:16 PM Subject: [jira] Commented: (WW-1334) Showcase example does not work with JDK 5 [ http://issues.apache.org/struts/browse/WW-1334?page=comments#action_37459 ] Don Brown commented on WW-1334: --- Agreed, we have two different issues. As for the original of not working with Java 5, I can confirm it does so I'd like to mark this as worksforme. The missing xwork-conversion.xml problem, as you noted Wendy, is probably due to a file Toby forgot to commit. Until then, my commit comments it out, so I can currently run showcase without any problems. > Showcase example does not work with JDK 5 > - > > Key: WW-1334 > URL: http://issues.apache.org/struts/browse/WW-1334 > Project: Struts Action 2 > Type: Bug > Components: Examples > Environment: JDK 5, Tomcat 5 > Reporter: Tamara Cattivelli > > If you want to run the showcase example, you get the following error: > 06.06.2006 15:27:34 org.apache.catalina.core.StandardWrapperValve invoke > SCHWERWIEGEND: Servlet.service() for servlet jsp threw exception > javax.xml.transform.TransformerFactoryConfigurationError: Provider > org.apache.xalan.processor.TransformerFactoryImpl not found > at javax.xml.transform.TransformerFactory.newInstance(Unknown Source) > at > com.opensymphony.xwork.util.DomHelper$DOMBuilder.(DomHelper.java:121) > at com.opensymphony.xwork.util.DomHelper.parse(DomHelper.java:98) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.loadConfigurationFile(XmlConfigurationProvider.java:631) > at > com.opensymphony.xwork.config.providers.XmlConfigurationProvider.init(XmlConfigurationProvider.java:90) > at > com.opensymphony.xwork.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:86) > at > com.opensymphony.xwork.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:46) > at > com.opensymphony.xwork.DefaultActionProxy.(DefaultActionProxy.java:56) > at > com.opensymphony.xwork.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:46) > at > org.apache.struts.action2.components.ActionComponent.executeAction(ActionComponent.java:219) > at > org.apache.struts.action2.components.ActionComponent.end(ActionComponent.java:126) > at > org.apache.struts.action2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:35) > at > org.apache.jsp.WEB_002dINF.decorators.main_jsp._jspx_meth_saf_action_0(main_jsp.java:494) > at > org.apache.jsp.WEB_002dINF.decorators.main_jsp._jspService(main_jsp.java:189) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > at > com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java:156) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:59) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coy
Re: [action2] /s /xwork.xml /action.xml
A key problem is renaming the xwork.xml file. Last time I looked, the
token "xwork.xml" is hardwired, so we'd have to change the way OS
XWork is configured, or use a "Rube Goldberg" bootstap file.
As to the rest of it, I'm ready to let it drop, as we have other "fish to fry".
-Ted.
On 6/9/06, Don Brown <[EMAIL PROTECTED]> wrote:
The webwork renaming issue goes deeper than just those 3 or so files
and affects things like template variables, the static resources
prefix, the dojo package, etc. Currently, they have all be renamed to
'struts' consistently, however if we switched to 'struts-action' or
even 'action', I'm not sure it would be appropriate name for all those
areas.
Ted, are you suggesting just renaming those configuration files or a
renaming exercise that goes deeper? If it is the former, I just don't
think 'action' is appropriate for things like template variable names
as they would be confused with the Action itself, and complex names
like 'struts-action' obviously wouldn't work for such variable names.
If it is the latter, let's put both options on the table and let the
community vote. If the community would rather use something
different, I agree that we need to do that now.
Don
On 5/1/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> As much as I love shorter names, I still think "struts-action" is more
> user friendly. I see "struts" and immediately know what the file is. I
> can't say the same for "action"; it's missing an important namespace
> qualifier.
>
> If anything, I would shorten it to "struts.xml", but like we said
> before, we could run into a conflict if the user uses shale or
> something at the same time. Is this really worth worrying about, i.e.
> does Shale or some other Struts project already use or plan on using
> "struts.xml"?
>
> Actually, on my project, we used to name our files "foo-xwork.xml",
> but now we name them "foo.xwork". Maybe there's another option along
> those lines...
>
> Bob
>
> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
HTH, Ted.
* http://www.husted.com/struts/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[action2] showcase resources
Showcase resource needs to be in a separate directory for maven to include them when doing a war package. now. eg. apps/src/main/java/org/apache/struts/action2/showcase/validation/ contains resources like - FieldValidatorsExampleAction.properties - FieldValidatorsExampleAction-conversion.properties - etc. that should be in apps/src/main/resources/org/apache/struts/action2/showcase/validation/ I think we should move them. Thoghts? Pat, will this affect quickstart? Tia. regards
Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
On Jun 9, 2006, at 3:10 AM, Antonio Petrelli wrote: I don't think it is what you mean, because this is already there. Can you clarify what you mean with an example? No that's what I meant. I just never have actually used that. How does that look on the JSP doing ? You'd think I'd know this already :-) If that works the way I think it does then I'd much prefer that than the "nested" tiles. I'm not against support for the nested tiles, I'd probably just never use it myself. I think it makes things look cleaner if you do something like the above. Of course I rarely use nested anonymous classes with Java either. But it's just a personal preference. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] building showcase webapp using maven
When building showcase war file using maven, it seems that xwork-1.2-SNAPSHOT.jar is being included in /WEB-INF/lib and so is xwork-2.0-SNAPSHOT.jar. It should only include xwork-2.0-SNAPSHOT.jar i guess. Showcase pom.xml seems to indicate a dependency on struts-core-2.0-SNAPSHOT, and struts-core's pom.xml indicate dependency on xwork-2.0-SNAPSHOT, i wonder why xwork-1.2-SNAPSHOT.jar is included in it. Any thoughts? thx in advance.
Re: [action2] showcase resources
created a jira issue at http://issues.apache.org/struts/browse/WW-1336 - Original Message From: tm jee <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Friday, 9 June, 2006 9:50:03 PM Subject: [action2] showcase resources Showcase resource needs to be in a separate directory for maven to include them when doing a war package. now. eg. apps/src/main/java/org/apache/struts/action2/showcase/validation/ contains resources like - FieldValidatorsExampleAction.properties - FieldValidatorsExampleAction-conversion.properties - etc. that should be in apps/src/main/resources/org/apache/struts/action2/showcase/validation/ I think we should move them. Thoghts? Pat, will this affect quickstart? Tia. regards
Re: [action2] building showcase webapp using maven
On 6/9/06, tm jee <[EMAIL PROTECTED]> wrote: When building showcase war file using maven, it seems that xwork-1.2-SNAPSHOT.jar is being included in /WEB-INF/lib and so is xwork-2.0-SNAPSHOT.jar. It should only include xwork-2.0-SNAPSHOT.jar i guess. Showcase pom.xml seems to indicate a dependency on struts-core-2.0-SNAPSHOT, and struts-core's pom.xml indicate dependency on xwork-2.0-SNAPSHOT, i wonder why xwork-1.2-SNAPSHOT.jar is included in it. mvn clean mvn install -X Maven will print the path to every dependency, and you should be able to see where the old version is coming from. You can get rid of it with an , but Maven is supposed to mediate dependencies and pick the "closest" one. Maybe that isn't working for snapshots? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] building showcase webapp using maven
On 6/9/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > Showcase pom.xml seems to indicate a dependency on struts-core-2.0-SNAPSHOT, and struts-core's pom.xml indicate dependency on xwork-2.0-SNAPSHOT, i wonder why xwork-1.2-SNAPSHOT.jar is included in it. mvn clean mvn install -X I tried this and only got xwork-2.0-SNAPSHOT in WEB-INF/lib. My guess is that showcase used to depend (transitively) on 1.2-SNAPSHOT and you have an old dependency in WEB-INF/lib. I think 'mvn clean' will fix the problem, let us know if not. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] building showcase webapp using maven
Thx for the tips Wendy. It is as you predicted, i have an old xwork-1.2-SNAPSHOT.jar in my target/struts-showcase/WEB-INF/lib temporary build directory. Doing a clean does the tricks. :-) Thx a lot. - Original Message From: Wendy Smoak <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, 9 June, 2006 11:38:01 PM Subject: Re: [action2] building showcase webapp using maven On 6/9/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > Showcase pom.xml seems to indicate a dependency on > > struts-core-2.0-SNAPSHOT, and struts-core's pom.xml indicate dependency on > > xwork-2.0-SNAPSHOT, i wonder why xwork-1.2-SNAPSHOT.jar is included in it. > > mvn clean > mvn install -X I tried this and only got xwork-2.0-SNAPSHOT in WEB-INF/lib. My guess is that showcase used to depend (transitively) on 1.2-SNAPSHOT and you have an old dependency in WEB-INF/lib. I think 'mvn clean' will fix the problem, let us know if not. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] /s /xwork.xml /action.xml
Ok, I'm open to change xwork.xml to action.xml and even make that configurable
in struts.properties. Wasn't action.xml the name of the original Struts
configuration file? That has a nice symmetry to it.
I looked at how to make that change, but I think we still need to do some work
with xwork's config. It makes heavy use of this XWorkStatic class with static
retrieval methods. Worse, the static use creates a circular dependency between
ConfigurationManager and DefaultConfiguration for the purposes of retrieving the
list of ConfigurationProviders from ConfigurationManager. Furthermore, there
doesn't seem to be a way to inject your own list of providers before the default
list is created, since to do so, you have to get the ConfigurationManager
instance from XWorkStatic and by doing so, you implicitly create one with a
default list of providers.
I want to wait to see Jason's thoughts before making this change.
Don
Ted Husted wrote:
A key problem is renaming the xwork.xml file. Last time I looked, the
token "xwork.xml" is hardwired, so we'd have to change the way OS
XWork is configured, or use a "Rube Goldberg" bootstap file.
As to the rest of it, I'm ready to let it drop, as we have other "fish
to fry".
-Ted.
On 6/9/06, Don Brown <[EMAIL PROTECTED]> wrote:
The webwork renaming issue goes deeper than just those 3 or so files
and affects things like template variables, the static resources
prefix, the dojo package, etc. Currently, they have all be renamed to
'struts' consistently, however if we switched to 'struts-action' or
even 'action', I'm not sure it would be appropriate name for all those
areas.
Ted, are you suggesting just renaming those configuration files or a
renaming exercise that goes deeper? If it is the former, I just don't
think 'action' is appropriate for things like template variable names
as they would be confused with the Action itself, and complex names
like 'struts-action' obviously wouldn't work for such variable names.
If it is the latter, let's put both options on the table and let the
community vote. If the community would rather use something
different, I agree that we need to do that now.
Don
On 5/1/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> As much as I love shorter names, I still think "struts-action" is more
> user friendly. I see "struts" and immediately know what the file is. I
> can't say the same for "action"; it's missing an important namespace
> qualifier.
>
> If anything, I would shorten it to "struts.xml", but like we said
> before, we could run into a conflict if the user uses shale or
> something at the same time. Is this really worth worrying about, i.e.
> does Shale or some other Struts project already use or plan on using
> "struts.xml"?
>
> Actually, on my project, we used to name our files "foo-xwork.xml",
> but now we name them "foo.xwork". Maybe there's another option along
> those lines...
>
> Bob
>
> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [action2] /s /xwork.xml /action.xml
> I looked at how to make that change, but I think we > still need to do some work > with xwork's config. It makes heavy use of this > XWorkStatic class with static > retrieval methods. Worse, the static use creates a > circular dependency between > ConfigurationManager and DefaultConfiguration for the > purposes of retrieving the > list of ConfigurationProviders from > ConfigurationManager. Furthermore, there > doesn't seem to be a way to inject your own list of > providers before the default > list is created, since to do so, you have to get the > ConfigurationManager > instance from XWorkStatic and by doing so, you > implicitly create one with a > default list of providers. > > I want to wait to see Jason's thoughts before making > this change. Yeah, that stuff's crappy, all right. I just created the XWorkStatic class on the flight back from SF as a "ghetto" to put the statics in until we could get rid of them altogether. I wanted to get all of them into that one place so they'd be easier to identify and deal with. I only got around to moving the one, the Configuration, but there's more to be moved... dragged into the XWorkStatics and shot... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=28769&messageID=65844#65844 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some comments & questions on Struts 1.3 chain & Strecks
Joe - Thanks for the detailed reply. While supporting Spring integration is very important with Strecks, I took the decision to avoid using Spring to configure the framework extensions - I've wanted to limit dependencies to those already present in Struts. Regards, Phil Joe Germuska wrote: I have a couple of questions/thoughts/observations that have arisen: - the chain configuration appears to apply across the application as a whole rather than per module. This differs from the 1.2 request processor which can be varied/subclassed on a per module basis. (Of course, you can still subclass RequestProcessor on a per-module basis, but the whole point of the chain is that you should not need to do that) well, I think we have found that very few active Struts developers use modules, so some module-centric things get overlooked, unfortunately. That said, the per-application config is the loading of the catalog factory. It *is* possible to change which command is looked up in the catalogs and executed to process the request as part of the controller-config on per-module basis. - the chain seems to be quite good at allowing you to vary the request processing flow. It is more difficult to apply configuration or make services accessible to groups of commands in the chain. One way I can see to do this is by subclassing ComposableRequestProcessor (not that old chestnut again), overriding init(ActionServlet,ModuleConfig), then adding the relevant services to the chain context, using getApplicationScope().put(...). Another way, apparently, would be to load the configuration in the constructor or synchronized block of one of the chain commands, then use getApplicationScope().put(). It would be nice if you could configure chain commands using some form of dependency injection, a la Spring, and allow these services to be added via the chain config file. (I suppose I should be addressing this to the chain developers mailing list, although I suspect that most of the chain developers are on this list as well). (yes, I think this is effectively the chain developers list :) ) Don't forget that you can configure basic properties on any command simply by setting xml attributes and letting digester and beanutils handle the population. This is limited to values, not references, and is limited by all the limitations for type conversion that BeanUtils has, but it can still get you pretty far. It's not so elegant, but for anything beyond that, I'd probably just have command properties whose values were spring bean names, and then have the command retrieve the Spring ApplicationContext from the ServletContext, and look up a bean from there. Of course, it's possible to create commands and chains in a spring beans XML file too; it's a bit awkward in terms of syntax, but it can be done. Technically, you could create an entire alternative CatalogFactory in Spring (or as many as you like) -- there's just no good way to inject a CatalogFactory instance into a ComposableRequestProcessor instance, because of the way that Struts initialization happens. You could have a SpringAwareComposableRequestProcessor which found the Spring ApplicationContext during the init(...) method and looked up its CatalogFactory there. I think that in general, the Struts 1.x initialization process is awfully constraining, but I haven't had any substantially better ideas about how to do it. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Struts Action 2.0.0 Issues
I changed the JIRA version to 2.0.0 and have started to pair down the actual tickets we are signing up to resolve for 2.0.0. Please go through the list of those improvements moved to Future and see if there are any you'd be willing to tackle for this release. Also, I'll be moving items from our TODO lists over to issues so be prepared for more emails :) This JIRA report [1] should contain everything we are planning for in the 2.0.0 release slated for August. Again, we are trying to keep the scope small so we can have a stable release out there for users. I think getting a minimal yet timely release is more important than getting everything right on our first go. Therefore, I recommend that we defer many of the more drastic changes from our Rough Spots page to 2.1 to aid in migration and release speed. I'm fine deprecating core classes, but let's hold off on removing them. While this is a major 2.0 release from a Struts point of view, this is in effect a minor 2.3 release for all the existing WebWork applications. Please feel free to jump in and be sure to use JIRA to track everything. Let's get this show on the road :) Don [1] http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10030&fixfor=21510 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
