Java Global FAQ

Taj Mahal or Tejo Mahalya

noreply@blogger.com (Anonymous) — Wed, 21 Jul 2010 19:24:00 +0000

Check out this SlideShare Presentation:

Taj Mahal or Tejo Mahalya

View more presentations from Aalap Tripathy.

mignonesia: My Fried banana in peanut caramel sauce recipe.

noreply@blogger.com (Anonymous) — Fri, 19 Jun 2009 12:40:00 +0000

mignonesia: My Fried banana in peanut caramel sauce recipe.

AP - SSC RESULTS 2009

noreply@blogger.com (Anonymous) — Wed, 27 May 2009 06:35:00 +0000

Andhra pradesh SSC results2009

|AP SSC 2009 Results Available at 11:00 AM today

SC results (10th class) of the Andhra pradesh state will be declared on the 27th of May 2009. It was scheduled to be released much earlier than 27th but due to the new Government formation it is a bit delayed, because THE EDUCATION MINISTER WILL BE BUSY ON 25TH TAKING HIS OATH.......AS THE EDUCATION MINISTER.....SO...THE RESULTS ARE POST-PONED TO 27TH.....!!! The new education Minister will release the results on 27th.

To check your SSC Result 2009 online, visit for SSC Results (General) and
SSC Results (Vocational)

Schools9
results.manabadi.co.in

check hurry up..... keep enjoy.....
If you can't change your fate, change your attitude

Foundations of Ajax

noreply@blogger.com (Anonymous) — Sun, 08 Mar 2009 03:56:00 +0000

Foundations of Ajax

Author: Ryan AslesonNathaniel T. Schutta

Overview of Book:

Foundations of Ajax is written to give you, the developer, all the tools you need to add Ajaxtechniques to your existing or future applications. Our motto while writing this book was,“Everything you need to know; nothing you don’t.” We assume that as a reader of this bookyou are already an experienced Web application developer. Because of this, we focus on thetopics that are most likely new to you: Ajax and its associated tools and techniques.We don’tspend much time talking about server-side languages because we assume you will developserver-side functionality using the toolset of your choice and that you don’t need our helpxixdoing it. We don’t spend time talking about how to build enterprise-scale applications that justhappen to use Ajax. Instead, we focus solely on Ajax and its related tools and techniques.

The examples in this book are deliberately small and tightly focused. They demonstrateone or two important Ajax concepts as succinctly as possible. We assume that as an experiencedWeb developer you can extrapolate the demonstrated topic into your own environment;thus, we avoid cluttering the examples with information that is of little use to you.

Chapter 1 discusses the themes of Web application development from the past, present,and future. It’s easier to see where development techniques are going once you know wherethey have been.

Chapter 2 introduces the XMLHttpRequest object. This is the Ajax concept with which you’relikely the least familiar, so we dedicate an entire chapter to explaining the XMLHttpRequestobject’s properties and methods. If you’re like us, you may not have even been aware of theXMLHttpRequest object until recently, despite that it has been available in Internet Explorer forseveral years. Therefore, we’ll take the time to properly discuss this object and what it can do.

Chapter 3 starts to get into the meat of Ajax. This chapter discusses the various ways inwhich the XMLHttpRequest object can communicate with the server. We discuss using XML,plain text, and even JavaScript Object Notation (JSON) as the transport medium and discussthe various ways in which you use them in conjunction with the XMLHttpRequest object. Bythe end of this chapter, you’ll be comfortable using the XMLHttpRequest object to communicatewith the server without forcing the user to suffer through a complete page refresh.Too often we, as developers, spend time learning how to use a new technology or techniquewithout learning about how to apply it.

Chapter 4 solves this problem by demonstrating a numberof scenarios in which you can use Ajax techniques. As promised, each example is small andfocused, enabling you to better understand the topic without having to wade through copiousamounts of unnecessary information.Chapters 5, 6, and 7 are worth their weight in gold to the new Ajax developer. We don’twant you to start enhancing your applications with Ajax without being equipped with theproper tools and techniques to do so. Chapter 5 introduces several tools and techniques thatyou can use to ease the development of Web applications. The tools and techniques describedin

Chapter 5 will help you produce code that is higher in quality, adheres to industry standards,and is easier to maintain in the future.Test-driven development (TDD) is changing the way we develop applications. By writingunit tests before you write any code, you can ensure that the code you write is workingas expected, greatly increasing the quality of your code. A suite of unit tests also makesfuture changes easier by ensuring that all code still works as expected after changes aremade. There’s no reason to exclude Ajax from TDD, and since the benefits of TDD cannotbe overstated, we dedicate an entire chapter to it. Since Ajax is primarily a browser-basedtechnology,

Chapter 6 demonstrates how to apply TDD to your JavaScript code.Speaking of JavaScript, if you’re going to use Ajax, you’re going to have to write at leastsome JavaScript. Many developers have shied away from JavaScript, claiming it lacks importantproductivity tools such as debuggers to be truly useful. That is no longer true.

Chapter 7 discusses tools and techniques you can use to track down problems when they arise and solvethem as quickly and easily as possible. No longer must you avoid JavaScript with the fear thatyou won’t be able to diagnose problems when they arise.

Ajax is a rapidly evolving technology that has grown exponentially during the time wewere writing this book.

Chapter 8 ties everything together by discussing emerging Ajax developmentpatterns, frameworks, and online resources. Also, the complete example in Chapter 8xx n INTRODUCTION shows some advanced Ajax techniques and demonstrates how easy Ajax development can bewhen using a prebuilt Ajax framework. Using a framework shields you from some of the moremundane tasks of Ajax development, allowing you to focus more on business logic than on thenuances of Ajax.

To cap it all off, Appendix A outlines some quirks and inconsistencies that exist within theW3C DOM and JavaScript implementations that exist across browsers, and ways to overcomethese issues. Appendix B summarizes some of the most popular Ajax frameworks and librariesthat are available to simplify the adoption of Ajax techniques. The number of frameworks issure to grow as Ajax becomes more popluar, so stay on the lookout for emerging frameworksand other development tools.

download Link:Click Here

Enterprise Java Beans

noreply@blogger.com (Anonymous) — Sat, 07 Mar 2009 08:35:00 +0000

Enterprise Java Beans?

Author: Gerard C. Weatherby

Contents:

