Skip to main content

CDI injection broken between POJOs

9 replies [Last post]
theodan
Offline
Joined: 2010-04-07
Points: 0

I have a POJO User entity that needs to get a POJO SiteDao injected into it, but GF or Weld seems to be ignoring my @Inject annotation.

@Inject does work in my EJB, but not in my POJO User entity. Both are in the same EJB module, which has the empty beans.xml.

When I invoke my EJB, I can see that the SiteDao that should've been injected is null:

Caused by: java.lang.NullPointerException
at sample.model.User.getSite(User.java:15)
at sample.service.UserService.getSiteByUserGuid(UserService.java:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1055)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1127)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5259)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:158)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5231)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5219)
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
... 66 more

My simple EAR is attached.

Anyone know a workaround?

Thanks,
-Dan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Sahoo

Dan,

I am with you. I am already discussing the JPA/CDI limitation with some
folks internally (people who normally don't participate in this forum)
and will let you know the outcome.

Thanks,
Sahoo

glassfish@javadesktop.org wrote:
> Sahoo,
>
> You understood my situation perfectly.
>
> I understand now why the SiteDao was not injected into the User entity. Because the User entity comes from the EntityManager, CDI doesn't get a chance to handle it. So if that's the way it is, that's fine.
>
> However, please allow me to get on my soapbox a bit. :) To me a great technology is one that, given a user of reasonable expertise, works exactly as the user expects it to (a.k.a. the "It Just Works!" quality).
>
> From the perspective of a client of the model, there's little difference between, say, Site.getUsers() and Site.getActiveUsers(). The fact that Site.getUsers() is implemented under the hood as a JPA mapped relationship, whereas Site.getActiveUsers() is implemented as a JPQL query, should be hidden from model clients.
>
> I've seen both the DAO and Repository patterns configured such that entity classes had references to them, and would expose their methods as entity methods for convenience. e.g. The Site entity might have a reference to UserDao, and expose UserDao.findByStatus() as Site.getActiveUsers(). This way, clients wouldn't even have to know about the UserDao under the hood.
>
> So it would be nice if CDI could also inject into objects like entities returned from an EntityManager. I realize that may be beyond CDI's current capabilities, but I will not be the last developer scratching my head as to why, in cases like this one, CDI doesn't work as I expect it to. Granted, that may be partly naivete on my part, but maybe it's possible in a future CDI release.
>
> As for decorators... I'm definitely no expert on them, but from what I know about the pattern in general, and from what I've read about its implementation in CDI, it seems like a stretch to apply it in this scenario. I'd rather not resort to decorators just as a hack around a CDI limitation.
>
> Thanks again for your help,
> -Dan
>
> Message was edited by: theodan
>
> Message was edited by: theodan
> [Message sent by forum member 'theodan']
>
> http://forums.java.net/jive/thread.jspa?messageID=396369
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Sahoo

Dan,

From the response I have received so far, it appears that interaction
between JPA and CDI was considered but not made part of the spec for
some unknown reason. If I come to know of the reason, I shall update
this thread. In the mean while, it has been sent as a feedback to
appropriate folks. So, this one is definitely not a bug in GlassFish.

Thanks,
Sahoo

