Expand my Community achievements bar.

FlexSessionBindingListener bug?

Avatar

Level 2
I have created a class implementing this interface, but it's
method "valueUnbound" does never get called when my HttpFlexSession
object is invalidated (and I do store attributes on this session
during it's lifetime).



Do "FlexSessionBindingListener" implementations need to be
explicitly registered, and if so, how?



Thanks..





7 Replies

Avatar

Level 1
you need to register it or in web.xml or in
services-config.xml (latter requires it to extend
AbstractBootstrapService)



here is my services-config.xml

<services>

<service-include file-path="messaging-config.xml" />

<service-include file-path="remoting-config.xml" />

<service-include file-path="proxy-config.xml" />

<service-include file-path="data-management-config.xml"
/>

<service class="my.package.MySessionListener"
id="my-session-listener-service"
messageTypes="flex.messaging.messages.AsyncMessage"/>

</services>

Avatar

Level 2
Thanks... really? But in a classic J2EE scenario you don't
need to register the HttpSessionBindingListener implementations...
and the framework calls their "valueBound" and "valueUnbound"
methods whenever it is appropriate.




http://tomcat.apache.org/tomcat-5.5-doc/servletapi/index.html



Back to Flex/FDS case... as my attribute being bound to a
HttpFlexSession implements the FlexSessionBindingListener listener,
I would expect the framework (FDS) to call its methods when the
session gets invalidated, correct? So no XML configuration settings
are required.



Basically, what I'm doing:



FlexSession fs = FlexContext.getFlexSession();

fs.setAttribute("test", new FlexSessionBinding());

..................................



private class FlexSessionBinding implements
FlexSessionBindingListener

{

...................



/**

* Session 'Bound' notification

*/

public void valueBound(FlexSessionBindingEvent event)

{

........................

} // valueBound



/**

* Session 'Unbound' notification

*/

public void valueUnbound(FlexSessionBindingEvent event)

{

// Cleanup resources held by the service

.......................................

} // valueUnbound

............................

} // end of class FlexSessionBinding



The valueUnbound() method does not get called when the
session is invalidated.

Avatar

Level 1
yes, messed it up a bit with my case with SessionListener,
sorry

Avatar

Level 1

quote:




Originally posted by:
Robert Csiki
The valueUnbound() method does not get
called when the session is invalidated.

did you try manually remove the attribute from
session? will the valueUnbound() be called then?



Avatar

Level 2
Yes, if I programatically remove the attribute, the
"valueUnbound()" method gets called by the framework. But I would
expect the same when the HttpFlexSession objects gets invalidated
by calling its "invalidate()" method (or when it times out).



I thought these FDS session wrappers work the same as
javax.servlet.http.HttpSession. Or maybe they do and it's
just a FDS bug?

Avatar

Level 3
I didn't try invalidate(), but I tried session timeout and it
work. I put debug printout in my java class, and I could see the
unbound



[Flex] 09:52:04.716 [INFO] [QA.Client] session -
attributeRemoved

[Flex] 09:52:04.716 [INFO] [QA.Client] session - valueUnbound

[Flex] 09:52:04.716 [INFO] [QA.Client] session -
attributeRemoved

[Flex] 09:52:04.716 [INFO] [QA.Client]
clientDestroyed81C1F4D4-790D-D3E9-2650-3462DFD39A48

[Flex] 09:52:04.716 [INFO] [QA.Client] client -
valueUnboundflex.messaging.client.FlexClient@bb8ae8,test,null

[Flex] 09:52:04.716 [INFO] [QA.Client] client -
attributeRemovedflex.messaging.client.FlexClient@bb8ae8,test,qos.ClientA

ttribute@9cb7fc

[Flex] 09:52:04.716 [INFO] [QA.Client] Session
Destroyeda630783bf8af5f7e727b



I just checked what the invalidate() method. It calls the
session destroyListener first before it remove all attributes. This
might be the problem



William Chan

Avatar

Level 2

quote:




Originally posted by:
aBill


I just checked what the invalidate() method. It calls the
session destroyListener first before it remove all attributes. This
might be the problem



William Chan





Thanks William. Clearly a bug.