Java Reference
In-Depth Information
type, javax.ejb.SessionContext . Because DefaultBidService is a session
bean, the result of the injection would be the same if the variable were specified to
be the parent class, EJBContext . In the following code, an underlying instance of
javax.ejb.SessionContext is still injected into the context variable, even if the
variable data type is javax.ejb.EJBContext :
@Resource
private EJBContext context;
Using this code in a session bean would make a lot of sense if you didn't plan to use any of
the bean type-specific methods available through the SessionContext interface any-
way.
Injecting environment entries
If you've been working with Enterprise applications for any length of time, it's likely
you've encountered situations where some parameters of your application change from one
deployment to another (customer site information, product version, and so on). It's overkill
to save this kind of “semi-static” information in the database. This is exactly the situation
environment entry values are designed to handle.
For example, in the ActionBazaar application, suppose you want to set the censorship flag
for certain countries. If this flag is on, the ActionBazaar application checks items pos-
ted against a censorship list specific to the country the application deployment instance is
geared toward. You can inject an instance of an environment entry as follows:
@Resource
private boolean censorship;
Environment entries are specified in the deployment descriptor and are accessible via
JNDI. The ActionBazaar censorship flag could be specified like this:
<env-entry>
<env-entry-name>censorship</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>
Environment entries are essentially meant to be robust application constants and support a
relatively small range of data types. Specifically, the values of the <env-entry-type>
Search WWH ::




Custom Search