Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Server-side Java: Create forward-compatible beans in EJB, Part 2

More key strategies for developing portable EJB 1.0 beans for EJB 1.1 servers

By Richard Monson-haefel, JavaWorld.com, 01/21/00

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.

Other portability changes in EJB 1.1

Changes specific to entity beans

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.

Bean-managed transactions

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.