What are Enterprise Java Beans?
Glossary
Why use them? (Or why not.)
Enterprise Java Bean server features
Enterprise Java Bean roles
Enterprise Java Bean programming restrictions
How does it work (briefly)
Types of beans
An example
Deployment descriptor
Archive Files
J2EE Server

Glossary

• J2EE - Java 2 Enterprise Edition -- EJB’s + JSP’s etc.
• JMS - Java Messaging Service
• JNDI - Java Naming and Directory Interface
• JSP - Java Server page. Here this could mean JSPs, servlets,
and/or beans installed on the web server
• API - Application Programmer’s Interface
• JVM - Java Virtual Machine
• SQL - Structured Query Language
• AWT - abstract window toolkit
• I/O - input output
• J2EE RI - J2EE reference implementation

download links:
http://www.ziddu.com/download/3121015/EJB.pdf.html

Struts2.0 Framework Guide

noreply@blogger.com (Anonymous) — Fri, 27 Feb 2009 14:53:00 +0000

Struts2.0 Framework Guide

Struts and webwork has joined together to develop the Struts 2 Framework. Struts 2 Framework is very extensible and elegant for the development of enterprise web application of any size. In this section we are going to explain you the architecture of Struts 2 Framework.

Contents:

Struts 2 Architecture
Why Struts2
Struts 1.x Vs Struts 2.x
Struts HelloWorld Example
Developing JSP, Java and Configuration for Hello World Application
Struts Configuration file - struts.xml
Struts 2 Login Application
Struts 2 Validation Example Running and Testing
Struts 2 Login application
Client Side validation in Struts 2 application
Validations using Struts 2 Annotations Login/Logout With Session
Struts 2 MySQL
Rich Editor Example
Validate TextArea Introduction to Struts 2 Tags Append Tag (Control Tags) Example
Java Captcha in Struts 2 Application

For More Information:

http://www.ziddu.com/download/3104373/struts2tutorial.zip.html

http://www.ziddu.com/download/3104340/Struts2Framework.doc.html

http://www.ziddu.com/download/3104369/struts2.doc.html

http://www.ziddu.com/download/3104370/WE9-struts-2.0.ppt.html

http://www.struts.apache.org

Keeps rocking in Struts2

Oracle Reports 10g

noreply@blogger.com (Anonymous) — Thu, 26 Feb 2009 12:07:00 +0000

Oracle® ReportsBuilding Reports10g Release 2 (10.1.2)

Our goal is to make Oracle products, services, and supporting documentationaccessible, with good usability, to the disabled community. To that end, ourdocumentation includes features that make information available to users of assistivetechnology. This documentation is available in HTML format, and contains markup tofacilitate access by the disabled community. Accessibility standards will continue toevolve over time, and Oracle is actively engaged with other market-leadingtechnology vendors to address technical obstacles so that our documentation can beaccessible to all of our customers. For more information, visit the Oracle AccessibilityProgram Web site athttp://www.oracle.com/accessibility/

download:
http://www.ziddu.com/download/3646524/OracleReports.pdf.html

Struts 2.0 Framework Guide

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 07:14:00 +0000

Struts 2.0 Framework Guide

this tutorial contains below topics:

Struts 2 Architecture
Why Struts 2
Struts 1.x Vs Struts 2.
Download and Installing Struts 2
Struts 2 Hello World Application Example,
Developing JSP, Java and Configuration for Hello World Application
Struts 2 Login Application
Struts 2 Validation Example
Running and Testing Struts 2 Login application
Client Side validation in Struts 2 application
Validations using Struts 2 Annotations
Introduction to Struts 2 Tags
Struts 2 Examples
Struts 2 Resources Examples
Struts 2 IDE
Java Captcha in Struts 2 Application

download link:
http://www.ziddu.com/download/3104340/Struts2Framework.doc.html

source code download:
http://www.ziddu.com/download/3104373/struts2tutorial.zip.html

Java core topics in deep

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 07:02:00 +0000

Java Core topics in Deep knowledge:

topics include:
interface vs abstract class
serialization
How To Use Generics
Comparator/Comparable
Generics and Serialised Objects
Recipes for Quoting Awkward Characters in Java Regexes in Java source code String Literals
Examples of Collections
Collection Classes and Interfaces

download link:click here

Generics in the Java Programming Language

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 06:52:00 +0000

Generics in the Java Programming Language

Author:
Gilad Bracha

Book Descriptions:

JDK 1.5 introduces several extensions to the Java programming language. One of these
is the introduction of generics.
This tutorial is aimed at introducing you to generics. You may be familiar with
similar constructs from other languages, most notably C++ templates. If so, you’ll soon
see that there are both similarities and important differences. If you are not familiar
with look-a-alike constructs from elsewhere, all the better; you can start afresh, without
unlearning any misconceptions.

topics include:
1 Introduction
2 Defining Simple Generics
3 Generics and Subtyping
4 Wildcards
4.1 Bounded Wildcards . . . . . .... . . . . . . . . .
5 Generic Methods
6 Interoperating with Legacy Code
6.1 Using Legacy Code in Generic Code . . . . . .
6.2 Erasure and Translation . . . . . . . .. . . . . .
6.3 Using Generic Code in Legacy Code . . . . . .
7 The Fine Print
7.1 A Generic Class is Shared by all its Invocations
7.2 Casts and InstanceOf . . . .. .. .. . . . . . . . .
7.3 Arrays . . . . . . .... . . . . .. ... . . . . . . . . .
8 Class Literals as Run-time Type Tokens
9 More Fun with Wildcards
9.1 Wildcard Capture . . . . . . . ..... . . . . . . . .
10 Converting Legacy Code to Use Generics

download link:
http://www.ziddu.com/download/3121098/generics-tutorial.pdf.html

Sun Certified programmer and Developer Java2(j2se1.4) Study_Guide

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 06:45:00 +0000

Sun Certified programmer and Developer Java2 Study_Guide

This Zip contains the chapters about Java 1.4 cerfication Exam guide:

Chapter 1: Language Fundamentals
Chapter 2: Declarations and Access Control
Chapter 3: Operators and Assignments
Chapter 4: Flow Control, Exceptions, and Assertions
Chapter 5: Object Orientation, Overloading and Overriding, Constructors, and Return Types
Chapter 6: Java.lang—The Math Class, Strings, and Wrappers
Chapter 7: Objects and Collections
Chapter 8: Inner Classes
Chapter 9: Threads
Chapter 10: Introduction to the SCJD
Chapter 11: Coding Standards
Chapter 12: Clarity and Maintainability
Chapter 13: Designing the Graphical User Interface
Chapter 14: Networking Issues
Chapter 15: Database Issues
Chapter 16: Exam Documentation
Chapter 17: Final Submission and Essay

