Monday, April 30, 2007

cvc-elt.1: Cannot find the declaration of element 'faces-config'

If you get this error while trying to deploy JavaServer Faces (JSF)-based applications, just make sure your faces-config.xml configuration file has the reference:
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
I think the DTD version might have changed (to 1.2?) since I last used the reference implementation from Sun. This is a surprisingly common problem for people just starting out with JSF. A few books I have reviewed don't mention that configuration files (including web.xml) are validated by the container during deployment.

Sunday, April 29, 2007

Creating Custom Tag Actions For JSPs

Custom tags are used to extend the JSTL, and are especially important when you decide to go scriptless in JSPs like I recently did. The process involves three actions: creating the tag handler class, creating the tag library descriptor (TLD), and updating the deployment descriptor (web.xml). This example creates a custom action that can be used in JSP pages to format dates for display in the resulting HTML.
The example is done in the NetBeans 5.5 IDE (with Sun Java System Application Server 9u1). NetBeans makes this process a no-brainer. I still encourage you to learn to write these tags by hand - for debugging and troubleshooting. Almost all Java web-oriented IDEs have similar features.

Create the Tag Library Descriptor (TLD):
- This is where your application looks up references to tags used in JSPs. It can refer to individual tag files or other libraries.
  1. Open the web application you want to add custom tags to in NetBeans IDE.
  2. Right-click web module | New - File/Folder - Web - Tag Library Descriptor, click Next | provide a name and prefix. Click Finish.
  3. A basic TLD is created. I normally remove the uri tag and commented text from the generated TLD file - keep things tidy.

Creating the Tag Handler Class:
- This is where what the tag does is defined. It follows JavaBean conventions and implements tag extension interfaces (such as SimpleTag in JSP 2.0).
  1. Open the web application you want to add custom tags to in NetBeans.
  2. Right-click web module | New - File/Folder - Web - Tag Handler, click Next | provide a name and package. Click Next. Provide the path to the TLD file we just made above to have its information added automatically. Provide attributes on the same page.
  3. The TLD is updated and the handler class created, complete with setters for all the attributes you specify. Only thing you need to do is modify the doTag() method with what you want the tag to do.
Updating the Deployment Descriptor (web.xml):
- Unfortunately, the IDE does not update web.xml (and you need to if you are not using JSP 2.x).
- You have to manually add the tag-lib node under jsp-config.
- With Java EE 5, you do not need to do this step.

Use the Custom Action in a JSP:
  1. Reference the TLD using the taglib page directive. Remember you can use Ctrl+Space in NetBeans to have the some of the directive's fields autocompleted for you.
  2. Use the tag to format some dates.
Source code with snippets for the example can be viewed in my published GoogleDocs. As you can see, adding custom tags is a trivial activity, made even easier by improvements in the JSP container since JSP 2.0.

Monday, April 23, 2007

Move To Scriptless JSP A Pain

If you plan to use 'scriptless JSP' in your Java web applications, it is much easier to start out with the idea than hope to convert existing JavaServer Pages (JSP) after building your application. Scriptless JSP (s-JSP) involves moving all Java code, scriptlets, declarations, and "set operations" away from JSPs to servlets, leavings the JSPs display-oriented. Dynamic content in the JSPs is then provided by a combination of the JSP Expression Language (EL), JavaBeans, JSTL/custom actions, and objects in mainly the session and application scopes.

Scriptless JSP is great for enforcing the MVC design model, allowing non-Java programmers to take control of designing the presentation/view a lot easier. It also conforms to XML specifications by using characters that XML engines won't freak about. For example, the '>' sign is known simply as 'gt' in EL - the day you wish to XML-ize your JSPs, the transition will be much easier from s-JSP than from regular JSP.

