Abstract
The purpose of “Online Library Remote Access through Proxy Server” project is to build the
web application which will allow to login into the application with given username and password
and access online repositories with IP restrictions. This project was initiated by American University
of Armenia in order to let the students and faculty members to use library materials from abroad
of campus. During implementation “Online Library Remote Access through Proxy Server” was given
name Armenian Virtual Science Library (AVSL). The AVSL is a gatekeeper and a director for
information; it sits between the Publishers (Information Resources) and the user. This work shows
how to integrate various products to build Virtual Library that purchases the expensive licenses to
access the Publishers resources and provide these resources freely to the students and
researchers. In this system the LDAP directory server is used to keep user information; in the
system could be three groups of users each one with a specified role (none, administrator, and
editor). The web technologies used to create the AVSL system are: - the Sun Java Application
Server, Open LDAP Directory Server, MySQL Database Server, EZProxy Server, the NetBeans IDE
which is used to edit and compile the program, the J2EE J2SE Java Technologies are used for
creating the dynamic web program (These Java technologies are: - JDBC used to access the
relational Database, JNDI used to access the Directory Server, XML, Servlets, JSF, Java Beans). We
used open source e-science-library4 project and integrated with EZProxy commercial pass-through
proxy server. The result of this work is to put and configure AVSL project on AUA servers and give
access to students to use purchased virtual libraries
1
Contents
Abstract ............................................................................................................................................................... 1
Contents .............................................................................................................................................................. 2
1.
Introduction ................................................................................................................................................ 4
2. Problem description and research .................................................................................................................. 7
2.1. Detailed description of the problem ........................................................................................................ 7
2.2. Research ................................................................................................................................................... 9
2.2.1 VPN Access ......................................................................................................................................... 9
2.2.2 Proxy Servers .................................................................................................................................... 10
2.2.3 Pass-Through Proxy Servers ............................................................................................................. 13
2.3 Decision ................................................................................................................................................... 18
3. Implementation............................................................................................................................................. 19
3.1 AVSL Use Cases........................................................................................................................................ 20
3.1.1 Use Case actors ................................................................................................................................ 21
3.1.2 Use case descriptions ....................................................................................................................... 21
3.2 Application Components ......................................................................................................................... 30
3.2.1 User database................................................................................................................................... 30
3.2.2 Portal Security .................................................................................................................................. 31
3.2.3 Access to remote resources ............................................................................................................. 31
3.2.4 News database ................................................................................................................................. 31
3.3 Application design ................................................................................................................................... 32
3.6 EZProxy Design ........................................................................................................................................ 33
3.7. System configuration ............................................................................................................................. 34
3.7.1 Sun Java System Application Server Configuration .......................................................................... 34
3.7.2 LDAP configuration........................................................................................................................... 38
2
3.7.3 EZproxy installation and configuration in Solaris 10 ........................................................................ 39
3.8 JSF Web Pages Navigation Work Flow .................................................................................................... 41
3.9 The Resulting JSF Web Pages .................................................................................................................. 42
4. Conclusions................................................................................................................................................... 46
5. Suggestions for Future Work......................................................................................................................... 47
6. References ..................................................................................................................................................... 48
Appendix A ........................................................................................................................................................ 49
Appendix B ........................................................................................................................................................ 53
3
1. Introduction
By growing day by day virtual libraries become more popular and expensive and it’s more
than necessary for researchers to have access to those libraries. Universities all over the world buy
the access to their students and faculty to use those virtual libraries but they have IP restrictions
and usage of bought materials could be done only within campus buildings. So IP restrictions do
not allow faculty and students of widespread universities to have access to virtual resources.
There are varieties of ways to solve this problem such as: set up public proxy (with
authentication or not) or to have engine which will work between user and library server and will
create illusion for the user who will think that he use university material and for the virtual library
server which will think that request comes from the IP for which access is granted.
American University of Armenia is one of the universities that have faculty members who
work abroad Armenia and need to have the access to virtual libraries that bought for compass.
Therefore AUA initiated the “Online Library Remote Access Through Proxy Server” project.
The purpose of the project is to build the web application which will allow to login into the
application with given username and password and access online repositories with IP restrictions.
Growing with WWW, virtual libraries become more popular and irreplaceable for
researchers. The bigger virtual libraries like “ACM Digital Library” or BioMed Central are
commercial and giving the access by physical location (by IP address).The library of American
University of Armenia buys the licenses and give access to students, faculty and staff of AUA to use
those libraries. But the problem is that materials are accessible only within campus building. Now
Library administration wants to increase given services and have the system which will give users
access to anywhere through internet.
So aim of “Online Library Remote Access Through Proxy Server” project to solve the
problem and create new online library remote access service for AUA library and the requirements
for implementing “Online Library Remote Access through Proxy Server” project were the following:
4

To have the system which will give the access bought virtual libraries from anywhere to
all students and faculty

The system will work on existing Sun Fireware hardware with Soloris 10 operating
system installed on it

There should not be any client-side installation or setup to work with the system

