Hi Stefan,
On the backend, RPC should not be linked to session.
Session should be managed on server side before reaching RPC.
RPC services are classes that should be singleton, no need to instanciate more
than once, and this instance should be reached by thread, like a Servlet,
inside or outside session, this should not be linked.
Once you managed HTTP/JEE session before reaching RPC, in a filter for example
or in your RPC servlet but before the RPC lib provided by the RPCJava contrib,
you can do what you want and JEE is very simple for that.
On the client side, you don't have to pass the jsessionid token or anything
else, this is all automatic from Java point of view.
On each HTTP request, all cookies are passed (this is due to HTTP protocol) and
that's how jsessionid is transferred and how Java handle it for you on server
side.
That way, you can use session in the service without problem but I would advice
not to do so to maintain service independent from the underlying techno.
I advice to pass extra param to the service : the needed value you find in the
session become function param that are pass to the service at the entry point
of the server side.
That way, this extra param are not seen as param from the rpc client side but
the session do not pollute service that can stay functional/business things.
By the way, we gave a contribution called RPCJavaPOJO, a very ugly name for a
good contribution ;-)
This Java RPC is more open and configurable than RPCJava (and also quicker) but
the software architecture assumption differs.
We are working at attribute level and not using accessors for RPC which is good
practice.
This allow the code to rely on transient Java keyword that apply to attribute.
This allow not to have accessor only for RPC but only because it is needed :
putting accessor everywhere simply break encapsulation.
Finally, you can have accessor or not : no impact on RPC.
To avoid serialization, use transient, it is there for that purpose.
Serializable classes must implement standard Serializable interface, this is
the only constraint we have.
On 28 oct. 2010, at 10:44, Stefan Andersson wrote:
> We have been dealing with some session problems regarding rpc.
>
> The manual says:
>
> "There is one instance of a service class per session."
>
> - It can be interpreted as every rpc service call made gets a new session.
> This is really what happens.
> - Cookies turn on means session id is saved locally for the browser.
>
> What is the best way to let the session survive many rpc service calls within
> the same Rpc object? What alternatives do you see we have? i.e. transporting
> ?jsessionid= with the url etc
>
> Stefan
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev_______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
