On Sep 12, 2013, at 11:34 AM, Ken McWilliams wrote:
> prefix, IE: "OGNL:" or "EL:
I've long argued that %{}, #{}, ${} provides this already, and that this
wrapping should therefore not be optional in preparation for when something
other than %{} migh
ave been done, but not yet the third.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
on of the result of a
state change operation) might cause the POST action to happen again instead of
just reloading the data you display when the POST is complete. If you value
server CPU over site usability, by all means use any of the suggestions
previously offered.
me-type
should be, I would suggest it be configurable so developers can set it
to use whatever response type they want it to have.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
true,
we should add instructions about this change to a new "2.2 -> 2.3
upgrade tips" wiki page.
Lukasz, you committed the patch, would you mind tweaking it? If you
don't have time I can probably work up a patc
POST" or "GET" by default?
The configuration of your struts.xml which specifies the interceptors
and result types that your actions will use does not by default include
json. If you want to add in those interceptors or results, you should
learn how they work, and configure t
r interaction.
The plugin doesn't care, it's the configuration that determines when you
use the interceptor or result.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Below are a few (of many that I found with a simple google search)
explaining the issue in detail. Basically the problem is that
the result, stripping off a few characters and the exec'ing
to get the data.
So by "resolving" this "issue" you've just made all apps built on top of
it less secure.
-Dale
-
To unsubscribe, e-mai
This conversation is not about whether or not it should be deprecated,
but whether or not it should be excised from the first 2.3 release.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
On 6/27/11 9:02 AM, Johannes Geppert wrote:
What you all think about moving deprecated plugins to archive for the 2.3
release?
And the Dojo plugin...
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For
I assume you meant "losing" instead of "using"?
-Dale
On Jun 5, 2011, at 3:17 PM, Dave Newton wrote:
> I'm nervous about using the clean delineation between the web and non-web
> bits. I like that separation.
>
> Dave
---
ange.
My question is if stuff should be folded together even more, and touches on
Dave's question of how to do that w/o losing the non-web users of xwork to a
fork of old code. Should we still produce two jars, one struts(w/xwork) and a
another a sub
On Jun 5, 2011, at 2:37 PM, Lukasz Lenart wrote:
> one struts-core instead of struts-core and xwork-core -
> but we still discussing the best option.
For example, should the package structure change drastically?
-Dale
--
:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=jafl5272
Of course as soon as I got that the phone rang, so I've yet to look at
any of them myself...
-Dale
-
To un
On 8/21/10 11:51 AM, Dave Newton wrote:
Should the Dojo plugin be removed from the distro now?
Wasn't it deprecated in 2.1? Doesn't that mean we can just kill it in 2.2?
-Dale
-
To unsubscribe, e-mail: de
On 7/17/10 6:15 PM, Frans Thamura wrote:
is this version, we can mix .action and REST?
Yes, you can use
org.apache.struts2.dispatcher.mapper.PrefixBasedActionMapper to cause
different portions of the url space to be mapped to actions/parameters
by different action mappers.
-Dale
cy was excluded in OGNL, you must remember to include
it, except when you are lunching an application on JBoss server"
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional com
On 6/29/10 3:02 PM, Lukasz Lenart wrote:
Once you have had a chance to review the test build, please respond
with a vote on its quality:
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 non-binding.
-Dale
ools) upgrade it works for a while, then just
stops altogether, so I'm assuming it's some sort of engine configuration
issue (with the engine not having the right lifespan or somesuch).
Rather than tracking it down right now I'm reverting back to 1.5 (unless
someone can point t
ow if there are any issues within struts that are likely to re-emerge
due to this change?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
quot;...is it
possible some of those transient files were committed to a repository,
or are listed in some table of contents somewhere?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional comman
On 6/22/10 10:40 AM, Lukasz Lenart wrote:
I start Maven release process
Lukasz++ !
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
round in place for this specific bug in the released
2.1.8.1's xwork 2.1.6, is there really any reason to develop against the
trunk rather than that release? Has anyone started working on "2.1 ->
2.2" upgrade instructions yet?
-Dale
-
Thanks for working on this, Łukasz!
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
chance we can
incorporate them, too?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
27;ve also
previously filed a CLA. If there's anything else needed from me to
"clear" this code (only one class, IIRC), please let me know.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additio
xample, is it done once at release time, or is this
export automated and run periodically? Once the export has happened, is
it served via wiki software, or are static pages generated and served
from there forward?
-Dale
-
To u
El 1/22/2010 9:33 AM, Dale Newfield escribió:
Stephen Turner wrote:
Oscar's syntax is described in the Struts docs:
http://struts.apache.org/2.0.8/docs/stream-result.html
It's been updated in
http://struts.apache.org/2.1.8.1/docs/stream-result.html Too bad the
docs are versioned
g) to have a few tutorials on OGNL.
I guess context is the most important factor. For tutorials it might
make sense to have "controlled exposure" to complex topics. For
reference examples, though, I think that argument does not hold and we
should still be explicit.
-Dale
o JUEL or something else
(should that ever happen :-) cause less of the documentation to break.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
I thought we had reached consensus on this back in August:
http://old.nabble.com/Re%3A-Let%27s-kill-xwork-%28was-Re%3A-2.1.8-release-%29-p24966742.html
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For
tributes on the form, url, and every input tag) so
that we don't have users getting freaked out about all the extra stuff
in their pages that they didn't ask for.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr
so the
two windows could be part of two parallel wizards.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Musachy Barroso wrote:
that sounds good, can someone open a jira ticket so we don't depend
on my short term memory :)?
I modified https://issues.apache.org/struts/browse/WW-3332 (although
there didn't appear to be a way for me to change the resolution, so
maybe this was a mistake.
using a more generic and extensible attribute name is
always a good idea.
For example, it could even be implemented such that an attribute
escape="javascript,xml" allows the specification of multiple escape
mechanisms including an
Chris Pratt wrote:
In the struts.xml file you can use ${} to run an OGNL expression and access
things from the Action (actually the value stack, but we're trying to keep
it simple here)
JSYK, %{} now works as expected in struts.xml.
leave xwork where it is so that other
codebases can continue to use it, and to migrate a fork into the struts2
codebase so we can make changes to it.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional
sitemesh filter in between the StrutsPrepareFilter / StrutsExecuteFilter
pair).
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
reemarker
more exetensively?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Alex Siman wrote:
I use [2.1.8]. Just read the version of Struts in a Subject of this thread.
Whoops--my bad.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h
o track it down for
you.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Musachy Barroso wrote:
hum, yeah after rtexprvalue=false it should work fine, please edit the wiki :)
Done.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h
f so, anyone mind if I remove that
portion of the wiki page (replacing it with a link to the ognl
mapContruction link)?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
at are the problems that this addresses? It seems that the cure is
worse than the disease of having to escape a few #'s here and there
(none in my codebase), especially after we've since restricted all the
struts tags with rtexprva
ues.apache.org/struts/secure/ReleaseNote.jspa?projectId=10030&styleName=Html&version=21920
My eyes started to glaze over partway through the second link, and I
wonder if I missed anything important...does anyone think that there's
something on that second page that should be on the first but is not
I don't think this is a big deal, but I figured it was worth asking...
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
&Create=Create
doesn't seem to suggest anything that should require changes other
than a .jar replacement...
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
re we planning on switching to 2.2 so we can
eliminate the external xwork dependency?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Chris Pratt wrote:
Holy Carp! How big is your water heater? =9^D
Funny you should mention that--yes, I've been finding dead fish all over
the place.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.or
Martin Gainty wrote:
a small flood a few weeks back when my HW tank blew..not fun
http://newfield.org/dale/flood/
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h
Wes Wannemacher wrote:
@Dale - which container / JDK are you running when you get the error?
I was using glassfish / 1.5 (on a mac PPC, so no 1.6 available), and
while I *think* I saw the error on a clean launch of glassfish, I *know*
I saw it on a redeploy. I did have a completely screwed
Wes Wannemacher wrote:
if you build with maven 2.0.x the unit test in the embedded
JSP plugin will fail... But, if you are using 2.2.1, the test
succeeds.
Using java5 instead of java6 will result in the same symptom. Do you
know what version of java hudson or bamboo compile with?
-Dale
could get released
(and hopefully go GA) so I would know my java5 compilation environment
isn't screwing up anything important.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
ing on. I just know that I'm spinning my wheels
like crazy trying to get stuff working again. Serves me right for not
doing more frequent svn commits, I guess :-(
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.
t,java.lang.String,java.lang.String,java.lang.String,java.lang.String).
So I'm thinking it doesn't actually have a default value.
(yes, I'm using xwork and struts2 SNAPSHOT updated today, and since
I'm on an apple still running 10.4, I don't have java6, so it took
some pom
xwork component, as the
two codebases will be merged into one.
Is there any dissent from this plan?
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
struts2 and xwork.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Musachy Barroso wrote:
I think the JSON plugin is ready to be moved to trunk, here is my +1.
(non-committer's non-binding) +1
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e
ad an occasion where a code update I needed to
test included only action class changes, so this trick rather than a
redeploy hasn't yet been a viable testing strategy for me, and I've not
yet fully tested it. I'll let you know once I
trying to test changes to my app by
just copying the new .class file over the old one, but it doesn't seem
to get noticed.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
ction/reload happen even if there are currently no
active requests, or will it only notice when the next request comes in?
(No, in my case it doesn't notice then, either.)
-Dale
-
To unsubscribe, e-mail: de
Musachy Barroso wrote:
I added "struts.class.reloading.acceptClasses", so now I can make the
reloading class loader handle only action classes, so I don't get
ClassCastException(s)
I also added support for the relative paths, @Dale, take it for a spin
and let me know how it w
Musachy Barroso wrote:
With the bytecode stuff out the way I am inclined to just
upgrade to 2.7.3 at once, and upgrade freemarker also.
+1
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional
Musachy Barroso wrote:
Dale, take it for a spin and let me know how it works.
Sorry I've been banging my head against JNI stuff and not working on the
web side of my current application lately, so I've not yet gotten a
chance to test any of this.
. (I have a
feeling that this has fairly consistently been the case throughout the
lifetime of struts v1 and v2.) I'm happy that struts is improving, so
I'm not trying to discourage heroic effort, but I'm wondering if anyone
has any suggestions for how to get more
? Meaning this must know the
deployment directory? Any way to make relative paths be relative to the
context root, so you can just add 'WEB-INF/classes' without knowing the
deployment path? (Sorry to nit pick, I'm excited about this, just
trying to make it
Musachy Barroso wrote:
I get my action classes reloaded after compilation, from jar files
and normal dirs. If anyone is interested I could add this to the
Spring plugin
That seems great, but something that should only kick in if devMode is
true. Is that possible?
-Dale
Musachy Barroso wrote:
It seems like we wont be able to use the new OGNL byte code
Oh, well.
I think it's been too long since you've received public kudos, Musachy,
for all the work you've put in of late to support the struts community:
Mu
would best go into
2.2), but if it neither breaks anything nor slows anything down with
just a jar change, any reason to wait? (Your caching issue is one, but
adding that doNotCache flag seems like a reasonable workaround for now...)
added around it in the 2.6.10 -> 2.6.11 transition also is
synchronized the same way in 2.7.2.
This is not a comprehensive comparison, but it appears to indicate that
the answer to your question might be "yes".
-Dale
--
been built with the JDK source and target options set to JDK 1.3 and,
except for
those implementations, can be used with JDK 1.3 (see IO IO-127).
So while I've not yet tested it, it sounds like we should be able to
jump to 1.4 if we're moving
Matt Raible wrote:
Release Notes 2.1.6 is an invalid link on the Version Notes page.
And the "Struts 2.1.7 DONE" link.
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-m
Martin Cooper wrote:
I've confirmed that an iCLA is on file for you, and have given you
corresponding access to the wiki.
Thanks!
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional comman
Philip Luppens wrote:
You should file a CLA (contact Martin C. for that or check out the
pages at the Apache site).
I'm pretty sure I faxed in one of these like 6-9 months ago, but never
heard any followup...
-Dale
---
de
protected void beforeInvocation() throws Exception {
+while (!initializationComplete) {
+ try {
+synchronized (lock) {
+ lock.wait(100);
+}
+ } catch (InterruptedException e) {
+// behavior ignores cause of re-awakening.
+
ue. I'm certain that there's a better solution than a busy-wait
loop, but it's past my bed time, so I'll think about that more in the
morning. The obvious solution (synchronized methods) won't work to
avoid simultaneous
r before the thread is started. This is
relevant to the solution offered at
http://cwiki.apache.org/WW/hibernateandspringenabledexecuteandwaitinterceptor.html
and I'm not sure if it's really an issue or how to fix it (but I'm
interested since I use
Dave Newton wrote:
Dale Newfield wrote:
public final List getPayPlanTypes() {
return payPlanTypes;
}
public final void setPayPlanTypes(List payPlanTypes) {
this.payPlanTypes = payPlanTypes;
}
I recognize that "final" for methods is an attempt to make this
not-over-rida
ning them, but that means it's not visible in the
reflection api that's used to find the appropriate attributes?)
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
rd's three
lectures is *well* worth it.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
anded to the File
constructor that we're trying to protect ourselves from, making that
catch specific for IllegalArgumentException seems like a good choice.
At least if it were trimmed down to RuntimeException, then a valid
IOException would get out of the inner try/c
es not specify a
scheme." Since it also says that "An opaque URI is an absolute URI
whose scheme-specific part does not begin with a slash character
('/').", then ensuring that it is also not opaque wi
Also check for !uri.isOpaque() .)
This will prevent a bunch of cryptic stack traces from entering the logs
(possibly MANY times) for many users.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
processing continues. I would like to find the source of the
bad url, but this patch to xwork will at least prevent that bad url from
being a showstopper for me.
So, should I just add this patch to WW-2633, or should I open a new issue?
-Dale
Index:
src/java/com/opensymphony/xwork2
ars
to be supplying either an invalid classpath, or a broken class loader...
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ilar issues, but found neither.
I seem to be going in circles. Can anyone here point me in another
direction?
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
some patches to address this (I think it'll require
both xwork2 and struts2 changes), but I'm confused right out of the
gate, because I can't find where the setParameters method of
ActionContext is initially called...
...can anyone offer guidance here?
-Dale Newfie
ck you could use to sidestep this would be to
replicate your action with different names...
I'm not sure exactly what the restriction is--maybe you can define a
wildcarded action so that there are multiple available?
longRun
requests to be paired with the
appropriate long running task.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
e "lib" version) contain these two
seemingly mismatched pair of .jar files?
commons-logging-1.0.4.jar
commons-logging-api-1.1.jar
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This appears to be missing from the 2.1.2 candidate...
Is this file no longer relevant?
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Antonio Petrelli wrote:
2008/3/17, Dale Newfield <[EMAIL PROTECTED]>:
We can avoid the JS requirement if we make the submit button's submitted
value complex enough to encode the names of the namespace and
actionname.
The problem is that the value of the submit button is what the
elect a different one based on these two
strings. This wouldn't help with WW-2316/WW-2363/XW-595/XW-594, but it
would fix this validation problem...
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
idation.xml for example).
It would solve your validation problem and many more simultaneously.
The only cost is that it makes the s:submit tag only work correctly if
the client has javascript enabled.
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
" attribute
to the submit tag that uses js on the client to change the form target
before submitting. This will enable the usage pattern that I believe
developers want and reduces the dispatcher complexity.
Thoughts?
-Dale
---
needing to globally select
one EL plugin... (And as you've been saying, since the string would be
evaluated by exactly one of these, we don't re-expose the previous
security risk.)
-Dale
-
To unsubscribe, e-mail: [
pass the string "${foo}" on to your tag. As
previous posters suggested, I believe the only way to prevent this is to
tell the container to never evaluate these el expressions, which has the
previously mentioned down-sides.
-Dale
---
ompromise it.
It's the same as SQL injection...
In fact, it's OGNL injection, and the way to avoid it is not to evaluate
user provided strings as OGNL expressions. Turning off EL is part of
how that's been accomplished.
-Dale
---
W-461
-Dale
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
1 - 100 of 131 matches
Mail list logo
