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
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
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...
Coo
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 mess
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
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, 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
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
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
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 togethe
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
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 hold
There is documentation: http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8
Bob
On 2/26/07, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
On 2/26/07, Bob Lee <[EMAIL PROTECTED]> wrote:
> On 2/26/07, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
> >
> > Hi
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 in
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 e
pring has a @Required 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 l
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 use
We can bring it back easily when we're ready to finish implementing it.
Bob
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
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
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
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 per
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)
com.
I wouldn't jump straight to a bytecode solution, there's no reason it should
be that much faster than a well-designed plain Java solution.
Bob
On 12/13/06, Jessek <[EMAIL PROTECTED]> wrote:
Last time I'll interrupt your normal dev cycle I promise.
Since it seems we are both equally screwed i
mplates which
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 re
his is an order of magnitude
faster
* 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
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 wh
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.
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 whi
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
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
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
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
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
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 removi
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 namespa
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
log.debug("And the answer is: ", myBigObject, " (didn't you
guess?).");
I like that.
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.
) {
log.debug("Creating new order for user: #0 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.
bly designed, obtuse API. I'd
> 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
>
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
Velocity's
logging classes. It would 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&#x
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 java.util
On 8/20/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Hopefully, for 2.0.1, we can have an implementation of the new API, so
that we can start phasing that in as the default API for 2.1.
The new API is actually about 90% implemented and checked in, though it
still needs to be hooked in.
Bob
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?
switch in a new impl easily
for more 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 r
ndlers.
Don
tm jee wrote:
> Just out of curiosity, the "invoice/{method}" and "{method}" pair, does
the current implementation of Struts2 wildcard supports this? Looks a lot
more clearer than the "invoice/*" and "{1}" pair.
>
> rgds
>
> - Ori
oks a lot
more clearer than the "invoice/*" and "{1}" pair.
rgds
- Original Message
From: Bob Lee <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Wednesday, 26 July, 2006 12:01:50 PM
Subject: Re: Returning Result directly (was Re: DefaultActionMapper
comp
On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
/template/eplus/metaDataList.ftl
...
Or:
/template/eplus/metaDataList.ftl
...
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
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?
Th
+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
http://forums.opensy
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
On 7/25/06, Don Brown <[EMAIL PROTECTED]> wrote:
In the future, I could see an interceptor that checks the method specified
for a
method-level annotation, and only if it is present, allow the request to
continue.
Works for me. What should we call this annotation? @Published?
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 <
gue 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, D
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
nerally one 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
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
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 h
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 pr
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
r
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
b
hing getters 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 diff
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 OGNL
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 rele
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:
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 v
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 lifecycl
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 <[EMAI
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 p
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, e-ma
Thanks for the link. The ThreadLocal discussion toward the end applies
directly to the new attributes package.
Bob
On 5/14/06, Don Brown <[EMAIL PROTECTED]> wrote:
I came across this presentation on good API design I thought relevant to
our current Action 2 API discussions:
http://lcsd05.cs.ta
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
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 ge
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
m
t... arguments);
Preferences, more 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 s
p;
import java.util.HashMap;
import java.util.Set;
import java.io.Serializable;
/**
* Request and field-scoped messages. Uses keys instead of actual messages to decouple code from messages. Messages
* may come from multiple actions and interceptors.
*
* @author [EMAIL PROTECTED] (Bob
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
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)
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
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...
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
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
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, w
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ 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
>
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
--
This
http://issues.apache.org/struts/browse/WW-1296
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+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 e
ome and discarding others, then
> implementing them in a staggered fashion. Introducing a strong 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&
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 to
reira <[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/th
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
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"
> i
1 - 100 of 109 matches
Mail list logo