Sahoo wrote:
> Dan,
>
> I am with you. I am already discussing the JPA/CDI limitation with
> some folks internally (people who normally don't participate in this
> forum) and will let you know the outcome.
>
> Thanks,
> Sahoo
>
> glassfish@javadesktop.org wrote:
>> Sahoo,
>>
>> You understood my situation perfectly.
>>
>> I understand now why the SiteDao was not injected into the User
>> entity. Because the User entity comes from the EntityManager, CDI
>> doesn't get a chance to handle it. So if that's the way it is,
>> that's fine.
>>
>> However, please allow me to get on my soapbox a bit. :) To me a
>> great technology is one that, given a user of reasonable expertise,
>> works exactly as the user expects it to (a.k.a. the "It Just Works!"
>> quality).
>>
>> From the perspective of a client of the model, there's little
>> difference between, say, Site.getUsers() and Site.getActiveUsers().
>> The fact that Site.getUsers() is implemented under the hood as a JPA
>> mapped relationship, whereas Site.getActiveUsers() is implemented as
>> a JPQL query, should be hidden from model clients.
>>
>> I've seen both the DAO and Repository patterns configured such that
>> entity classes had references to them, and would expose their methods
>> as entity methods for convenience. e.g. The Site entity might have a
>> reference to UserDao, and expose UserDao.findByStatus() as
>> Site.getActiveUsers(). This way, clients wouldn't even have to know
>> about the UserDao under the hood.
>>
>> So it would be nice if CDI could also inject into objects like
>> entities returned from an EntityManager. I realize that may be
>> beyond CDI's current capabilities, but I will not be the last
>> developer scratching my head as to why, in cases like this one, CDI
>> doesn't work as I expect it to. Granted, that may be partly naivete
>> on my part, but maybe it's possible in a future CDI release.
>>
>> As for decorators... I'm definitely no expert on them, but from what
>> I know about the pattern in general, and from what I've read about
>> its implementation in CDI, it seems like a stretch to apply it in
>> this scenario. I'd rather not resort to decorators just as a hack
>> around a CDI limitation.
>>
>> Thanks again for your help,
>> -Dan
>>
>> Message was edited by: theodan
>>
>> Message was edited by: theodan
>> [Message sent by forum member 'theodan']
>>
>> http://forums.java.net/jive/thread.jspa?messageID=396369
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

theodan
Offline
Joined: 2010-04-07
Points: 0

Thanks Sahoo. I appreciate the follow-up.

Not sure why the forum isn't allowing me to acknowledge your answer as correct, but I'm marking the thread as answered.

-Dan

> Dan,
>
> From the response I have received so far, it appears
> that interaction
> etween JPA and CDI was considered but not made part
> of the spec for
> some unknown reason. If I come to know of the reason,
> I shall update
> this thread. In the mean while, it has been sent as a
> feedback to
> appropriate folks. So, this one is definitely not a
> bug in GlassFish.
>
> Thanks,
> Sahoo

Sahoo

Dan,

You have an interesting use case. IIUC from your sample, you are trying
to do the following:

1. UserService SLSB is injected with UserDao. It calls UserDao to return
a User. See step #2.
2. UserDaoImpl calls entitymanager.find to return a User.
3. User is injected with SiteDao.

The user returned in step #2 does not get injected with SiteDao,
correct? This is going to be tricky. User object returned in step #2
does not go through CDI at all. It's not as if you injected a User
instance into another bean. So, why do you expect SiteDao to be injected
into the User instance, which is returned by entity manager. I don't
know CDI that well. Is Decorators applicable here? Could you decorate
User bean and add inject SiteDao in your decorator bean?

Thanks,
Sahoo

glassfish@javadesktop.org wrote:
> I have a POJO User entity that needs to get a POJO SiteDao injected into it, but GF or Weld seems to be ignoring my @Inject annotation.
>
> @Inject does work in my EJB, but not in my POJO User entity. Both are in the same EJB module, which has the empty beans.xml.
>
> When I invoke my EJB, I can see that the SiteDao that should've been injected is null:
>
> Caused by: java.lang.NullPointerException
> at sample.model.User.getSite(User.java:15)
> at sample.service.UserService.getSiteByUserGuid(UserService.java:26)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1055)
> at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1127)
> at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5259)
> at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
> at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:158)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
> at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5231)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5219)
> at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
> ... 66 more
>
> My simple EAR is attached.
>
> Anyone know a workaround?
>
> Thanks,
> -Dan
> [Message sent by forum member 'theodan']
>
> http://forums.java.net/jive/thread.jspa?messageID=396170
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

theodan
Offline
Joined: 2010-04-07
Points: 0

Sahoo,

You understood my situation perfectly.

I understand now why the SiteDao was not injected into the User entity. Because the User entity comes from the EntityManager, CDI doesn't get a chance to handle it. So if that's the way it is, that's fine.