download link:
http://www.ziddu.com/download/3121101/rtified_programmer_and_Developer_Java2_Study_Guide.zip.html

Java 2, JDK 5 Edition

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 06:17:00 +0000

Beginning Java™ 2, JDK™ 5 Edition

Author:
Ivor Horton’s

Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com
Copyright © 2005 by Ivor Horton
Published by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 0-7645-6874-4
Manufactured in the United States of America

Book Description:
Using this book you can learn java programming using latest and greatest java platform - Java 2 Standard Edition version 5.0 (J2SE 5.0)

Topics include
Chapter 1: Introducing Java
Chapter 2: Programs, Data, Variables, and Calculation
Chapter 3: Loops and Logic
Chapter 4: Arrays and Strings
Chapter 5: Defining Classes
Chapter 6: Extending Classes and Inheritance
Chapter 7: Exceptions
Chapter 8: Understanding Streams
Chapter 9: Accessing Files and Directories
Chapter 10: Writing Files
Chapter 11: Reading Files
Chapter 12: Serializing Objects
Chapter 13: Generic Class Types
Chapter 14: The Collections Framework
Chapter 15: A Collection of Useful Classes
Chapter 16: Threads
Chapter 17: Creating Windows
Chapter 18: Handling Events
Chapter 19: Drawing in a Window
Chapter 20: Extending the GUI
Chapter 21: Filing and Printing Documents

download link:
http://www.ziddu.com/download/3121096/WroxBeginningJava52005.pdf.html

Core Java 2 Volume II - Seventh Edition - Ebook:

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 06:01:00 +0000

Core Java™ 2 Volume II - Advanced Features, Seventh Edition

Author: Cay S. Horstmann, Gary Cornell
Publisher: Prentice Hall PTR
Pub Date: November 22, 2004
ISBN: 0-13-111826-9
Pages: 1024

Ebook Description:
Completely revised and up-to-date coverage of

Multithreadingincluding the java.util.concurrent library, locks, condition objects, futures, thread pools, thread-safe collections, threads and Swing
Collection classescollections framework, concrete collections, and generic utility methods
Annotations and metadatausing annotations to automate programming tasks, JDK™ 5.0 standard annotations, the apt tool for source-level annotation processing, and bytecode engineering
Advanced Swing and AWTlists, trees, tables, and other advanced components; image processing and printing
JavaBeans™including property editors, customizers, and long-term persistence
XMLDOM and SAX parsers, XPath, and XSL transformations

The seventh edition of Core Java™ 2, Volume II, covers advanced user-interface programming and the enterprise features of the Java 2 Platform, Standard Edition (J2SE™). Like Volume I (which covers the most important language and library features), this book has been completely updated and revised for J2SE 5.0. All of the sample programs have been updated and carefully crafted to illustrate practical solutions to the type of real-world problems professional developers encounter.

download link:

http://www.ziddu.com/download/3121095/CoreJava2VolumeI7thEdition.pdf.html

Core java Volume I, 7th Edition - Ebook

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 05:49:00 +0000

Core Java™ 2 Volume I - Fundamentals, Seventh Edition

Ebook Title:
Core Java™ 2 Volume I - Fundamentals, Seventh Edition
Author:
Cay S. Horstmann, Gary Cornell
Publisher: Prentice Hall PTR
Pub Date: August 17, 2004
ISBN: 0-13-148202-5
Pages: 784
Slots: 1.0

Ebook Description:

Completely revised and up-to-date coverage of:

Generic programming, restrictions and limitations, type bounds, wilcard types, and generic reflection
Swing GUI development, including input validation and other enhancements
Exception handling and debugging, including chained exceptions, stack frames, assertions, and logging
Streams and files, the new I/O API, memory-mapped files, file locking, and character set encoders/decoders
Regular expressions using the powerful java.util.regex package
Inner classes, reflection, and dynamic proxies
Application packaging and the Preferences API

The seventh edition of Core Java™ 2, Volume I, covers the fundamentals of the Java 2 Platform, Standard Edition (J2SE™). A no-nonsense tutorial and reliable reference, this book features thoroughly tested real-world examples. The most important language and library features are demonstrated with deliberately simple sample programs, but they aren't fake and they don't cut corners. More importantly, all of the programs have been updated for J2SE 5.0 and should make good starting points for your own code. You won't find any toy examples here. This is a book for programmers who want to write real code to solve real problems.

Volume I concentrates on the fundamental concepts of the Java language, along with the basics of user-interface programming and provides detailed coverage of:

Object-oriented programming
Reflection and proxies
Interfaces and inner classes
The event listener model
Graphical user-interface design with the Swing UI toolkit
Exception handling
Stream input/output and object serialization
Generic programming

For the same real-world treatment of enterprise features and advanced user-interface programming, look for the forthcoming new edition of Core Java™ 2, Volume II—Advanced Features.

It includes new sections on metadata and other J2SE 5.0 enhancements along with complete coverage of:

Multithreading
Distributed objects
Databases & bull; Advanced GUI components
Native methods
XML Processing
Network programming
Collection classes
Advanced graphics
Internationalization
JavaBeans

download link:
http://www.ziddu.com/download/3121095/CoreJava2VolumeI7thEdition.pdf.html

Tutorial on EJB - Ebook

noreply@blogger.com (Anonymous) — Thu, 08 Jan 2009 05:25:00 +0000

EJB Tutorial

EBook Title:
Tutorial on Enterprise JavaBeanstm
EBook Details:
Author:
Phillip Bride
GemStone Systems, Inc.
Description:
topics:
1) Introducing EJB
2) Overview of EJB
3) Summary

download link:
http://www.ziddu.com/download/3121015/EJB.pdf.html

Tomcat Security & Analysis - 4

noreply@blogger.com (Anonymous) — Fri, 22 Aug 2008 07:23:00 +0000

Tomcat Security Overview and Analysis

Authentication:

