Re: Wiki spaces
Not for nothing, but the docs between two minor versions creating confusion is usually a sign that we're overdue for a new GA release :) If 2.1 went GA, the problem should solve itself, since we could refer 2.0 folks to archival version of the site. We had the same problem in the 1.0/1.1 days. -Ted. On Sat, Sep 27, 2008 at 10:35 PM, Dave Newton [EMAIL PROTECTED] wrote: It might make sense to create one or two more wiki spaces for S2: one for S2.0, one for S2.1, and maybe one for things that are relevant to both. I don't know if the snippet plugin allows for pulling in from a specific version or if that's handled by the repository definition--either way, it's doable, even if it means tweaking the snippet plugin. Perhaps the current space could be copied into an S2.0 space? I'll volunteer to work on making the pages right, at least between S2.1/S2.0. IMO it causes too much confusion as it is now. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: If your evaluating new template engines, what about ZipScript
For me, it's the real world apps, *plus* the interest in porting GXP to other platforms, like C++, and Ruby. Personally, I'd like to add C# to that list. ASPX, like JSF, has its charms, but many .NET developers (including me) would like alternatives. I do find the zipscript YUI examples interesting, since we are also looking for an alternative approach to supporting Ajax with the Struts tags. -Ted. On Fri, Aug 1, 2008 at 1:30 AM, Al Sutton [EMAIL PROTECTED] wrote: Joe, My main reason for backing GXP is that it's been used in high volume real world apps by Google and so has been proven to scale. Does ZipScript have the same real world testing, and if so where is it used? Al. Joe Hudson wrote: Hello, With all the talk about GXP, I wanted to let you know about another template engine called ZipScript (zipscript.org). Ok, you're probably saying... another one??? but this has some distinct advantages and I would love for you to give it a try - I really think you'll be happy you did. 1) it can be used to create complex UI components 2) it has a powerful non XML-based syntax (which is helpful since the most common output is XML) 3) it can also be used to get more than just text from expressions (like booleans or objects) - great for having smarter config properties Here are some quick links: - homepage: http://zipscript.googlecode.com - Yahoo! UI macro examples: http://code.google.com/p/zipscript/wiki/YUIMacros - Language Syntax Examples http://code.google.com/p/zipscript/wiki/SyntaxExamples Thanks Joe Hudson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create multiple struts configuration file problem
The best place to post this message would be the Apache Struts user list.
* http://struts.apache.org/mail.html
* http://www.nabble.com/Struts---User-f206.html
HTH, Ted
http://husted.com/ted/blog/
On Wed, Jul 30, 2008 at 11:26 PM, angelwei [EMAIL PROTECTED] wrote:
Hai, can anybody help me to solve the problem javax.servlet.jsp.JspException:
Cannot retrieve mapping for action /pro.
if i replace the content in struts-config-product.xml to struts-config.xml.
it work. any idea???
web.xml
init-param
param-nameconfig/param-name
param-value/WEB-INF/struts-config.xml/param-value
/init-param
init-param
param-nameconfig/product/param-name
param-value/WEB-INF/product/struts-config-product.xml/param-value
/init-param
struts-config-product.xml (product folder)
?xml version=1.0 encoding=UTF-8?
!DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts
Configuration 1.1//EN
http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd;
struts-config
!-- Data Sources --
data-sources
/data-sources
!-- Form Beans --
form-beans
form-bean name=productForm type=app.ProductForm/
/form-beans
!-- Global Exceptions --
global-exceptions
/global-exceptions
!-- Global Forwards --
global-forwards
/global-forwards
!-- Action Mappings --
action-mappings
action path=/pro
type=app.ProductAction
name=productForm
scope=request
forward name=success path=/success.html/
/action
/action-mappings
/struts-config
ProductForm.java
package app;
import org.apache.struts.action.ActionForm;
public class ProductForm extends ActionForm{
private int id;
public int getId(){
return id;
}
public void setId(int id){
this.id=id;
}
}
ProductAction.java
package app;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
public class ProductAction extends Action{
public ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response){
ProductForm product=(ProductForm)form;
int iProduct=product.getId();
HttpSession session=request.getSession();
session.setAttribute(product,form);
return mapping.findForward(success);
}
}
thank you.
--
View this message in context:
http://www.nabble.com/Create-multiple-struts-configuration-file-problem-tp18747121p18747121.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]
Re: [s2] Google XML Pages (GXP) to replace Freemarker in tags?
Yes, for anyone unfamilar with how the Struts Tags are implemented,
the content of all three flavors of tags -- JSP, Velocity, and
Freemarker -- are, way down deep, generated from the same set of
templates. The content generated by the template is then wrapped as a
JSP tag, Velocity macro, or Freemarker tag. For example, here's the
gritty guts of our a tag:
a#rt/
#if parameters.id?if_exists !=
id=${parameters.id?html}#rt/
/#if
#if parameters.href?if_exists !=
href=${parameters.href}#rt/
/#if
#if parameters.tabindex?exists
tabindex=${parameters.tabindex?html}#rt/
/#if
#if parameters.cssClass?exists
class=${parameters.cssClass?html}#rt/
/#if
#if parameters.cssStyle?exists
style=${parameters.cssStyle?html}#rt/
/#if
#if parameters.title?exists
title=${parameters.title?html}#rt/
/#if
#include /${parameters.templateDir}/simple/scripting-events.ftl /
#include /${parameters.templateDir}/simple/common-attributes.ftl /
#include /${parameters.templateDir}/simple/dynamic-attributes.ftl /
*
http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/template/simple/a.ftl?revision=590812view=markup
Note that the block starts with a and ends with . Everything
else in the block generates dynamic content that might go between a
and .
The proposal would use GXP to generate the same content as we do here,
so we can wrap the output as a JSP, Velocity, or Freemarker tag.
HTH, Ted.
http://husted.com/ted/blog/
On Sat, Jul 26, 2008 at 3:39 PM, Dave Newton [EMAIL PROTECTED] wrote:
--- On Sat, 7/26/08, Piero Sartini [EMAIL PROTECTED] wrote:
Since there is no support for JSP tags in GXP, how could
the struts2 tags be accessed in such an result?
Er, I think the idea was to use GXP instead of FreeMarker for the S2 tags.
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Yes, I just want to get a handle on GXP first, to see if there's any synergy between the two proposals. (Trying to get the tests to run now.) On Sun, Jul 27, 2008 at 11:55 AM, Musachy Barroso [EMAIL PROTECTED] wrote: My hand are full for the next couple of weeks (releases at work), but I can jump in and help from time to time. Ted, do you want get started on them? I would suggest we setup a project in the sandbox. musachy On Thu, Jul 24, 2008 at 5:40 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Ted Husted wrote: I'd suggest that we put a replacement together before pulling the Dojo plugin out of the distribution (I can help). We could at least deprecate Dojo in the meantime. -T. I can help too but I'm moving house today so may be offline for a while (it takes weeks to get a new adsl2 connection in this country). I committed some minimal remote div, anchor, submit and tabbed panel tags to the yuiplugin a while ago. I'd rewrite all the javascript again to not mess with the namespace if I were using them but they may prompt some ideas. http://code.google.com/p/struts2yuiplugin/downloads/list - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Google XML Pages (GXP) to replace Freemarker in tags?
I like the idea. I wonder if GPX might also be a good way to phase in a new approach for Ajax-backed tags? -Ted. On Sat, Jul 26, 2008 at 1:02 AM, Don Brown [EMAIL PROTECTED] wrote: It is pretty well known that Google uses WebWork 2 and Struts 2 in many of its applications, but for the view layer, they use Google XML Pages (GXP) [1], which was just opened source yesterday or so. There is a lot to like in GXP like type safety, speed, correct HTML generation, automatic support for HTML and XHTML (one of our frequent tickets), automatic encoding of untrusted content, and even things like mulitiple language support. This might be a perfect replacement for Freemarker in our tags as the templates can be compiled, have better error reporting, don't introduce yet another expression language, and solve a number of our outstanding feature requests around tags. Thoughts? Don [1] http://code.google.com/p/gxp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dynamic
The best place to post this message would be the Apache Struts user list. * http://struts.apache.org/mail.html * http://www.nabble.com/Struts---User-f206.html HTH, Ted http://husted.com/ted/blog/ On Thu, Jul 24, 2008 at 2:13 AM, allwin [EMAIL PROTECTED] wrote: i wanted to created dynamic components like select in my jsp, is it possible to create using action class without using javascript -- View this message in context: http://www.nabble.com/dynamic-tp18625957p18625957.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] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
I'd suggest that we put a replacement together before pulling the Dojo plugin out of the distribution (I can help). We could at least deprecate Dojo in the meantime. -T. On Thu, Jul 24, 2008 at 3:44 PM, Musachy Barroso [EMAIL PROTECTED] wrote: So is the consensus so far that we should have a few, very simple tags, based on another framework, and take the dojo plugin out of struts? musachy On Thu, Jul 24, 2008 at 7:20 AM, Dave Newton [EMAIL PROTECTED] wrote: One solution would be to provide the backing components for simple use-cases (like sx:a... and sx:submit... at least) and an integration with a couple JavaScript libraries, hopefully making it obvious enough that people could then implement their own back-end. With simple components updating on backing library updates is easier, and (in theory) it makes it easier to understand how users can extend or create additional tags to suit their needs. So I vote +1 for removing the existing Dojo plugin (+0 for deprecating) and +1 for creating the simplistic components and example integrations. Dave --- On Tue, 7/22/08, Musachy Barroso [EMAIL PROTECTED] wrote: From: Musachy Barroso [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Deprecate or remove Dojo plugin To: Struts Developers List dev@struts.apache.org Date: Tuesday, July 22, 2008, 9:34 AM I think Dave also had a JQuery plugin somewhere, isn't that right? musachy On Tue, Jul 22, 2008 at 7:49 AM, alvins [EMAIL PROTECTED] wrote: +1 to remove. Valid points raised by all. I personally use JQuery in my daily life and have written my own tags to do these functions. I did previously look at the effort required to update the current tags to the latest dojo but it would be very time consuming and far easier to start from scratch. I think a large problem with the current dojo tags are that it is very complicated to do simple things (dojo itself is complicated relatively). With JQuery it is quite easy to do most of the things mentioned so am not sure on the benefits of tags. That said - if you made the tags powerful enough - they can be quite useful in a large number of cases - however the flipside is as you add functionality, maintainability becomes an issue. btw. If anybody is interested in some JQuery tags I could start a plugin..? -- View this message in context: http://www.nabble.com/-PROPOSAL--Deprecate-or-remove-Dojo-plugin-tp18573704p18587222.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] -- Hey you! Would you help me to carry the stone? Pink Floyd - 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] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
Dojo seems to get the most lip service, but I've seen persistence reports that YUI has broader acceptance. -Ted. On Tue, Jul 22, 2008 at 4:48 PM, Dave Newton [EMAIL PROTECTED] wrote: --- On Tue, 7/22/08, Paul Benedict [EMAIL PROTECTED] wrote: Isn't Dojo the defacto ajax standard on the web? In terms of deployments I'd put money on Prototype and/or jQuery. Not that it's a large sample size, but I don't know *anybody* using Dojo outside of S2. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
+1 for Musachy's suggestion, and I'm also at a point where I could help with the implementation. As to Ajax-enabling some of the tags, there are several tag-based Ajax libraries out there that we could look at embedding or emulating. In this case, we wouldn't be adopting a general-purpose Ajax library, but special-purpose scripts designed to be used with tags. * Ajax Tags - http://ajaxtags.sourceforge.net * Prize Tags - http://jenkov.com/prizetags/index.html * JSON-taglib - http://json-taglib.sourceforge.net/ * AjaxParts Taglib - http://javawebparts.sourceforge.net/ Has anyone had good or bad experiences with tag-based libraries like these? -Ted. On Mon, Jul 21, 2008 at 11:33 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I am not sure about that approach. On one hand it is very strutsish, in that is supports many ways of doing the same thing, and provides ways to extend what is provided, on the other hand, I think we should learn from other frameworks and just don't give users that many options, for they can be confusing, and frustrating when there is not enough documentation. Looking at ajax, and the ajax tags I think we have 2 kind of users: the power users, they won't use the ajax tag at all, unless they are doing something extremely simple. the beginners: they will use the ajax tags out of the box. When the beginners need to do something that is not provided by the tags out of the box, they start hacking away, and end up dumping the tags. So our target is the beginners, and they don't want customization, they just want to drop a few tags on their jsps and get it working. Based on that, I think we should either: don't provide any ajax tags at all, or just provide a very limited set of tags (like what Jeromy listed) with very little functionality to cover simple use cases, and use a reliable and simple framework for the implementation. Disregarding what path we take, I think it is fairly obvious that the Dojo plugin will end up unmaintained, that's why we should users know that we do not plan on upgrading from 0.4.3. musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Deprecate or remove Dojo plugin
On Tue, Jul 22, 2008 at 8:19 PM, Dave Newton [EMAIL PROTECTED] wrote: --- On Tue, 7/22/08, Bob Tiernay [EMAIL PROTECTED] wrote: I really don't see why even a taglib is even on the table. I think the issue was a let's make some of this cool stuff really easy for the people that don't know JavaScript. True. There are a lot of applications that don't need or want a full client-side front-end. For a lot of folks, full-page refresh is just fine most of the time, but there is still a key place or three where sprinkling in a little Ajax magic can make a big difference, without making any sweeping UI changes. We don't need to hookup an entire general -purpose Ajax framework for that. We just need to go in with a scalpel and add some simple Ajax scripts where they will do the most good. Of course, if an application has already elected to use a full clientde front-end, anything we do with the tags would be irrelevant. -Ted. To steal the phrase: now you have two problems. I'm not sure it's worth keeping the Dojo tags as part of S2, particularly since client-side stuff varies so wildly across companies (even *within* companies), developers, projects, etc. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity-check regarding ModelDrivenInterceptor vs. stack order
+1
As mentioned, to refresh the model, we remove the existing model and
push the latest version. For a refresh operation, we might expect
the new instance to replace the old instance in the same stack
position.
In RefreshModelBeforeResult, we already have a reference to the old
model (Item). Could we just replace one object with another?
for (Object item : root) {
if (item == newModel) {
needsRefresh = false;
}
+ else {
+ item = newModel
+ }
*
http://svn.opensymphony.com/fisheye/browse/~raw,r=1833/xwork/trunk/src/java/com/opensymphony/xwork2/interceptor/ModelDrivenInterceptor.java
Or would there be side-effects?
HTH, Ted.
On Wed, Jul 16, 2008 at 7:22 PM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Dave Newton wrote:
It appears as though ModelDrivenInterceptor could change the stack order
when a refresh is necessary; the old model is removed from wherever it was
in the stack and the new model is simply pushed.
Is it possible to make it do a replace within the stack?
If not, rather than document it, I'd prefer that it throws an exception
(stack order changed exception/model not at top of stack exception/something
like that exception), so the developer's attention is drawn to it. These
kinds of things cause apparently intermittent difficult to isolate
problems.
The i18n tag had a similar issue when its closing tag liberally popped
anything off the top of the stack (now throws)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
HTH, Ted
http://husted.com/ted/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature sponsorship proposal
Apache just plain wouldn't exist without corporate support. And a lot of corporations wouldn't exist without our software to run their business :) -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature sponsorship proposal
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]
Re: Feature sponsorship proposal
On Mon, Apr 7, 2008 at 11:02 PM, Don Brown [EMAIL PROTECTED] wrote: 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. Following up on what James said, I think this much would be OK so long as Wendy had filed a ICLA (or a CCLA, if the work was done on company time). We already try to do that in the commit logs, and, for more substantial contributions, the release notes would be an extension of that practice. (The original Apache HTTPD voting rules even gave contributors (or authors) a binding vote over something like this!) 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. And, of course, if Wendy continued to make welcome contributions to the project, we should consider her for committership, the BigCo paycheck notwithstanding. And, if she changes jobs, then she's still a committer. BigCo is transparent to us. We don't want their money, we want Wendy's brain. As for BigCo's motivation, it should be the same as anyone else's motivation. If BigCo is using our software, then BigCo should want the software to be the best that it can be. And it should want that regardless of attribution. If BigCo is using our software, then it should not be difficult for BigCo to calculate a positive ROI without a marketing element. Working with an open source project can eliminate or mitigate a good portion of the cost of developing equivalent software independently. To me, the most valuable part of this proposal is not only the list, but the specification. Where we really, really suck is planning features without actually coding them first :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Thanks, Don.
BTW, getting setup for digital signing is harder than it sounds. Every
committer should consider generating a signature and putting it on
file with the foundation. Signing isn't hard, but it can be a
stumblingblock when it comes to posting a release.
*
http://struts.apache.org/2.0.11.1/docs/creating-and-signing-a-distribution.html#CreatingandSigningaDistribution-Onetime
Since ASF distributions are sometimes passed around, it's important
that we sign them, so if a strange problem is reported with a
distribution, we confirm whether it's one of ours, or a forgery.
-Ted.
On Sun, Apr 6, 2008 at 8:28 AM, 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
Re: 2.1 build
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 On Fri, Mar 28, 2008 at 6:38 AM, Ted Husted [EMAIL PROTECTED] wrote: Is there much to do beside tag it, build it, and sign it? I could help with that much, so long as other people are testing it. -Ted. On Fri, Mar 28, 2008 at 5:35 AM, Pedro Herrera [EMAIL PROTECTED] wrote: good question . . . Musachy Barroso wrote: Hi all, Any news on the 2.1 build? Is anyone looking into it? regards musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - 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] -- 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] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
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 On Fri, Mar 28, 2008 at 6:38 AM, Ted Husted [EMAIL PROTECTED] wrote: Is there much to do beside tag it, build it, and sign it? I could help with that much, so long as other people are testing it. -Ted. On Fri, Mar 28, 2008 at 5:35 AM, Pedro Herrera [EMAIL PROTECTED] wrote: good question . . . Musachy Barroso wrote: Hi all, Any news on the 2.1 build? Is anyone looking into it? regards musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - 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] -- 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] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Is there much to do beside tag it, build it, and sign it? I could help with that much, so long as other people are testing it. -Ted. On Fri, Mar 28, 2008 at 5:35 AM, Pedro Herrera [EMAIL PROTECTED] wrote: good question . . . Musachy Barroso wrote: Hi all, Any news on the 2.1 build? Is anyone looking into it? regards musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weekly, daily, hourly?! FAQ/README on Struts User?
If it's just finding the docs, perhaps the home page needs to provide a more obvious switchboard to the site. There are now three main areas, Struts 1, Struts 2, and the Struts Project (shared pages). Maybe the same type of big-ass buttons we have on the the Struts 2 page. Perhaps we should also add some Read the Manual links to the top of the Mailing List page. * http://struts.apache.org/mail.html On the top page, the first support link is User Mailing List, and so maybe newbies aren't digging deeper first. HTH, Ted. On Mon, Mar 10, 2008 at 11:57 AM, Dave Newton [EMAIL PROTECTED] wrote: I've brought this up a few times in the past, but I think I'm going to take action on it now. I'd like to have a weekly (or daily) posting on struts-user regarding the usual suspects, how to ask questions, some useful links, maybe some sort of tip of the week or whatever, and all that. Mostly I'm trying to mitigate the amount of teeth-pulling necessary to get questions asked in a way they can actually be answered because it's driving me insane. If anybody has any objections, let me know. Otherwise I'll start a wiki page (I guess on the public wiki? Or is there a way to mark a page to not be exported into the docs?) and if anybody has any suggestions they can put them there and I'll try to get something reasonable within a few days. I'm just tired of a dozen-post questions that should have been one or two, and it might just be handy to have some of the doc links hammered in to people. Like nails. I'm also planning to either expand the FAQ section and/or move some of the information there into the mainline docs and/or link from the mainline docs into the FAQ and include information gleaned from the mailing list, so if anyone has any ideas on how they'd like that organized chime in. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Struts 2 sources not in maven repo
Forwarded with permission. -- Forwarded message -- From: Carlos Sanchez [EMAIL PROTECTED] Date: Mon, Feb 11, 2008 at 7:30 PM Subject: Re: Struts 2 sources not in maven repo To: Wendy Smoak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] copying Ted as he was the one making the releases And BTW in struts2-parent you dont need organization and license , they are inherited from the apache parent pom http://repo1.maven.org/maven2/org/apache/struts/struts2-parent/2.0.11/struts2-parent-2.0.11.pom On Feb 11, 2008 4:13 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: Sources are not in http://repo1.maven.org/maven2/org/apache/struts/struts2-core/2.0.11/ or any other version or subproject. Can you ping somebody to see if this can be fixed for latest or new releases? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.12 version tag removed in Jira - by intention?
On Feb 12, 2008 1:34 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: Anyway, it's nice to hear that there is *finally* a paid Struts developer (TED where are you???) :-) Sadly, my new project is not Struts related. :( I do expect to be heads-down for the first half of this year, but I'll try to stay in touch. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.12 version tag removed in Jira - by intention?
On Feb 12, 2008 1:34 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: Sorry, I did not mean this. I meant that customer (or better, users) may ask for features/bug fixing, but it will be fixed only if there is a developer willing to do the work. Another way of looking at it is that *WE* are the customer. An Apache project builds the product that we ourselves *want* to use (and then we actually use it). Other people who use Apache projects are not the customer, but prospective customers, who might someday want to contribute back to the project (by helping out on the mailing list and issue tracker, suggesting patches, testing builds, and so forth). People who use our products for years and years, but never contribute back, are simply freeloaders. (God bless them every one!) Since it's an all-volunteer effort, talking about doing something that someone else might like us to do (a prospective contributor or freeloader), tends not to work in the long term, since there is no incentive to actually do the work -- unless the feature also helps us in our own work. It's easy to talk about such things, it's harder to find the volunteer hours to actually do them. :) A key problem with continuing to patch a branch is just that it's more work, and we have very few people who are ready, willing, and able to do any of the patch work right now. If someone has an itch to release 2.0.12, and wants to backport some of the patches, then great, have at it. But, please, only if you fully intend to follow through and create a new 2.0.12 build for the rest of us to test. We have a large backlog of patches. Insisting that everyone apply and test all of these patches against the branch, and making sure it builds (Is Bamboo building the branch?), is twice as much work. Right now we can even get anyone to do 1x the work!. AFAIK, if a security issue came up with 2.0.11, we could make a surgical fix and release that as 2.0.12. It's as GA now as it was when released it. But, if we start applying miscellaneous patches, then 2.0.12 would not be GA ready anymore, and if we had to do an immediate, surgical release, we'd have to roll a 2.0.11.1 instead. HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: First commit is a FAILURE!
Bamboo is also know to generate false negatives. If it passed locally under J5, try making an innocuous commit so it builds again. I don't remember discussed using J6 code for tests or otherwise, and so if we have a J6 issue, we should address that directly. HTH, Ted. On Feb 9, 2008 5:17 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: I tried to commit a fix for WW-2477, which would be my first. I didn't realize that Bamboo is running/building with java 6. Shortly after committing, the Bamboo builds failed on the unit test I committed with the fix. I apologize for that :( I went ahead and deleted the test (the actual fixes were trivial). I have to go out to eat, but when I get back, I'll re-write the test using java 6 and commit. I attached the patch that I attempted to commit to the JIRA (in case anyone wants to take a look and help me guess why it works in 1.5 but fails when run in 6.0). Again sorry! -Wes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse Europa and Tomacat 6
General questions about using Eclipse should be posted to the appropriate Eclipse newsgroup. * http://www.eclipse.org/newsgroups/index.php A number of Struts folk do use Eclipse, so you might also get an answer by posting to the Struts user list. * http://www.nabble.com/Struts---User-f206.html But, the Struts developers list is not the appropriate forum for this question. HTH, Ted http://husted.com/ted/blog/ On Feb 4, 2008 9:31 PM, jorgem [EMAIL PROTECTED] wrote: I'm relatively new to Struts. Was using Tomcat 5.5 and Eclipse 3.1 and used to deploy my projects manually, Moving from my project folder: web-inf folder, images folder and my .jsp scripts into the Tomcat wepapps folder. Now, I'm using Eclipse Europa with Tomacat 6.0 I have my projects in the Eclipse Workspace and the deployment is different. You have to right click on the server and click on publish After doing that, nothing happens and I don't know if Eclipse is supposed to create a folder in the Tomcat/webapps folder for my project or I have to do it myself. Does Tomcat take my classes, image etc from the workspace or it takes those from the Tomcat/wepapps folder? the error I'm getting is no class found for the StartupManager (I alreday checked the web.xml and is OK) Thank you -- View this message in context: http://www.nabble.com/Eclipse-Europa-and-Tomacat-6-tp15282336p15282336.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]
[ANN] New Struts Committer - Wes Wannemacher
Please join us in welcoming Wes Wannemacher as a new Struts committer. Wes has been posting to the user list and to dev@ since September 2007, and, to date, he has reported a dozen JIRA issues, often with patches. Wes has also been helping with the documentation. Welcome, wesw ... now you tweak your own POMs! PMC vote: 6 +1s -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] New Struts Committer - Jeromy Evans
Please join us in welcoming Jeromy Evans as a new Struts committer. Jeromy has been posting to the user list since May 2007, and to dev@ since July 2007, and has submitted two issues to JIRA, both with patches. Welcome, jeromy@ ... WW-2398 is all yours now! PMC vote: 5 +1s -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.1 Release Planning
I'm starting a new project on Thursday that will be consuming all my bandwidth for a few months, and I won't be able to help plan or create the Struts 2.1.1 release. I should still be able to help test a new distribution and assign a quality grade. I'll be monitoring the lists, so if there are any questions regarding the release process, just post them, and I'll do my best to respond here. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Examples and summaries in wiki via snippet plugin
+1 My suggestion would be to retain technically complete but minimalistic Javadocs, and link from the Javadoc to the wikidoc (and also link from the wikidoc to the Javadoc). The underlying goal is to single-source the documentation, and avoid cutting-and-pasting between assets. One way to single-source is to use something like a snippet macro, but I think bi-directional linking can work as well. -Ted. On Jan 30, 2008 3:12 AM, Philip Luppens [EMAIL PROTECTED] wrote: Hi all, I agree the snippet macro is quite useful to keep for example attributes for tags in sync with the documentation in the wiki. However, using that same technique to include a summary and/or examples seems to be less fitting. It's often hard to write good and well formatted samples in the javadoc code for display in the wiki (esp. if you're dealing with XML tags and comments). So, my question is: wouldn't it be better to keep the summary and examples out of the javadocs and just put them in the wiki directly ? I often find myself browsing the wiki to resolve some comments about code samples having typoes(sp?) or display problems, and because I don't have regular access to the struts svn because of my work, I cannot make some quick adjustments (and neither can non-committers). Creating (good-looking, well documented) examples is a lot easier in confluence than it is in javadoc. (Note: I am quite aware that we can simply throw out the snippet macro line in a page and add the new example directly - I was simply wondering if we shouldn't prefer it that way instead and move away from the examples-in-javadoc) Apologies if this has already been brought up before, my 2 cents, comments welcome as always. Phil -- Software Architect - Hydrodesk Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2.1] Moving testing classes from core to a new module
On Jan 26, 2008 5:29 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: The problem is that, when we package everything in binary form, we ship 3rd party packages together with Struts 2. We should *at least* add a line in the NOTICE.txt file, and when the package is not licensed under the ASL, the license of the package itself. ... which, in all cases where we package a third-party binary, would be a license compatible with the ASF Third-Party Licensing Policy :) * http://people.apache.org/~cliffs/3party.html HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki docs suggestion
It's a working guideline, not gospel. If the toc stuff implies we
should use h1, then let's start using h1.
On Jan 25, 2008 8:49 PM, Dave Newton [EMAIL PROTECTED] wrote:
Hmm, that says not to use the h1 heading, so never mind. I'll look at
either {toc-zone} or some of the reporting stuff to see if I can be appeased.
Thanks,
Dave
--- Ted Husted [EMAIL PROTECTED] wrote:
We might also want to keep the Style Guide and Colophon updated with
any changes or new approaches.
* http://struts.apache.org/2.x/docs/documentation-style-guide.html
HTH, Ted.
On Jan 25, 2008 1:45 PM, Dave Newton [EMAIL PROTECTED] wrote:
Howdy,
I'd like to suggest that we make sure to use the right heading levels
(h1,
h2, ...) on the documentation wiki pages so that we can better use
Confluence's {toc} macro. This should help make doc navigation a bit
easier
and allow jumping to target sections a bit easier.
Relatively minor, but I know I've been frustrated about having to scroll
over
some of the longer pages (some of which should probably even be broken up
a
bit further).
If I'm off my rocker (about this, anyway :p let me know otherwise I'll
probably add TOCs to some of the longer pages as I'm going through stuff
over
the next couple of weeks.
Thanks,
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki docs suggestion
We might also want to keep the Style Guide and Colophon updated with
any changes or new approaches.
* http://struts.apache.org/2.x/docs/documentation-style-guide.html
HTH, Ted.
On Jan 25, 2008 1:45 PM, Dave Newton [EMAIL PROTECTED] wrote:
Howdy,
I'd like to suggest that we make sure to use the right heading levels (h1,
h2, ...) on the documentation wiki pages so that we can better use
Confluence's {toc} macro. This should help make doc navigation a bit easier
and allow jumping to target sections a bit easier.
Relatively minor, but I know I've been frustrated about having to scroll over
some of the longer pages (some of which should probably even be broken up a
bit further).
If I'm off my rocker (about this, anyway :p let me know otherwise I'll
probably add TOCs to some of the longer pages as I'm going through stuff over
the next couple of weeks.
Thanks,
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2.1] Moving testing classes from core to a new module
It sounds reasonable to me, so long as we are talking about /s/shale-test/struts-test :) On Jan 25, 2008 2:15 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: Hi friends, during my license-problem-busting I noticed that in struts-core there are some classes using TestNG and JUnit, therefore these dependencies must be at compile-scope. So my question is: isn't it better to move these classes to a new module, like shale-test. to help other people testing? This way we can remove not-runtime classes out of the core. Thoughts? Ciao Antonio - 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
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]
Re: Struts 2.1.1 Release Planning
Thanks, Wes! On Jan 17, 2008 3:42 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: Okay, I did a run-through of the showcase app and filed a few JIRAs. Most seem fairly minor and hopefully easy to fix. Here is the list - WW-2442 WW-2441 WW-2440 WW-2439 WW-2438 Thanks! -Wes On Thu, 2008-01-17 at 07:06 -0500, Ted Husted wrote: So, at this moment in time, we are down to 49 open fixes, from an average of 50+ last quarter, even with people kindly filing new tickets :) S2 is building and all the unit tests are passing, but it's probably time for a comprehensive test drive of the example applications, so see if we've broken any edge cases yet. I'll try to work that in tomorrow night, unless someone else is up for the task. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with select multiple
The best place to post this message would be the Struts User list,
where there are more people who can help you.
* http://struts.apache.org/mail.html
-Ted.
On Jan 18, 2008 7:01 AM, jabelsc [EMAIL PROTECTED] wrote:
Hello everybody!
I'm using Struts2 2.0.11 and I'm having a problem with the select multiple
tag. This is the code I use:
s:select list=eligibleUsers listKey=appuserId
listValue=name name=client.availableSalesmen
value=%{client.availableSalesmen.{name}} multiple=true size=10/
eligibleUsers and client.availableSalesmen are ArrayList of objects Users,
which I have defined in the correpsonding conversion file of the action. I
also populate these arrays, but when I send data (watching the netbeans
debugger) I can see that the selected values mapped to the variable
client.availableSalesmen are passed to the action as a array of strings
instead as an array of the class User objects. So I cannot handle it right
in the action.
Any clue would be highly appreciated. I'm desperate.
Thanks a lot!
Abel S.
--
View this message in context:
http://www.nabble.com/Problem-with-select-multiple-tp14948204p14948204.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]
--
HTH, Ted
* http://www.StrutsMentor.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Coverity Scan
There's a company that's been scanning open source project codebases for static flaws. In November 2007, they announced that Java projects are being added. * http://www.coverity.com/html/press_story51_11_20_07.html There's been the odd email about using these projects foundation-wide, possibly by running them locally. But, the core service descibed by this press release seems to be external. I couldn't find a list of Java projects on the website. The next step seems to be to send an email to [EMAIL PROTECTED]. If we are not already on the list, my question is whether we would like to opt-in now or not? My thought is that we might want to be proactive. In the alternative, we are like to find one day that Coverity has started to scan us unilaterally, and then be surprised by a lot of new fixes to make. Since Struts is an approved framework for several government agencies (DoD, VA, and so forth), I would think that we would be on the short list anyway. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.1 Release Planning
So, at this moment in time, we are down to 49 open fixes, from an average of 50+ last quarter, even with people kindly filing new tickets :) S2 is building and all the unit tests are passing, but it's probably time for a comprehensive test drive of the example applications, so see if we've broken any edge cases yet. I'll try to work that in tomorrow night, unless someone else is up for the task. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Assembly build (was svn commit: r604801 )
On Dec 17, 2007 5:22 AM, Don Brown [EMAIL PROTECTED] wrote: 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). We couldn't even if we wanted to, since some of our plugins require JARs under an incompatible license. One thing we should work toward is a separate -plugins distribution. The -lib distribution should only contain the requisite dependencies (FreeMarker, OGNL, XWork, Struts2-Core, and Struts2-CodeBehind), and all the (other) plugins should be in a separate distribution. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox
On Jan 16, 2008 5:25 AM, 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? AFAIK the sandbox is made for playing :-) Seriously, I think that you can safely put your code in the sandbox, because it's not included when building Struts 1 nor 2. For example, Tiles 2 has been a lot of time in the sandbox, since it was an (almost) complete rewrite of Tiles. I don't know if it needs a vote, though. No vote is needed. It's our expression of a committer's Right to Revolution as described in the ASF Rules for Revolutionaries http://incubator.apache.org/learn/rules-for-revolutionaries.html. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OSS Bamboo] Struts 2 SVN - Main Build (Java 6) build 314 has FAILED (0 tests failed). Change made by Nils-Helge Garli Hegvik
For whatever reason, I can succesfully buid the head ocally. I'll apply some patches elsewhere in the codebase to my working copy, but hold off on any commit until Bamboo is a happy camper. On Jan 16, 2008 5:20 AM, Atlassian Open Source Bamboo Integration Server [EMAIL PROTECTED] wrote: The project Struts 2 SVN - Main Build (Java 6) has the following 1 change by 1 author: *Nils-Helge Garli Hegvik* made the following changes at Comment: WW-1859 The namespace computation does not seem to have any meaning, so removing it completely. /struts/struts2/trunk/plugins/portlet/src/main/java/org/apache/struts2/components/PortletUrlRenderer.java (612406) --- No failed tests found, a possible compilation error. Click http://opensource.bamboo.atlassian.com/browse/STRUTS-MAINJ6-314 to find out more. Thanks, Bamboo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OSS Bamboo] Struts 2 SVN - Main Build (Java 6) build 314 has FAILED (0 tests failed). Change made by Nils-Helge Garli Hegvik
On Jan 16, 2008 9:38 AM, Ted Husted [EMAIL PROTECTED] wrote: For whatever reason, I can succesfully buid the head ocally. This wasn't some kind of a joke. I was typing with one hand unsuccessfully while eating an apple. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OSS Bamboo] Struts 2 SVN - Main Build (Java 6) build 314 has FAILED (0 tests failed). Change made by Nils-Helge Garli Hegvik
Dunno. It builds for me. I have some POM changes to commit. I'll go ahead and commit those, so that we can see what happens. On Jan 16, 2008 10:07 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: I'm not sure what caused the error. The commit shouldn't have caused any problems. Is it Bamboo hiccups? Nils-H On Jan 16, 2008 3:39 PM, Ted Husted [EMAIL PROTECTED] wrote: On Jan 16, 2008 9:38 AM, Ted Husted [EMAIL PROTECTED] wrote: For whatever reason, I can succesfully buid the head ocally. This wasn't some kind of a joke. I was typing with one hand unsuccessfully while eating an apple. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 16, 2008 12:23 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: That's a fair question, but I have an answer for it. Put simply, I feel that anyone officially made a member of a project team has accepted a greater level of responsibility than someone in the larger user community. A careful reading of How it Works implies that the Apache Way is designed so that individual committers do not have to accept a greater level of responsibility. The notion is that we can invite enough committers to the table that there will always be other volunteers available. @Struts, we seem to have trouble keeping enough active committers in play to make up for the committers who are heads-down on our day jobs. We also have trouble electing grassroot contributors who are not star coders. The trouble with electing only star coders is that people tend to focus on their own contributions, rather than applying patches submitted by others. I can testify that some of the very best features in Struts 1 were contributions made by people who where not committers. As PMC member, I would really like to know who intends to be available to support a release, or at least who expects to be heads-down for awhile. It's not uncommon for a release to pass with a minimum number of binding votes. If some of the voters are about to go heads-down on another project for six months, I'd like to know that before casting my own GA vote. As a group, we really suck at letting each other know that we won't be around for a while. On Jan 16, 2008 1:45 AM, Al Sutton [EMAIL PROTECTED] wrote: We could always switch to holding off releases until we have 0 bugs of major and above level :) (if we did that then we should do the M$ thing and switch the default JIRA level to be the lowest possible and let the user upgrade it rather than everything going in as Major by default). In practice, we do. There have been many times we counted down to rolling a build based on how many outstanding issues we had left. To an extent, that's what's happening with Struts 2.1.1. When we get to zero patches, I would be happy to roll another build. (Though, if another committer got antzy, someone else could post another release plan and roll one sooner.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 16, 2008 10:47 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: (1) If as you say Niall votes are votes, then that SHOULD mean that non-binding voters can veto a release, but the bylaws say differently: 3 binding +1 votes and no binding vetos is the benchmark to whether a action passes or not. It doesn't say 3 +1 votes from anyone, nor does it say no vetos from anyone, it specifically spells out binding votes. Non-binding votes are not officially considered in other words. Nobody can veto a release. It's a majority vote action not a consensus vote action. A release quality vote would only fail if there is not a quorum of three +1 binding votes, or if there are more binding -1s than binding +1s. We don't count non-binding votes, but most of us would take them into consideration. If I'm on the fence, and a number of contributors cast +1 non-binding votes, then I'm more likely to cast my binding vote for GA. The inverse is also true. We publish the project guidelines (or by laws) to cover the common cases, so that we don't have to have these types of discussions every time we create a release. We're not trying to be legalistic, we're just trying to get the work done. Since everyone here is a volunteer, there's no way to enforce an obligation, and the ASF guidelines remind us of this. A vote is an opinion, not a commitment. The key thing to me is what are the expectations of the commiters when we vote +1 on a GA release. Right now, the general feeling is that a +1 GA vote doesn't indicate that the committer will have the bandwidth available to support the release. Meaning, if I want to ask about that, we need to ask in a different context. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OSS Bamboo] Struts 2 SVN - Main Build (Java 6) build 314 has FAILED (0 tests failed). Change made by Nils-Helge Garli Hegvik
It's passing now, so I guess it was just a hiccup. On Jan 16, 2008 10:16 AM, Ted Husted [EMAIL PROTECTED] wrote: Dunno. It builds for me. I have some POM changes to commit. I'll go ahead and commit those, so that we can see what happens. On Jan 16, 2008 10:07 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: I'm not sure what caused the error. The commit shouldn't have caused any problems. Is it Bamboo hiccups? Nils-H On Jan 16, 2008 3:39 PM, Ted Husted [EMAIL PROTECTED] wrote: On Jan 16, 2008 9:38 AM, Ted Husted [EMAIL PROTECTED] wrote: For whatever reason, I can succesfully buid the head ocally. This wasn't some kind of a joke. I was typing with one hand unsuccessfully while eating an apple. :) -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 16, 2008 11:42 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: That may be so in practice Ted, but the bylaws say differently: An action requiring consensus approval must receive at least 3 binding +1 votes and no binding vetos. A release is not an action that requires consensus approval. It's a majority action. Look farther down under Release Plan and Release Grade. And I think that's a perfectly reasonable way to approach it, but that's not what the bylaws says, nor is it what Nial and Nathan say is in their books (I'm not picking on you two by the way, but I don't think you're the only ones that feel that way, hence it's likely a reflection on a larger group feeling). Well, first, AFAIK, it's never actually happened. But, if we did have a flurry of earnest -1s from regular contributors, I'd probably change my own vote, and I expect most other PMC members would do the same. And that too is reasonable, except that now you've got Martin seemingly disagreeing with you (how this all started as I recall) and both Niall and Nathan apparently with understanding that don't seem to jive with the bylaws, hence it seems obvious to me that something needs to be done, and the easiest answer is probably to rewrite the bylaws to match the consensus view, whatever that turns out to be. Which is why we've been having these discussions, to clarify our expections. Martin, Niall, Nathan, and I don't chat out-of-band. Everything we've had to say to each other, we've said here. Since everyone here is a volunteer, there's no way to enforce an obligation, and the ASF guidelines remind us of this. A vote is an opinion, not a commitment. Didn't you effectively say the opposite just yesterday? : I asked about a voter's implied intention to make a good-faith effort, which is effectively an opinion. Maybe it's a semantic thing, but if a +1 vote means ...he or she intends to help support the release, isn't that an obligation? Or is obligation simply the wrong term? Perhaps willingness, as I suggested yesterday? In the case of a release vote, it occurs to me that the obligation in question is reviewing the release and forming an opinion as to whether it meets our standards our correctness. Where our is the expectations of the ASF as well as the expectations of the Apache Struts Group. The meaning then becomes that we are not simply tossing out an armchair opinion, but we are stating an informed opinion based on direct experience. My recollection is that we inherited the act of voting language form a Jakarta document, which was in turn based on an ancient Apache HTTPD document. The key point now is that our page doesn't jive word-for-word with the ASF guidelines. (Though, I would contend that the spirit remains the same.) * http://apache.org/foundation/voting.html Now that the ASF guidelines includes an implications section (it didn't always), my suggestion would be that we strike that language from our own. We can probably simplify or eliminate other sections as well, by incorporating the latest ASF pages by reference. As for our intentions as to support, the general opinion seems to be that support is a separate topic from release grade. We're saying the same thing here. I personally feel that a +1 *should* imply something, but if everyone disagrees with me, that's fine, but it seems obvious there isn't consensus on that right now, and the bylaws say something that not everyone else seems to be saying in any case, so what's the final arbiter of which way is accurate? The bylaws should spell it all out clearly and unambiguously, regardless of what it is that they actually spell out, just to avoid such situations. I understand the bylaws aren't meant to be legalize, but I believe I've pointed out some contradictions and interpretations that should be dealt with so there's never any debate over what a vote does or does not mean, what obligations someone does or does not have. I don't so much care what the answers actually are, only that they are clear and unassailable, and I'd expect everyone would want that level of clarity from any project they're involve din. Since the project is a living working group, and not a political body, some ambiguity seems fine, even necessary. Within the ASF boundaries, each set of committers should be able to able to put their own spin on things, so that the project works for us, not the other way around. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
On Jan 16, 2008 12:19 AM, Martin Cooper [EMAIL PROTECTED] wrote: So why not start a thread about who's planning / intending / feeling [morally] obligated / promising to support the product and help apply patches, and get an answer to you real question? * http://www.nabble.com/-S2--Patch-a-Day-Challenge-to13475978.html#a13475978 * http://www.nabble.com/-S2--Developers-please-apply-patches-%28WAS%3A-Re%3A--VOTE--Should-voting-%2B1-on-a-release-imply-that-the-vote-intends-to-help-support-the-release-%29-to14836932.html The replies to these threads was loud and clear: the sound of crickets chirping. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 16, 2008 4:42 PM, Frank W. Zammetti [EMAIL PROTECTED] wrote: What I don't understand is why there's any hesitation to get the bylaws inline with reality, There's no hesitation. Before acting, some of us just like to give others a chance to express their own opinions. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 16, 2008 2:14 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: Sorry for being rude. No offense taken. Like all ASF projects, Apache Struts is modeled after the original Apache HTTPD Group. In this sense, it is like a group in an operating system. Everyone in the group has the same privileges (or karma) and, we can do all the same things, interchangeably. The Apache HTTPD Group came about because the NCSA web server was not being maintained. People needed a scalable and secure web server to use at work, but no one at NCSA was available to apply the needed patches. Much of the Apache Way is designed to keep individuals from becoming bottlenecks, and to keep companies from controlling the future of a product. Most people become involved in ASF projects because we use the product at work, and it is in our professional best interest that the product be the best that it can be. A key idea is that an ASF development group is relatively large, so that if two or three or four of us are busy, there are other volunteers who can pick up the slack. Unfortunately, in the case of Struts, we have so few active committers, that if a couple of us become busy, progress grinds to a halt. It's OK to busy. It's good to be busy. But, when we become too busy to do the work, we should at least try to nominate other volunteers who may be eager to do the work we cannot do. Spread the joy; share the wealth. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
On Jan 15, 2008 4:04 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: We are not obliged to work on Struts, we can go away at any time, and we have not deadlines. So, the *forced obligation* of support seems like a nonsense to me. Please note that the original post cites the top-level ASF documentation which suggests: The tacit implications of voting should be spelt out in the community's guidelines. However, in no case may someone's vote be considered invalid if the implied commitment doesn't appear to be met;a vote is a formal expression of opinion, not of commitment. Put another way: is a binding GA vote also asking, In your opinion, will you be able to support the release? I suppose one solution would be add that second proposition to the quality votes, just so we could also have a poll of people who intend to do the work. Here's the underlying problem: We have over fifty outstanding patches. We have had over fifty outstanding patches for months nows. As a PMC member, I would like to know who intends to be available to help apply patches in 2008. Not fix bugs, but simply review and apply patches. Several committers do spend a lot of time on the mailing lists, and user-to-ouser support is an important contribution. Several committers also spend a lot of time writing new code. Again, a critical contribution. But we also need people who will apply patches. If we don't have these people, then, frankly, I personally don't see the point in continuing to build releases. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
On Jan 15, 2008 5:00 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: What about replacing the term obligation with intention? +1 -- The voter's intention was the original point, and the most we could ever ask. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
On Jan 15, 2008 1:40 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote: That's a loaded question... do we have even three *PEOPLE* still willing to support further releases of S1? :) If a security flaw, or other important reason to do a new release appeared, yes, I am sure that we do. As it happens, the only outstanding patch for Struts 1 is one of Frank's, [STR-3006], an IE7 edge case. If that were the case for S2, then we wouldn't be having this conversation. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release Management (was Re: [struts-dev] [S2] Libraries in JDK 1.4 distribution)
On Jan 15, 2008 1:09 PM, Dale Newfield [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: my feeling is that until a project deprecates a release, then no, there would be no expiration. Anyone who +1'd a release is implying they are willing to support it until it's officially deprecated. Do we ever deprecate any releases except non-current patch-level ones? (I.E.: is W.X.Y automatically deprecated when W.X.Z (where ZY) is released? Is A.B.C ever deprecated if there exists no A.B.D where DC?) Not in so many words. Though, once we move on to the next minor series (x.1 to x.2), it seems unlikely that we would go back and add new features to x.1. But if a committer wanted to do it for some reason, and the release plan and quality vote passed, then it would happen. The Apache Way favors individual initiative tempered by peer review. We do deprecate features regularly ... and we even try to remove them after deprecation :) The strange part is that while the release plan is lazy majority, and the quality vote is active majority (3 +1s for quorum and +1s-1s), each individual code change is subject to a lazy consensus vote, where a PMC member has a unilateral veto. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overnight builds snapshots
Just lack of people with the bandwidth to concentrate on those tasks. :( We do have Atlassian Bamboo watching the builds for us, so we do know whether it builds or not. The various JAR files are available there, if you know where to look (under the target directories). * http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN A key problem is that we still can't quite create a distribution automatically. Integrating the Confluence HTML export of the site has been a bit of a sticky wicket. I have some volunteer hours set aside this morning, but my priority is patches, and then trying the Conventions pluing against the JPA Mailreader, toward the hope of rolling 2.1.1. Of course, all of the source is available for checkout and building through Maven, which can be more efficient that checking out the binaries, once you're setup. * http://struts.apache.org/2.x/docs/building-the-framework-from-source.html HTH, Ted. On Jan 14, 2008 7:25 AM, Al Sutton [EMAIL PROTECTED] wrote: Guys, I was just wondering what the problems are with S2 overnight builds and why the most recent snapshot appears to be from the end of October last year. Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overnight builds snapshots
On Jan 14, 2008 7:25 AM, Al Sutton [EMAIL PROTECTED] wrote: I was just wondering what the problems are with S2 overnight builds and why the most recent snapshot appears to be from the end of October last year. Just to be clear, the overnight builds are the snapshots, and the latest can be found here: * http://people.apache.org/builds/struts/nightlies/ Right now, it's only building the core JAR, which, admittedly, is next to useless without a current XWork snapshot JAR and so forth. The artifact dated for October was the version 2.0.0 test-build. * http://people.apache.org/builds/struts/ For various reasons, it's stayed a test-build rather than progressing to a Beta or a General Availability release. There are a number of outstanding patches slated for 2.1.1, and once those are applied, we would run another test build, and then decide whether to progress the quality to Beta or General Availability. There's no telling when that will happen, since the amount of time the volunteers have available fluctuates. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts 2.1.1 Release Planning
Is anyone else up to helping with the 2.1.1 release management? With the anniversary of the first Struts 2.0 GA coming up in February, it would be nice if we could squeeze out another tagged build. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
init-params as a single configuration point
If we are using REST with CodeBehind/Conventions, is it true that *any* of the application-wide properties can be set as an init-param to the filter? And if for some reason we needed to use different sets of application-wide properties, we could also configure more than one filter? I just want to make sure that we retain a single-point of configuration. I don't much are if its XML or init-param, so long as there can be only one :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overnight builds snapshots
On Jan 14, 2008 8:46 AM, Al Sutton [EMAIL PROTECTED] wrote: I'm going to look into it some more, but is it possible that bamboo is missing something? (or that the test is showing up a platform difference between the bamboo compile farm and my Vista/JDK 1.5.0_14 machine)? It's working for me under XPx64. We have had platform-specific issues before, using having to do with memory allocation or temporary files. The first thing to check is that Maven has enough memory. The second might be that Vista has not amassed too many temporary files. HTH, Ted. http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.1 Release Planning
I don't understand. Do you mean don't apply any patches for a few hours? I didn't mean to imply that we were ready t roll 2.1.1, only that I'd like to get ready over the next few weeks. On Jan 14, 2008 10:49 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/14, Ted Husted [EMAIL PROTECTED]: Is anyone else up to helping with the 2.1.1 release management? With the anniversary of the first Struts 2.0 GA coming up in February, it would be nice if we could squeeze out another tagged build. Wait some hours, until we clear things up about WW-2379: https://issues.apache.org/struts/browse/WW-2379 Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.1 Release Planning
Just whatever is on the issues list, James. On Jan 14, 2008 10:45 AM, Mitchell James [EMAIL PROTECTED] wrote: I can throw in a few hours here and there. Just let me know what you need. -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.1 Release Planning
Works for me. It has to happen sometime. On Jan 14, 2008 11:27 AM, Al Sutton [EMAIL PROTECTED] wrote: Ditch JDK 1.4 support... problem solved ;). Al. - Original Message - From: Antonio Petrelli [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Monday, January 14, 2008 3:49 PM Subject: Re: Struts 2.1.1 Release Planning 2008/1/14, Ted Husted [EMAIL PROTECTED]: Is anyone else up to helping with the 2.1.1 release management? With the anniversary of the first Struts 2.0 GA coming up in February, it would be nice if we could squeeze out another tagged build. Wait some hours, until we clear things up about WW-2379: https://issues.apache.org/struts/browse/WW-2379 Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://struts.apache.org/dtds/struts-2.0.dtd needs to be updated
On Jan 13, 2008 10:34 PM, matt.payne [EMAIL PROTECTED] wrote: No not backwards at all. It is exactly how inheritance works. A child is free to override in case it wants to provide its own implementation of something. It's how configuration works, when there can be only one configuration setting. But it is not how inheritance works in languages like Java. In the case of this particular setting, I would say that each package should be allowed its own copy of the setting, and that if we change the setting for a child, then only its children inherit the setting. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
On Jan 12, 2008 12:24 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/12, Tom Schneider [EMAIL PROTECTED]: I disagree, I think there is a support cost. If users are having issues with the 1.4 stuff, (which happens more often than not) then we're obligated to assist that user. Obligated? Come on we are all volunteers, we are not obliged to do anything: we do it because we like what we do. It's true that we're volunteers, and any of us can walk away whenever we like, but it's also true that when we vote +1 on a GA, each voter is saying that he or she intends to help support the release. If the release includes a J4 distribution, it means that we are each saying that we will make a good-faith effort to support that distribution too. If none of the committers are using the J4 builds in production now, and we have no realistic expectation that any of us are going to try and support the J4 builds, then it's dishonest to include them. Long term I think we will drop the 1.4 stuff at some point, it's just a matter of figuring out when. I think that if we drop the 1.4 stuff, we lose a lot of audience. If it means we are going to lose active contributors, then I say we should keep doing it. If it means we are going to lose anonymous users who don't contribute to the project, then I don't care. Another advantage is the builds become a bit simpler. (Or at least there's a chunk of the build that goes away) Retrotranslation seems a pretty fast process to me. It is fast, but the artifacts add to the clutter and confusion. The question is whether it's gaining us active contributors. Not freeloaders who just download the software, but volunteers who answer mailing list posts and provide patches. A year ago, the answer was yes. Now, I'm not so sure. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
OK, here it is, out of context ... * http://www.jroller.com/TedHusted/entry/geek_glossary_asf - Ted Just as long as they spell my name right Husted. On Jan 14, 2008 1:28 PM, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Mon, January 14, 2008 1:05 pm, Ted Husted wrote: Retrotranslation seems a pretty fast process to me. It is fast, but the artifacts add to the clutter and confusion. The question is whether it's gaining us active contributors. Not freeloaders who just download the software, but volunteers who answer mailing list posts and provide patches. You know Ted, if you and I were on opposite sides of a political campaign, your choice of words (freeloaders) would have given me ample ammunition to attack you for weeks, maybe wind up costing you the election! - LOL I know what you really meant by it, as did everyone else here, but you know as well as I do that there are people out there that will take anything they can find to use to attack a project they don't like... I wonder how long before this is taken out of context and shows up on someones' blog? :) -Ted. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overnight builds snapshots
Hmmm, do you have a non-Vista machine handy? It seems to be fine on Linux (Ubuntu?) and XPx64. Anyone try it on a Mac today? On Jan 14, 2008 2:32 PM, Al Sutton [EMAIL PROTECTED] wrote: OK, After the detour down the getting eclipse working I'm back on track to see whats wrong and I'd be grateful if someone could check this over. Whats happening at the moment is that FreeMarkerResultTest.testWithoutWriteIfCompleted is calling through to FreemarkerResult.execute, which in turn calls through to FreemarkerResult.doExecute in turn calls through to ResourceUtil.getResourceBase, which is where I beleive a problem is occurring. ResourceUtil.getResourceBase returns a base of (an empty string), which means the specified template can't be found (because it's in org.apache.struts2.views.freemarker instead of the default package). This throws an FileNotFound exception from line 167 of FreemarkerResult.java (Template template = configuration.getTemplate(locationArg, deduceLocale());), and because the template has not been found the StringWriter has not been written to, and thus it's empty and fails the test. Is this suppose to be the case and the StringWriter should have been written to, or is ResourceUtil.getResourceBase suppose to return something useful, find the template and the test case complete in another way? Al. - Original Message - From: Al Sutton [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Monday, January 14, 2008 4:20 PM Subject: Re: Overnight builds snapshots I've cleaned out the temporary files, put -Xmx128M in MAVEN_OPTS, and maven reports Final Memory: 16M/42M. The box is a 3GB Q6600 so I can ramp up the ram available to the JVM as far as neccessary. I've been trying to see if I could hack together an Eclipse workspace to do some tracing in to find out whats happening, but the svn tree seems to favour IntelliJ IDEA, and I'd prefer not to have to learn a new IDE just for investigation of the problem :( Al. - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Monday, January 14, 2008 3:32 PM Subject: Re: Overnight builds snapshots On Jan 14, 2008 8:46 AM, Al Sutton [EMAIL PROTECTED] wrote: I'm going to look into it some more, but is it possible that bamboo is missing something? (or that the test is showing up a platform difference between the bamboo compile farm and my Vista/JDK 1.5.0_14 machine)? It's working for me under XPx64. We have had platform-specific issues before, using having to do with memory allocation or temporary files. The first thing to check is that Maven has enough memory. The second might be that Vista has not amassed too many temporary files. HTH, Ted. http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Should voting +1 on a release imply that the vote intends to help support the release?
The ASF How it work page, at Implications of Voting, suggest that --- In some cases and communities, the exercise of a vote carries some responsibilities that may not be immediately obvious. For example, in some cases a favorable vote carries the implied message 'I approve and I'm willing to help.' Also, an unfavorable vote may imply that 'I disapprove, but I have an alternative and will help with that alternative.' The tacit implications of voting should be spelt out in the community's guidelines. However, in no case may someone's vote be considered invalid if the implied commitment doesn't appear to be met; a vote is a formal expression of opinion, not of commitment. Our community guidelines suggest that: The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing to help do the work. --- While we would never discount a binding vote of a PMC member, I believe we could agree, as a community, that if someone casts a binding vote for a GA release, it is our expectation that the PMC Member is declaring his or her intention to support the release. So, is a +1 on a GA merely a vote of confidence in the bits, or should the vote also be declaring an intention to help? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention plugin
I still have this at the top of my list, it's just been another crazy week. I do want to have good working examples of using both the Convention and REST plugins. Then, if we can apply some of the outstanding patches, we can get back to rolling 2.1.x builds :) -Ted. On Jan 4, 2008 5:57 AM, Ted Husted [EMAIL PROTECTED] wrote: That's great news, Brian. I'll give it a try on the JPA MailReader, which is using the CodeBehind plugin right now, and see if it's, well, plug and play :) -Ted. On Dec 29, 2007 12:41 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: I have the first rough version of the convention plugin checked into the sandbox. Feel free to take a look. I haven't completed the unit tests yet, but I did get most of the Javadoc updated and added all the new features and support that was discussed. The most major change I'm trying to determine if I like is that you now do most everything on the action methods rather than the action class. I tend to like it more, but my only compliant is that I have to move my getters and setters below my action methods, which I don't normally do, so that I can see how the class is configured quickly after opening it in an editor. I guess I could go Groovy and drop the getters and setters. I've also tossed around the idea of some interceptor changes that would allow for actions with public/protected member variables. Anyways, feel free to check it all out and comment on things. Oh, and there are a few outstanding bugs I've opened with XWork that I had to make locally (not a committer) in order to get things working correctly. So, if you run into issues, it could be those things. They had to do with the Guice container and type converters. I can send folks patch files until they are fixed on XWork trunk. Just send me an email if you want them. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention plugin
Oops -- The application does use custom type converters! What can I expect? It's in the sandbox, if you want to take a look. On Jan 10, 2008 10:58 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Excellent! Let me know if you run into issues. I think as long as you don't have any custom type converters in your application my XWork changes won't be necessary. Let me know if you do run into Xwork or other issues and I can help out. -bp Ted Husted wrote: I still have this at the top of my list, it's just been another crazy week. I do want to have good working examples of using both the Convention and REST plugins. Then, if we can apply some of the outstanding patches, we can get back to rolling 2.1.x builds :) -Ted. On Jan 4, 2008 5:57 AM, Ted Husted [EMAIL PROTECTED] wrote: That's great news, Brian. I'll give it a try on the JPA MailReader, which is using the CodeBehind plugin right now, and see if it's, well, plug and play :) -Ted. On Dec 29, 2007 12:41 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: I have the first rough version of the convention plugin checked into the sandbox. Feel free to take a look. I haven't completed the unit tests yet, but I did get most of the Javadoc updated and added all the new features and support that was discussed. The most major change I'm trying to determine if I like is that you now do most everything on the action methods rather than the action class. I tend to like it more, but my only compliant is that I have to move my getters and setters below my action methods, which I don't normally do, so that I can see how the class is configured quickly after opening it in an editor. I guess I could go Groovy and drop the getters and setters. I've also tossed around the idea of some interceptor changes that would allow for actions with public/protected member variables. Anyways, feel free to check it all out and comment on things. Oh, and there are a few outstanding bugs I've opened with XWork that I had to make locally (not a committer) in order to get things working correctly. So, if you run into issues, it could be those things. They had to do with the Guice container and type converters. I can send folks patch files until they are fixed on XWork trunk. Just send me an email if you want them. -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] -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Access to WW space at cwiki
To request page editing privileges to WW, first file a Contributor's License Agreement ASF http://www.apache.org/licenses/index.html#clas. An HTML export of the WW space is bundled with the Struts distribution, and so we must be sure that the ASF has the right to distribute the material in another format. For more see, * http://struts.apache.org/2.x/docs/editing-the-documentation.html HTH, Ted http://www.StrutsMentor.com/ On Jan 9, 2008 3:33 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: I have access to edit pages in the S2* spaces, but not the WW space, which also contain Struts 2 documentation. Can anyone grant me access there? And why is there both a S2WIKI space and a WW space? Nils-H (username nilsga) - 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
The Hegvik at the end of the name on this email confused me. I looked for that in the CLA file, and nothing turned up, so I thought this was someone else. nilsga has editing karma to WW now. -Ted. On Jan 9, 2008 5:44 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/9, Ted Husted [EMAIL PROTECTED]: To request page editing privileges to WW, first file a Contributor's License Agreement ASF http://www.apache.org/licenses/index.html#clas. Ted, Nils is a Struts committer... Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] - Plugin documentation in the wiki
If the plugin is bundled with the distribution, then the documentation can go here * http://struts.apache.org/2.x/docs/plugin-developers-guide.html And then we just put a bridge page in the S2PLUGINS space, so that people can get here from there :) The S2PLUGIN space covers both the plugins that we bundle, and the plugins that other people distribute. If the documentation for a bundled plugin in the S2PLUGINS space, and the authors have a CLA on file, then we could move it to WW. HTH, Ted On Jan 9, 2008 8:34 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Where's the correct place to put documentation for S2 plugins? I've noticed that some reside in the S2PLUGINS space in the wiki, and some are in the WW space. I put the portlet plugin documentation in the S2PLUGINS space, which I have a feeling was the wrong place to put it... It aparently also causes problems when the pages are exported, since the links point into the wiki, and not the exported static content. Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] - Plugin documentation in the wiki
Like this: * http://cwiki.apache.org/S2PLUGINS/rest-plugin.html -T. On Jan 9, 2008 8:44 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Ok, I'll just move it there then, and create a link (I'm not sure if that's what you meant by a bridge page?) in the S2PLUGINS space to it. Thanks. Nils-H On Jan 9, 2008 2:39 PM, Ted Husted [EMAIL PROTECTED] wrote: If the plugin is bundled with the distribution, then the documentation can go here * http://struts.apache.org/2.x/docs/plugin-developers-guide.html And then we just put a bridge page in the S2PLUGINS space, so that people can get here from there :) The S2PLUGIN space covers both the plugins that we bundle, and the plugins that other people distribute. If the documentation for a bundled plugin in the S2PLUGINS space, and the authors have a CLA on file, then we could move it to WW. HTH, Ted On Jan 9, 2008 8:34 AM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Where's the correct place to put documentation for S2 plugins? I've noticed that some reside in the S2PLUGINS space in the wiki, and some are in the WW space. I put the portlet plugin documentation in the S2PLUGINS space, which I have a feeling was the wrong place to put it... It aparently also causes problems when the pages are exported, since the links point into the wiki, and not the exported static content. Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LoggingInterceptor output
Looking at the code
public String intercept(ActionInvocation invocation) throws Exception {
logMessage(invocation, FINISH_MESSAGE);
String result = invocation.invoke();
logMessage(invocation, START_MESSAGE);
return result;
}
that does seem to be the case.
I don't understand why that would be.
Does anyone know if there a FishEye or ViewVCC instance for XWork available?
-Ted.
On Jan 7, 2008 8:05 AM, stanlick [EMAIL PROTECTED] wrote:
I am using 2.0.11 and the started and finished messages seem to be written in
the opposite order.
Scott
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention plugin
That's great news, Brian. I'll give it a try on the JPA MailReader, which is using the CodeBehind plugin right now, and see if it's, well, plug and play :) -Ted. On Dec 29, 2007 12:41 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: I have the first rough version of the convention plugin checked into the sandbox. Feel free to take a look. I haven't completed the unit tests yet, but I did get most of the Javadoc updated and added all the new features and support that was discussed. The most major change I'm trying to determine if I like is that you now do most everything on the action methods rather than the action class. I tend to like it more, but my only compliant is that I have to move my getters and setters below my action methods, which I don't normally do, so that I can see how the class is configured quickly after opening it in an editor. I guess I could go Groovy and drop the getters and setters. I've also tossed around the idea of some interceptor changes that would allow for actions with public/protected member variables. Anyways, feel free to check it all out and comment on things. Oh, and there are a few outstanding bugs I've opened with XWork that I had to make locally (not a committer) in order to get things working correctly. So, if you run into issues, it could be those things. They had to do with the Guice container and type converters. I can send folks patch files until they are fixed on XWork trunk. Just send me an email if you want them. -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: XWork project
The backstory is that we proposed bringing over WebWork as Struts 2, we decided to leave XWork at OpenSymphony. One reason is that most of us like the strong separation between XWork and Struts 2, so as to keep HTTP from creeping back in the core API. Another reason is that incubating a large codebase is painful, and there are so many other ways we could spend our volunteer hours. As it stands, most or all of the active XWork committers are Struts 2 committers, and, in practice, Struts 2 committers tend to be welcomed as XWork committers. So far, XWork hasn't had too much trouble keeping up with the Struts 2 releases. If XWork did decide to join the ASF, it probably end up being another top-level Apache project, and the overall workflow wouldn't be much different. The net gain would be pretty much zero. Merging XWork and Struts 2 back into a monolithic codebase has been discussed, and the suggestion seems like a non-starter. As for OGNL, the codebase is rumored to be dark and mysterious. As Don mentioned, volunteer hours might be better spent making the expression language pluggable, and then plugging in JUEL. I'm not 100% sure, but I believe if we ever made the tags into a plugin, then FreeMarker would be a dependency of that plugin, rather than the core. (A Good Thing, IMHO.) -Ted. On Jan 2, 2008 5:26 PM, Don Brown [EMAIL PROTECTED] wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork project
Not every Struts committer works on Struts 2, and not every committer working on Struts 2 wants to work on XWork too. It's a security exception to give people accounts that they haven't requested and may never use. AFAIK, to date, anyone here who wanted access to XWork has gotten it without any trouble. I don't think we need any formal agreements. (In fact, I think some people like the fact that XWork is not as formal than Struts.) We probably just need to remember to mention to new committers that anyone who wants access to XWork should ping Rainer or Don. And, in any event, the venue for that discussion would be the XWork list. :) -Ted. On Jan 4, 2008 12:24 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: If the codebases are to remain separate, I'd like to suggest that all Struts2 committers are added to XWork. The reason that I say that is the codebases are so coupled. If you look through comments in XWork, you start to see more references directly to Struts2. Struts2 won't function unless XWork is functioning and the XWork API is not changing. Therefore, it is sometimes very important to work in both codebases when doing development for Struts2 and bugs in XWork often halt development completely on Struts2 until they are resolved. -bp Ted Husted wrote: The backstory is that we proposed bringing over WebWork as Struts 2, we decided to leave XWork at OpenSymphony. One reason is that most of us like the strong separation between XWork and Struts 2, so as to keep HTTP from creeping back in the core API. Another reason is that incubating a large codebase is painful, and there are so many other ways we could spend our volunteer hours. As it stands, most or all of the active XWork committers are Struts 2 committers, and, in practice, Struts 2 committers tend to be welcomed as XWork committers. So far, XWork hasn't had too much trouble keeping up with the Struts 2 releases. If XWork did decide to join the ASF, it probably end up being another top-level Apache project, and the overall workflow wouldn't be much different. The net gain would be pretty much zero. Merging XWork and Struts 2 back into a monolithic codebase has been discussed, and the suggestion seems like a non-starter. As for OGNL, the codebase is rumored to be dark and mysterious. As Don mentioned, volunteer hours might be better spent making the expression language pluggable, and then plugging in JUEL. I'm not 100% sure, but I believe if we ever made the tags into a plugin, then FreeMarker would be a dependency of that plugin, rather than the core. (A Good Thing, IMHO.) -Ted. On Jan 2, 2008 5:26 PM, Don Brown [EMAIL PROTECTED] wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts JIRA readonly ATM
The Struts JIRA instance seems to be read-only ATM. There was an upgrade over the weekend, and there's a thread open on [EMAIL PROTECTED] In the meantime, I've been scrolling through the 80+ unscheduled issues and making notes as to scheduling them. I hope to start applying some of the patches today, updating JIRA at a later time, if necessary. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts JIRA readonly ATM
OK, we are read/write again. Let the games begin! On Jan 3, 2008 4:49 AM, Ted Husted [EMAIL PROTECTED] wrote: The Struts JIRA instance seems to be read-only ATM. There was an upgrade over the weekend, and there's a thread open on [EMAIL PROTECTED] In the meantime, I've been scrolling through the 80+ unscheduled issues and making notes as to scheduling them. I hope to start applying some of the patches today, updating JIRA at a later time, if necessary. -Ted. -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Preparing for 2.1.1
I scrolled through the 84 unscheduled tickets and assigned 20 tickets with patches to 2.1.1. bringing that total to 58 tickets Since there were so many (and JIRA was readonly), I actually made a list first. Since I have it, I might as well annex it :) Quite a few seemed like support incidents to me, so I resolved those as incomplete with a comment that they should be posted to the user mailing list first. -- HTH, Ted * http://www.StrutsMentor.com/ Future WW-2277 WW-2305 WW-2307 WW-2308 ww-2314 ww-2326 ww-2330 WW-2332 ww-2333 ww-2336 ww-2337 ww-2338 ww-2339 ww-2342 ww-2344 ww-2345 ww-2349 ww-2350 ww-2352 ww-2353 ww-2356 ww-2357 ww-2358 ww-2359 ww-2362 ww-2365 WW-2367 WW-2372 WW-2373 WW-2381 WW-2391 WW-2392 WW-2393 WW-2394 ww-2365 Patch WW-2285 WW-2286 ww-2287 WW-2293 ww-2311 WW-2315 WW-2320 ww-2323 ww-2324 ww-2331 ww-2334 ww-2343 ww-2351 ww-2361 WW-2366 WW-2383 WW-2385 WW-2397 WW-2398 WW-2293 Support Issue (Incomplete) WW-2281 WW-2301 WW-2355 ww-2364 WW-2368 WW-2369 WW-2370 WW-2374 WW-2375 WW-2376 WW-2377 WW-2384 WW-2386 WW-2390 WW-2396 WW-2399 WW-2400 WW-2401 WW-2402 ww-2403 Not a problem WW-2304 WW-2309 (doc) WW-2378 WW-2387 xWork WW-2294 WW-2298 WW-2312 Duplicates WW-2351 WW-2303 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Destroy Of Interceptor
+1 I haven't traced the code, but I believe we redeploy the Interceptors in dev mode, making a destroy option more important. On Dec 14, 2007 7:46 PM, Tom Schneider [EMAIL PROTECTED] wrote: You know, I think you're right! I searched the entire codebase (both xwork and struts) and I have found nowhere where we call destroy() on the interceptors. I guess that hasn't been an issue because if the destroy isn't being called, no big deal because your usually shutting down anyway. If we were to call destroy on the interceptors, I would expect it to happen in the cleanup() method of Dispatcher. This is where all the rest of the cleanup happens. At runtime, the list of interceptors is stored in the ActionConfig object. (part of xwork) Perhaps it might be a good idea to submit a patch that fixes this issue. :) (hint, hint) Tom Décio Heinzelmann Luckow wrote: Hi All, I´m studing Interceptors and I was looking for the local where Struts call the destroy() method of Interceptor. The init() method is called at the same time of construction of Interceptor, but I can´t find where the destroy is called. Someone know where its happen? Tanks! Décio Heinzelmann Luckow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Destroy-Of-Interceptor-tp14338766p14339890.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] -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: web-beans ?
If by alternate implementation, you mean an implementation of JSR 299, that's something best discussed with the MyFaces group. Evidentially, Shale is merging with MyFaces, making MyFaces our one-stop JSF shop. :) Meanwhile, Don's been working on a scope plugin in the sandbox that mimic's Seam-style bijection. I'm not sure of the status, but you might want to have a look at what he's done so far. ' http://svn.apache.org/viewvc/struts/sandbox/trunk/struts2-scope-plugin/ Also in the Apache Struts sandbox is the JPA MailReader implementation that Wes mentioned. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll probably be heads-down on some Ajax stuff the rest of December, but I hope to get back to this eventually. -- HTH, Ted * http://www.StrutsMentor.com/ On Dec 14, 2007 2:41 AM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I' just looked at jBoss Seam documentation. I wonder if anyone allready suggested to have similar features on Struts actions, that seems not so difficult to implement, by mixing an OpenSessionInView interceptor, some ModelDriven elements and injecting a JPA EntityManager in the action. As Seams is now promoted as a JSR (299), this could be nice to have Struts as an alternative implementation. Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: In regards to Struts 2 Validation.
A good place to start might be with a set of use cases that demonstrate various validation scenarios. We could then try to implement the use cases using the XW validation, Commons validator, and Hibernate Validator, and compare the outcome. -- HTH, Ted * http://www.StrutsMentor.com/ On Dec 12, 2007 5:18 AM, Bob Tiernay [EMAIL PROTECTED] wrote: Fair enough. But HV still doesn't have a full set of validation features in my opinion. Perhaps we should discuss what is wrong with our current validation support, and what we want to accomplish. I believe all we need are some simple changes to take us most of the way there. My personal thoughts have been captured here (just replace the word OVal with Struts2 Validation): http://sourceforge.net/forum/forum.php?thread_id=1889936forum_id=488109 Date: Tue, 11 Dec 2007 03:38:50 -0800 From: [EMAIL PROTECTED] To: dev@struts.apache.org Subject: Re: In regards to Struts 2 Validation. Hmmm, I'd say that it's still a safe bet that Hibernate Validator will have a profound effect on JSR 303, akin to JPA and Hibernate Core. I've seen posts on the Hibernate list that imply JSR 303 will be backwardly compatible with HV. -Ted. On Dec 10, 2007 4:37 PM, Bob Tiernay [EMAIL PROTECTED] wrote: I believe that OVal will soon be a referenced as existing technology for this JSR: http://sourceforge.net/forum/forum.php?thread_id=1640398forum_id=488109 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Exercise your brain! Try Flexicon! http://puzzles.sympatico.msn.ca/chicktionary/index.html?icid=htmlsig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: In regards to Struts 2 Validation.
Hmmm, I'd say that it's still a safe bet that Hibernate Validator will have a profound effect on JSR 303, akin to JPA and Hibernate Core. I've seen posts on the Hibernate list that imply JSR 303 will be backwardly compatible with HV. -Ted. On Dec 10, 2007 4:37 PM, Bob Tiernay [EMAIL PROTECTED] wrote: I believe that OVal will soon be a referenced as existing technology for this JSR: http://sourceforge.net/forum/forum.php?thread_id=1640398forum_id=488109 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S1/2: Data integrity and security
On Dec 6, 2007 10:59 PM, Paul Benedict [EMAIL PROTECTED] wrote: I think we should document this question on the wiki and whiteboard this idea. The makers of HDIV will be able to contribute answers there too. HDIV is being distributed via SourceForge, and SourceForge offers a wiki now too. If the notion is to have a multi-framework interface that would work with S1, S2, Tapestry, Wicket, and so forth, perhaps HDIV should activate their wiki, and we could invite people from those groups to chime in. It's also something that we could bring up on our favorite Rebel Looking for a Cause, the Java Web Alignment Group :) * http://tech.groups.yahoo.com/group/java_web_alignment/ -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SmartURLs port
Once the branch is available, I can also try it against the JPA MailReader that's in the sandbox. This particular application was reworked for SmartURLs and the backported to CodeBehind. Bringing it forward again would help test whether the branch is a proper superset of the existing feature set or not. Just committing it to the sandbox under the name CodeBehind2 might be a good way to go, since that is how we usually bring plugins and whatnot into the project. -Ted. On Dec 6, 2007 5:03 AM, Don Brown [EMAIL PROTECTED] wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S1/2: Data integrity and security
It's unusual that a feature such as this comes without penality. If HDIV were native, what would be the performance cost? Complexity cost? Although I have no clue what SPI means, I do see the web page mentions Struts by name, and says that it can be added to applications transparently. What if we were to start by adding HDIV to our example applications and posting the result in the sandbox. This would give us an opportunity to identify any pain points, as well as compare the performance impact. The vast majority of web applications run inside a firewall and are used by a handful of trusted employees. There are many cases where Klingon-grade security may not always trump day-to-day performance. On the Struts 1 security front, there are also projects like the Struts SSL Extension which could be subsumed into the core. -Ted. On Dec 6, 2007 12:34 PM, Matt Raible [EMAIL PROTECTED] wrote: HDIV seems to solve a problem that most web application developers don't know they have. By natively, I mean it's part of the core and you can't make your application less secure by ripping it out. It is Apache licensed after all. If rolling it into the core isn't an option, it would be nice if it was easier to integrate. Instead of requiring new tag libraries, it'd be nice if tag libraries (and Velocity/FreeMarker macros) were HDIV aware. If an HDIV JAR/Plugin is on the classpath - use it. Matt On Dec 6, 2007, at 9:22 AM, Paul Benedict wrote: Matt, I want to use HDIV natively in Struts 1 too -- which is why I was hoping for an SPI interface which anyone can provide for an implementation. What do you have in mind with native integration? And is your idea of integration also against an SPI? Paul On Dec 6, 2007 10:18 AM, Matt Raible [EMAIL PROTECTED] wrote: What about integrating HDIV natively so Struts is as secure as it can possibly be? Matt On Dec 5, 2007, at 11:08 PM, Paul Benedict wrote: I've been emailing the authors of HDIV offline for some quite time. I take a fond interest in data integrity and security, and believe their project is a great benefit to Struts. The problem, of course, exists that S1 and S2 are so radical in architecture that separate deliverables are required. I think a framework SPI should be provided so that library implementors can scramble form data (e.g., hidden form field values) and provide whatever encryption necessary. The goal would be for this SPI to be honored in both Struts 1.4 and latest Struts 2.x. This would be the start of a shared library between Struts versions. These are the current known extension points that the SPI would be invoked for: 1. Form start point 2. Form end point 3. Link or form's action 4. Form's Parameters name 5. FoParameter's values Where is the right place to whiteboard this idea? Email or MoinMoin? And is anyone else interested in helping? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted * http://www.StrutsMentor.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the Source, Luke!
Either way, there should be a release plan if we are moving forward with 1.4.0 * http://wiki.apache.org/struts/StrutsReleasePlans -T. On Dec 5, 2007 4:41 AM, Niall Pemberton [EMAIL PROTECTED] wrote: I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for the next Struts (1.4) version - but perhaps we did? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing source jars in maven repo
OK, for the next round, we can run it with the alljars parameter, and see if that helps. On Dec 4, 2007 3:00 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: In fact I did not fix anything, I only fixed the wiki! the alljars needs to be activated when deploying. I cannot do it myself since I changed my PC, where I have my private keys to sign artifacts (I have to migrate them, but I don't have the time). The steps are pretty simple: deploy with: mvn deploy -P release,all,alljars,pre-assembly -Dpassphrase=$PASSPHRASE and then move only the -source and -javadoc artifact to the rsync-ed directory. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing source jars in maven repo
I did try to use the plugin last time, but there's a problem with my security setup, and the plugin doesn't work for me. I'd like to setup a new workstation soon, but it probably won't happen this calendar year. The underlying problem is that the ASF expects us to sign all the JARs, which complicates the release process, and creates a bar toward other volunteers stepping up and helping. Ironically, the reason we sign the JARs is to help protect the release managers from individual liability. On Dec 4, 2007 9:39 AM, Tomislav Stojcevich [EMAIL PROTECTED] wrote: It does, but from the looks of the release process at http://struts.apache.org/2.x/docs/creating-and-signing-a-distribution.html the release plugin is not being used. Even if it were, in the parent pom it has useReleaseProfilefalse/useReleaseProfile in the release plugin configuration so it won't run with that profile for whatever reason. It could be changed so that it does run with the release profile and/or changed so that all required profiles are run -P release,all,alljars,pre-assembly. That way nobody forgets. Just mvn release:prepare and mvn release:perform. Although the build does look a bit more complex so maybe it can't be done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing source jars in maven repo
The crux of my problem is that automatic signing doesn't work, and I have to enter the passcode multiple times during the build. (It's a pain, but no one else seems to be available to roll the releases.) My recollection is with the plugin, signing didn't work at all. I'm sure the plugin is fine, the problem is with my system. On Dec 4, 2007 12:11 PM, Tomislav Stojcevich [EMAIL PROTECTED] wrote: This might help. The jar plugin can be configured to automatically sign the jars when it creates them during the package phase. http://maven.apache.org/plugins/maven-jar-plugin/usage.html http://maven.apache.org/plugins/maven-jar-plugin/sign-mojo.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent WebWork fixes
Thanks, Wes. We appreciate the help! -Ted. On Dec 4, 2007 3:54 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: Hello, I took a look through the issues that have been resolved in the last few weeks over on webwork and found the following - webwork's WW-1476 and WW-1463 are non-issues in struts2 because the webwork issues are related to components that were moved / updated to be in the dojo plugin. Just to be sure, I checked the new versions of the affected tags and the resolved issues in webwork are non-issues in struts2. webwork's WW-1475 and WW-1485 were both XWork issues and fixed in XWork. webwork's WW-1453 and WW-1442, I created struts2 WW-2351 and attached a patch. webwork's WW-1466 is already created in struts2 as WW-2128. The last issue is webwork's WW-1456 - http://jira.opensymphony.com/browse/WW-1456 which appears to require a bit more work than I can do just this second, but unless someone else takes care of it first, I'll take a closer look tonight. -Wes -- Wesley Wannemacher President, Head Engineer/Consultant WanTii, Inc. http://www.wantii.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP EL in struts2 tags
As someone mentioned, do we want to bundle both under different URIs? We could keep the paranoid/safe one as the default, and use a URI like struts-tags-rt for the one that allows all runtime expressions. To use the other, we can change one line at the top of the file to opt in. -Ted. On Dec 3, 2007 2:48 AM, Don Brown [EMAIL PROTECTED] wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting patches committed
I'll be heads-down until at least December 19th, but I should be able to start appying patches again by the end of the year. It's not that they are being ignored, it's just, as you say, that no one has time. Struts is still an all-volunteer project, and everyone has some other full time job. frustration-speaking Personally, I think that the Java web community should be ashamed. Struts has generated millions of dollars of revenue for consultants, training centers, and publishers, the world over, and saved tens of thousands of companies the expense of developing and documenting their own framework. Yet, no one has ever stepped up and tried to put a paid developer into the Struts group. It boggles the mind. /frustration-speaking -Ted. On Dec 3, 2007 3:24 PM, chengas123 [EMAIL PROTECTED] wrote: Hi, I submitted a bug fix patch about three weeks ago and it seems like it was approved and never committed (WW-2094 and WW-2300). I know everyone's busy, but it seems like those issues on the JIRA are being ignored. Another patch (WW-2240) has been ignored as well. I've got a much more recent patch (WW-2256) that I'm also hoping someone will take a look at. Let me know if there's anything I can do to help get these fixes committed (which address rather noticeable, major, and easy to fix issues) since I don't have commit privileges. Thanks, Ben http://benmccann.com -- View this message in context: http://www.nabble.com/Getting-patches-committed-tf4939073.html#a14137942 Sent from the Struts - Dev mailing list archive at Nabble.com. - 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]
Re: Missing source jars in maven repo
Unfortunately, I have no idea how to fix it. My setup here isn't quite right, and it might have something do with it. The exact steps we follow are here: * http://struts.apache.org/2.x/docs/creating-and-signing-a-distribution.html I know Antonio has been working on it, and if he, or someone else, runs the 2.1.1 release, maybe he or she will be able to do a better job. :) I'd like to get an Ubuntu system installed here soon, which might also help. -Ted. On Dec 3, 2007 3:06 PM, Paul Benedict [EMAIL PROTECTED] wrote: I agree this is a problem. I haven't been able to find the Struts 2 source code (and javadocs) in the repos myself. Paul On Dec 3, 2007 2:04 PM, Tomislav Stojcevich [EMAIL PROTECTED] wrote: Can somebody please manually upload the source jars to the maven repo. See the following issues: https://issues.apache.org/struts/browse/WW-2346 https://issues.apache.org/struts/browse/WW-1870 https://issues.apache.org/struts/browse/WW-1587 https://issues.apache.org/struts/browse/WW-2028 Either the profile isn't getting used during release or there is something wrong with the profile or there is something wrong with the sync to the maven repo. After at least 4 reported and closed issues, i still cannot find a single source file for any of the version 2 jars in the central repo. Thanks --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]
Re: JRuby in Struts 2
On Dec 2, 2007 3:13 PM, Tom Schneider [EMAIL PROTECTED] wrote: So I'm curious to see where others on the dev list see Ruby fitting into the s2 ecosystem. Should we have a rails-like framework that is pretty close to Ruby on Rails and makes an easy transition from rails? Or do we want something that diverges from the rails and provides an alternate to rails development on the JRuby platform? This is a Brave New World for struts so I think it's useful to get some ideas on where we might take this. I would say that Rails is an excellent source of inspiration, but I don't think Ruby or Rails is magic. Rails incorporates a number of good ideas, and a take no prisoners perspective toward productivity, but that doesn't mean every idea is perfectly implemented. It's my belief that we can achieve the same level of productivity in Java by using tools like Eclipse, Maven, and JPA to their full extent. I'm especially impressed by the plugins now available with MyEclipse. With Tomcat and Derby bundled in, we can download Java and MyEclipse and start writing enterprise-grade applications out of the box. A key to the success of Rails has been ActiveRecord. Likewise, a key to creating a highly productive Java stack is adopting and exploiting JPA. For the type of applications that most people write, especially with something like Rails, JPA is an ideal technology. I'm finishing up a JPA/Struts training course now. I'm presenting it next week, and after I hope to do a series of companion tutorials. I'm not sure that everyone realizes how close the Java ecosystem may be to a productivy tipping point, where we might see 2x and 3x gains, just by aggressively integrating and exploiting the tools we already have at our fingertips. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JRuby in Struts 2
We did/do have BSF/JavaScript Actions for Struts 1. I had been thinking of bringing that forward for Struts 2, but there's always something else going on :) You might want to look there for inspiration: * http://struts.apache.org/1.3.8/struts-scripting/index.html Going back to your original post. As to #1, the type issue, I'd try a Struts 1 approach. Use only String properties on the Action. Try replacing the default interceptor with one that doesn't try to do conversion, but sets everything as if it were a String. Hopefully, JRuby can take it from there. Alternatively, there's also the notion of first gathering the input into a Map in a base Action, and then converting from Map to an object with properties. This could even be a useful strategy for some Java implementations and make use of a marker interface, like MapAware. As to #2, we haven't had annotations that long, and I don't think it's been anyone's intention to make Struts 2 an annotation-dependent framework. What is that we can suddenly do with annotations that can't be done with XML descriptors? Moreover, while there might not be annotations in Ruby (yet), could there be annotations in JRuby? Overall, I wouldn't overlook the idea of JRuby for Struts 1, Java's most popular web framework, based on what we already have in the Struts 1 BSF extension (thanks Don!). I'd also emphasize the need for JRuby to play nice with JPA. I haven't done any work with Groovy, but the same suggestion would hold. Though I see at least someone has tried it: * http://www.curious-creature.org/2007/03/25/persistence-made-easy-with-groovy-and-jpa/ -Ted. On Dec 2, 2007 5:33 PM, Tom Schneider [EMAIL PROTECTED] wrote: No Martin, that's a valid question. Is there a need for JRuby in S2? I'm not really the person driving this initiative, it's Richard Burton with assistance from Charles Nutter (one of the JRuby core developers). I just provided some S2 technical expertise for them. However, since Sun employs 2 of the core JRuby developers, I don't think it's going away any time soon. I think originally we thought we could write S2 actions in JRuby. Since that didn't work out so well, the question becomes: 'Now what?' Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping up with Toby :)
That would be great, Wes. There's plenty to go around. On Nov 30, 2007 9:21 AM, Wes Wannemacher [EMAIL PROTECTED] wrote: Ted, I'd like to take a crack at this one. I am not a committer, but I've worked in both the s2 and xwork2 codebase. -Wes On 11/30/07, Ted Husted [EMAIL PROTECTED] wrote: I'd also suggest focusing on the 2.1.x head, rather than worrying about backporting to the 2.0.x branch, unless of course it's something so nasty that we should roll a 2.0.12 release. We're probably in good shape for 2.1.x. I believe it's mainly a matter of catching up on the patches and wrapping up the CodeBehind/SmartURLs merger. -T. On Nov 30, 2007 8:43 AM, Ted Husted [EMAIL PROTECTED] wrote: Sure. Just try to see if there is already a matching ticket. Phil created a few during the transition period that might still be open. On Nov 30, 2007 8:15 AM, Martin Gilday [EMAIL PROTECTED] wrote: Should we just create a matching Struts 2 JIRA issue, linking to the WW one and attach the patch there? - Original message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Date: Fri, 30 Nov 2007 07:50:05 -0500 Subject: Keeping up with Toby :) Our good friend Toby (tm_jee) has been closing a lot of tickets on the WebWork side. I expect that some of these could be ported to Struts 2. If anyone is looking for an opportunity to learn more about Struts 2, we could use volunteers to review Toby's WW patches and port them to S2. Of course, if the volunteer were not a committer, I'd be happy to apply the patches on this side (though, I can't promise same day service!). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping up with Toby :)
I'd also suggest focusing on the 2.1.x head, rather than worrying about backporting to the 2.0.x branch, unless of course it's something so nasty that we should roll a 2.0.12 release. We're probably in good shape for 2.1.x. I believe it's mainly a matter of catching up on the patches and wrapping up the CodeBehind/SmartURLs merger. -T. On Nov 30, 2007 8:43 AM, Ted Husted [EMAIL PROTECTED] wrote: Sure. Just try to see if there is already a matching ticket. Phil created a few during the transition period that might still be open. On Nov 30, 2007 8:15 AM, Martin Gilday [EMAIL PROTECTED] wrote: Should we just create a matching Struts 2 JIRA issue, linking to the WW one and attach the patch there? - Original message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Date: Fri, 30 Nov 2007 07:50:05 -0500 Subject: Keeping up with Toby :) Our good friend Toby (tm_jee) has been closing a lot of tickets on the WebWork side. I expect that some of these could be ported to Struts 2. If anyone is looking for an opportunity to learn more about Struts 2, we could use volunteers to review Toby's WW patches and port them to S2. Of course, if the volunteer were not a committer, I'd be happy to apply the patches on this side (though, I can't promise same day service!). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping up with Toby :)
Sure. Just try to see if there is already a matching ticket. Phil created a few during the transition period that might still be open. On Nov 30, 2007 8:15 AM, Martin Gilday [EMAIL PROTECTED] wrote: Should we just create a matching Struts 2 JIRA issue, linking to the WW one and attach the patch there? - Original message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Date: Fri, 30 Nov 2007 07:50:05 -0500 Subject: Keeping up with Toby :) Our good friend Toby (tm_jee) has been closing a lot of tickets on the WebWork side. I expect that some of these could be ported to Struts 2. If anyone is looking for an opportunity to learn more about Struts 2, we could use volunteers to review Toby's WW patches and port them to S2. Of course, if the volunteer were not a committer, I'd be happy to apply the patches on this side (though, I can't promise same day service!). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
