On 8/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I will add that to the bug report. Yes, those concerns have been
addressed because the approach is different then the original idea.
OK, then the only other thing I'd suggest is to work this into one of
the example apps, and update the relev
On 8/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
From the comments on the issue, it looks like Craig has some
> reservations about this idea. You might want to add a comment to the
> issue linking to the relevant mailing list thread(s) from November
> '05. Craig commented on the issue itse
From the comments on the issue, it looks like Craig has some
reservations about this idea. You might want to add a comment to the
issue linking to the relevant mailing list thread(s) from November
'05. Craig commented on the issue itself, but Martin must have
answered on the mailing list. Have
On 8/25/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I don't have any straight instructions on when it's appropriate to
commit code, and so I have provided a patch. If anyone wants to test it
out, please feel free. It works well for me both on the
ComposableRequestProcessor and the ol' RequestPr
I don't have any straight instructions on when it's appropriate to
commit code, and so I have provided a patch. If anyone wants to test it
out, please feel free. It works well for me both on the
ComposableRequestProcessor and the ol' RequestProcessor.
What's the next steps?
Paul
--- Begin Mes
On 8/25/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
If we can do it with Ant, we should be able to do it as part of the
Maven build, using maven-antrun-plugin. So if someone can come up
with that simple Ant build file, I'll try to integrate it in the Maven
build. Shouldn't we be able to find it
On 8/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
The simplest thing might be to setup a very simple Ant build file that
just called XDoclet to create the TLD. Then everything else falls into
place. If we need to call it as a separate process for now, then so be
it. I expect that eventually XDoc
OK, I've parred down the TODO list for 2.0.0
* https://issues.apache.org/struts/secure/IssueNavigator.jspa
The biggest stumbling block is the taglib documentation. I
experimented with the maven-taglib plugin, but I just don't think it
is going to work for us (or at least me).
The plugin would e
On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
What were you meaning by removing the deprecation?
Deprecation means that we may remove the behavior in favor of a
preferred alternative. That's very different from making the behavior
switchable. Right now, we don't have a preferred alternative,
That's my fault; I thought by saying to remove the deprecation, you
meant the backwards-compat stuff, which includes the deprecation of tag
attributes and code in the mapper. What were you meaning by removing
the deprecation?
Don
Ted Husted wrote:
On 8/25/06, Patrick Lightbody <[EMAIL PROTE
On 8/25/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Done.
Ummm, first, when we call for a vote, we try to wait 72 hours before
taking action, to give every one time to weigh in.
Second, the vote was about whether to enable or disable the switch by
default, not whether we were going to rip
Jason Carreira wrote:
...unless you really want to take the security
exercise all the way,
i.e., secure each and every method via
container-managed security using
annotations (ideally) to configure what roles/users
can access what
methods, thereby taking the URI out of the equation
entirely...
On 8/24/06, James Mitchell <[EMAIL PROTECTED]> wrote:
Ok, good to go.
Cheers.
John Fallows.
--
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Done.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=41363&messageID=82541#82541
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For ad
On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
I think it's problematic to try to specify things like action methods in the
XML file. Keep in
mind that there's the JSR-303 spec that's getting started up to deal with
validation in a
completely environment-agnostic way. It's not going to
> Ted,
> My opinion on this is that the ! syntax should be
> used strictly as a URL pattern and not anywhere else.
> That means we shouldn't name files like
> foo!bar-validation.xml, but instead figure out
> another way to map it to a context.
>
> Currently, you can name those files
> "foo-bar-val
> ...unless you really want to take the security
> exercise all the way,
> i.e., secure each and every method via
> container-managed security using
> annotations (ideally) to configure what roles/users
> can access what
> methods, thereby taking the URI out of the equation
> entirely... if you
Agreed.
> On 8/25/06, Patrick Lightbody
> <[EMAIL PROTECTED]> wrote:
> > Make sense?
>
> Yes. Since the validation files are acting like
> code-behinds, being
> able to bind to a code artifact, like the method,
> does make sense to
> me. I can understand why we would also want to bind
> to the
>
On 8/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/25/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> It's interesting that no one says DispatchAction in 1.x is a security
> flaw... doesn't that give you exactly the same thing just with a
> different call semantic? I guess we shou
I believe DWR too has a similar concern, conceptually. They have some
configuration parameters to deal with it. I wonder though if my
suggestion about securing all methods maybe isn't all that wacky?
Step 1... let's say we have a silly XML file like so:
user1,user2
user2
On 8/25/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Make sense?
Yes. Since the validation files are acting like code-behinds, being
able to bind to a code artifact, like the method, does make sense to
me. I can understand why we would also want to bind to the
action/context, but *not* bein
On 8/25/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
It's interesting that no one says DispatchAction in 1.x is a security
flaw... doesn't that give you exactly the same thing just with a
different call semantic? I guess we should quick drop Dispatch-type
Actions for everyones' safety!! ;)
Fine - I propose the branch be named "Able".
Don
Ted Husted wrote:
+1
But let's not label it the "2.1" branch. Last I knew, we observed the
Rules for Revolutionaries
* http://incubator.apache.org/learn/rules-for-revolutionaries.html
which says that we should name the branch first, and then d
+1
But let's not label it the "2.1" branch. Last I knew, we observed the
Rules for Revolutionaries
* http://incubator.apache.org/learn/rules-for-revolutionaries.html
which says that we should name the branch first, and then decide
whether to accept it, or what version to assign, once there is a
Ted,
My opinion on this is that the ! syntax should be used strictly as a URL
pattern and not anywhere else. That means we shouldn't name files like
foo!bar-validation.xml, but instead figure out another way to map it to a
context.
Currently, you can name those files "foo-bar-validation.xml" wh
That's fine with me. Patrick, I believe you were itching to backout my
deprecation changes? ;)
Don
Ted Husted wrote:
On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
Yes, the "!" is "deprecated" for now, but we can
un-deprecate it later if we decide to.
Let's undeprecate it now. There's n
I agree to a degree, however, it is inevitable that a lot of resources
that would be used in moving the code forward are absorbed by these
"discussions", and generally, the folks with the energy and vision to
move forward don't have the patience for drawn out detail discussions.
While ideally,
-1 - don't depreciate, leave enabled
Given that there is still a lot to discuss I think we should leave it
enabled.
/Ian
Ted Husted wrote:
On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
And I'm all for those (or similar ideas). I think everyone is for
those, or at least one or the
o
On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
Yes, the "!" is "deprecated" for now, but we can
un-deprecate it later if we decide to.
Let's undeprecate it now. There's nothing in the code or documentation
that says it's deprecated. Once we are sure there is an alternative,
we can deprecate
On 8/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Agreed. But I want to start shipping tagged builds of the framework
this weekend, and so we need to decide what to do right now, today.
-1
We have to put this in perspective.
First, disabling by default doesn't address the "method:xxx" param
It's interesting that no one says DispatchAction in 1.x is a security
flaw... doesn't that give you exactly the same thing just with a
different call semantic? I guess we should quick drop Dispatch-type
Actions for everyones' safety!! ;) LOL
I'm with you Ian... doesn't seem like a security fl
Agreed as well. In that case, I say we leave it and move on with things
the way they are. Yes, the "!" is "deprecated" for now, but we can
un-deprecate it later if we decide to. Webwork has worked fine with the
"!" in the past, so let's trust in its success for this release. We can
re-evalu
On 8/25/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Goal: It should be our goal to ship Struts in a way that it is pre-configured
with default
settings that mimic the agreed upon styles and techniques by the very
best Struts users
and developers.
Hmmm, how do we determine who are the "v
On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
I just sense we are getting bogged down in little details and bickering
over them won't move us forward or even result in a half-way useful and
cohesive framework.
Agreed. But I want to start shipping tagged builds of the framework
this weekend,
I cannot underscore how much of a mistake this would be. I would vigorously
fight this decision to keep it off by default for a long time. I'm happy to put
more constraints on the ability to invoke methods via the HTTP request, but I
will not support turning it off by default. See my mini manife
I haven't been following this too closely, but I'm pretty sure this vote
doesn't really tackle the core issues. For example, if we were really
against the ability to specify a method in a url directly, we would
remove the method: prefix, which would break several of the tags.
I wonder if inst
Hi, guys, would you please move me out of the group? I tried to email to
[EMAIL PROTECTED], but it doesn't work.
Please and Thanks.
From: Jason Carreira <[EMAIL PROTECTED]>
Reply-To: dev@struts.apache.org
To: dev@struts.apache.org
Subject: Re: [s2] Action ! Method syntax (was Freemarker tran
> I'm not 100% sure how that one works... does it
> depend on "!" somehow? I've been stuck on an older
> release of WebWork for a while...
foo!bar.action is the same thing as foo.action?method:bar=whatever
It is defined in DefaultActionMapper.
-
>
> My understanding was that wildcards was much more
> about reducing configuration and introducing
> conventions rather than addressing any perceived
> issues about multiple entry points on the action.
>
You say "multiple entry points on the action" like you can't have that without
the "!" n
On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
And I'm all for those (or similar ideas). I think everyone is for those, or at
least one or the
other. The problem is for the current release. The one where people don't want
to wait for
those new features. The "!" syntax is still in that on
Related to the ! thread, but a more general concept that I want to bring up and
underscore. This is my mini manifesto on why we can't treat the default options
and settings in Struts lightly. These are all my opinions, but I think they are
also fairly common sense.
Goal: It should be our goal t
On 8/25/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
I've also used the ! notation extensively, and am disappointed that it
is being removed.
No one ever suggested that it be removed. It's been suggested that we
try to replicate the same functionality with wildcards. I tried it
myself in an exam
>
> Christ - I have proposed things, many times. Why are
> the words "annotations" and "convention" being
> ignored by everyone. Let's try one more time.
>
> 1) Convention-based protection: only allow methods of
> the form "String doXxx()" to be called via the
> request.
> 2) Annotation-based pro
On 8/25/06, Nick Hill <[EMAIL PROTECTED]> wrote:
As a heavy user of webwork, I must say that I have to agree with Patrick in
this case. Our
xml config file is already enormous and having to duplicate definitions for
different
methods of the same action would be a real mess. I don't really care
On 8/25/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
I have to say that I still don't really understand why this is a
security flaw. I can understand that calling any public method on a
class may not be a good thing, but let's face it, actions are *meant* to
be called via a URL. If there is a s
> Just to step back a moment, let's be clear that the
> original
> suggestion, which stemmed from the "Rough Spots"
> discussion, was that
> we experiment with using wildcards to provide the
> same functionality
> as the "!" syntax. If that experiment provided
> fruitful, we would
> then, only only
I've also used the ! notation extensively, and am disappointed that it
is being removed. I find that the 1-1 mapping from the URL to the
method on an action is simple to follow and easy to understand.
One thing that I have not seen any mention of yet is conflicting
mappings - what happens? Wh
> Following up to myself: I want to also make it
> clear
> > that I'm not opposed to changing my way of doing
> > things, but so far I haven't seen anything that
> seems
> > any better than what I'm doing now. I'm happy to
> > explain more about how the ! syntax is used with
> all
> > my forms, so
Also, in regard to security, we can require that methods invoked with the !
convention have a @Public annotation or something. Method explicitly listed
in the struts.xml won't need this annotation.
Wildcards will make it harder to differentiate these two cases. You could
argue that you don't need
I am one of the engineers at Jive Software (the company that provides these
forums for opensymphony) and we use the ! method syntax all over the place. As
an example, when you are replying to this post, note the post!reply.jspa url.
As a heavy user of webwork, I must say that I have to agree wit
On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
>
> Following up to myself: I want to also make it clear
> that I'm not opposed to changing my way of doing
> things, but so far I haven't seen anything that seems
> any better than what I'm doing now. I'm happy to
> explain more about how the
>
> Following up to myself: I want to also make it clear
> that I'm not opposed to changing my way of doing
> things, but so far I haven't seen anything that seems
> any better than what I'm doing now. I'm happy to
> explain more about how the ! syntax is used with all
> my forms, so that alternat
On 8/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
At this point, I'm uncertain as to how to proceed.
I have to dash, but, for S2, one approach just occurred to me.
The missing part in S2 is XDoclet generating a nominal TLD, for IDEs
and whatnot to use.
Moving forward, we might be able to use
On 8/24/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I noticed on the Struts 1.3 web site, the reference guide for the tag
libraries do not have any descriptions. Is this a problem with the
current Maven 2 plug-in?
They have descriptions, it's just that the plugin is not rendering the
content c
54 matches
Mail list logo
