Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
تنظیمات قلم


اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
لیست موضوعات
افزودن یادداشت
افزودن یادداشت جدید

10.4 Setting Up the Indexer

Now that the search service
integrated into the application, we'll configure the
indexer to automatically update against the current version of the
web site on a regular basis. If you recall from the previous chapter,
both the console application and the web service have mechanisms that
let you launch the indexer service instead of the search service. The
question is, how should the indexer be integrated with

10.4.1 Embed in jPetStore or Launch Externally?

The first approach is to

make the indexer part of the
jPetStore application itself; in other words, to
add code to jPetStore that invokes the indexer.
jPetStore could invoke the indexer at the request
of a user or on a schedule. Both methods have problems: if we expose
a user interface for launching the indexer, we have to wrap it in
some kind of secured section of the site for administrative users
only. Currently, jPetStore has no such security
built in. Building it just to wrap around the indexer seems like a
major stretchtoo much complexity, not enough payoff. Which
means a manual access point is out.

The other option is to build a scheduler into the
jPetStore application. Regardless of how the
architecture, a scheduler would require the
jPetStore application to be running for indexing
to occur. Since jPetStore is a web- and
container-based application, its lifecycle is entirely dependent on
the external hosts. If the web server software is turned off for any
reason, jPetStore shuts down as well. If the
interval for the indexer falls in that window, the indexer
doesn't run. In addition, writing scheduling code is
completely outside of the problem domain for
jPetStore, just as it was for the Simple Spider.
The jPetStore application should do one thing:
display animals in a web catalog.

We have no option but to invoke the indexer from some other location.
A good strategy is to leverage an existing scheduler system: on
Windows it's schtasks and on
Linux it's cron.
Let's implement the scheduled indexer on

10.4.2 Using the System Scheduler

For ease of use, we create a

batch file for actually
launching the service. We want to invoke the Java runtime to run our
ConsoleSearch class's main
method, passing in the starting point for
jPetStore. The command (and, therefore, the
contents of our batch file) looks like this:

java c:\the\path\to\ConsoleSearch /i:http://localhost/jpetstore

We store that in a file called
jpetstoreIndexer.bat. For
simplicity's sake, we'll store it
in c:\commands.

In order to schedule the indexer to run every night at 2:00 a.m.,
issue the following command (whiled logged in as a local

c>schtasks /create /tn "jpetstore Indexer" /tr:c:\commands\jpetstoreIndexer.bat 
/sc daily /st 02:00:00

The /tn flag creates a unique name for the text;
/tr points to the actual command to invoke;
/sc is the time interval; and
/st is the specific time to launch the indexer on
that interval.

Similarly, on Linux, edit the crontab file and
launch the cron daemon to accomplish the same

10.4.3 Smell the Roses

The beauty of this solution is that our application, the Simple
Spider, has been repurposed to run in both a container-based
environment (Spring) and a direct runtime environment (via the
scheduler calling the Java runtime directly) without any extra code
whatsoever. Because of its simple architecture and loosely coupled
services, the Spider itself can operate just fine in both
environments simultaneously. We didn't have to write
a new access point or code a new UI or even make any configuration
changes. Even better, we were able to take a single application from
our first chapter and repurpose its internal services to two
different endpoints without much work. It's good to
step back every now and again and smell the roses, just to realize
what a little forethought and adherence to simple principles gets

10.4.4 Principles in Action

Keep it simple: use system-provided scheduler and existing
console-based access point to application

Choose the right tools: schtasks,
cron, ConsoleSearch

Do one thing, and do it well: neither Spider nor
jPetStore worry about the scheduling of the
indexer; the scheduler only worries about the index, not the rest of
the functionality

Strive for transparency: the scheduler knows nothing about the
implementation details of the indexer or even where the results of
the indexing will end up: it's all handled in

configuration files

Allow for extension: none

/ 111