Ftp Web Hosting - PHP, MySQL, Java, Jsp, Servlet, Tomcat, Ssh Blog

jar cvf storefront.war . Because you changed to the root directory, the storefront directory will not be included in the WAR file. This is fine, because you may want to call the root directory something else when it’s installed. When you install the web application, if you plan to explode the WAR file, all you need to do is create a directory and un-jar the files, like this: C:tomcatwebapps>mkdir storefrontC:tomcatwebapps>cp storefront.war storefrontC:tomcatwebapps>cd storefrontC:tomcatwebappsstorefront>jar xf storefront.war The location where the WAR file gets expanded is container-dependent. If you plan to distribute the WAR file without exploding it, all you have to do is place it in the appropriate place for the container. You don’t have to recreate the storefront directory, although you might want to delete the existing directory when deploying a newer version. Some containers are not good at removing old files before deploying an updated WAR file. Although Section 9.8 of the 2.3 Servlet specification is a little ambiguous about replacing a web application without restarting the server, most containers allow you to drop in a new WAR file or replace certain files without restarting. There’s always a danger with leaving this feature on in a production environment; however, while developing the application or debugging a problem, you’ll quickly learn to appreciate this functionality. In containers that do support this feature, there’s usually a way to disable it when you deploy a web application into production. 16.4 Building Your Struts Applications with Ant Although there are several different mechanisms to compile and deploy your Struts application, by far the most popular and most flexible is the Ant build tool.[3] This section discusses how to use Ant to perform the necessary tasks for compiling and packaging your application. [3] Ant is an acronym for “Another Neat Tool.” 16.4.1 What Is Ant? Ant is a platform-independent build tool that can be configured to compile your Java source code files, build your deployment JAR and WAR files, unit-test your code, and create your project’s JavaDoc documentation. It also has many other uses and can be expanded to perform new tasks of your own creation. Ant is similar to the Unix make utility (also known as gmake in Linux and nmake in DOS/Windows). make utilities have been used for generations to manage projects for languages such as C and C++, but these utilities are platform-dependent because the rules they use are typically shell commands executed by the host operating system. Unlike make, Ant’s rules (or tasks, in Ant terminology) are Java classes and can be run on any platform with a supported JVM.
Searching for affordable and reliable webhost to host and run your web applications? Go to our java web server services and you will be pleased.

much easier. The next section describes the steps that you must perform to package your web application as a WAR file. 16.3.1 Creating the WAR File The first step in packaging your application as a WAR file is to create a root directory. In most cases, this directory will have the same name as your web application. For our example, we will create a directory called storefront. After deciding how your JSP and HTML pages will be placed within your application, place them underneath the root directory in their appropriate subdirectories. For the Storefront example, our directory structure so far would look like Figure 16-2. Figure 16-2. The Storefront application directory structure Figure 16-2 shows 11 subdirectories, 8 of which contain JSP pages for the application. The images directory contains images that are used globally throughout the application, the stylesheets directory stores cascading stylesheets for the application, and the include directory contains files that are included using either a static or dynamic include. The next step in setting up the WAR file is to ensure that you have a WEB-INF directory underneath your root web application directory. The WEB-INF directory contains all of the resources that are used internally by the application. For example, the TLD files for your custom tag libraries reside in this directory, as does the web deployment descriptor. This is also where the Struts configuration files belong. No resource within this directory can be made public outside of the application. Underneath the WEB-INF directory, create two subdirectories: one called classes and the other called lib. The classes directory should contain all of your utility and servlet classes. The lib directory should contain the JAR files that the application depends on. Once all of the resources for the web application are accounted for and are inside the appropriate directories, you need to use Java’s archiving tool jar to package the directories and files. From a command line, change to the root directory of your web application and use the jar utility. You need to give the file a .war extension, like this:
You want to have a cheap webhost for your apache application, then check apache web hosting services.

