Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss

JavaSercer Pages The WEB-INF/web.xml file must then contain (Tomcat hosting)

JavaSercer Pages The WEB-INF/web.xml file must then contain the following elements: … /orataglib /WEB-INF/lib/orataglib_1_0.jar … The element contains the symbolic name, and the element contains the path to either the JAR file or the extracted TLD file. page 234
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans

JavaSercer Pages 16.10 Packaging and Installing a Tag

JavaSercer Pages 16.10 Packaging and Installing a Tag Library During development, you may want to let the tag library classes and the TLD file reside as-is in the filesystem, since it makes it easy to change the TLD and modify and recompile the classes. Just make sure the class files are stored in a directory that’s part of the classpath for the JSP container, such as the WEBINF/ classes directory for the web application. The TLD must also be in a directory where the JSP container can find it. The recommended location is the WEB-INF/tlds directory. To identify the library with the TLD stored in this location, use a taglib directive in the JSP pages like this: <%@ taglib uri="/WEB-INF/tlds/orataglib_1_0.tld" prefix="ora" %> Here the uri attribute refers directly to the TLD file’s location. When you’re done with the development, you may want to package all tag handler classes, TagExtraInfo classes, beans used by the tag handler classes, and the TLD in a JAR file. This makes it easier to install the library in an application. The TLD must be saved as /META-INF/taglib.tld within the JAR file. To create the JAR file, first arrange the files in a directory with a structure like this: META-INF/ taglib.tld com/ ora/ jsp/ tags/ generic/ EncodeHTMLTag.class … util/ StringFormat.class … The structure for the class files must match the package names for your classes. Here a few of the classes in the tag library for this java blog are shown as an example. With the file structure in place, use the jar command to create the JAR file: jar cvf orataglib_1_0.jar META-INF com This command creates a JAR file named orataglib_1_0.jar containing the files in the META-INF and com directories. Use any JAR filename that makes sense for your own tag library. Including the version number for the library is also a good idea, since it lets the users know which version of the library they are using. You can now use the packaged tag library in any application. Just copy the JAR file to the application’s WEBINF/ lib directory and use a taglib directive like this in the JSP pages: <%@ taglib uri="/WEB-INF/lib/orataglib_1_0.jar" prefix="ora" %> Note that the uri attribute now refers to the JAR file instead of the TLD file. A JSP 1.1 container is supposed to be able to find the TLD file in the JAR file, but this is a fairly recent clarification of the specification. If the JSP container you use doesn’t support this notation yet, you have to extract the TLD file from the JAR file, save it somewhere else, for instance in WEB-INF/tlds, and let the uri attribute refer to the TLD file instead. Instead of letting the taglib directive point directly to the TLD or JAR file, you can specify a symbolic name as the uri attribute value, and provide a mapping between this name and the real location in the WEBINF/ web.xml file for the application: <%@ taglib uri="/orataglib" prefix="ora" %> page 233

Hint: This post is supported by Gama web hosting php mysql provider

JavaSercer Pages 16.9 How Tag Handlers May Be (Comcast hosting)

