Re: [jira] Issue Comment Edited: (WW-2709) 2.0.11.2 upgrades breaks xml validators
Where can i get XWork 2.0.6-SNAPSHOT? I can't find it. Please, help JIRA [EMAIL PROTECTED] wrote: > > > [ > https://issues.apache.org/struts/browse/WW-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44336#action_44336 > ] > > rgielen edited comment on WW-2709 at 7/7/08 4:24 PM: > - > > The linked issues deliver a full discussion of the problem. In summary, > this is a problem being unique to WebShere 6 / IBM JVM environments. The > code was introduced with a fix between XWork 2.0.4 and 2.0.5, and the > breaking part for the said environment was fixed for XW2 trunk (2.1.x), > but not for 2.0 branch. > > The problem should be fixed now in XWork 2.0 branch, see > http://jira.opensymphony.com/browse/XW-651 > > Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to discuss > the release plans regarding this issue. > > was (Author: rgielen): > The linked issues deliver a full discussion of the problem. In > summary, this is a problem being unique to WebShere 6.0 / IBM JVM > environments. The code was introduced with a fix between XWork 2.0.4 and > 2.0.5, and the breaking part for the said environment was fixed for XW2 > trunk (2.1.x), but not for 2.0 branch. > > The problem should be fixed now in XWork 2.0 branch, see > http://jira.opensymphony.com/browse/XW-651 > > Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to discuss > the release plans regarding this issue. > >> 2.0.11.2 upgrades breaks xml validators >> --- >> >> Key: WW-2709 >> URL: https://issues.apache.org/struts/browse/WW-2709 >> Project: Struts 2 >> Issue Type: Bug >>Affects Versions: 2.0.11.2 >> Environment: Websphere V6.1.0.15 >>Reporter: S. Farshi >>Assignee: Rene Gielen >>Priority: Critical >> Attachments: TicketCreation-validation.xml >> >> >> I have upgraded my struts 2.0.11.1 to struts 2.0.11.2. None of my xml >> validators run and they all break. I have downgraded to 2.0.11.1 and they >> all work again. I think there must be a bug with xwork-2.0.5.jar. >> [7/3/08 14:42:22:753 EDT] 003f WebAppE [Servlet >> Error]-[Filter [struts2]: filter is unavailable.]: >> java.lang.ExceptionInInitializerError >> at java.lang.J9VMInternals.initialize(J9VMInternals.java:216) >> at >> com.opensymphony.xwork2.validator.ValidatorFileParser.addValidatorConfigs(ValidatorFileParser.java:192) >> at >> com.opensymphony.xwork2.validator.ValidatorFileParser.parseActionValidatorConfigs(ValidatorFileParser.java:72) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.loadFile(AnnotationActionValidatorManager.java:361) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.buildAliasValidatorConfigs(AnnotationActionValidatorManager.java:244) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.buildValidatorConfigs(AnnotationActionValidatorManager.java:343) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.getValidators(AnnotationActionValidatorManager.java:69) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:138) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:113) >> at >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:100) >> at >> com.opensymphony.xwork2.validator.ValidationInterceptor.doBeforeInvocation(ValidationInterceptor.java:142) >> at >> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:148) >> at >> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:48) >> at >> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) >> at >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224) >> at >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223) >> at >> com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455) >> at >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221) >> at >> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:123) >> at >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224) >> at >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223) >> at >> com.opensymphony.xwork2.uti
Re: [jira] Issue Comment Edited: (WW-2709) 2.0.11.2 upgrades breaks xml validators
I guess it is https://svn.opensymphony.com/svn/xwork/branches/2.0 The pom does not reflect this, but the last change was 2008-07-08. Piero Am Freitag, 18. Juli 2008 12:55:04 schrieb holod: > Where can i get XWork 2.0.6-SNAPSHOT? > I can't find it. Please, help > > JIRA [EMAIL PROTECTED] wrote: > > [ > > https://issues.apache.org/struts/browse/WW-2709?page=com.atlassian.jira.p > >lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44336#action > >_44336 ] > > > > rgielen edited comment on WW-2709 at 7/7/08 4:24 PM: > > - > > > > The linked issues deliver a full discussion of the problem. In summary, > > this is a problem being unique to WebShere 6 / IBM JVM environments. The > > code was introduced with a fix between XWork 2.0.4 and 2.0.5, and the > > breaking part for the said environment was fixed for XW2 trunk (2.1.x), > > but not for 2.0 branch. > > > > The problem should be fixed now in XWork 2.0 branch, see > > http://jira.opensymphony.com/browse/XW-651 > > > > Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to > > discuss the release plans regarding this issue. > > > > was (Author: rgielen): > > The linked issues deliver a full discussion of the problem. In > > summary, this is a problem being unique to WebShere 6.0 / IBM JVM > > environments. The code was introduced with a fix between XWork 2.0.4 and > > 2.0.5, and the breaking part for the said environment was fixed for XW2 > > trunk (2.1.x), but not for 2.0 branch. > > > > The problem should be fixed now in XWork 2.0 branch, see > > http://jira.opensymphony.com/browse/XW-651 > > > > Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to > > discuss the release plans regarding this issue. > > > >> 2.0.11.2 upgrades breaks xml validators > >> --- > >> > >> Key: WW-2709 > >> URL: https://issues.apache.org/struts/browse/WW-2709 > >> Project: Struts 2 > >> Issue Type: Bug > >>Affects Versions: 2.0.11.2 > >> Environment: Websphere V6.1.0.15 > >>Reporter: S. Farshi > >>Assignee: Rene Gielen > >>Priority: Critical > >> Attachments: TicketCreation-validation.xml > >> > >> > >> I have upgraded my struts 2.0.11.1 to struts 2.0.11.2. None of my xml > >> validators run and they all break. I have downgraded to 2.0.11.1 and > >> they all work again. I think there must be a bug with xwork-2.0.5.jar. > >> [7/3/08 14:42:22:753 EDT] 003f WebAppE [Servlet > >> Error]-[Filter [struts2]: filter is unavailable.]: > >> java.lang.ExceptionInInitializerError > >>at java.lang.J9VMInternals.initialize(J9VMInternals.java:216) > >>at > >> com.opensymphony.xwork2.validator.ValidatorFileParser.addValidatorConfig > >>s(ValidatorFileParser.java:192) at > >> com.opensymphony.xwork2.validator.ValidatorFileParser.parseActionValidat > >>orConfigs(ValidatorFileParser.java:72) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.loadF > >>ile(AnnotationActionValidatorManager.java:361) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.build > >>AliasValidatorConfigs(AnnotationActionValidatorManager.java:244) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.build > >>ValidatorConfigs(AnnotationActionValidatorManager.java:343) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.getVa > >>lidators(AnnotationActionValidatorManager.java:69) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.valid > >>ate(AnnotationActionValidatorManager.java:138) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.valid > >>ate(AnnotationActionValidatorManager.java:113) at > >> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.valid > >>ate(AnnotationActionValidatorManager.java:100) at > >> com.opensymphony.xwork2.validator.ValidationInterceptor.doBeforeInvocati > >>on(ValidationInterceptor.java:142) at > >> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(Vali > >>dationInterceptor.java:148) at > >> org.apache.struts2.interceptor.validation.AnnotationValidationIntercepto > >>r.doIntercept(AnnotationValidationInterceptor.java:48) at > >> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(Me > >>thodFilterInterceptor.java:86) at > >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultAct > >>ionInvocation.java:224) at > >> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultAct > >>ionInvocation.java:223) at > >> com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerS > >>tack.java:455) at > >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvo > >>cation.java:221) at > >> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept > >>(ConversionErr
Re: Firefox3 seems to jam with the struts2 ajax theme
Hi, In Firefox 3 I've set the following two parameters in about:config and it seems Firefox no longer jams: security.fileuri.origin_policy 3 security.fileuri.strict_origin_policy false If you don't see security.fileuri.origin_policy in about:config then right-click and create it. Ciao tonijim wrote: > > Hi there, > I have an application running on tomcat6. It uses postgres and hibernate. > The point is that Firefox 3 seems to jam when it tries to load the pages > that use the ajax theme. > It looks like it throws an error at some point when loading the dojo js > libraries in . The particular page actually seems to > work properly but then it halts and displays a blank page. > > I tried to import the js files manually instead of using the tag, > and "struts/ajax/dojoRequire.js" seems troubling. Then turned the debug > mode on and the following error came up: > > > DEBUG: failed loading /[appname]/struts/dojo/src/widget/RichText.js with > error: [TypeError: setting a property that has only a getter, file: > http://localhost:8080/[appname]/struts/dojo/dojo.js, line: 131] > > > I reckon it's an issue concerning firefox 3 since the same app works on > IE7, Firefox2, Opera and Safari. Anyone knows if its a reported bug of > Firefox3 or Struts2? > > Regards > -- View this message in context: http://www.nabble.com/Firefox3-seems-to-jam-with-the-struts2-ajax-theme-tp18377641p18528373.html 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: Firefox3 seems to jam with the struts2 ajax theme
On the other hand this workaround is a pain in the neck because I cannot ask my customers to start fiddling in about:config all the time. This was an afterthought. Ciao Pierrot52 wrote: > > Hi, > > In Firefox 3 I've set the following two parameters in about:config and it > seems Firefox no longer jams: > > security.fileuri.origin_policy 3 > security.fileuri.strict_origin_policy false > > If you don't see security.fileuri.origin_policy in about:config then > right-click and create it. > > Ciao > > > tonijim wrote: >> >> Hi there, >> I have an application running on tomcat6. It uses postgres and hibernate. >> The point is that Firefox 3 seems to jam when it tries to load the pages >> that use the ajax theme. >> It looks like it throws an error at some point when loading the dojo js >> libraries in . The particular page actually seems >> to work properly but then it halts and displays a blank page. >> >> I tried to import the js files manually instead of using the >> tag, and "struts/ajax/dojoRequire.js" seems troubling. Then turned the >> debug mode on and the following error came up: >> >> >> DEBUG: failed loading /[appname]/struts/dojo/src/widget/RichText.js with >> error: [TypeError: setting a property that has only a getter, file: >> http://localhost:8080/[appname]/struts/dojo/dojo.js, line: 131] >> >> >> I reckon it's an issue concerning firefox 3 since the same app works on >> IE7, Firefox2, Opera and Safari. Anyone knows if its a reported bug of >> Firefox3 or Struts2? >> >> Regards >> > > -- View this message in context: http://www.nabble.com/Firefox3-seems-to-jam-with-the-struts2-ajax-theme-tp18377641p18528433.html 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: Firefox3 seems to jam with the struts2 ajax theme
I really appreciate all your answers but I'm seriously thinking of migrating to struts 2.1.x where dojo becomes an external plugin. Most of the stuff concerning ajax tags needs to be slightly adapted so I have no clue as to how long it might take. I've taken a look and found some good looking migration guides in the official page so I think I'll try. Thanks! Regards Pierrot52 wrote: > > On the other hand this workaround is a pain in the neck because I cannot > ask my customers to start fiddling in about:config all the time. > > This was an afterthought. > > Ciao > > > Pierrot52 wrote: >> >> Hi, >> >> In Firefox 3 I've set the following two parameters in about:config and it >> seems Firefox no longer jams: >> >> security.fileuri.origin_policy 3 >> security.fileuri.strict_origin_policy false >> >> If you don't see security.fileuri.origin_policy in about:config then >> right-click and create it. >> >> Ciao >> >> >> tonijim wrote: >>> >>> Hi there, >>> I have an application running on tomcat6. It uses postgres and >>> hibernate. The point is that Firefox 3 seems to jam when it tries to >>> load the pages that use the ajax theme. >>> It looks like it throws an error at some point when loading the dojo js >>> libraries in . The particular page actually seems >>> to work properly but then it halts and displays a blank page. >>> >>> I tried to import the js files manually instead of using the >>> tag, and "struts/ajax/dojoRequire.js" seems troubling. Then turned the >>> debug mode on and the following error came up: >>> >>> >>> DEBUG: failed loading /[appname]/struts/dojo/src/widget/RichText.js with >>> error: [TypeError: setting a property that has only a getter, file: >>> http://localhost:8080/[appname]/struts/dojo/dojo.js, line: 131] >>> >>> >>> I reckon it's an issue concerning firefox 3 since the same app works on >>> IE7, Firefox2, Opera and Safari. Anyone knows if its a reported bug of >>> Firefox3 or Struts2? >>> >>> Regards >>> >> >> > > -- View this message in context: http://www.nabble.com/Firefox3-seems-to-jam-with-the-struts2-ajax-theme-tp18377641p18529222.html 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: [jira] Issue Comment Edited: (WW-2709) 2.0.11.2 upgrades breaks xml validators
There is nothing as a nightly build for XWork right now. You would have to checkout the branch from svn and do build with maven (mvn install) Am Fr, 18.07.2008, 12:55, schrieb holod: > > Where can i get XWork 2.0.6-SNAPSHOT? > I can't find it. Please, help > > JIRA [EMAIL PROTECTED] wrote: >> >> >> [ >> https://issues.apache.org/struts/browse/WW-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44336#action_44336 >> ] >> >> rgielen edited comment on WW-2709 at 7/7/08 4:24 PM: >> - >> >> The linked issues deliver a full discussion of the problem. In summary, >> this is a problem being unique to WebShere 6 / IBM JVM environments. The >> code was introduced with a fix between XWork 2.0.4 and 2.0.5, and the >> breaking part for the said environment was fixed for XW2 trunk (2.1.x), >> but not for 2.0 branch. >> >> The problem should be fixed now in XWork 2.0 branch, see >> http://jira.opensymphony.com/browse/XW-651 >> >> Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to >> discuss >> the release plans regarding this issue. >> >> was (Author: rgielen): >> The linked issues deliver a full discussion of the problem. In >> summary, this is a problem being unique to WebShere 6.0 / IBM JVM >> environments. The code was introduced with a fix between XWork 2.0.4 and >> 2.0.5, and the breaking part for the said environment was fixed for XW2 >> trunk (2.1.x), but not for 2.0 branch. >> >> The problem should be fixed now in XWork 2.0 branch, see >> http://jira.opensymphony.com/browse/XW-651 >> >> Using a XWork 2.0.6-SNAPSHOT build should work now. We now have to >> discuss >> the release plans regarding this issue. >> >>> 2.0.11.2 upgrades breaks xml validators >>> --- >>> >>> Key: WW-2709 >>> URL: https://issues.apache.org/struts/browse/WW-2709 >>> Project: Struts 2 >>> Issue Type: Bug >>>Affects Versions: 2.0.11.2 >>> Environment: Websphere V6.1.0.15 >>>Reporter: S. Farshi >>>Assignee: Rene Gielen >>>Priority: Critical >>> Attachments: TicketCreation-validation.xml >>> >>> >>> I have upgraded my struts 2.0.11.1 to struts 2.0.11.2. None of my xml >>> validators run and they all break. I have downgraded to 2.0.11.1 and >>> they >>> all work again. I think there must be a bug with xwork-2.0.5.jar. >>> [7/3/08 14:42:22:753 EDT] 003f WebAppE [Servlet >>> Error]-[Filter [struts2]: filter is unavailable.]: >>> java.lang.ExceptionInInitializerError >>> at java.lang.J9VMInternals.initialize(J9VMInternals.java:216) >>> at >>> com.opensymphony.xwork2.validator.ValidatorFileParser.addValidatorConfigs(ValidatorFileParser.java:192) >>> at >>> com.opensymphony.xwork2.validator.ValidatorFileParser.parseActionValidatorConfigs(ValidatorFileParser.java:72) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.loadFile(AnnotationActionValidatorManager.java:361) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.buildAliasValidatorConfigs(AnnotationActionValidatorManager.java:244) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.buildValidatorConfigs(AnnotationActionValidatorManager.java:343) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.getValidators(AnnotationActionValidatorManager.java:69) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:138) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:113) >>> at >>> com.opensymphony.xwork2.validator.AnnotationActionValidatorManager.validate(AnnotationActionValidatorManager.java:100) >>> at >>> com.opensymphony.xwork2.validator.ValidationInterceptor.doBeforeInvocation(ValidationInterceptor.java:142) >>> at >>> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:148) >>> at >>> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:48) >>> at >>> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) >>> at >>> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:224) >>> at >>> com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionInvocation.java:223) >>> at >>> com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack.java:455) >>> at >>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:221) >>> at >>> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:123) >>
Re: Firefox3 seems to jam with the struts2 ajax theme
By the way, Pierrot52, I've been unable to find the first property name you mention, security.fileuri.origin_policy, amongst my Firefox's about:config page Pierrot52 wrote: > > Hi, > > In Firefox 3 I've set the following two parameters in about:config and it > seems Firefox no longer jams: > > security.fileuri.origin_policy 3 > security.fileuri.strict_origin_policy false > > If you don't see security.fileuri.origin_policy in about:config then > right-click and create it. > > Ciao > -- View this message in context: http://www.nabble.com/Firefox3-seems-to-jam-with-the-struts2-ajax-theme-tp18377641p18529291.html 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: hacking OGNL and parameter binding
I opened a code review here:
http://fisheye6.atlassian.com/cru/CR-9
I added a new interface ClearableValueStack, which if implemented will
make the OGNL parameter binding run in a clean context.
musachy
On Thu, Jul 17, 2008 at 5:46 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> I think it would be the same, we would just need to add a method to
> ValueStack, to clear the context.
>
> musachy
>
> On Thu, Jul 17, 2008 at 5:32 PM, Chris Pratt <[EMAIL PROTECTED]> wrote:
>> Will it be pluggable between the new-and-improved ValueStack and the
>> OGNL ValueStack so that we can make the transition as painless as
>> possible?
>> (*Chris*)
>>
>> On Thu, Jul 17, 2008 at 2:28 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
>>> Yeah I am set to fix those security holes ;). Doing the change below,
>>> all tests pass, with the exception of some tests in
>>> ParameterInterceptorTest, that need to inject dependencies, and others
>>> that check for the order of the values added to the stack (new context
>>> is created here, so they fail)
>>>
>>> +ValueStack emptyStack = valueStackFactory.createValueStack(stack);
>>> +Map context = emptyStack.getContext();
>>> +((OgnlContext)context).getValues().clear(); /// THIS IS BAD
>>> +ReflectionContextState.setCreatingNullObjects(context, true);
>>> +ReflectionContextState.setDenyMethodExecution(context, true);
>>> +ReflectionContextState.setReportingConversionErrors(context, true);
>>> +
>>> for (Map.Entry entry :
>>> acceptableParameters.entrySet()) {
>>> String name = entry.getKey();
>>> Object value = entry.getValue();
>>> @@ -233,7 +265,7 @@
>>> String name = entry.getKey();
>>> Object value = entry.getValue();
>>> try {
>>> -stack.setValue(name, value);
>>> +emptyStack.setValue(name, value);
>>> } catch (RuntimeException e) {
>>> if (devMode) {
>>> String developerNotification =
>>> LocalizedTextUtil.findText(ParametersInterceptor.class,
>>> "devmode.notification", ActionContext.getContext().getLocale(),
>>> "Developer Notification:\n{0}", new Object[]{
>>> @@ -246,6 +278,9 @@
>>> }
>>> }
>>> }
>>> +stack.getContext().putAll(acceptableParameters);
>>> +
>>>
>>> The 2 big things to be addressed are:
>>>
>>> 1. ((OgnlContext)context).getValues().clear();
>>>
>>> I cannot just do context.clear(), because that method not only removes
>>> the values from the stack, but it clears the root, type converter and
>>> other stuff, so we will have to add another "clear" method to the
>>> OgnlContext, that just clears the values.
>>>
>>> 2. throwPropertyExceptions which needs to be the same in the new value
>>> stack, but I think it is getting cleared.
>>>
>>> what do you guys think?
>>>
>>> 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]
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"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: Sanity-check regarding ModelDrivenInterceptor vs. stack order
I think I need to read more code to follow this thread...I promise. 2008/7/17 Ted Husted <[EMAIL PROTECTED]>: > On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres > <[EMAIL PROTECTED]> wrote: >> The dangerous case is when you add to the value stack objects with >> some identical properties, that's when the order in the stack is >> important (and should log a warning when this happens?). If there are >> no objects with shadowed properties, then it should be ok? > > In the case of validation, doesn't that happen in the normal course? > > Don't we push the validator property onto the stack, so that we can > capture whatever String value is input, even if it is not valid for a > binary type (e.g. "blue" for an int type)? > > -Ted. > > On Wed, Jul 16, 2008 at 4:23 PM, Gabriel Belingueres > <[EMAIL PROTECTED]> wrote: >> I'm not a big user of ModelDriven, but reading the >> ModelDrivenInterceptor source code I see what you meant. >> >> I thought that making an action ModelDriven would push the model at >> the top of the stack, but it seems that there are cases where the >> pushed model will not end at the top of the value stack when the >> result is rendered. >> Can this be cases where this may happen: >> when action-chaining the result to another ModelDriven action? what if >> both actions has refreshModelBeforeResult==true? >> when other interceptor pushes data after the ModelDriverInterceptor? >> >> The dangerous case is when you add to the value stack objects with >> some identical properties, that's when the order in the stack is >> important (and should log a warning when this happens?). If there are >> no objects with shadowed properties, then it should be ok? >> >> >> 2008/7/16 Dave Newton <[EMAIL PROTECTED]>: >>> --- On Wed, 7/16/08, Gabriel Belingueres wrote: May you describe us a context, a use case, UI interaction or the sequence of events that need to take place so that would you be exposed to this behavior? >>> >>> Any time there's stack manipulation and the user accesses the stack via >>> OGNL's [] syntax. >>> >>> Like I said, it's an edge case, but it's a case nonetheless. >>> >>> Dave >>> >>> >>> - >>> 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] >> >> > > > > -- > HTH, Ted > http://husted.com/ted/blog/ > > - > 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]
[S2] Why XWorkBasicConverter throws XWorkException exception?
I have a conversion validator on a form textfield, which is an Integer
property on the action. Now if I enter "a" instead of a number, the
conversion validator acts and works, but it throws an exception.
Which is the policy for throwing an XWorkException?
I first thought that there was "throw XWorkException when something
unexpected happened inside Struts". In this case, if I'm using the
conversion validator in the right way, wouldn't be better to log
something in devMode and move on?
This is the code in XWorkBasicConverter.java that is executed:
private Object doConvertToNumber(Map context, Object value, Class toType) {
if (value instanceof String) {
if (toType == BigDecimal.class) {
return new BigDecimal((String) value);
} else if (toType == BigInteger.class) {
return new BigInteger((String) value);
} else if (toType.isPrimitive()) {
return super.convertValue(context, value, toType);
} else {
String stringValue = (String) value;
if (!toType.isPrimitive() && (stringValue == null ||
stringValue.length() == 0)) {
return null;
}
NumberFormat numFormat =
NumberFormat.getInstance(getLocale(context));
ParsePosition parsePos = new ParsePosition(0);
if (isIntegerType(toType)) {
numFormat.setParseIntegerOnly(true);
}
numFormat.setGroupingUsed(true);
Number number = numFormat.parse(stringValue, parsePos);
if (parsePos.getIndex() != stringValue.length()) {
throw new XWorkException("Unparseable number: \""
+ stringValue + "\" at position "
+ parsePos.getIndex());
} else {
value = super.convertValue(context, number, toType);
}
}
} else if (value instanceof Object[]) {
Object[] objArray = (Object[]) value;
if (objArray.length == 1) {
return doConvertToNumber(context, objArray[0], toType);
}
}
// pass it through DefaultTypeConverter
return super.convertValue(context, value, toType);
}
This is the stack trace:
Unparseable number: " " at position 0 - [unknown location]
at
com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter.doConvertToNumber(XWorkBasicConverter.java:411)
at
com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter.doConvertToNumber(XWorkBasicConverter.java:421)
at
com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter.convertValue(XWorkBasicConverter.java:132)
at
com.opensymphony.xwork2.conversion.impl.XWorkConverter.convertValue(XWorkConverter.java:313)
at
com.opensymphony.xwork2.ognl.OgnlTypeConverterWrapper.convertValue(OgnlTypeConverterWrapper.java:28)
at ognl.OgnlRuntime.getConvertedType(OgnlRuntime.java:687)
at ognl.OgnlRuntime.getConvertedTypes(OgnlRuntime.java:703)
at ognl.OgnlRuntime.getConvertedMethodAndArgs(OgnlRuntime.java:726)
at ognl.OgnlRuntime.getAppropriateMethod(OgnlRuntime.java:783)
at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:794)
at ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:964)
at
ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:75)
at
ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:131)
at
com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27)
at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656)
at
com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:59)
at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656)
at ognl.ASTProperty.setValueBody(ASTProperty.java:101)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177)
at ognl.SimpleNode.setValue(SimpleNode.java:246)
at ognl.Ognl.setValue(Ognl.java:476)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:197)
at
com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:150)
at
com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:138)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:205)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:162)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at
com.opensymphony.xwork2.DefaultActionInvocation$1.doProfiling(DefaultActionInvocation.java:230)
at
com.opensymphony.xwork2.DefaultActionInvocation$1.doProfiling(DefaultActionInvocation.java:229)
at
com.opensymphony.xwork2.
Re: Firefox3 seems to jam with the struts2 ajax theme
Hi, I would highly recommend to wait until struts 2.1.x reaches the GA before migrating your application. Also, it's only my opinion, I think Firefox 3 is still in mega sub Beta version because struts2 doesn't jam with Firefox 2, IE6, IE7, Safari 3.x, and Opera 9.x Ciao tonijim wrote: > > I really appreciate all your answers but I'm seriously thinking of > migrating to struts 2.1.x where dojo becomes an external plugin. Most of > the stuff concerning ajax tags needs to be slightly adapted so I have no > clue as to how long it might take. I've taken a look and found some good > looking migration guides in the official page so I think I'll try. Thanks! > > Regards > > > > Pierrot52 wrote: >> >> On the other hand this workaround is a pain in the neck because I cannot >> ask my customers to start fiddling in about:config all the time. >> >> This was an afterthought. >> >> Ciao >> >> >> Pierrot52 wrote: >>> >>> Hi, >>> >>> In Firefox 3 I've set the following two parameters in about:config and >>> it seems Firefox no longer jams: >>> >>> security.fileuri.origin_policy 3 >>> security.fileuri.strict_origin_policy false >>> >>> If you don't see security.fileuri.origin_policy in about:config then >>> right-click and create it. >>> >>> Ciao >>> >>> >>> tonijim wrote: Hi there, I have an application running on tomcat6. It uses postgres and hibernate. The point is that Firefox 3 seems to jam when it tries to load the pages that use the ajax theme. It looks like it throws an error at some point when loading the dojo js libraries in . The particular page actually seems to work properly but then it halts and displays a blank page. I tried to import the js files manually instead of using the tag, and "struts/ajax/dojoRequire.js" seems troubling. Then turned the debug mode on and the following error came up: DEBUG: failed loading /[appname]/struts/dojo/src/widget/RichText.js with error: [TypeError: setting a property that has only a getter, file: http://localhost:8080/[appname]/struts/dojo/dojo.js, line: 131] I reckon it's an issue concerning firefox 3 since the same app works on IE7, Firefox2, Opera and Safari. Anyone knows if its a reported bug of Firefox3 or Struts2? Regards >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Firefox3-seems-to-jam-with-the-struts2-ajax-theme-tp18377641p18539074.html 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: hacking OGNL and parameter binding
Musachy Barroso wrote: I opened a code review here: http://fisheye6.atlassian.com/cru/CR-9 I added a new interface ClearableValueStack, which if implemented will make the OGNL parameter binding run in a clean context. I'm not sure how to get permission to make comments in crucible. General comment: Seems okay, but need to check impact on the s:action tag and chain result. From memory, they create an invocation that set params of the next action via the param interceptor (?) and assume the context is not cleared. I could be wrong about that, but I don't recall the params being set by any other means. Any estimate on the potential performance hit of creating a new stack? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
