Dependecy Injection in JMX Service Object

[echon]

Hi,

is it a bug that Injections in JMX Service Objects are bound not until the
LifeCycle method start() is executed? This behaviour is new since CR2.
While proceeding the create() and start() method the EntityManager injected by

@PersistenceContext(unitName = "myEM") protected EntityManager em;

em is "null", but when calling a method after the start of the Service it is available.
I compared org.jboss.system.ServiceController from RC1 and CR2, but there are no changes, which would affect this behaviour.

Someone has an idea what changes affected this?



Regards

Peter

[echon]

if a datasource is not injected it's not a problem, because i can get it from JNDI, but how can i get the EntityManager (peristence unit already created)?

[echon]

no statement to this?

[echon]

is it a bug or not?

[bill.burke]

you mean, why is it null before start()? Like in the constructor?

[echon]

the JMX Component has the standard lifecycle methods:
create(), start(),stop(), destroy()

My code looks like this:

@Service(objectName = "portal:service=SystemPropertyService")
@Management(SystemPropertyManagement.class)
@Local(SystemPropertyLocal.class)
@LocalBinding(jndiBinding = SystemPropertyLocal.JNDI)
public class SystemPropertyService implements SystemPropertyLocal,
 SystemPropertyManagement {

 private static final Log _log = LogFactory
 .getLog(SystemPropertyService.class);

 private final ConcurrentHashMap<String, String> _properties = new ConcurrentHashMap<String, String>();


 @PersistenceContext(unitName = "portalEM")
 protected EntityManager em;


 public void create() throws Exception {
 }

 public void start() throws Exception {
 List<SystemProperty> properties = _getProperties();

 // add Properties
 }

 public void stop() {
 _properties.clear();
 }

 public void destroy() {
 }



 @SuppressWarnings("unchecked")
 @TransactionAttribute(TransactionAttributeType.REQUIRED)
 private List<SystemProperty> _getProperties() {
 try {


 List<SystemProperty> list = em.createQuery("from SystemProperty sp").getResultList();


 em.flush();

 return list;

 } catch (RuntimeException e) {
 throw new SystemException(e);
 }

 }
}

I get a NullPointerException in _getProperties() because em is null.


I would accept it if the EntityManager is not injected while constructor or create(), but why in start()? And why is this behaviour different since CR2?

The EntityManager is not injected before the start() method is completly processed. ( before: null, start(): null, after: injected)
In 4.0.4RC1 i can use the EntityManager in the start() method,
in 4.0.4CR2 it is null (same Sourcecode).
I also tried to inject only a datasource by @Resource and it was also not injected (but available by JNDI and InitialContext in start() method).
In both versions the EntityManager is available when the service is started.


This is a little bit curious. Do you have an explanation for this behaviour?

Regads

Peter

[echon]

no statement? I only want to know, if this is a bug or if this behaviour will also exist in the final version of 4.0.4.


Regards

Peter

[bill.burke]

I'll log a bug in jira. We changed the behavior for service beans to fix another bug.

Another release is scheduled before java one.

[bill.burke]

http://jira.jboss.com/jira/browse/EJBTHREE-520

[bdecoste]

I just corrected this issue and closed the JIRA task. The fix will be available in the next release of EJB3

[bjornbjorn]

I also get EntityManager null when trying to inject it in a servlet with 404RC2. When using it in the processRequest() method it is null.

Could this be the same issue?

[echon]

dependency injections don't work for servlets. This bug only affects jmx service objects whith lifecycle methods.

Regards

Peter

[cleanerx]

@EJB annotations cannot be injected within @Service Beans. The behavior changed from 4.0.4Patch1 to > 4.2. The injected @EJB references are null within the start method of the jmx bean. However the @PersistenceContext annotation can be injected. I'm just curious if I'm missing something or if it's a bug.