Cams gives you all the security features Tomcat does, and a whole lot more. Find out more about Cams by reading the
Cams Overview and the Access Management white paper. We recommend that you also take the Cams Tour to interactively learn about Cams and web security in general.

Previous Home

Tomcat Security & Analysis - 3

noreply@blogger.com (Anonymous) — Fri, 22 Aug 2008 07:15:00 +0000

TOMCAT SECURITY AND ANALYSIS

HTTPS Client Authentication
Authentication using HTTPS (HTTP over SSL) enables browsers and web servers to communicate over an encrypted connection. This is a two-way process, meaning that both the server and the browser encrypt all traffic before sending out data. Tomcat uses HTTPS for confidentiality (by encrypting the data) and integrity (which is insured if the message can be decrypted).
Another important aspect of the SSL protocol is authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a certificate chain, as proof the site is who and what it claims to be. Though Tomcat supports HTTPS connections and server authentication, it is generally recommended that you off-load SSL connections to a web server like Apache or IIS and use Tomcat as a plugin to process the servlet and JSP requests.
The server may also request a client certificate from your browser, asking for proof that you are who you claim to be. This practice is used more for business-to-business transactions than with individual internet users because of the overhead required to manage certificates. Most SSL-enabled web servers do not request client authentication but if you need it, Tomcat does support it.

Web Application Single Sign-on
As the underlying principals to which roles are mapped are environment specific rather than web application specific, it is desirable to:

Make login mechanisms and policies a property of the web application environment.
Use the same authentication information to represent a principal to all applications in the same container, and
Require re-authentication of users only when a security policy domain boundary has been crossed.

Therefore, a J2EE compliant servlet container is required to track authentication information at the container level (rather than at the web application level). Tomcat enables users authenticated for one web application to access other web applications managed by the same container. However, login configurations must still be specified for each web application, which, depending upon the number of web applications can be difficult to manage (Tomcat also allows each web application to define its own realm). Additionally, Tomcat single sign-on does not address multiple Tomcat servers, other web servers such as Apache, or an application server like JBoss.

Specifying Security Constraints
Deployment descriptor elements define the permissions and rules for the protected Tomcat resources and include the following XML elements:
web-resource-collection - A set of URL patterns and HTTP methods that describe a set of resources to be protected. All requests that contain a URL pattern matched in a web resource collection are subject to the constraint.
auth-constraint - A set of security roles (one or more) to which a user must belong to be granted access to resources matched by the web resource collection.
user-data-constraint - Describes integrity and confidentiality requirements for the transport layer of the client server.
Hence, the web resource collection defines the resources, the authorization constraint defines the roles to which a user can belong to access the resources, and the data constraints defines if HTTPS should be required.
Enhancing Tomcat Security with Cams
When you arrive at the boundary of Tomcat security, you'll discover that it is generally limited by the scope of the servlet specification and J2EE security. Consequently, Tomcat will not meet the security needs of most heterogenous, multi-server environments. The good news is that you have the Tomcat source and can write security code and implement security in servlets to customize Tomcat. The bad news is that you probably don't have the time, budget, expertise, or even desire to write security code.
In addition, embedding low-level security code within applications is considered to be bad practice.
The Cafésoft Access Management System is designed to pickup where Tomcat security stops. Cams flexibly meets the needs of the enterprise by providing a complete web access managment system which spans servers and tiers in a web farm. Cams provides the same security features Tomcat does and more.
From a high-level, you should consider using Cams with Tomcat when you have any of the following needs:

You have a web server farm with more than one stand-alone Tomcat server
You are using Apache and Tomcat servers and desire integrated security
You need centralized security configuration, logging, and events
You need a flexible, easy-to-extend security system

Cams offers many unique features that might more closely adhear to your security needs. The following tables show a feature by feature comparison of Tomcat security with and without Cams.

Previous Next

Tomcat Security and Analysis - 2

noreply@blogger.com (Anonymous) — Fri, 22 Aug 2008 06:22:00 +0000

TOMCAT SECURITY AND ANALYSIS

Authentication
By default, you do not need to authenticate to access Tomcat resources. Authentication is needed only when specified in the deployment descriptor with the auth-constrain element. You use a web client (typically a web browser) to authenticate with Tomcat using one of the following mechanisms:
HTTP Basic Authentication
HTTP Digest Authentication
Form Based Authentication
HTTPS Client Authentication
HTTP Basic Authentication
When your browser prompts you for a username and password in a dialog box, you are using HTTP basic authentication to logon to a web server. This is also know as browser-based authentication because the web server requests the browser to authenticate you through the HTTP 1.0 protocol. In the dialog box, you also see the name of a realm to which you will be authenticated. The realm does not necessarily reflect a security policy domain, which is also referred to as a realm. Think of an HTTP basic authentication realm as a "database" of usernames and passwords that identify valid users of a web application (or set of web applications), plus a list of the roles associated with each valid user.
Once you enter your username and password, they are base64 encoded and sent by the browser to Tomcat (for both secure and non-secure resources). Tomcat authenticates you, and then reauthenticates each subsequent request against the specified realm. You cannot logout as your username and password remain in browser memory until you exit. Hence, you must exit the browser to "logout".
Because the username and password are not encrypted, and the target server's identity is not authenticated by the browser, basic authentication alone is not secure. You can improve security by using a secure transport mechanism such as HTTPS, or security at the network level such as a VPN. However, if you switch to HTTP (after authenticating with basic authentication and HTTPS), your browser continues to send your username and password with each subsequent request in cleartext until you exit.
HTTP Digest Authentication
HTTP digest authentication is also performed by the browser upon request by the web server and based on a username, password, and realm. However, in this case your password is digested with the secure MD5 algorithm before it is sent by the browser.
You can specify in Tomcat's element a digest attribute, which must be one of the digest algorithms supported by the java.security.MessageDigest class (SHA, MD2, or MD5). When you select this option, the contents of the password that is stored in the realm must be the digest version of the password. The client must also digest the password using the same algorithm before it is sent. When the realm authenticate() method is called, the password you input is compared with the value returned by the realm and, if equal, you are authenticated.
Because your password is digested, HTTP digest authentication is more secure than basic. However, it does suffer from the same security issues as basic authentication. As it is not supported by popular browsers, HTTP digest authentication is not required by the servlet specification, but it is implemented by Tomcat. As with basic authentication, your credentials are stored in the browser's memory until it is exited.
Form Based Authentication
This is the most popular web authentication mechanism in use. It provides the application developer with the greatest control over the look and feel of the “login screen”, enables closing of user sessions without exiting the browser, and is more secure than basic authentication.
The web application deployment descriptor contains elements to specify a "login form" and an "error page". The HTML login form must contain fields for entering a username and a password, which must be named "j_username" and "j_password", respectively. When you attempt to access a protected resource, Tomcat checks if you are authenticated. If not, the following steps occur:

Tomcat saves the entire HTTP request, then redirects the browser to the configured login form.
You enter your username and password in the login form's "j_username" and "j_password" fields.
The browser posts the form back to the server using the "j_security_check" action.
The container attempts to authenticate the user using the configured security realm.
If authentication fails, the error page is returned with the status code of the response set to 401.
If authentication succeeds, the principal is checked to determine if you have a role authorized to access the resource.
If you are authorized, Tomcat processes the original HTTP request. If authentication fails, or you are not authorized to access the requested resource, the configured error page is returned.

Because your username and password are not encrypted and the target server is not authenticated, form-based authentication using HTTP is not secure. If you are using form-based authentication, you should use a secure transport mechanism such as HTTPS, or security at the network level such as a VPN. However, form-based authentication is more secure than basic authentication when switching back and forth between HTTPS and HTTP as your username and password are not sent with each request.

Another advantage of form-based over basic authentication is that the application can programmatically close your authenticated session, enabling you to logout without restarting your browser. In this respect, calling the HttpSession.invalidate method seems like it should work, but it does not because HTTP sessions are totally independent of authentication (e.g., you can have an HTTP session without authenticating and authenticate without having an HTTP session).

Previous Next

Tomcat Security & Analysis - 1

noreply@blogger.com (Anonymous) — Fri, 22 Aug 2008 05:41:00 +0000

TOMCAT SECURITY AND ANALYSIS

This topic presents an overview of the security features provided with the Apache Jakarta Tomcat servlet container, including suggestions on best practices. Then, an analysis is provided to show how the Cafésoft Access Management System (Cams™) can be integrated with Tomcat to provide enhanced enterprise-wide security that overcomes deficiencies inherent in the servlet and J2EE security model.
Introduction
Tomcat implements security as specified in the Java servlet specification. This document primarily addresses Tomcat 4.x security, which is compliant with the 2.3 servlet specification. Some information is also provided regarding the forthcoming Tomcat 5.x release, which implements the servlet 2.4 specification. Also, there is some overlap between security requirements defined in the servlet and J2EE specifications. In general, the J2EE specification includes all servlet specification requirements and makes some optional requirements mandatory for a web container to be "J2EE compliant". Tomcat implements most optional servlet specification features but, as an open source project, has not been able to pass the J2EE compliance tests due to J2EE licensing policy (recent changes by Sun may allow this in the near future).
Tomcat Security Scope
As stated in the servlet specification, Tomcat security is primarily concerned with:
Authentication - The means by which communicating entities prove their identities to one another.
Access control - The means by which requests for resources are limited to users or programs.
Integrity - The means used to prove that information has not been modified while in transit.
Confidentiality - The means used to ensure that information is understandable only by authorized users.
As defined in the servlet specification, Tomcat security is user role-based and web container (somewhat web application) centric. Hence, Tomcat security scope, by definition in the servlet specification, does not address issues of security integration with other web and application servers.
Declarative and Programmatic Security
The servlet specification classifies Tomcat security into two broad categories:
Declarative security is the expression of application security external to the application and is preferred when sufficient as it allows runtime configuration of application security without recoding the application.
Programmatic security is used to implement fine-grained access control, enabling application components to become security aware.
It may be easier to think in terms of security you configure in the web application environment (declarative) and security you define within the web application code (programmatic). Each web application configures declarative security in its unique deployment descriptor, web.xml. This is a required XML-formatted configuration file (also called the deployment descriptor) found in each web application's WEB-INF directory. Programmatic security involves using HttpServletRequest API method calls to make business logic decisions within the web application context. For example, you may want to make combo box values dynamic based on a user's identity. The servlet API calls you use are:
getRemoteUser - Returns the user name the client used for authentication.
isUserInRole - Determines if a remote user is in a specified security role.
getUserPrincipal - Returns a java.security.Principal object, which contains the principals name and roles.
Tomcat uses role-based authorization to manage access. With this model, access permissions are granted to an abstract entity called a security role, and access is allowed only to users or groups of users who have that role. For example, the Tomcat distribution includes two administrative web applications that only grant access to users with the "manager" role. The deployment descriptor specifies the type of access granted to each role, but does not specify the role to user or group mappings. That's done in the user repository, which is typically a relational database or LDAP server in production environments, but is another XML-formatted file named tomcat-users.xml by default.

Figure 1 - Security snippet from Tomcat Manager's web.xml deployment descriptor
Figure 1.0 shows a security snippet from the Tomcat Manager web application's web.xml file. The security contraint element defines the URL pattern to match for the constraint to apply (in this example the entire web application) and an authentication constraint, which will force the user to authenticate. Access is granted only if an authenticated user has the "manager" role. The login config element defines the type of authentication (more on this next), in this case HTTP basic. And, the roles referenced by the web application.

Next

Java API for XML-Based RPC (JAX-RPC)

noreply@blogger.com (Anonymous) — Tue, 15 Jul 2008 12:21:00 +0000

Java API for XML-Based RPC (JAX-RPC)

Q. What is the Java API for XML-Based RPC (JAX-RPC)?

A. The Java API for XML-Based RPC (JAX-RPC) enables Java technology developers to build Web applications and Web services incorporating XML-based RPC functionality according to the SOAP (Simple Object Access Protocol) 1.1 specification.

Q. How does JAX-RPC use SOAP?

A. Please refer to JSR-101.

Q. What is RPC?

A. RPC stands for remote procedure call, a mechanism that allows a client to execute procedures on other systems. The RPC mechanism is often used in a distributed client/server model. The server defines a service as a collection of procedures that may be called by remote clients.

Q. How is XML related to RPC?

A. The remote procedure call is represented by an XML-based protocol, such as SOAP. In addition to defining envelope structure and encoding rules, the SOAP specification defines a convention for representing remote procedure calls and responses.

Q. What does JAX-RPC have to do with Web services?

