Hi Peter,
I'll ask Howard to verify what I say here as its a pretty important
issue. Short answer: Yes, you will get the same instance using the state
manager as you would from injection via @ApplicationState... for
simultaneous requests made by the same user (and therefore the same
request/session).
That is a very simplified answer. Its important to understand why you
can use @ApplicationState in a page but not in a singleton service. If
you read both wikis and/or docs on the state manager, you should already
have a basic understanding. Under the hood, T5 IoC uses the state
manager to retrieve page members marked as state objects with the
@ApplicationState annotation. Why? Because an instance of a page class
may be accessed simultaneously by many different requests at the same
time. In reality the annotation is just an indicator that a page member
is specific to the current request, NOT the page. Its up to the IoC
container to resolve exactly what request (session) is associated with
the requesting user, and ultimately which instance of your ASO class.
I'm quite sure this work is done by the state manager.
hope that helps
sincerely,
chris
Peter Stavrinides wrote:
Hi Chris,
Thanks for the great wiki article, I have managed to implement what I
needed using 'Tapestry5HowToCreateADispatcher2'. My implementation is
very similar to the example... it seems to work great!
One question though regarding my ASO (which is similar to your
permissions ASO), you mention "the object referenced by 'perms' is an
instance specific to the current request" does this mean that I will
*not* get the very same instance if I try inject it in a page class
using the @ApplicationState annotation?
Thanks
Peter
Chris Lewis wrote:
Hello Peter,
It sounds like by 'filter' you mean a servlet filter and not a
Tapestry filter. Your requirements sound a tad exotic to me, but
these wikis should get you on the right track:
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher
http://wiki.apache.org/tapestry/Tapestry5HowToCreateADispatcher2
They focus on implementing authentication/restriction code completely
outside of the 'page' level of the application. The focus on these is
the required infrastructure, so there are some holes left to be
filled. At any rate they should be useful for you. Note that the same
thing can be achieved using a Tapestry filter:
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/RequestFilter.html
Sincerely,
Chris
Peter Stavrinides wrote:
Hi all
My question is more of a best practice related question, I want to
use a filter to extract my authentication code from the rest of the
application logic, so I can avoid adding this logic to pages. In
addition, one of my authentication requirements involves some
integration with third party applications so I need to check for
authentication headers... to accommodate this I use a session state
object in my app (i.e. a T5 service), which is available for the
duration of a users session.
Implementing an ordinary servlet filter would do the trick for the
authentication part... but then I wouldn't be able to use it with
the IoC service. So:
1. Is there a way to register my filter with Tapestry IoC instead of
registering it in web.xml? (would I create a contribution to the
framework?)
2. Can I inject this service (i.e. my state object )into the
filter? and what does this involve i.e. eager loading etc?
I am not sure I am going about this the right way, if someone has
done something similar could I get some pointers.
Thanks in advance,
Peter
---------------------------------------------------------------------
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]
