Having @Stateless public class EjbService {...}
, is@Inject EjbService myService;
ok?
Will it really inject SLSB, or it will create new pojo?
Will such inserted myService be transactional?
Will such inserted myService be thread safe?
Having @Stateless public class EjbService {...}
, is@Inject EjbService myService;
ok?
Will it really inject SLSB, or it will create new pojo?
Will such inserted myService be transactional?
Will such inserted myService be thread safe?
As @scottb pointed out, if it is a certain version of the spec, the EJB would be injected as EJBs are a superset of injectable objects.
Having said that, let us go one by one:
New POJO? If it is not tied to a pre-defined CDI context, then it would be a new POJO. This may also differ by application server.
Transactional? This totally depends on the application server and if the application server scanning recognizes the EJB, then it depends on the type of transactional control configured in your EJB configuration.
Thread-safe? If instantiated as a POJO by the container it will inherit the thread-safe characteristics of the container (for example, servlet container). Again, an application server may scan it as an EJB and support EJB-style multi-threading when injected as a POJO.
In summary, you may be able to inject a SLSB as a POJO, for after all it is a POJO. However, you cannot rely on EJB-specific behaviour when injected in this way unless you have tested everything out on your application server, which may be harder and error-prone than just adopting an application server that supports EJBs.
In short, when you just inject an EJB as a POJO, you are 'off-spec'. That means that the application server is not guaranteed to conform to EJB specifications.