]
Mark Struberg commented on CDI-414:
-----------------------------------
Rolling a few ideas with Antoine, we thought it might be better to have a code sample
about how it looks today.
And then we can figure how it _might_ look in the future
Here is the current solution to start with:
{code}
@ApplicationScoped
public class CountryService {
private List<Country> cachedCountries;
private @Inject CountryService _self;
// this method doesn't need to open any transaction
// so keep it fast without any interceptor and TX handling
public List<Counry> getCountries() {
if (cachedCountries == null) {
_self.loadCountries();
}
return cachedCountries;
}
// but over here we might need a transaction...
@Transactional
protected synchronized loadCountries() {
if (countries != null) return;
countries = em…. load all countries form DB
}
}
{code}
Support for "self" injection
----------------------------
Key: CDI-414
URL:
https://issues.jboss.org/browse/CDI-414
Project: CDI Specification Issues
Issue Type: Bug
Components: Resolution
Reporter: arjan tijms
Fix For: 2.0 (discussion)
Many features of CDI and EJB work by means of a proxy that intercepts calls and adds
'aspects'. In Java it's however not possible to decorate the {{this}} pointer,
so methods called on the same bean instance from within a method in the bean do not get
their 'aspects' applied.
This is a well known limitation, but in EJB it's possible to work around this by
injecting a bean into itself. E.g.
{code}
@Stateless
public class Foo {
@EJB
private Foo self;
// ...
}
{code}
Also see
http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails
the deployment and logs:
{noformat}
WELD-001443 Pseudo scoped bean has circular dependencies.
{noformat}
See also:
http://adam-bien.com/roller/abien/entry/inject_vs_ejb
Although there are workarounds, it would be great if {{@Inject}} in combination with CDI
could support self injection as well.
With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the
capability can be convenient for new projects as well (e.g. calling two separate
{{@Transactional}} methods from a single method without being required to create a new
bean).