A. An XML-based RPC server application can define, describe, and export a Web service as an RPC-based service. WSDL (Web Service Description Language) specifies an XML format for describing a service as a set of endpoints operating on messages. With the JAX-RPC API, developers can implement clients and services described by WSDL.

Q. What are the modes of interaction between clients and JAX-RPC services?

A. There are three different modes:

Synchronous Request-Response: The client invokes a remote procedure and blocks until it receives a return or an exception.

One-Way RPC: The client invokes a remote procedure but it does not block or wait until it receives a return. The runtime system for the JAX-RPC client may throw an exception.

Non-Blocking RPC Invocation: The client invokes a remote procedure and continues processing in the same thread without waiting for a return. Later, the client processes the remote method return by blocking for the receive or polling for the return.

Q. Can a remote method call or response carry service context information?

A. Yes. For example, it may carry a unique transaction identifier or digital signature.

Q. Why doesn't xrpcc generate a WSDL file?

A. The xrpcc tool does in fact generate the WSDL file, but due to a bug it gets deleted along with the source files if the -keep option is not specified. You can use the -keep option which will cause xrpcc to not delete the WSDL or .java source files. If you also use the -s sourcepath option, all of the source files will be placed in the sourcepath directory and then you can easily delete them. The WSDL file will still be placed in the current directory or the directory specified by the -d option.

Q. Does the Java 2 Platform, Enterprise Edition (J2EE) use XML?

A. The Java 2 Platform, Enterprise Edition (J2EE) promotes the use of XML for data messaging between loosely-coupled business systems. The J2EE reference implementation includes the Java API for XML Parsing (JAXP).

JavaServer Pages (JSP) can generate and consume XML between multi-tier servers or between server and client. Java Message Service (JMS) provides an asynchronous transport mechanism for XML data messaging. Enterprise JavaBeans (EJB) offers a robust, synchronous transport mechanism by allowing a business service object to be invoked by XML tags. EJB also uses XML to describe its deployment properties, such as transactions and security.

Q. Can I generate dynamic XML documents using JSP pages?

A. JSP pages enables the authoring of XML pages. XML pages can be generated using JSP pages, which include elements to produce the dynamic portions of the document. The JSP specification includes a powerful tag extension mechanism that can be used to perform XML-based operations, such as applying an XSLT transformation to an XML document.

Java API for XML Registries (JAXR)

noreply@blogger.com (Anonymous) — Tue, 15 Jul 2008 12:17:00 +0000

Java API for XML Registries (JAXR)

Q. What is the Java API for XML Registries (JAXR)?

A. The Java API for XML Registries (JAXR) API provides a uniform and standard Java API for accessing different kinds of XML Registries. XML registries are an enabling infrastructure for building, deployment, and discovery of Web services.

Q. What is the relationship between the JAXR API and other XML APIs?

A. Implementations of JAXR providers may use the Jav API for XML-Based RPC (JAX-RPC) for communication between JAXR providers and registry providers that export a SOAP based RPC-like interface (for example, UDDI).

Implementations of JAXR providers may use the Java API for XML Messaging (JAXM) API for communication between JAXR providers and registry providers that export an XML Messaging-based interface (for example, ebXML TRP).

The Java API for XML Processing (JAXP) and Java Architecture for XML Binding (JAXB) may be used by implementers of JAXR providers and JAXR clients for processing XML content that is submitted to or retrieved from the Registry.

Q. Why do we need a new JAXR API when we have the Java Naming and Directory Interface (JNDI)?

A. The JNDI API was designed with a very different set of requirements from the JAXR API. Both are abstraction APIs over existing specifications. However, the abstraction in directory services differs considerably from that of XML Registries used for publishing and discovery of Web services. The JAXR API needs richer metadata capabilities for classification and association, as well as richer query capabilities.

Q. Would it not be better to have enhanced the JNDI API with the added functionality of the JAXR API?

A. That option was considered. Meeting the additional requirements of XML Registries requires an elaborate information model. The JNDI API has an existing information model that is constrained by design to address the requirements for directory services. Extending the JNDI API would overly constrain the JAXR API and would create backward compatibility issues for the JNDI API.

Q. What is the purpose of Association in the JAXR information model? It is not used anywhere in the API.

A. An Association relates two RegistryObjects to each other. An Association may be defined between two objects in the registry and submitted using the GenericLifeCycleManager's saveObjects method.

Q. What is the purpose of Classification in the JAXR information model? It is not used anywhere in the API.

A. A Classification classifies a RegistryObject. A Classification may be defined for a RegistryObject and submitted using the GenericLifeCycleManager's saveObjects method.

Q. Why is JAXR an abstraction API and not targeted to a specific registry such as UDDI or ebXML?

A. An abstraction-based JAXR API gives developers the ability to write registry client programs that are portable across different target registries. This is consistent with the Java philosophy of Write Once, Run Anywhere. It also enables value-added capabilities beyond what the underlying registries are capable of. For example, a non-JAXR UDDI client does not have the ability to do taxonomy browsing and taxonomy-aware smart queries, which are available to a JAXR client for UDDI.

Q. Why does the JAXR API not use UDDI terms and concepts?

A. The JAXR API is not specific to UDDI or any other registry specification. It is an abstraction API that covers multiple specifications. It is designed to enable developer choice in the use of a Web service registry and/or repository. The JAXR API uses UDDI terms and concepts when they fit the JAXR information model (for example, Service, ServiceBinding, and method names in BusinessQueryManager and BusinessLifeCycleManager).

Q. Why did the JAXR information model use the ebXML Registry Information Model as its basis rather than the UDDI data structures?

A. The JAXR API is designed to support multiple registries. The ebXML Registry Information Model is more generic and extensible than the UDDI data structures. Because of this characteristic, it was possible to extend the ebXML Registry Information Model to satisfy the needs of UDDI and other registries.

Q. Why was the JAXR information model not designed from the ground up?

A. Information models take time to develop. It was easier to start with an existing information model and improve upon it.

Java API for XML Messaging (JAXM)

noreply@blogger.com (Anonymous) — Tue, 15 Jul 2008 12:16:00 +0000

Java API for XML Messaging (JAXM)

Q. What is the Java API for XML Messaging (JAXM)?

A: The Java API for XML Messaging (JAXM) is an API designed specifically for the exchange of XML business documents over the Internet. Examples of XML documents that might typically be exchanged are purchase orders, order confirmations, and invoices. You can send non-XML data by adding attachments to your message.