JavaSercer Pages 16.9 How Tag Handlers May Be Reused Creating new objects is a relatively expensive operation in Java. For high-performance applications, it’s common to try to minimize the number of objects created and reuse the same objects instead. The JSP 1.1 specification describes how a tag handler instance can be reused within the code generated for a JSP page if the same type of custom action appears more than once. The reuse is subject to a number of restrictions and relies on tag handler classes dealing with their internal state as specified. It’s important to understand the reuse rules, so your tag handler classes behave as expected in a JSP implementation that takes advantage of this mechanism. As discussed in the previous sections of this chapter, a tag handler’s state is initiated through property setter methods corresponding to the action element’s attributes. The tag handler is then offered a chance to do its thing in various stages, represented by the doStartTag( ), doInitBody( ), doAfterBody( ), and doEndTag( ) methods. It’s clear that the property values must be kept at least until the tag handler has done what it intends to do. But when can it safely reset its state? If a tag handler implements all logic in the doStartTag( ) method, can it reset all instance variables before it returns from this method? Or should it wait until the doEndTag( ) method is called? The answer is that it must not reset the state until the release( ) method is called. Let’s use a JSP page fragment to discuss why: In this case, a JSP container is allowed to use one instance of the tag handler for both action elements, with generated code similar to this: // Code for first occurrence MyActionTag _jspx_th_test_myAction_1 = new MyActionTag( ); _jspx_th_test_myAction_1.setPageContext(pageContext); _jspx_th_test_myAction_1.setParent(null); _jspx_th_test_myAction_1.setAttr1(”one”); _jspx_th_test_myAction_1.setAttr2(”two”); _jspx_th_test_myAction_1.doStartTag( ); if (_jspx_th_test_myAction_1.doEndTag( ) == Tag.SKIP_PAGE) return; // Code for second occurrence _jspx_th_test_myAction_1.setAttr2(”new”); _jspx_th_test_myAction_1.doStartTag( ); if (_jspx_th_test_myAction_1.doEndTag( ) == Tag.SKIP_PAGE) return; _jspx_th_test_myAction_1.release( ); As you can see, all the property setter methods are called to initialize the instance for the first occurrence of the element. But for the second occurrence, only the setter method for the property with a different value is called. The release( ) method is called when the tag handler has been used for both occurrences. If the tag handler class resets all property variables in any method other than release( ), the processing of the second action element fails. The only scenario in which a tag handler can be reused in JSP 1.1 is the one described above. If the same action element is used multiple times on the same page but with different sets of attributes, the state of the tag handler is not guaranteed to be correct if the same instance is reused. Reuse between pages, using a tag handler object pool, is not explicitly supported in JSP 1.1. For this reason, most JSP containers do not implement tag handler pooling today. To get your tag handler classes to work with the few that do, you must reset all properties before the tag handler is used to handle a new request. I recommend that you do this in the release( ) method, as shown in the examples in this chapter. Note that if some properties must have a default value set instead of null, you must set it in the release( ) method as well. A typical example is a primitive type property, such as an int property: public void release( ) { aStringProperty = null; anIntProperty = -1; } To make it easier for a container to reuse tag handlers, both within a page and between pages, a future version of JSP will likely introduce a method that resets all properties in a controlled manner. page 232
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check professional tomcat hosting services

JavaSercer Pages Another optional element is . It (Buy webspace)

