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
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
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
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.
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
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.
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-
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.
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.
This is another good option.
Senior Software Engineer, Red Hat | Author of Seam in Action
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
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
you feel that it did not reach my attention.
seam-dev mailing list