| From | Sent On | Attachments |
|---|---|---|
| glas...@javadesktop.org | Jun 22, 2010 8:15 pm | |
| Sanjeeb Sahoo | Jun 22, 2010 9:22 pm | |
| Dominik Dorn | Jun 22, 2010 10:23 pm | |
| glas...@javadesktop.org | Jun 22, 2010 10:45 pm | |
| Sanjeeb Sahoo | Jun 22, 2010 11:26 pm |
| Subject: | Re: Deployer control over CDI | |
|---|---|---|
| From: | Sanjeeb Sahoo (Sah...@Sun.COM) | |
| Date: | Jun 22, 2010 9:22:36 pm | |
| List: | net.java.dev.glassfish.users | |
What relationship does the deployment of webservices that are part of WEB/lib/*.jar have with CDI? As you said that jars in WEB-INF/lib does not contain beans.xml. The webservices are getting deployed because they are part of the web app.
On Wednesday 23 June 2010 08:55 AM, glas...@javadesktop.org wrote:
I have a Java EE 6 web app that contains a jar that contains some web services
annotated classes as well as some other classes annotated with JSR330 and 250
annotations. When the app is deployed to GFv3 the web services are automatically
deployed even though the web app and jar do not contain a beans.xml file and the
web services are not referenced in the web.xml
Coming from a Spring background which allows the deployer to explicitly define
instances and injection relations from what I experienced with CDI it is like a
big melting pot where beans are jumbled together and hopefully the injections
turn out correctly. Qualifiers and Alternatives seem useful but inadequate.
As a deployer given a static library containing beans how can I tell the CDI
container to ignore certain beans during auto discovery or create multiple
instances of a given type and associate (i.e. wire) them together as desired? Is
there a CDI extension that can accomplish this?
[Message sent by forum member 'aaronanderson']