In my opinion, you better make the decision to use s-JSP before you start writing web applications. In fact, it is always smarter to use EL from the start - conversion to regular JSP is as easy as setting the el-gnored switch to false and scripting-invalid switch to false in web.xml.
Also, you should be very familiar with the Java Standard Template Library (JSTL) and know how to build your own custom actions. Because I could have Java code in JSPs, I neglected these topics only to discover they are important for s-JSP.
Also make sure your IDE supports EL fully. In NetBeans 5.5 (which does fully), I kept on seeing what seems like a discrepancy: when I use a statement like: <c:if test="${empty sessionScope["title"]}"> I get an error. But outside the test, I can obtain the title attribute from the session map by using
${sessionScope["title"]}. I must not be understanding something here. Why do I need to omit quotes (as in <c:if test="${empty sessionScope[title]}">) in the test to make the syntax right? With correct syntax, I can never find my object in the session. It'd seem as if the "title" attribute is a page-scoped object?

As a matter of caution, endeavors like this should be done on test systems first before moving them into production. I'll take this a step further - do changes like this move on test code before integrating them into production code. If I didn't use CVS, I'd be screwed just about now; fortunately, I was able to return to my original code from CVS. Save for the wasted hours, you must plan the move very carefully.

Friday, April 20, 2007

Freedom of Fonts in Web Browsers

I really do not think it should be up to web page designers to dictate what font you view a web page with. There are websites you visit and you can hardly read content because someone specified some insane font style and size for the page, which works well if the viewer's web browser is left in defaults. If you in fact have the fonts and can do the sizes specified, trouble happens. I wish I could just avail a few fonts to a browser and force every website I visit to be displayed in just those few fonts as desired.
Also, don't developers ever test their sites across browsers any more? I've come across a few websites that work well only in IE or Firefox and suck in other browsers. Even if you develop for IIS only, it's imperative you test on other browsers ... unless you don't care about visitors that exercise freedom of browsers. At least have a disclaimer if you have to go that way.

For the rest of us that customize our browsers to the tee, including specifying a font and style, it becomes an annoyance. Preferences change often, but I like "Californian" and "Courier New" at 10pt for my pages - small font. If I were to visit a site that attempts to reduce the font size by 3 points (relative), for example, the text would be unreadable. This is where Firefox excels at giving control to the user - you can specify a minimum font and the browser ensures that all font sizes are always above that size. I don't know anywhere in IE where this can be done. In Firefox, you also have to unselect the option that allows pages to choose their own fonts.

I always recommend that when you design web pages, the bulk of your content shouldn't have restrictions on what font styles and sizes users should use. Most users customize these two things, and you'd be abusing your authority as an author to restrict that freedom. It's understandable for fonts that must fit on images or certain fixed spaces such as menus and ads. Developers that use templates that calculate font sizes based on available space, etc, are prone to this problem. I discourage using relative font sizing (e.g. <font size="-3">) for text that can be manipulated by browsers. User preferences with fonts and styles can also mess up your menus and such that depend on fixed spaces. For such, images are the way to go - to promote consistency.

Friday, April 13, 2007

Simple Authentication Servlet Filter with JSP/Servlet

Servlet filters in Java allow you centralized management of tasks such as authetication, compression, auding and logging, image conversion, and localization of web content, among others. The servlet filter I discuss here only demonstrates how a simple Java-based web application could add a form of authentication. Doing this saves you from having to check whether users are logged in, page is expired, or other permissions on every page, freeing each web page to focus more on its content.