The system should be less expensive and use well known technologies to simplify
further development and management
We call the built system Armenian Virtual Science Library (AVSL). AVSL needed to meet
mentioned above requirement and research showed that best solution will be web based
application with “Pass-Through Proxy” strategy. For AVSL we chose EZProxy as “Pass-Through
Proxy” implementation and e-science-library web based project for application that will manage
EZProxy. To have maximum performance we decided to put the system in Solaris operating system
in Sun fireware machine, but for further development and testing we chose Windows platform. Escience-library is open source, web based Java application, which is implemented using one of
known java web frameworks, JSF, and as application server in which the system will work on is
decided to be Sun Java Application Server integrated with MySQL database management system
and as user authentication server was integrated Open Directory Server. The application is
available in any known browser without any user configuration need.
The Armenian Virtual Science Library is the best solution for the AUA’s library needs. This
can be used for purchasing the expensive licenses of electronic information resources from the
Publishers and provide them freely to the students, faculty, etc. It is integrated with Directory
Server for authenticating users using which system gives appropriate roles to users and control
system security. The system integrated with EZProxy as “Pass-Through Proxy” strategy to give
access to publishers’ resources with IP restrictions. It also has user friendly look and feel and
therefore simple for users to access, at the same time east for developers to update existing code
and deploy in any operating system.
So AVSL system will be based on Sun Microsystems hardware and is intended to be
deployed in AUA and managed locally. The idea is to set up the application based on J2EE
technology, with one of famous frameworks Java Server Faces, which will make system to be more
5
understandable and simplify further development and management. To increase security AVSL
integrated with LDAP server and MySQL chosen as DataBase management system. Figure x displays
the components and connected tools of AVSL application.
6
2. Problem description and research
In this chapter we will describe the stated problem and requirements and research to find
the solution to given problem.
2.1. Detailed description of the problem
Just two decades ago, access to vital university information resources was largely a matter
of physical proximity: You had to be nearby, or make frequent trips, in order to do serious
academic writing and research. In particular, to gain access to serials, papers, monographs, and
other core research materials you had to present credentials in person at the library-usually in the
form of a university ID.
As information resources have made their way onto the Internet, and in particular onto the
Web, however, physical proximity has taken on an increasingly secondary role. To reach Webbased information resources today all one needs is a computer with a Web browser and some sort
of Internet feed.
The increasingly secondary role played by physical proximity has created a critical problem
for university communities and for their core information resources. If physical presence is no
longer necessary, i.e., if someone can "knock at the door" without actually being at the door, how
can we tell whether to let him or her in? How can we tell if the person knocking is a member in
good standing of our community? How can we grant him or her access without accidentally letting
anyone else in?
If you belong to a university, computer support, or library reference department, you have
struggled with these sorts of questions. Librarians, in particular, will have struggled through
scenarios like the following:
7
Scenario 1:
Adjunct medical-school professor takes up a practice in a university-affiliated clinic. He
turns on his new office computer, logs in via the clinic's Internet service provider (ISP), then goes to
his university's BioMed web site, where he expects to find the Web version of Medline (to which
his university subscribes). Instead of seeing a list of available databases he finds himself bounced to
a username/password screen that he has never seen before--and for which he has no username or
password.
Scenario 2:
Professor leaves on vacation to do research on eighteenth-century English scientific
terminology. She settles into her cabin in upstate Maine-only to discover that when she tries to
access the online Oxford English Dictionary, which she has been accustomed to using for complex
search and retrieval operations from her campus office, the server on which the OED resides
rejects her connection, offering instead a cryptic sign-in screen.
Scenario 3:
Computer support staff personnel report that the number of students, staff, and faculty
coming in via the modem pool at night has tripled in the last two years, and that the university
must either expand its dial-in facilities, or else farm out this service to another ISP. Preliminary
figures indicate that it would be significantly less expensive to farm the service out. Users revolt,
however, when they are told that key library databases will no longer be accessible from offcampus under this arrangement. The support staff revolts when they hear that the only way to
make these databases available is to outfit all remote machines with special client software and
plug-ins. Professors revolt when they realize that the client software and plug-ins cannot easily be
installed on other universities' machines, or on kiosks available to them while they are away on
sabbatical or at conferences.
8
Those are problems that face thousands of universities around the world including
American University of Armenia. Many of AUA Faculty members mainly work abroad Armenia and
can’t have access to libraries American University buy.
2.2. Research
During requirement analysis and design there was done research to find possible solution
to given problem that used in other universities around the world. There were 3 major solutions
that can be used to solve given problem: Access through VPN, Access through standard proxy and
pass-through proxy. Here are detailed description of each solution.
2.2.1 VPN Access
A final remote-access solution that has just started being deployed on a large scale is the
virtual private network (VPN). VPNs let people using machines outside your LAN make these
machines look just like units inside your LAN. They do this by creating a tunnel over the Internet to
your internal LAN - a kind of private pipeline from the outside world into your internal network.
The VPN solution is good for some things (e.g., telecommuting), but only partially fulfills Library
and general web needs. One problem with VPNs is that they require proprietary clients - a client
that must be set up anywhere a connection to the internal LAN is needed. Some are hard to install
and support. Still others only support a limited range of operating systems. Worse yet, the tunnel
created by VPN clients adds overhead to any connections that traverse it, slowing access down to
the point of near unusability in many situations. The biggest problem with VPNs, though, is that
they can't be used in a variety of familiar situations, e.g., at Internet kiosks, cluster workstations,
and basically any machine the user doesn't have enough privileges.
9
2.2.2 Proxy Servers
One way of circumventing disinterested vendors that has come increasingly to the fore is
the HTTP proxy server. What an HTTP proxy server does, in this instance, is make off-campus web
clients look like on-campus ones by allowing the off-campus clients to route their Web traffic
through it. Because the proxy sits on campus, and occupies an on-campus IP address, the vendors'
machines will generally allow connections that are routed through it. In fact, depending on how
the proxy is set up, the vendor's systems usually can't even tell that there is a proxy. Rather, the
proxy looks to them just like a regular on-campus web client.
There are, in fact, a few vendors that try to deny proxy connections (e.g., EBSCO, as of
1999). They do this so that someone on campus can't just set up an open proxy, and then let the
whole world access the vendor's database(s) through it. To use a proxy with such vendors' systems,
one normally has to notify the vendor that the proxy is officially sanctioned, and that it isn't just a
rogue proxy run by, say, a student. Even though it is possible to proxies so that the vendor'
software can't tell they are there (e.g., by blocking HTTP headers like trace and x-forwarded-for)
the fact is that even without them, simple traffic analysis (e.g., of the Agent headers) will typically
identify the proxy as such. And some vendors, as noted above, will block access from the proxy
unless contacted and specifically requested to accept traffic from that machine.
Even for proxies that pass muster with all the relevant vendors there is still the issue of
authentication. For a standard proxy server to work securely, some form of encrypted password or
keyed authentication must be enabled between off-campus web clients and the proxy. The proxy,
that is, must allow the user to identify him or herself via a non-clear-text link. And it must not treat
the source network (i.e., IP) address of the client machine as an integral authentication tool, since
the whole idea of setting up a proxy is to deal with machines coming in via unknown, off-campus
networks, from unknown, off-campus IP addresses. Nor may the proxy use the usual plain-text
username/password authentication methods used by most standard proxy servers, since these
may be intercepted ("sniffed") by intermediaries, or in some cases, by network peers (e.g., by the
10
graduate student sitting in the next office down the hall). Unless people's user names and
passwords are considered to be of little value, and the resources being proxied of no account, the
proxy server must be outfitted with some means of sending and receiving encrypted
authentication information.
It turns out that some proxy servers can be outfitted with specially built packages that
facilitate encrypted client/proxy authentication. Encrypted proxy authentication, however, also
requires specially built client software and/or plug-ins to work. Special client software and/or plugins pose a problem because they create a need for added client-side support. And they ultimately
reduce the accessibility of the proxy.
To solve this problem, one might suppose that proxies could just transmit and receive the
necessary authentication information using HTTP redirects and encrypted HTTP cookies. Use of
HTTP cookies in place of standard proxy authentication, however, raises some knotty problems on
the client end. On the server end, cookies are problematic because they were never designed to be
used with proxies. Although a new PCookie (proxy-cookie) standard is in the works, trying to use
cookies in this way can, for at least the next several years, only lead to grief for programmers and
support personnel.
Even without cookies, standard proxies are problematic because they require changes in
browser settings that are not always possible. It turns out that most large ISPs run caching proxies
that, for performance reasons, keep temporary copies on hand of Web pages that their customers
fetch. This creates a situation where, if customers keep requesting the same pages (as typically
happens with popular sites), these customers don't have to fetch those same pages over and over
again from possibly slow or (in network terms) distant machines. They can, rather, just look at the
temporary copies of those pages that are sitting in their ISP's proxy-cache. All of this happens,
unbeknownst to the user, via the ISP's caching proxy.
So why does these make standard proxies problematic as a means of solving the web-access
problem? Because a user who wants to take advantage of, say, an on-campus library proxy (i.e.,
one not officially sanctioned by the local ISP) must manually reset his or her browser to point away
11
from the ISP's caching proxy, and toward the library's proxy server. In cases where this is actually
possible, it reduces performance. Often, however, it is not possible, because many ISPs run
firewalls that force customers to use their proxy and no other. If the user just barrels on ahead and
resets the browser to point to the new proxy anyway, his or her browser may no longer work. Even
for browsers running on on-campus machines, standard proxies are problematic if library
databases fall into more than one authentication domain.
It might be added that in many cases (e.g., at public cluster machines) the whole issue of
proxying is moot, because users simply are not allowed to go in and change the browsers' basic
settings. In other words, the browsers themselves enforce use of a specific proxy (or of none)
because they do not permit modification of their basic settings and "preferences."
A final problem with standard proxy servers is that they do not require users to
authenticate to every remote database being used, nor can their authentications be easily
configured to time out. Rather, they ask the user to authenticate just once, after which the user
receives unlimited access to all web-based resources. Although in some situations a single sign-on
no-timeout system like this might seem an advantage, there are times when it is a decided
disadvantage. Suppose, for example, that someone using a single sign-on scheme accesses a
resource via a proxy using a kiosk at another institution. Assuming the kiosk's browser can be so
modified, and assuming that the local ISP will permit use of an alternate proxy server setting in the
first place, doing this will create a number of potentially serious maintenance problems and
security holes. For example, if, when finished, the user walks away from the kiosk without restoring
the old proxy settings, then the browser remains in a state where anyone who uses it has access to
every proxied resource that the user had access to. And, of course, the very fact that the proxy
required a username and password means that the next time the machine boots or someone
restarts the browser a prompt will suddenly appear asking for username/password information
that local users presumably won't have--effectively disabling the kiosk until a knowledgeable user,
or a systems person, can come in and reset the altered proxy settings.
12
Although it is possible to do some proxy configuration automatically using something called
a PAC (i.e., a proxy auto-configuration) file, this whole mode of operation remains problematic for
kiosks and other machines not maintained by the institution that runs the proxy service-again,
because doing so requires making alterations to basic browser settings that often cannot, and
typically should not, be changed.
The bottom line for standard proxy servers is that they require changes to browser settings
that many kiosk setups and ISPs simply do not allow. To make matters worse, they make
authentication difficult, and, worst of all, create serious security problems by passing people's
passwords around in the clear over the network.
2.2.3 Pass-Through Proxy Servers
The only way to run a proxy service that anyone can use with any ISP or kiosk is to run a
reverse- or pass-through proxy (when outfitted with a cache, one also hears such proxies called
accelerators). A pass-through proxy is a proxy that masquerades as the server it is proxying for,
13
such that the proxy appears to hold a mirror image of whatever is on the remote server, i.e., on the
server being proxied.
The process works like this: An outside client (presumably a web browser) requests a page
from the pass-through proxy. The proxy first prompts the user for whatever authentication tokens
it needs (usually a username and password). After clearing the username and password with some
local authentication service, the pass-through proxy then fetches the requested page from the
remote server. Finally, it sends the requested information back to the client. Throughout this
process, the client never talks directly to the remote server; and the remote server never talks
directly to the client. For all the client knows, the proxy is just a regular webserver. For all the
remote server knows, the proxy is just a web browser on someone's desktop.
It's kind of like the proverbial manager who reports on work "he" has been doing--when really all
he is doing is passing on information gleaned from other members of his team. Just as our manager
presents himself as the author of the information, so also the pass-through proxy can make itself
look like the source of pages it fetches from the site it mirrors.
Because pass-through proxies look exactly like origin web servers, they can be used in
conjunction with other proxies, or through a firewall--just like any other web server. They can also
send and receive cookies, which, as noted above, is difficult at best with non-PCookie-enabled
proxies--but is perfectly acceptable with origin web servers. Pass-through proxies' also require no
set-up on the client end. And they do a complete end-run around vendors, who never need to
know of its existence.
For many institutions, therefore, a simple pass-through proxy offers decisive advantages
over both standard proxies and large-scale portals. And even in institutions that use portals it may
prove convenient to set up a pass-through proxy to work together with the portal, so that the
portal can treat proxied library databases as a single authentication domain. A portal and a passthrough proxy, in other words, may complement, rather than compete with, each other.
14
But Pass-Through Proxying has some problems and one of serious one is that the easiest
implementation route is to set up a new proxy server for every remote server being proxied. In this
respect, the proxy server is quite unlike our proverbial manager above, who can take credit for any
number of team members' work. Pass-through proxies assume, rather, a one-to-one relationship.
Every remote resource must have its own distinct proxy server. Doing things this way obviates the
need for elaborate HTTP header and content rewriting (in technical terms, you only have to remap
FQDNs, not URL paths). The disadvantage to doing things this way is that, for sites with significant
IP-restricted information resources, one has to run what might seem like a daunting number of
distinct proxy servers.
Fortunately, most webservers today allow port-based virtual hosting. That is, they allow
one to set up distinct webservers on the same physical machine that differ only in the port number
given in the URL (e.g., http://servername.cis.brown.edu:1443/, where 1443 is the port number).
Port-based virtual hosting can be accomplished without adding new machine names, and without
requiring extra (e.g., "Host") headers to be exchanged between client browsers and the server. So,
even in cases where there are hundreds of vendors with servers that must be proxied, port-based
virtual hosting makes it easy to set up enough proxy servers to cover them all. (What we have done
here at Brown University is to set up simple scripts that automate the creation of virtual hosts.)
In fact, the most serious problem with using a pass-through proxy to solve the web-access
problem is that links branching off of pages fetched from the mirrored site will often lead users out
of the pass-through proxy's document space, and back to the original server.
So analyzing all those possible solutions we come up with Pass-Through Proxying strategy,
which best satisfy AUA’s needs and further research is done to find existing products that best
satisfy the needs of AUA.
To understand just how far pass-through proxies and similar technologies work is ahead of
other remote access solutions, we'll need to take a look at the leading remote-access systems
being used in libraries today. The most famous products that implemented Pass-Through Proxying
strategy are EZProxy and LibProxy.
15
2.2.3.1 EZProxy
EZproxy is an easy to setup and easy to maintain program for providing your users with
remote access to web-based licensed databases. It operates as an intermediary server between
your users and your licensed databases. Your users connect to EZproxy, and then it connects on
their behalf to your licensed databases to obtain web pages and send them back to your users.
Since EZproxy runs on a machine on your network, your database vendor sees the requests as
coming from an IP address on your network, so it permits access.
When one of your users remotely accesses avsl.aua.am and requests access to
somedb.com, EZproxy automatically creates a virtual web server for somedb.com. In this example,
http://somedb.com might be assigned to a virtual web server named
http://ezproxy.yourlib.org:2050. All virtual web servers use the same naming convention, with
different ports (e.g., 2050) distinguishing them.
When this user requests documents from this virtual web server, EZproxy makes the same
request to the somedb.com then sends the response back to this user. During this transaction, the
request to somedb.com comes from your own server, so somedb.com views it as one of your IP
addresses and allows the access. The graphical representation of EZProxy displayed on Figure2.
However, EZProxy is not acceptable for some sites because it currently passes
authentication credentials over the network in the clear, and therefore presents a serious security
16
hole. EZProxy also typically requires (especially for medium and large-sized university libraries)
hand configuration-file editing and maintenance, which in larger institutions can drain away time
from skilled personnel and shift the burden of configuring the list of proxied resources away from
where it should properly reside (i.e., with the reference and serials/acquisitions staff) to the
systems staff, thereby adding yet another layer of administrative indirection to the process of
adding new vendors and resources, and of generally maintaining the proxy.
Main disadvantages of EZProxy are that it’s commercial expensive product and is not open
source, but, although, has API’s to let developers easily integrate with their applications.
2.2.3.2 LibProxy
With its easy web interface, rich feature set, and flexible, secure single sign-on
authentication, Libproxy could be one of the best remote access solutions currently available. To
use Libproxy, users simply go directly to URLs on the Libproxy server - the same way they would go
to URLs on any normal web server. Libproxy then acts as a portal, relaying the users on, invisibly,
to vendors' web sites. There is no special client software to install and no need to reconfigure
either the browser or the operating system. It's easy to maintain and it works.
Libproxy is like a standard web proxy in the sense that it requests web pages from remote servers
on behalf of clients (i.e., users' web browsers), substituting its own IP address for those of the
clients.
Unlike a standard proxy, however, Libproxy passes client information through to the
remote server unaltered, rewriting HTTP headers as needed to create the illusion that it is a
browser, and not a proxy. On the client end Libproxy creates a similar illusion, acting like an origin
web server rather than a proxy; users just go directly to it, the same way they would to any normal
web server. No browser reconfiguration is needed.
Some of the big advantages of Libproxy over a standard proxy are that it looks, as noted
above, like an origin web server, and that there is no need to reconfigure one's browser to use it.
It is also more secure than a standard proxy because it can be used with a wide variety of (e.g.,
cookie-based) authentication systems. And, because it looks like an origin web server, it can be
17
used by off-site users coming in via remote kiosks, or via machines routed through ISPs that
enforce use of their own standard proxy servers and don't allow connections to other proxies.
Although Libproxy is not alone in its ability to mimic an origin web server, it differs from
most other so-called pass-through proxies in that it rewrites fetched web pages on the return trip.
Libproxy does this for several reasons; among them that rewriting enhances the degree to which it
can fool the clients and servers into thinking they are talking directly to each other (thereby
eliminating the need to do anything special with either users or vendors to give them access).
Rewriting also prevents patrons from unwittingly doing an end run around the proxy by following a
fully qualified URL that point to one of the web servers it is mirroring.
Libproxy differs also from the few rewriting pass-through proxies that exist (e.g., EZProxy) in
being free - and offering an easy-to-use, web-based administrative interface. To add or delete
hosts/domains, check on the server's run-time status and performance, view stats, or augment
per-host settings like the list MIME types to filter, all you need to do is go to Libproxy's selfdocumenting web-based administrative interface and basically just point and click. There's rarely
any need to edit any Libproxy's configuration files or manually restart the server.
Unlike other remote-access solutions, Libproxy - with its easy, web-driven interface and nononsense operation - suffers from no such disadvantages. As noted above, users simply go directly
to URLs on the Libproxy server, as they would to URLs on any web server. From there they are
relayed, invisibly, to vendors' web sites, which they can access freely after entering their PIN or
username/password just once. Although Libproxy has a lot of prerequisite software packages
(Apache, Perl, mod_perl, MySQL, etc.), which make a snap installation, especially in Sun Solaris
operating system.
2.3 Decision
18
Having into account all known solutions to the problem we’ve decided to implement one of
pass-through proxy products. We compared pros and cons of EZProxy and LibProxy and chose for
implementation EZProxy as remote access manager tool in AVSL product, because:

Unlike EZProxy which is simple to install, LibProxy require a lot of preinstalled packages to
be in OS

EZProxy has very good installation and usage guides

Since EZProxy is commercial product is has good maintenance and support

There are number of publications that advice EZProxy to use as one of the stabile passthrough proxy server
3. Implementation
19
This chapter will explain the implementation of AVSL project in details. Implementation started
from use case description, then components that need to be configure for development.
3.1 AVSL Use Cases
This diagram presents the various use cases for the AVSL Portal, which is described in the next
section.
20
3.1.1 Use Case actors
In the use cases, we define 3 different types (or roles) of actors:

a 'regular' user is any user who reaches the AVSL Portal, authenticated or not

an 'admin' user is a user known by the AVSL Portal who has been granted the 'admin'
privileges, allowing him to perform user registration operations

an 'editor' user is a user known by the AVSL Portal who has been granted the 'editor'
privileges, allowing him to perform bulletin board management operations
Users may also have a status:

an active user is known to the system and authorized to perform any action granted by
his role

a suspended user is known to the system, but all permission have been suspended
temporarily
3.1.2 Use case descriptions
Use case #
1
Use case name
Access to the public AVSL website
Summary
A user accesses the public AVSL website via his browser
Dependency
Actor
Web user
Precondition
Description

A user accesses the public section of the AVSL website via his browser

He can navigate through the different pages (welcome page, resource
page) as long as he stays within the public section of the site

No authentication is required
21
Alternative
Postcondition
Use case #
2
Use case name
Access to a protected resource
Summary
A user accesses a protected resource from the public AVSL website via his
browser
Dependency
Actor
Web user
Precondition
The user is viewing the public section of the AVSL site

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) a resource that is protected by EZProxy
Alternative

the user is redirected to EZProxy authentication page

the user is given access to the resource upon successful authentication
Authentication failure

user is redirected to the public section of the site
User already authenticated

the user has previously authenticated with EZProxy and his session has
not expired and has not been revoked

user is given access to the resource without re-authenticating
Postcondition
User has a valid session with EZProxy
Use case #
3
Use case name
Login to AVSL website
Summary
A user authenticates with the AVSL website
Dependency
22
Actor
web user
Precondition
The user has no valid session with AVSL website

Description
The user goes to the login screen on the public section of the AVSL
website

The user presents his credentials (username, password)

The user is redirected to the public section of the AVSL website with a
valid session established

Depending on the role associated with the user, links to the admin or
editor section appear
Alternative
Authentication failure

user is redirected to the public section of the site
Postcondition
User has a valid session with AVSL website
Use case #
4
Use case name
Logout from AVSL website
Summary
User has a valid session with AVSL website
Dependency
Actor
web user
Precondition
The user has a valid session with AVSL website

Description
The user selects (clicks on) the logout link on the public section of the
AVSL website

The user is redirected to the public section of the AVSL website with
any previously established valid session destroyed
Alternative
The User session expires automatically after a certain amount of time
Postcondition
User has no valid session with AVSL website
Use case #
6
Use case name
Modify user
23
Summary
An admin user updates existing user data in the AVSL registration sy
Dependency
Login
Actor
Admin user
Precondition
User has a valid session with AVSL website
User has the admin role

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) the admin section (this link only appears if the user has the
admin role)

