so, i recently took some time off. as American standards go, a rather long time
off (8 weeks). instead of sleeping for the entire time (as my wife expected), i
got turned on by the idea of attacking our home network/automation system and
making it actually work. after two different (and expensive)
contractors, it still didn’t behave the way i wanted. but hey, i’m a geek, how
hard can it be? hmmmmm…
why am i telling you this? after all, you can read about “what i did on my
summer vacation” on my home blog. the
reason is that when i’m not playing amateur home automation geek, my day job
for the last 2 years has been as dev-lead for the runtime in BEA’s WebLogic
Workshop. and horror of horrors, i didn’t use WebLogic Server or Workshop in my
summer quest. i used, gulp, Apache . in my defense, i stated upfront that i
would move to WebLogic Server as soon as i could. but when would that be?
this little fact did not escape the notice of
Byron Sebastian, my boss’ boss, and
“the man” when it comes to Workshop. one of his first emails to me when reading
my home blog was “when you try switching to WLS/W, please write up your
experience because others will likely find it useful”. the end result of that
email thread was this post
the first thing i had to figure out was exactly what i wanted out of WLS in
order to make the switch. why, after all, did i start with Apache in the first
place? after all, WLS is a J2EE AppServer that is also a full featured web-
server. so what’s the problem, just install it and away you go. well, not
quite…
you have to realize that the design center for WLS is the clustered, high-
throughput and heavily transacted IT environment, and the installer is
generally focused on this case. recently, with the introduction of Workshop,
the installer works better for the developer using the Workshop IDE, but still
needs work to deliver well outside these scenarios
but neither of these scenarios was really what i wanted. the latter came
closest in that it made development easy, but i wanted more. here’s the high-
level list of what “more” was:
one thing i really wanted, that i decided not to tackle, was to support
having an RPM-based install. i thought about it, but since i don’t understand
how easy/hard it is to create an RPM i took a pass
with this loosely defined set of goals, i downloaded WLS off BEA’s
dev2dev website and dug in. the result of
my efforts can be found
here. it’s a zip file containing:
- wlsInstall: a Bash script that installs everything
- silentI.xml: an XML file used during the first phase of the install
- silentC.txt: a text file used during the second phase of the install
- default: an exploded J2EE web-app used during the third phase of the
install
- wls: a Python script that supports the “rc-script” standard for
start|stop|status
i also need to mention that i wouldn’t have gotten anywhere if it
wasn’t for the help of Raj Alagumalai. he
answered a ton of questions with way more patience then i would have shown in
his position. he really knows WLS install and setup cold. thanks Raj!
i’ve verified that this stuff works on both RedHat9 and RedHat8. it’ll even
work on RedHat7, but with RH7 you’ll need to upgrade your version of Python.
i know it works with Python 2.2, not sure how far back you can go and still
have it work. there’s also no reason WLS won’t run on
Debian or
SuSE, but i haven’t tried them. if anyone finds they work, or makes fixes
so that they do, let me know
ok, onto using this stuff yourself. do the following:
- download the zip file
and into the same directory, download
WebLogic Server 8.1. the server link provided here gets you most of the way
through the dev2dev site, but there’s a few things you need to do manually:
- on the page i’ve linked you to, you need to select the right OS. in the
dropdown, in the 2nd section labeled “WebLogic Server Package
Installer”, pick “Red Hat Enterprise Linux (2.1, 32 bit)” and then click on the
“Select >>” button to the right of the drop-down
- at this point, you will be challenged for a username and password. you
can’t download without giving marketing its due <g>. if you don’t have a
dev2dev account, getting one is trivial. there’s a register button on the login
page that lets you sign up. once you’ve either logged in or registered,
you’ll come back to the right spot in the download process
- once past that, you’ll see a page asking if you’re downloading a server
you’ve already paid for, or do you want to evaluate a server first. BEA now
provides a “developer license” where you can get and run the server for free
for 1-year, as long as you don’t “put it into production”. so just select
“I would like to evaluate this product and click “Next >>”
- you’ll now see a form asking some questions about what you want to do with
the product, blah blah blah. answer however seems best, and then click
“submit”
please note that the download process you’re forced to go through is
being streamlined and revamped, so that there will be less marketing/sales gorp
to deal with. but for now, please ignore it as best you can
- next up is the License Agreement. click “I Accept” when you’re ready
- click on the download area that is the closest match to the region you’re
in and your browser should prompt you to open or save. pick save. do not
open it yet. when saving, make sure the saved name is server811_linux32.bin
. that should be the default, but in case your browser did something
funny…
- unzip simple.zip. you want the sub-dir that’s created to be right there,
next to the server binary and the zip file
unzip simple.zip
- move into the directory that was just created (should be named simple)
cd simple
- security issue: the management password being set during this install
is weblogic, which is fine as long as your machine cannot be seen from
the net at large. WLS supports management via the browser, and you don’t want
random people on the web changing things on you if you can avoid it <g>. so
if your machine will be seen on the Internet, you should change the management
password in the silentC.txt and wls files in this directory
before proceeding with the install. just search for the word “password” and
you’ll see the values that need to change
- the next steps require root-privilege, so switch-user to root (this will
prompt you for the root password)
su --command="cd $PWD" -
- run the wlsInstall script
./wlsInstall
- at this point, WLS is installed, you’ve got a default web-app, and the
server is ready-to-run. you can start and stop the server using the service
command
service wls start
- with the server running, you should be able to type http://localhost/
into your browser and see the home page of the default web-app
- if you want the server to start during boot, use chkconfig
chkconfig --add wls
chkconfig wls on
- assuming you don’t want to have to be root in order to add content to your
web-app, you can give all users on the machine the ability to modify the web-app
with the following command
chmod -R a=rwx /bea/user_projects/domains/wls/applications/default
the directory listed here is the root of the default web-app
- within the default web-app, there’s a directory named “cgi-bin”. they way
i’ve configured things, you can place Python scripts with the extension ‘.py’
in the cgi-bin directory and then hit them from the browser and they’ll run. so
for example, if you put a Python script named ‘foo.py’ in there and then point
the browser at http://localhost/cgi-bin/foo.py, you’ll see the results of your
script. you can see what enables this by looking in
/bea/user_projects/domains/wls/applications/default/WEB-INF/web.xml at the
following lines:
<init-param>
<param-name>*.py<param-name>
<param-value>/usr/bin/python<param-value>
<init-param>
if you want to enable other script engines, just add another section like this
one with the appropriate file extension and script engine
well, that would seem to be that. a simple install, an easy way to control the
server and all on top of an industrial-strength J2EE server. cool, eh? and i’m
sure there are ways to make it simpler/easier, so if you spot any, i’d be very
interested in your input. btw, you can find the online doc for WLS 8.1
here
next up i’m going to spend some time building some samples and services that
will run live on dev2dev, which is BEA’s developer support site. i’ll be
posting the code for all of these, along with my experience in building them,
on this blog. and i will be developing all of them on top of the install
described in this post. make no mistake, this install will evolve, and it
wouldn’t surprise me if it ended up changing quite a bit over time. and i
should also make clear that anyone who would like to participate, from
criticism (you moron Rod, why did you do it that way?) through code, and
anything in between. in the end, i’m a utility junkie. i’m interested in things
that get used, that do something *useful*. we’ll see
one of the ideas i’ve got for the first online developer service to write would
be an “XML comparison” service. initially, you feed in two payloads, either via
file-upload or a web-service, and it performs an xml-wise compare and returns
the result. it could be extended over time to take a schema to optionally
perform a schema-wise compare. for example, one payload specifies a value, and
the other doesn’t, but the value supplied is equal to the default value
proscribed in the schema. from a schema-wise perspective, the two payloads
would be considered “equivalent”. what think?
did you find this useful? any ideas for improvement of the process? did it work for you (or not)?