However, please allow me to get on my soapbox a bit. :) To me a great technology is one that, given a user of reasonable expertise, works exactly as the user expects it to (a.k.a. the "It Just Works!" quality).

From the perspective of a client of the model, there's little difference between, say, Site.getUsers() and Site.getActiveUsers(). The fact that Site.getUsers() is implemented under the hood as a JPA mapped relationship, whereas Site.getActiveUsers() is implemented as a JPQL query, should be hidden from model clients.

I've seen both the DAO and Repository patterns configured such that entity classes had references to them, and would expose their methods as entity methods for convenience. e.g. The Site entity might have a reference to UserDao, and expose UserDao.findByStatus() as Site.getActiveUsers(). This way, clients wouldn't even have to know about the UserDao under the hood.

So it would be nice if CDI could also inject into objects like entities returned from an EntityManager. I realize that may be beyond CDI's current capabilities, but I will not be the last developer scratching my head as to why, in cases like this one, CDI doesn't work as I expect it to. Granted, that may be partly naivete on my part, but maybe it's possible in a future CDI release.

As for decorators... I'm definitely no expert on them, but from what I know about the pattern in general, and from what I've read about its implementation in CDI, it seems like a stretch to apply it in this scenario. I'd rather not resort to decorators just as a hack around a CDI limitation.

Thanks again for your help,
-Dan

Message was edited by: theodan

Message was edited by: theodan

Dominik Dorn

Am I understanding you correctly? Your entities have references back
to the DAO's ?

Your Entities should be simple POJO's, just getters + setters and some
JPA2 annotations. Lazy loading of lists etc. is done automatically by
the jpa2 container,
if you haven't detached the entity.

On Sun, Apr 11, 2010 at 8:26 PM, wrote:
> Sahoo,
>
> You understood my situation perfectly.
>
> I understand now why the SiteDao was not injected into the User entity.  Because the User entity comes from the EntityManager, CDI doesn't get a chance to handle it.  So if that's the way it is, that's fine.
>
> However, please allow me to get on my soapbox a bit. :)  To me a great technology is one that, given a user of reasonable expertise, works exactly as the user expects it to (a.k.a. the "It Just Works!" quality).
>
> From the perspective of a client of the model, there's little difference between, say, Site.getUsers() and Site.getActiveUsers().  The fact that Site.getUsers() is implemented under the hood as a JPA mapped relationship, whereas Site.getActiveUsers() is implemented as a JPQL query, should be hidden from model clients.
>
> I've seen both the DAO and Repository patterns configured such that entity classes had references to them, and would expose their methods as entity methods for convenience.  e.g. The Site entity might have a reference to UserDao, and expose UserDao.findByStatus() as Site.getActiveUsers().  This way, clients wouldn't even have to know about the UserDao under the hood.
>
> So it would be nice if CDI could also inject into objects like entities returned from an EntityManager.  I realize that may be beyond CDI's current capabilities, but I will not be the last developer scratching my head as to why, in cases like this one, CDI doesn't work as I expect it to.  Granted, that may be partly naivete on my part, but maybe it's possible in a future CDI release.
>
> As for decorators...  I'm definitely no expert on them, but from what I know about the pattern in general, and from what I've read about its implementation in CDI, it seems like a stretch to apply it in this scenario.  I'd rather not resort to decorators just as a hack around a CDI limitation.
>
> Thanks again for your help,
> -Dan
>
> Message was edited by: theodan
>
> Message was edited by: theodan
> [Message sent by forum member 'theodan']
>
> http://forums.java.net/jive/thread.jspa?messageID=396369
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

--
Dominik Dorn
http://dominikdorn.com

Tausche Deine Lernunterlagen auf http://www.studyguru.eu !

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

theodan
Offline
Joined: 2010-04-07
Points: 0

> Am I understanding you correctly? Your entities have
> references back
> to the DAO's ?
>
> Your Entities should be simple POJO's, just getters +
> setters and some
> JPA2 annotations. Lazy loading of lists etc. is done
> automatically by
> the jpa2 container,
> if you haven't detached the entity.