the user gets access to the AVSL admin section

the user selects the user he needs to modify
o he modifies the details for the selected user:
o first name
o last name
o email
o password
o roles (none, admin, editor, both):

the user confirms the modification
Alternative
Postcondition
User is in the AVSL admin section
Changes to the user data have been written to the user database
Use case #
7
Use case name
Delete user
Summary
An admin user removes an existing user from the AVSL registration system
Dependency
Login
Actor
Admin user
Precondition
User has a valid session with AVSL website
User has the admin role
Description

From the public section of the AVSL site, the user selects (clicks on a
24
link to) the admin section (this link only appears if the user has the
admin role)

the user gets access to the AVSL admin section

the user selects the user he needs to delete

the user confirms the deletion
Alternative
Postcondition
User is in the AVSL admin section
User record is deleted from the user database
Use case #
8
Use case name
Suspend user
Summary
An admin user suspends an existing user in the AVSL registration system
Dependency
Login
Actor
Admin user
Precondition
User has a valid session with AVSL website
User has the admin role

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) the admin section (this link only appears if the user has the
admin role)

the user gets access to the AVSL admin section

the user selects the user he needs to suspend
o the user confirms the operation
Alternative
Postcondition
User is in the AVSL admin section
User record is updated in the user database to reflect the changes
Use case #
9
Use case name
Activate user
25
Summary
An admin user activates an existing user in the AVSL registration system
Dependency
Login
Actor
Admin user
Precondition
User has a valid session with AVSL website
User has the admin role

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) the admin section (this link only appears if the user has the
admin role)

