On 7/22/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> I really don't like calling action a handler. Well yes, it is a
> request handler, but I would like to reserve "handler" as in "event
> handler" for dispatch action methods. Also, ASP.NET
On 7/4/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
It's time to release version 3 of the struts-master pom:
[RESULT]
+1 Wendy, James, Don
I'll get this deployed to ibiblio.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECT
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 privat
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
This is a question best suited for the user list, where there are more
people to help.
* http://struts.apache.org/mail.html
On 7/23/06, Damien Gallagher <[EMAIL PROTECTED]> wrote:
All
I require to use Struts Dyna forms and indexed properties for one of
my college projects.
At the moment this
> 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 S
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
Da
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.
Goi
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, 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 this,that,theOther.
The fr
> -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 th
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 d
done and done (WW-1391)
On 25/07/06, Ted Husted <[EMAIL PROTECTED]> wrote:
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.
---
On 7/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
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 w
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
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.
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
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:
...
Update
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 pre
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.
Don
Bob Lee wrote:
I think "method:foo" migh
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
> > compatib
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
> > b
On 7/24/06, Anders Steinlein <[EMAIL PROTECTED]> wrote:
> IMHO, all the users, including ourselves, are served best
> when we release early and release often.
Isn't this kind of ironic you repeating this over and over again given
the state of the 1.3 release?
(Yes, I know a vote is pending, but
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
> -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 someth
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
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 plea
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=423995&view=rev
>> > Log:
>> > XSLT Views + XML Mapping + Ha
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
>
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 relea
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.
* http://wiki.apache.org/
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 jumpin
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 series
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 cha
+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"
...wi
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
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 con
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
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 Re
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 assemblie
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
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
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 -
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 2.0/2.0.x/2.x.
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, b
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 thin
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
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:
Hone
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 bot
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 th
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
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/
--
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 st
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-leve
> 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
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 are still co
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, an
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 t
> 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
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 stab
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:
* http://www.twdata.org/backups/WW/portlet-tutori
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 templa
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=38227&messageID=75314#75314
---
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
http://forums.opensymph
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 ab
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
> 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 d
:) 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 PROTECTED
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 a
70 matches
Mail list logo