JavaSercer Pages Another optional element is . It can contain one of three values. A value of empty means that the action body must be empty. If the body can contain JSP elements, such as standard or custom actions or scripting elements, the JSP value should be used. All JSP elements in the body are processed, and the result is handled as specified by the tag handler (i.e., processed by the tag handler or sent through to the response body). This is also the default value, in case you omit the element. The third alternative is tagdependent. This value means that possible JSP elements in the body are not processed. Typically, this value is used when the body is processed by the tag handler and the content may contain characters that could be confused with JSP elements, for example, SELECT * FROM MyTable WHERE Name LIKE ‘<%>‘. If a tag that expects this kind of body content is declared as JSP, the <%> is likely to confuse the JSP container. The tagdependent value can be used to avoid this risk for confusion. The element can optionally be used to describe the purpose of the action. The element must also contain an element for each action attribute. Each element in turn contains other elements that describe the attribute: , , and . The mandatory element contains the attribute name. The optional element tells if the attribute is required or not. The values true, false, yes, and no are valid, with false being the default. Finally, the element is an optional element that can have the same values as the element. If the value is true or yes, a request-time attribute expression can be used to specify the attribute value, for instance ‘attr=”<%= request.getParameter("par") %>‘. The default value is false. 16.8 Validating Syntax The TLD for a tag library contains information about the attributes each action element supports. Therefore, the JSP container can help by verifying that the custom action is used correctly by the page author, at least with respect to the attributes. When the JSP container converts a JSP page to a servlet, it compares each custom action element to the specification of the action element in the TLD. First, it makes sure that the action name matches the name of an action specified in the TLD corresponding to the action element’s prefix. It then looks at the attribute list in the page and compares it to the attribute specification in the TLD. If a required attribute is missing, or an attribute is used in the page but not specified in the TLD, it reports it as an error so the page author can correct the mistake. But for some actions, it’s not that simple. Some attributes may depend on the presence of other attributes. Attributes may be mutually exclusive, so that if one is used, the other must not be used. Or an optional attribute may require that another optional attribute is used as well. To be able to verify these kinds of dependencies, the JSP container asks the tag handler’s TagExtraInfo subclass for assistance. After the JSP container has checked everything it can on its own, it looks for a TagExtraInfo subclass, defined by the element, for the action. If one is defined, it puts all attribute information in an instance of the TagData class and calls the TagExtraInfo isValid( ) method: public boolean isValid(TagData data) { // Mutually exclusive attributes if (data.getAttribute(”attr1″) != null && data.getAttribute(”attr2″ != null) { return false; } // Dependent optional attributes if (data.getAttribute(”attr3″) != null && data.getAttribute(”attr4″ == null) { return false; } return true; } A TagExtraInfo subclass can use the TagData instance to verify that all attribute dependencies are okay, as in this example. In JSP 1.1, unfortunately, there’s no way to generate an appropriate error message; the method can only return false to indicate that something is not quite right. This will hopefully be rectified in a future version of JSP. page 231
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

JavaSercer Pages redirect com.ora.jsp.tags.generic.RedirectTag JSP Encodes the url (Blog hosting)

JavaSercer Pages redirect com.ora.jsp.tags.generic.RedirectTag JSP Encodes the url attribute and possible param tags in the body and sets redirect headers. page true true … At the top of the TLD file, you find a standard XML declaration and a DOCTYPE declaration, specifying the Document Type Definition (DTD) for this file. A DTD defines the rules for how elements in an XML file must be used, such as the order of the elements, which elements are mandatory and which are optional, if an element can be included multiple times, etc. If you’re not familiar with XML, don’t worry about this. Just accept the fact that you need to copy the first two elements of Example 16.8 faithfully into your own TLD files. Regarding the order of the elements, just follow the same order as in Example 16.8. Whether an element is mandatory or optional is spelled out in the following descriptions of each element. After the two declarations, the first element in the TLD file must be the element. This is the main element for the TLD, enclosing all more specific elements that describe the library. Within the body of the element, you can specify elements that describe the library as such, as well as each individual tag handler. Let’s start with the five elements that describe the library itself. The element is mandatory and is used to specify the tag library version. The version should be specified as a series of numbers separated by dots. In other words, the normal conventions for software version numbers, such as 1.1 or 2.0.3, should be used. The element, specifying the version of the JSP specification that the library depends on, is optional. The default value is 1.1. The element is intended to be used by page authoring tools. It’s a mandatory element that should contain the default prefix for the action elements. In Example 16.8 the value is ora, meaning that an authoring tool by default generates custom action elements using the ora prefix, for instance . This element value can also be used by a tool as the value of the prefix attribute if it generates the taglib directive in the JSP page. The element value must not include whitespace or other special characters, or start with a digit or underscore. The element is also intended to benefit authoring tools. The value can be used as the default value for the uri attribute in a taglib directive. It’s an optional element, following the same character rules as the element. The last element that describes the library as such is the optional element. It can be used to provide a short description of the library, perhaps something a tool might display to help users decide if the library is what they are looking for. Besides the general elements, the TLD must include at least one element. The element contains other elements that describe different aspects of the custom action: , , , , , and . The element is mandatory and contains the unique name for the corresponding custom action element. The element, also mandatory, contains the fully qualified class name for the tag handler class. If the action introduces variables or needs to do additional syntax validation as described in the next section, the optional element is used to specify the fully qualified class name for the TagExtraInfo subclass. page 230
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check professional tomcat hosting services

JavaSercer Pages class Versus className (Free speech web hosting) You may have

JavaSercer Pages // Set the first loop value,

JavaSercer Pages // Set the first loop value, if any if (enum != null && enum.hasMoreElements( )) { Object currValue = enum.nextElement( ); pageContext.setAttribute(loopId, currValue); return EVAL_BODY_TAG; } else { return SKIP_BODY; } } After verifying that there really is an object with the specified name, a test is done to see if a property name is specified. If it is, the getProperty( ) method is called to retrieve the property value from the specified object so it can be used for the iteration. If a property name is not specified, the object itself is used. All the supported data structure types can be turned into an Enumeration. That’s done by calling the getEnumeration( ) method. The getProperty( ) method and the getEnumeration( ) method are not shown here, because this code is just plain Java code that has nothing to do with implementing iteration in a tag handler. You can look at the source code to see how they work. When the Enumeration has been created, the doStartTag( ) method initializes the loopId variable and places it in the JSP page scope. As you learned in the previous section, the code generated for the page uses the information gained from the LoopTagExtraInfo class to declare a Java variable and assign it the value it finds in one of the JSP scopes, right after the doStartTag( ) call. When the body has been evaluated, the doAfterBody( ) method is called: public int doAfterBody( ) throws JspException { if (enum.hasMoreElements( )) { Object currValue = enum.nextElement( ); pageContext.setAttribute(loopId, currValue); return EVAL_BODY_TAG; } else { return SKIP_BODY; } } The Enumeration is tested to see if it contains any more values. If it does, the loopId page scope variable is reassigned to the new value, and EVAL_BODY_TAG is returned to evaluate the body again. When the end of the Enumeration is reached, SKIP_BODY is returned to break the iteration. When the doAfterBody( ) method returns SKIP_BODY, the doEndTag( ) method is called: public int doEndTag( ) throws JspException { // Test if bodyContent is set, since it will be null if the // body was never evaluated (doStartTag returned SKIP_BODY) if (getBodyContent( ) != null) { try { getPreviousOut().print(getBodyContent( ).getString( )); } catch (IOException e) {} } return EVAL_PAGE; } For every iteration, the content of the evaluated body is buffered in the BodyContent instance assigned to the tag handler. In the doEndTag( ), the content is simply moved to the parent’s BodyContent instance or the main JspWriter instance for the page. An alternative to accumulating the content until the doEndTag( ) method is called is to write it to the parent’s output stream already in the doAfterBody( ) method, using the same code as shown here. page 228
Hint: If you are looking for high quality webhost to host and run your jsp application check Vision web hosting jsp services

Php5 web hosting - JavaSercer Pages Current value: Here, the tag iterates

JavaSercer Pages

    Current value: <%= x %>    

Here, the tag iterates over the elements of a String array, adding the current value to the response using a JSP expression in the action’s body. The com.ora.jsp.tags.generic.LoopTag class is the tag handler class for the action. It extends BodyTag support and has four properties: public class LoopTag extends BodyTagSupport { private String name; private String loopId; private String className; private String property; … A standard property setter method is provided for each property. This is no different than in previous examples, so it’s not shown here. The name, loopId, and className properties are mandatory. The name is the name of a JSP scope variable of one of the types listed earlier. The current value of the data structure is made available in the element body through a variable with the name specified by loopId, of the type specified by className. Optionally, property can be specified. If it is, it’s used to get the data structure from the specified property of the bean named by name, instead of using the name object itself as the data structure. To make the loopId variable available in the element’s body, a TagExtraInfo subclass is needed, as described in the previous section. The LoopTagExtraInfo class looks like this: public class LoopTagExtraInfo extends TagExtraInfo { public VariableInfo[] getVariableInfo(TagData data) { return new VariableInfo[] { new VariableInfo(data.getAttributeString(”loopId”), data.getAttributeString(”className”), true, VariableInfo.NESTED) }; } } It introduces a variable named by the loopId attribute, with the type specified by the className attribute. The scope is specified as NESTED, meaning the variable is available only within the action element’s body. In addition to the property variables, the tag handler class has an Enumeration instance variable: private Enumeration enum; This variable is initiated by the doStartTag( ) method: public int doStartTag( ) throws JspException { Object obj = pageContext.findAttribute(name); if (obj == null) { throw new JspException(”Variable ” + name + ” not found”); } Object mvObj = obj; try { // Get the multi-value object using the specified property // getter method, if any if (property != null) { mvObj = getProperty(obj, property); } enum = getEnumeration(mvObj); } catch (JspException e) { throw new JspException(”Error getting loop data from ” + name + “: ” + e.getMessage( )); } page 227

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Sandzak jsp web hosting provider

Oscommerce web hosting - JavaSercer Pages The UsePropertyTagExtraInfo class sets the scope

JavaSercer Pages The UsePropertyTagExtraInfo class sets the scope to AT_END . As you can see in Example 16.5, this results in the variable declaration and assignment code being added after the doEndTag( ) call. To satisfy the second requirement, the tag handler must therefore give the variable a value and save it in one of the JSP scopes at the very latest in the doEndTag( ) method. Example 16.7 shows the doEndTag( ) method for the UsePropertyTag class. Example 16.7. Saving the New Object in a JSP Scope public int doEndTag( ) throws JspException { Object obj = pageContext.findAttribute(name); if (obj == null) { throw new JspException(”Variable ” + name + ” not found”); } Object propObj = getProperty(obj, property, className); pageContext.setAttribute(id, propObj); return SKIP_BODY; } The value is added to the page scope by calling the setAttribute( ) method on the current PageContext object, using the name specified by the id attribute. If the scope is specified as AT_BEGIN instead, the declaration is added before the doStartTag( ) call and the assignment code is added right after the call. In this case, the tag handler must save the variable in a JSP scope in the doStartTag( ) method. If the tag handler implements BodyTag, assignment code is also added so that it is executed for every evaluation of the body, and after the call to doAfterBody( ) . This allows the tag handler to modify the variable value in the doAfterBody( ) method, so each evaluation of the body has a new value. When we look at an iteration action later, you’ll see why this is important. Finally, if the scope is set to NESTED, both the declaration and the value assignment code are inserted in the code block representing the action body. The tag handler must therefore make the variable available in either the doStartTag( ) method or the doInitBody( ) method, and can also modify the value in the doAfterBody( ) method. The UsePropertyTagExtraInfo class sets the varName and className properties of the VariableInfo bean to the values of the id and className attributes specified by the page author in the JSP page. This is done using another simple class named TagData , passed as the argument to the getVariableInfo( ) method, as shown in Example 16.6. The TagData instance is created by the JSP container and contains information about all action attributes that the page author specified in the JSP page. It has two methods of interest. First, the getAttributeString( ) method, used in Example 16.6, simply returns the specified attribute as a String. But some attribute values may be specified by a JSP expression instead of a string literal, so-called request- time attributes. Since these values are not known during the translation phase, the TagData class also provides the getAttribute( ) method to indicate if an attribute value is a literal string, a request-time attribute, or not set at all. The getAttribute( ) method returns an Object. If the attribute is specified as a request-time value, the special REQUEST_TIME_VALUE object is returned. Otherwise, a String is returned, or null if the attribute is not set. 16.6 Developing an Iterating Action As I alluded to earlier, a tag handler can iterate over the element’s body until some condition is true. The evaluation of the body may be different for each iteration, since the tag handler can introduce a variable (used in the body) that changes its value. An example of an iterating action is the used in this book. It can be used to iterate over the element body once for each value in an array, a java.util.Vector, a java.util.Dictionary, or a java.util.Enumeration. Here’s an example of how the action can be used: <%@ page language="java" contentType="text/html" %> <%@ taglib uri="/orataglib" prefix="ora" %> <% String[] test = new String[4]; test[0] = "first"; test[1] = "second"; test[2] = "third"; test[3] = "fourth"; pageContext.setAttribute("test", test); %> page 226
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

JavaSercer Pages The action results in code for (Private jvm hosting)

JavaSercer Pages The action results in code for locating or creating the CatalogBean, and declaring and assigning a Java variable named catalog. But since we’re talking about custom actions here, let’s focus on the code generated for the action. First, a tag handler instance is created and initialized with the standard properties (pageContext and parent) plus all properties corresponding to the action attributes. Next, the doStartTag( ) and doEndTag( ) methods are called. Then comes the code that makes the object created by the action available as a scripting variable. Note how a variable with the name specified by the id attribute (prod) is declared, using the type specified by the className attribute. Also note that the variable is declared at the top level of the method. This means that it’s available to scripting elements anywhere on the page after the action element. The variable is then assigned the value of the object with same name located in one of the standard JSP scopes, using the findAttribute( ) method. This method searches through the scopes, in the order page, request, session, and application, until it finds the specified object. With the object available in the JSP page scope, the code generated for the action can find it. Since it’s also assigned to a Java variable, the JSP expression works correctly as well. At least two things are required for a tag handler to create a new object and make it accessible for other actions and JSP scripting code: 1. The JSP container must know the name and the Java type for the object, so it can generate the code for the variable declaration. 2. The object must be placed in one of the JSP scopes, so it can be found by findAttribute( ) and assigned to the variable. The first requirement is fulfilled by a class called TagExtraInfo . When you develop a tag handler for an action that introduces an object, you must also create a subclass of the TagExtraInfo class. The JSP container consults an instance of this class when it generates the code. Example 16.6 shows the class associated with the action. Example 16.6. UsePropertyTagExtraInfo Class package com.ora.jsp.tags.generic; import javax.servlet.jsp.tagext.*; public class UsePropertyTagExtraInfo extends TagExtraInfo { public VariableInfo[] getVariableInfo(TagData data) { return new VariableInfo[] { new VariableInfo(data.getAttributeString(”id”), data.getAttributeString(”className”), true, VariableInfo.AT_END) }; } } The method used by the JSP container during code generation is called getVariableInfo( ). It returns an array of VariableInfo objects, one per variable introduced by the tag handler. The VariableInfo class is a simple bean with four properties, all of them initialized to the values passed as arguments to the constructor: varName, className, declare, and scope. The meaning of the first two is not hard to guess: the name of the variable and the name of its class. The declare property is a boolean, in which true means that a new variable is created by the action. In other words, a declaration of the variable must be added to the generated servlet. A value of false means that the variable has already been created by another action or by another occurrence of the same action, so the generated code already contains the declaration. This is all the information the JSP container needs to generate the code for the variable declaration; the first requirement is satisfied. The scope property has nothing to do with the JSP scopes we have seen so far (page, request, session, and application). Instead, it defines where the new variable is available to JSP scripting elements. A value of AT_BEGIN means that it is available from the action’s start tag and stays available after the action’s end tag. AT_END means it is not available until after the action’s end tag. A variable with scope NESTED is available only in the action’s body, between the start and the end tags. The scope therefore controls where the variable declaration and value assignment code is generated, and the tag handler class must make sure the variable is available in one of the JSP scopes at the appropriate time. page 225
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services