the user gets access to the AVSL admin section

the user selects the user he needs to activate
o the user confirms the operation
Alternative
Postcondition
User is in the AVSL admin section
User record is updated in the user database to reflect the changes
Use case #
10
Use case name
Upload user data
Summary
An admin user uploads new users to the AVSL registration system
Dependency
Login
Actor
Admin user
Precondition
User has a valid session with AVSL website
User has the admin role
User has prepared a file containing the details of the users to import into the
AVSL registration system
Description

From the public section of the AVSL site, the user selects (clicks on a
link to) the admin section (this link only appears if the user has the
admin role)

the user gets access to the AVSL admin section
26

the user selects the 'upload users' link

the user provides the details of the file to upload and confirms the
operation

the system displays a summary of the upload operation
Alternative
Postcondition
User is in the AVSL admin section
User data have been imported from the uploaded file to the user database
Use case #
11
Use case name
Create news
Summary
An editor user adds a news message to the AVSL Bulletin Board
Dependency
Login
Actor
Editor user
Precondition
User has a valid session with AVSL website
User has the editor role

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) the editor section (this link only appears if the user has the
editor role)

the user gets access to the AVSL editor section

the user selects the 'Add News' and fills in the body for the new
message

the user confirms the creation
Alternative
Postcondition
User is in the AVSL editor section
A news record is added to the news database; changes are visible to all users
Use case #
12
Use case name
Modify news
27
Summary
An editor user modifies a news message in the AVSL Bulletin Board
Dependency
Login
Actor
Editor user
Precondition
User has a valid session with AVSL website
User has the editor role

