I like that idea actually, moving this logic into an interceptor, but i still think
ActionContext.getContext().getSession() should not be returning null when used in a sitemesh decorator.
Jason Carreira wrote:
You could have it populate this boolean during execution, or pull this
into an Intercep
Jason Carreira wrote:
webwork.configuration.xml.reload=true
In your webwork.properties to tell it to check and automatically reload
XML configuration files (this includes the xwork.xml file and any other
included xwork configuration files, validation.xml files, and type
conversion .properties file
You could have it populate this boolean during execution, or pull this
into an Interceptor. I don't think leaving around leftover state in a
ThreadLocal is the way to go, though...
> -Original Message-
> From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2003
the tags work fine in sitemesh decorators as it stands, but the problem is that i need
to use
ActionContext.getContext().getSession() and that returns null when used inside of a
sitemesh decorator
Im using ActionContext.getContext().getSession() inside the decorator to do the typical checking of
You can set
webwork.configuration.xml.reload=true
In your webwork.properties to tell it to check and automatically reload
XML configuration files (this includes the xwork.xml file and any other
included xwork configuration files, validation.xml files, and type
conversion .properties files right
OK... Will do, thanks.
> -Original Message-
> From: BOGAERT Mathias [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2003 9:43 AM
> To: [EMAIL PROTECTED]
> Subject: [OS-webwork] Small exception problem
>
>
> Can someone add a space to
>
> throw new XworkException("Action class "
The purpose is for each ActionInvocation to have its own ActionContext
which is only active while the ActionInvocation is being executed (as
managed by the ActionProxy).
If, for instance, you chain to another Action, that nested Action should
have its own ActionContext which is available while it
Hi,
I have encountered what is to me a serious usability issue with XWork. I
am using it deployed in a .war in Jboss, where hot redeploy greatly
reduces update times during the development process. To reduce the size
of the created .war files, I store the xwork/webwork jars in the JBoss
server
Can someone add a space to
throw new XworkException("Action class " + actionClass.getClass().getName()
+ "does not implement " + Action.class.getName(), e);
Before 'does not implement' at
com.opensymphony.xwork.DefaultActionInvocation.createAction(DefaultActionInv
ocation.java:212)
Thanks,
Mathi
AFTER-HOURS TRADING - BREAKING NEWS
Get Quote - http://quote.money.cnn.com/quote/quote?symbols=htds
Hard to Treat Diseases Incorporated - HTDS - Announces: Receipt of Tubercin Toxicity
Study and Formation of Scientific Advisory Panel - Wednesday December 3, 8:04 pm ET
DELRAY BEACH, Fla.--(BUSIN
For some reason, I couldn't edit the Xwork Interceptors page so I added it
to http://wiki.opensymphony.com/space/WebWork+2+Interceptors instead (down
the bottom).
It _seriously_ needs fleshing out so i'll take you up on that offer:
http://wiki.opensymphony.com/space/Chaining+Interceptor
Anyone wh
11 matches
Mail list logo
