 | Level: Introductory Brett D. McLaughlin, Sr. (brett@newInstance.com), Author and Editor, O'Reilly Media, Inc.
28 Feb 2006 What Shale isn't is a shrink-wrapped, well-documented, well-tested product complete with an automated installer and a polished management interface. Now find out what it is, as Brett McLaughlin unveils this mighty -- and rightful-- heir to the legacy of Struts. In this first of a five-part series, Brett explains what Shale is, how it's different from the Struts framework, and how to install and set it up in your development environment.
Of all the Web frameworks to come out of the past five years, Jakarta
Struts is among the most popular ever to be used by Java™ developers, so
the arrival of its offspring is a noteworthy event. While Shale isn't yet the
most popular framework -- or even the most known -- its pedigree is
impressive. Even more exciting is the fact that Shale isn't just a
significant upgrade or a new version release of Struts: it's a complete
reworking of many of the core principles of Struts, along with the newest thinking in Web development.
As you'll learn in this five-part series, Shale's departure from Struts is a double-edged sword. On the one hand, Shale is an extremely well-thought-out heir to the legacy of Struts. Shale's creators have taken into account both the weaknesses and the strengths of the Struts framework and come up with a next-generation framework worthy of its predecessor. On the other hand, as you'll begin to see very quickly in this series, Shale is a completely different framework from Struts, with all the new development work that implies!
Rather than being just another revision of Struts, Shale expands well
beyond the reach of Struts. It encompasses and builds on some of the
most important recent developments in Java Web programming, including
the JSP Standard Tag Library (JSTL) and JavaServer Faces (JSF). Shale
fully deserves consideration as a separate framework from Struts, and in
this series, I'll give the framework its due. I'll start this month with
an overview of what differentiates Shale from Struts and then walk you through
the steps of installing Shale and testing your installation. I'll conclude with some ideas for getting more involved with the Shale project (which is open
source), as well as practical information for doing so. Throughout this series, it is my goal to show you how to install, build, and develop for Shale with little reference to its predecessor, the Struts framework.
|
And I name you...Shale!
You should see the Shale Web site (see Resources) for a short but complete write-up on the origins of the Shale mind. In a nutshell, though, the name Shale comes from the idea that Web frameworks function best as loosely connected "layers" of functionality. Each layer is largely independent of the others and has a very specific focus. The analogy was drawn from this idea to the layers you'll find in a geological deposit, which around coastlines are made up largely of shale -- and thus the new framework was named!
|
|
Evaluating Shale
Any new Web development framework that tries to squeeze into what is, by now, a pretty packed space had better be able to withstand tough evaluation. The good news about Shale is that it holds up under scrutiny, and it does so on its own terms. The bad news -- maybe -- is that, because Shale truly is a complete re-working of Struts, you're going to have to rework, retest, and rewrite all of your Struts code in order to implement it. You'll put as much work into writing a new Shale application, or converting a Struts application to Shale, as if Shale had nothing at all to do with Struts.
So the next intuitive question is, why adopt Shale? To get to the answer, I'll first explain what makes Shale great -- largely, but not only, the legacy of Struts -- and then discuss the two major reasons why it isn't being released as a major revision of the Struts framework. That will give you a better idea of what you're actually getting from Shale, and it will help you evaluate whether it's worth making the jump to this next-generation framework.
The legacy of Struts
Shale reuses a lot of the Struts codebase and claims Struts as its
"parent" framework, so you need to be convinced of the value of Struts
if you're going to believe in the value of Shale. First and foremost,
Struts has tremendous value as one of the first true Web development
frameworks. The Shale and Struts Web site reports that the first
code was committed to the Struts CVS repository in June of 2000, and
Struts 1.0 was released in late 2001. At a time when many developers
were struggling to get their heads (and hands) around JavaServer Pages (JSP)
and the evolving servlet specification, Struts offered an easy-to-use,
Model 2 approach to building servlet- and JSP-based Web applications. In
other words, Struts gave Web developers the ability to develop robust
Web applications without having to be adept in logging, distributed
computing, JDBC, Servlets, JSPs, JNDI, RMI, and a whole host of other
APIs and acronyms.
The next thing Struts has going for it is staying power: Almost six
years since those first lines of code were written, Struts remains one
of the most popular Web development frameworks. It's still talked about,
written about, and used as much as any of its newbie competitors, and
more so than most. Because of its popularity and longevity, Struts is
full-featured, well-documented, well-supported, and easy to use, develop
on, and manage. Thousands of developers respond to queries on the Struts
mailing lists, and tens of thousands have tried out Struts and reported
problems, thus allowing them to be easily fixed.
Finally, Struts has evolved. While many frameworks start strong and then
largely stagnate (this is true of commercial products as well as open
source ones), Struts has continually offered new features. When you
download Struts, you get a robust validation engine as part of the core
distribution, easy integration with JavaServer Faces, extensive tag
libraries, and an evolving Model 2 architecture that brings with it the
latest thinking in the area of distributed n-tier applications. And, just in
case you were wondering, Struts has also kept up with new paradigms in programming like IoC (Inversion of Control). Struts naturally integrates with WebWork and the Spring framework, both best-of-breed offerings that provide easier entry into new approaches to Web development.
In short, you'll be hard pressed to find something you can't
do or find support for in Struts. So the next obvious question is, why is Shale starting over? Why isn't Shale just the next version of Struts? Two major reasons come to mind: one has to do with the little-understood truth about new software releases, and the other has to do with a well-known weakness
in the foundations of Struts. Let's consider them both.
Review, revise, revisit, release
To appreciate why Shale isn't just a new release of Struts, you need to first understand a thing or two about new software releases. Most users look to a new software release for a new set of features. The larger the version jump from the last release, the more new features users expect. So software moving from 2.1 to 2.2 should have some new features, but software moving from version 2.2 to 3.0 should have a lot of new features. This is why new versions and releases of huge products like Microsoft Word or operating systems like Windows and Mac OS X are under such close scrutiny; users demand a growing set of features with each new release.
With all this attention going to features, most users don't realize that backward compatibility is what they really value most. While everyone wants a cool new option in Excel, greater integration with iTunes in Panther, or better support for XUL in Gnome, all those users would scream bloody murder if their existing programs and files suddenly aren't usable on the newer versions. And in that case, new features aren't worth a thing.
The same is certainly true with Struts. For the most part, each new version of Struts has added new features while maintaining backward compatibility with previous versions. Additionally, it's been required to support older versions of the Java platform and the Servlet specification because older installations are running on those platforms. Both of these requirements -- backward compatibility and support for older versions of the Java APIs -- would have been a serious constraint on Shale. In particular, the JSF API has become a central piece in the evolving Web, at least as far as the Java platform is concerned. While Struts supports JSF, Shale depends entirely on it -- something simply not possible for Struts to do while still maintaining backward compatibility.
Finally, spawning a new project like Shale while also keeping development active on an existing project like Struts has distinct advantages. If Struts did simply move to a new 2.0 (or 3.0, or 4.0) version and implement the Shale functionality without regard to backward compatibility, the migration would be painful to many, and others would simply stop using Struts altogether. Even if the older codebase was maintained, it would be very difficult to get developers to spend time fixing bugs and adding even minor features to a "deprecated" or "old" version of the software.
For all these reasons, it makes sense that Shale is a completely new project, building on a fresh codebase.
Shale's service-oriented architecture
The final reason Shale isn't just a new release of Struts has nothing to do with logistics: it has to do with the framework's ability to embrace new approaches to Web development. Shale differentiates from Struts in many significant ways, but two stand out:
- Struts integrates with JSF, while Shale is built upon JSF.
- Struts is essentially a giant, complex request processor; Shale is a set of services that can be combined in any way you like.
The implications of Shale's dependency on JSF are significant and, surprisingly, for the most part positive. I'll delve into some of them
as I get deeper into the series. The second of the two differentiating factors is worth discussing in some detail before I move on.
If you've used Struts much, you realize that it's is largely a request processor, allowing you to receive requests and instruct the framework how to process each request. You can indicate which action to take, what model to use, which view to display to the user, what validation rules to employ, which forms to display ... Struts is totally configurable. However, at the core of all this is a request processor that runs, servicing each request. That processor is the most important -- and most complex -- part of Struts because it must either handle or delegate essentially every portion of handling a request. There is almost nothing in the Struts code base that doesn't touch or isn't affected by the request processor.
As a result, Struts can be hard to change in any fundamental way. If you want to dramatically alter how requests are processed or the order in which parts of a request are handled, you've got a daunting task: you have to essentially rewrite the Struts code base. Changing the request processor's behavior is mildly extensible, but for the most part, it's a closed system. This is one of the key problems (if you need that degree of flexibility in your Web framework, at least) that Shale attempts to solve.
Rather than having a central component like the Struts request processor, Shale is simply a large set of services. You can combine these services in almost any way you can dream up, and each service is loosely coupled with the others. Using a well-defined set of interfaces (which are sometimes actual Java interface classes and sometimes simply contracts between components to act in a certain way), it's easy to reconfigure how Shale behaves. This makes it extensible, flexible, and even "nimble." You can change it easily, extend it almost effortlessly, and adapt it quickly to new programming approaches. A loose assembly of components or services like this is often referred to as a service-oriented architecture, or SOA. Sure, that's a bit of a buzzword, but you really shouldn't hold it against Shale!
Installing Shale
You can understand Shale's differentiation from Struts logistically
and conceptually, but to really get your head around the difference
between these two great frameworks, you need to get your hands dirty. As unexciting as it is, every Web framework begins with a
download and an install. The good news is that there's usually a lot to be learned from this process. Projects and products that are a pain to install
and set up are often also a pain to configure, to deploy to, and
(worst of all) to keep up and running. While the installation
process is hardly a definitive means of evaluating a Web framework, it
certainly should be part of the criteria. In this section, you'll learn
to manually install Shale, get a feel for some of the rough spots, and
find out exactly what you'll need on your system to get Shale
running.
Note that I also cover the easy install option for Shale, but I strongly
encourage you to at least review the manual install for the depth of
information it provides.
Prerequisites
The list of prerequisites and requirements for Shale is fairly extensive. As is the case with most Apache- and Jakarta-related projects, Shale's install is dependent on several other Jakarta projects. Here's the complete list of things you'll need to get Shale running:
- Java Runtime Environment (JRE) and Java Development Kit (JDK) 1.4 or later
- Java Servlet API 2.4 or greater
- JSP 2.0 or later
- JSF 1.1 or later
- JSP Standard Tag Library (JSTL) 1.1 or later
- Jakarta Commons BeanUtils 1.7 or later
- Jakarta Commons Chain 1.0 or later
- Jakarta Commons Digester 1.7 or later
- Apache Logging 1.0.4 or later
- Apache Ant 1.6.3 or later
Apache Ant is only used in building Shale, but you'll want (and probably have) a version of Ant on your system if you're doing much Java development anyway. If you want to track bugs in Shale, you'll need FindBugs 0.8.5 or later and JUnit 3.8.1 or later. Because I'm focusing in Part 1 on installing and using Shale, you don't need to worry about FindBugs or JUnit yet, unless you simply want to add these projects into the mix early.
Add-ons and their dependencies
As is the case with Struts, there are several add-ons (often called optional Shale components in the Shale world) that have some dependencies of their own:
- Jakarta Commons Validator 1.2 or later
- The Spring Framework 1.2.2 or later
- The Struts Tiles Framework (in its stand-alone version)
If this list looks a bit long and daunting, it is! Shale uses a lot of lower level libraries, helper classes, utility components, and classes from other projects. If you had to individually download each of these components, configure Shale to work with each, and assemble the whole into something you could deploy, only the most dedicated developers would ever give Shale a second look. Additionally, because Shale is still fairly young in its development cycle, the process for getting these dependencies and configuring them is still a little raw; however, it's very workable and doesn't require as much additional effort as you might think.
|
Welcome to the cutting edge!
If you've never worked with an open source project before, or if you have only worked with open source projects in fairly stable and mature versions, downloading a nightly build might make you a bit nervous. While there's nothing radioactive or inherently dangerous with nightly builds, they certainly are a little more volatile than the release downloads available for more mature technologies and projects.
Consider that most nightly builds are automated; at a certain time each day, these builds are created from the current source code tree for the project. Even if some developer is ironing out a massive bug in the code, the nightly build process still happily creates a new snapshot of the code and posts it online for worldwide download. This means that a build today might work great, and one from tomorrow might crash horribly. So be careful with nightly builds and exercise a little patience. If something doesn't work with the build you have, it might very well be fixed in tomorrow's build. This is cutting-edge development, so a few bumps in the road are natural.
|
|
First, if you're looking at doing any kind of Web development -- with any framework -- you should already have several of these dependencies in place. So this list is a lot more manageable than it first appears. For example, any Web developer should already have a JRE and a JDK, as well as a servlet engine, like Jakarta Tomcat. If you've got a servlet engine, then you should have the Servlet API, as well as a JSP engine. Add to that the fact that most servlet engines -- at least the most current versions of them -- include a copy of the JSTL, and many now come with JSF as well. And, finally, most developers probably already have Ant on their machines. So the list quickly gets pared down to just this:
- JSF 1.1 or later (maybe; it might come with your servlet engine)
- JSTL 1.1 or later (maybe; it might come with your servlet engine)
- Jakarta Commons BeanUtils 1.7 or later
- Jakarta Commons Chain 1.0 or later
- Jakarta Commons Digester 1.7 or later
- Apache Logging 1.0.4 or later
Considering that Tapestry actually makes all its dependencies available as an additional download, the "too many dependencies" problem quickly becomes a non-problem.
Now that you've got the big picture, let's go through the steps to download, install, and configure Shale and its dependencies.
1. Download Shale
To download Shale, visit the Shale project home page. You'll find a "Shale Download" section with links to nightly builds of the Shale framework. Clicking on this link will take you to a site that looks something like Figure 1:
Figure 1. Nightly builds from the Shale CVS repository
To get Shale running, you should download both the "framework" file and the "dependencies" file. For example, as of this writing, I downloaded two files:
- shale-framework-20060204.zip
- shale-dependencies-20060204.zip
Obviously, if you need or prefer to download the .tar.gz version, select that instead of the .zip version. Because work is ongoing with Shale and there aren't yet release builds, you should try to download the latest nightly build (with the most current date).
Once you've downloaded these two files, extract both archives. For the core framework, you'll end up with a folder named something like shale-framework-20060204/, and for the dependencies archive, you'll get a folder named lib/. Move the core framework directory -- shale-framework-20060204/ -- to where you like to keep your Java projects. On my system, for example, I moved shale-framework-20060204/ into my /usr/local/java directory. Next, move the lib/ directory into your Shale directory, so you end up with something like shale-framework-20060204/lib/.
2. Add the Shale libraries to your Web app
Your next step is to add all the Shale JAR files and libraries into a location where your Web application can access and use them. Here are the steps you should take:
- If you don't have a JSF installation in your servlet engine, copy shale-framework-20060204/lib/jsf-ri/jsf-api.jar and shale-framework-20060204/lib/jsf-ri/jsf-impl.jar into your application's WEB-INF/lib directory.
- Copy shale-core.jar, shale-clay.jar, shale-tiles.jar, and tiles-core.jar from your shale-framework-20060204/dist/ directory into the WEB-INF/lib directory of your Web application.
- Copy the following Shale dependencies into your Web application's WEB-INF/lib directory:
- shale-framework-20060204/lib/commons-beanutils/commons-beanutils.jar
- shale-framework-20060204/lib/commons-chain/commons-chain.jar
- shale-framework-20060204/lib/commons-digester/commons-digester.jar
- shale-framework-20060204/lib/commons-logging/commons-logging.jar
- shale-framework-20060204/lib/commons-validator/commons-validator.jar
- If you want to use Shale's Spring-integration features, copy shale-spring.jar from shale-framework-20060204/dist/ into your Web application's WEB-INF/ directory. If you follow this step, you must also be sure that the Spring all-in-one JAR file is also in your Web application's WEB-INF/lib directory. This JAR file, called spring.jar, is in the shale-framework-20060204/lib/shaleframework/ directory if you don't already have it.
- If you're running Java 5.0, copy shale-tiger.jar from shale-framework-20060204/dist/ into your Web application's WEB-INF/lib directory. Only take this step if you're running Java 5.0; otherwise, your servlet engine and any Web applications using Shale will have problems.
At this point, things start to get more complicated (yes, all that
copying was the easy part). Rather than continue to do everything the
hardest way possible, however, I should at least give you the
option to take the easy way out. Indeed, there is an easier path to
getting Shale up and running on your system; now that you have some
idea of the complexity involved in manually setting up Shale, it's worth
looking at this "shortcut" approach.
The easier way
Revisit the Shale download site and download the "starter" application, named something like shale-starter-20060204.zip. Expand this archive, and you'll get a directory called shale-starter/. This is a mostly-configured Shale Web application and is designed to help you avoid all the copying and configuration detailed in the last section. The first thing you should do is rename the shale-starter/ directory to what you want your application to be called; you could use first-shale/, for example. Go into the first-shale/ directory, and you'll see several files and subdirectories.
In your first-shale/ directory, create a new file called build.properties. This file allows you to customize how the Shale starter application builds and ensure it is set up for your environment. Listing 1 shows a basic build.properties file that you can easily customize for your environment"
Listing 1. Sample build.properties for the Shale starter application
# Basic project information
project.copyright=My project, Copyright © 2006
project.name=My First Shale Application
project.vendor=IBM DeveloperWorks
project.vendor.id=com.ibm.dw
# Java package and context path for servlet engine
project.package=com.ibm.dw.firstShale
project.path=first-shale
# Directory for Shale distribution - change this for your system
shale.dir=/usr/local/java/shale-framework-20060204
# Directory for all your libraries - change this for your system
lib.dir=/usr/local/java/shale-framework-20060204/lib
|
Once you've got these properties set up for your system, you can simply run ant. The Shale starter app begins to build and (assuming you've set up your paths correctly) creates a sample application for you. If there are problems, the build script outputs an error message; these are very descriptive, so you shouldn't have any problem correcting any errors.
At the end of the build process, you'll have a new directory called target/. Navigate into this directory, and you'll see a sub-directory, named first-app (or whatever you specified in build.properties as the name of your project). Most servlet engines let you copy this entire directory structure into the webapps/ directory for that servlet engine. For example, using Tomcat, I copied the entire first-shale directory that the build script created into /usr/local/java/tomcat/webapps.
Building a WAR file
If you're using a servlet engine that requires you to provide WAR files, you can use the same Shale starter application's build file, with a slight modification. Because you haven't written any Java files for the Shale application yet, the build script errors out when you request a WAR file (the JavaScript command in build.xml looks for files, but doesn't find any). To fix this problem, open up build.xml and look for a line that starts with "javadoc" and looks like this:
<!-- ===================== Generate Documentation ======================== -->
<target name="javadocs" depends="compile"
description="Create JavaDocs">
<mkdir dir="${build.docs.dir}"/>
<javadoc
sourcepath="${src.java.dir}"
destdir="${build.docs.dir}"
author="false"
private="true"
version="true"
source="${project.source}"
packagenames="${project.package}.*"
windowtitle="${project.name} (Version ${project.version})"
doctitle="${project.name} (Version ${project.version})"
bottom="${project.copyright}">
<classpath refid="compile.classpath"/>
</javadoc>
<copy todir="${build.docs.dir}">
<fileset dir="${src.java.dir}"
includes="**/*.gif"/>
</copy>
</target>
|
Now, just comment out the javadoc task, like this:
<!-- ===================== Generate Documentation ======================== -->
<target name="javadocs" depends="compile"
description="Create JavaDocs">
<mkdir dir="${build.docs.dir}"/>
<
<javadoc
sourcepath="${src.java.dir}"
destdir="${build.docs.dir}"
author="false"
private="true"
version="true"
source="${project.source}"
packagenames="${project.package}.*"
windowtitle="${project.name} (Version ${project.version})"
doctitle="${project.name} (Version ${project.version})"
bottom="${project.copyright}">
<classpath refid="compile.classpath"/>
</javadoc>
-->
<copy todir="${build.docs.dir}">
<fileset dir="${src.java.dir}"
includes="**/*.gif"/>
</copy>
</target>
|
This is a bit of a hack, and you won't need to do it once you start developing Java code for your Shale application. For now, though, it gets the job done. Save your modified build.xml and run ant dist. Ant compiles and assembles your starter application and creates a new WAR file in the dist/ directory. For example, I ran ant dist and ended up with dist/first-shale-0.1.war. Now you can copy this WAR file into your servlet engine's webapps/ directory.
Testing your installation
If you've followed along so far, regardless of which installation path you've chosen, you should be able to start your servlet engine and access your Shale application at http://your.host.name/first-shale. Running Tomcat on a local machine, for example, you'd end up with http://localhost:8080/first-shale. If everything is working correctly, you should see a simple page similar to Figure 2:
Figure 2. The Shale starter application proves things are working correctly
Now, all that might seem like a lot of work for a little gain, but consider that by opening and editing a simple build.properties file, you were able to avoid a lot of tedious copying and configuration. You'll find that starting with the blank Shale starter application is almost always the easiest way to start working on a new Shale application. In fact, when you begin developing Shale applications in the next article, you'll use the blank starter application as a starting point.
The Shale use cases
That's almost it for the download and installation, but take a moment to download the Shale use cases WAR application, available from the main Shale download site. Look for a file named something like shale-usecases-20060204.war. Download this WAR file and drop it into your servlet engine's webapps/ directory, and then navigate to the WAR. On my system, I went to http://localhost:8080/shale-usecases-20060204/ and got the screen shown in Figure 3:
Figure 3. The Shale use cases application
You should take some time to look around the use cases application; it has some nice demos of features like the Validator and remoting support in Shale, as well as a simple Ajax application. You can get some ideas about what even simple Shale applications are capable of by browsing these use cases.
That said, a warning is in order: Some of the use cases are still being worked on, and depending on when you download your nightly build, you may find some use cases that aren't quite working. You can always download the use cases application again later and see if something has been fixed. Even with these small problems, the use cases application is a nice way to get a basic feel for Shale.
Get involved with Shale!
Most Web developers never go beyond using existing frameworks (like Shale, Struts, or Spring) to develop their Web applications. There's certainly nothing wrong with that approach, but if you want to understand a framework -- and the technologies it engages with -- there's really no substitute for going deeper into the framework itself.
In the case of Shale (and by extension, Struts), you'll learn more about servlets and Web development than you could ever imagine by actually checking out the framework internals. This is also incredibly helpful if you want to use some of the Shale dependencies in your own projects. If you're interested in logging from your Java application, working on Shale will acquaint you with the Apache Logging project far more effectively than any article would. The same is true for working with the Jakarta Commons BeanUtils, Chain, or Digester projects. All of these are great tools and useful to any Web developer, so spending a few weeks or months tinkering with Shale is a great learning experience in these areas.
Because this article is the first installment in an in-depth series about Shale, I'd be remiss if I didn't discuss the points of entry (and some of
the hurdles) to getting involved with the Shale project.
|
Additional dependencies
I've already mentioned that if you want to work with Shale yourself, on a code-level, you'll need to have a copy of Ant as well as the FindBugs project and the JUnit testing framework. Despite some of the misnomers about open source projects being disorganized or unprofessional, you'll find that every bug, issue, and feature related to Shale development is logged in a FindBugs database, and every bit of code checked into the Shale Subversion repository must be tested.
|
|
Go to the source (where's the source?)
Unfortunately, there isn't much in the way of documentation on the development processes involved in Shale, so you'll have to use a little ingenuity if you want to work directly with the Shale source code. For the most part, the instructions I detailed for downloading Shale to use it as a framework also apply to downloading Shale's source code. The nightly builds contain all the source code for Shale, and each directory of code has a build.xml file within it.
You'll need to copy the build.properties.sample file in the root of your Shale download to a file called build.properties (remove the ".sample" on the end of the original filename), and modify this file for your system. Listing 2 shows what the sample version of this file looks like, with many of the comments removed for brevity:
Listing 2. Sample Shale build file
# This file contains example property settings that you would use to customize
# your build environment to build the Struts Shale Library from
# source code. To use this file, make a copy of it in "build.properties" and
# customize the values as required.
# Root directory into which you have unpacked the Shale Framework release.
root.dir=${basedir}
# Fully qualified pathname of the directory into which you have unpacked
# a binary distribution of the JavaServer Faces Reference Implementation
jsfri.dir=/usr/local/jsf-1_1_01
findbugs.outputFile=${root.dir}/find-bugs.html
lib.dir=${root.dir}/lib
jsf.home = ${lib.dir}/myfaces
jsf-api.jar = ${jsf.home}/myfaces-api.jar
jsf-impl.jar = ${jsf.home}/myfaces-impl.jar
# The absolute or relative pathname of the Apache Struts
# distribution
struts.home = /usr/local/jakarta-struts
spring.home=${lib.dir}/springframework
findbugs.home = /usr/local/findbugs-0.8.6
|
|
MyFaces or JavaServer Faces?
MyFaces is an open-source Apache project. It's an implementation of the JSF API from Sun, but it has all the openness and benefits associated with the Apache Foundation's other Java projects. You can use MyFaces as a drop-in replacement for Sun's JSF reference implementation, and MyFaces is the preferred JSF implementation for use with Shale.
|
|
You'll need to change most of the paths in this build file to match your system. ${basedir} defaults to the directory in which you run Ant from, so if you're running Ant from the root directory of your Shale download, you're in good shape there. You should replace the other paths with ones appropriate to your system though. For example, if you have the JSF reference implementation in c:/java/jsf-1_1_02, then use that value for the jsfri.dir directory. Most of the default paths are geared toward using MyFaces (see "MyFaces or JavaServer Faces"), but of course you can use Sun's JSF implementation and change these paths accordingly. You'll also need to set the path for Struts, Spring (which is optional and not required for the core Shale framework), and the FindBugs project.
Ant is on task
Once you've set this file up correctly, you can run Ant in the root of your Shale download. First though, you should run ant download-dependencies. As you've surely noticed, Shale has a lot of dependencies, and using Ant to automate downloading those dependencies saves you a lot of time and frustration. The Ant script also handles setting up the paths connecting Shale to those dependencies. You should also run ant copy-jsf-ri to handle some JSF-specific tasks (the details really aren't relevant, as Ant takes care of this for you).
Before you build the main Shale release, you should run ant clean to remove any preexisting built code. While this means your overall build time will be longer, it ensures all your code will build consistently. Finally, run ant release, which builds Shale from scratch. Once this Ant script finishes (it takes a little time), you'll have a complete Shale distribution built from source.
A word about lists
Open source projects function almost wholly through e-mail (with the addition of the Apache bug tracking database, which you'll find in the Resources section). Shale isn't different in this regard, although it still uses the Struts mailing lists. For questions related to using Shale, you should send an e-mail to user@struts.apache.org. Once you start developing the actual Shale internals, though, you should send e-mail to dev@struts.apache.org. In both cases, preface your subject lines with "[shale]" so it's clear you're asking Shale-related questions, as opposed to Struts-related questions. Expect Shale to have its own mailing lists in the months ahead as it begins to move toward being an independent project of its own.
A mild word of caution is in order, particularly when sending e-mail to the development list: do your homework and stay on point. E-mails that are wandering, vague, or show a lack of thought are often not received well. You're also likely to get a rude response if you send an e-mail anywhere along the lines of "I want to learn Shale, please send me some example applications." While this might seem a silly caution, it's warranted; development lists are always inundated with spam and requests like this, and they're not appreciated. In general, take the time to carefully formulate your question, explain what platform and versions of software you are using, and reflect that you've tried the obvious steps. Your request will be met with respect and appreciation, and answers to the request will reflect that. The developer's list is nothing to be afraid of, but it is something to show respect for.
In conclusion
If this first installment in my series on Shale has revealed anything, it's that Shale isn't for everybody. With Shale, you're definitely not getting a shrink-wrapped, well-documented, well-tested product complete with an automated installer and polished management interface, which is what many Web developers have come to expect in the age of Tapestry. While all of these things -- with the exception of the shrink-wrapped box -- may show up in a later version of the framework, today's Shale (as of early 2006) is a work in progress, and the Shale site refers to it as largely an "alpha"-state project. Many of the components it uses are stable and mature, but Shale itself is still very young. If you're not comfortable working through a little pain and confusion, you might want to wait another year or so before picking it up.
On the other hand, if you're a Java developer interested in staying on the leading (some might say bleeding) edge of Web development, then you really should check out the Shale project. It's a bit rough around the edges and will certainly take some extra effort to get set up and working correctly, but it has all the makings of an exceptionally popular Web development framework. Shale truly does build on the legacy of Struts while offering something completely new, and for that alone, it's worth investigating. Shale is also a worthy investment for more seasoned or adventurous developers interested in being part of an open source project.
If you are ready to take the the plunge, there's a lot more to this series than the installation and basic setup I've discussed here! In the next article, I'll explain the principles behind Shale and how they apply to writing Shale applications. You'll also get a guided tour of the Struts starter application and learn how to use it as a launch pad for your own applications. So roll up your sleeves a bit and come back next month for more on Shale.
Resources Learn
- "JSF for nonbelievers: Clearing the FUD about JSF" (Richard Hightower, developerWorks, January 2005): An in-depth look at the strengths and weaknesses of JavaServer Faces, one of the foundations of Shale.
- "Service-oriented modeling and architecture" (Ali Arsanjani, developerWorks, November 2004): Get a relatively buzz-free overview of the service-oriented architecture paradigm.
- "In tune with Tapestry" (Brett McLaughlin, developerWorks, January 2006): Learn more about Tapestry, one of the new-breed of user-friendly Web development frameworks (two parts).
- "Integrating Struts, Tiles, and JavaServer Faces" (Srikanth Shenoy and Nithin Mallya, developerWorks, September 2003): An interesting peek at life before Shale.
- The Shale homepage: Find javadocs and additional framework information about Shale.
- The Struts homepage: The predecessor of Shale is a well-used and extensible Web development framework in its own right.
- Bugzilla: Find current information on the status of particular bugs or features in Shale at this Apache bug tracking Website.
- The Java technology zone: Hundreds of articles about every aspect of Java programming.
Get products and technologies
-
Download Shale: Find it on the Apache Jakarta Website and get started!
-
Apache Tomcat: A great servlet engine that works perfectly with Shale, as well as Struts.
- Jakarta Commons BeanUtils: Provides handy utility classes for working with classes that are in the JavaBeans naming format.
- Jakarta Chain: A Java-based component set that implements the Chain of Responsibility design pattern, allowing commands or components to be "chained" together without being dependent on each other.
- Jakarta Digester: Enables easy mapping from XML to Java, making it possible to simply read configuration and property files that are represented as XML.
-
Apache Logging: Logging services for different programming languages, including C++, Java, Perl, PHP, and PL/SQL.
- Apache Ant: A Java-based build tool used to build Shale.
Discuss
About the author | 
| | Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java technology and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. His most recent book, Java 5.0 Tiger: A Developer's Notebook, is the first book available on the newest version of Java technology, and his classic Java and XML remains one of the definitive works on using XML technologies in the Java language. |
Rate this page
| |