Description
From the public section of the AVSL site, the user selects (clicks on a
link to) the editor section (this link only appears if the user has the
editor role)

the user gets access to the AVSL editor section

the user selects the news message he needs to modify and updates the
body as required

the user confirms the modification
Alternative
Postcondition
User is in the AVSL editor section
The news record is updated in the news database; changes are visible to all
users
Use case #
13
Use case name
Delete news
Summary
An editor user deletes a news message from the AVSL Bulletin Board
Dependency
Login
Actor
Editor user
Precondition
User has a valid session with AVSL website
User has the editor role
Description

From the public section of the AVSL site, the user selects (clicks on a
link to) the editor section (this link only appears if the user has the
editor role)

the user gets access to the AVSL editor section
28

the user selects the news message he needs to delete

the user confirms the modification
Alternative
Postcondition
User is in the AVSL editor section
The news record is definitively removed from the news database;
Use case #
14
Use case name
Archive news
Summary
An editor user archives a news message in the AVSL Bulletin Board
Dependency
Login
Actor
Editor user
Precondition
User has a valid session with AVSL website
User has the editor role
Description

From the public section of the AVSL site, the user selects (clicks on a
link to) the editor section (this link only appears if the user has the
editor role)

the user gets access to the AVSL editor section

the user selects the news message he needs to archive

the user confirms the modification

the news message is marked as 'archived' in the database, which
makes it invisible in the Bulletin Board, while it still exists in the
database
Alternative
Postcondition
User is in the AVSL editor section
The news record is definitively removed from the news database
29
3.2 Application Components
From a software perspective, the following components are used:
 a directory server (LDAP), to store user information
 a web/EJB container to host the web application
 a relational database to store additional information
 a security mechanism to match Publisher's authentication/authorization scheme; as most
