AFAIK exceptions are always thrown directly and bring up the error page
as ssoon as the are thrown -
There is one thing which is somehow delicate: if you try to set a
property through OGNL and it can not be set because of an incompatible
class (say you try to set object Foo to a property which takes only
Bars) , the value will be silently dropped.
This is very bad, because you will eventually get a NullPointerException
- you will have to debug and search for quite some time until you
realize the problem...
This is a none issue in OGNL - has nothing to do with Tapestry though...
Cheers,
Ron
Adam Zimowski wrote:
Thank You Ron. I digged deeper on this before going to sleep and came
to the same conlusion.. I also figured out the problem with
HttpSessionAttributeListener. It was ofcouse my silly casting error
that caused ClassCastException be thrown inside the attribute listener
method.
However, is this a bug in Tapestry? It seems to me like Tapestry is
catching exceptions in SessionAttributeListener and not bubbling them
up. This has caused me all the grief to begin with. Shouldn't the
Tapestry throw back the exception so that I know what's going on?
Once I corrected my listener method I saw the key Tapestry is using to
map all attributes and it all became obvious.
On 3/2/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
a persistant property (session) is tied to a single component on a
single page - also if you use it inside a component, when using the same
component on another page the value will not be kept.
a state object is shared by all components/pages.
Cheers,
Ron
Adam Zimowski wrote:
Hi,
I noticed that whether I do:
@Persist("session")
public abstract void setMemberId(Long id);
or
@InjectState("memberId")
public abstract void setMemberId(Long id);
new session is created. However, my:
@InjectStateFlag("memberId")
public abstract boolean isLoggedIn();
returns true only if I set member id thru @InjectState, but returns
false if I set the member id thru @Persist("session"). I don't
understand why, afterall both are creating a session attribute right?
And if so, how come my HttpSessionAttributeListener is not reporting
anything no matter how I set member id? Yet HttpSessionListener
clearly shows that session does get created.
public class HttpSessionSniffer extends LogableObject implements
HttpSessionListener, HttpSessionAttributeListener {
public void sessionCreated(HttpSessionEvent arg0) {
if (sDbg())
_sLog.debug("session created: " +
arg0.getSession().getId());
}
public void attributeAdded(HttpSessionBindingEvent arg0) {
if (sDbg())
_sLog.debug(arg0.getName() + " " + (String)
arg0.getValue());
}
public void attributeRemoved(HttpSessionBindingEvent arg0) {
if (sDbg())
_sLog.debug(arg0.getName() + " " + (String)
arg0.getValue());
}
public void attributeReplaced(HttpSessionBindingEvent arg0) {
if (sDbg())
_sLog.debug(arg0.getName() + " " + (String)
arg0.getValue());
}
}
---------------------------------------------------------------------
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]