resin/bin/httpd -conf conf/resin.conf -compile Here, the URL is a JSP resource within a web application installed in Resin. You can also use the command-line version, like this: resin/bin/httpd -e With this approach, you can compile only a single JSP page at a time, although you could easily create a script that went through your entire web application. An easier way to configure this is to use Ant, as discussed later in this chapter. 16.2.3.3 Precompiling JSP pages with WebLogic With WebLogic 6.0, you have to include a context-param element in the deployment descriptor for each web application. This will instruct WebLogic to compile every JSP page that is part of the web application when the application server starts up. The following context-param element must be added to the web.xml file:
weblogic.jsp.precompile true WebLogic 6.0 will not deploy the web application if any one of the JSP pages fails to compile. Once it detects an error compiling a page, all compilation stops and the web application will not be deployed. You have to fix whatever is causing the problem and then restart WebLogic to start the process all over again. 16.2.4 Packaging EJB Resources with Struts If you’re communicating with EJBs in the middle tier, it might be necessary to package some of the EJB resources along with your web application package. Because the web tier acts as a client to the EJB server, certain resources are required to connect and communicate with the beans. The beans’ home and remote interfaces, for example, need to be packaged either in the classes directory or as a JAR file in the lib directory of the web application. Also, some of the JNDI classes need to be included so that clients can acquire home and remote objects. The actual client-side EJB stub classes are not required, however. This wasn’t always the case, but the latest specification now describes a mechanism that allows these to be automatically downloaded when a request is made using an EJB remote interface. In many cases, it’s enough to put the EJB container JAR file in the WEB-INF/lib directory. For example, if you are using WebLogic 6.0 or higher, you can put the weblogic.jar file in the web tier, as it contains all of the necessary client-side resources. 16.3 Packaging the Application as a WAR File Packaging your web applications using the WAR format is very convenient. The structure is precise, and because it is specified so carefully, porting your applications across the various web containers is
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.

is selected to process the request. If this is the first request for the JSP page or if the timestamp for the JSP page is newer than the existing servlet class, the page will normally be compiled.[2] [2] Most containers have an option that disables detection so that pages that have changed will not be recompiled. This option is usually selected in a production environment because incremental changes should not be introduced in production. Also, allowing this to occur would amount to a security risk. The JSP container uses a two-step process. First, the JSP page is translated from the JSP code into a Java source file. Each container may have its own implementation to translate the JSP page. The second step takes the Java source file and compiles it into a servlet class file using whichever Java compiler is installed for the JSP container. Although just-in-time compilation is a nice feature while you are developing or debugging an application, you may not want to make the JSP source available in a deployment package. This is an issue of both security and licensing although the JSP pages should contain only presentation logic, that’s still intellectual property. If this is the case, you can precompile the JSP pages and not provide the JSP source code to customers. You’ll have to distribute only the compiled bytecode, making it harder for the source code to be seen. Once the JSP pages are compiled into Java class files, you can even run them through an obfuscator to make it harder for them to be viewed through decompilation tools. Precompiling the JSP pages gives you more options for dealing with issues like these. As always, though, there are some downsides to precompiling JSP pages. For one thing, you lose the ability to update or fix a problem quickly. Instead of just placing a new JSP file onto the server and letting the JSP container compile it when it’s accessed, you must do the recompilation by hand and deploy the servlet class. Another downside is that when some containers detect a problem with a single JSP, they will stop processing the rest of the application’s JSP pages. When this occurs, you must make sure that every JSP page compiles successfully before the container will deploy the web application. Developers may actually consider this a benefit rather than a disadvantage, but it can be problematic in production environments if you are trying to make a quick fix to a bug. Unfortunately, there’s no standard way to precompile the JSP pages. Each container has a different way of doing it. This section briefly discusses how to precompile pages using three of the available containers on the market: Tomcat 4.0, Resin 2.0, and WebLogic 7.0. 16.2.3.1 Precompiling JSP pages with Tomcat The JSP implementation in Tomcat, which is called Jasper, provides a reference implementation for the latest specification. It’s packaged along with Catalina, the reference implementation of the latest Servlet specification, inside of Tomcat. The JSP-to-Java compiler is available as a separate program that can be executed from the command line. Its job is to convert a JSP page into a Java source file. From there, a standard Java compiler can convert the source code into bytecode. The program is called jspc.bat (or jspc.sh, depending on which platform you’re using) and is located in the bin directory of the Tomcat installation directory. Many options can be set to configure everything from the output directory to the package name of the Java source. There’s even an option that will cause the compiler to create XML that can be added to the web.xml file for each JSP page that gets precompiled. You can do one page at a time or specify an entire web application. 16.2.3.2 Precompiling JSP pages with Resin To precompile JSP pages using Resin, you can use the httpd.exe command from the Resin bin directory, like this:
You need excellent and relaible webhost company to host your web applications? Then pay a visit to Inexpensive Web Hosting services.

