Dan and I have been working on the @Begin and @End conversation support for
Seam Faces, and we've discovered that there is a new fact of life for
consumers of portable CDI extensions. Due to the fact that @Interceptors
cannot be enabled in the extensions themselves (due to restrictions on
beans.xml for purposes of absolute ordering in the application. See:
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
- Exposed to the developer
- Registered manually by the developer in beans.xml -
- Consistently named and packaged to prevent refactoring / backwards
- Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor
We would like to propose the following conventions in order to address the
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we forgot to
tie the ladder.)
3. A protected namespace so that when we refactor, we don't break their
world. (Even though #2 would catch it.)
I've updated the Seam 3 Development
reflect these conventions - they can be changed as needed pending the
outcome of this discussion :)
Lincoln Baxter, III
"Keep it Simple"
1) Lincoln will produce a guide for writing tests using Arquillian
2) Pete, Lincoln, Jason will work on a namespace import solution that looks like the Java one. It will have a default set up, which can be adjusted by modules, and can be overridden by the application.
3) We will place UI components in their module, as a sub-module. We will produce shaded jars e.g. drools-for-faces.jar which include the core code + UI components.
I think that there is a real use case for something similar to the @Unwrap feature of seam 2.
I think that it would be possible to implement something like this:
public class ManagedPersistenceContext
public EntityManager produce(InjectionPoint injectionPoint)
public class MyClass
@Inject @SomeQualifier EntityManager entityManager;
the way I envisage this working is that a proxy gets injected into MyClass, and this proxy calls ManagedPersistenceContext.produce to resolve the correct EntityManager to pass the call to every time a method is invoked on the proxy.
I am pretty sure I can implement this in weld-extensions using JDK proxies, does this sound like a good idea?
I can't see any way to get information about the actual Bean that an interceptor is bound to.
For example say I have a class:
Another bean with the same class is wired up with XML:
I cannot see any way for a security interceptor to know which Bean it is intercepting, and therefore figure out which annotation to use. Is there something I am missing here?
I'll note this in the Seam 3 wiki somewhere, but Seam parent should be a
single number, like Weld parent and JBoss parent. Currently it is set to
We'll also need a release of it in order to release modules that use it,
like Faces. Let's start with 1.
While I'm on the topic of build poms, I don't understand why dist is not in
the build root. We currently have:
Yet the dist is the bom. I'm confused every time I build. I think it should
Just put all the build stuff in the build root and call it what it is.
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
Could you please create a JIRA for the Seam 3 JMS Module? Required info:
*Friendly Name:* Seam JMS
*Project Lead (JBoss.org username):* Jordan Ganoff (jganoff)
*Additional Project Administrators (JBoss.org user name):* Dan Allen
*Categories:* Injection, Event Forwarding
*Project Developers (JBoss.org user names):* Jordan Ganoff (jganoff)
After contributing some code (PrettyFaces) and having a discussion with
Lincoln I've joined a seam-dev mailing list. My plan is to help Lincoln with
Seam faces module (maybe with other modules to) - I hope to find time for
well I was using Seam from version 1.2 to 2.2.x - so I'm familiar with
I checked out seam-faces module about two weeks ago and compiled it with no
problem. but last week, after an update (svn up) it didn't compile anymore.
After having a discussion with Lincoln yesterday, I started from beginning.
So I removed a org/jboss/seam folder from m2 repo, followed the instruction
svn co http://anonsvn.jboss.org/repos/seam/build/trunk build
svn co http://anonsvn.jboss.org/repos/seam/dist/trunk dist
svn co http://anonsvn.jboss.org/repos/seam/modules/faces/trunk faces
as first I got an error:
*[ERROR] BUILD ERROR*
*[INFO] Failed to resolve artifact.*
* Try downloading the file manually from the project website.*
* Then, install it using the command: *
* mvn install:install-file -DgroupId=org.glassfish
-DartifactId=javax.servlet -Dversion=3.0 -Dpackaging=jar
* Alternatively, if you host your own repository you can deploy the file
* mvn deploy:deploy-file -DgroupId=org.glassfish
-DartifactId=javax.servlet -Dversion=3.0 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]*
* Path to dependency: *
* ** **1) org.jboss.seam.faces:seam-faces:jar:3.0.0-SNAPSHOT*
* ** **2) org.glassfish:javax.servlet:jar:3.0*
*1 required artifact is missing.*
*for artifact: *
so I added following code to the .m2/settings.xml:
now every time i do "*mvn install*" i get an error:
* T E S T S*
*SLF4J: The requested version 1.5.9 by your slf4j binding is not compatible
with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9.RC1, 1.5.10]*
*SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.444 sec
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.087 sec
*Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.117 sec
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.065 sec
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.063 sec
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.059 sec
*Tests in error: *
*Tests run: 9, Failures: 0, Errors: 6, Skipped: 0*
I've attached a file *
* with a report.
Did anyone else had similar problems?