I found these issues:
1.) ForwardConfig inheritance doesn't work when trying to inherit
global forwards. There's code to handle it within the config objects,
but they're not being triggered at app startup.
2.) Arbitrary properties don't get copied when creating ActionRedirect
objects based on
head-slap/
:) You mean we should have release notes too ?
* http://confluence.twdata.org/display/WW/Release+Notes+2.0.0
Anyone trying the snapshot may want to watch this page for updates.
Contributions to the Release Notes or Migration Guide are welcome.
-Ted.
On 7/23/06, Matt Raible [EMAIL
If so, maybe the best thing to provide is a portlet wrapper that can work
with an s2 app
(similar to MyFacesGenericPortlet for MyFaces). Then let the portal vendors
provide the deployment script.
From my limited knowledge of Portlets, I think this is what Struts2 / WebWork
is doing.
About the ant build that creating a skeleton for various portlet container,
what if we build a maven arcetype specific for each of the portlet container?
Maybe,
mvn archetype:create .. portlet-liferay-archetype-starter
will create a template/skeleton for liferay portal, just like what we
Hi Matt,
Is there a repo/artifactId/groupId I can use to start testing this.
Ted just pointed this out to me. :-) Its at
http://people.apache.org/builds/struts/2.0.x/
Is there any documentation of what's changed in order to upgrade
from WebWork 2.2 to Struts 2.0?
Ted wrote up somthing about
The snippet binary is attached with a comment indicating the source and date.
Our snippet macro is a lot more advanced than the one you linked to. It is
based on that one, however.
-
Posted via Jive Forums
Sounds good to me, provided everyone is aware that 2.0.1 and 2.0.2 will likely
have some large changes.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38227messageID=75314#75314
On Jul 24, 2006, at 9:47 AM, tm jee wrote:
About the ant build that creating a skeleton for various portlet
container, what if we build a maven arcetype specific for each of
the portlet container?
Maybe,
mvn archetype:create .. portlet-liferay-archetype-starter
will create a
On 7/24/06, Greg Reddin [EMAIL PROTECTED] wrote:
Honestly, I don't know what
the WebWork approach has been in the past. I think with Struts,
we've just provided helper documentation for those kinds of things.
There's a portlet tutorial here:
*
On 7/23/06, Bob Lee [EMAIL PROTECTED] wrote:
If we want to tag now, the new API will have to wait for 3.0.
I think we are reaching the point where if we still want to make
large changes for 2.0, we need to make them now, or make them in
2.1. AFAIC, we can open 2.1 as soon as we have a stable
On 7/23/06, Bob Lee [EMAIL PROTECTED] wrote:
If we want to tag now, the new API will have to
wait for 3.0.
I think we are reaching the point where if we still
want to make
large changes for 2.0, we need to make them now,
or make them in
2.1. AFAIC, we can open 2.1 as soon as we have a
Now wait a minute - what happened to our alpha releases? In a more traditional
scheme, you would have 2.0 alpha and 2.0 alpha 1, which could contain
basically anything you want. The clear alpha designation indicates that big
changes are in progress and this is more of a milestone release to
It's not about the numbering system; it's about the August people like
to bandy about.
Realistically, if we are going to have anything like a stable release
in the August timeframe, we need to feature lock now, so that we can
test and document what we already got.
I'm not against the new API,
On 7/24/06, Ted Husted [EMAIL PROTECTED] wrote:
* http://confluence.twdata.org/display/WW/Release+Notes+2.0.0
From the release notes:
* Java 1.5 is required to build the Struts 2 distribution from source,
but Java 1.4 is targeted for the binary JARs.
The struts2-parent pom is targetting
I don't often reply to messages on these lists, but I
feel like I
have to offer a (relatively) outside perspective
here.
There's been a lot of confusion external to apache
about what's going
on with Struts. With Shale moving to a TLP, that's
helped, but I
think a lot of people
On 7/24/06, Tim Fennell [EMAIL PROTECTED] wrote:
There's been a lot of confusion external to apache about what's going
on with Struts. With Shale moving to a TLP, that's helped, but I
think a lot of people are still confused about exactly what Struts
2.0 will be.
Shale graduating to top-level
On 7/24/06, Jason Carreira [EMAIL PROTECTED] wrote:
+1 to this. This is what we talked about at JavaOne, I thought... We can have
pre-releases, where it's ok for people to get their feet wet, but if
we want the big API
changes we've talked about, and I think we do, then we can't release
a
As Wendy pointed out, I missed the step where we convert the bits from
1.5 to 1.4 using RetroWeaver or RetroTranslator.
Any preferences?
Or, should we post both, and see what happens?
-Ted.
* http://retroweaver.sourceforge.net/
* http://retrotranslator.sourceforge.net/
It's a gentle slide for WebWork 2.2 developers now, and some of us
would like to keep it that way.
Forever? Or just for the Struts 2.0 release? Because if you guys
are talking about making sweeping changes some time ... can you keep
doing this?
Now, if the current 2.0.0 doesn't represent
These are all good points, and I'm happy to see the diverse involvement. I'm
wondering if perhaps we should reclassify the 2.0.0 release. To some, it
signifies the next great foundation to build web apps upon, and by doing so,
sweeps clean the legacies of Struts and WebWork. When I look at
I think we should follow Tim's lead by using RetroTranslator, however, it
shouldn't hold up the 2.0.0 release.
Don
Ted Husted wrote:
As Wendy pointed out, I missed the step where we convert the bits from
1.5 to 1.4 using RetroWeaver or RetroTranslator.
Any preferences?
Or, should we post
I'd love to be able to use a Maven plugin, like the Jetty one, to easily test
the portlet w/o any extra installation. Using 'mvn jetty6:run-war is just too
handy. This is one of my many personal todo projects :)
Don
Ted Husted wrote:
On 7/24/06, Greg Reddin [EMAIL PROTECTED] wrote:
But to me, making
sweeping changes to the core API should not be an option for a long
time after 2.0 goes stable.
Sure, but why should 2.0 be seen as the end of the road. Not so long
ago, only early adopters used the #.0 version of anything, even if
shrink-wrapped :)
We already know 2.0 won't
This bridge is really what exists today in Struts 2/WebWork 2. You can write
an app, test it in Tomcat as a webapp, then run it as a portlet without any code
changes.
I think what Toby is talking about is helping with the extra configuration files
that the different portals require. I think
On 7/24/06, Ted Husted [EMAIL PROTECTED] wrote:
It's a gentle slide for WebWork 2.2 developers now, and some of us
would like to keep it that way.
It will be gentle either way; there's no reason we can't continue to support
the existing API in a deprecated fashion.
WebWork teams perhaps,
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
Struts 2.0.x - WebWork transitional releases
Struts 2.1.x/3.0.x - The true successor to Struts and WebWork
Can number them this way instead? It seems more intuitive.
Struts 2.0 alpha/beta x - WebWork transitional releases
Struts
On 7/24/06, Bob Lee [EMAIL PROTECTED] wrote:
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
Struts 2.0.x - WebWork transitional releases
Struts 2.1.x/3.0.x - The true successor to Struts and WebWork
Can number them this way instead? It seems more intuitive.
Struts 2.0 alpha/beta x -
Personally, I would love to, however the Struts PMC has voted successfully to
adopt the Tomcat/HTTPD naming scheme, which gives all releases a number [1].
While I am generally one to stir up trouble, this is a case where there was
considerable debate, a lot of time was taken, and finally a fair
Cool. I didn't realize there was so much process involved.
Bob
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
Personally, I would love to, however the Struts PMC has voted successfully
to
adopt the Tomcat/HTTPD naming scheme, which gives all releases a number
[1].
While I am generally one to
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
I think we should follow Tim's lead by using RetroTranslator, however, it
shouldn't hold up the 2.0.0 release.
I could finesse the 2.0.0 distribution, but I wonder if we are going
be able to make using RT a standard feature of the Maven assemblies
Yeah, exactly. It will probably involve using the antrun plugin, but unless
someone really wants to work on that right now, it'll have to be another entry
on the todo list.
Don
Ted Husted wrote:
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
I think we should follow Tim's lead by using
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
I'd love to be able to use a Maven plugin, like the Jetty one, to easily
test
the portlet w/o any extra installation. Using 'mvn jetty6:run-war is
just too
handy. This is one of my many personal todo projects :)
Don
I believe the Pluto 1.1
On 7/24/06, Ted Husted [EMAIL PROTECTED] wrote:
-1 on changing the versioning scheme.
But, I would be open to something like
* Struts 2.0 == WebWork transtional release
* Struts 2.1 == new API release
* Struts 3.x == phase 2 - the best of breed release
...with pointers on what to consider
Yeah, that is a step, but to really make it useful, it should work without
Tomcat and/or Pluto installed anywhere on the hard drive. The Jetty plugin
embeds Jetty so that no external files are needed.
Don
Nils-Helge Garli wrote:
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
I'd love to
+1
Hubert Rabago wrote:
On 7/24/06, Ted Husted [EMAIL PROTECTED] wrote:
-1 on changing the versioning scheme.
But, I would be open to something like
* Struts 2.0 == WebWork transtional release
* Struts 2.1 == new API release
* Struts 3.x == phase 2 - the best of breed release
...with
I would like to propose a versioning roadmap for Struts 2 and beyond.
* 2.0.x series == WebWork transitionary release
* 2.1.x series = New API release
* 3.x series = Best of breed/Phase 2 release
The proposal extends the original Ti proposal by adding a 2.1 series
to accomodate the API
I like it. If we can get a functioning implementation of the API in by Monday,
it goes in 2.0.x. Bob, please commit anything you have, as I'd like to help in
getting the API in there.
Don
Ted Husted wrote:
I would like to propose a versioning roadmap for Struts 2 and beyond.
* 2.0.x
On Mon, July 24, 2006 4:35 pm, Ted Husted wrote:
I would like to propose a versioning roadmap for Struts 2 and beyond.
* 2.0.x series == WebWork transitionary release
* 2.1.x series = New API release
* 3.x series = Best of breed/Phase 2 release
What's the reasoning behind jumping from
On 7/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
What's the reasoning behind jumping from 2.1.x to 3.x? I would have been
thinking 2.2(.x) instead of 3.x.
Going back to the Ti proposal, phase 2 is intended to be a major
jump, not an evolutionary refinement.
*
This sounds really helpful for current webwork users and the upcoming
struts 2.x community. +1 from my side.
Lots of efforts are currently taken to address changes and fixes in Struts
.x and backport them to webwork 2.2.3 and vice versa.
Therefore we should get out a Struts 2.0 alpha quality
As soon as webwork 2.2.3 is out I will concentrate my help on Struts 2.0.
I want to help in getting the new API implemented ASAP.
Rainer
I like it. If we can get a functioning implementation of the API in by
Monday,
it goes in 2.0.x. Bob, please commit anything you have, as I'd like to
Wendy, Ted,
I will ask Pat to send in a CLA. Which form does he need to sign?
Can you point me to the required CLA form please?
tia,
Rainer
On 7/22/06, Wendy Smoak [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=423995view=rev
Log:
XSLT Views + XML Mapping + HashMap
There's a link on the licenses page.
* http://apache.org/licenses/
It's the same one that committers file.
-Ted.
On 7/24/06, Rainer Hermanns [EMAIL PROTECTED] wrote:
Wendy, Ted,
I will ask Pat to send in a CLA. Which form does he need to sign?
Can you point me to the required CLA form
On Mon, 2006-07-24 at 16:35 -0400, Ted Husted wrote:
I would like to propose a versioning roadmap for Struts 2 and beyond.
* 2.0.x series == WebWork transitionary release
* 2.1.x series = New API release
* 3.x series = Best of breed/Phase 2 release
The proposal extends the original Ti
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ted Husted
Sent: 24. juli 2006 21:53
To: Struts Developers List
Subject: Re: [s2] Struts 2.0.0 - Tag it and Roll it?
-1 on changing the versioning scheme.
But, I would be open to something like
David Evans wrote:
I was looking in DefaultActionMapper and am wondering about the
compatibilityMode switch functionality. In getMapping compatibilityMode
is used to see whether to check for the ! method idiom. I assume this is
because it will eventually be removed because wildcard mappings make
On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote:
David Evans wrote:
I was looking in DefaultActionMapper and am wondering about the
compatibilityMode switch functionality. In getMapping compatibilityMode
is used to see whether to check for the ! method idiom. I assume this is
because
I think method:foo might still make sense. It's orthogonal to path
mappings. Maybe.
Bob
On 7/24/06, David Evans [EMAIL PROTECTED] wrote:
On Mon, 2006-07-24 at 15:15 -0700, Don Brown wrote:
David Evans wrote:
I was looking in DefaultActionMapper and am wondering about the
Potentially simple solution: a config switch to turn this functionality
on (the ability to specify method in the URL). It'd be off by default.
That way everyone can be happy... security hole closed, but easy to
activate for those who want it.
Frank
Don Brown wrote:
The problem is that
I agree it's a security concern, and it still is if the developer uses a
path pattern, except in the latter case, it's harder for us to secure.
I was hoping we'd store which methods are OK to invoke in the session or
sign them or something. For example, we could have tags like this:
s:link
From those that have been using it, I've heard retrotranslator was
more workable for this scenario. We have plugins for both retroweaver
and retrotranslator at mojo.codehaus.org:
http://mojo.codehaus.org/retrotranslator-maven-plugin/
Jason Dillon has been working on making that more functional
On 7/24/06, Don Brown [EMAIL PROTECTED] wrote:
The problem is that prefix allows anyone to specify the method to be called on
the action through the URL, any URL. I'd argue it is a security concern, so the
developer should have to work at explicitly allowing a method to be arbitrarily
called.
On 7/24/06, Brett Porter [EMAIL PROTECTED] wrote:
Is there a JIRA issue I can watch for this, or should I create one?
You could create one and, for extra credit, link it to the build issue. :)
-Ted.
-
To unsubscribe, e-mail:
If something like this was implemented, I'd hope that there would be a
way for those of us who use JSTL to still be able to specify method
names.
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ted Husted
Sent: 25. juli 2006 00:45
To: Struts Developers List
Subject: Re: [s2] Struts 2.0.0 - Tag it and Roll it?
On 7/24/06, Anders Steinlein [EMAIL PROTECTED] wrote:
IMHO, all the users,
On 7/24/06, David Evans [EMAIL PROTECTED] wrote:
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they don't want run by xwork private. Or maybe have an explicit
list of param
I'd much rather annotate methods which can be called than specify them in
XML.
Also, this doesn't pose much of a security risk in practice as it only
applies to public, no-arg methods which return String in actions.
Bob
On 7/24/06, Ted Husted [EMAIL PROTECTED] wrote:
On 7/24/06, Don Brown
On 7/24/06, Bob Lee [EMAIL PROTECTED] wrote:
I'd much rather annotate methods which can be called than specify them in
XML.
Feel free to do so then.
Also, this doesn't pose much of a security risk in practice as it only
applies to public, no-arg methods which return String in actions.
All
I require to use Struts Dyna forms and indexed properties for one of
my college projects.
At the moment this is proving more difficult than i thought it would.
Does anyone have any code that i can following in regards struts dyna forms
Any help would be greatly appreciated
Kind Regards
I'd much rather annotate methods which can be called
than specify them in
XML.
Also, this doesn't pose much of a security risk in
practice as it only
applies to public, no-arg methods which return String
in actions.
Bob
No-arg, yes, but it will convert anything else to a String on
On 7/24/06, Anders Steinlein [EMAIL PROTECTED] wrote:
I didn't mean to nag or sound negative, but I'm glad you plan to do
better. It isn't really the time between new features and bug fixes that
bother me much, it's the time they take to finalize and release. The
latest 1.3 releases have, to my
On Mon, 2006-07-24 at 21:27 -0400, Ted Husted wrote:
On 7/24/06, David Evans [EMAIL PROTECTED] wrote:
I understand the security concerns, but the flexibility is far more
important to me. If a user wants to protect themselves, they can make
methods they don't want run by xwork private. Or
62 matches
Mail list logo
