Re: OGNL performance detrimental to Struts 2
On 12/11/06, dice <[EMAIL PROTECTED]> wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. There's a similar thread on the webwork dev list: http://forums.opensymphony.com/thread.jspa?threadID=52734&messageID=106274 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Howard, who writes Tapestry, notes the same thing in his framework: http://tapestryjava.blogspot.com/2006/11/improve-tapestry-performance-with.html He chose a different way of retrieving simple properties. It supposedly has jumped his performance a lot. I recommend Struts 2 Committees look for an alternative as well, especially when the expression is simple. Paul dice wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. I would like to know whether the decision-makers for Struts 2 have acknowledged its performance problems and if any resolution has been planned. If so, what timeframe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ajaxtags] autocompleter + question
Did you ever get a chance to look at this? regards musachy Rainer Hermanns wrote: Thanks Musachy, patch applied. Regarding the result stuff, I will have some time over the weekend to include those XML/JSONResult stuff before the 2.0.2 release. -Rainer Oh, I get it now. Is it Friday already ? :) I have attached the patch for the autocompleter to WW-1529. musachy Martin Cooper wrote: On 11/30/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Where do you think we should put it? a tag? No, no. That would be worse. The generic serialisation code should be in some utility class somewhere, so that it can be used from wherever might be appropriate. A result implementation would be the first place that it would be used, but it may well be used in other places later (including application code). I have no idea. There are also some comments that Don added that we should check out. Yes. I haven't had the time to read through the whole JIRA thing yet, though. -- Martin Cooper "I think this has promise. First, I'd like to see the incoming parameters better integrated into the ActionContext. In particular, the parameters should populate the parameters map in the ActionContext, and OGNL should be used for the Action population rather than by custom means. Also, it would be interesting to make the result selection happen outside the Action somehow. For example, say you had an Action that returned HTML. It would be interesting to somehow call that Action via Ajax but get JSON back instead, without the Action having to return a different result code. " Rainer, I'm going to submit my patch for the autocompleter the way it is now, and when we get this done, (if we do) then I will modify the example, sounds good? regards musachy Martin Cooper wrote: On 11/30/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Yeah, they are not tied to ajax at all, so they shouldn't have "ajax" in the name if that is what you mean, but are you against having a JSON result type that will take care of the serialization for you? Yes, I was cringing at the naming with AJAX in there. No, I'm not against having a JSON result type, but the serialisation code itself should not be buried in there, because people might want to use that for something else ( e.g. embedding some JSON output within generated HTML). -- Martin Cooper regards musachy Martin Cooper wrote: On 11/30/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote: Musachy and others, sounds like we should finally add an AJAXResult... There have been efforts to create an AjaxJSON and AjaxXML result type already. Please, please decouple the notion of rendering / serialising to JSON and XML from "AJAX". They are completely unrelated. Both JSON and XML are used much more widely than in just AJAX scenarios now. Also, note that there are lots of JSON serialisers out there. See http://json.org/ for a list. The json.org one is also public domain. -- Martin Cooper So may be we should add this to the core of Struts2 now. Have a look at http://issues.apache.org/struts/browse/WW-1330 for more details. What do you think? -Rainer I was finishing the autocompleter examples tonight (annoying patch coming soon:) ) and I have a couple of questions. The autocompleter when used in the "ajax" theme needs the action to return a JSON name/value list, should we provide any easy way to generate the response from the action? In showcase I'm using a freemaker template as an example, but that's going to be a repetitive task for anyone using it. The second question is a beginners question, if I'm writing an action that is going to be used on an ajax request, and I want to write my response straight to the outputstream, I still need to return an string from execute, and I get an error on the server log stating that there is no "result" configured, what is the right way of doing this? regards musachy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---
Re: OGNL performance detrimental to Struts 2
We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't
have time to rewrite OGNL myself.)
In the mean time, we wrote a custom version of OgnlValueStack (pasted below)
which optimizes and uses reflection for normal Java expressions; it's an
order of magnitude faster. I think it's 100% compatible (we haven't noticed
any problems).
We don't use JSP, so I'm not sure how applicable this would be to other
users. If it is applicable, I'll happily check this in.
Bob
import com.opensymphony.xwork.util.OgnlUtil;
import com.opensymphony.xwork.util.OgnlValueStack;
import ognl.Ognl;
import ognl.OgnlException;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
/**
* Optimizes [EMAIL PROTECTED] #findValue(String, Class)} for expressions that
are Java
* identifiers. Performances tests indicate this 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 final Object NOT_FOUND = new Object();
Map overrides;
Class defaultType;
public FastValueStack(OgnlValueStack vs) {
super(vs);
}
public FastValueStack() {}
@Override public void setExprOverrides(Map overrides) {
super.setExprOverrides(overrides);
this.overrides = overrides;
}
@Override public void setDefaultType(Class defaultType) {
super.setDefaultType(defaultType);
this.defaultType = defaultType;
}
@Override public Object findValue(String expression, Class asType) {
if (expression == null) {
return null;
}
if (overrides != null && overrides.containsKey(expression)) {
expression = (String) overrides.get(expression);
}
if (isJavaIdentifier(expression)) {
Object value = findValueForJavaIdentifier(expression, asType);
if (value != NOT_FOUND) {
return value;
}
}
// fall back to old behavior.
return findValueUsingOgnl(expression, asType);
}
/**
* Tries to find a value when the expression is a java identifier. Returns
* the value or NOT_FOUND if no qualifying map entry or
accessor
* method is found.
*/
Object findValueForJavaIdentifier(String javaIdentifier, Class asType) {
for (Object o : getRoot()) {
if (o instanceof Map) {
// gets value from a map.
Map m = (Map) o;
if (m.containsKey(javaIdentifier)) {
Object value = m.get(javaIdentifier);
if (value == null || isAssignable(asType, value.getClass())) {
return value;
}
}
} else {
// gets value by invoking a getter.
Getter getter = Getter.getInstance(o.getClass(), javaIdentifier);
if (getter != null
&& isAssignable(asType, getter.getMethod().getReturnType())) {
return getter.invoke(o);
}
}
}
return NOT_FOUND;
}
Object findValueUsingOgnl(String expression, Class asType) {
try {
Object compiled = OgnlUtil.compile(expression);
return Ognl.getValue(compiled, getContext(), getRoot(), asType);
} catch (OgnlException e) {
throw new RuntimeException(e);
}
}
/**
* Maps primitive classes to their wrapper classes and vice versa.
*/
static Map primitiveClassMap = createPrimitiveClassMap();
static Map createPrimitiveClassMap() {
Map primitiveClassMap = new HashMap() {{
put(boolean.class, Boolean.class);
put(char.class, Character.class);
put(short.class, Short.class);
put(int.class, Integer.class);
put(long.class, Long.class);
put(float.class, Float.class);
put(double.class, Double.class);
}};
// add inverted mappings.
Map inverted = new HashMap();
for (Map.Entry entry : primitiveClassMap.entrySet()) {
inverted.put(entry.getValue(), entry.getKey());
}
primitiveClassMap.putAll(inverted);
return primitiveClassMap;
}
/**
* Returns true if you can cast from to to.
Allows
* for assignment between primitives and their respective wrapper types.
*
* @param to type to cast to
* @param from actual type
*/
static boolean isAssignable(Class to, Class from) {
if (to.isAssignableFrom(from)) {
return true;
}
Class validFrom = primitiveClassMap.get(to);
if (validFrom != null && validFrom.equals(from)) {
return true;
}
return false;
}
static Map javaIdentifiers =
new ConcurrentHashMap();
/**
* Returns true if the string is a valid Java identifier.
*/
static boolean isJavaIdentifier(String s) {
if (javaIdentifiers.containsKey(s)) {
return true;
}
if (s.length() == 0
|| !Character.isJavaIdentifierStart(s.charAt(0))) {
return false;
}
for (int i = 1; i < s.length(); i++) {
if (!Character.isJavaIdentifierPart(s.charAt(i))) {
return false;
}
}
javaIdentifiers.put(s, s);
return true;
}
}
import static com
OGNL performance detrimental to Struts 2
By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. I would like to know whether the decision-makers for Struts 2 have acknowledged its performance problems and if any resolution has been planned. If so, what timeframe? -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7825136 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Tag attribute changes and Dojo upgrade
I have attached a patch and a gif file to WW-1554. Because the patch to WW-1555 has not been applied, there might be some small conflicts on struts-tld.xml. If you guys find anything still missing (hope not :) ), let me know. regards musachy Don Brown wrote: Musachy Barroso wrote: That said, could you go through your tag changes and ensure that we have kept all tags and attributes as they were, and explicitly list those that you really feel we should remove/change. The original WebWork 2.2 tags may have not been the best named, most consistent, or fully featured, but we need to make the best possible effort to keep within those lines. I will, it is mostly about names, we have more functionality than before, not less. Could we consider changing preInvokeJS ->beforeLoading onLoadJS ->afterLoading If we did, we'd have to keep the old attributes and mark them as deprecated. Any objections? at least? musachy //annoying patch coming your way :) Patches are never annoying :) Don Struts 2.0 is advertised as a smooth, painless upgrade for WebWork 2.2 applications, and to make that happen, we need to be very, very careful. Don Musachy Barroso wrote: Good that you mentioned 'cause I hadn't seen it. First thing, "notifyTopics" ,my bad, I forgot to fix it, easy to fix. The attributes that are a little bit problematic cause they were not consistent between the different tags are: preInvokeJS (in anchor, not in div), shouldn't this one be "beforeLoading"? afterLoading (in anchor and div, not in submit) onLoadJS (only on submit), same as "afterLoading" but with a different name. notifyTopics (only on anchor) listenTopics (div and submit) being new here, I tried to make them consistent and I ended up messing the backward compatibility because of the attribute names. Functionality-wise I think pretty much all is there. musachy Martin Cooper wrote: Oops! Forgot [1]: https://issues.apache.org/struts/browse/WW-1554 On 12/9/06, Martin Cooper <[EMAIL PROTECTED]> wrote: As Don has noted [1], there are some tag attributes (e.g. notifyTopics) that have disappeared recently. It seems that, included in the patch to upgrade Dojo to version 0.4, there were other changes that have caused incompatibility with earlier versions. I don't claim to be an expert on the tags, by any stretch of the imagination, but I can't see any reason for changing the attributes here, and hence the public API, especially as part of a Dojo dependency upgrade. Can someone help me understand why attribute compatibility needed to be broken as part of the Dojo upgrade? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release the struts-master pom v4
On 12/10/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 12/7/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I'd like to release version 4 of the struts-master pom. > > The repository has been tagged: > http://svn.apache.org/viewvc/struts/maven/tags/STRUTS_MASTER_4/ > > Pom version 4 available for review here: > http://people.apache.org/builds/struts/STRUTS_MASTER_4/ +1 I copied it into a Maven repository structure so I could test it out; this would have happened with 'mvn deploy'. To try it, add a profile to your settings.xml and enable with -Pstruts-staging struts-staging struts-staging http://people.apache.org/builds/struts/m2-staging-repository false true Thanks - I've added it for next time :-) (This repository structure can be copied over to people.apache.org/repo/m2-ibiblio-rsync-repository to complete the release, then removed from builds/struts/.) Done, thanks for the help - much appreciated. Niall -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release the struts-master pom v4
This vote passed with the following seven +1 votes (6 binding) and no other votes: Niall Pemberton David DeWolf Martin Cooper Rainer Hermanns Don Brown Ted Husted Wendy Smoak Thanks to everyone - I'll get on an complete the master pom release Niall On 12/7/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: I'd like to release version 4 of the struts-master pom. The repository has been tagged: http://svn.apache.org/viewvc/struts/maven/tags/STRUTS_MASTER_4/ Pom version 4 available for review here: http://people.apache.org/builds/struts/STRUTS_MASTER_4/ This is the master pom from which struts-parent inherits, and it needs to be released for future Struts1 (and I assume 2) releases Changes since v3 include: - David DeWolf added - element id changed from "apache.snapshot" to "struts-staging" and now points to people.apache.org/builds/struts/m2-staging-repository - element now points to people.apache.org/repo/m2-snapshot-repository Here's my +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