/order/* GET POST Figure 16-1 shows what happens when a client attempts to access a JSP page directly within the order directory. Figure 16-1. A 500 error will occur when accessing a protected JSP When the security-constraint element is added to the web.xml file for the Storefront application, it says that no user without the proper authentication can access the order JSP pages. However, in this example, the role-name element was intentionally left blank and therefore will never match an actual role. You could also have specified that only users with an admin role could access the pages, and then never given that role to an actual user. The container would still be able to access these pages through forwards and includes. You must be careful what you put in the url-pattern element, however. If you have resources such as images in subdirectories, they will not be available when the browser attempts to download them. Using the /order/* pattern means that nothing under the order directory can be requested directly by the client; this includes images in subdirectories, and the browser will have difficulty receiving the images for a returned HTTP response message. 16.2.3 Precompiling JavaServer Pages If you are using JavaServer Pages as your Struts presentation technology, you are probably very familiar with the compilation process that the JSP container performs on the application’s behalf. When the web container receives a request for a resource with an extension of .jsp, the JSP container
From our experience, we are can tell you that you can find a reliable and cheap webhost service at Java Web Hosting services.

computer industry. The manner in which the Internet Domain Name System (DNS) works is a type of namespace. Within the oreilly.com domain, for instance, other IP addresses are linked together in a hierarchal fashion. All of this referencing helps prevent IP addresses from colliding. Another example, which is more closely related to software development, is the namespace that is used within JNDI. But by far the most familiar use of a namespace in Java development is for creating classes and interfaces that reside in a package. As you know, Java applications are organized as sets of packages. Even when you don’t specify a package explicitly, it’s still part of a package.[1] The purpose of the package is to prevent name collisions and to help identify entities (in this case, Java classes) easily. When extending the Struts framework with your own classes and interfaces, you need to decide how best to package these components for your application. Not every application will contain the same classes and interfaces. [1] Any Java class that doesn’t have a package statement declared in the source file is considered to be part of the default package. 16.2.2 JSP File Placement For many developers, where you place the JSP pages may seem like an easy question to answer. Although you may have to decide which directory a particular JSP page belongs in, that’s normally all that has to be decided. However, there are situations where more control may need to be placed on who and what has access to the JSP pages. One suggestion is to put the JSPs in a directory underneath the WEB-INF directory. The purpose of this approach is threefold: It forces all requests to go through the ActionServletclass. It prevents users from bookmarking a page. It protects the WEB-INF directory and helps protect JSP pages from being called directly. This alternate approach has gained some popularity, although not all of the containers currently support it. Although the 2.3 Servlet specification seems to indicate that something to this effect may be possible, different vendors may not agree in their interpretation of the specification for example, in the past, the WebLogic developers have stated that they interpret section SRV.6.5 of the Servlet specification differently. WebLogic will return a 404 or 500 error code when you attempt to access a JSP page underneath the WEB-INF directory (although there has been some indication that WebLogic will make this option available in future versions of their container). Even though some containers do support the above approach, you may not need to put the JSP pages underneath the WEB-INF directory. If you call Struts actions only from your web application and don’t link to JSP pages directly (which is a requirement for Struts 1.1), this approach will not have much benefit for your applications. There are portable alternatives for example, you can use the security-constraintelement in the web.xml file. Just create the required directories for the JSP pages that you want to protect. In the Storefront example, suppose that users shouldn’t be able to access the JSP pages underneath the order directory. A security-constraint element like this could then be added: SecureOrderJSP Protect the Order JSP Pages
We recommend you use shared web hosting services, because many users agree that it is cheap, reliable and customer-satisfying webhost.

The second approach to deploying a Struts application puts more work on the developer. It still involves packaging your application as a WAR file, but includes manually unpackaging the WAR file into a directory of the container. The exact location of the directory is container-dependent. In Tomcat and Resin, for example, the default web applications directory is webapps. In the WebLogic application server, you have to unpack the WAR file underneath the applications directory. (All three of these containers also allow you to specify alternate installation directories.) When expanding the WAR file, you need to create a directory into which to unpack the files. The name of the directory is usually the name of the web application. So for example, if the web application was called Storefront and you wanted to install it into Tomcat, you could create a directory called storefront under the webapps directory and unpack the WAR file there. The WAR file should not contain the storefront directory as part of its structure. This deployment approach is referred to as an exploded directory format, because the WAR file is exploded back into its original structure within the container. The benefit of this approach over deploying the WAR file itself is that when there are changes, only the changed files need to be redeployed into the container. This is much easier when you’re still developing or debugging the application, but you may not want to leave it like this for production. When deploying a web application into production, it’s a better approach to leave the WAR file packed because there’s less chance of one or more files getting contaminated. Leaving it as a single WAR file forces you to replace the entire WAR file if changes need to be made, so there’s no chance of a version of a file getting out of sync with the rest of the application. 16.2 Deciding How to Package Your Application Because Struts applications are web applications, most of the questions about how to package them are answered in the Servlet and JavaServer Pages specifications. A web application must follow a very strict set of completely specified guidelines and conventions that make the web application portable across other compatible web containers. Fortunately, packaging your Struts application in the WAR format solves much of the hassle regarding packaging. However, there are many questions that you will have to resolve. For example, you’ll have to decide where all the JSP pages go and whether you should store your Struts Actionand ActionForm classes together or in separate action and form packages. Although there are definitely best practices, there are no hard-and-fast rules for resolving issues such as these. Some of the solutions will depend on your organization’s requirements and policies. 16.2.1 Namespace Management A namespace is simply a set of names that may or may not be associated. A namespace is normally used to prevent conflicts or collisions between similar entities and to allow clients to reference these entities by some logical name. In software development, a namespace is a way to package classes, interfaces, and other types of information into a hierarchical structure. There are many examples of namespaces throughout the
You need excellent and relaible webhost company to host your web applications? Then pay a visit to Inexpensive Web Hosting services.

16.1 To Package or Not to Package Applications need to be deployed to be useful. There’s really no point in developing an application that never gets deployed, although this occurs more often than you might think. The need for deployment is obvious, but what about packaging? Does every Struts application have to be packaged before it gets deployed? The short answer is yes. In this chapter, though, we’ll examine the long answer. Before we get into the details of packaging and deploying Struts applications, let’s define exactly what these two concepts mean in the context of web applications that are built using the Struts framework. Although the two concepts are closely related, they are not the same thing. 16.1.1 What Is Packaging? Packaging a Struts application involves gathering all the files and resources that are part of the application and bundling them together in a logical structure. Many different types of resources are usually included in a Struts application, and all of these need to be bundled with the application. Some of the more common types of resources that can be packaged with a Struts application are: HTML and/or XML files Images, audio, and video files Stylesheets JavaServer Pages Properties files Java utility classes Configuration files Actionand ActionFormclasses Third-party JARs During the design stage, time and effort should be spent on deciding how you are going to structure the application. Not every detail needs to be figured out and resolved before construction begins, but you should understand the target environment’s requirements and how these requirements will affect your packaging and deployment strategy. Ideally, you should decide on the principal package and directory structure for the application before construction gets underway. This will help to alleviate the normal miscommunication between developers and reduce the number of redundant resource files. 16.1.2 What Is Deployment? As the previous section mentioned, packaging and deployment are closely related, but involve different tasks. While packaging determines where the resource files will reside in the package structure and how those resources will be bundled, deployment deals with how the bundled application will be installed and configured inside a target web container. There are two approaches that you can use when deploying a web application into a container. The first approach is to deploy the web application in a web archive (WAR) file. Most web containers install a WAR file and make it available for users, often without even requiring a restart of the container. This approach is convenient because once the WAR file is properly built, the rest of the work is handled by the container. One of the downsides of this approach, however, is that if a change is made to any file or resource within the web application, a new WAR file must be created and redeployed into the container. The details of how to deploy your Struts application as a WAR file are discussed later in the chapter.
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.

15.8 Java 1.4 Logging API Even if you aren’t using Java 1.4, you’ve probably heard of it and the new features that it includes. One of the new features is the logging API now included with the core library. You may be wondering what the difference is between log4j and this new library, and whether you should be using that instead. There are several similarities between log4j and the 1.4 logging implementation. However, there are also a few major differences. Let’s look at the similarities first. Both log4j and the Java 1.4 logging implementation use a hierarchical namespace for the loggers. This allows you to configure loggers that basically align along your application’s package structure, although this is not the only way to structure the loggers.They also both support multiple levels or priorities. The 1.4 logging implementation actually contains a few more levels than log4j, though you might not ever use the extra ones because they are so fine-grained. The differences between the two implementations are generally not big enough to cause you to miss out on important functionality. However, it does appear that log4j offers more functionality for those that really need it. More importantly, log4j works with Java Versions 1.1 and above, while the 1.4 logging implementation works only with Version 1.4. There was talk about making it backward compatible, but that hasn’t happened yet and may never happen. Also, there are currently many more appender types available for log4j than for Java 1.4, but this is not a major issue because the most important ones are present in Java 1.4. Regardless of whether you use log4j or Java 1.4 as your logging implementation, you should leverage the Commons Logging API to protect your application from inevitable change. Coupling your application to any single third-party implementation is not recommended, in terms of logging or anything else. Chapter 16. Packaging Your Struts Application Contrary to what many developers might assume, designing and building an application is only half the battle. When the application is finished, it must then be packaged and deployed into the target environment. Many applications are built and packaged with the intent of being installed into a customer’s production environment. For others, the target deployment environment is in-house. For web applications, fortunately, the work that has to be accomplished in either case is very similar. Internal deployments may be less formal and less nerve-wracking. However, they still should be taken seriously and conducted in an efficient and professional manner. Whether the customer is a “real” customer or another department within the organization, an unprofessional deployment can leave a bad impression. Formalizing the packaging and deployment process allows developers to focus on building a quality application and spend less time worrying whether the application will install and run correctly when it’s finished. This chapter discusses the best practices for packaging and deploying a Struts application, including coverage of what it takes to automate the build process for your environment. Special attention is given to Ant, the Java-based build tool available from Jakarta.
Visit our web design programs services for an affordable and reliable webhost to suit all your needs.

Probably the most significant impact on logging is what information you attempt to log and how you format that information. log4j uses a subclass of org.apache.log4j.Layout to determine how the message should be formatted in the output destination. Using the SimpleLayout class is the fastest, as it logs only the log level and the message. On the other hand, the PatternLayoutclass allows for a great amount of flexibility in the format of the message; you can log all sorts of information, including the class creating the message, the line number, and even the Java thread that is generating the message. However, all of this additional information comes at a severe price in terms of performance. The log4j documentation contains several warning messages in the JavaDocs for the PatternLayout class stating that performance may suffer greatly if certain information is written out with the log message. You must be very particular about what information you need in the log message. You should be able to get by with the class, the level, and the message. The other information is nice to have, but in most cases it’s superfluous. Creating the message that goes into the log statement can also impact the time and performance. Creating a message using values such as: logger.debug(”Session id is: ” + sessId + ” for user ” + user.getFullName( ) ); can add significant time to logging. This isn’t related to log4j, but rather to the cost associated with making Java method calls and concatenating the strings together before the actual log statement can be generated. Finally, as mentioned earlier, loggers can be connected together in a parent/child relationship. Because the logging threshold can be assigned at any level, the log4j environment may have to search up the hierarchy to determine whether the log message should be written. If this hierarchy is very deep, this traversal can add significant time to the log statement creation. Generally, in the development stages of your application, logging costs are less important. The performance of logging shouldn’t matter that much while you’re still developing and debugging the application; in fact, this is typically where you want as much logging as the application can generate. When it’s time to go to QA or production, turn down the logging levels. With other languages, the logging code might not ever make it into the compiled binaries. Preprocessors might remove the logging code to keep the binary size smaller and prevent the log messages from showing up. However, this is not necessary using log4j you have the flexibility of controlling how much logging is done just by changing the configuration file. (Of course, the log statements are still present in the binary code once it’s compiled.) 15.7 Third-Party log4j Extensions Several helpful third-party tools and utilities are available for log4j. Most of them are free and/or open source. For example, there are several Swing-based GUI applications that allow you to view and filter log messages dynamically, which is ideal for administrators in a production environment. There are also several other types of appenders that other developers have created that might be helpful to you. You can find these third-party extensions in the log4j download area at http://jakarta.apache.org/log4j/docs/download.html. It’s definitely worth the time to take a look and see what’s there. The list of available extensions is constantly growing.
You want to have a cheap webhost for your apache application, then check apache web hosting services.