Yes, my entities have references to Repository interfaces (not implementation classes), which are part of the domain model. Repository is a pattern similar to DAO, so I was using DAO in my examples to simplify things.

If you limit entities to being simple POJOs with only getters and setters, you're creating a pretty anemic model, as discussed here:

http://martinfowler.com/bliki/AnemicDomainModel.html

If you want to create a richer domain model, I believe exposing additional Repository or DAO methods through your entities (e.g. Site.getActiveUsers() exposing UserDAO.findByStatus()) is not a bad idea. If people disagree, I'm open to that, but I'd like to know their reasoning.

Steven Siebert

Your POJO isn't container managed, so you can't use CDI like you can in an
EJB. The EJB container is what does the CDI magic for your EJBs.

If both your Entity and DAO are POJO's, why not simply instantiate the
SiteDAO using a constructor or a factory? If you're looking for the CDI to
do pooling or something like that, perhaps create a SLSB factory that can
retrieve it via CDI and return it to your POJO? You'll need to use JNDI to
retrieve a copy of your SLSB from the context.

Cheers,

Steve

On Fri, Apr 9, 2010 at 6:22 PM, wrote:

> I have a POJO User entity that needs to get a POJO SiteDao injected into
> it, but GF or Weld seems to be ignoring my @Inject annotation.
>
> @Inject does work in my EJB, but not in my POJO User entity. Both are in
> the same EJB module, which has the empty beans.xml.
>
> When I invoke my EJB, I can see that the SiteDao that should've been
> injected is null:
>
> Caused by: java.lang.NullPointerException
> at sample.model.User.getSite(User.java:15)
> at sample.service.UserService.getSiteByUserGuid(UserService.java:26)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1055)
> at
> org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1127)
> at
> com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5259)
> at
> com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
> at
> org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
> at
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:158)
> at
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
> at
> com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
> at
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
> at
> com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5231)
> at
> com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5219)
> at
> com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
> ... 66 more
>
> My simple EAR is attached.
>
> Anyone know a workaround?
>
> Thanks,
> -Dan
> [Message sent by forum member 'theodan']
>
> http://forums.java.net/jive/thread.jspa?messageID=396170
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

theodan
Offline
Joined: 2010-04-07
Points: 0

Thanks for the quick reply, Steve.

> Your POJO isn't container managed, so you can't use
> CDI like you can in an
> EJB. The EJB container is what does the CDI magic
> for your EJBs.

There seems to be a common misconception that CDI only works for traditional container-managed components (EJBs, servlets, etc.). But I'm pretty sure that's not the case.

Here's a definition of managed beans from the JEE 6 Tutorial:

http://java.sun.com/javaee/6/docs/tutorial/doc/gjfzi.html

Here's an example of one POJO being injected into another POJO:

http://java.sun.com/javaee/6/docs/tutorial/doc/gjban.html

Here's another discussion:

http://www.theserverside.com/news/1373391/Dependency-Injection-in-Java-E...

"Managed beans are a key concept introduced in Java EE 6 to solve some of the limitations we talked about in the previous section with Java EE 5 style resource injection. A managed bean is just a bare Java object in a Java EE environment. Other than Java object semantics, it has a well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations. Managed beans can be explicitly denoted via the @ManagedBean annotation, but this is not always needed, especially with CDI. From a CDI perspective, this means that almost any Java object can be treated as managed beans and so can be full participants in dependency injection."

> If both your Entity and DAO are POJO's, why not
> simply instantiate the
> SiteDAO using a constructor or a factory? If you're
> looking for the CDI to
> do pooling or something like that, perhaps create a
> SLSB factory that can
> retrieve it via CDI and return it to your POJO?
> You'll need to use JNDI to
> etrieve a copy of your SLSB from the context.

My sample EAR was greatly simplified and probably a bit contrived. I'm not sure that I will keep the SiteDaoImpl as a POJO in my real app. I may make it a singleton EJB instead. But from everything I've read, CDI should work between POJOs, as I have it setup. The fact that it doesn't seems to imply another bug in GlassFish, which I'd be happy to submit a defect for if someone can confirm this.

Thanks,
-Dan