I'll send the source for our gxp result on mon.
On Jul 26, 2008 12:03 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
Possible DoS? Isn't this a remote exploit? Can you call arbitrary methods?
Bob
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
some simple testing shows that the field value is simply evaluated...
try to put on a struts textfield %{1+1} submit and you'll get 2 on
the field...
Cool
On 7/5/07, Ing. Andrea Vettori [EMAIL PROTECTED] wrote:
The DoS is because you can trigger an infinite loop.
My point is, can you execute arbitrary code on the server? If so, a DoS is
the least of your worries.
Bob
Are you using the Guice Struts 2 plugin? I didn't realize Struts 2 would
delegate to the ObjectFactory to create an int[].
Bob
On 4/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I'm playing around with Guice as an ObjectFactory and I've run into an
issue. I've got an action that I want to
It's in the upcoming 1.0rc3. If you want a sneak peek, check out the code
and run ant dist.
Bob
On 3/4/07, Allen Iverson [EMAIL PROTECTED] wrote:
There's a annotation type ImplementedBy in online doc but I can't find
and
use it in 1.0rc2 jar, is it deprecated?
regards
--
View this message
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
U, strictly speaking, that's still code. ;)
Strictly speaking yes. But it is externalized and
does not impose anything on used classes.
It imposes something on me, the programmer.
What if I like to use another session impl in
On 2/27/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
Pico approach at least leaves your managed classes
alone.
Right, and Guice supports both approaches (the external approach via custom
providers which are roughly equivalent to Pico's external configuration).
Strictly speaking, pico
You're right. Sorry for the noise.
On 2/27/07, Ted Husted [EMAIL PROTECTED] wrote:
Perhaps a better venue for this discussion would be the Guide
developers mailing list.
* http://groups.google.com/group/google-guice
-Ted.
-
On 2/27/07, Dave Newton [EMAIL PROTECTED] wrote:
But... we'll miss the fisticuffs.
Not if you sign up for the Guice mailing list. :)
Konstantin, you're more than welcome to try peddling Pico on our list. ;)
Bob
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
I would ask why to prefer guice over
pico/nanocontainer instead ;)
Type checking, performance, documentation, less code, generic types support,
cleaner configuration (Guice uses a nice EDSL), no setter method
requirement, up front
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
Hi Bob,
I'd like to say that I'm codeveloper of
pico/nanocontainer.
I've used Pico and Nano. Nano uses my AOP framework. You should try Guice.
What's important is that you don't depend on the
implementation. Depending
on the
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
Using these key objects is more verbose than using
annotations with Guice.
Not necessarily. There are no references to keys in
my code, only in container buildup. And only in
cases where this is necessary.
My point still holds
On 2/26/07, Bob Lee [EMAIL PROTECTED] wrote:
bind(Session.class)
.annotatedWith(Secure.class)
.to(FailoverSessionDelegator.class);
Then apply @Inject @Secure wherever you want a secure Session. You can
obviously reuse the @Secure annotation elsewhere, too.
If I were to really implement
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
If S2 architecture is the same than WW2, then it is
not necessary to register it as plugin - it's just an
object factory and couple of filters ( which are
independet of S2/WW )
XWork 2 uses an older version of Guice to wire together
On 2/26/07, Konstantin Priblouda [EMAIL PROTECTED] wrote:
My point still holds true--Pico requires more code
than Guice.
Structly speaking using pico in a webapp requires no
code at all (except of course container configuration
in xml or whatever else)
U, strictly speaking, that's
Guice has come along way since we copied the source over into XWork. If
anyone would like to try out Guice with Struts 2.0.6, we've included a
plugin jar in the latest distribution:
http://google-guice.googlecode.com/files/guice-1.0rc2.zip
And instructions for using Guice with Struts 2 in the
annotation. I guess my
question is why would someone prefer Guice support over Spring? I read
the Why Guice? section, but I didn't see this question.
Paul
Bob Lee wrote:
Guice has come along way since we copied the source over into XWork. If
anyone would like to try out Guice with Struts 2.0.6
I'm seeing some test failures in Struts 2 head. It's difficult to tell what
exactly is failing with all the log output. Should we disable test log
output?
Bob
We can bring it back easily when we're ready to finish implementing it.
Bob
I'm cool with that. I'm not going to finish it by this weekend--I'm working
feverishly toward a Guice release, and I plan on using Guice in the API
anyway (we won't need *Aware interfaces).
Bob
On 2/1/07, Ted Husted [EMAIL PROTECTED] wrote:
I tend to agree. Unless someone says they are ready,
We've been running WebWork 2 in quite a few production applications for a
couple years and have seen no related performance problems. And we're very
particular about performance. I wouldn't worry about it.
Bob
On 1/17/07, Shekhar Yadav [EMAIL PROTECTED] wrote:
Is there a plan on when the
On 1/18/07, Ted Husted [EMAIL PROTECTED] wrote:
(And hopefully some of those will
lend us a hand. Even with the merge, we still don't have more active
committers than we had a year ago.)
Sorry, Ted--I really should contribute more. I've been investing a lot of
time in Guice.
Bob
Any idea what would trigger this? We don't use continuations.
java.lang.NullPointerException
com.opensymphony.xwork.DefaultActionInvocation.prepareContinuation(
DefaultActionInvocation.java:248)
com.opensymphony.xwork.DefaultActionInvocation.createAction(
DefaultActionInvocation.java:236)
are not simple java properties. It's a pity. I was looking forward to
using
Struts 2 on our next major project but much like JSF it is too risky from
a
performance perspective.
Back to Struts 1 ... *sigh*
Bob Lee wrote:
We noticed the same thing. Maybe we should replace it with JSP-EL? (I
don't
have time
* than [EMAIL PROTECTED] OgnlValueStack}. Unlike [EMAIL PROTECTED]
OgnlValueStack}, this
* implementation does not eat exceptions when finding values.
*
* @author [EMAIL PROTECTED] (Bob Lee)
*/
public class FastValueStack extends OgnlValueStack {
static final Object NOT_FOUND = new Object
Thanks, everyone, for the encouragement.
Guice is still very much in the early stages, and I'm trying not to draw too
much attention/scrutiny at this point. Guice is usable though. In fact,
we've been running it in production for a couple release cycles now.
Check out the issue tracker to see
Great idea. +1
On 9/11/06, Don Brown [EMAIL PROTECTED] wrote:
The way I propose to solve this problem is to implement Framework
Plugins. A framework plugin is a jar that contains framework extension
classes and configuration, which only need to be dropped into the
classpath to be activated.
A
On 9/6/06, Martin Cooper [EMAIL PROTECTED] wrote:
This sounds to me like a rather blatant mis-use of actions. In the first
place, as Michael points out, action chaining has always been an
anti-pattern in Struts. As such, I'd be against promoting / encouraging the
use of chaining in the way you
I've needed this, too. You should be able to implement it with an
interceptor. Apply the interceptor globally to all your actions. If
the current action has a private parameter, the interceptor can
verify that it's being entered a second time (i.e., the first time was
through a public action
We should actually make it work like interceptors do: don't check for
the class until the user actually tries to use the result type. If the
user tries to use it and we don't have the class, don't just log a
warning: blow up with an exception.
Bob
On 8/30/06, Ted Husted [EMAIL PROTECTED] wrote:
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
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
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
On 8/24/06, Jason Carreira [EMAIL PROTECTED] wrote:
I disagree here because the URL mapping is more likely to change than the
namespace / actionName mapping. Consider if you leave the namespace empty
and just give an action name, it will assume the same namespace. Now if you
change the
We use the ! syntax, and I'd really like something more secure to replace
it (store valid methods in the session, signed URLs, something), but I'm OK
with defaulting the flag to off.
Bob
On 8/24/06, Jason Carreira [EMAIL PROTECTED] wrote:
First off: we're *not* deprecating and removing the
On 8/22/06, Ted Husted [EMAIL PROTECTED] wrote:
Say, wasn't there a mention of some package that renamed packages
dynamically or something? That's the real issue. Two versions of the
same package name on the same classpath.
jarjar
In the case of logging though, we should just use
help us solve the xwork version problem nicely.
Don
Bob Lee wrote:
On 8/22/06, Ted Husted [EMAIL PROTECTED] wrote:
Say, wasn't there a mention of some package that renamed packages
dynamically or something? That's the real issue. Two versions of the
same package name on the same classpath
On 8/22/06, Don Brown [EMAIL PROTECTED] wrote:
Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of
rather see us write a small, clean API along the lines of Seam's
logging class that utilizes varargs to reduce the need for
isDebugEnabled().
http://docs.jboss.com/seam/latest/reference/en/html/
concepts.html#d0e2598
Don
Bob Lee wrote:
How is j.u.logging overkill, especially considering
product: #1 quantity: #2,
user.username(), product.name(), quantity);
return new Order(user, product, quantity);
}
Considering how often we log things, I think the cleanup is huge and a
few classes are definitely worth the price.
Don
Bob Lee wrote:
On 8/22/06, Don Brown [EMAIL PROTECTED] wrote
On 8/22/06, Don Brown [EMAIL PROTECTED] wrote:
Well, I don't think adding external deps was ever on the table as the
discussion was prompted by wanting to get rid of them :) I'm fine with
extending j.u.logging, but would plan to add isDebugEnabled and debug
methods :)
Sounds great.
On 8/22/06, Tim Fennell [EMAIL PROTECTED] wrote:
log.debug(And the answer is: , myBigObject, (didn't you
guess?).);
I like that.
On 7/26/06, Jason Carreira [EMAIL PROTECTED] wrote:
I understand that there are different ways to skin the cat, but what if I
want to reuse my actions in different contexts? What if I want to call my
action from a JBPM workflow? Do I need to subclass it to override the result
that's returned?
Instead of returning a Result object, we can also consider calling out to a
result method. This is how Rails works. For example:
class FooAction ... {
Foo foo = new Foo(); // populated from request parameters.
public void create() {
if (foo.isValid())
redirectTo(ListFoos);
else
+1 for @Action
On 7/25/06, Jason Carreira [EMAIL PROTECTED] wrote:
Works for me. What should we call this annotation?
@Published?
@Action to mark it as an Action method?
-
Posted via Jive Forums
On 7/25/06, Jason Carreira [EMAIL PROTECTED] wrote:
What happened to not coupling code to the framework?
That's one of many factors that should impact a design decision.
Oh please no... please no abstract methods with magic implementations. What
happens when you go to debug the class?
The
On 7/25/06, Don Brown [EMAIL PROTECTED] wrote:
action name=invoice/*
class=com.eplus.app.invoice.action.InvoiceCrudAction method={1}
result name=list
type=freemarker/template/eplus/metaDataList.ftl/result
...
/action
Or:
action name=invoice/{method}
/* and {1} pair.
rgds
- Original Message
From: Bob Lee [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Wednesday, 26 July, 2006 12:01:50 PM
Subject: Re: Returning Result directly (was Re: DefaultActionMapper
compatablity
On 7/25/06, Don Brown [EMAIL PROTECTED] wrote
} and {method} pair, does
the current implementation of Struts2 wildcard supports this? Looks a lot
more clearer than the invoice/* and {1} pair.
rgds
- Original Message
From: Bob Lee [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Wednesday, 26 July, 2006
advanced cases. That said, I'm open to changing the default
wildcard pattern style if we find one that is more powerful, yet still
easy and intuitive.
Don
Bob Lee wrote:
{foo*} could match slashes. Or {/foo}. Or {{foo}}.
We could also use regular expressions--they support this sort of group
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
to stir up trouble, this is a case where there
was
considerable debate, a lot of time was taken, and finally a fair vote was
passed. I feel we have much more important things to do than revisit old
arguments, however I may disagree with their outcome.
Don
Bob Lee wrote:
On 7/24/06, Don Brown [EMAIL
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
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 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
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
If we want to tag now, the new API will have to wait for 3.0.
Bob
On 7/23/06, David Evans [EMAIL PROTECTED] wrote:
Hello,
I've downloaded the struts-2.0.0-SNAPSHOT-all.zip and had a look at its
contents. I'm wondering what the relationship is between this
struts-2.0.0 and the API published
Anyone know what's causing this? I grepped for com.opensymphony.xwork. and
ConfigurationProvider but the culprit wasn't immediately clear.
---
T E S T S
---
java.lang.NoClassDefFoundError:
Pat documented it here:
http://confluence.twdata.org/display/WW/Building+with+Maven
On 7/2/06, Jason Carreira [EMAIL PROTECTED] wrote:
Can someone add to that page the instructions for setting up Idea projects
and especially the magic incantation needed for it to build one for XWork if
you've
Missing AbstractInterceptor. Anybody have any clues?
Bob
+1 for Struts 2.0
Bob
On 6/28/06, Don Brown [EMAIL PROTECTED] wrote:
With the departure of Struts Shale, I think it is time we return to the
idea of
Struts as a single, unified framework. While I had hoped we could do this
by
including Shale, everyone involved felt Shale deserved its own
I've run into this problem with OGNL where I want it to invoke a setter, but
if there's a getter method with the same property name but a different type,
OGNL will just fail silently. Why does it even care about the getter? Anyone
have an idea of what's going on here?
I'm working against the
and setters to be well formed java
beans. Although I never took the time to look into it further.
/Ian
Bob Lee wrote:
I've run into this problem with OGNL where I want it to invoke a
setter, but
if there's a getter method with the same property name but a different
type,
OGNL will just fail
You can use GWT standalone, but it also makes sense to use it for rich
components embedded in a normal web page. For example, you could use
it to implement an AJAX table component which can sort columns and
page-by-page iterate.
As for using XWork on the server side, I personally wouldn't do it
I did think about it, and it's not logical. Why do I want to lump getters
and setters together to fit some artificial notion of a property? The
answer is I don't. I don't think there's a justification for doing so that
matters to users, and there are plenty of reason for a getter and setter to
I don't use them.
On 6/19/06, Jason Carreira [EMAIL PROTECTED] wrote:
I see your concern.
I don't use doXXX and extends my custom interceptor
off Interceptor interface, so it wouldn't be of any
impact to me, but I am not sure about other WebWork
users.
Since this is a SAF2 release, I'd
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
On 6/13/06, Don Brown [EMAIL PROTECTED] wrote:
What about doing what Sun does with Xalan for Java 5 and rename XWork
packages? With the changes we are making to XWork 2.0, I don't think
it will co-exist with WebWork 2.2.2/3
It's a tool though, so it won't be distrubuted. If it's a big issue,
I'm sure we can talk Chris into something. Chris?
Bob
On 6/13/06, Don Brown [EMAIL PROTECTED] wrote:
Very tempting if it wasn't GPL :(
Don
Bob Lee wrote:
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
I finally understand wildcards! Can you give an example of using more
than one wildcard in an action name?
Bob
On 6/11/06, Don Brown [EMAIL PROTECTED] wrote:
With XWork now supporting wildcards in xwork.xml, I think it is time to
remove the explicit support for the fooAction!barMethod.action
Don, this is *very* interesting. Nice work. I've been wondering for a
while if we could reuse off-the-shelf JSF components. It looks like
you may have figured out how!
It also proves that you can think of the JSF lifecycle as a more
complex, higher level of abstraction of our interceptor
I've attached a patch with the API updates we discussed last week. I
also fixed the Maven build to correctly build the API again.
The latest Javadocs are here: http://www.crazybob.org/javadoc/
Thanks,
Bob
-
To unsubscribe,
Doh. Here it is:
http://issues.apache.org/struts/browse/WW-1314
Bob
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote:
The list won't accept attachments. You should open a JIRA ticket instead.
-Te.d
On 5/16/06, Bob Lee [EMAIL PROTECTED] wrote:
I've attached a patch with the API updates we
We've been cleaning up and reorganizing the API to make it more
intuitive and user friendly. Any feedback is much appreciated.
Bob
On 5/16/06, Paul Benedict [EMAIL PROTECTED] wrote:
I don't remember an SPI being part of WW. Is this new to Action 2?
--- Bob Lee [EMAIL PROTECTED] wrote:
I've
Don't worry, David. We're just talking about cleaning up the API and
making your code a little cleaner. It's fundamentally the same
framework with the same philosophies.
Bob
On 5/5/06, David Evans [EMAIL PROTECTED] wrote:
I am a struts user who has recently began programming in webwork, to get
On 5/6/06, Jason Carreira [EMAIL PROTECTED] wrote:
Maybe the same philosophies, but the API you laid out is very different for
users of the framework...
Let's not exaggerate the impact of the API on user code though...
Users record validation errors a little differently; you should be
able
suggestions?
Bob
On 5/5/06, Don Brown [EMAIL PROTECTED] wrote:
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish
I'm cool with that. Sticking with verbs, there's also err(), warn(),
inform(). ;)
Bob
On 5/5/06, Jason Carreira [EMAIL PROTECTED] wrote:
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier (to
On 5/4/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 5/4/06, Claus Ibsen [EMAIL PROTECTED] wrote:
The JDK1.5 api looks really great.
I'm not native english but is this interface name correct?
Validatable
Should it not be?
Validateable
Neither of these is an English word... ;-)
Yeah,
On 5/4/06, Eric Molitor [EMAIL PROTECTED] wrote:
In regards to the implementation of the API where did ResponseAware
go?
org.apache.struts.action2.servlet.ServletResponseAware
I put these interfaces in a sub package because users should avoid
creating dependencies on the servlet API in their
We're using WebWork 2.2 heavily on a handful of projects (OK, a big
handful of big projects), so I definitely understand the concerns.
I didn't mean to shock anyone. I thought my point of view was clear
based on the introduction to the Rough Spots page
(http://wiki.apache.org/struts/RoughSpots)
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown [EMAIL PROTECTED] wrote:
Don Brown wrote:
re-education of developers. I want Struts Action Framework 2 to be
As much as I love shorter names, I still think struts-action is more
user friendly. I see struts and immediately know what the file is. I
can't say the same for action; it's missing an important namespace
qualifier.
If anything, I would shorten it to struts.xml, but like we said
before, we could
+1
On 5/1/06, Don Brown [EMAIL PROTECTED] wrote:
I agree - I think we should break this document down into JIRA tickets and
track the discussion there. When we meet at
the JavaOne BOF, we can discuss the tickets and their fix schedules further.
Don
Patrick Lightbody wrote:
I propose that
That would be awesome.
Bob
On 5/1/06, Jason Carreira [EMAIL PROTECTED] wrote:
Speaking of which, I was planning on doing some work on XWork configuration
refactoring and making it runtime changeable along with removing some
singletons on my flights to SFO for JavaOne... Any objections?
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'm not sure two major releases is what's best for users.
- If SAF2 is going to be the same as WW2, why have it at all? I think
it will confuse users unnecessarily.
- We'll be stuck supporting WW2, SAF2, and SAF3 instead of just WW2 and SAF2.
- Some users will migrate to SAF2 and then will have
annotation
support in 2.1, for example, is a more
realistic goal, than trying to quickly get it down and push it in for the
August release.
Don
Bob Lee wrote:
I'm not sure two major releases is what's best for users.
- If SAF2 is going to be the same as WW2, why have it at all? I think
+1 to that.
Bob
On 4/24/06, Don Brown [EMAIL PROTECTED] wrote:
Craig McClanahan wrote:
I think a better strategy would be to have the core framework depend solely
on 1.4, but provide an optional layer on top which leverages 1.5 things for
those who actually do have a 1.5 runtime
http://issues.apache.org/struts/browse/WW-1296
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fix for broken option transfer select tag tests
---
Key: WW-1296
URL: http://issues.apache.org/struts/browse/WW-1296
Project: Struts Action 2
Type: Task
Reporter: Bob Lee
Attachments: brokenTest.patch
[ http://issues.apache.org/struts/browse/WW-1296?page=all ]
Bob Lee updated WW-1296:
Attachment: brokenTest.patch
Fix for broken option transfer select tag tests
---
Key: WW-1296
URL: http
[EMAIL PROTECTED] wrote:
Who did this edit? It says by Bob Lee but one of the comments is tagged as
hani
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26827messageID=52884#52884
I vote for struts-action.xml.
Bob
On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote:
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer action-default.xml to struts-default.xml
is that we want
On 4/19/06, Patrick Lightbody [EMAIL PROTECTED] wrote:
1) Drop XW directly in to WW (ie: fork). This is Bob's proposal.
Just to clarify what I already said on the wiki page, I propose that
we make XWork an implementation detail, not part of our API. This
means creating a thin abstraction layer
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote:
This doesn't concern XWork itself.
Huh? I thought we were talking about moving it?
I didn't say anything about moving it.
Okay, so make your Action implement ServletContextAware, ServletRequestAware,
etc.
I was specifically thinking
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote:
Ahh, you're talking about forking it and copying the source into Struts
Action 2?
No... but I do think we should shield Struts users from the XWork
API/documentation as much as possible (i.e. a lot more than WebWork
does). I _suppose_ it's
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote:
I would tend to disagree. I feel that the separate of concerns between
XWork and a web application front end are important. I don't believe
it would be helpful to start lumping things back together again.
Providing Struts users with a complete,
You mean we have committers who aren't running 1.5 yet? For shame. ;)
I'll set up the rough spots page.
Bob
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote:
When a committer votes +1 on a release, it's taken to mean that the
committer is using the release in production his or herself, and that
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
I'll set up the rough spots page.
http://wiki.apache.org/struts/RoughSpots?action=show
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
I'll buy that, but users should understand that malicious users can
put HTML like this on other sites:
img src=http://yoursite/deleteAccount;
That's not to say that POSTs are 100% immune to this sort of thing.
They're just slightly less susceptible. The safe solution is to emded
some sort of
1 - 100 of 103 matches
Mail list logo
