Hello,
2007/3/5, Craig McClanahan <[EMAIL PROTECTED]>:
Two common scenarios where you might want to override the
configuration information that was originally specified with
annotations:
* Third party beans where you don't have the ability
to modify the sources to meet your requirements.
* Use cases where the annotated configuration is
default values, but the bean is explicitly designed to
allow you to customize things (via configuration files).
This pattern is essentially universal across all of Java EE ...
everything you can specify with annotations can be overridden with
configuration files. Thus, it made sense to emulate this pattern with
Shale as well, because Shale users will likely expect the same sorts
of behaviors.
Don't get me wrong. I'm not saying that I don't want to override the
type of a managed bean, but in that case I would rather replace the
existing bean than to merge the characteristics. This behavior would
be in accord with other Java EE technologies. Consider following
example:
/// EmployeeServiceBean.java
package com.acme;
import javax.ejb.Stateless;
import javax.persistence.PersistenceContext;
@Stateless
public class EmployeeServiceBean implements EmployeeService {
@PersistenceContext
private PersistenceContext employees;
...
}
\\\
/// EmployeeServiceImpl.java
package com.acme;
import javax.annotation.Resource;
import javax.sql.DataSource;
public class EmployeeServiceImpl implements EmployeeService {
@Resource
private DataSource employeeDs;
...
}
\\\
/// ejb-jar.xml
....
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>EmployeeServiceBean</ejb-name>
....
<ejb-class>com.acme.EmployeeServiceImpl</ejb-class>
....
</session>
</enterprise-beans>
</ejb-jar>
\\\
Note that even though the class EmployeeServiceBean expresses a
dependency on a persistence context, the EJB container won't inject
this dependency as the ejb-jar.xml _replaces_ the annotated EJB.
Actually, I don't know exactly what the EJB container internally
really does, but at least no exception will be thrown because of a
missing field 'employees'.
I don't understand quite what you are saying. Managed bean
annotations can only be in one place ... on the source code for bean
classes in your application.
I just wanted to say that one can't know the bean class which defines
the annotations, just from looking at the faces-config.xml. Unlike the
shale-tiger module an EJB container just injects those dependencies
that have been declared in the actual ejb-class (no matter how many
other enterprise beans you define using annotations with the same
ejb-name; see also the example above).
Bernhard Huemer
