Tài liệu XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application- P4 docx

132 Chapter 6 bonForum Chat Application: Implementation Using Xalan-Java 2 Instead of Xalan-Java 1 The bonForum release with this book was developed before a stable release of Xalan- Java 2 was available. It turned out that the part of Xalan that we use (XSLT transfor- mation) was among the most reworked parts of the Xalan product as it went to version 2. Here is what the version 2 readme.html says: Given the scope of the redesign, the changes with respect to Xalan-Java 1.x are global in nature …. Xalan-Java 2 implements the TraX (Transformation API for XML) interfaces.The product of extensive open-source collaboration by mem- bers of the XML developer community,TrAX provides a conceptual framework and a standard API for performing XML transformations. Fortunately, the changeover to Xalan-Java 2 did not have a major impact on the design of bonForum—it requires only a somewhat different way to create and use an XSLT processor—so the input and output of that processor will remain the same. For infor- mation about using either Xalan Java 1 or 2 with the bonForum project, please refer to Chapter 4, “XML and XSLT: Xerces and Xalan,” Section 4.5, “Installing Xalan.” Also, check for the latest bonForum information at www.bonForum.org . Xalan’s XSLT Servlet At the time we were developing our XSLT custom tag, there was no XSLT servlet in Xalan.Today, we may be tempted to solve the XSLT requirements of our JSP tag by having it access the XSLT servlet that is now provided with Xalan.We recommend that you try that approach in similar situations.We tried again, with Xalan 2.0.0, but it still had the old documentation for the Xalan-Java 1.2.2 servlet, although it has changed drastically, including the name of the servlet. Now, with Xalan 2.0.1, the servlet sample is a very useful resource. Relative to the root folder for either Xalan- Java 1 or Xalan-Java 2, look for the XSLT servlet documentation at /docs/samples.html#servlet . JSP Scripting with Java Code We found some code in the Xalan sample TransformToDom that looked promising. We decided to put some similar code directly on a JSP, using scriptlets, just to test it. After it was working, we would encapsulate it in a tag class.The details of that code are discussed in section 10.6,“XSLT and the TransformTag Class,” of Chapter 10. We had hit upon perhaps the best procedure for developing the Web application. Developing and testing code directly on a JSP is fast and simple. After it works, you can move it into a separate class, which makes the JSP simpler and enables you to reuse the code elsewhere.We do this only to speed up development; the code usually doesn’t belong in the JSP servlet and needs encapsulation in its own object. XSLT from a JSP Custom Tag Our JSP custom tag for choosing an Actor-Action-Thing command was already send- ing three generic attributes as arguments to a Java servlet method. It was an easy step 06 1089-9 CH06 6/26/01 7:30 AM Page 132 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 133 6.1 Building the bonForum Web Chat to alter that testbed tag so that it could function also as an XSLT processor.The code that we had used to test our JSP scriptlets was further developed on our chameleon tag and finally found a home in the TransformTag class.With it, we could do the follow- ing on our JSP: <bon:transform type=”XalanVersion” inDoc=” \\webapps\\bonForum\\mldocs\\foo.xml” styleSheet=” \\webapps\\bonForum\\mldocs\\foo.xsl” outDoc=” \\webapps\\bonForum\\mldocs\\foo.html” > </bon:transform> Actually, the type value shown is a rather late addition.We now use type attribute val- ues to select XSLT processes. Current acceptable values are “Xalan Java 1” and “Xalan Java 2”.There is also a session attribute called “xalanVersion” which can be set to any acceptable value for the type attribute. One way you can set that session attribute is by including something like the following HTML form (JSP or otherwise) that is POSTED to the BonForumEngine: <form name=”forum_entry” method=”POST” action=”/bonForum/servlet/BonForumEngine”> <label for=”xalanVersion”> Apache Xalan Version? </label> <input id=”xalan1” type=”radio” name=”xalanVersion” value=”Xalan-Java 1”> Xalan-Java 1 </input> <input id=”xalan2” type=”radio” name=”xalanVersion” value=”Xalan-Java 2” CHECKED> Xalan-Java 2 </input> <input type=”hidden” name=”actorReturning” value=”yes”> </input> <input type=”hidden” name=”bonCommand” value=”visitor_executes_choice”> </input> <input type=”submit” value=”continue” name=”submit”> </input> </form> The BonForumEngine servlet will set the session attribute from the request parameter. The tag class will get and use that session attribute if a value of xalanVersion is used for the type attribute in the custom tag on the JSP. Do not worry if the details are not clear at this point, more will be said about all this later. The output of the XSLT process need not be HTML—it can be XML, for example. It can also go to a custom scripting variable named output , which it does when the outDoc attribute is set to output or outputNormalized . Instead of using a file for its XML InputSource , TransformTag can instead use the contents of the ForestHashtable XML database. It does that if the first attribute is set to the string value bonForumXML .This turned out to be one of our best tools for devel- oping bonForum (see Chapter 10). Our JSP now has powerful possibilities using TransformTag . For example, we can dump our entire database out to the browser for debugging like this: 06 1089-9 CH06 6/26/01 7:31 AM Page 133 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 134 Chapter 6 bonForum Chat Application: Implementation <bon:transform type=”bonTransform” inDoc=” bonForumXML “ styleSheet=” \\webapps\\bonForum\\mldocs\\identity.xsl” outDoc=”outputNormalized” > <%=output%> </bon:transform> 6.1.15 Style Sheets When we had TransformTag working, we were able to use some XSL style sheets to accomplish some of our XML data-display goals. Eventually, as the prototype is further developed, we expect that there will be many more style sheets.The ones that we have used already are discussed in Chapter 10. All the style sheets that we used in the book version of bonForum were applied using XSLT to the entire contents of the bonForumXML ForestHashtable . In the future, we plan to have a more selective mechanism for determining the XML InputSource for the XSLT process. For that reason, we have already included in the project a second ForestHashtable object, named bonBufferXML . It will help when we want to apply XSLT to only a selected subset of the entire data contents of bonForum. The XSL style sheet files are all found in the folder TOMCAT_HOME\webapps\ bonForum\mldocs. Here is a list of the XSL style sheet documents in use when this book went to print.They are used for getting a list of available chats, a list of the guests in a chat, and a list of links to other resources, (including other bonForums, presumably): bonChatItems.xsl bonChatGuests.xsl bonForumLinks.xsl 6.1.16 Session-Based Application Information We highly recommend to any reader interested in Java the book Thinking in Java,by Bruce Eckels, published by Prentice Hall.At this time, you can freely download a pre- view version of the entire book. Find out more about this very useful book by visiting the Web address http://www.mindview.net . One chapter of that book that may be helpful for understanding bonForum is Chapter 15, “Distributed Computing.” In particular, the two sections entitled “Servlets” and “JavaServer Pages” are recommended because they explain the use of the session object in servlets and the various data scopes available in JSP. Much of the bonForum application information that is not kept in the bonForumXML data storage object typically ends up being kept in HTTP session attrib- utes.We have seen, for example, that on our JavaServer pages many HTML form ele- ments are POSTed to the BonForumEngine servlet.These forms include input elements whose values are visible within that servlet as HTTP request parameter values. 06 1089-9 CH06 6/26/01 7:31 AM Page 134 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 135 6.1 Building the bonForum Web Chat If one of these application variables will be required again, when a different HTTP request (from the same browser session) is being serviced, the BonForumEngine servlet copies it to a session attribute that it creates with the same name as the request para- meter. Here is an example, from BonForumEngine.java: chatTopic = normalize((String)request.getParameter(“chatTopic”)); if(chatTopic.trim().length() > 0) { session.setAttribute(“chatTopic”, chatTopic); } In case you are wondering what the normalize method does, it serves two purposes. It makes sure that strings input by the users can be legally included in the XML data, by substituting inadmissible characters with the appropriate character entities. It also replaces null values with empty strings so that we do not later have to add code to check for null values. Nor do we have to handle null-value exceptions commonly caused by passing null string values to Java methods that expect a string. One session attribute in the application is called bonForumStore . It enables us to find the application interface to its XML database from anywhere, including JSP, that can access the session object with this attribute. The use of session attributes to store information has important features and conse- quences that must be grasped to understand the Web application implementation: n Each user is provided a separate variable context in the Web application. n Each user context is tied to the existence and duration of one session, which connects all the requests made by one browser for a configurable period of activity. n When a session expires, all information in its user context becomes inaccessible. In addition to maintaining user-related information in storage locations with session scope, we used a user’s current session ID to connect the user to important elements in the XML storage so that these could be quickly found and retrieved.That is dis- cussed in the next section. Meanwhile, notice that when a session expires, these XML elements also become “orphans” in the application, inaccessible to the code. Obviously, these effects of the volatility of session objects must be handled by bonForum before it is deployed.This task has been left for a future version, mostly because it involves design decisions that are better made based on the results of experi- menting with the current implementation.At the very least, we will have to purge “orphan” session-related information from the data. At the other extreme, we could do what some commercial chat sites do, which is to implement a system of associating registered users with unique IDs and then track each user across all their bonForum sessions. 6.1.17 Avoiding Parsing and Searching A major theme in the implementation of bonForum has been to find ways to opti- mize the application for speed.We have tried to find mechanisms that will scale up to installations handling thousands of simultaneous users.That is not to say that the prototype bonForum can do that. In fact, some of its methods will certainly need 06 1089-9 CH06 6/26/01 7:31 AM Page 135 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 136 Chapter 6 bonForum Chat Application: Implementation some more work before they can. Nevertheless, one of our experiments turned out promising. Session-Unique Elements As discussed previously, one way to know which data items are related to a particular user of the Web application is to keep those items in session attributes. However, what about all the data that we keep in an XML database? It includes items pertaining to each user, and there must be some way to know what belongs to whom. Of course, this kind of problem is not at all new.There are obvious solutions using relational database tables. On the other hand, if we were using an XML document only to store data, the solution would most likely involve the use of XPATH. However, bonForum stores XML documents in a special hashtable class, ForestHashtable , which is a simulation for a relational database table design. Each ele- ment node of the XML is stored in a table row with a key called a NodeKey , which encodes the position of the node in a tree structure.We had to find our own solution to the problem of relating data to the bonForum users. Let’s use an example here. A user of the bonForum is associated with at particular chat.That chat is represented by an element node in the XML data.We could associate the user with the chat by adding a child element inside the chat element.That child element would either represent the user or point to an element elsewhere that repre- sents the user (we did the latter). We wanted to avoid repeated searches through our data every time the same piece of information was required.There were many places in the code where we needed to know which chat element belonged to the current user. If every time we needed that answer we had to search through all the data looking for the chat element that con- tained a child that was associated with that user, it was time to find a better way. First, we made a rule.Whenever possible, we defined elements in our XML so that they would be unique for each user.That meant that they would be unique within an HTTP session. One session can “own” only one chat element. One session can own only one guest element. The second thing we did was to create another hashtable, called a NodeNameHashtable .The elements that this hashtable holds are NodeKey values.The keys that it uses associate the NodeKey s with a user session.To use the previous example given, the key for the NodeKey of an XML chat node would be something like To1012mC7576871324604071At:chat .The key’s prefix is the ID of the session that owns the chat node. These two things together gave us a mechanism for fast access to data that is related to a particular session and, thus, the user and browser.This mechanism plays a part in quite a few places in the code.You can read more about it in Chapter 11, Section 11.5, “Caching Keys for Fast Node Access.” 06 1089-9 CH06 6/26/01 7:31 AM Page 136 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 137 6.1 Building the bonForum Web Chat PathNameHashtable In Chapter 11, section 11.5, you can also read about another mechanism we employed to prevent time-consuming processing.When a user wants to join a chat, he must choose one from a list displayed by the browser.The list shows the user the subject and topic of each available chat. Processing the user choice involves locating a particu- lar node in the XML data—in this case, a subject node. Instead of searching through the XML somehow, we again have a fast way to get the NodeKey of the node we need.This involves yet another hashtable, this time one called PathNameHashtable . In this case, NodeKey s are stored in the hashtable using keys that indicate the path to a subject element in the XML data tree. As noted elsewhere, we have constrained the possible names that these elements can have. Duplicate sibling-node names are not allowed.Thus, we have a unique set of subject pathnames.When a user chooses a chat to join, the choice is associated with a unique pathname.This pathname can then be used to quickly retrieve the subject ele- ment required for the user to join the chat. 6.1.18 Synchronizing Multiple Threads We soon had to pay more attention to the question of how our Web application would handle an environment in which it was being used by not one developer, but by many clients. One of Java’s strengths is its built-in thread management.We hoped that it could solve the problem of multiple, simultaneous access to our BonForumEngine Java servlet. Again, we recommend to the reader the book Thinking in Java, by Bruce Eckels. Especially helpful in the present context are Chapters 14 and 15: “Multiple Threads” and “Distributed Computing.”That book is a good resource for learning about those two topics. Critical Resources Essentially, we had to find a way to use the Java mechanism of synchronization to pro- tect access to critical resources.We could synchronize access either to methods or to blocks of code.A lot can be said about the topic of synchronization in Java by using the following two analogies: n Synchronizing all the public methods in a class is like saying, “I’m doing this action, so you cannot do that action, nor that action, and so on.” n Synchronizing a block of code on an object is like saying, “I have this thing, so you cannot do that, nor that, and so on.” Of course, the first of the two cases is really the same as the second one, with this class instance being the object upon which code processing is being synchronized. 06 1089-9 CH06 6/26/01 7:31 AM Page 137 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 138 Chapter 6 bonForum Chat Application: Implementation In any case, it is quite apparent that we must protect the bonForum data.The progress of the forum continually depends upon the current contents of its XML rep- resentation, which is what we have chosen to keep in the bonForumXML ForestHashtable object.This XML representation is continually being changed in response to the actions of the actors. In other words, the application data change in response to multiple asynchronous user inputs. Typically, while interacting with one JSP-generated HTML page, each client causes more than one change to bonForumXML .This means that access to that XML represen- tation must be transactional.We made sure that only one client at a time could access the bonForumXML object:We used the synchronized Java keyword. At first, we thought that meant synchronizing all the public methods in BonForumEngine .These include methods that are capable of changing the bonForumXML object. However, if we did that, the lock being used would be on the Java servlet object. It would not be much of a servlet if only one client can access it at a time, so we knew that there must be a better way. Instead, we synchronize any “critical code” sections on the bonForumXML instance. In effect, this means that whoever owns the XML representation of bonForum can access the methods that are capable of changing its contents. All the other users must wait their turn; they are blocked—in effect, queued up and buffered—by the Java synchro- nization mechanism. Questions Regarding Synchronization Certainly, the way that we have set up multiple thread access to the data is an area that needs far more testing. For one thing, it is important to minimize the number and size of synchronized code sections in the application because they constitute bottlenecks and overhead. We also want to make sure that there are no ways to defeat the protections offered by the synchronization that we have added—for example, by accessing methods from JSP. Getting thread synchronization right is partly an art, and we will not be surprised if problems surface. However, after we have implemented a persistent database table from our ForestHashtable design, we will at least be able to recover from a thread clash, which is not possible now! 6.2 Displaying and Selecting Chat Subjects As you have read, our implementation began as a system involving many JSP docu- ments, which used custom tags to access an XML data-interface object and an XSLT processor. At that point, we still had some major problems to solve before this system could work as a chat application. Obviously, one of the first problems that we had to solve was how a visitor to the 06 1089-9 CH06 6/26/01 7:31 AM Page 138 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 139 6.2 Displaying and Selecting Chat Subjects bonForum would start a new chat.We knew from our design that it would involve selecting one element from a subtree of subjects in our XML data.The technical ques- tion became how to display the subjects on a browser and then how to find the XML subject element using the display item that the visitor selected on the browser. We were looking for places to apply XSLT and XPATH in bonForum. In some ways, this seemed like a good place to start, but we decided against that. It was not a simple problem on which to begin applying those technologies. Second, everything else in the project was contingent upon creating a chat, so we wanted a fast solution for that. In addition, our XML data structure was morphing and evolving in response to our attempts to find fast node-lookup mechanisms. 6.2.1 Complexities of Starting a Chat The solutions that we created instead involved the PathNameHashtable , which we dis- cussed earlier. However, starting a chat turned out to be quite a complex problem. Here we list some things involved: n Many chats can exist that all have the same subject, with each chat belonging to a different session. n Each chat element in the XML must somehow be connected to the XML ele- ment for its subject. n Each chat also has a short description added by the user who starts it.This chatTopic must also be stored, related, and retrieved. This chapter is not the place to describe the solution that we devised. Indeed, the solution involved working with all the various parts of our new Web application sys- tem.Therefore, again, understanding what is going on in bonForum may require read- ing relevant sections in several of the more technical chapter yet to come. Here we simply list the book chapters and sections that will help you the most.You might want to mark this list and refer back to it later! n Chapter 7: “JavaServer Pages:The Browseable User Interface” n Section 7.2.5: “visitor_starts_chat_frame.jsp” n Chapter 8: “Java Servlet in Charge: BonForumEngine” n Section 8.1.20: “The processRequests() Method: Handling Host Executes Chat” n Section 8.2.12: “Invoking Chat Methods from JSP Custom Tags” n Chapter 10: “JSP Taglib and Custom Tag: ChoiceTag” n Chapter 11: “XML Data Storage Class: ForestHashtable” n Section 11.5.2: “ NodeKeyHashtables Cache NodeKeys ” n Section 11.5.4: “ PathNameHashtable ” n Section 11.6.4: “Automatic Parent Node Location Retrieval” 06 1089-9 CH06 6/26/01 7:31 AM Page 139 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 140 Chapter 6 bonForum Chat Application: Implementation 6.3 Displaying Chat Messages After we had a chat with a host, we were ready to tackle the problems involved in presenting the chat to a user.We decided to work on the “host executes chat” forum state before the “guest joins chat” forum state. Our solution would also apply to the “guest executes chat” forum state. In addition, it would be more challenging and more capable of positively influencing the rest of the implementation work.The problem turned out to be much more complex than we ever imagined. Getting the job done required solving several challenging technical problems, all related to displaying the chat history for the user. Although we had foreseen some of them during the design phase of the project, we were glad that we had not tried to solve them at that time.The solutions to these problems truly required experimenta- tion.The principles of rapid application development were vindicated in this instance. Actual experience with a prototype was worth much more than theoretical discussion of the technological possibilities. Again, we first considered basing our solution upon XSLT and XPATH. Our rea- sons for not doing so are well covered elsewhere, along with the solutions that we devised.Therefore, in this chapter we will try to discuss only the implementation process itself. Here is a list of all the chapters and sections that will help you to under- stand the process of displaying chat messages: n Chapter 7: “JavaServer Pages:The Browseable User Interface” n Section 7.2.9: “host_executes_chat.jsp” n Chapter 8: “Java Servlet in Charge: BonForumEngine” n Section 8.2.12: “Invoking Chat Methods from JSP Custom Tags” n Chapter 9: “Java Applet Plugged In: BonForumRobot ” n Section 9.3: “ BonForumRobot ” n Chapter 11: “XML Data Storage Class: ForestHashtable ” n Section 11.11: “Initializing the bonForumXML Database” n Section 11.12: “Runtime bonForumXML Database” 6.3.1 The outputForumChatMessages Method There is one very important thing to note about the method that provides the chat messages to list on the browser page. In its current implementation, it iterates through the bonForumXML ForestHashtable contents searching for elements that are named “ message .”This works for the prototype, but the results will take longer to get as the 06 1089-9 CH06 6/26/01 7:31 AM Page 140 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 141 6.3 Displaying Chat Messages database grows. Our plan is to iterate only the message pointers that exist within a particular chat element in the XML data.We had to settle for this interim solution for this version because the real solution had a bug that was found too late to fix before writing this book. It is possible that the version on the CD-ROM does include the correct, efficient algorithm. Also, please check the project Web site at http:// www.bonforum.org for news and new releases. 6.3.2 Session Local Data Versus Chatting One of the rules of our system is that the code that handles one particular user can access only elements in the XML database that belong to that user’s session.That means, for example, that it is not possible for one user’s thread to add an actorNickname child to a different user’s guest actor element. We suddenly realized that by allowing a session to add elements only to parent ele- ments that were also added by that same session, we were making chatting impossible. It seemed that the process of adding a messageKey element to a chat element was dif- ferent from all other add operations. A guest must be allowed to add messages for any chat joined, even if the guest has not added that chat’s element. 6.3.3 The Need to Refresh Chat Messages When an actor adds a message to a chat, that message should be seen very soon by all the other actors in the chat.We needed to find a technique to do this in our bonForum.Without this, it could hardly be called a chat forum; it would be more like a message board than a chat room. Possible Refresh Mechanisms We considered some mechanisms for refreshing the chat history display on the browsers. Some of these were rejected for being too “client-side.” We tried using a Pragma setting to cause a refresh of the page that had the chat messages displayed on it.We got that working, but it had two problems for us. One was that it was quite browser-dependent and would not work on all browsers. Although that was not an immediate consideration because we were only testing with IE5.X, we wanted our Web application eventually to be browser-independent. The worse problem was that there was a lot of flickering in the message’s display. It seems that when IE5 repainted the display, it first erased the old one to white.We started looking for other uses of the refresh Pragma on Web sites and found some that seemed to work. An occasional refresh is not bothersome, especially if you are not always looking right at the frame that is being refreshed. In our case, we wanted one refresh every 5 seconds, so the user would be staring at the flickering messages display most of the time.That was quite bothersome. 06 1089-9 CH06 6/26/01 7:31 AM Page 141 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... would have been using the XSLT JSP tag As an example, here is a batch file (for Xalan 1.2.2) that was used to develop the display of available chats: Rem xalanTest.bat: java org.apache.xalan.xslt.Process -IN test.xml -XSL bonChatItems.xsl -OUT bonChatItems.xml type bonChatItems.xml Note that if you are using Xalan Java 2, you will have to update the command in this batch file.You can find information about... (a ForestHashtable) as a string Now we decided to make it the input XML stream for the Xalan XSLT processor as part of our TransformTag class Displaying the available chats would mean showing both the chat subject and the chat topic.We began with the following vague idea:We would create a style sheet that would find each chat subject item It would accumulate the path to each such element in a variable.Then... described in Chapter 10, so there is no need to elaborate here Our XSLT solution could use some improvement In accordance with our experimental agenda, we pressed on as soon as a minimally acceptable result was obtained Getting a full system up and running is a higher priority than taking care of the details Successful Display of Available Chats The details about displaying available chats are covered in. .. about that by reading the Xalan command line page of the Xalan 2.0.1 docs Assuming the usual drive and installation folder, browse the following document: C:\xalan-j_2_0_1\docs\commandline.html The file, called test .xml, contained fake bonForumXML data that included just enough to test the XSLT processing In the actual bonForum project, the XML input data for the transforms come from the bonForumXML All... app you are developing, try down shutting Tomcat, deleting its work folder with all the work files it needs, and then restarting Tomcat Tomcat can tell when a JSP file has been modified, and it retranslates and recompiles it when necessary.This is one of the advantages of using JSP pages, in fact It means that they are dynamic in many ways:They have a runtime behavior associated with them in their... leveraging the tag classes Creating your own custom tags is as important in a JSPbased design as having subroutines was in early BASIC programs It furthers the separation of page design from code design, and that is the central appeal of JSP In this chapter, we do not discuss using tag libraries to design, but we do discuss one complex tag example: the TransformTag class.You can understand what we do with... chatWelcomeMessage %> The JSP expression in the last line displays a greeting containing the user nickname, entered on a different Web page In the previous state of the Web application, forum entry, the user entered a nickname in a form element.That nickname value was POSTed to the BonForumEngine servlet as a request parameter.The servlet copied its value into a session attribute.There it will remain available as... method=”POST” action=”/bonForum/servlet/BonForumEngine”> join a chat start a chat exit this forum ... “visitor_joins_chat_frame.jsp,” in Chapter 7.The output of the XSLT process now does not need to go to a file and then be read back into the page output, as in our prototype Now we can output it to a scripting variable named output, which we can display within the TransformTag element (You can read about the TagExtraInfo class in the Jakarta servlet API docs.) We could also change the scope of the variable... The Browseable User Interface chatPageNumber for each user.We would have to add a user manager to keep track of all the values for the users.That is what the session object gives us, so why not use it? Using jsp:useBean We can use the same bean in a JSP, however Here is an example from the JSP: host_increases_rating.jsp First, we make the bean available with a jsp:useBean element: . community,TrAX provides a conceptual framework and a standard API for performing XML transformations. Fortunately, the changeover to Xalan-Java 2 did not have a major. 1”> Xalan-Java 1 </input> <input id=”xalan2” type=”radio” name=”xalanVersion” value=”Xalan-Java 2” CHECKED> Xalan-Java 2 </input> <input