Part of the problem is that to grab the user object, I need access to
a session, and sessions are not thread safe. So either I have a
service that uses a long-lived session with user objects loaded by
synchronized methods. Or my requestfilter is made per-thread with a
session, or HibernateSessionSource injected in, which loads the
object, sets it on the ASO manager, and then detachs that user object
before cleaning up the session.
So basically, the filter sees if a user is auth'd for a path, if so,
populates the user object, otherwise invalidates the httpsession, and
kicks the user out.
Damned if I do/don't.
On Thu, Apr 9, 2009 at 9:49 PM, daniel joyce <daniel.a.jo...@gmail.com> wrote:
> Still confused. So buildMethods allow proxies/per-thread? But using
> constructor style doesn't? Even if the class passed to autobuilding is
> annotated per-thread?
>
> On Thu, Apr 9, 2009 at 8:58 PM, Robert Zeigler <robe...@scazdl.org> wrote:
>> Yes, build methods go in the app module.
>>
>> RequestFilters: depends on how you build them, but if you construct them as
>> a bonafide service (rather than autobuilding) they will be proxied, and are
>> therefore elligible for "per thread scope".
>>
>> That said, I've never used a per-thread RequestFilter. Rather, I tend to
>> inject per-thread services into my RequestFilter implementation. For
>> example, ApplicationStateManager is a per-thread-scoped service. So even
>> through my filter isn't per thread, it's accessing thread-specific data when
>> it accesses data from the ApplicationStateManager service.
>>
>> Robert
>>
>> On Apr 9, 2009, at 4/99:52 PM , daniel joyce wrote:
>>
>>> Also, build methods go in the appmodule, right?
>>>
>>> Guess it wasn't my final question. :)
>>>
>>> Also, are RequestFilters per-Thread, or Singleton? Can they be
>>> per-thread if needed?
>>>
>>> -Daniel
>>>
>>> On Thu, Apr 9, 2009 at 7:42 PM, daniel joyce <daniel.a.jo...@gmail.com>
>>> wrote:
>>>>
>>>> I also found a HttpServletRequestFilter.
>>>>
>>>> Thanks for the response, it helps to explain a lot.
>>>>
>>>> I am finding my biggest problem is the documentation. I have OReilley
>>>> safari access, and the Tapestry 5 book there leaves out about half
>>>> features. What is needed is a tapestry cookbook/recipe style thing.
>>>> How to make a service, How to make a filter.
>>>>
>>>> One final question. In the document examples on service building,
>>>> sometimes the build method is called build, othertimes buildFoo where
>>>> foo is the service being built. Which is correct, or does it matter?
>>>>
>>>> -Daniel
>>>>
>>>> On Thu, Apr 9, 2009 at 7:10 PM, Robert Zeigler <robe...@scazdl.org>
>>>> wrote:
>>>>>
>>>>> Autobuilder vs. builder vs. constructor:
>>>>>
>>>>> Depends on your needs. These aren't mutually exclusive, either.
>>>>>
>>>>> a) Tapestry's ioc container will attempt to use an "ObjectLocator" to
>>>>> fill
>>>>> in the arguments to the constructor; one such object provider is a
>>>>> service
>>>>> injection provider.
>>>>> So, though it used to be that you /had/ to specify @InjectService on
>>>>> constructor arguments, it's not so anymore. There are cases where using
>>>>> @InjectService with a specific service id is still useful (to avoid
>>>>> dependency recursion issues, for example). But often, you can just put
>>>>> the
>>>>> service interface in and have it "work".
>>>>>
>>>>> b) Builder: a builder method is useful when you're constructing certain
>>>>> types of services. For example, pipelines. You might use tapestry's
>>>>> pipeline builder service to build your pipeline for you, so you don't
>>>>> have
>>>>> an actual "PipelineXImpl" class lying around; instead, you use a builder
>>>>> method to construct the service "on the fly".
>>>>>
>>>>> c) Autobuilding - the ability to "autobuild" objects is very nice.
>>>>> Typically, I use this when the object I'm building is /not/ a
>>>>> "standalone
>>>>> service" that I'm going to reference from somewhere else (not something
>>>>> that
>>>>> will directly injected or contributed to). In that sense, the
>>>>> CayenneRequestFilter could have been autobuilt, since I could have done
>>>>> a
>>>>> "contributeRequestHandler(OrderedConfiguration<RequestFilter> conf,
>>>>> @Autobuild CayenneRequestHandler handler) {...}
>>>>>
>>>>> I don't need to inject CayenneRequestHandler anywhere else, so there's
>>>>> no
>>>>> real need to define it as a separate service. But @Autobuild didn't
>>>>> exist
>>>>> when I wrote the module. ;)
>>>>> If I were to write it today (or refactor it today), I would probably use
>>>>> @Autobuild for that one. Keep in mind that @Autobuild is going to use
>>>>> the
>>>>> constructor parameters to determine what to inject*. :)
>>>>>
>>>>> Regarding HttpServletRequest, if you need it directly, you can inject
>>>>> it, as
>>>>> tapestry provides a thread-based proxy around it. Something like:
>>>>>
>>>>> public MyRequestFilter implements RequestFilter {
>>>>>
>>>>> private final HttpServletRequest servletRequest;
>>>>>
>>>>> public MyRequestFilter(HttpServletRequest request) {
>>>>> servletRequest = request;
>>>>> }
>>>>>
>>>>> public boolean service(Request request, Response response,
>>>>> RequestHandler handler)
>>>>> {
>>>>> //do stuff with the servlet request.
>>>>> return handler.service(request,response);
>>>>> }
>>>>> }
>>>>>
>>>>> Robert
>>>>>
>>>>> * Recently, field-based injection support was added for services, so
>>>>> this
>>>>> isn't strictly true anymore. But I still prefer constructor injection
>>>>> for
>>>>> services.
>>>>>
>>>>> On Apr 9, 2009, at 4/95:54 PM , daniel joyce wrote:
>>>>>
>>>>>> How/where do I inject it? It's not obvious from the docs on when/how I
>>>>>> should user autobuilder vs builder vs constructor.
>>>>>>
>>>>>> The docs say you need to inject services explicitely inside the
>>>>>> constructor, yet the CayenneRequestFilter has a constructor w/o Inject
>>>>>> annotations.
>>>>>>
>>>>>> Also, the Tapestry 5 Request object supposedly wraps the
>>>>>> HttpServletRequest ( where remote user is set ), but provides no way
>>>>>> to get the raw request, from which I can grab RemoteUser which tells
>>>>>> me which user tomcat logged in.
>>>>>>
>>>>>> -Daniel
>>>>>>
>>>>>> On Thu, Apr 9, 2009 at 1:57 PM, daniel joyce <daniel.a.jo...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Awesome, Thanks!
>>>>>>>
>>>>>>> So far, the nice thing about Tapestry has been its very fluid
>>>>>>> component based nature. I am so used to having to do things in a
>>>>>>> certain order with other frameworks. Here, things are very orthogonal,
>>>>>>> and my reasoning about how to use Tapestry keeps improving.
>>>>>>>
>>>>>>> -Daniel
>>>>>>>
>>>>>>> On Thu, Apr 9, 2009 at 12:51 PM, Robert Zeigler <robe...@scazdl.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Here's a sample request filter that plays with application state
>>>>>>>> objects
>>>>>>>> (which are backed by the http session):
>>>>>>>>
>>>>>>>>
>>>>>>>> http://code.google.com/p/tapestry5-cayenne/source/browse/trunk/tapestry5-cayenne-core/src/main/java/com/googlecode/tapestry5cayenne/services/CayenneRequestFilter.java
>>>>>>>>
>>>>>>>> You can also use the tapestry-provided Request object (which wraps
>>>>>>>> HttpServletRequest), which provides access to the wrapper "Session"
>>>>>>>> object.
>>>>>>>> You can also directly inject HttpServletRequest.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>> On Apr 9, 2009, at 4/92:11 PM , daniel joyce wrote:
>>>>>>>>
>>>>>>>>> What about using a requestfilter? Any better docs on how to
>>>>>>>>> implement
>>>>>>>>> one? I see bits and pieces here and there, but nothing as coherent
>>>>>>>>> as
>>>>>>>>> the Dispatcher howto.
>>>>>>>>>
>>>>>>>>> -Daniel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 9, 2009 at 11:38 AM, daniel joyce
>>>>>>>>> <daniel.a.jo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I looked at spring security, and it required yet-another
>>>>>>>>>> annotation,
>>>>>>>>>> and annotating a class to protect it didn't protect the methods as
>>>>>>>>>> well. This struck me as too hit-or-miss
>>>>>>>>>>
>>>>>>>>>> With Tomcat, I can simply protect whole paths or pages, no need to
>>>>>>>>>> worry about annotating a class, and then annotating each method.
>>>>>>>>>> Bit
>>>>>>>>>> too fine-grained for my needs.
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 9, 2009 at 11:00 AM, manuel aldana <ald...@gmx.de>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Maybe you should look at the tapestry-spring-security plugin
>>>>>>>>>>>
>>>>>>>>>>> (http://www.localhost.nu/java/tapestry-spring-security/index.html).
>>>>>>>>>>> It
>>>>>>>>>>> works
>>>>>>>>>>> great and integrating is also not that difficult.
>>>>>>>>>>>
>>>>>>>>>>> Good thing is that you can both secure by single page or by page
>>>>>>>>>>> folders.
>>>>>>>>>>>
>>>>>>>>>>> Beware that it is not compatible with 5.1.x yet (works only for
>>>>>>>>>>> 5.0.18).
>>>>>>>>>>>
>>>>>>>>>>> daniel joyce schrieb:
>>>>>>>>>>>>
>>>>>>>>>>>> So I want to use pages with context so that it is easily
>>>>>>>>>>>> bookmarkable.
>>>>>>>>>>>>
>>>>>>>>>>>> My website uses a DataSourcerealm to determine which pages can be
>>>>>>>>>>>> accessed by a user.
>>>>>>>>>>>>
>>>>>>>>>>>> So normal flow is user logs in, first page he gets directed to
>>>>>>>>>>>> sets
>>>>>>>>>>>> up
>>>>>>>>>>>> the User object as a ASO, other pages use this user.
>>>>>>>>>>>>
>>>>>>>>>>>> But if he bookmarks a url with context, say
>>>>>>>>>>>> "configureProject/124332",
>>>>>>>>>>>> and he clickes on the bookmark, logs in to tomcat, and gets
>>>>>>>>>>>> redirected
>>>>>>>>>>>> to it, the User object may not have been initialized yet. Now
>>>>>>>>>>>> configure project is fine, since it is mostly working with
>>>>>>>>>>>> projects.
>>>>>>>>>>>> But I want the user object to exist so that I confirm the user
>>>>>>>>>>>> actually owns it.
>>>>>>>>>>>>
>>>>>>>>>>>> Now I could have a basepage, whose onActivate() grabs the auth'd
>>>>>>>>>>>> user
>>>>>>>>>>>> string from the Httpsession, runs a query, and either sets up the
>>>>>>>>>>>> User
>>>>>>>>>>>> object, or bounces out the login page. And every other page could
>>>>>>>>>>>> inherit from this one, and call super.OnActivate in their
>>>>>>>>>>>> onActivate
>>>>>>>>>>>> method.
>>>>>>>>>>>>
>>>>>>>>>>>> But I was wondering, is there a service I can write that can
>>>>>>>>>>>> examine
>>>>>>>>>>>> the HttpSession, and populate the User object. Is HttpSession
>>>>>>>>>>>> available to services already? IE, can I inject it in the usual
>>>>>>>>>>>> method
>>>>>>>>>>>> via my builder?
>>>>>>>>>>>>
>>>>>>>>>>>> -Daniel
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> manuel aldana
>>>>>>>>>>> ald...@gmx.de
>>>>>>>>>>> software-engineering blog: http://www.aldana-online.de
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
