10:24 p.m.
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(a)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.