[seam-dev] Seam 3 porting issues

[Dan Allen]

On Tue, May 5, 2009 at 1:21 PM, Pete Muir <pmuir at redhat.com> wrote:

>
> On 2 May 2009, at 04:24, Dan Allen wrote:
>
>  Before I get started, I want to mention that we should have wiki pages up
>> to discuss the status (Jay is doing this with RichFaces and it is working
>> out nicely). I'll duplicate some of my response there.
>>
>> On Wed, Apr 29, 2009 at 8:17 PM, Shane Bryzak <shane.bryzak at jboss.com>
>> wrote:
>> To get the ball rolling, I've hand picked a couple of the more important
>> issues from my list.  We can discuss these in more depth during the conf
>> call, however I would like people to start thinking about them now.
>>
>> 1. Obtaining instances to a Web Beans component from outside of the
>> component framework.  There are a number of places that we need to do this.
>>  I got around it in SeamLoginModule by extending the CallbackHandler to
>> support callbacks for Identity, Authenticator, etc.  We unfortunately don't
>> have such an easy workaround in other places - here's just a few examples:
>>
>>  * DroolsHandler (which is a jBPM handler) needs to access the Expressions
>> and WorkingMemory components.
>>  * SeamGlobalResolver (which resolves Drools global variables) needs to
>> get an instance of Manager to perform lookups.
>>  * EntitySecurityListener and HibernateSecurityInterceptor both require
>> access to security components.
>>  * DateConverter needs to access the TimeZone and Locale components
>>
>> The 299 spec guarantees that the Manager will be available in JNDI. So
>> that is our bridge.
>>
>
> This is problematic as it's only guaranteed for EE, for example by default
> in TC it's not available. The better hook is to observe the startup event.


Yeah, I thought of that. But that problem is, when Web Beans starts up, we
don't have access to a ServletContext at that point. So where to we stick
it? Okay, I guess we could go with a ThreadLocal that a listener that comes
behind it could pick up...or a static variable (yuck). And JSF is definitely
not up yet at this point. So I just need to connect with the right solution
there.


>
>
>  The question becomes, should we cache the result of this lookup. We can
>> either do a thread locale cache...which is fine since a single JNDI lookup
>> per request is very cheap.
>>
>
> If the lifecycle of the place you need to propagate it is well defined
> (i.e. you know it will occur next in the current thread) this is safe, but
> sometimes this isn't well defined.
>
>  We could, however, think about putting it in application-scope since it
>> shouldn't change between deployments. For that, we would need access to the
>> servlet context application scope which would mean having a seam-contexts
>> module. Anyway, I have an impl already. See JndiManager in the seam-faces
>> module. It can be changed to use a thread local.
>>
>
> I would avoid this. If you are in a bean then inject it using @Current
> Manager manager, if you are in a non-bean, you need to decide this case by
> case, depending on the lifecycle of the object.


Right, we will always use @Current Manager if we can. It's those other cases
we need to worry about at this point.


>
>
>  One possible solution to this issue is to have a thread local Manager
>> available for the lifecycle of a single request, which can be accessed by
>> non-component classes.
>>
>
> Again, I would avoid this - why do you need to do this? It is also
> potentially dangerous with async requests where you can have the same thread
> sequentially processing different requests before they end.
>
> In general, don't make assumptions about JNDI, or that you are in servlet.


Hmm..


>
>
> I've said it before, and I'll say it again. There is no global pattern to
> solve this, we have to address this for each case.


Okay, but we haven't even settled on some patterns yet...I mean we haven't
demonstrated any yet. So that's the first step.



>
> 2. Module granularity / dependencies.  I'm going to use security as an
> example for this issue, however there are other modules which are similarly
> affected.  Within the security module, there are certain features (such as
> the action components, RememberMe, etc) that depend on the faces module.  My
> preference is to not have any dependencies on faces and that the security
> module remains view-layer independent.
> One possible way to solve this issue is to introduce a bridging module, in
> this example it would be seam-faces-security which contains the
> functionality that you would require if you were using Seam Security in a
> JSF environment.  The only downside to this is that it may lead to jar bloat
> (which may not really be an issue).  The upside is that it keeps everything
> nice and modular, and helps to simplify the dependency tree.
>

I think this is the correct approach. We can then provide a seam-jsf jar
> that bundles *all* JSF related seam modules, and people can dump that in
> their WEB-INF/lib to get going. As their project develops, they can pick up
> individual modules as they want.


Yeah, with a good repository structure we are going to have much great
flexibility with creating bundle JARs...the WB team proved that nicely with
webbeans-servlet.jar using the shade plugin.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090505/76bc23ac/attachment.html