|
|
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 4 of 6
For example, the Gemstone/J server supports most of the EJB 1.1 features, with one notable exception: it does not use of the
JNDI ENC to obtain a JDBC database connection. When a database connection is needed, it is instead obtained using the DriverManager.getConnection() method. To support beans deployed in a Gemstone/J server, you simply define a Gemstone/J concrete implementation. List 8
is an example of just such an vendor-specific implementation.
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.ejb.EJBContext;
import javax.ejb.EJBException;
import java.sql.SQLException;
import javax.rmi.PortableRemoteObject;
import java.sql.DriverManager;
import java.security.Principal;
public class GSPortableContext3_0 extends PortableContext {
InitialContext jndiContext;
public Principal getCallerPrincipal( ){
return ejbContext.getCallerPrincipal();
}
public boolean isCallerInRole(String roleName){
return ejbContext.isCallerInRole(roleName);
}
public Object lookup(String name, Class type)throws PortableContextException{
try{
jndiContext = new InitialContext();
Object value = jndiContext.lookup(name);
if(name.startsWith("java:comp/env/jdbc")){ return DriverManager.getConnection((String)value);
}
else if(name.startsWith("java:comp/env/ejb")){
return PortableRemoteObject.narrow(value,type);
}
else
return value;
}catch(NamingException ne){
throw new PortableContextException(ne);
}catch(SQLException se){
throw new PortableContextException(se);
}
}
}
|
If you were to run a forward-compatible bean (one that uses PortableContext) in BEA's Weblogic Server 4.5, for example, you would use the PortableContext1_0 concrete implementation. The same bean could later be deployed in Gemstone/J 3.0 server by simply changing the system property
java.ejb.portable_context to point at the GSPortableContext3_0 concrete implementation.
The most obvious change in EJB 1.1 is its mandated support for entity beans. This support must be complete, embracing support for both container-managed and bean-managed persistent entities. As big and burly as this change is, it's not going to significantly affect the portability of beans developed in 1.0 servers. If entity beans weren't available before, then the new version simply makes them available to you; if you're already using entity beans, then in all likelihood you will need to make some cumbersome but simple changes to your code.
The entity bean did not make it into EJB 1.1 unchanged. In addition to changes in the EJBContext and access to beans and resources (addressed above), entity beans also lost bean-managed transactions and changed the return
value of ejbCreate(..) methods.
In EJB 1.0 and 1.1, you can manage transactions both by declaration and by explicit use of a transactional bean-container
interface. This declarative transaction control, called container-managed transactions (CMT), is the simplest of the two options because it doesn't require that a bean developer explicitly control the transactional
bounds -- it's automatic. In bean-managed transactions (BMT), the bean uses the EJBContext and the UserTransaction object to explicitly control the transaction. In EJB 1.0, both stateful and entity beans had the option of using BMT instead
of CMT; this was deemed necessary in order to accommodate fairly complicated and unusual scenarios in which declarative transaction
control was too restrictive. In practice, the use of BMT in stateful session beans is more common than BMT in entity beans.
This is good, because EJB 1.1 prohibits the use of BMT in entity beans. If you are developing beans to the EJB 1.0 specification,
you must not use BMT if you want your bean to port to EJB 1.1 servers.
Server-side Java: Read the whole series -archived on JavaWorld