Q: What standards is JAXM based on?

A: JAXM is based on the Simple Object Access Protocol (SOAP) 1.1 and SOAP with Attachments specifications. JAXM also allows the implementation of standard protocols on top of the SOAP implementation, such as SOAP-RP or the ebXML Transport, Routing & Packaging V1.0 - Message Service Specification.

Q. Do I have to use the J2EE platform to use JAXM?

A: No, you are free to use the Java 2 Platform, Standard Edition (J2SE) as well as the Java 2 Platform, Enterprise Edition (J2EE). A stand-alone client (a client that does not use a messaging provider) can use the J2SE platform to send request-response messages to Web services that process request-response messages. This requires no deployment or configuration from the client, so it is easy to do.

Q. What is a messaging provider?

A: A messaging provider is a service that works with the messaging infrastructure to route and transmit messages. What it does is completely transparent to the client sending or receiving a message. An application that uses a messaging provider must use a connection that goes to the provider, called a ProviderConnection object in the JAXM API. Using a messaging provider also requires some deployment and configuration. Normally, a client using a messaging provider runs in a container -- either a servlet or a J2EE container. At deployment time, the client needs to give the container information about the messaging provider. In the future, there will be a deployment tool that makes this easy.

Q. Do I have to use a messaging provider?

A: No. You need to use a messaging provider only when your application requires one-way (asynchronous) messaging. In this type of messaging, a message is sent to a recipient as one operation, and the recipient responds at some later time in a different operation. If you application uses a request-response style of messaging, in which the response to a message is sent back as part of the same operation, you do not need a messaging provider. When you do not use a messaging provider, you use a SOAPConnection object, which supports the simpler request-response messaging model.

Q. Can a JAXM message be routed to more than one destination?

Yes. Intermediate recipients can be specified in a message's header. One way this capability can be used is to automate business processes. For example, two businesses can agree to the conditions under which they exchange XML documents so that they can implement the automatic generation of messages and responses. Assume that two businesses have an arrangement specifying that purchase orders will go first to the order entry department, then to the order confirmation department, then to the shipping department, and finally to the billing department. Each department is an intermediate recipient (called an actor). After an actor has done its part, it removes everything in the header that relates to it and sends the message on to the next actor listed in the header.

Q. Can I use ebXML headers in a JAXM message?

A: Yes, you can use ebXML headers if you use an ebXML profile that is implemented on top of SOAP. A profile is a standard protocol, such as ebXML TRP or SOAP-RP, that works on top of SOAP to give you added functionality. You need to use a messaging provider that supports the profile, and you need to arrange with your recipients to use the same profile.

Java Architecture for XML Binding (JAXB)

noreply@blogger.com (Anonymous) — Tue, 15 Jul 2008 12:15:00 +0000

Java Architecture for XML Binding (JAXB)

Q. What is Java Architecture for XML Binding (JAXB)?

A. The Java Architecture for XML Binding (JAXB) simplifies the creation and maintenance of XML-enabled Java applications. JAXB provides a binding compiler and a runtime framework to support a two-way mapping between XML documents and Java objects. The binding compiler translates W3C XML Schema into one or more Java classes without requiring the developer to write complex parsing code. The schema-derived classes and binding framework enable error and validity checking of incoming and outgoing XML documents, thereby making it possible to ensure that only valid, error-free messages are accepted, processed, and generated by a system. For more information, see the Reference Implementation and the Public Draft Specification, both available for download from the JAXB homepage.

Q. What is the difference between JAXB, SAX, and DOM? Which one should I use?

A. SAX is an event-driven XML parser that is appropriate for high-speed processing of XML because it does not produce a representation of the data in memory. DOM, on the other hand, produces an in-memory data representation, which allows an application to manipulate the contents in memory. Both SAX and DOM automatically perform structure validation. An application could perform content validation with SAX and DOM, but such an application must provide the necessary extra code, which might be complicated, error-prone, and difficult to maintain.

A JAXB application can perform structure and content validation with Java classes that it generates from a schema. A JAXB application builds an in-memory data structure, like a DOM, by marshalling an XML document to build a content tree, which contains objects that are instances of the derived classes. However, unlike a DOM tree, a content tree is specific to one source schema, does not contain extra tree-manipulation functionality, allows access to its data with the derived classes' accessor methods, and is not built dynamically. For these reasons, a JAXB application uses memory more efficiently than a DOM application does. If the content of a document is more dynamic and not well-constrained, DOM and SAX are more appropriate than JAXB for processing XML content that does not have a well-known schema prior to processing the content.

Q. How does JAXB work?

A. To build a JAXB application, start with an XML schema. The beta release requires that the schema language be W3C 2001 Recommendation for XML Schema.

After obtaining an XML Schema, you build and use a JAXB application by performing these steps:

Generate the Java source files by submitting the XML Schema to the binding compiler.

You can use custom binding declarations to override the default binding of XML Schema components to Java representations

Compile the Java source code.

With the classes and the binding framework, write Java applications that:

Build object trees representing XML data that is valid against the XML Schema by either unmarshalling the data from a document or instantiating the classes you created.

Access and modify the data.

Optionally validate the modifications to the data relative to the constraints expressed in the XML Schema

Marshal the data to new XML documents.

Q. Who is involved in developing JAXB?

A. JAXB is being developed through the Java Community Process (JCP) with an expert group consisting of IBM, Software AG, BEA Systems, Hewlett-Packard, TIBCO Software Inc., Oracle, Fujitsu Limited, Breeze Factor LLC, Macromedia, Inc. and Intalio, Inc. Sun is an active member of the W3C XML Schema Working Group and is also working with other industry consortia such as OASIS and xml.org.

Q. Where can I read more about JAXB?

A. For a higher-level explanation of JAXB, refer to the JAXB chapters in the Java Web Services Tutorial. Also note that a detailed user's guide is included as part of the JAXB distribution. For a more technical and detailed description of JAXB, see the the latest version of the Specification, which you can download from the JAXB homepage. Please note that the Specification is in Adobe Acrobat PDF format. Download Adobe Acrobat for free.

XML Basics

noreply@blogger.com (Anonymous) — Tue, 15 Jul 2008 12:08:00 +0000

XML BASICS

Q. What is XML?

