You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Muhammad Gelbana <m....@gmail.com> on 2013/08/29 15:45:26 UTC
[5.3.7] Integrating Metro web services (Using Derkoe's code)
I'm using Derkoe's code to integration Metro with Tapestry.
I'm still not fully aware of what I'm doing...but that's fine, its working
:D
I only need to enable session management in my tapestry code to refer to
session stored values.
I edited this filter class to obtain the username\password from the
request's headers (i.e. I know this isn't a standar but it will be agreed
upon with the web-service consumer)
https://github.com/derkoe/tapestry-jaxws/blob/master/src/main/java/org/apache/tapestry/jaxws/internal/metro/MetroHttpServletRequestFilter.java
So how can I instruct tapestry to start a session ?
And how can I refer to session-stored objects from within a service just as
its done from a tapestry page ? Is that even possible ?
Regards
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 30 Aug 2013 17:51:17 -0300, Muhammad Gelbana <m....@gmail.com>
wrote:
> I'm asking because having a maintained session between the client and the
> server is a better scenario. Instead of having to authenticate the user's
> credentials upon every request.
As far as I know, that's how almost any webservice works and you're
swimming against the tide here. As Lance already said, doing this or not
depends on what the client is. If it uses HttpClient, it already supports
cookies, so you don't need to change anything server-side. If not, then we
need to know how the client is implemented to give y
> I'm aware there are other standard methods to have a statefull web
> service, but I haven't explored that area yet, and I thought it could be
> done faster and easier using the
> ApplicationStateManager. Frankly the idea is not fully developed in my
> head.
The problem with this is that you have to handle the session creation
yourself and knowing which session should be used in a given request.
That's a difficult problem that, if not implemented very, very carefully,
can lead to session hijacking and other security problems.
ApplicationStateManager is the service that handles the @SessionState
annotation, so you can override, advice or decorate to make it work anyway
you want.
> Also I always like exploring all possible options to always be free to
> chose whatever fit my needs more, and I always like to know more Tapestry
> tricks.
Nice. :) The problem here, if I got it right, is that you want to replace
a functionality which isn't implemented by Tapestry itself (session
handling), being implemented by servlet containers instead. Of course, you
can take a look at the sources of Jetty and Tomcat to know how they deal
with sessions.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
>
> Why are you asking that? Any specific need?
I'm asking because having a maintained session between the client and the
server is a better scenario. Instead of having to authenticate the user's
credentials upon every request. I'm aware there are other standard methods
to have a statefull web service, but I haven't explored that area yet, and
I thought it could be done faster and easier using the
ApplicationStateManager. Frankly the idea is not fully developed in my head.
Also I always like exploring all possible options to always be free to
chose whatever fit my needs more, and I always like to know more Tapestry
tricks.
I haven't used any other web framework and IoC other than Tapestry and I'm
not planning to do so anytime soon. It's a very good framework and I love
using it. So I'm always trying to find out ways to tweak it in every way
possible.
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Fri, Aug 30, 2013 at 6:58 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Fri, 30 Aug 2013 12:15:00 -0300, Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> I have one last question. Is it possible to instruct the
>> ApplicationStateManager to manage it's sessions using something else than
>> a HTTP based request (i.e. Whether its *HttpServletRequest* or Tapestry's *
>> Request*) ?
>>
>
> Tapestry's Request is just a thin layer over HttpServletRequest. Same for
> Session and HttpSession. So, in the end, it's actually the servlet
> container the one implementing the session handling. You can override,
> advise or decorate the ApplicationStateManager and implement it any way you
> want. I never had a situation that needed that. Why are you asking that?
> Any specific need?
>
>
> This has been fruitful discussion, thanks a lot :)
>>
>
> :)
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 30 Aug 2013 12:15:00 -0300, Muhammad Gelbana <m....@gmail.com>
wrote:
> I have one last question. Is it possible to instruct the
> ApplicationStateManager to manage it's sessions using something else
> than a HTTP based request (i.e. Whether its *HttpServletRequest* or
> Tapestry's *
> Request*) ?
Tapestry's Request is just a thin layer over HttpServletRequest. Same for
Session and HttpSession. So, in the end, it's actually the servlet
container the one implementing the session handling. You can override,
advise or decorate the ApplicationStateManager and implement it any way
you want. I never had a situation that needed that. Why are you asking
that? Any specific need?
> This has been fruitful discussion, thanks a lot :)
:)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
I have one last question. Is it possible to instruct the
ApplicationStateManager to manage it's sessions using something else than a
HTTP based request (i.e. Whether its *HttpServletRequest* or Tapestry's *
Request*) ?
This has been fruitful discussion, thanks a lot :)
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Fri, Aug 30, 2013 at 12:28 PM, Lance Java <la...@googlemail.com>wrote:
> IMO using the session in a webservice is a bad idea. It's much better to
> keep it stateless and pass the required info in each request.
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Lance Java <la...@googlemail.com>.
IMO using the session in a webservice is a bad idea. It's much better to
keep it stateless and pass the required info in each request.
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Lance Java <la...@googlemail.com>.
It depends how you are making the webservice call. Apache HTTPClient can
handle cookies and I'm sure many other web service libraries out there can
too.
If you are using java.net.URL directly then you won't have session / cookie
management on the client.
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
Didn't know it was that simple ! Thanks a lot :)
Now ApplicationStateManager (ASM) can be injected and used.
But there is another problem. I'm still not sure but I don't think web
services keep cookie sessions !
So If I facilitate session-id generation and send back a session-id to the
client when he logs in using a web-service call.
So the client will have to send me that session-id with over successive
call.
How can I tell ASM to use that session-id to get\set objects specific to
that session-id ?
I have a strong feeling I'll get another "I don't see a problem?" reply,
this is going to be simple too, correct ? :D
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Fri, Aug 30, 2013 at 9:24 AM, Lance Java <la...@googlemail.com>wrote:
> Why can't you use a RequestFilter?
>
> The HttpServletRequest has been set on RequestGlobals by the time the
> RequestFilters are invoked. So you can @Inject HttpServletRequest in your
> RequestFilter (or any service called by your RequestFilter). If you need to
> wrap the HttpServletRequest, you can @Inject RequestGlobals and call
> storeServletRequestResponse(…).
>
> I don't see a problem?
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Lance Java <la...@googlemail.com>.
Why can't you use a RequestFilter?
The HttpServletRequest has been set on RequestGlobals by the time the
RequestFilters are invoked. So you can @Inject HttpServletRequest in your
RequestFilter (or any service called by your RequestFilter). If you need to
wrap the HttpServletRequest, you can @Inject RequestGlobals and call
storeServletRequestResponse(…).
I don't see a problem?
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
*@Lance*
I tried implementing a RequestFilter instead but it looks like Derkoe
didn't do that in the first place for a reason. At some point, I need to
have a HttpServleRequest object, which cannot be obtained from Tapestry's
Request object.
*@Thiago*
I can't use a per-thread service. The user needs to send his credentials
once.
[OT]
On a second thought. Web service clients aren't actually browsers and they
don't deal with cookies, so they can't manage session-ids, or can they ?
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Thu, Aug 29, 2013 at 7:39 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 29 Aug 2013 12:11:32 -0300, Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> But I need to initially store some values and retrieve them later on.
>>
>> If I inject the *ApplicationStateManager* in the filter and store values
>> in it, then retrieve these values later on through a tapestry service. How
>>
>> will tapestry know which session is currently active ?
>>
>
> The one used in the given thread, supposing the thread is an HTTP request.
>
> Shouldn't I wire the *ApplicationStateManager* service with the request
>> session id somewhere ?
>>
>
> No.
>
> Also after reviewing the api doc for the *ApplicationStateManager
>> *service:
>>
>> http://tapestry.apache.org/**current/apidocs/org/apache/**
>> tapestry5/services/**ApplicationStateManager.html<http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ApplicationStateManager.html>
>>
>> What does SSO mean ?
>>
>
> "Responsible for managing *session state objects*, objects which persist
> between requests, but are not tied to any individual page or component.
> SSOs are also created on demand. SSOs are typically stored in the session,
> so that they are specific to a particular client."
>
> Probably the best option for you is to define a per-thread service
> wrapping the data you want to pass around instead of putting them in the
> session (supposing you don't need to keep this data between different
> threads).
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 29 Aug 2013 12:11:32 -0300, Muhammad Gelbana <m....@gmail.com>
wrote:
> But I need to initially store some values and retrieve them later on.
>
> If I inject the *ApplicationStateManager* in the filter and store values
> in it, then retrieve these values later on through a tapestry service.
> How
> will tapestry know which session is currently active ?
The one used in the given thread, supposing the thread is an HTTP request.
> Shouldn't I wire the *ApplicationStateManager* service with the request
> session id somewhere ?
No.
> Also after reviewing the api doc for the *ApplicationStateManager
> *service:
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ApplicationStateManager.html
>
> What does SSO mean ?
"Responsible for managing *session state objects*, objects which persist
between requests, but are not tied to any individual page or component.
SSOs are also created on demand. SSOs are typically stored in the session,
so that they are specific to a particular client."
Probably the best option for you is to define a per-thread service
wrapping the data you want to pass around instead of putting them in the
session (supposing you don't need to keep this data between different
threads).
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Lance Java <la...@googlemail.com>.
I think you need to be aware of how the request, httpsession and response
objects work in tapestry. Ultimately they are proxies that lookup values
from RequestGlobals.
1. RequestGlobals.storeServletRequestResponse(…) is called
2. The HttpServletRequestFilters run
3. RequestGlobals.storeServletRequestResponse(…) is called again
4. RequestGlobals.storeRequestResponse(…) is called
5. The RequestFilters are run
6. RequestGlobals.storeRequestResponse(…) is called again
Since you are using a HttpServletRequestFilter and not a RequestFilter, the
Request and Response are not set yet. You should use the HttpServletRequest
instead of Request.
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
I guess this exception explains what I'm talking about
java.lang.NullPointerException: Unable to delegate method invocation to
property 'request' of <Proxy for
RequestGlobals(org.apache.tapestry5.services.RequestGlobals)>, because the
property is null.
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Thu, Aug 29, 2013 at 5:11 PM, Muhammad Gelbana <m....@gmail.com>wrote:
> But I need to initially store some values and retrieve them later on.
>
> If I inject the *ApplicationStateManager* in the filter and store values
> in it, then retrieve these values later on through a tapestry service. How
> will tapestry know which session is currently active ?
>
> Shouldn't I wire the *ApplicationStateManager* service with the request
> session id somewhere ?
>
> Also after reviewing the api doc for the *ApplicationStateManager *
> service:
>
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ApplicationStateManager.html
>
> What does SSO mean ?
>
> Thanks you
>
> *---------------------*
> *Muhammad Gelbana*
> Java Software Engineer
>
>
> On Thu, Aug 29, 2013 at 4:48 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Thu, 29 Aug 2013 10:45:26 -0300, Muhammad Gelbana <m....@gmail.com>
>> wrote:
>>
>> I only need to enable session management in my tapestry code to refer to
>>> session stored values.
>>>
>>
>> If they're stored by @SessionState, just use the ApplicationStateManager
>> service. If they're set directly into the HttpSession, @Inject the Request
>> and use it getSession() method to grab the session.
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Muhammad Gelbana <m....@gmail.com>.
But I need to initially store some values and retrieve them later on.
If I inject the *ApplicationStateManager* in the filter and store values in
it, then retrieve these values later on through a tapestry service. How
will tapestry know which session is currently active ?
Shouldn't I wire the *ApplicationStateManager* service with the request
session id somewhere ?
Also after reviewing the api doc for the *ApplicationStateManager *service:
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ApplicationStateManager.html
What does SSO mean ?
Thanks you
*---------------------*
*Muhammad Gelbana*
Java Software Engineer
On Thu, Aug 29, 2013 at 4:48 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 29 Aug 2013 10:45:26 -0300, Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> I only need to enable session management in my tapestry code to refer to
>> session stored values.
>>
>
> If they're stored by @SessionState, just use the ApplicationStateManager
> service. If they're set directly into the HttpSession, @Inject the Request
> and use it getSession() method to grab the session.
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [5.3.7] Integrating Metro web services (Using Derkoe's code)
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 29 Aug 2013 10:45:26 -0300, Muhammad Gelbana <m....@gmail.com>
wrote:
> I only need to enable session management in my tapestry code to refer to
> session stored values.
If they're stored by @SessionState, just use the ApplicationStateManager
service. If they're set directly into the HttpSession, @Inject the Request
and use it getSession() method to grab the session.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org