The design scenario is simple: when an HTTP request arrives, users are sent to a login page (e.g. "login.jsp") if they are not logged in. Otherwise, authenticated users are sent to whatever other page they requested. When users log in, a servlet (call it "/auth") handles the authentication and sends the login page again if login fails, or sends the user to a landing page (e.g. "index.jsp") if successful.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
System.out.print("Authentication: Request received ...");
try {
boolean authorized = false;
if (request instanceof HttpServletRequest) {
HttpSession session = ((HttpServletRequest)request).getSession(false);
if (session != null) {
UserToken token = (UserToken) session.getAttribute("userToken");
String qryStr = ((HttpServletRequest)request).getQueryString();
if((token != null) || "cLogin".equalsIgnoreCase(qryStr))
authorized = true;

if (authorized) {
chain.doFilter(request, response);
} else if (filterConfig != null) {
ServletContext context = filterConfig.getServletContext();
String login_page = context.getInitParameter("login_page");
System.out.print("Authentication: Login page = " + login_page);
if (login_page != null && !"".equals(login_page)) {
context.getRequestDispatcher(login_page).forward(request, response);
} else {
throw new ServletException ("Unauthorized access, unable to forward to login page");
} catch (IOException io) {
System.out.println("IOException raised in AuthenticationFilter");
} catch (ServletException se) {
System.out.println("ServletException raised in AuthenticationFilter");
System.out.print("Authentication: Response dispatched ...");

  • A user token is placed in the session after successful authentication in the servlet. It is removed when the session expires or when the user logs out.
  • The login page should call the servlet for authetication with an identifiable query. In this example, the link in login.jsp's form would probably look like "http://domain/servlet/auth?cLogin". (see below).
  • We check for the token first and if it is valid, we don't care about the query string. This setup helps avoid circular calls (especially since we do a forward as opposed to a redirect).
  • Authentication is valid only when a user token exists in the session. But we let the request proceed if the user is logging in.
  • If authentication fails and we have a valid configuration, we simply forward the request to the login page again. Otherwise, we throw an exception (we should really never get here ...). The default error page for the application would likely pick that up.
Add to the root <app> node.


Code snippet for Login Page
String urlParams = url + "/auth?cLogin";
<form action="<%=urlParams%>" method="POST">
// Form components

Code snippet for Servlet:
- Obviously would be called from a doPost() method that's already extracted the parameters from the request if one of the parameters is "cLogin".
private void performLogin(HttpServletRequest request, HttpServletResponse response, String username,
String password, ServletContext context) throws ServletException, IOException {
if((username!=null) & (password!=null)) {
User user = userFacade.findByUsername(username);
if(user!=null) {
UserToken tok = Authentication.authenticateUser(user, username, password);
if (tok != null) {
request.getSession().setAttribute("userToken", tok);
} else {
String url = context.getInitParameter("login_page");
if (url != null && !"".equals(url)) {
} else {
String url = context.getInitParameter(
if (url != null && !"".equals(url)) {

That's it. After you deploy a web application with this filter, all requests will be intercepted and authentication checked.

Saturday, April 07, 2007

Reverse Engineering At A Glance

If you've ever wanted to understand how something works, you've considered 'reverse engineering'. Reversing happens more widely than most people realize (read this Wikipedia article for examples), but my interest here is in a specific field of software reverse engineering.
Although often mistaken for "hacking", reversing is different in that it is a dignified science much as a biology researcher would seek to understand the working of natural processes. The goal is to discover information that was previously unavailable. For software, it means taking a peek into the guts of programs and understanding what they are really doing. On college campuses, this is the subject of entire courses. You don't have to go to college for this stuff though - a creative mind, code breaking skills, programming, and logical analysis abilities are much of what you will need.

Why reverse engineering? Apart from paranoia when programs arbitrarily run on my computer without my knowledge, more plausible reasons exist:
  1. Be able to create competing or better software products.
  2. Understand security = encryption, malicious software, product protections, audit programs.
  3. Interoperability with other [undocumented] software systems.
  4. Evaluate software quality and robustness.
To get started reversing, you must be familiar with specific platforms (e.g IA-32 - used on most 32-bit PCs these days) and learn the assembly/object language for that platform, including [dis]assembly and [de]compiling processes. You've got to the operating system well, as it'll be the gateway you use to access low-level processes on the system. Be aware that certain methods of building programs can make reversing a nightmare. For example: compiler optimizations can cause object code to seem counter-intuitive as they endeavor to minimize code size or improve execution efficiency.
You must be able to reverse at all levels of program complexity. System-level reversing involves understanding what the OS and applications are doing, before delving into code-level reversing where you deal with algorithms and design concepts. You should be able to work with native [C/C++] binaries (as opposed to [Java/.Net] bytecode - which requires a virtual machine to execute - and is easier).

You'll need an arsenal of tools to get your work done, including monitors, sniffers, and explorers (to show you information about the programs in the operating environment), disassembers (to provide textual representations of program binaries), debuggers (to observe software at runtime, including setting breakpoints and tracing through code), and decompilers (build source code from assembly/object code).

You'll certainly run into legal issues. There's really no need to reverse patented technologies (since they are publicly published and protected from duplication by law). Trade secrets can nevertheless be reversed, as long as they are available on the open market and obtained legally. The DMCA can seem threatening, but it really doesn't affect most reverse engineering.
The DMCA prohibits circumventing copyright protection systems (e.g defeating DRM) and creating technologies to circumvent copyright protection systems (e.g. key-gens). If you develop a license key generation program, you violate the second provision, and if you use it, you violate the first. You are however excused from the DMCA if your intent is for interoperability, research, security evaluation, educational institutions and library evaluation (presumably before purchase), government investigation, regulation (e.g. restrict usage by minors), and protection of privacy (e.g. remove features that transmit personal information).

Once you have grasped this high level view of reversing, you need patience and persistence to start getting good at it. The benefits of this skill are endless. The desire to know what's going on and to gain competitive advantage shall always be a primary motivator, but proficiency at this skills is what will guarantee how useful this world becomes to you. You'll end up with gains in observation skills and avid attention to detail. If you are a software developer, it'll change how you design and write programs. If you are a software tester, you'll be more productive at how you do testing and quality control.

Simple Java EE 5 Development Environment

From emails of readers wondering how I have my development environment set up, I decided to get this documented somewhere in response. I promise it's the simplest setup ever, and you can get cranking on code and produce applications much sooner than other options I have tried.
For basic Java EE 5 development, you need a Java IDE, an application server, the JDK, and a database application. Here are details of what my environment consists of:

Development System:
2.66GHz Pentium 4 HP Pavilion laptop with Windows XP SP2 and 1.2GB RAM. The emphasis here is a fast processor and gobs of memory. I also recommend about 4GB of hard disk space for the tools and projects.

Integrated Development Environment:
NetBeans 5.5; came bundled with Sun Java System Application Server 9u1 (or you can always associate it later). You should also have JDK 5.0 or later installed.
Remember to update system environment variables such that when you run java -version on the command prompt, it is successful. You can debug applications on the server from the IDE quite simply.

Database Application:
MySQL 5.x. You can set up SJSAS9u1 to use this database for your applications by setting up references to it from the admin console. SJSAS comes with Apache's DerbyDB database, but I prefer MySQL because it is production grade and comes with admin tools.

That's all there is to it. Pretty novice, isn't it? But as any good programmer, you should have alternatives on standby for when your primary environment seems to misbehave. I maintain an installation of the JBoss Application Server 4.0.3, the Eclipse 3.x IDE/platform, MS SQL Server 2000 Developer Edition, and (believe it or not) JBuilder 2005 Foundation. Except for MS SQL, everything I do development on is free (or costs very little).
As you get more advanced with the language and application development, you'll find need for decompilers, profiling tools, unit test and optimization tools, productivity and feature packs (such as the web pack or C/C++ development pack), modeling tools, and other integration tools. You might want to use CVS at some point for source code control and start building your own libraries and templates.

This setup is only suitable for desktop and web applications. More advanced programming will certainly require other tools. For example, if you do reverse engineering, this setup will not help you. Keep an eye out for posts I'll do on reverse engineering. In the first such posts, I'll focus on r.e.'ing DVDs and CDs with so-called protection. That topic will be my graduate school dissertation.

As to my qualifications, I'm simply still a college student. Almost all my programming/computing skills are self-taught (read lots of books, surf the web, code a lot, learn by experience). Very little has come from my formal training. I have a couple of programming certifications in Java and C/C++, database (MS, Oracle), and MCSEs. Lots more valuable experience working in telecommunications (programming cell phones) and storage device development (read FC, SAS and SCSI storage controllers). Nothing special there, except my passion to learn and use what I learn. I also contribute code regularly to open-source projects such as those on Finally, I don't like Microsoft stuff - if I knew Linux well enough, I'd move all my development to it (some day). Although I can program with C# and other .Net technologies, I'm not even listing them here ...

Hope this answers the emails. Thanks for those, by the way.

Friday, April 06, 2007

Dip Into Java EE 5

If you are considering moving to Java EE 5 soon and need to know what it's all about and how to get started on it, the following in a brief summary from a great book I've been reading (credits at end of post). Though examples are implemented on the JBoss AS, I did all of mine on Sun System Application Server 9.1 using the NetBeans 5.5 IDE and MySQL Community Server 5.x.

Java EE 5 provides a platform for developing and deploying multitiered, distributed applications that are designed to be maintainable, scalable, and portable. Just as an office building requires a lot of hidden infrastructure of plumbing, electricity, and telecommunications, large-scale applications require a great deal of support infrastructure. This infrastructure includes database access, transaction support, and security. Java EE provides that infrastructure and allows you to focus on your applications.

Building distributed applications (software with components that run as separate processes, or on separate computers) allows you to partition the software into layers of responsibility, or tiers. Distributed applications are commonly partitioned into three primary tiers: presentation, business rules, and data access. Partitioning applications into distinct tiers makes the software more maintainable and provides opportunities for scaling up applications as the demand on those applications increases. Java EE architecture is based on the idea of building applications around multiple tiers of responsibility. The application developer creates components, which are hosted by the Java EE containers.

Containers play a central theme in the Java EE architecture. Servlets are one type of Java EE web component. They are Java classes that are hosted within, and invoked by the Java EE server by requests made to, a web server. These Servlets respond to those requests by dynamically generating HTML, which is then returned to the requesting client.
JSPs are very similar in concept to Servlets, but differ in that the Java code is embedded within an HTML document. The Java EE server then compiles that HTML document into a Servlet, and that Servlet generates HTML in response to client requests.

JSF is a Java EE technology designed to create full and rich user interfaces. Standard user interface components are created on the server and connected to business logic components. Custom renderers take the components and create the actual user interface.

JDBC is a technology that enables an application to communicate with a data-storage system. Most often that is a relational database that stores data in tables that are linked through logical relations between tables. JDBC provides a common interface that allows you to communicate with the database through a standard interface without needing to learn the syntax of a particular database.

EJBs are the centerpiece of Java EE and are the component model for building the business rules logic in a Java EE application. EJBs can be designed to maintain state during a conversation with a client, or can be stateless. They can also be designed to be short-lived and ephemeral, or can be persisted for later recall. EJBs can also be designed to listen to message queues and respond to specific messages. Java EE is about a lot more than EJBs, although EJBs do play a
prominent role.

The Java EE platform provides a number of services beyond the component hosting of Servlets, JSPs, and EJBs. Fundamental services include support for XML, web services, transactions, and security. Extensive support for XML is a core component of Java EE. Support for both document-based and stream-based parsing of XML documents forms the foundation of XML support. Additional APIs provide XML registry service, remote procedure call invocation via XML, and XML-based messaging support.

Web services, which rely heavily on XML, provide support for describing, registering, finding, and invoking object services over the Web. Java EE provides support for publishing and accessing Java EE components as web services.
Transaction support is required in order to ensure data integrity for distributed database systems. This allows complex, multiple-step updates to databases to be treated as a single step with provisions to make the entire process committed upon success, or completely undone by rolling back on a failure. Java EE provides intrinsic support for distributed database transactions.
Java EE provides configurable security to ensure that sensitive systems are afforded appropriate protection. Security is provided in the form of authentication and authorization.

Additional notes:
• Containers provide an environment and infrastructure for executing Java EE components.
• Servlets and JSPs provide server-side processing and are used to create the presentation layer of a Java EE system.
• JSF provides user interface components that make it easy to create flexible user interfaces and connect user interface widgets to business objects.
• JDBC is an interface to database systems that allows developers to easily read and persist business data.
• EJBs represent business objects in a Java EE application. EJBs come in various categories, including stateful session beans, stateless session beans, entity beans, and messagedriven beans.
• Java EE systems can be used to develop service-oriented architectures or web services systems. A web service architecture is one that provides machine-to-machine services over a network using a well-defined protocol.
• Some of the essential architectural patterns used in Java EE applications include an application client with EJBs, a JSP client with EJBs, an applet client with JSPs and a database, and web services used for application integration.

[Beginning Java EE 5 - From Novice to Professional, pp. 26-28, Copyright © 2006 by Kevin Mukhar and Chris Zelenak, with James L. Weaver and Jim Crume]