A. XML, the Extensible Markup Language, is a universal syntax for describing and structuring data independent from the application logic. XML can be used to define unlimited languages for specific industries and applications.

Q. Who developed XML?

A. XML is an activity of the World Wide Web Consortium (W3C). The XML development effort started in 1996.

A diverse group of markup language experts, from industry to academia, developed a simplified version of SGML (Standard Generalized Markup Language) for the Web. In February 1998, XML 1.0 specification became a recommendation by the W3C.

Q. What are the key benefits of XML?

A. XML promises to simplify and lower the cost of data interchange and publishing in a Web environment. XML is a text-based syntax that is readable by both computer and humans. XML offers data portability and reusability across different platforms and devices. It is also flexible and extensible, allowing new tags to be added without breaking an existing document structure. Based on Unicode, XML provides global language support.

Q. What are the applications of XML?

A. XML is poised to play a prominent role as a data interchange format in B2B Web applications such as e-commerce, supply-chain management, workflow, and application integration. Another use of XML is for structured information management, including information from databases. XML also supports media-independent publishing, allowing documents to be written once and published in multiple media formats and devices. On the client, XML can be used to create customized views into data.

Q. What is the relationship between XML and Java technology?

A. XML and the Java technology are complementary. Java technology provides the portable, maintainable code to process portable, reusable XML data. In addition, XML and Java technology have a number of shared features that make them the ideal pair for Web computing, including being industry standards, platform-independence, extensible, reusable, Web-centric, and internationalized.

Q. What are the benefits of using Java technology with XML?

A. Java technology offers a substantial productivity boost for software developers compared to programming languages such as C or C++. In addition, developers using the Java platform can create sophisticated programs that are reusable and maintainable compared to programs written with scripting languages. Using XML and Java together, developers can build sophisticated, interoperable Web applications more quickly and at a lower cost.

Q. What XML-related activities is Sun participating in?

A. Sun is actively participating in W3C working groups for XML Stylesheet/Transformation Language (XSL/T), XML Schema, Xlink, and XML Query. Sun is also participating in a number of other industry consortia including Oasis, XML.org, and Apache.

Q. Where can I find additional documentation?

A. The Java Technology & XML Documentation page has a comprehensive list of all documentation related to Java Technology and XML available on this website.

Q. What is Java API for XML Processing (JAXP)?

The Java API for XML Processing, or "JAXP" for short, enables applications to parse and transform XML documents using an API that is independent of a particular XML processor implementation. JAXP also provides a pluggability feature which enables applications to easily switch between particular XML processor implementations.

To achieve the goal of XML processor independence, an application should limit itself to the JAXP API and avoid implementation-dependent APIs. This may or may not be easy depending on the application. JAXP includes industry standard APIs such as DOM and SAX.

The reason for the existance of JAXP is to facilitate the use of XML on the Java platform. For example, current APIs such as DOM Level 2 do not provide a method to bootstrap a DOM Document object from an XML input document, JAXP does. (When DOM Level 3 provides this functionality, a new version of the JAXP specification will probably support the new Level 3 scheme also.) Other parts of JAXP such as the javax.xml.transform portion do not have any other equivalent APIs that are XSLT processor independent.

Java XML part 5

noreply@blogger.com (Anonymous) — Wed, 09 Jul 2008 04:00:00 +0000

Java XML

3) On calling DOMHelloWorld

The main method of DOMHelloWorld.java will check that the filenameof the xml file has been provided as an argument.

public static void main(String[] args)

{

if (args.length != 1)

{

System.out.println("usage: java DOMHelloWorld hello.xml");

System.exit(0);

}
String xmlfilename = args[0];
}

4) Parsing the XML document

First we must create an instance of the parser (vendor specific parser). This is the same parser we imported earlier in step 2.

DOMParser xmlparser = new DOMParser();

5) Parse the xml file.

This is really easy because the parser does it for you.
All you have to do is call the parse method with the name of the xml file.
xmlparser.parse(xmlfilename);
If you look at the API documentation that comes with the Xerces parser and search for the parse method you will notice something special.
DOMParser and SAXParser are subclasses of XMLParser.
The parse method throws two exceptions, SAXException and java.io.IOException.
If you try to compile the source code without catching the exception, an error will occur (java.io.IOException must be caught).
Under the previous import statements add the importsfor the IOException and SAXException classes .
import

java.io.IOException;
import org.xml.sax.SAXException;
So now we put a try/catch block around the parse method of DOMParser.
try {
xmlparser.parse(xmlfilename);
} catch (IOException e)
{
System.out.println("Error reading xml file: " e.getMessage());
}
catch (SAXException e)
{
System.out.println("Error in parsing: " e.getMessage());
}

6) Accessing the DOM tree

As DOM creates a tree-based structure based on the xml file,we will need to access the information stored in the tree.
To access the tree call getDocument() and this returns a Document.

Document doc = xmlparser.getDocument();

This Document represents the entire XML document. The data we need to access is stored in nodes. These nodes can have child nodes.
Therefore what you need to do next is walk through the Tree structure (Document) and display the data stored in the Nodes.
Now the Fun starts!!!

7) Walking the nodes

Next we will write a method to display the data in a node. The method will be called displayNode and will take one parameter, the start node.

This method will start from the first node and walk through all the nodes in the XML using recursion.

The nodes in the XML document are of different node types.
The node types can be divided into two broad categories; structural nodes and content nodes.
Structural nodes are not actually part of the content in the document but are used to provide syntax structure.

The following is a list of the different types of nodes:

The main nodes we are interested in are DOCUMENT_NODE, ELEMENT_NODE and ATTRIBUTE_NODE.

Should I use DOM or SAX?
If your document is really large, or you only need to extract a few elements from the whole document, then using DOM is not practical.
SAX Looks for startElement events in which the element name is verse, then looks at each character event for the name SAX is more efficient because we only care about a few elements in the document

SAX is good when:

1)You only need to go through a document once
2)You’re only looking for a few items
3)You’re not too concerned with document structure of the context of the elements you’re looking for
4)You don’t have much memory

DOM Builds Java objects for everything in the document, then walks through the tree looking for the name. Using DOM, we create a lot of Java objects we never use, and we go through the document twice (once to parse it and once to search it)

DOM is good when:

1)You need to go through a document more than once
2)You need to manipulate lots of things
3)in the document The structure of the document and the
4)context of the elements is a concern
5)Memory is not an issue

Previous Home