|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
List 1-A is an example of an EJB 1.0 bean using the EJBContext to read an environment property used to validate a request (the comparison is applicable to both entity and session beans).
List 1-B is an example of how an EJB 1.1 bean would use the new JNDI ENC to obtain an environment property to also validate
a request.
public class AccountBean implements EntityBean {
int id;
double balance;
EntityContext ejbContext;
public void setEntityContext(EntityContext ctx){
ejbContext = ctx;
}
public void withdraw(Double withdraw)
throws WithdrawLimitException {
Properties props = ejbContext.getEnvironment();
String value = props.getProperty("withdraw_limit");
Double limit = new Double(value)
if (withdraw.doubleValue() > limit.doubleValue())
throw new WithdrawLimitException(limit);
else
balance = balance - withdraw.doubleValue();
}
...
}
|
public class AccountBean implements EntityBean {
int id;
double balance;
EntityContext ejbContext;
public void setEntityContext(EntityContext ctx){
ejbContext = ctx;
}
public void withdraw(Double withdraw)
throws WithdrawLimitException {
InitialContext jndiContext = new InitialContext();
Double limit = (Double)
jndiContext.lookup("java:comp/env/withdraw_limit");
if (withdraw.doubleValue() > limit.doubleValue())
throw new WithdrawLimitException(limit);
else
balance = balance - withdraw.doubleValue();
}
...
}
|
In both EJB 1.0 and EJB 1.1, the value associated with the property name withdraw_limit is used as a business validation boundary. You can use properties for many things, including validation boundaries and other
static values. The advantage of using environment properties is that you can modify the bean's behavior without having to
change its code.
In EJB 1.0, environment properties are limited to String types and are available through the EJBContext. In EJB 1.1, environment properties can be a type of String or any one of the primitive numerical wrappers (Integer, Long, Double, Boolean, Byte, and Float); they are available through a default JNDI context. Why the change? EJB 1.1 wanted to extend the bean-container contract
to address many of the issues that would have mandated complicated changes to the EJBContext interface. To avoid the limitations of EJBContext -- its definition is fixed and therefore limited -- the JNDI ENC was introduced, which provides a more dynamic and extensible
bean-container interface. The EJBContext still exists, with some changes, but most of the new EJB 1.1 features are realized through the JNDI ENC.