Interceptor packaging convention
by Lincoln Baxter, III
Seam Devs,
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:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
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 -
<interceptors>...</interceptors>
- Consistently named and packaged to prevent refactoring / backwards
compatibility issues
- 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
above concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
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,
interceptorBindings)
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
Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines>to
reflect these conventions - they can be changed as needed pending the
outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
16 years
Decisions and action items from meeting
by Pete Muir
http://seamframework.org/Seam3/MeetingTranscript20100422
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.
16 years
@Unwrap implementation in weld-extensions
by Stuart Douglas
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:
@ConversationScoped
public class ManagedPersistenceContext
{
EntityManager entityManager;
@Unwrap
@SomeQualifier
public EntityManager produce(InjectionPoint injectionPoint)
{
entityManager.joinTransaction();
return entityManager;
}
}
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?
Stuart
16 years
Retrieving the Bean object for an interceptor
by Stuart Douglas
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:
@Security("#{true}")
class SomeClass
{
...
}
Another bean with the same class is wired up with XML:
<t:SomeClass>
<se:Security>#{false}</se:Security>
....
</t:SomeClass>
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?
Stuart
16 years
Seam parent version
by Dan Allen
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
3.0.0-SNAPSHOT.
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:
build/trunk/parent/pom.xml
dist/trunk/pom.xml
Yet the dist is the bom. I'm confused every time I build. I think it should
be:
build/trunk/parent/pom.xml
build/trunk/bom/pom.xml
build/trunk/dist/pom.xml
Just put all the build stuff in the build root and call it what it is.
Thoughts?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
16 years
JIRA for the Seam 3 JMS Module
by Jordan Ganoff
Hi Shane,
Could you please create a JIRA for the Seam 3 JMS Module? Required info:
*Name:* SEAMJMS
*Friendly Name:* Seam JMS
*Project Lead (JBoss.org username):* Jordan Ganoff (jganoff)
*URL:* http://sfwk.org/Seam3/JMSModule
*Additional Project Administrators (JBoss.org user name):* Dan Allen
(dan.j.allen)
*Categories:* Injection, Event Forwarding
*Project Developers (JBoss.org user names):* Jordan Ganoff (jganoff)
Thanks.
--
Jordan Ganoff
16 years
Compiling Seam faces module
by Uroš Majerič
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
helping.
well I was using Seam from version 1.2 to 2.2.x - so I'm familiar with
seam.
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
on http://seamframework.org/Seam3/CheckOutAndBuildSeam:
mkdir seam-trunk
cd seam-trunk
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
cd build/parent
mvn install
cd ../..
cd dist
mvn install
cd ..
cd faces
mvn install
as first I got an error:
*[INFO]
------------------------------------------------------------------------*
*[ERROR] BUILD ERROR*
*[INFO]
------------------------------------------------------------------------*
*[INFO] Failed to resolve artifact.*
*
*
*Missing:*
*----------*
*1) org.glassfish:javax.servlet:jar:3.0*
*
*
* 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
-Dfile=/path/to/file*
*
*
* Alternatively, if you host your own repository you can deploy the file
there: *
* 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: *
* org.jboss.seam.faces:seam-faces:jar:3.0.0-SNAPSHOT*
so I added following code to the .m2/settings.xml:
*<repository>
<id>glassfish</id>
<url>**http://download.java.net/maven/glassfish*<http://download.java.net/maven/glassfish>
*</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>*
*
*
now every time i do "*mvn install*" i get an error:
*-------------------------------------------------------*
* T E S T S*
*-------------------------------------------------------*
*Running org.jboss.seam.faces.environment.FacesContextProducerTest*
*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
details.*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.444 sec
<<< FAILURE!*
*Running org.jboss.seam.faces.context.FacesAnnotationsAdapterExtensionTest*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.087 sec
<<< FAILURE!*
*Running org.jboss.seam.faces.util.AnnotationsTest*
*Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec*
*Running org.jboss.seam.faces.event.SystemEventBridgeTest*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.117 sec
<<< FAILURE!*
*Running
org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptorTest
*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.065 sec
<<< FAILURE!*
*Running org.jboss.seam.faces.event.PhaseEventBridgeTest*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.063 sec
<<< FAILURE!*
*Running org.jboss.seam.faces.environment.ExternalContextProducerTest*
*Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.059 sec
<<< FAILURE!*
*
*
*Results :*
*
*
*Tests in error: *
* org.jboss.seam.faces.environment.FacesContextProducerTest*
* org.jboss.seam.faces.context.FacesAnnotationsAdapterExtensionTest*
* org.jboss.seam.faces.event.SystemEventBridgeTest*
*
org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptorTest
*
* org.jboss.seam.faces.event.PhaseEventBridgeTest*
* org.jboss.seam.faces.environment.ExternalContextProducerTest*
*
*
*Tests run: 9, Failures: 0, Errors: 6, Skipped: 0*
*
*
I've attached a file *
{faces-module}/impl/target/surefire-reports/org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptorTest.txt
* with a report.
Did anyone else had similar problems?
Uros
16 years
