[seam-dev] Seam 3 porting issues

[Dan Allen]

It's not much so far, but I've added two pages to the wiki. The first is on
the Seam 3 build system. The second is on the porting status. Please feel
free to update. Don't feel that you have to post in the comments. In fact,
don't. I would rather the discussions be on the mailing list and the wiki
represent the current state of what we have agreed upon in the design (or a
list of open questions where we have not decided).

http://seamframework.org/Documentation/Design

On Fri, May 1, 2009 at 11:24 PM, Dan Allen <dan.j.allen at gmail.com> 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. 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. 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.
>
>
>>
>> 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.
>>
>> 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.
>
>
> Remember there is a difference between compile time and runtime
> dependencies. It may be necessary for seam-faces to depend on seam-security
> for compile, but if you don't have seam-identity deployed, the the observer
> never get called. The other line of thought is that security is so central
> that seam-faces should depend on it. We'll just keep moving things around
> until it feels right.
>
> -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.
>



-- 
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/20090501/10fd6b3e/attachment.html