5 messages in net.java.dev.glassfish.usersRe: Deployer control over CDI| 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: | Dominik Dorn (domi...@gmail.com) | |
| Date: | Jun 22, 2010 10:23:42 pm | |
| List: | net.java.dev.glassfish.users | |
like sanjeeb sahoo already said, it actually has nothing to do with CDI. if you are deploying a webapp with a webservice that's annotated correctly to a container knowing how to handle it (which glassfish certainly is), it will automatically do whats defined in the spec, and in case of webservices, that is to deploy them.
the same goes for servlets annotated with the servlet 3.0 annotations: a servlet 3.0 aware container will automatically deploy them.
as for CDI: you are explicitly telling the container to handle the classes as CDI beans iff you put a beans.xml in the file.. thats what you need to do for CDI, but its only for CDI, it will not influence other javaee services (except that some may not work if you forget to do it and depend on CDI injection in them)
the biggest difference when coming from a spring background is probably that with JavaEE6, you only define CDI related stuff in beans.xml, for most of the other things you either use web.xml, annotations in the beans or technology specific configuration files.
Also, CDI beans by default inherent their parents scope, while in spring automatically every bean is a (pseudo) singleton and you have to explicitly have to say that it should be requestscoped/etc.
On Wed, Jun 23, 2010 at 5:25 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']
-- Dominik Dorn http://dominikdorn.com
Liquido Lyrics http://www.lyrix.eu/lyrics/Liquido/