I recognize this is an edge case, but I can see value in having @EJB
injection capability when using Weld Servlet in a pre-Java EE 6 container.
You could go about it at least two ways:
1. provide a portable extension that satisfies the @EJB annotation on a
managed bean field
2. implement Weld's EjbServices
#1 would be a great demo of a portable extension, but the shortcoming is
that it's only a connector between a managed bean and an EJB. You would have
to do quite a lot of work to give the EJB CDI services.
#2 would be pretty easy since you could off-load all the work of #1 back to
Weld. The problem is that the Weld Listener doesn't provide any hooks (that
I can see) to register services before it starts the Weld container. I
was imagining something like a service-provider approach so you can shove
the EjbServices implementation (+ family) into the deployment classpath. Can
we add that feature?
We're really just a small step away from giving people access to CDI in
pre-Java EE 6 containers. And there are a lot of people on those containers
and will be for quite some time.
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
I am running the core tests from the workspace against glassfish.I have
these question related to 2 tests.
In the test, org.jboss.weld.tests.scope.RemoteScopeTest, there is a servlet
by name RemoteClient using the annotation "@WebServlet("*")".
In the test resource.EMFFactoryTest, there are 3 servlets EMFConsumerTest1,
EMFConsumerTest2, EMFConsumerTest3 which uses the annotation
@WebServlet("emfconsumer") with out a leading "/" .
Are these 2 test cases valid with respect to servlet specification?I guess
these need to be rectified.Please comment.