Re: [s2] Roadmap for the core taglib
Even though I argued for it initially, I'm still not 100% sure we want to pull out the tags. Not only is it more confusing to users, but it makes tag extension harder, since plugins can't provide plugin points to other plugins. That means we'd have to keep the majority of the tag infrastructure in core, which gains us little, IMO. One reason to pull them out is it better facilitates new EL's. With how the tags work right now, they depend on the OGNL EL from a syntax perspective mostly as the API dependency has been abstracted. If you created a JUEL plugin, for example, you'd probably want to rewrite most of the tags to better take advantage of deferred expressions. Anyways, I'm not saying there aren't solutions, just that we need to think about it some more. At this point, I'm not sure the potential cost outweights the benefits. Don On 11/5/07, Ted Husted [EMAIL PROTECTED] wrote: On Nov 4, 2007 9:33 AM, Tom Schneider [EMAIL PROTECTED] wrote: Speaking of the core taglib, what ARE we going to do with it. There's been talk of moving them to a separate plugin, reimplementing them in a java, etc. It would be nice to know from a roadmap prespective about where the core taglib is headed--I have several plugins that would be affected by it. My understanding is that we would like to move the existing tags to a plugin, and create a standard bundle that would include the tag-plugin, the code-behind plugin, and the core as a single JAR. The code-behind plugin will subsume the zero-config and annotations code, as well as the SmartURls plugin. * [s2] Should tags be their own plugin? * [S2] Plugins gone wild! One place to document decisions like this is the STATUS.txt file under SVN. * http://svn.apache.org/viewvc/struts/current/STATUS.txt?view=markup In terms of the longer-term roadmap, work is being done on a JSP 2 taglib that won't use the templating system at all. Don's also been doing some preliminary refactoring in XWork so that the expression language can be made pluggable, meaning we would also be able to plugin something else instead of OGNL. -Ted. At a minimum, if we're going to keep the ftl template at all, then I would recommend we bring in tabletags. (At least the paging and sorting tags) Looking at the downloads page for tabletags, there have been over 7000 downloads over the last year. That seems significant to me. The table tag itself probably needs a little TLC at the moment, but I think the other tags are pretty solid. I'm also open to looking at other tags that should be brought in--again this is contingent on what we decide to do with them pesky tags. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai
The Bamboo messages to go [EMAIL PROTECTED], which you may not be on. As for the port, just pick one, say 8887. Don On 11/5/07, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Indeed so it seemsI didn't get an email, that's weird... Anyway, it seems that the port 8080 which the integration test is running under is taken...obviously (of course I had to pick one of the most commonly used) Which port can I use? Nils-H On Nov 5, 2007 12:50 PM, Don Brown [EMAIL PROTECTED] wrote: Nils, you broke the build: http://opensource.bamboo.atlassian.com/browse/STRUTS Don On 11/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: nilsga Date: Mon Nov 5 02:06:31 2007 New Revision: 591942 URL: http://svn.apache.org/viewvc?rev=591942view=rev Log: WW-2296 Added jetty-pluto embedded to the sample application. Also added some new samples and a new integration test. Added: struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp struts/struts2/trunk/apps/portlet/src/test/ struts/struts2/trunk/apps/portlet/src/test/java/ struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java struts/struts2/trunk/apps/portlet/src/test/java/org/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java Modified: struts/struts2/trunk/apps/portlet/ (props changed) struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai
Oh, and thanks for fixing it so quick :) Don On 11/5/07, Don Brown [EMAIL PROTECTED] wrote: The Bamboo messages to go [EMAIL PROTECTED], which you may not be on. As for the port, just pick one, say 8887. Don On 11/5/07, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Indeed so it seemsI didn't get an email, that's weird... Anyway, it seems that the port 8080 which the integration test is running under is taken...obviously (of course I had to pick one of the most commonly used) Which port can I use? Nils-H On Nov 5, 2007 12:50 PM, Don Brown [EMAIL PROTECTED] wrote: Nils, you broke the build: http://opensource.bamboo.atlassian.com/browse/STRUTS Don On 11/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: nilsga Date: Mon Nov 5 02:06:31 2007 New Revision: 591942 URL: http://svn.apache.org/viewvc?rev=591942view=rev Log: WW-2296 Added jetty-pluto embedded to the sample application. Also added some new samples and a new integration test. Added: struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp struts/struts2/trunk/apps/portlet/src/test/ struts/struts2/trunk/apps/portlet/src/test/java/ struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java struts/struts2/trunk/apps/portlet/src/test/java/org/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/ struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java Modified: struts/struts2/trunk/apps/portlet/ (props changed) struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
Ah, another good reason not to kill the codebehind plugin as it currently exists. I'm still not convinced we need drastic changes here, more like just filling out functionality. Don On 11/7/07, Ian Roughley [EMAIL PROTECTED] wrote: If it were me, I'd finish the book using struts.xml, and go to work on a second edition as soon as SmartURLs goes to 1.0 (even if the first edition isn't done yet). Getting a couple of solid Struts 2.0 books out there is the best way to drum up marketshare for a Struts 2.1 edition. Bummer... mine already went to press (available Nov 26th), and I used XML and the basic annotations/code-behind. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
On 11/7/07, Tom Schneider [EMAIL PROTECTED] wrote: Ian brings up a good point in that we'll have to decide how to handle some things like I18N/type conversion/method invocation. Not all EL's are created equal and OGNL probably is a little more flexible and powerful than most. Then even if we get all that working, what's the migration strategy? Type conversion isn't tied to OGNL in 2.1. XWork has a new API (copied from OGNL) to abstract type conversion. Of course not all EL's support type conversion in the same way, so there may be issues down the road. i18N isn't tied at all to OGNL, so I agree with Chris here as well. Even if the JUEL plugin works out, we probably won't be shipping it till Struts 2.2 at the earliest. I think it is awesome that Tom is working on it now, though, as I think it has a better future than OGNL, particularly for JSP users. Seam has shown you can build a solid framework on UEL and even extend it to add the new features you need. Don Don Tom On 11/6/07, Ted Husted [EMAIL PROTECTED] wrote: On Nov 6, 2007 3:00 PM, Ian Roughley [EMAIL PROTECTED] wrote: For your comment, I am assuming you are saying the message is - changing the EL means changing everything the EL touches, and selecting an EL means making a choice on everything the EL touches, correct? At this point, JUEL is just something Tom committed to the sandbox, like yesterday (literally). We aren't sending any messages to anyone else, since I doubt that many of us have had a chance to look at it ourselves yet. If JUEL turns out to be too much work, then none of us will use it ourselves, and it will simply wither away. The general idea is that we are building the framework that we want to use, and then sharing the wealth with others. But, Job 1 is that it has to be the framework that *we* want to use. Evidentially, Tom thinks he might want to use a framework that supports JUEL. The next question is whether anyone else feels the same way. -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]
Re: Struts 2 Plugin for Grails?
On 11/8/07, Matt Raible [EMAIL PROTECTED] wrote: What I'd like is to use Grails to develop my application, but have it use Struts 2 under-the-covers instead of Spring MVC. As far as code differences between writing a Spring MVC Grails Controller and a Struts 2 Grails Controller - I don't think there needs to be any. Interesting, I didn't know Grails used Spring under the covers. Might look into that during the hackathon. One of the main reasons I chose Struts 2 for the prototype I've done was because it allowed me to call methods with arguments from its EL. Since I see a move away from OGNL (and possibly) this feature, it makes me less inclined to use Struts 2. I may be able to see I think a definite condition of accepting the Unified EL would be support for calling methods. If we did go the UEL route, I'd guess we'd be more like Seam, where we extended it to do things like method calls. Again, moving to UEL hasn't been decided and even if it had, it is probably at least a year or two away. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release struts2-archetype-plugin and struts2-archetype-starter version 2.0.11
I've created test builds titled 2.0.11 for the following archetypes: * struts2-archetype-plugin - Creates a Struts 2 plugin * struts2-archetype-starter - Creates a starter Struts 2 app Since they are both pretty simple, I'm combining their votes, so: [ ] +1 - Release them to the wild [ ] +/- 0 - Do the release, but I don't use them [ ] -1 - Don't release them and here is why... Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release struts2-archetype-plugin and struts2-archetype-starter version 2.0.11
+1 On 11/13/07, Don Brown [EMAIL PROTECTED] wrote: I've created test builds titled 2.0.11 for the following archetypes: * struts2-archetype-plugin - Creates a Struts 2 plugin * struts2-archetype-starter - Creates a starter Struts 2 app Since they are both pretty simple, I'm combining their votes, so: [ ] +1 - Release them to the wild [ ] +/- 0 - Do the release, but I don't use them [ ] -1 - Don't release them and here is why... Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence Rate Plugin for the Plugin Registry
Done. Unfortunately, the latest version requires a newer version of Confluence, so I installed an older version. I placed the macro on each plugin page, but found a couple of issues: * Anyone can reset the ratings * The table report doesn't seem to work right, so I didn't put that report on the home page * New votes won't kick off an export of the page, so users using the static page won't see the new votes Still, I think it is better than nothing, so vote away. Don On 11/11/07, Tom Schneider [EMAIL PROTECTED] wrote: I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence Rate Plugin for the Plugin Registry
IMO, every project, no matter where it is hosted, should have a page on that Confluence space and be in the main list. Now, that page might just point to another site where the real docs can be found, but for registration purposes, it should be on that page. When I get time to upgrade Confluence, I'll be installing the metadata plugin so we can more intelligently use the metadata on the plugin's page. Don On 11/14/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: On a related note, what's the policy WRT putting plug-ins in the main list (the section after the news items)? I see the note on the page saying plug-ins hosted externally should be listed as news items, which I've done for my two plug-ins, but it seems there's a number of them in the main list that are hosted at Google code and elsewhere... I'd like to have my plug-ins in the main list so they are available for voting too (I'd think we'd want all plug-ins to have voting available so that those that become popular might be considered for addition to the main Struts distro down the road). Any objections to me adding mine to the list? If not, should that note be removed from the page altogether? Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of Practical Ajax Projects With Java Technology (2006, Apress, ISBN 1-59059-695-1) and JavaScript, DOM Scripting and Ajax Projects (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! Tom Schneider wrote: Thanks for doing this Don, I appreciate you taking the lead on this. Did you vote for all your own plugins? :) Tom On Nov 14, 2007 4:17 PM, Don Brown [EMAIL PROTECTED] wrote: Done. Unfortunately, the latest version requires a newer version of Confluence, so I installed an older version. I placed the macro on each plugin page, but found a couple of issues: * Anyone can reset the ratings * The table report doesn't seem to work right, so I didn't put that report on the home page * New votes won't kick off an export of the page, so users using the static page won't see the new votes Still, I think it is better than nothing, so vote away. Don On 11/11/07, Tom Schneider [EMAIL PROTECTED] wrote: I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence Rate Plugin for the Plugin Registry
I did for most of them, and not always high ratings. For example, the Struts 1 plugin got a 2 :( Don On 11/14/07, Tom Schneider [EMAIL PROTECTED] wrote: Thanks for doing this Don, I appreciate you taking the lead on this. Did you vote for all your own plugins? :) Tom On Nov 14, 2007 4:17 PM, Don Brown [EMAIL PROTECTED] wrote: Done. Unfortunately, the latest version requires a newer version of Confluence, so I installed an older version. I placed the macro on each plugin page, but found a couple of issues: * Anyone can reset the ratings * The table report doesn't seem to work right, so I didn't put that report on the home page * New votes won't kick off an export of the page, so users using the static page won't see the new votes Still, I think it is better than nothing, so vote away. Don On 11/11/07, Tom Schneider [EMAIL PROTECTED] wrote: I know I've mentioned this before, but I was wondering if we could use this plugin: http://www.atlassian.com/software/confluence/plugins/rate.jsp To provide user rating capabilities for the plugin registry. As more and more of the core functionality becomes plugins, I think it makes sense to let people vote on the plugins so new users have an idea of which plugins are the most popular. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
On 11/20/07, Brian Pontarelli [EMAIL PROTECTED] wrote: Here are my thoughts: AFAICT, the questions then become * Which Result annotation syntax to support? ** CB uses a .class reference, SU uses a string setting that corresponds to the Result name. ** CB uses value where SU uses location. SU because it provides more flexibility with respect to action names, mappings, etc. I could go either way with the result type String vs. Class. I tend to prefer remaining close to the XML whenever possible. I feel the same about the value vs. location naming. Again, the XML uses location since that this the DEFAULT_PARAM for most result types, so I prefer that. I prefer type safety wherever possible, but the annotation should probably support both for the rresult type. As for value vs location, value is more convenient since you can just do: @Result(/foo.jsp) for results that use the default result type, and as mentioned, location isn't the param name everywhere. * Do we add an ActionName annotation? I say yes. I think it adds some controls that could be useful for some folks. The codebehind plugin has this in the @Action annotation. You can specify the action name and the namespace for this specific action. I'm not really excited about how it is done, however, particularly the package-level annotations like @ParentPackage, but I'm not sure of a good alternative. Having an annotation on a class that magically applies the setting to all actions in that package seems silly to me (how it works now). * Do we add the extra support for Index pages? I say yes because this is one of my favorite features and I use this heavily. This seems useful, however, I haven't looked at how it is done in smarturls. If it can be done without modifying the action mapper. that would be ideal. * Do we add the base result page setting, so that pages can be placed under WEB-INF (or whatever)? I say yes. It protects those resources that shouldn't be accessible directly by clients. Codebehind actually supports this now - struts.codebehind.pathPrefix - but I see it isn't documented. There are a few others things to consider: * Should we leverage the action.packages configuration or a naming convention for finding action packages? (I prefer convention) I'm not so sure about this one. Would we do something like stripes where we scan for the 'actions' subpackage? I don't see the 'actionPackages' init parameter as too burdensome. * Should we support package level annotations for things like base result location, parent package, new result types, interceptors, etc.? (I say yes) How would this work? Would you put the annotation on any class in the package and it would magically apply for all actions in the package, like how codebehind works now? * If we leverage the action.packages configuration, how do we support actions and results inside the classpath? (Right now it is component.xml, which is not ideal. This is my main reason for convention over configuration for finding action packages) I'm not sure what you mean by this. I should also add, I don't see XML going away nor do I want it to. There will always be more things you can do in XML that you won't be able to do in annotations, and I see the codebehind plugin accepting this fact. I'd like it to add conventions and a few annotations to cover 90-95% of the cases, leaving more involved things like defining results, interceptors, and more complex package-level config to XML. Also, if I haven't mentioned it already, Struts 2.1 supports multiple filter instances in a webapp. This means you could have two filters, each looking for actions in a different root package and using different path prefixes for their results. I'm still not clear why you would be putting templates in two different root directories, but if you wanted to, you can. This is a great first step towards integrating the two plugins. Perhaps the next step, after some more discussion, would be to set up a matrix of the features SmartURLs has that codebehind doesn't, then we can systematically evaluate them in a way that is easy to follow and record. Don -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 CodeBehind/SmartURLs (was Re: Struts 2 Plugin for Grails?)
On 11/20/07, Dave Newton [EMAIL PROTECTED] wrote: I'd think that package-level annotations should go in the package-info.java; that's what it's for, more or less. Perfect! I didn't know about that class, hence my hacky workarounds. Let's definitely use it. Don d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Plugin and auto-generated XHTML Views
The problem with working off XML rather than Java is you lose the type information. In order to build a useful form, for example, you need to know that the 'age' field is a number or that 'created' is a date. XStream puts some data type information into the markup, but not enough to really be useful, and you could argue it doesn't belong there in the first place. Don On 12/2/07, Matt Raible [EMAIL PROTECTED] wrote: I just thought of something that might be an easy way to generate XHTML views for the REST Plugin. What if we used XSL on the client-side with the XML views? As far as browser capabilities, I think client-side XSL could be a hidden gem that hasn't been looked at in a while. Of course, it could also be something that doesn't work very well across browsers. Do you guys think it's worth looking into? If it works, .html (or .xhtml) could render HTML views and we could allow users to override the XSL stylesheet. Matt -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Plugin and auto-generated XHTML Views
On 12/2/07, Jeromy Evans [EMAIL PROTECTED] wrote: I thought I'd just add that I've been thinking along the same line as Matt, but rather than client-side XSTL I've been desperate for a good quality javascript templating library. You mean something like this? http://particletree.com/notebook/templates-in-javascript/ I've done some work with Trimpath's Javascript Templates and have been happy with it. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shall I open a ticket for these?
Yes, please do and patches are always appreciated. Thanks!
Don
On 12/2/07, Giovanni Azua [EMAIL PROTECTED] wrote:
hi,
I am using 2.1.1 built from trunk and I am very happy to see how well it
works.
I found couple of really minor issues though and wanted to ask before
openning JIRA issues:
- ajax remote DIV does not work the same as in 2.0.9, there is an issue
related to the preload, updateFreq and delay parameters please see below for
details.
- the datetimepicker dojo widget control set to time does not allow entering
any time. When you select any and you enter any free time (not selecting
it from the widget) as soon as it loses the focus, it rounds the entered
time to be a multiple of 5.
May I go ahead opening tickets for these? I could not find any related
tickets open.
regards,
Giovanni
PS: message sent to the users list remote div diff behavior in 2.1.x
In version 2.0.x the remote DIV UI tag was initially rendering the content
of the DIV by immediately invoking the target action. In version 2.1.x on
the other hand, remote DIV does not initially render the content of the
target action, I did some research and tried using the new parameter
autoStart=true but does not work either. In version 2.1.x you have to wait
the updateFreq before you see anything rendered ...
Please have a look at the example with title *Ajax UI tags were moved to
the new dojo plugin ...* placed under:
http://cwiki.apache.org/confluence/display/S2WIKI/Troubleshooting+guide+migr
ating+from+Struts+2.0.x+to+2.1.x
The example illustrates using the remote DIV in a JSP before and after
migrating to 2.1.x I experience the problem described in exactly that
example.
The key parameters in this issue are these:
- delay: How long to wait before fetching the content (in milliseconds)
- updateFreq: How often to reload the content (in milliseconds)
- preload: Load content when page is loaded
The closest I could get to the would be a BUG was in file:
plugins/dojo/src/main/resources/org/apache/struts2/static/dojo/struts/widget
/BindDiv.js
line 258
***
if(this.isShowing() this.preload this.updateFreq = 0 this.delay =
0) {
this.refresh();
}
***
Obviously if you set either updateFreq or delay 0 then it would not
refresh upon startup.
I tried modifying that source to:
if(this.isShowing() (this.preload || (this.updateFreq = 0 this.delay
= 0))) {
this.refresh();
}
but did not work either, from there on I need more understanding of the
intrinsics of the DOJO library. I will keep digging it further as soon as I
have a chance.
Any help greatly appreciated.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Plugin and auto-generated XHTML Views
Completely agree with Martin. Once you get XSLT and functional programming in general, XSLT is actually pretty cool. I've deployed an application using XSLT and the aforementioned STXX and it went pretty well. Debugging was really easy, and even the performance was very good. You can even do cool stuff like flip a switch in config and now you send the XML and XSLT to the browser for it to be rendered on the client side, saving server resources and enabling mashups with no extra work. That said, I probably wouldn't chose pure XSLT again, especially now that similar benefits can be had using the REST plugin. Also, JSP has progressed quite a bit since those days, so with JSP tag files and the EL, it isn't quite the pain it was. Don On 12/3/07, Martin Cooper [EMAIL PROTECTED] wrote: On Dec 2, 2007 6:13 AM, Tom Schneider [EMAIL PROTECTED] wrote: Personally, I !!HATE!! writing xsl. I try to avoid it at all costs, but maybe others might feel differently. For anyone who has only ever worked with imperative languages, XSLT can be a complete mystery. It's not the most gentle introduction to functional programming, either. Once you get your head into the functional way of thinking, though, it's really not so bad. A lot of people complain about performance, but that's often the result of writing XSLT code that tries to be imperative. You really do have to think XSLT to get the performance up to par. To me, the biggest downside of XSLT in web apps, and especially in a framework, is that not enough people understand it, or are willing to take the time to understand it. That means that there's a high probability that it will go unmaintained, or, worse, fixed by people who don't properly understand the language. (Disclaimer: I am _not_ an expert in XSLT, by any stretch of the imagination.) -- Martin Cooper Is the idea here that the action would output XML then let the xsl processor on the client convert it to html? If so, would you expect the domain model to be automatically serialized to xml, or would there need to be code to do that? Also, would we need a new xsl for each screen? I guess I'm having trouble understanding exactly how this would work. Where I work, they used to do XML + XSL - HTML, but they did it server-side. It was terrible from a performance perspective--although moving it to the client might work better. I would still be a little hesitant to go down this path just because of the war stories I heard. :) I think I would rather see something more along the lines of rails/grails. Have a default template that's automatically used for list/edit/delete screens. If you need to diverge from the default, then you could generate a real view from the template and start with that. Tom Matt Raible wrote: I just thought of something that might be an easy way to generate XHTML views for the REST Plugin. What if we used XSL on the client-side with the XML views? As far as browser capabilities, I think client-side XSL could be a hidden gem that hasn't been looked at in a while. Of course, it could also be something that doesn't work very well across browsers. Do you guys think it's worth looking into? If it works, .html (or .xhtml) could render HTML views and we could allow users to override the XSL stylesheet. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP EL in struts2 tags
On 12/3/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote: I'm happy to know that a complete solution is being planned/developed. I just say that if the security problem is caused only by bad programming practice, removing EL evaluation into S2 tld is causing upgrading problems to many well-written applications. It isn't so much bad programming practices as unintentionally opening your application up to abuse. If you are confident that your application isn't vulnerable, feel free to replace the struts-tags.tld in the struts jar with one that allows expressions. The 10 minutes that will take will probably save you tons of time. Don -- Ing. Andrea Vettori Consulente per l'Information Technology - 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]
[s2] Allowed methods
I'm about to commit a fairly large patch that, among other things, adds built-in support for limiting what methods can be invoked on an Action. My motivation was actually to improve the ability for the REST plugin to introspect what HTTP methods are supported (automatic HTTP OPTIONS and WADL support), but I'd imagine the primary use will be as a security feature to prevent any arbitrary action being executed. The default behavior is to introspect the Action class during startup to get a list of all methods that can be executed. This allows, among other things, the config-browser plugin the ability to display exactly what methods are being automatically exposed to users. My question is, how best should this capability be exposed? A couple of ideas: 1. A new property/constant titled 'struts.restrictToDeclaredMethod' that will instruct the ActionConfig (where the allowedMethods property lives) to only allow the method that is explicitly defined (defaults to 'execute'). If false, all methods will be allowed. 2. A new attribute on the action element called 'allowedMethods', which takes a comma-separated list of method names to allow 3. A new @ActionMethod annotation for the codebehind plugin that declares a method as callable I'm thinking about doing all three, but I'm not sure #2 is necessary. I want to minimize XML configuration as much as possible, and I'm not convinced #2 is worth the extra config. Any other ideas? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SmartURLs port
Could you commit your version as a development branch, rather than to trunk? I'm using/improving Codebehind right now in some of the new features both in core and the rest plugin. I'd also like a chance to fully review the changes before we dump the old. On 12/6/07, Brian Pontarelli [EMAIL PROTECTED] wrote: I'm going to start working on the SmartURLs port. Here's what I'm planning: 1. Deprecate all the current codebehind annotations and classes I'm still not convinced this is a good idea, but as I said, I'll reserve judgment till the merge branch is ready. 2. Create a new package named org.apache.struts2.plugin.codebehind Use org.apache.struts2.codebehind, as it fits better with the convention used by other plugins. 8. Add configuration for changing the names used to find action packages via configuration property struts.plugin.codebehind.actionPackage.names 9. Add support for action package exclusions via configuration property struts.plugin.codebehind.actionPackage.excludes Regarding 8 and 9, I recommend simplifying the name as much as possible, mainly because properties can alternatively be declared in web.xml as init-params, which I've been finding more convenient lately. 10. Remove ActionNames and ActionName in favor of a new Action annotation for methods (not sure about this yet) 11. Remove Namespace annotation (this should probably be handled entirely in the action annotations) I still think we need to keep the idea of changing a namespace for all actions in a package. The package-info.java suggestion seems perfect. Same goes for specifying parent packages. Thanks for taking this on, and I'm looking forward to finally finishing this plugin :) Don -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Allowed methods next step
Since the commit for this feature involved a rather large XWork change
(properly immutable configuration objects [1]), I decided to commit
what I have and discuss the next steps.
First, due the aforementioned fix [1], Brian, your SmartURL's
migration work will probably be most affected. I changed the
configuration objects to be immutable using a static inner builder
class pattern. This makes construction a bit tricker, so pay
attention to the changes in the code and tests for the codebehind
plugin. The bright side is the construction code is much more
readable and nasty state bugs should be gone. You can do nifty things
like this:
ActionConfig config = new ActionConfig.Builder(mypackage, foo/*/*,
foo.BarAction)
.methodName(execute)
.addParam(someparam, someval)
.addResultConfig(new
ResultConfig.Builder(success{1}, foo.MyResult)
.addParams(location, /foo.jsp)
.build())
.build();
As for the allowed methods, I originally suggested three options:
1. A new property/constant titled 'struts.restrictToDeclaredMethod'
that will instruct the ActionConfig (where the allowedMethods property
lives) to only allow the method that is explicitly defined (defaults
to 'execute'). If false, all methods will be allowed.
2. A new attribute on the action element called 'allowedMethods',
which takes a comma-separated list of method names to allow
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
And after the comments, I see #2 is important and #3 I'll skip, since
Brian will be rewriting that stuff anyways.
To answer Matt's concern, yes, the default will be all public, no-arg
methods can be called, but what this will allow folks to do is limit
the methods that can be called, if they so choose. It also makes it
clearer to the developer what methods are being exposed through tools
like the config browser plugin. I'm also thinking it will be helpful
down the road when a plugin wants to move behind no-arg methods (I've
tried it, it can be pretty powerful).
See https://issues.apache.org/struts/browse/WW-2363
Any more thoughts?
Don
[1] http://jira.opensymphony.com/browse/XW-594
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Allowed methods next step
On 12/11/07, Brian Pontarelli [EMAIL PROTECTED] wrote: At first I thought this might be a problem because SmartURLs was sub-classing the ActionConfig object in order to add some additional information for performance reasons. However, I have a feeling that I can remove the sub-class. All the same, I think your change still allows sub-classing. Now I just need to figure out if I want to remove my sub-class or not :) Yeah, try to do it without the subclass, and feel free to add more builder methods as needed. I've got some work done on the new convention plugin and put together a short design doc for it because I kept getting lost in the soup of conventions and configuration overrides. Here's the URL for the design doc: http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-convention-plugin/design.txt?view=markup Yep, looks fine to me. With respect to allowed methods, the new plugin only generates configuration for the execute method and any other method that is annotated. So, with the new allowedMethods property inside the ActionConfig, it should be a snap to just ensure that when the plugin is constructing the ActionConfig instances it locks down the Action accordingly. Cool. To be honest, I'm thinking that maybe the feature would be better simply as an Interceptor, and therefore, I might end up ripping it out this weekend. Doing it as an interceptor would certainly be the most flexible and consistent with how other features work. Don -bp - 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]
[s2] Build changes
FYI, I'm working on the XWork and Struts 2 builds, trying to do a few things: * Automatic deployment of xwork and struts 2 snapshots (by Bamboo) * Automatic deployment of struts 2 assemblies (by Bamboo) * One step creation of assemblies, including j4 backport jars One of the stumbling points of the project right now is releases are still not as easy as they should be and this makes it hard to get users involved early. By automatically deploying assemblies, users can get usable versions of the code by downloading full builds that even include docs. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Build changes
On 12/17/07, Martin Gilday [EMAIL PROTECTED] wrote: Does this include getting artifacts published to a snapshot Struts 2 Maven repo (i.e. not central)? Yep, and as I mentioned, I'm hoping to get the full assembly builds automatically published as well. Don - Original message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Date: Sun, 16 Dec 2007 22:18:14 +1100 Subject: [s2] Build changes FYI, I'm working on the XWork and Struts 2 builds, trying to do a few things: * Automatic deployment of xwork and struts 2 snapshots (by Bamboo) * Automatic deployment of struts 2 assemblies (by Bamboo) * One step creation of assemblies, including j4 backport jars One of the stumbling points of the project right now is releases are still not as easy as they should be and this makes it hard to get users involved early. By automatically deploying assemblies, users can get usable versions of the code by downloading full builds that even include docs. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r604737 - /struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Don't forget to put the ticket number in the commit, cause that will
usually be the bit that has the link to the thread.
Don
On 12/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: davenewton
Date: Sun Dec 16 15:14:16 2007
New Revision: 604737
URL: http://svn.apache.org/viewvc?rev=604737view=rev
Log:
Patch for optiontransferselect.ftl null doubleListValue issue from Dale
Newfield.
See thread at
http://www.nabble.com/-struts--2.0.11--optiontransferselect-limit--tt14344098.html#a14344098.
Modified:
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Modified:
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
URL:
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl?rev=604737r1=604736r2=604737view=diff
==
---
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
(original)
+++
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Sun Dec 16 15:14:16 2007
@@ -261,7 +261,9 @@
/#if#t/
#assign doubleItemKeyStr = doubleItemKey.toString() /#t/
#if parameters.doubleListValue?exists#t/
-#assign doubleItemValue =
stack.findString(parameters.doubleListValue) /#t/
+#if
stack.findString(parameters.doubleListValue)?has_content#t/
+#assign doubleItemValue =
stack.findString(parameters.doubleListValue) /#t/
+/#if#t/
#else#t/
#assign doubleItemValue = stack.findString('top') /#t/
/#if#t/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r604737 - /struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Heh, that was the no-so-subtle hint :)
Don
On 12/17/07, Dave Newton [EMAIL PROTECTED] wrote:
Oh; didn't know there was a ticket, sorry.
d.
--- Don Brown [EMAIL PROTECTED] wrote:
Don't forget to put the ticket number in the commit, cause that will
usually be the bit that has the link to the thread.
Don
On 12/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: davenewton
Date: Sun Dec 16 15:14:16 2007
New Revision: 604737
URL: http://svn.apache.org/viewvc?rev=604737view=rev
Log:
Patch for optiontransferselect.ftl null doubleListValue issue from Dale
Newfield.
See thread at
http://www.nabble.com/-struts--2.0.11--optiontransferselect-limit--tt14344098.html#a14344098.
Modified:
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Modified:
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
URL:
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl?rev=604737r1=604736r2=604737view=diff
==
---
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
(original)
+++
struts/struts2/trunk/core/src/main/resources/template/simple/optiontransferselect.ftl
Sun Dec 16 15:14:16 2007
@@ -261,7 +261,9 @@
/#if#t/
#assign doubleItemKeyStr = doubleItemKey.toString() /#t/
#if parameters.doubleListValue?exists#t/
-#assign doubleItemValue =
stack.findString(parameters.doubleListValue) /#t/
+#if
stack.findString(parameters.doubleListValue)?has_content#t/
+#assign doubleItemValue =
stack.findString(parameters.doubleListValue) /#t/
+/#if#t/
#else#t/
#assign doubleItemValue = stack.findString('top') /#t/
/#if#t/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Build changes
Yep, if you look in the OpenSymphony maven 2 repository, you'll see the -jdk14 jar. I closed the ticket accordingly. I'm working on cleaning up the assembly right now as it is rather out of date. I'm really hoping we can use the release plugin...will make things much easier. Don On Dec 17, 2007 6:52 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/12/16, Don Brown [EMAIL PROTECTED]: * One step creation of assemblies, including j4 backport jars This might interest you, I noticed it was not applied: http://jira.opensymphony.com/browse/XW-585 One of the stumbling points of the project right now is releases are still not as easy as they should be Did you try to use the Maven release plugin? I configured it for Struts 2 and I hope to use it for the next Struts 2.1.x release, but the patch mentioned above must be resolved to work. BTW, I could help configuring the Maven release plugin for XWork, but I think I can do it only in January. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Build changes
Ok, I believe I have the first cut at the assembly builds. They were very out of date, and didn't include all the jdk14 jars, particularly for plugins. I'm sure there are more jars we should be bundling, so take a look. As far as I can tell, the steps go: mvn -Pall,j4,alljars clean install cd assembly mvn assembly:assembly Don On 12/17/07, Don Brown [EMAIL PROTECTED] wrote: On 12/17/07, Martin Gilday [EMAIL PROTECTED] wrote: Does this include getting artifacts published to a snapshot Struts 2 Maven repo (i.e. not central)? Yep, and as I mentioned, I'm hoping to get the full assembly builds automatically published as well. Don - Original message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Date: Sun, 16 Dec 2007 22:18:14 +1100 Subject: [s2] Build changes FYI, I'm working on the XWork and Struts 2 builds, trying to do a few things: * Automatic deployment of xwork and struts 2 snapshots (by Bamboo) * Automatic deployment of struts 2 assemblies (by Bamboo) * One step creation of assemblies, including j4 backport jars One of the stumbling points of the project right now is releases are still not as easy as they should be and this makes it hard to get users involved early. By automatically deploying assemblies, users can get usable versions of the code by downloading full builds that even include docs. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r604801 - in /struts/struts2/trunk/assembly: pom.xml src/main/assembly/all.xml src/main/assembly/lib-backport.xml src/main/assembly/lib-jdk14.xml src/main/assembly/lib.xml
On 12/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote:
Don,
Why did you remove so many dependencies? I think that your commit broke the
assemblies instead of fixing them...
Most of those were not used anymore, but I'm sure I'll have to put
back in. I'd rather know exactly what needs to go there than have a
bunch of stuff no one is quite sure about.
For example, there were spring jars, but those shouldn't be defined
here, as the spring plugin will pull them in automatically. That
leads me to think they were from the pre-plugin days.
And why did you change the backported artifacts classifier to jdk14? I think
that the name was chosen by Ted (Husted) for a good reason (I suppose :-) ).
Well, that is the default and couldn't think of a good reason to not
use it. I actually did the xwork build first, and then copy/pasted.
To me, backport is too generic, where the -jdk14 classifier is pretty
clear what it is. Still, I'd don't really care, as long as it is
consistent and it seemed to me jdk14 is more consistent with both
xwork and the maven world at large.
Don
Ciao
Antonio
2007/12/17, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: mrdon
Date: Mon Dec 17 01:20:25 2007
New Revision: 604801
URL: http://svn.apache.org/viewvc?rev=604801view=rev
Log:
Updating assemblies, adding all plugins to jdk14 zip
WW-2379
Added:
struts/struts2/trunk/assembly/src/main/assembly/lib-jdk14.xml
- copied, changed from r604783,
struts/struts2/trunk/assembly/src/main/assembly/lib-backport.xml
Removed:
struts/struts2/trunk/assembly/src/main/assembly/lib-backport.xml
Modified:
struts/struts2/trunk/assembly/pom.xml
struts/struts2/trunk/assembly/src/main/assembly/all.xml
struts/struts2/trunk/assembly/src/main/assembly/lib.xml
Modified: struts/struts2/trunk/assembly/pom.xml
URL:
http://svn.apache.org/viewvc/struts/struts2/trunk/assembly/pom.xml?rev=604801r1=604800r2=604801view=diff
==
--- struts/struts2/trunk/assembly/pom.xml (original)
+++ struts/struts2/trunk/assembly/pom.xml Mon Dec 17 01:20:25 2007
@@ -83,6 +83,12 @@
/artifactItem
artifactItem
groupIdorg.apache.struts/groupId
+
artifactIdstruts2-rest-showcase/artifactId
+version${version}/version
+typewar/type
+/artifactItem
+artifactItem
+groupIdorg.apache.struts/groupId
artifactIdstruts2-mailreader/artifactId
version${version}/version
typewar/type
@@ -100,10 +106,10 @@
configuration
artifactItems
artifactItem
-groupIdopensymphony/groupId
+groupIdcom.opensymphony/groupId
artifactIdxwork/artifactId
classifierjavadoc/classifier
-version2.1-SNAPSHOT/version
+version2.1.1-SNAPSHOT/version
/artifactItem
/artifactItems
outputDirectory${project.build.directory
}/xwork-apidocs/outputDirectory
@@ -124,7 +130,7 @@
dest=${project.build.directory
}/docs.zip
ignoreerrors=false/
unzip src=${project.build.directory
}/docs.zip
- dest=${project.build.directory
}/cwiki/
+dest=${project.build.directory
}/cwiki/
/tasks
/configuration
goals
@@ -140,7 +146,7 @@
descriptors
descriptorsrc/main/assembly/all.xml/descriptor
descriptorsrc/main/assembly/lib.xml/descriptor
-descriptorsrc/main/assembly/lib-backport.xml
/descriptor
+descriptorsrc/main/assembly/lib-jdk14.xml
/descriptor
descriptorsrc/main/assembly/apps.xml/descriptor
descriptorsrc/main/assembly/src.xml/descriptor
descriptorsrc/main/assembly/docs.xml/descriptor
@@ -155,40 +161,6 @@
dependencies
-dependency
-groupIdorg.apache.struts/groupId
-artifactIdstruts2-api/artifactId
-version${version}/version
-/dependency
-dependency
-groupIdorg.apache.struts/groupId
-
Re: svn commit: r604801 - in /struts/struts2/trunk/assembly: pom.xml src/main/assembly/all.xml src/main/assembly/lib-backport.xml src/main/assembly/lib-jdk14.xml src/main/assembly/lib.xml
On 12/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote: Mmm I think that you removed Tiles for no good reason Nope, I just checked - Tiles is still there in -all, -lib, and -lib-jdk14. You don't need to specify the jar explicitly, as it is pulled in via the tiles plugin. One of the advantages of the plugin system is we don't have to use optional jars all over the place. It was the optional jars that were requiring us to declare dependencies in multiple places, but now that they are required by the plugins, they are properly retrieved with no extra work. As I said, we'll probably have to add a few back for the couple cases where the jars were optional and we want them in the zips, but getting rid of all that duplication will help make the build more maintainable and less error-prone. Don Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Assembly build (was svn commit: r604801 )
On 12/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote: The Struts 2/Tiles 2 plugin does not depend on tiles-jsp, so I suppose that it isn't there... Hmm...this is kinda a bigger issue - should our assembly contain all the files for the frameworks that the plugin provides support for? We don't include every Spring jar or a JSF framework with our JSF plugin. I'd lean towards not including jars we don't have to - our downloads are big enough (some would say 100 megs for a web framework with 2 real dependencies is a bit overkill). BTW, I noticed that you removed the backport-utils and retrotranslator-runtime dependencies: are they still there in backport assemblies? (Sorry for the question but at the moment I cannot test myself). I had thought they were included in the jars, but looking at them again, I see the size increase isn't large enough. I'll put those back in. I don't like the approach. I think it is best to create assemblies on your local machine by removing all the unneeded dependencies to clean up the pom and the assembly descriptors, until the assemblies are exactly the same as they were before your intervention. After that, we could discuss the removal of dependencies and jars from the distributions. Fair enough, I guess we prefer different approaches here. Since the assembly didn't work before, it is hard to compare, but I pulled down 2.0.11 so I'll use that. Still, as it sits now, even our slimmed down lib zip is 59 megs, so I think we need to get serious about cutting the fat. Don Thanks Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Assembly build (was svn commit: r604801 )
On 12/17/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/12/17, Don Brown [EMAIL PROTECTED]: Hmm...this is kinda a bigger issue - should our assembly contain all the files for the frameworks that the plugin provides support for? We don't include every Spring jar or a JSF framework with our JSF plugin. I'd lean towards not including jars we don't have to - our downloads are big enough (some would say 100 megs for a web framework with 2 real dependencies is a bit overkill). I don't think that Tiles is a bigger issue: The S2/T2 plugin has a compile dependency on tiles-core (that, in turn, depends on tiles-api), but tiles-jsp is necessary for a typical use. My preference is to ship only the minimal amount of jars, but in true open source fashion, you are the one that maintains the Tiles plugin, so it is your call. That inclusion should happen at the plugin build level, though, to keep all the tiles dep info in one place. I've added the retrotranslator runtime jars back into the appropriate assemblies. Let me know if there are any other missing jars, or better yet, add them in yourself :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork project
On Jan 3, 2008 5:44 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: What is the policy for Struts committers getting access to XWork? While updating the convention plugin I had to change a few things in XWork and I want to make sure that they get committed to trunk before I start using the convention plugin on projects. I have a few bugs open, but it could take a while to get those in. Since Struts and XWork as so tightly coupled and still separate projects, would it make sense for all Struts committers to also have access to XWork? Yep, send me an email with your desired user name and your sha1-encoded password, and I'll add you. Also, as a separate topic, what are the future plans for all the external dependencies for Struts core? One of the difficult things I've found is that the two most major dependencies, OGNL and XWork, are not only confusing for some of my employees since the need to import from packages other than org.apache.struts2, but also not accessible to me for modification and updates and such. At this point, our plan is to leave them where they are. I'd like to get rid of OGNL through the JUEL plugin, and perhaps just include the xwork code inside the Struts jar, dropping our dependency list down to just Freemarker. Don -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork project
In a perfect world, we would have the theme system in core, then a Freemarker theme plugin that implements it for Freemarker (same for velocity). Still there are a couple other areas we use freemarker, the debug screen comes to mind. That probably doesn't need something as powerful as Freemarker, so perhaps we could get away with embedding a version of StringTemplate or something. Don On 1/3/08, Chris Pratt [EMAIL PROTECTED] wrote: On Jan 2, 2008 2:26 PM, Don Brown [EMAIL PROTECTED] wrote: At this point, our plan is to leave them where they are. I'd like to get rid of OGNL through the JUEL plugin, and perhaps just include the xwork code inside the Struts jar, dropping our dependency list down to just Freemarker. If we push the theme support into the plugins, wouldn't that move the Freemarker dependency to that plug-in, and out of the core? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Personally, I'm leaning more and more to not shipping dependencies by default, so I'd prefer the 1.4 distro to not have them. Our download sizes are way too big already. Don On 1/12/08, Antonio Petrelli [EMAIL PROTECTED] wrote: Hi all, Currently in the JDK 1.4 distribution, that contains backported Struts 2 artifacts, all the dependencies are added, while in release builds only the backported artifacts (along with Retrotranslator runtime libraries) are included. What are your feelings? Do you think that adding dependencies in this distributions is correct? Notice that, in this case, the JDK1.4-compatible JARs must be used, such as Tiles backported artifacts. Thoughts? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox
On 1/16/08, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/16, Nils-Helge Garli Hegvik [EMAIL PROTECTED]: I've started playing with JSR286 portlet support in Struts 2. Is the sandbox an appropriate place to put this code (probably a new plugin), or is the sandbox reserved for other purposes? I don't know if it needs a vote, though. Nope. go nuts. Don HTH Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2.1] Does struts2-core include Dojo code?
It shouldn't... Don On 1/18/08, Antonio Petrelli [EMAIL PROTECTED] wrote: Hi all, I wish to know if the struts2-core, in Struts 2.1, contains Dojo in any form, since I have to resolve some license issues and probably I have to move it to the Dojo plugin. Thanks Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r614488 - in /struts/struts2/trunk: core/pom.xml plugins/dojo/pom.xml
Don't forget to deploy the snapshot before updating the pom. Also, when I deployed the struts-annotations snapshot, I noticed it had a unique snapshot version, so I changed the poms to use it, and kicked off the build again, which just passed. Don On 1/23/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: husted Date: Wed Jan 23 02:56:48 2008 New Revision: 614488 URL: http://svn.apache.org/viewvc?rev=614488view=rev Log: WW-2451 Updated poms to use struts annotations 1.0.3-SNAPSHOT to fix dependency issue Apply patch suggested by Al Sutton, but leave issue open pending a 1.0.3 release of Struts-Annotations. Modified: struts/struts2/trunk/core/pom.xml struts/struts2/trunk/plugins/dojo/pom.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OSS Bamboo] Struts 2 SVN - Main Build build 685 has FAILED (0 tests failed). Change made by husted
Yeah, passes for me too. That is a really weird Maven error: INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [1.0,) commons-logging:commons-logging:jar:null from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), Maven Snapshots (http://snapshots.maven.codehaus.org/maven2/), opensymphony (http://maven.opensymphony.com), opensymphony-m2 (http://maven2.opensymphony.com), central (http://repo1.maven.org/maven2), snapshots-maven-codehaus (http://snapshots.maven.codehaus.org/maven2) If I had a nickel for every time a Maven build worked on one person's machine and not another's :) Don On 1/24/08, Ted Husted [EMAIL PROTECTED] wrote: The build passes for me locally. Might be another hiccup. On Jan 24, 2008 6:15 AM, Atlassian Open Source Bamboo Integration Server [EMAIL PROTECTED] wrote: The project Struts 2 SVN - Main Build has the following 1 change by 1 author: *husted* made the following changes at Comment: WW-2171 Label tag does not use key attribute to lookup value in resources when using simple theme Apply patch provided by Maja S Bratseth. /struts/struts2/trunk/core/src/test/java/org/apache/struts2/views/jsp/ui/LabelTest.java (614842) /struts/struts2/trunk/core/src/main/java/org/apache/struts2/components/Label.java (614842) /struts/struts2/trunk/core/src/test/java/org/apache/struts2/TestAction.java (614842) --- No failed tests found, a possible compilation error. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-685 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Tiles plugin build error?
Is anyone else seeing this problem with the Tiles plugin?
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tiles/tiles-master/1/tiles-master-1.pom
Downloading:
http://people.apache.org/builds/tiles/${pom.version}/m2-staging-repository//org/apache/tiles/tiles-master/1/tiles-master-1.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Unable to build project dependencies.
Embedded error: Invalid uri
'http://people.apache.org/builds/tiles/${pom.version}/m2-staging-repository//org/apache/tiles/tiles-master/1/tiles-master-1.pom':
escaped absolute path not valid
My maven command:
mvn -Pplugins,apps,xwork idea:clean idea:idea -DdownloadSources=true
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628298 - /struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
I explicitly removed the 2.4 servlet jar that was leaking in, but that
only seemed to fix the method not found exception I was seeing. I
even tried including jstl but that didn't seem to help.
Don
On 2/17/08, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote:
I don't know why the test have started to fail, but it appears that
some updated dependency version somewhere has caused a
dependency-classloader-clash The prime suspect is a conflicting
version of servlet-api indirectly included somewhere...
Nils-H
On Feb 16, 2008 3:01 PM, [EMAIL PROTECTED] wrote:
Author: mrdon
Date: Sat Feb 16 06:01:29 2008
New Revision: 628298
URL: http://svn.apache.org/viewvc?rev=628298view=rev
Log:
Commenting out tests for now
WW-2494
Modified:
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
Modified:
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
URL:
http://svn.apache.org/viewvc/struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java?rev=628298r1=628297r2=628298view=diff
==
---
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
(original)
+++
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
Sat Feb 16 06:01:29 2008
@@ -3,7 +3,9 @@
public class Struts2PortletTest extends BasePortletTest {
private final static String PORTLET_NAME = StrutsPortlet;
-
+
+public void testNone() {}
+/*
public void testIndexPage() throws Exception {
beginAt(pluto/index.jsp);
assertTextPresent(Welcome to the Struts example portlet);
@@ -74,7 +76,7 @@
switchEdit();
assertTextPresent(Back to view mode);
}
-
+*/
@Override
public String getPortletName() {
return PORTLET_NAME;
-
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]
[s2] Let's get out Struts 2.1.1
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628298 - /struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
Yay Maven... *ducks* :)
Don
On 2/17/08, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote:
I know. I've tried locally as well. It's not very obvious what the
problem could be. This test has been running without problems for a
long time no (after some initial start up problems...), so there's no
reason it suddenly should fail.
Nils-H
On Feb 16, 2008 3:08 PM, Don Brown [EMAIL PROTECTED] wrote:
I explicitly removed the 2.4 servlet jar that was leaking in, but that
only seemed to fix the method not found exception I was seeing. I
even tried including jstl but that didn't seem to help.
Don
On 2/17/08, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote:
I don't know why the test have started to fail, but it appears that
some updated dependency version somewhere has caused a
dependency-classloader-clash The prime suspect is a conflicting
version of servlet-api indirectly included somewhere...
Nils-H
On Feb 16, 2008 3:01 PM, [EMAIL PROTECTED] wrote:
Author: mrdon
Date: Sat Feb 16 06:01:29 2008
New Revision: 628298
URL: http://svn.apache.org/viewvc?rev=628298view=rev
Log:
Commenting out tests for now
WW-2494
Modified:
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
Modified:
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
URL:
http://svn.apache.org/viewvc/struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java?rev=628298r1=628297r2=628298view=diff
==
---
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
(original)
+++
struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
Sat Feb 16 06:01:29 2008
@@ -3,7 +3,9 @@
public class Struts2PortletTest extends BasePortletTest {
private final static String PORTLET_NAME = StrutsPortlet;
-
+
+public void testNone() {}
+/*
public void testIndexPage() throws Exception {
beginAt(pluto/index.jsp);
assertTextPresent(Welcome to the Struts example
portlet);
@@ -74,7 +76,7 @@
switchEdit();
assertTextPresent(Back to view mode);
}
-
+*/
@Override
public String getPortletName() {
return PORTLET_NAME;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Publish Struts Annotations 1.0.3
The test build of Struts Annotations 1.0.3 is available. Maven 2 staging repository: * http://people.apache.org/builds/struts/struts-annotations/1.0.3/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on whether to publish it or not: [ ] +1 Publish to the Maven 2 repository [ ] -1 Don't publish, because Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Closer award -[OT] slow down Don!
You gotta be faster than that :) Really, don't stress about your first commit; it is like stressing over your first kiss. Just get the damn thing out of the way and get on to more interesting things :) Don On 2/17/08, Jeromy Evans [EMAIL PROTECTED] wrote: Dave Newton wrote: --- Don Brown [EMAIL PROTECTED] wrote: Well, most of those were patches so I can't really take any credit. Strangely, many of the patches were from Jeromy...someone should tell him he can commit his own patches now :) Maybe he forget ;) I was saving my patches up especially for my first commit day! Now I have to start again :-( ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Tiles plugin build error?
Nm, working fine now. Don On 2/16/08, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/16, Don Brown [EMAIL PROTECTED]: Is anyone else seeing this problem with the Tiles plugin? For me the build went fine. What version of Maven are you using? For me it's 2.0.7. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Publish Struts Annotations 1.0.3
+1 On Feb 17, 2008 7:34 PM, Don Brown [EMAIL PROTECTED] wrote: The test build of Struts Annotations 1.0.3 is available. Maven 2 staging repository: * http://people.apache.org/builds/struts/struts-annotations/1.0.3/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on whether to publish it or not: [ ] +1 Publish to the Maven 2 repository [ ] -1 Don't publish, because Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Access to WW space at cwiki
Done. On 2/18/08, Jeromy Evans [EMAIL PROTECTED] wrote: Thanks Don. Sorry, the confluence username is jeromyevans (with an o) Don Brown wrote: I tried, but I don't see your account. Could it be under something else? Don On 2/18/08, Jeromy Evans [EMAIL PROTECTED] wrote: Can someone with power please grant me write access to the WW space at http://cwiki.apache.org/confluence/display/WW/Home? My existing login (jeromy) currently only has write access to the S2WIKI: http://cwiki.apache.org/S2WIKI/home.html Thanks! Jeromy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Are there any special instructions or is it a simple 'mvn
release:prepare release:perform'?
Don
On 2/18/08, Rainer Hermanns [EMAIL PROTECTED] wrote:
Don,
great work, thanks for your help...
I'm really busy during the week so that I can not release before
friday evening (GMT+2), 23rd. If this will still meet you timeline I can
do the release otherwise either you or Pat could roll the release.
If you need any help, I'm available via IM.
cheers,
Rainer
Ok, here are the release notes so far:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
I'm planning on a date of Feb 24 Australia time so Feb 23 for the US.
I've closed out all but one ticket in XWork 2.1.1, which I may bump as
well.
Rainer, any chance on getting an XWork 2.1.1 release out? If you are
busy, I can stumble through that release as well.
Don
On 2/17/08, Don Brown [EMAIL PROTECTED] wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any objections to rolling a release(*) in the next day or so?
Don
{*} build, test build, or whatever we are calling it this week :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Rainer Hermanns
aixcept
Mariahilfstrasse 9
52062 Aachen - Germany
w: http://aixcept.de/
t: +49-241-4012247
m: +49-170-3432912
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Oh, I know how to release Struts; I was referring to the XWork release. IIRC, this will be the first release with the Maven 2 build, so we'll see how it goes... Don On 2/20/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Feb 19, 2008 6:01 AM, Don Brown [EMAIL PROTECTED] wrote: Are there any special instructions or is it a simple 'mvn release:prepare release:perform'? Antonio linked to this earlier: http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Let's get out Struts 2.1.1
Here's the thing - I'm going to create the 2.1.1 test build on Sunday, hopefully followed by test builds every couple weeks or so. Whatever you can get into the code by those dates will be included in the subsequent release. Honestly, I don't expect 2.1.1 to be GA, but am aiming for a Beta vote. I would like to see a GA release sometime around the 2.1.4 timeframe, though. Don On 2/21/08, Brian Pontarelli [EMAIL PROTECTED] wrote: If convention-plugin is not bundled with the next release, people will stick to the codebehind plugin. Last time I checked there was no smarturls for 2.1.x as well - so there is really not much choice. (compiling from the sandbox is no option for most users) You are probably correct. However, unless everyone agrees to promote convention plugin out of the sandbox and solidify it in the next few days or so, it will have to be a separate release outside of the bundle. Back to the convention plugin... If folks would like to discuss the API and solidify it over the next few days, I'd be up for that. I'll start a new thread for that and we can hopefully get things ready for a 2.1.1 final release of the plugin shortly after the release of core. Is it possible to release a 2.1.1 plugin after the core? In this case I do not feel like it is that important to make it part of the s2.1.1 release :) Until now I thought that the next possible release for the convention plugin would be 2.1.2 (or whatever build makes it). Not really if you want it in the bundle. Otherwise, it would be an external download until 2.1.2 or some version like that. I'm up for anything Thoughts? -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Yeah, the way Struts does versions kinda breaks this. You could see very major changes between 2.1.0 and 2.1.1 because neither made GA. Once a GA release has been made in a series, however, the normal rules apply. It is beating a dead horse to say I never liked the Struts versioning system, so moving forward, how can we better educate our users on how things work? Don On 2/21/08, Brian Pontarelli [EMAIL PROTECTED] wrote: The API has yet to be solidified and there are a few things that I'd still like to discuss and possibly change in that regard. My main goal is to ensure backwards compatibility in the convention plugin API. My thinking is like this: upgrading from [today's convention-plugin] to [final convention-plugin] will be much easier than upgrading from [codebehind] to the [final convention-plugin]. True. The changes will probably not impact most applications, but will be API changes and not compatible. Furthermore, I think we should all start thinking about when the true stable release of XWork and Struts2 will be. Isn't a GA release meant to be a true stable release? I think to know what you want to say, but I am still somewhat confused about why releases in s2 are working the way they do. It depends on your versioning system. I prefer for all minor numbers (2.x) to be compatible and all major numbers (x.0) to be incompatible for the API perspective. I also feel that patches numbers (2.1.x) should not add or subtract features. Therefore, the schema I use GAs don't measure compatibility, the version numbers to. In my world you release GAs for majors, minors and patches when they are final. If the release isn't final, it uses a signifier like A, B, RC, M. For example, 2.1.1-RC1 would be the first release candidate and 2.1.1 would be the GA final release. Struts versioning is much different though. I think it makes sense to target the next release and jump up to 2.5 or some number to indicate stable APIs. This would include a number of API clean-ups, OGNL replacement and a few other things that will severely break plugins and applications. After that release, API changes should be compatible so that plugins and applications can be upgraded without requiring re-compiling. I am quite sure there will rise another list with new issues that should be resolved before a true release in some time... In my oppinion, API stability is nothing that comes with reaching some feature set or project milestone. This would imply stopping innovation at that point. For me, API stability needs to be some kind of project goal or philosophy - which needs to be enforced by defining commonly accepted rules. I agree for the most part, but also use version numbers to imply API freeze and compatibility. Innovation and API compatibility are not mutually exclusive. Folks just have to understand what they can and cannot do to APIs. For example, you cannot remove any methods or classes otherwise, it isn't compatible. You can add new methods and classes and this implies the ability to innovate. Deprecation can also be used correctly (not like the JDK) to handle API changes between major versions. But my impression is that this is no (important) goal for s2, and I can hardly imagine that it will be one day just because it gets to a point where _today's_ most wanted features are implemented. Not yet, but I want to make it one. I think since the plugin system allows developers access to APIs that were at one point internal, it changes things quite a bit. These APIs are now public and need to be stabilized at some point. Otherwise we will end up having developers who are constantly battling with upgrading plugins and applications and get turned off by Struts. But maybe this is worth a new thread... Agreed ;) -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
But don't you see, if we used the more traditional 1.0-alpha-1 - 1.0-beta-1 - 1.0-rc-1 - 1.0 then we could produce releases that drastically changed the API within a single version. As it is now, there could very well be huge changes from 1.0 to 1.0.1 because every release gets its own numeric version number, regardless of quality. I agree the changes in 2.1 are very significant, so much so that they necessitate multiple alpha releases to get feedback from the community. Currently, there is no way to do that without releasing 2.1.0 - 2.1.1 - 2.1.2. Again, the versioning discussion has happened many times before, and individual numeric releases is how the community has decided to run Struts, and that's fine. Then, the question becomes how we can better educate our users on what to expect. Don On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: From my perspective the issue isn't education, it is compatibility at the code level. Making changes that severely break plugins and applications needs to be reserved for major releases. Here are two examples that had severe impacts: - Making XWork objects immutable with the builder pattern This change broke a number of plugins because that API is public and reducing visibility or removing methods is not a compatible change. - Changing the names of the interceptors in struts.xml This change broke all applications that had custom interceptor chains. This is a higher level of public API in the configuration files and renaming methods or ids is not a compatible change. These types of changes seem to be the largest issue with the versioning of Struts 2. -bp Don Brown wrote: Yeah, the way Struts does versions kinda breaks this. You could see very major changes between 2.1.0 and 2.1.1 because neither made GA. Once a GA release has been made in a series, however, the normal rules apply. It is beating a dead horse to say I never liked the Struts versioning system, so moving forward, how can we better educate our users on how things work? Don On 2/21/08, Brian Pontarelli [EMAIL PROTECTED] wrote: The API has yet to be solidified and there are a few things that I'd still like to discuss and possibly change in that regard. My main goal is to ensure backwards compatibility in the convention plugin API. My thinking is like this: upgrading from [today's convention-plugin] to [final convention-plugin] will be much easier than upgrading from [codebehind] to the [final convention-plugin]. True. The changes will probably not impact most applications, but will be API changes and not compatible. Furthermore, I think we should all start thinking about when the true stable release of XWork and Struts2 will be. Isn't a GA release meant to be a true stable release? I think to know what you want to say, but I am still somewhat confused about why releases in s2 are working the way they do. It depends on your versioning system. I prefer for all minor numbers (2.x) to be compatible and all major numbers (x.0) to be incompatible for the API perspective. I also feel that patches numbers (2.1.x) should not add or subtract features. Therefore, the schema I use GAs don't measure compatibility, the version numbers to. In my world you release GAs for majors, minors and patches when they are final. If the release isn't final, it uses a signifier like A, B, RC, M. For example, 2.1.1-RC1 would be the first release candidate and 2.1.1 would be the GA final release. Struts versioning is much different though. I think it makes sense to target the next release and jump up to 2.5 or some number to indicate stable APIs. This would include a number of API clean-ups, OGNL replacement and a few other things that will severely break plugins and applications. After that release, API changes should be compatible so that plugins and applications can be upgraded without requiring re-compiling. I am quite sure there will rise another list with new issues that should be resolved before a true release in some time... In my oppinion, API stability is nothing that comes with reaching some feature set or project milestone. This would imply stopping innovation at that point. For me, API stability needs to be some kind of project goal or philosophy - which needs to be enforced by defining commonly accepted rules. I agree for the most part, but also use version numbers to imply API freeze and compatibility. Innovation and API compatibility are not mutually exclusive. Folks just have to understand what they can and cannot do to APIs. For example, you cannot remove any methods or classes otherwise, it isn't compatible. You can add new methods and classes and this implies
Re: StrutsStatics...
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this change is minor in comparison. I disagree with that statement. For Struts 2 users, the changes are only minor. I think you feel them more because you are working on plugins that dig deep into the Struts 2 and XWork 2 code, and yes, the internals have changed quite a bit. I'd say the biggest change, from a user standpoint, was not allowing JSP EL expressions in JSP tags, and that was first done in 2.0.10. As for this statics discussion, yes, this code was brought over from WebWork, but really, is there any pragmatic reason to change it? Especially stacked up against all the other issues, would we really get a big bang for the buck? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: Here's an example... The XWork configuration API changed to the builder pattern. This is probably a good thing, but required any plugin using it to make significant changes and re-compile. This change wasn't compatible and there are ways to make these types of changes while not impacting compatibility. Then it doesn't matter what the version numbers are. You deprecate things correctly and then remove them on a defined schedule. I disagree - we should be able to make internal changes between minor versions without deprecations where necessary and I would consider this necessary. By preserving the constructors and setter methods on the configuration entities, we wouldn't have gained any of the immutable benefits of the builders, and therefore, the bugs would have continued to exist. There is a significant distinction between changing an internal API and an external one. The number of people that were affected by this change was probably less than 10, as most users aren't creating ActionConfig objects. But, I will say this... Struts 2 doesn't have any compatibility definition at all. Versions 2.1.0 and 2.1.1 might be incompatible and 2.1.5 and 2.2.7 might be compatible. This makes it impossible for tools like Ivy and Savant to manage Struts dependencies correctly. Therefore, I think it is VITAL that we pick a compatibility model and stick to it. Well, the Struts project has always had a defined strategy to guide changes and deprecations, although I can't seem to find it on the website right now. Also, each release plan includes notes where incompatibilities are listed. What more do you suggest we do? Don -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsStatics...
I do agree we need to be much better about how much of our API we expose to developers, but I think the question of public vs private API goes beyond the Java semantics and into what a typical Struts user will encounter. Unless you are a plugin or framework developer, it would be very rare for you to be creating configuration objects, so yes, while these are technically public, I'd certainly call them more private than, say, the Action interface. The other example you mention, changing the names of interceptors and results, is easily rectified by re-adding them under their old names side-by-side the new ones. I agree this is a change that should have been done better. So the bottom line is what changes can you do when? As I understand the Struts policy, there can be internal changes between minor releases as they are generally viewed as mostly backwards-compatible. Therefore, I just don't enough justification for the statement that 2.1 changes are completely incompatible, especially from the standpoint of a Struts application developer. Don On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: Don Brown wrote: On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this change is minor in comparison. I disagree with that statement. For Struts 2 users, the changes are only minor. I think you feel them more because you are working on plugins that dig deep into the Struts 2 and XWork 2 code, and yes, the internals have changed quite a bit. I'd say the biggest change, from a user standpoint, was not allowing JSP EL expressions in JSP tags, and that was first done in 2.0.10. I'm pretty sure applications will break. Just look at the changes made to the names of interceptors, results, etc. Plus, I've got to argue this point because those APIs that I was using as a plugin developer or in other similar cases are public APIs. This is very different than internal APIs. If you are going to make something public, you need to ensure compatibility because if it is public, people will use it. I have a good antidote about this. The folks over at Spring had an API that was public and returned the current proxy (for AOP). They documented it saying something like, don't use this even though it is public. Well, sure enough, a number of people used it and the method changed a few times and broke a few times over the years. Each release they did there would be a bug submitted to fix that method and each time the Spring folks would say, don't use that method, and after some moaning and groaning would eventually fix the method. The moral of the story: if it is public, people will use it and if you break it, people will complain. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
On 2/22/08, Paul Benedict [EMAIL PROTECTED] wrote: I would strongly suggest that Struts 2.1 refactor itself, if necessary, to separate out the public and internal API and produce two distrinct javadocs and source bundles based on these. Since 2.1 is already incompatible for plugins, I think it's the perfect excuse to not let the problem linger any more. I'd love to see that as well, since we were half-way there with Bob creating a new API that would even shield XWork classes, drastically simplifying the API surface area for Struts users. Unfortunately, there is still a lot of work to be done, and as it would greatly affect all Struts applications, the earliest it could be introduced would be Struts 3. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Well said, and I completely agree. My original point is your point #1 just isn't possible with the current versioning scheme. Because every release gets its own patch number, regardless of quality or API changes, it can't be counted on, and really, I don't see any solution other than creating a big matrix of releases for users to somehow navigate the sea of releases to understand which are compatible with the other. Don On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: snip / The solution is this: 1. Pick a versioning scheme. I suggest that minor numbers indicate compatibility such that 2.1.x are all compatible but 2.1 is not compatible with 2.2. This seems to be the pattern. This is commonly referred to as patch compatibility since things are only compatible across patch version numbers like 2.1.1 and 2.1.2. 2. Tell developers that if the minor numbers in the version aren't changing, they can't break any public APIs runtime compatibility. That should be it. Simple, straight-forward and still allows each release to have its own version number. Then the tools can correctly manage dependencies. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Here are my two points: 1. Our current versioning scheme requires patch versions for all releases, regardless of quality 2. We need to be able to do alpha releases to get new, experimental features into the community for testing These two points, put together, will necessarily result in a 2.1.0 release that is drastically different than 2.1.1. I just don't see any way around that. As for your other point about dependencies, well, that problem goes away once the convention plugin is bundled with Struts, because it will then have the same version number and will necessarily be compatibility with its counterparts in that release. As for third-party plugins, yes, that is an issue, but I don't see how it is any different than any other library. My app depends on Velocity 1.5, but a library I use depends on Velocity 1.4, so problems could arise. We have this all the time in the projects I work on, so I don't see how Struts is unique here. Don On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: Don Brown wrote: Well said, and I completely agree. My original point is your point #1 just isn't possible with the current versioning scheme. Because every release gets its own patch number, regardless of quality or API changes, it can't be counted on, and really, I don't see any solution other than creating a big matrix of releases for users to somehow navigate the sea of releases to understand which are compatible with the other. I agree with you on that. It is difficult. However, it doesn't mean that a person or tool couldn't check the public APIs for changes prior to doing a release. The release would not ever occur and remain in -SNAPSHOT until those broken APIs are fixed. From the other thread: I do agree we need to be much better about how much of our API we expose to developers, but I think the question of public vs private API goes beyond the Java semantics and into what a typical Struts user will encounter. Unless you are a plugin or framework developer, it would be very rare for you to be creating configuration objects, so yes, while these are technically public, I'd certainly call them more private than, say, the Action interface. It is actually more complex than I think you realize. Here is another dependency graph that reveals a really bad issue: Project A - struts 2.0.6 Project A - library B Project A - library C library B - convention-plugin 2.0.6 - struts 2.0.6 library C - struts 2.1.1 This graph is broken because the build will decide that 2.1.1 is the latest and most correct version of Struts to use and put that in the classpath. However, the API changes in 2.1.1 break the convention plugin. BUT struts 2.1.1 doesn't depend on the convention plugin 2.1.1 and therefore the build is incapable of warning the user that things are broken and cannot manage this graph correctly. So, any public APIs need to be managed and when you introduce transitive dependencies, things get complex. Applications will break, even if they don't use those public APIs directly. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote: These two points, put together, will necessarily result in a 2.1.0 release that is drastically different than 2.1.1. I just don't see any way around that. Tooling can solve this issue. How? As I said, it is not possible for Struts releases to be compatible across patch versions. How will tooling solve this? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
It doesn't help your argument to use Maven as an example :) I think it is pretty straight forward - all plugins have versions, only the bundled plugins are versioned/released along with the rest of Struts to make it simpler. If we gave each plugin its own version, which we did with Struts 1, it gets really confusing really quickly what versions are meant to go with what releases. For the occasional third-party plugin with its own release cycle, this is a necessary evil, but for the core plugins, it is a huge source of confusion to users. Don On 2/23/08, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/2/23, Al Sutton [EMAIL PROTECTED]: So what happens if a plug-in is added to the core (e.g. a YUI and/or GWT plugin to compliment the dojo one), does that necessitate a 2.2? This is The Good Question :-) As I wrote a lot of time before, IMHO every plugin should be treated as a different project, with its own version number, a-la Maven. This suggestion has not been taken into consideration and we are suffering the consequences, because lots of Struts 2 plugins are coming out day by day. Antonio - 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]
[s2] Struts 2.1.1 delayed
Unfortunately, my computer is experiencing severe stability problems, so the Struts 2.1.1 build will be delayed. I'm hoping to give it a shot next weekend. Of course, anyone is free to give it a go in the meantime... Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r630822 - in /struts/sandbox/trunk/struts2-osgi-plugin: ./ admin-bundle/ admin-bundle/src/ admin-bundle/src/main/ admin-bundle/src/main/java/ admin-bundle/src/main/java/org/ admin-bund
Cool, I just took whatever the Spring osgi archetype gave me. Glad to see activity as I came across at least one bug that'll hopefully be fixed in the next version :) Don On 2/25/08, Niall Pemberton [EMAIL PROTECTED] wrote: Don, just a FYI - the latest release of felix's bundle plugin is version 1.2.1 (theres also a vote underway on releasing 1.4.0) Niall On Mon, Feb 25, 2008 at 12:04 PM, [EMAIL PROTECTED] wrote: Author: mrdon Date: Mon Feb 25 04:04:16 2008 New Revision: 630822 URL: http://svn.apache.org/viewvc?rev=630822view=rev Log: Adding beginnings of an admin web bundle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.11.1 Quality (fast track) - PROPOSED ANNOUNCEMENT
Looks good. Thanks for creating a security bulletin as well. Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: The release has been submitted for mirroring. Here's a draft announcement that we could post tomorrow morning, including a link to a corresponding security bulletin announcement in the wiki. Comments and corrections to both texts are highly appreciated. Apache Struts 2.0.11.1 is now available from http://struts.apache.org/download.cgi#struts20111. This release is a fast track security fix release, including important security fixes regarding possible cross site scripting exploits. For more information about the exploits, visit our security bulletins page at http://cwiki.apache.org/confluence/display/WW/S2-002. * ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.11.1 IMMEDIATELY! For the complete release notes for Struts 2.0.11.1, see http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.11.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.11.1 Quality (fast track) - PROPOSED ANNOUNCEMENT
Good point. This pales in comparison to, say, the OGNL remote code exploit. XSS exploits, while important, just aren't anywhere near as big of deal. Don On Tue, Mar 4, 2008 at 12:43 PM, Jeromy Evans [EMAIL PROTECTED] wrote: My opinion is that the criticality is overstated. However it is useful to draw attention to the vulnerability. Don Brown wrote: Looks good. Thanks for creating a security bulletin as well. Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: The release has been submitted for mirroring. Here's a draft announcement that we could post tomorrow morning, including a link to a corresponding security bulletin announcement in the wiki. Comments and corrections to both texts are highly appreciated. Apache Struts 2.0.11.1 is now available from http://struts.apache.org/download.cgi#struts20111. This release is a fast track security fix release, including important security fixes regarding possible cross site scripting exploits. For more information about the exploits, visit our security bulletins page at http://cwiki.apache.org/confluence/display/WW/S2-002. * ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.11.1 IMMEDIATELY! For the complete release notes for Struts 2.0.11.1, see http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.11.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.11.1 Quality (fast track) - PROPOSED ANNOUNCEMENT
What about: * All developers are strongly advised to update Struts 2 applications to Struts 2.0.11.1 to prevent XSS attacks through Struts 2 tags. In this way, we aren't quite so in-your-face and a quick summary of the issue and what part of Struts 2 is affected is included. The qualifier is probably important as not all apps use the affected Struts 2 tags and since the release just includes that one fix, it is valuable to specify exactly what has been fixed. Still, these are all minor things - the important thing is that you got this release out so quickly and for that, we are all very grateful :) Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: Agreed. How should we put it better? Don Brown schrieb: Good point. This pales in comparison to, say, the OGNL remote code exploit. XSS exploits, while important, just aren't anywhere near as big of deal. Don On Tue, Mar 4, 2008 at 12:43 PM, Jeromy Evans [EMAIL PROTECTED] wrote: My opinion is that the criticality is overstated. However it is useful to draw attention to the vulnerability. Don Brown wrote: Looks good. Thanks for creating a security bulletin as well. Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: The release has been submitted for mirroring. Here's a draft announcement that we could post tomorrow morning, including a link to a corresponding security bulletin announcement in the wiki. Comments and corrections to both texts are highly appreciated. Apache Struts 2.0.11.1 is now available from http://struts.apache.org/download.cgi#struts20111. This release is a fast track security fix release, including important security fixes regarding possible cross site scripting exploits. For more information about the exploits, visit our security bulletins page at http://cwiki.apache.org/confluence/display/WW/S2-002. * ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.11.1 IMMEDIATELY! For the complete release notes for Struts 2.0.11.1, see http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.11.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.11.1 Quality (fast track) - PROPOSED ANNOUNCEMENT
Well, this was the first hit on google: http://www.microsoft.com/technet/security/bulletin/rating.mspx Therefore, I'd say Moderate to Important. Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: Yes, sounds good to me. How about the criticality rating in the bulletin? Critical was - I have to admit :) - just copied from 001, what would be a fitting rating here? Don Brown schrieb: What about: * All developers are strongly advised to update Struts 2 applications to Struts 2.0.11.1 to prevent XSS attacks through Struts 2 tags. In this way, we aren't quite so in-your-face and a quick summary of the issue and what part of Struts 2 is affected is included. The qualifier is probably important as not all apps use the affected Struts 2 tags and since the release just includes that one fix, it is valuable to specify exactly what has been fixed. Still, these are all minor things - the important thing is that you got this release out so quickly and for that, we are all very grateful :) Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: Agreed. How should we put it better? Don Brown schrieb: Good point. This pales in comparison to, say, the OGNL remote code exploit. XSS exploits, while important, just aren't anywhere near as big of deal. Don On Tue, Mar 4, 2008 at 12:43 PM, Jeromy Evans [EMAIL PROTECTED] wrote: My opinion is that the criticality is overstated. However it is useful to draw attention to the vulnerability. Don Brown wrote: Looks good. Thanks for creating a security bulletin as well. Don On 3/4/08, Rene Gielen [EMAIL PROTECTED] wrote: The release has been submitted for mirroring. Here's a draft announcement that we could post tomorrow morning, including a link to a corresponding security bulletin announcement in the wiki. Comments and corrections to both texts are highly appreciated. Apache Struts 2.0.11.1 is now available from http://struts.apache.org/download.cgi#struts20111. This release is a fast track security fix release, including important security fixes regarding possible cross site scripting exploits. For more information about the exploits, visit our security bulletins page at http://cwiki.apache.org/confluence/display/WW/S2-002. * ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.11.1 IMMEDIATELY! For the complete release notes for Struts 2.0.11.1, see http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.11.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Leverage Spring's namespace support for s2 configuration
I've put down some thoughts as to how we could leverage Spring's XML schema support to merge the Struts and Spring XML into one file. For Struts apps, this might be a nice way to leverage all the XML loading advantages of Spring and remove yet another configuration file, however my main motivation is to leverage the Spring Dynamic Modules project and this opens the door there. http://cwiki.apache.org/confluence/display/S2PLUGINS/Spring+namespace+whiteboard Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
FWIW, Struts Annotations 1.0.3 has been released and approved, but I
haven't had time to finish it off by signing the jar and moving it to
the official repo. I'll try to find some time in the next few days if
no one beats me to it.
Don
On Fri, Apr 4, 2008 at 8:59 PM, Ted Husted [EMAIL PROTECTED] wrote:
Yes, it is something we should do first. It's on the list, but I
usually forget about it until the last minute ... :)
Are you setup to digitally sign the releases, Jeromy? It's the
one-time section of Creating and Signing a Distributiob
*
http://struts.apache.org/2.0.11.1/docs/creating-and-signing-a-distribution.html#CreatingandSigningaDistribution-Onetime
For a wet run of the release, that's usually the blocker for people.
After that, it's a bit of a bother, but not actually difficult to do.
Since it seems like you've already done most of the work, would you
like to add your name to the release plan as a co-manager (along with
mine)?
* http://struts.apache.org/2.0.11.1/docs/version-notes-211.html
-Ted.
On Fri, Apr 4, 2008 at 4:35 AM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Is the release of struts-annotations-1.0.3 a blocker? It's not in central
yet.
struts-annotations dependencies:
./core/pom.xml:425: version1.0.3-20080216.121126-3/version
./plugins/dojo/pom.xml:261: version1.0.3-20080123.123514-2/version
../maven/struts-annotations/pom.xml: version1.0.4-SNAPSHOT/version
Jeromy Evans wrote:
Ted, I tried to get you started with a dryRun of release:prepare but I'm
still missing xwork.jar:2.1.1. The mvn output is at
http://people.apache.org/~jeromy/buildlog1.txt
Other details:
* JIRA: No open issues except the omnibus ticket
(https://issues.apache.org/struts/browse/WW-2421)
* Release Notes: reasonably up-to-date:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
svn co https://svn.apache.org/repos/asf/struts/struts2/trunk
STRUTS_2.1.1
svn info: Revision: 644624
* check pom.xml repositories (I'm not sure values should be here)
find . -name pom.xml -exec grep -i -H -n 'repository' {}
./pom.xml:72
urlscp://people.apache.org/www/people.apache.org/builds/struts/${pom.version}/m2-staging-repository/url
./apps/pom.xml:73 urlhttp://repository.codehaus.org/url
find . -name pom.xml -exec grep -i -H -n 'snapshotRepository' {}
./pom.xml
urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/url
* change mvn settings.xml to a clean localRepository and dryRun
release:prepare
mvn release:prepare -P release,all,alljars,j4,pre-assembly
-DdryRun=true
The mvn output is at http://people.apache.org/~jeromy/buildlog1.txt
That's as far as I got because I shouldn't have to install:install-file
xwork-2.1.1 into my localRepository, so I guess I have to wait a little
longer for it to replicate?
regards,
Jeromy Evans
Ted Husted wrote:
I'm still heads-down, but I could run a build through the gauntlet.
Can anyone confirm that everything else we want to do is done, and
we're at the tag and roll point?
-Ted.
On Tue, Apr 1, 2008 at 7:21 AM, Rainer Hermanns [EMAIL PROTECTED]
wrote:
Ted, others,
xwork 2.1.1 is out and should be in the repos shortly.
So we should be ready for a Struts 2.1.1 release build now.
thanks for waiting,
Rainer
On Apr 1, 2008, at 12:24 AM, Ted Husted wrote:
And, if we're ready to roll a Struts after that, I'd be happy to
step
through the process Wednesday night.
-Ted.
On Mon, Mar 31, 2008 at 4:05 PM, Rainer Hermanns
[EMAIL PROTECTED]
wrote:
Sorry, but I have to delay the xwork release until tomorrow.
cheers,
Rainer
Hey there,
I am working on the open issues for xwork 2.1.1 over the
weekend,
so that the release could be out on monday.
Since lots of fixes and changes were done affecting S2.1 core
features, testing S2.1 with latest xwork snapshots would help
to
get
both codebases stablelized.
Please report xwork errors to XWork Jira [1].
Ted, if you have some time next week for getting out the
release,
that would be awesome.
cheers,
Rainer
[1] http://jira.opensymphony.com
I will help testing it (I don't have any application on
production
tho). Ted if you could do it, it would be great, I think it
is
about
time we get a build out there.
regards
musachy
[s2] Get rid of optional dependencies
In an effort to make Struts 2 more OSGi friendly, I noticed we have a number of optional dependencies that confuse the bnd plugin. I'd like to take the next step and resolve these: * DWR - Create a struts2-dwr-plugin * Velocity - Create a struts2-velocity-plugin * Commons File Upload - Change jar to be required or at least commit a simple implementation into core and create struts2-commons-fileupload-plugin * JUnit - Create struts2-junit-plugin (we'd probably have to copy the testcase into our test code to avoid the circular dependency, keeping the testhelper class in core) * TestNG - Create struts2-testng-plugin Any objections? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature sponsorship proposal
I think you are assuming the community isn't composed of Corporations, when in fact, they play an important part in almost every successful Open Source project. From providing hardware to sponsoring conferences to paying developers to work on projects, companies play a critical role in the community. Apache is concerned, and rightly so, that a single company may gain too much control in a project, but Apache just plain wouldn't exist without corporate support. One of the core aspects of the ASF, the Apache Public License, encourages corporate acceptance of Open Source projects. The core issue in this proposal is something that has bothered me about Struts for years - we do a poor job giving credit to contributors. I remember this one Open Source project I started playing with that would include a little note of thanks/credit next to a feature in the release notes, something simple like, Added feature foo. Thanks Wendy for the patch! Just that little note, a few characters really, did so much to encourage participation and build a community. Community members want to feel like they make a difference and when the only recognition they get is a patch buried in the depths of JIRA or even in a commit no one will ever see, the motivation isn't there. This proposal gives us an opportunity to kill two birds with one stone - put in place a sane, community-building attribution system, and give companies that want to give back to the community a clear path to get involved. The ASF and Struts, in particular, has always been about the community - isn't it time we started recognizing that? Don On Tue, Apr 8, 2008 at 1:49 AM, James Mitchell [EMAIL PROTECTED] wrote: I'm inclined to vote down anything mixing Community and Corporate agenda. I think that's just a bad mix. In fact, the ASF has specific rules/guidelines with respect to corporate involvement (employment) with too many project leads. There's a reason that Apache projects are so successful, in one word ... community. I hate it as much as the next guy when movement seems to stagnate for weeks/months, but that's never just cause to bring in money/free stuff as incentive. The folks who want to help when there's a prize at the end will be the first ones to dump your a## when you really need them, but don't have an incentive to offer. If Struts (or any project) doesn't have enough volunteers to keep the work going, then we have bigger issues. Just my $0.02! On Mon, Apr 7, 2008 at 10:47 AM, Robert Leland [EMAIL PROTECTED] wrote: Don I have a few questions 1) I agree that this contribution has to be valuable to the contributing company both technically and marketing. Back in 2003 when I obtained free IntelliJ licenses from Jetbrains for the Struts Committers all they wanted was acknowledgment on our web page and that was voted down as too commercial. To IntelliJ's credit they still provided the license and later expanded it to all of Apache. How has the Struts PMC changed since then to allow what your proposing ? 2) What if a proposal isn't on the short list of features, however when it is proposed the Struts community its viewed as a useful idea ? 3) What if it turns out that two competing companies have different implementations, which is a great place to be in. Do we need to think this far ahead or using Agile methods do we not want to over design this process initially ? -Rob Don Brown wrote: As more and more companies start using open source software, many, like mine, are looking for ways to give back to the community. They want a way to contribute and ensure their contribution will be noticed and appreciated. What if we had a feature sponsorship program that encouraged companies to donate engineering time to filling out needed features in Struts? I imagine it would work like this: 1. The Struts community comes up with a short list of desired features with high-level specs 2. Companies (or individuals) could sign up for a feature and donate internal engineering time to implementing the feature 3. The Struts community would review then commit the feature 4. The release notes for that version and perhaps somewhere on the website would note who gets credit for the feature This would help those that want to donate time what features are most needed by the community and give them a way to receive recognition for their work in a very public way.A key component in this proposal is the way credit is given to the work, something that might encourage the marketing departments of the respective companies. The list of desired features is also important as it ensures their effort will not be in vain, and it also implies the support of the Struts dev community to work to apply the patch in a timely manner. Thoughts
Re: [s2] Get rid of optional dependencies
Actually, the solution is pretty simple here: copy/paste. All the logic is in a TestCaseHelper or whatever class that is in core. We move the StrutsTestCase, only a few lines of code, into our src/test/java directory then create a new struts2-junit-plugin (or whatever) jar and copy the code in there too. Same process to solve the TestNG dependency only there, we don't even need it in src/test/java. Don On Mon, Apr 7, 2008 at 11:43 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/4/7, Don Brown [EMAIL PROTECTED]: * JUnit - Create struts2-junit-plugin (we'd probably have to copy the testcase into our test code to avoid the circular dependency, keeping the testhelper class in core) * TestNG - Create struts2-testng-plugin This is a difficult one, since the core must depend on the JUnit and TestNG artifact, while these two depend on the core. Yuk! Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature sponsorship proposal
Exactly - I'm not suggesting we change how we accept contributions at all and of course, we would try to give credit to individuals where desired, but look at it this way: if IBM donated a server to us, would we credit the person who processed the order or the company that purchased the computer? Paying someone to develop a feature is a significant contribution that should be recognized, IMO, along side the individual who performed the work. In addition, as you point out, not everything can be traced back to a single individual. For example, for a given feature in an Atlassian product, there is involvement from probably 6 or 7 people: product manager, project manager, UI designer, tech writer, product marketing guy, and the two developers that paired on the feature. If a company took their donation seriously and brought their resources to bear, I think that deserves recognition. Don On Tue, Apr 8, 2008 at 7:37 PM, Ted Husted [EMAIL PROTECTED] wrote: On Tue, Apr 8, 2008 at 5:27 AM, Ted Husted [EMAIL PROTECTED] wrote: But, saying thanks to Wendy's employer might cross the line. One of our precepts is that ASF projects are composed of individuals, and so we give the credit to individuals. The farthest we might be able to go is to say Wendy of BigCo, Inc., if that's how Wendy wanted to be described. Unless, of course, most or all of the feature was developed outside of the project, and then donated in bulk, under a CCLA (as James implied). Of course, in that case, we'd then have to pass the contribution through the incubator, to vet the IP. Of course, we'd have to reserve the right to reject the contribution if the code was not up to our standards. (In fact, back in the day, the first contribution by an paid IBM engineer to Apache HTTPD was rejected!). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are Struts JARs OSGi Aware?
All it means is we'd ensure certain values are in our MANIFEST.MF file. There is this nice m2 plugin that does all the work for you. This is something I'm working on for Struts 2 (hence trying to remove optional dependencies). Don On Wed, Apr 9, 2008 at 6:12 AM, Paul Benedict [EMAIL PROTECTED] wrote: What purpose is making OSGi jars for Struts? I am familiar with the technology, but don't see what purpose bundling Struts as such. I hope to learn something. Paul On Tue, Apr 8, 2008 at 11:47 AM, Matt Raible [EMAIL PROTECTED] wrote: Are Struts JARs OSGi-aware? Spring MVC's are as of 2.5.3. I think it'd be good to do the same for Struts JARs. Thanks, Matt -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
*sigh* is this all necessary? I mean, by using the Maven release plugin, the binaries are created off the tag. A quick SVN command can confirm the tag hasn't been modified, so I don't see any problem with Jeromy building new binaries and finishing the release. The vote had passed with the caveat that the binaries are signed, so if Jeromy built the same binaries, a new vote would be an exercise in useless bureaucracy, IMO. Don On Wed, Apr 9, 2008 at 10:30 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Wendy Smoak wrote: On Tue, Apr 8, 2008 at 8:54 AM, Jeromy Evans [EMAIL PROTECTED] wrote: I've signed struts-annotations-1.0.3 using [EMAIL PROTECTED] and copied to [1]. Where/how did you sign them? Were the files re-built? Generally you only sign what you build yourself, while it's under your control on a machine you trust. Thanks for looking at these Wendy. It's difficult to step-in part way through the process. I checked the source out from the struts-annotations-1.03 TAG. I packaged and signed them myself but DID NOT deploy to m2-staging-repository as that task was complete already From step 7 of Ref[1], I signed the build artifacts and copied them to Ref[2] as per step 8. [1] http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Distribution [2] http://people.apache.org/builds/struts/struts-annotations/1.0.3/ I'm also not sure how the vote passed, if they were never signed originally. I see that you mentioned that during the vote. Can some please take a moment to check these? If they're okay I presume the artefacts then just need to be copied to the right location for rsync to ibiblio. Any other formalities for struts-annotations? [1] http://people.apache.org/builds/struts/struts-annotations/1.0.3/ Is this the same as what's in http://people.apache.org/builds/struts/struts-annotations/1.0.3/m2-staging-repository/org/apache/struts/struts-annotations/1.0.3/ ? I think that is a problem isn't it? The files in the m2-staging-repository [3] were built and deployed by Don, not the files I built and signed [2] As the maven artefacts for ibiblio come from m2-staging-repository they'd be Don's binaries, not mine. I presume that means the process has to be started from scratch unless Don completes as only he can/should sign the binaries he created and voters tested? [3] http://people.apache.org/builds/struts/struts-annotations/1.0.3/m2-staging-repository/org/apache/struts/struts-annotations/1.0.3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Actually, it did. If you just add up the +1's, they are much more than the single -1, and even that was given under the assumption that as soon as there were signatures, it would turn into a +1. My reading of the bylaws shows it only needed a majority vote after a 72 hour window, so yes, it did pass. Don On Wed, Apr 9, 2008 at 5:19 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/4/8, Wendy Smoak [EMAIL PROTECTED]: I'm also not sure how the vote passed, if they were never signed originally. I think that the vote did not pass: http://www.nabble.com/forum/ViewPost.jtp?post=15540281framed=y Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: i18n/TextProvider issues
Sounds good. Are there any performance implications? Don On Fri, Apr 11, 2008 at 3:48 PM, Jeromy Evans [EMAIL PROTECTED] wrote: I've been investigating some i18n issues in the 2.1.x branch and found that the search algorithm used by the Text tag differs from that of UIBean. The Text tag iterates through the ValueStack looking for the first TextProvider and invokes getText(...) on the first found. The UIBean executes the OGNL expression getText(String), which matches this method of the first TextProvider. This works almost all the time, but I have two issues with it: - the inconsistent search algorithm causes inconsistent behaviour when there's something unexpected in the stack (https://issues.apache.org/struts/browse/WW-2539) - the OGNL expression is slow (https://issues.apache.org/struts/browse/WW-1681) and fragile (https://issues.apache.org/struts/browse/WW-2511) I'm going to remove the hardcoded OGNL expressions from UIBean and Label and replace them with the same algorithm used by Text. I would have proceeded without saying so but I also discovered that the TestAction used by the unit tests relies on getText being invoked directly by OGNL rather than its TextProvider implementation, so the consequences may be larger that I first imagined. Please speak up if you see any potential issues. regards, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: i18n/TextProvider issues
Neat, hard to argue with that. Don On Fri, Apr 11, 2008 at 4:13 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Don Brown wrote: Sounds good. Are there any performance implications? Don According to https://issues.apache.org/struts/browse/WW-1681 the performance implications are very significant (significantly improved). getText(String) invoked via OGNL and and getText(key, defaultValues, args) invoked via Text are essentially identical in the default implementation (TextPrroviderSupport) as both invoke LocalizedTextUtil.findText(). The improvement comes down to iteration through the stack to find a class vs ognl expression evaluation plus iteration through the stack to find a method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Get rid of optional dependencies
Ok, I created the following new plugins with associated docs: * JUnit Plugin * TestNG Plugin * DWR Plugin I had to skip the Velocity plugin as it is too tightly integrated into our tag library interfaces, which I'm not sure is a good thing or a bad thing. I also made Commons FileUpload required to a) reduce user confusion and b) ensure that file upload tag shipped in core works. I'm not sure we want to keep the DWR plugin as a bundled plugin or if we should just move it off to google code or wherever. From what I can tell, it hasn't worked in a while, and no one has complained, so I wonder if it is even used. So anyways, I wasn't able to get rid of all the optionals, but it is looking better. The last major refactoring I've been contemplating is moving tags out into their own plugin, but I'm still not 100% sure it is a good idea. Don On Tue, Apr 8, 2008 at 1:04 PM, Don Brown [EMAIL PROTECTED] wrote: Actually, the solution is pretty simple here: copy/paste. All the logic is in a TestCaseHelper or whatever class that is in core. We move the StrutsTestCase, only a few lines of code, into our src/test/java directory then create a new struts2-junit-plugin (or whatever) jar and copy the code in there too. Same process to solve the TestNG dependency only there, we don't even need it in src/test/java. Don On Mon, Apr 7, 2008 at 11:43 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/4/7, Don Brown [EMAIL PROTECTED]: * JUnit - Create struts2-junit-plugin (we'd probably have to copy the testcase into our test code to avoid the circular dependency, keeping the testhelper class in core) * TestNG - Create struts2-testng-plugin This is a difficult one, since the core must depend on the JUnit and TestNG artifact, while these two depend on the core. Yuk! Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 trunk broken build
Should be fixed. Don On Mon, Apr 14, 2008 at 6:27 PM, Giovanni Azua [EMAIL PROTECTED] wrote: hi, I get the Maven failure below while trying to build the latest S2 trunk (rev 647691). The following plugin is not found: -DgroupId=org.apache.myfaces.tobago -DartifactId=maven-apt-plugin When I go and check the maven-apt-plugin there is no version 1.0.16 but 1.0.15 only. I can locally workaround the issue by adding the version tag fixed to 1.0.15 in: ./core/pom.xml ./plugins/dojo/pom.xml regards, Giovanni [INFO] [INFO] Building Struts 2 Core [INFO]task-segment: [clean, install, package] [INFO] [INFO] artifact org.apache.myfaces.tobago:maven-apt-plugin: checking for updates from central [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'b4049c851dd930e2b7132a5adec99a2760779fba'; remote = '42200262f4701c5eaaa365e9be4838004acec3e4' - RETRYING [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'b4049c851dd930e2b7132a5adec99a2760779fba'; remote = '42200262f4701c5eaaa365e9be4838004acec3e4' - IGNORING Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/tobago/maven-apt-plugin/1.0.16/maven-apt-plugin-1.0.16.pom Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/tobago/maven-apt-plugin/1.0.16/maven-apt-plugin-1.0.16.jar [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Ok, Struts Annotations 1.0.3 has been signed and released to the
ibiblio sync'ed repository. If anyone was itching to jump in and get
Struts 2.1.1 out, this would be the time.
Don
On Sun, Apr 6, 2008 at 10:28 PM, Don Brown [EMAIL PROTECTED] wrote:
FWIW, Struts Annotations 1.0.3 has been released and approved, but I
haven't had time to finish it off by signing the jar and moving it to
the official repo. I'll try to find some time in the next few days if
no one beats me to it.
Don
On Fri, Apr 4, 2008 at 8:59 PM, Ted Husted [EMAIL PROTECTED] wrote:
Yes, it is something we should do first. It's on the list, but I
usually forget about it until the last minute ... :)
Are you setup to digitally sign the releases, Jeromy? It's the
one-time section of Creating and Signing a Distributiob
*
http://struts.apache.org/2.0.11.1/docs/creating-and-signing-a-distribution.html#CreatingandSigningaDistribution-Onetime
For a wet run of the release, that's usually the blocker for people.
After that, it's a bit of a bother, but not actually difficult to do.
Since it seems like you've already done most of the work, would you
like to add your name to the release plan as a co-manager (along with
mine)?
* http://struts.apache.org/2.0.11.1/docs/version-notes-211.html
-Ted.
On Fri, Apr 4, 2008 at 4:35 AM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Is the release of struts-annotations-1.0.3 a blocker? It's not in
central
yet.
struts-annotations dependencies:
./core/pom.xml:425: version1.0.3-20080216.121126-3/version
./plugins/dojo/pom.xml:261: version1.0.3-20080123.123514-2/version
../maven/struts-annotations/pom.xml: version1.0.4-SNAPSHOT/version
Jeromy Evans wrote:
Ted, I tried to get you started with a dryRun of release:prepare but
I'm
still missing xwork.jar:2.1.1. The mvn output is at
http://people.apache.org/~jeromy/buildlog1.txt
Other details:
* JIRA: No open issues except the omnibus ticket
(https://issues.apache.org/struts/browse/WW-2421)
* Release Notes: reasonably up-to-date:
http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.1
svn co https://svn.apache.org/repos/asf/struts/struts2/trunk
STRUTS_2.1.1
svn info: Revision: 644624
* check pom.xml repositories (I'm not sure values should be here)
find . -name pom.xml -exec grep -i -H -n 'repository' {}
./pom.xml:72
urlscp://people.apache.org/www/people.apache.org/builds/struts/${pom.version}/m2-staging-repository/url
./apps/pom.xml:73 urlhttp://repository.codehaus.org/url
find . -name pom.xml -exec grep -i -H -n 'snapshotRepository' {}
./pom.xml
urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/url
* change mvn settings.xml to a clean localRepository and dryRun
release:prepare
mvn release:prepare -P release,all,alljars,j4,pre-assembly
-DdryRun=true
The mvn output is at http://people.apache.org/~jeromy/buildlog1.txt
That's as far as I got because I shouldn't have to
install:install-file
xwork-2.1.1 into my localRepository, so I guess I have to wait a little
longer for it to replicate?
regards,
Jeromy Evans
Ted Husted wrote:
I'm still heads-down, but I could run a build through the gauntlet.
Can anyone confirm that everything else we want to do is done, and
we're at the tag and roll point?
-Ted.
On Tue, Apr 1, 2008 at 7:21 AM, Rainer Hermanns [EMAIL PROTECTED]
wrote:
Ted, others,
xwork 2.1.1 is out and should be in the repos shortly.
So we should be ready for a Struts 2.1.1 release build now.
thanks for waiting,
Rainer
On Apr 1, 2008, at 12:24 AM, Ted Husted wrote:
And, if we're ready to roll a Struts after that, I'd be happy to
step
through the process Wednesday night.
-Ted.
On Mon, Mar 31, 2008 at 4:05 PM, Rainer Hermanns
[EMAIL PROTECTED]
wrote:
Sorry, but I have to delay the xwork release until tomorrow.
cheers,
Rainer
Hey there,
I am working on the open issues for xwork 2.1.1 over the
weekend,
so that the release could be out on monday.
Since lots of fixes and changes were done affecting S2.1
core
features, testing S2.1 with latest xwork snapshots would
help to
get
both codebases stablelized
Re: 2.1 build
I'm in the process of creating that build right now. Soon, I will announce the build to this list and ask for testing. The Struts community will then vote as to its quality, and it may turn into a beta or GA release, or remain a test build. Personally, I'm aiming for a beta release and expect to be doing several more quick releases to work out the kinks. Don On Fri, Apr 18, 2008 at 12:24 AM, Giovanni Azua [EMAIL PROTECTED] wrote: hi, Is it the tagged version 2.1.1 under subversion https://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_1_1; the recommended 2.1.x to be used? Will it appear as official GA download anytime soon? thanks in advance, Best regards, Giovanni - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r649024 - /struts/struts2/trunk/pom.xml
The fact that it was reporting hundreds of errors leads me to believe the problem is probably a combination of its configuration and the code, but regardless, getting through the release process is more important than running down this issue to me. I hope to investigate it further after the build is out, but right now, I'm focused on finishing the process, which is proving to be its own challenge (7 hours and counting...) Don On Fri, Apr 18, 2008 at 12:28 AM, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 2:39 AM, [EMAIL PROTECTED] wrote: Author: mrdon Date: Thu Apr 17 02:39:06 2008 New Revision: 649024 URL: http://svn.apache.org/viewvc?rev=649024view=rev Log: Commenting out the rat plugin as it is holding up the release. It shouldn't be uncommented until it is known to have passed. But the point of RAT is that if it fails, the project isn't ready for a release. What is the real issue here? -- Martin Cooper WW-2414 Modified: struts/struts2/trunk/pom.xml Modified: struts/struts2/trunk/pom.xml URL: http://svn.apache.org/viewvc/struts/struts2/trunk/pom.xml?rev=649024r1=649023r2=649024view=diff == --- struts/struts2/trunk/pom.xml (original) +++ struts/struts2/trunk/pom.xml Thu Apr 17 02:39:06 2008 @@ -225,6 +225,7 @@ /execution /executions /plugin +!-- Commenting it out until it stops breaking the release plugin groupIdorg.codehaus.mojo/groupId artifactIdrat-maven-plugin/artifactId @@ -250,6 +251,7 @@ /execution /executions /plugin +-- /plugins /build /profile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Cool, thanks James. Man, this release, while much, much better thanks to Wendy and Antonio, still takes _forever_ and is error prone. One main culprit is the speed (or lack thereof) of the scp wagon, and of course, it doesn't help I'm doing this from Australia (where it is 12:30 AM on a Friday morning I might add). I'm trying to keep a list of issues to tackle later, as I'd like to see us do builds every week or so till we get a GA release. Don On Fri, Apr 18, 2008 at 12:33 AM, James Mitchell [EMAIL PROTECTED] wrote: Don, I'm checking out the tag now and will be giving it a thorough test drive today and tomorrow. Thanks On Thu, Apr 17, 2008 at 10:27 AM, Don Brown [EMAIL PROTECTED] wrote: I'm in the process of creating that build right now. Soon, I will announce the build to this list and ask for testing. The Struts community will then vote as to its quality, and it may turn into a beta or GA release, or remain a test build. Personally, I'm aiming for a beta release and expect to be doing several more quick releases to work out the kinks. Don On Fri, Apr 18, 2008 at 12:24 AM, Giovanni Azua [EMAIL PROTECTED] wrote: hi, Is it the tagged version 2.1.1 under subversion https://svn.apache.org/repos/asf/struts/struts2/tags/STRUTS_2_1_1; the recommended 2.1.x to be used? Will it appear as official GA download anytime soon? thanks in advance, Best regards, Giovanni - 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] -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Test build of 2.1.1 available
The test build of Struts 2.1.1 is available.
No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Struts 2.1.1 has been made, and at this time it is simply a test
build. We welcome any comments you may have, and will take all
feedback into account if a quality vote is called for this build.
Release notes:
* http://struts.apache.org/2.0.11.1/docs/version-notes-211.html
Distribution:
* http://people.apache.org/builds/struts/2.1.1/
Maven 2 staging repository:
* http://people.apache.org/builds/struts/2.1.1/m2-staging-repository/
We appreciate the time and effort everyone has put toward contributing
code and documentation, posting to the mailing lists, and logging
issues.
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Test build of 2.1.1 available
Whoops, that should be: http://struts.apache.org/2.x/docs/version-notes-211.html Don On Sat, Apr 19, 2008 at 12:07 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Don Brown wrote: The test build of Struts 2.1.1 is available. Release notes: * http://struts.apache.org/2.0.11.1/docs/version-notes-211.html Any idea why this published Version 6 of the release notes dated 19 Feb 08 instead of Version 11 that was current at 17 Apr 08? Note the incorrect URL also. - 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]
[s2] A thought - next generation OSGi-based?
As I learn more and more about OSGi, I wonder if it might be the solution to several big problems we seem to have at the moment: poor reloadability and the lack of a solid API. With OSGi, you can drop bundles in and out of the system at runtime, even running multiple versions of the same bundle side-by-side, but the feature I'm most interested in right now is how it would allow us to put in a proper API while maintaining full backwards-compatibility. Evolving a web framework is hard because apps tend to be written on a specific version, and to migrate them to new versions has two problems: development may not be continuously funded and the upgrade may require too many changes to the application. On the other hand, if you don't evolve your web framework, you quickly go out-of-date and lose interest from new developers. In our case, despite being a relatively new framework, we have legacy code around from 2004 that we can't just remove, yet we want to provide an attractive, modern, clean framework for new development. The specific issue it hand that I've been thinking about is how to get a proper API into Struts 2 yet keep backwards compatibility, and I think OSGi might provide a solution. What about this: 1. Struts 2 and its plugins remain the way they are now - 100% backwards-compatibility 2. An OSGi plugin provides the platform for the next generation of Struts 2 3. A new API bundle is created, implemented by the underlying Struts 2 framework 4. Old apps can continue to write and deploy code against Struts 2, yet new development can start to use the new API 5. Later, when we want to write API version 2, we create a new bundle that runs side-by-side the old bundle, both implemented by Struts 2 Basically, OSGi would allow us to write a clean layer on top of a framework, much like how Grails builds on Spring, but we get, as a side benefit, all the architectural advantages of OSGi for free. Furthermore, if we do it right, users don't have to know or care that OSGi is under the hood - all they know is they write a jar, drop it in a directory or upload it via a form and they just installed part of their application at runtime. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Sanity-check trunk pom version num
2.1.2-SNAPSHOT Don On Fri, Apr 25, 2008 at 12:22 PM, Dave Newton [EMAIL PROTECTED] wrote: Can someone tell me if I'm nuts and/or my Eclipse/Maven thing is going crazy? What should I get as a plugin snapshot version number in trunk, 2.1.1 or 2.1.2, when building via Maven? Thanks, and *agh*, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
the version of the API that
the application is using and then select a configuration manager based on
that.
Now, there might be some type of tricks and things that OSGi can provide
to make this happen, but I'm not familiar enough with advanced bundling and
classloading to know how it would work. From what I understand of OSGi, any
bundle can only use a version of a dependent bundle that is compatible with
the version of that dependent bundle it compiled against.
For example, if I compiled against log4j 1.0, I can use 1.3 because they
are compatible at runtime and compile time. However, I can't use log4j 2.0
because the interfaces changed and things will blow up nicely at runtime.
What OSGi does provide is the ability to have one bundle using log4j 1.x and
another bundle using log4j 2.x in the same VM. I'm not aware that they have
gone any further than that.
Ian Roughley wrote:
Is this the case, or was the thinking more like:
- app 1
- api 1.0 --{
/ - app 2
Struts ---{
\ - app 4
- api 2.0 --{
- app 3
I think this is how I perceived it. I also agree with Brian that
there will be a burden on s2 to provide the necessary features for all APIs,
but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one
- Struts2
2. Do you want to allow implementors to implement multiple APIs?
Sounds like yes.
3. How much is shared between APIs? Probably a lot.
From what it sounds like, and correct me if I'm wrong, you are
looking to do something like this:
API 1.0--\
|--- Struts2
API 2.0--/
If this is the case, it will require some interesting coding
tactics. Sun and IBM have some white papers on these types of cases. OSGi
will shield the two APIs from each other so there aren't any conflicts,
however, the implementor will have the unfortunate task of implementing
both. This becomes difficult without proper structure at compile time
because struts2 will need to implement multiple interfaces from both
versions and these interfaces might overlap.
I've done some of this type of work before and in order to truly
break compatibility between 1.0 and 2.0, you need namespaces in order to
allow Struts2 to implement both. Otherwise you get naming conflicts that
cannot be resolved by the compiler. I've do things like this before:
org.apache.struts.api1.SomeInterface
org.apache.struts.api2.SomeInterface
This is the same interface, but breaks compatibility between the API
versions. Only by separating the namespaces will you be able to implement
both at compile time. I've also worked with other situations like this:
org.apache.struts.api.SomeInterface_1_0
org.apache.struts.api.SomeInterface_2_0
What it comes down to is that if you are going to break
compatibility at the API level you need to actually create a brand new API.
When you look at it from this perspective, OSGi really isn't needed, just
nice to have. Since the two API versions are in different namespaces, there
aren't any collisions at compile-time or runtime, eliminating the need for
bundle separation.
Having done some of these types of solutions before, I can attest to
the pain that they can cause. They can also become complex to manage. Which
sorta leads back to my original statements about compatibility. I'd much
rather see something like this:
1. The APIs locked down
2. These APIs called Struts3
3. No APIs break compatibility until Struts4
Therefore, 3.0, 3.1, 3.2, etc are all compatible. Then when Struts4
start wanting to break compatibility, you branch Struts3, and start breaking
away on Trunk.
-bp
Don Brown wrote:
As I learn more and more about OSGi, I wonder if it might be the
solution to several big problems we seem to have at the moment:
poor
reloadability and the lack of a solid API. With OSGi, you can
drop
bundles in and out of the system at runtime, even running multiple
versions of the same bundle side-by-side, but the feature I'm most
interested in right now is how it would allow us to put in a
proper
API while maintaining full backwards-compatibility.
Evolving a web framework is hard because apps tend to be written
on a
specific version, and to migrate them to new versions has two
problems: development may not be continuously funded and the
upgrade
may require too many changes to the application. On the other
hand
[s2] Struts 2.1.2 build target
I'd like to roll the 2.1.2 test build this Friday. The updated release plan is here: http://struts.apache.org/2.x/docs/version-notes-212.html Please ensure the build stays green, and make any major changes, like bringing in the Conventions plugin, in the next day or two, and not any later. The major tickets I'd like to resolve are: * Upgrade to OGNL 2.7.2 -- https://issues.apache.org/struts/browse/WW-2527 * Missing plugins from release artifacts -- https://issues.apache.org/struts/browse/WW-2604 * A bunch of other small bugs/improvements A couple areas I'd like to see someone tackle before then: File upload issues: * https://issues.apache.org/struts/browse/WW-1885 * https://issues.apache.org/struts/browse/WW-1880 Missing license headers: * https://issues.apache.org/struts/browse/WW-2147 Memory leaks: * https://issues.apache.org/struts/browse/WW-2167 And as always, there are a bunch of tag and dojo tag-related issues that need attention. If you were thinking you wanted to donate some time to fix a few bugs or submit some patches, now is the time. Let's get a 2.1.2 release out by JavaOne. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
Ok, I promised a more detailed proposal, so here it is: http://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi I converted Jeromy's goals into a more proper tech spec (with the pretty diagrams to follow...) I highly recommend those not familiar with OSGi to take a look at the references section, specifically the tutorials. OSGi brings some significant, game-changing elements to the table, so to fully understand the proposal and its possibilities, give them a look. I'll be updating the proposal to incorporate more feedback as I receive it. I'll be at JavaOne next week, so swing by the Atlassian booth and let's talk shop. Don On Sat, Apr 26, 2008 at 2:21 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Putting aside the technology for a moment: - ability to deploy new actions/replace actions and pages without a container restart: highly desirable - ability to deploy new/replace business-layer services without a container restart: highly desirable - ability to evolve Struts2 without fear of breaking an API; highly desirable If, through appropriate packaging, OSGi facilities those requirements that them I'm all for it. At this point I don't have a good appreciation of what *actually exists* in this area. I'd take care to ensure Struts2 continues to target entry-level containers though (ie. Tomcat rather than Glassfish). Don Brown wrote: As I learn more and more about OSGi, I wonder if it might be the solution to several big problems we seem to have at the moment: poor reloadability and the lack of a solid API. With OSGi, you can drop bundles in and out of the system at runtime, even running multiple versions of the same bundle side-by-side, but the feature I'm most interested in right now is how it would allow us to put in a proper API while maintaining full backwards-compatibility. Evolving a web framework is hard because apps tend to be written on a specific version, and to migrate them to new versions has two problems: development may not be continuously funded and the upgrade may require too many changes to the application. On the other hand, if you don't evolve your web framework, you quickly go out-of-date and lose interest from new developers. In our case, despite being a relatively new framework, we have legacy code around from 2004 that we can't just remove, yet we want to provide an attractive, modern, clean framework for new development. The specific issue it hand that I've been thinking about is how to get a proper API into Struts 2 yet keep backwards compatibility, and I think OSGi might provide a solution. What about this: 1. Struts 2 and its plugins remain the way they are now - 100% backwards-compatibility 2. An OSGi plugin provides the platform for the next generation of Struts 2 3. A new API bundle is created, implemented by the underlying Struts 2 framework 4. Old apps can continue to write and deploy code against Struts 2, yet new development can start to use the new API 5. Later, when we want to write API version 2, we create a new bundle that runs side-by-side the old bundle, both implemented by Struts 2 Basically, OSGi would allow us to write a clean layer on top of a framework, much like how Grails builds on Spring, but we get, as a side benefit, all the architectural advantages of OSGi for free. Furthermore, if we do it right, users don't have to know or care that OSGi is under the hood - all they know is they write a jar, drop it in a directory or upload it via a form and they just installed part of their application at runtime. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2.1.2 build target
Very cool, thanks Antonio. It obviously works as Bamboo is running the release profile and it hasn't complained. I sure wasn't looking forward to adding license headers to 600+ files :) Don On Mon, Apr 28, 2008 at 12:20 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/4/27 Antonio Petrelli [EMAIL PROTECTED]: 2008/4/27 Don Brown [EMAIL PROTECTED]: Missing license headers: * https://issues.apache.org/struts/browse/WW-2147 The fix is almost ready, but I need to finish the RAT plugin configuration. Done :-) Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
Nope, no changes to XWork are necessary, and most likely no changes to Struts 2 core either. Don On Mon, Apr 28, 2008 at 11:46 PM, James Mitchell [EMAIL PROTECTED] wrote: How does this affect XWork? It seems like most of this would need to be integrated into XWork core, so, would XW need to be completely overhauled? Move it to the ASF? Or do we drop XW altogether for something else? Is there enough here with this proposal for an Action Framework JSR? On Sun, Apr 27, 2008 at 6:49 AM, Don Brown [EMAIL PROTECTED] wrote: Ok, I promised a more detailed proposal, so here it is: http://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi I converted Jeromy's goals into a more proper tech spec (with the pretty diagrams to follow...) I highly recommend those not familiar with OSGi to take a look at the references section, specifically the tutorials. OSGi brings some significant, game-changing elements to the table, so to fully understand the proposal and its possibilities, give them a look. I'll be updating the proposal to incorporate more feedback as I receive it. I'll be at JavaOne next week, so swing by the Atlassian booth and let's talk shop. Don On Sat, Apr 26, 2008 at 2:21 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Putting aside the technology for a moment: - ability to deploy new actions/replace actions and pages without a container restart: highly desirable - ability to deploy new/replace business-layer services without a container restart: highly desirable - ability to evolve Struts2 without fear of breaking an API; highly desirable If, through appropriate packaging, OSGi facilities those requirements that them I'm all for it. At this point I don't have a good appreciation of what *actually exists* in this area. I'd take care to ensure Struts2 continues to target entry-level containers though (ie. Tomcat rather than Glassfish). Don Brown wrote: As I learn more and more about OSGi, I wonder if it might be the solution to several big problems we seem to have at the moment: poor reloadability and the lack of a solid API. With OSGi, you can drop bundles in and out of the system at runtime, even running multiple versions of the same bundle side-by-side, but the feature I'm most interested in right now is how it would allow us to put in a proper API while maintaining full backwards-compatibility. Evolving a web framework is hard because apps tend to be written on a specific version, and to migrate them to new versions has two problems: development may not be continuously funded and the upgrade may require too many changes to the application. On the other hand, if you don't evolve your web framework, you quickly go out-of-date and lose interest from new developers. In our case, despite being a relatively new framework, we have legacy code around from 2004 that we can't just remove, yet we want to provide an attractive, modern, clean framework for new development. The specific issue it hand that I've been thinking about is how to get a proper API into Struts 2 yet keep backwards compatibility, and I think OSGi might provide a solution. What about this: 1. Struts 2 and its plugins remain the way they are now - 100% backwards-compatibility 2. An OSGi plugin provides the platform for the next generation of Struts 2 3. A new API bundle is created, implemented by the underlying Struts 2 framework 4. Old apps can continue to write and deploy code against Struts 2, yet new development can start to use the new API 5. Later, when we want to write API version 2, we create a new bundle that runs side-by-side the old bundle, both implemented by Struts 2 Basically, OSGi would allow us to write a clean layer on top of a framework, much like how Grails builds on Spring, but we get, as a side benefit, all the architectural advantages of OSGi for free. Furthermore, if we do it right, users don't have to know or care that OSGi is under the hood - all they know is they write a jar, drop it in a directory or upload it via a form and they just installed part of their application at runtime. Don - 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: missing DWRValidator in struts 2.1.1
The DWR class in question has been moved to the DWR Plugin. Drop that jar into your WEB-INF/lib to install. Don On Wed, Apr 30, 2008 at 10:40 PM, Pedro Herrera [EMAIL PROTECTED] wrote: I´m migrating a system created with struts 2.0.11 to struts 2.1.1. dwr.xml has configurated a DWRValidator like this : create creator=new javascript=validator /create When tomcat is started a warning is showed in console : [ERROR] 09:43:15,544 [org.directwebremoting.util.CommonsLoggingOutput : 75] : Creator: 'NewCreator[validator]' for validator.js is returning null for type queries. [ERROR] 09:43:15,559 [org.directwebremoting.util.CommonsLoggingOutput : 83] : Unexpected Error java.lang.SecurityException: No class by name: DWRValidator Thanks in advanced Herrera -- View this message in context: http://www.nabble.com/missing-DWRValidator-in-struts-2.1.1-tp16981509p16981509.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Struts 2.1.2 test build
The Struts 2.1.2 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/version-notes-212.html Distribution: * http://people.apache.org/builds/struts/2.1.2/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.1.2/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Release feedback
Ok, so this time, it took probably two hours to generate the release all told. The guide is now pretty accurate, but the steps themselves can take quite a while. This time, I copied my keys, m2 config, etc. over to a server in the US and ran the release from there, and boy, what a difference that made. If anyone else wants to get involved in releases, I'm hoping to get them out every few weeks or so, so feel free to jump in. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.1.2 test build
On Fri, May 2, 2008 at 3:12 PM, Don Brown [EMAIL PROTECTED] wrote: [ ] Leave at test build [ ] Alpha [X] Beta [ ] General Availability (GA) I don't think it is stable enough for a GA (and there are apparent licensing issues I guess), but I think it is good enough to be BETA and to get into our user's hands for more testing. Unless there are huge legal issues or show-stopping stability problems, we need to be getting these releases out to our community or we will never get a GA build. Remember, beta means it is feature complete but there are known issues, and I think that is what we have here. Don o Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.1.2 test build
What license issues do you see exactly? The RAT tool passed, which checks all the code for headers, and that is really what matters. If it is just some issues about licenses on test or example code, I don't see how that would provoke an alpha label. Don On Fri, May 2, 2008 at 5:17 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/5/2 Don Brown [EMAIL PROTECTED]: [X] Alpha (+0) I vote +0 to Alpha because, from the License point of view, there are minor problems, but I did not test the build as a software artifact. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.1.2 test build
Yep, and it won't. This is basically what the GA release will look like minus the bugs (hopefully). No more API changes. Don On Fri, May 2, 2008 at 5:27 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/5/2 Don Brown [EMAIL PROTECTED]: Remember, beta means it is feature complete but there are known issues, and I think that is what we have here. Well, not completely correct. Beta also means that the API won't change much, while Alpha means that the API can change a lot. Antonio - 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]
