in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 149 150 151 152 153 154 < 155 > 156 157 158 159 160 161 .. 166 >> Next

041 }
043 public void ejbCreate() {}
044 public void ejbPostCreate() {}
045 public void ejbRemove()
046 public void ejbActivate()
047 public void ejbPassivate()
048 public void setSessionContext(SessionContext sc) {}
049 }
Listing 49.1 (continued)
What could go wrong in Listing 49.1? First of all, loading a properties file every time the calculateTax() method is called is bad practice. This is a given. More importantly, because the container is responsible for management of this session bean, who knows how many BadTaxCalculator beans may be actually instantiated during heavy loads on the server? When an EJB uses the package to access files on the filesystem, bad things could happen, ranging from very poor performance to running out of file descriptors and bringing down the server.5
5 Van Rooijen, Leander. "Programming Restrictions in EJB Development: Building Scalable and Robust Enterprise Applications." Java Developers Journal. Volume 7, Issue 7, July 2002.
Get Your Beans Off My Filesystem! 431
For this reason, the EJB specification lists programming restrictions related to the classes. In the "Runtime Environment" chapter of the specifications (EJB specifications 1.1, 2.0, and 2.1), the restriction is listed plainly: "An enterprise bean must not use the package to access files and directories in the filesystem. The filesystem APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as the JDBC API, to store data."6 Simply put, because a filesystem is not transactional, and because there is no resource manager involved in operations, you need to keep your beans off the filesystem! This presents us with a challenge: If a bean compiles and deploys into our EJB container without any problems, and it seems to work well when we test it, fatal errors may end up diagnosing the problem.
For our sales tax example, how should we rewrite it? If we store all the sales tax information in a database, this would eliminate the possible problems that we could encounter when using the package. Unfortunately, using a database in this example may be overkill because sales tax usually doesn't change very often, and we could pay a performance penalty for hitting the database every time. In our bad example, we used properties files because they are convenient for configuring our Java applications. Luckily, we can do something similarówith our deployment descriptor.
To customize your beans at runtime, you can use the environment properties in your deployment descriptor. For data that doesn't change often, and for an alternative to using a database for storing information, environment properties work well. Listing 49.2 shows our deployment descriptor for our new bean, in a file called ejb-jar.xml. Each entry, designated by the XML tag <env-entry>, contains a <description> tag, a name designated by <env-entry-name>, a type designated by <env-entry-type>, and a value designated by <env-entry-value>. As you can see from our listing of this deployment descriptor, we converted the original properties file to this format.
001 <?xml version="1.0" encoding="UTF-8"?>
002 <ejb-jar>
003 <description>GoodTaxCalculatorBean</description>
004 <display-name>GoodTaxCalculatorBean</display-name>
005 <enterprise-beans>
006 <session>
007 <ejb-name>GoodTaxCalculator</ejb-name>
008 <home>org.javapitalls.item49.GoodTaxCalculatorHome</home>
009 <remote>org.javapitfalls.item49.GoodTaxCalculator</remote>
010 <ejb-class>
011 org.javapitfalls.item49.GoodTaxCalculatorBean
012 </ejb-class>
013 <session-type>Stateless</session-type>
014 <transaction-type>Bean</transaction-type>
015 <env-entry>
016 <description>Alabama Sales Tax</description>
Listing 49.2 Setting environment entries in ejb-jar.xml (continued)
6 Enterprise JavaBeans Specification 2.1, Chapter 25; Enterprise JavaBeans Specification 2.0, Chapter 20; Enterprise JavaBeans Specifications 1.1, Chapter 18.
432 Item 49
017 <env-entry-name>Salestax.AB</env-entry-name>
018 <env-entry-type>java.lang.String</env-entry-type>
019 <env-entry-value>.04</env-entry-value>
020 </env-entry>
021 <env-entry>
022 <description>Virginia Sales Tax</description>
023 <env-entry-name>Salestax.VA</env-entry-name>
024 <env-entry-type>java.lang.String</env-entry-type>
025 <env-entry-value>.04</env-entry-value>
026 </env-entry>
027 </session>
028 </enterprise-beans>
029 </ejb-jar>
Listing 49.2 (continued)
To access these properties, the bean must do a JNDI lookup. Listing 49.3 demonstrates this approach. On lines 18 and 19, the session bean gets the initial context and uses it to look up the environment entries. These entries are always found under JNDI in java:comp/env. Finally, the lookup for the sales tax for a certain state is done by looking up the value of the current state's sales tax on line 20.
001 package 9 4 m e t i s l l a LM t i p a v a j g. r o
003 import java.rmi.RemoteException;
Previous << 1 .. 149 150 151 152 153 154 < 155 > 156 157 158 159 160 161 .. 166 >> Next