Publishers rely on IP-based control
Java Server Faces (JSF) is an application developing framework that simplifies building user
interfaces for Java based web applications.
Developers of various skill levels can quickly build web applications by: assembling reusable UI
components in a page; connecting these components to an application data source; and wiring
client-generated events to server-side event handlers. For ease of development and maintenance,
we have decided to use the JSF framework to develop the AVSL web application.
We have selected Sun Directory Server as the LDAP directory, for robustness, performance and
support reasons. We have selected Sun Application Server as a web container, for the same
reasons. We have selected MySQL database to store the news bulletin board data; however, as this
database is accessed through standard JDBC connection pooling, it could be easily replaced with
any other database without effort.
3.2.1 User database
The AVSL Portal is open to any user; no particular security control occurs when a user tries to
access the Portal. However, there's a need for a user to log in into the system in order to have
access to online materials or to perform some special activities if user have admin or editor roles.
All user data is stored in the LDAP Server.
30
3.2.2 Portal Security
Access to the specific areas of the AVSL Portal is controlled by the web container (Sun Application
Server) through the use of 'declarative security'. No programmatic security control is implemented
in the AVSL Portal, which allows for maximum portability. We require that the login page is
accessed on an encrypted (SSL) channel, as well as all user management operations.
3.2.3 Access to remote resources
Currently, EZProxy is used to link to publishers websites, and uses the same LDAP server and data
as the user registration system to authenticate users. This avoids data duplication, and allows for
Single-Sign On as a possible extension. Should other mechanisms be put in place to securely access
publisher’s resources, it is expected that they would rely on the same user data.
3.2.4 News database
All news messages are stored in the relational database with some additional management
information (like creation and archive dates, author, etc.); any modification to the news data
happens directly on the database, so that all Portal users keep access to up-to-date information.
31
3.3 Application design
The application is designed as a JSF application. The layout of the application is the following:

ivsl/src/java directory contains the source code:
o org.ivsl.jiab.admin package contains user management classes
o org.ivsl.jiab.beans package contains the JSF Beans
o org.ivsl.jiab.daos package contains the generic DAO classes
o org.ivsl.jiab.daos.ldap contains the LDAP DAO classes
o org.ivsl.jiab.daos.mysql contains the MySQL DAO classes
o org.ivsl.jiab.editor package contains the news editor classes
o org.ivsl.jiab.locale package contains the multilingual message files
o org.ivsl.jiab.servlets package contains the specific servlets

ivsl/build directory contains the compiled code

ivsl/dist directory contains the war file for the application deployment

ivsl/src/conf directory contains misc configuration files

ivsl/web contains the jsp files for the open functionalities and the style sheet

ivsl/web/admin contains the jsp files for the user management

ivsl/web/editor contains the jsp files for the news editor

ivsl/web/images contains the images files
32

ivsl/web/WEB-INF contains the deployment descriptor (web.xml) as well as the JSF facesconfig.xml file

ivsl/build.xml is the ant build script used to compile and package the web application
3.6 EZProxy Design
In the AVSL System the Application Proxy (EZProxy) had been adapted, that the EZProxy is used
with JAVA programming technologies and LDAP Directory Server to provide the user
authentication, the ticket authentication mechanism is used, the JAVA program with LDAP
Directory Server are responsible for managing the User Registration System, as the Figure below
shows, the JAVA program sends a ticket to EZProxy with the user name and time and the URL of
the requested Publisher to tell EZProxy to authenticate the user and then takes out of the
communication between the user and the Proxy server, this ticket is encrypted with MD5 message
digest (which is described in chapter two), after that EZProxy server will continuously rewrite the
Publisher URL to keep itself between the user web browser and the Publisher(content provider).
EZProxy is designed to use ticket authentication mechanism, Ticket authentication allows the
Virtual Library’ web server to request short-lived URLs on behalf of the user from EZProxy and
EZproxy will automatically recognize the user as being authorized and permit access to a resource
with no need for EZproxy to check back with the Virtual Library’s program that requests the URL.
The ticket parameter on the URL contains a digital signature that EZproxy uses to verify that the
URL was created by an authorized program which is the Virtual Library’s program. The ticket
33
contains a time-stamp of when it was created. EZproxy can be configured to determine how old a
ticket can be before it is considered expired.
1. Security constrains is added to EZCGIServlet by configuring the web.xml file, by doing so only the
users who have a valid session with the Virtual Library and have previously logged in successfully
can access the EZCGIServlet. This adds more security to the Virtual Library that the fraudulent
unauthenticated user cannot make an http request like the following and access the publisher
without login in the portal.
http://avsl.aua.am/AVSL /ezcgi?user=username&url=http://www.bl.uk
2. When the ECGI Servlet sends a ticket to EZProxy over this channel it encrypts it with MD5. And
when EZProxy receives the ticket and the user name, time stamp, it will recalculate the message
digest and compare it with the ticket. It will accept the request only if the two are identical, as
described in section 2.5, so no one can generate fraudulent ticket and send it to EZProxy.
3.7. System configuration
For development environment initial setup for Developer machine under Windows operating system
referee Appendix A. Further will be described configuration and integration of AVSL components.
3.7.1 Sun Java System Application Server Configuration
Open a new Browser and type http://localhost:4848/ (if the server is run on your computer).
And login with your username and password (default values are - usr: admin, psw:
adminadmin).
1. JDBC connection configuration.
1. On the left panel find Resources and under it select JDBC and then Connection pools
located under them. Then press the New button on the right panel.
34
2. Fill in the Name field with appropriate name and select java.sql.Datasourse in the second
field and mysql as Database vendor.
35
3. On the second step, leave all the fields as default and change only the last table as shown
below. Then press finish button.
4. Select JDBC Resources from the left panel and click on the New button.
36
5. Fill in the first field (JNDI Name) with jdbc/ivsldb and the select MySql connector in the
second row and leave anything else as the default and press OK.
6. Copy “mysql-connector-java-3.0.10-stable-bin.jar” file in your Sun Java Application Server
folder {$SunAppServ}\AppServer\domains\domain1\lib. And restart the sun Java
Application Server. (You can check if the configuration is correct by Ping button located on
the MySql-connector page on the server configuration. Before that the appropriate user
user@userhost should be created in mysql database).
37
3.7.2 LDAP configuration
1. Select Configuration  Security Realm, and Press New.
2. Fill the Fields with appropriate values shown below on the picture and save the entries.
Press Add Property button to open new lines. When finish press OK then Save if necessary.
38
10.8.0.30:389
3.7.3 EZproxy installation and configuration in Solaris 10
EZproxy is a completely stand-alone application. It does not require nor use any existing web
server that is already installed on your server.
If you are already running a web server on the system where EZproxy is running, do not attempt to
install EZproxy within directories that are used by that web server.
1. Create a directory for EZproxy and make it your current directory with command such as:
mkdir /usr/local/ezproxy
cd /usr/local/ezproxy
2. Download ezproxy.sol10.bin into this directory. If you download this file on a different
system and use FTP to move it to your EZproxy server, be sure to perform the transfer using
binary.
3. Rename the download file from ezproxy.sol10.bin to ezproxy and make it executable with
the commands:
39
mv ezproxy.sol10.bin ezproxy
chmod 755 ezproxy
4. To create the default version of most of the files mentioned above, issue the command:
./ezproxy -m
The "-m" stands for "missing file replacement" and this command can be used at any time
to reconstruct any missing files without overwriting existing files that you have changed.
5. To verify whether EZproxy can automatically detect your host name correctly, as well as to
check whether firewalls may interfere with your ability to use EZproxy, issue the command:
./ezproxy -c
This command will make your server connect to the www.usefulutilities.com server. Your
server will provide its name and IP address, then the www.usefulutilities.com server will
attempt to verify this information. Your server will then display various messages to let you
know what changes may be required for EZproxy to function properly.
If you do not like the idea of your server connecting to the www.usefulutilities.com server,
you may omit this step.
If your network requires the use of a standard proxy server to connect out to the Internet,
this test will fail. In this case, you will need to configure EZproxy to use your outgoing proxy
server using the Proxy directive, and then you can complete the network connectivity test
by finishing the installation of EZproxy and using a browser installed either on the same
server or within your network to log in to the EZProxy Administration page, where you can
use the Test network connectivity option. This performs a more thorough network test,
including offering the option to incorporate your outgoing proxy server in the test.
6. Use a text editor to edit the file ezproxy.cfg. If suggested from the previous step, manually
specify your host name in this file. The file also contains suggestions for other changes.
40
7. Use a text editor to edit the file ezproxy.usr. To this file, add a line similar to this:
someuser:somepass:admin
changing someuser to the username you want to use for testing and somepass to the
password you want to use for testing. In this example, admin should appear literally as
shown.
8. Start the server with the command:
./ezproxy
9. Using your web browser, connect to your server on port 2048. If your EZproxy server was
named ezproxy.yourlib.org, you would use this URL:
http://ezproxy.yourlib.org:2048/admin
10. Enter the username and password that you created when you edited the ezproxy.usr file.
This should bring you to the main server administration page.
If, instead of the menu page, you end up at a page indicating that the EZproxy cookie was
blocked, see www.usefulutilities.com/support/cookie.html for information on why this
happened and how to address it.
The options presented and how effectively they work will depend on how well you customized
ezproxy.cfg. As you make additional changes to ezproxy.cfg, you will need to stop and restart.
3.8 JSF Web Pages Navigation Work Flow
The diagram below shows the different JSF pages and the possible path between them, the
navigation for each user is restricted according to his role, so he can access only the JSF pages that
he is allowed to access according to his privileges.
41
3.9 The Resulting JSF Web Pages
The following JSF Web Pages are displayed during the navigation in the AVSL system:
1. The main page (the user not logged in): in this page the user may login, read news.
42
2. The login.jsp page: in this page the user can login by providing his credentials (user name,
password).
3. The main.jsp page (the user logged in and has the Admin, Editor Roles): in this page the user can
logout, access the publishers, access the Admin, Editor sections, and read news. Shown Admin
brows view
43
4. The error.jsp page: this page appears when login operation failed.
44
5. The browse.jsp page: appears when the user clicks for more news. In this page the user can
browse the news.
6. The publisher / the ACM portal
45
4. Conclusions
1. The Armenian Virtual Science Library is the best solution for the AUA’s library needs. This can be
used for purchasing the expensive licenses of electronic information resources from the Publishers
and provide them freely to the students, faculty, etc.
2. AVSL uses Directory Server for authenticating users which can allow distributing user load on the
servers (by replicating the Directory Server) thus making administration easier and also sorting the
directory entries. The System uses strong security mechanism to check and give appropriate role to
logged in user and also for integrating EZProxy send right tickets to give access to possible virtual
libraries and needed sections of the application.
3. The AVSL System has a secure and an easy to be implemented User Registration System which
divides the users into three groups, each one has a different role (none, Admin, and Editor), the
users with the “none” Role can only access the Publishers, the users with Admin Role can modify
the User Registration System, the users with Editor Role can edit the news, and all the users can
read the news.
4. The AVSL System uses EZProxy server for accessing the publishers’ resources, this solution is
preferable because EZProxy Server can be developed to support all the known publishers’ security
mechanisms which are: - IP Address authentication mechanism, Athens and Shibboleth, because
each publisher may use different security mechanism to restrict access to its resources.
5. The AVSL System’s bulletin board is a good solution to provide news and announcement from
the institution.
6. The system can be used easily because the users of the IVL System need only to use the internet
Web Browser without any configuration to access the system from anywhere and anytime.
46
5. Suggestions for Future Work
Some useful ideas can be used to develop the System of the Armenian Virtual Science
Library in the Future, these suggestions are:
1. Full integration with EZProxy, in order to sign in only ones
2. The ability to synchronize needed virtual hosts between System and EZProxy hosts list
3. The ability to synchronize users between LDAP System and EZProxy users list
4. An enhanced searching capabilities could be added covering the Articles from all publishers in
the public section of the AVSL, these searching capabilities could be accessed without login
47
6. References
[1] Jalal B Raouf, “Design of Iraqi Virtual Science Library”, 2007.
URL: http://e-science-library.dev.java.net
[2] Albama SuperComputer Authority, “Alabama Virtual Library
(AVL)”, 2000. URL: http://www.avl.lib.al.us/about/index.html
[3] URL: http://www.who.int/hinari/about/en/
[4] URL: http://www.aginternetwork.org/en/about.php
[5] URL: http://portal.acm.org
[6] URL: https://www.ivsl.org
[7] By Jayson Falkner (et. al.), “Servlets and JavaServer Pages™:
The J2EE™ Technology Web Tier”, Addison Wesley, United
State of America, September 19, 2003.
[8] By Bruce W. Perry, “Java Servlet & JSP Cookbook”, O'Reilly
Media Inc., United States of America, January 2004.
[10] NetBeans(IDE) help contents.
[11] URL: http://www.netbeans.org
[12] URL: http://www.usefulutilities.com
[13] URL: http://goerwitz.name/software/libproxy/dist/
[14] URL: https://www.dev.java.net/scdocs/ddCVS.html
[15] Jalal B Raouf, “IVSL Platform”, 2007.
URL: http://e-sciencelibrary.dev.java.net
[16] URL: http://sun.java.net
48
Appendix A
This appendix will describe the steps for installing components for AVSL developers.
Components to be installed
2. Java Development (Runtime) Environment - JDK
3. Integrated Editing and Compiling environment for Java.- NetBeans V5.5 (or higher):
http://www.netbeans.org/features/index.html
4. Application Server for running compiled Java application. - Java Tools Bundle Windows ML:
http://java.sun.com/javaee/downloads/index.jsp 5. Application Server Configuration
JDK Installation.
1.
Download and install “jdk-1_5_0_10-windows-i586-p.exe” from http://sun.java.net and
install by default steps.
NetBeans Installation & configuration
1. Download the NetBeans software “netbeans-5_5_1-windows.exe” from
http://www.netbeans.org/features/index.html and install it with the default steps.
2. If JDK is properly installed then there will appear an window with the path to JDK folder
“C:\Program Files\Java\jdk1.5.0_10”. If not then JDK should be installed and the path
should be shown during the NetBeans installation.
3. After installation we have an icon on desktop NetBeans 5.5.1 which we do not use for
running our program. We’ll use the other icon NetBeans 5.5 created after Application
Server installation.
49
Application Server Installation
1.
The Application Server we are going to install is Java EE 5 Tools Bundle “java-tools-bundlewindows-ml.exe”. Download it from http://java.sun.com/javaee/downloads/index.jsp and
install with the default settings.
2.
In the 3-rd step of installation, define the path of your JDK folder if it is not specified
automatically (usually C:\Program Files\Java\jdk1.5.0_10).
3.
The admin username password by default is admin / adminadmin which desirable to
change. The default ports are Admin – 4848, HTTP – 8080, HTTPS – 8181.
4.
Open the NetBeans IDE, File  Open Project and then show the path of the downloaded
project (C:\IVSL\e-science-library in our example). Click “Open Project” button. The
project will be loaded and some reference problems will be reported.
5.
We need to add libraries in order to be able to build the project. Right Click on the “escience-library4” on projects tab and select properties.
6.
Be sure that the 1.5 is selected at the Source level combo box at the bottom.
50
7.
Select Libraries tab from the left panel and add the required libraries
1 – JSF 1.1
2 – JSTL 1.1
3 – mysql-connector-java-3.0.10-stable-bin.jar
4 – commons-el.jar
The necessary libraries should be downloaded: MYSQL JDBC Driver:
http://mirrors.ibiblio.org/pub/mirrors/maven2/mysql/mysql-connector-java/3.0.10/mysqlconnector-java-3.0.10-stable-bin.jar
http://www.apache.org/dist/commons/el/binaries/commons-el-1.0.zip (extract and get commonsel.jar file )
51
8.
Select Build  Build Main Project and the project is ready to execute.
9.
Select Run  Run Main Project (it will automatically run the project with Sun Java System
Application Server).
10. From the Browser Open the following link http://localhost:8080/e-sciencelibrary4/login.jsp
52
Appendix B
The build.xml using which developer need compile source code (using apache-ant software) to
deploy it on Solaris operating system.
<?xml version="1.0"?>
<project name="AVSL" default="build" basedir=".">
<property name="appname" value="${ant.project.name}" />
<!-- LocalJars Directory -->
<property name="sjsas.root" location="/alt/SUNWappserver" />
<property name="sjsas.servlet.jar" value="${sjsas.root}/lib/j2ee.jar"/>
<!-- Java Server Faces jar files -->
<property name="localjarshome" location="./web/WEB-INF/lib"/>
<property name="jsfjarshome" location="${localjarshome}/jsf-1_1_01"/>
<property name="jsfapijar" location="${localjarshome}/jsf-api.jar"/>
<property name="jsfimpljar" location="${localjarshome}/jsf-impl.jar"/>
<property name="jsfcljar" location="${localjarshome}/jsfcl.jar"/>
<property name="tomahawkjar" location="${localjarshome}/tomahawk-1.1.3.jar" />
<property name="buildhome" location="."/>
<property name="build.dir" location="${buildhome}/build"/>
<property name="src.dir" location="${buildhome}/src/java"/>
<property name="dist.dir" location="${buildhome}/dist"/>
<property name="compile.debug" value="true" />
<property name="compile.optimize" value="false" />
<property name="webapp.webxml" value="${basedir}/etc/web.xml" />
53
<property name="webroot.dir" value="${basedir}/web" />
<property name="webinf.dir" value="${webroot.dir}/WEB-INF" />
<property name="metainf.dir" value="${webroot.dir}/META-INF" />
<property name="lib.dir" value="${webinf.dir}/lib" />
<path id="compile.classpath">
<pathelement location="${sjsas.servlet.jar}" />
<pathelement location="${jsfapijar}" />
<pathelement location="${jsfimpljar}" />
<pathelement location="${jsfcljar}" />
<pathelement location="${lib.dir}/commons-fileupload-1.1.1.jar" />
<pathelement location="${tomahawkjar}" />
</path>
<target name="init">
<echo message="-------- Start building, please wait --------" />
</target>
<target name="build" depends="package">
<echo message=" Building with ${ant.version} on Java ${ant.java.version}...." />
</target>
<target name="prepare" depends="init">
<mkdir dir="${dist.dir}" />
<mkdir dir="${build.dir}" />
<mkdir dir="${build.dir}/classes" />
</target>
<target name="compile" depends="prepare">
54
<javac srcdir="${src.dir}/" destdir="${build.dir}/classes/"
debug="${compile.debug}">
<classpath refid="compile.classpath" />
</javac>
</target>
<target name="package" depends="compile">
<echo message="Creating war from ${webroot.dir} into
${build.dir}/${ant.project.name}.war" />
<war basedir="${webroot.dir}" destfile="${build.dir}/${ant.project.name}.war"
webxml="${webinf.dir}/web.xml">
<classes dir="${build.dir}/classes/" />
<classes dir="${src.dir}/" />
<exclude name="WEB-INF/${build.dir}/**" />
<exclude name="WEB-INF/src/**" />
<exclude name="WEB-INF/web.xml" />
<exclude name="META-INF/application.xml" />
<exclude name="META-INF/sun-application.xml" />
</war>
<copy file="${build.dir}/${ant.project.name}.war" todir="${dist.dir}" />
</target>
<target name="clean">
<delete dir="${dist.dir}" />
<delete dir="${build.dir}" />
</target>
</project>
55