number 9

My (b33) glassfish v2 build
is a bit long in the tooth
(the latest promoted build is b50).

It bundles a JVM, but the nightly builds don’t, so my first pre-upgrade step is to install a standalone 1.6 JVM.

a communal JVM

I’ll need a few zones for playing with glassfish clustering and they’ll all need JVMs. Ideally, we want a central copy in the global zone that is visible from all the local zones.
That way:

• all zones use the same on-disk binaries, so the VM system can re-use text segments across your zones (and you save a bit of disk)
• you centralize upgrades/patches in the global zone
• a readonly JVM encourages (ok, forces) you to put things like SSL keys and libraries in your glassfish domain directory, where they should be.

neatly packaged

Originally, this ‘howto’ involved getting the tarball from the JEE page, installing it to a zfs filesystem and loopback mounting it into each zone read-only.

Today, I realized the Solaris packages for JDK 1.6 give us all the benefits of that with none of the hassle. They’ll install in the global zone and be visible (as part of /usr) in all local zones. I won’t even have to restart the zones.

Get JDK 6u1 from the Java SE download page
(the Solaris x86 packages – tar.Z on the ‘Download’ page) .

Extract it In the global zone and add the packages it contains:

vera # uncompress jdk-6u1-solaris-i586.tar.Z
vera # tar xf jdk-6u1-solaris-i586.tar
vera # yes | pkgadd -d . SUNW*

It’s now visible in all the zones:

vera # zlogin goldfish
goldfish # java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

The only minor niggle is that the /usr/java symlink can’t be edited in the local zones, but it’s easy enough to set a PATH explicitly if you want a different JVM.

/j2ee/bin/asupgrade kept insisting
DISPLAY wasn’t set.
I hanen’t installed X on this box so that’s hardly suprising.

To get X11 forwarding working, I had to add a few packages:

vera # pkginfo -d . SUNWxwfsw SUNWxwice SUNWxwrtl SUNWxwplr SUNWxwplt
system      SUNWxwfsw X Window System platform required font software
system      SUNWxwice X Window System Inter-Client Exchange (ICE) Components
system      SUNWxwplr X Window System platform software configuration
system      SUNWxwplt X Window System platform software
system      SUNWxwrtl X Window System & Graphics Runtime Library Links in /usr/lib
vera # yes | pkgadd -d . SUNWxwfsw SUNWxwice SUNWxwrtl SUNWxwplr SUNWxwplt

After all that, it turns out

1. asupgrade doesn’t do what I thought it did
2. I could’ve just used /j2ee/bin/asupgrade—console

Ho hum

Now my appserver
and database
are setup, I can install something.
Right on cue, Roller 3.1 shipped .
Looks pretty good too.

WARmonger

I want to deploy from a WAR file, but they don’t ship a prebuilt one
(a GPL thing ?).
So I’ll make my own
(this isn’t necessary – glassfish can deploy from a webapp directory easily enough – it just feels neater to me somehow).

planb:/tmp $ wget http://www.apache.org/dist/roller/roller-3/v3.1.0/bin/apache-roller-3.1.tar.gz
planb:/tmp $ wget https://roller.dev.java.net/files/documents/190/51361/required-jars-roller-3.1.tar.gz
planb:/tmp $ tar zxvf apache-roller-3.1.tar.gz
planb:/tmp $ tar zxvf required-jars-roller-3.1.tar.gz
planb:/tmp $ cd apache-roller-3.1/webapp/roller/

Jarring up apache-roller-3.1/webapp/roller will make a WAR. I need to make a couple of tweaks first.

this is how we (configure) Roll(er)

change the salt

First, edit WEB-INF/security.xml and change the ‘salts’ .

(optional) install textile plugin

Textile support is always nice (even without live preview):

planb:roller $ cd WEB-INF/lib
planb:lib $ wget https://roller.dev.java.net/files/documents/190/56103/textile-plugin-3.1.tar.gz
planb:lib $ tar zxvf textile-plugin-3.1.tar.gz
planb:lib $ mv textileplugin/* .
planb:lib $ rm -r textileplugin textile-plugin-3.1.tar.gz
planb:lib $ cd -

To enable the textile plugin, you can tweak roller-custom.properties
or download mine
(which also tells Hibernate that I’m using a postgresql database) to somewhere in your classpath:

planb:roller $ cd WEB-INF/classes
planb:classes $ wget http://files.hellooperator.net/solaris/glassfish/roller-custom.properties
planb:classes $ cd -

(optional) install extra themes

Add some bundled themes if that’s your thing (you might want to prune some out, there are 20+ themes in the bundle):

planb:roller $ cd themes
planb:themes $ wget https://roller.dev.java.net/files/documents/190/56087/opt-themes-roller-3.1.tar.gz
planb:themes $ tar zxvf opt-themes-roller-3.1.tar.gz ; rm opt-themes-roller-3.1.tar.gz
planb:themes $ cd ..

(not really optional) setup mail support

Roller depends on JavaMail for email notifications of comments, inviting people to become
authors, etc.
The relevant part of WEB-INF/web.xml is inexplicably commented out (apparently Tomcat doesn’t need this).
If you want to send any mail, uncomment the following chunk:

   planb:roller $ tail -15 WEB-INF/web.xml
   ....
       <resource-ref>
           <res-ref-name>mail/Session</res-ref-name>
           <res-type>javax.mail.Session</res-type>
           <res-auth>Container</res-auth>
       </resource-ref>
   ....

make the jar

Create the JARfile and copy it up to the appserver:

   planb:roller $ pwd
   /tmp/apache-roller-3.1/webapp/roller
   planb:roller $ jar cf ~/roller31.war .
   planb:roller $ scp ~/roller31.war  root@goldfish:

the little schema

Roller has db creation scripts for most databases (here’s one I made earlier )

planb $ scp  WEB-INF/dbscripts/postgresql/createdb.sql root@goldfish:
planb $ ssh root@goldfish
goldfish # PATH=/usr/postgres/8.2/bin/:$PATH
goldfish # psql -h elephantom.mydomain -U dbuser zonedb < createdb.sql
....creation output snipped....
goldfish #

configure glassfish

asadmin is great if you don’t like web frontends (or taking screnshots..). You can do all the setup from the CLI.

  planb $ ssh root@goldfish
  goldfish #

install a jdbc driver

PostgreSQL ones here .

   goldfish # cd /domains/rollerdisco/lib
   goldfish # wget http://jdbc.postgresql.org/download/postgresql-8.2-505.jdbc3.jar
   goldfish # svcadm restart rollerdisco

NB: I’ve put the JAR into the domain directory so it won’t be lost on server upgrades

create a connection pool

To create a pool called ‘rollerpool’ (’asadmin help create-jdbc-connection-pool’):

   goldfish # /j2ee/bin/asadmin create-jdbc-connection-pool \
   --user admin --passwordfile /domains/rollerdisco/.aspass -s \
   --datasourceclassname org.postgresql.ds.PGSimpleDataSource --restype javax.sql.DataSource \
   --steadypoolsize 4 --maxpoolsize 12 \
   --property portNumber=5432:password=sekrit:user=dbuser:serverName=elephantom:databaseName=zonedb \
   --description "Roller Connection Pool" rollerpool
  Command create-jdbc-connection-pool executed successfully.
  goldfish #

Using any datasources other than PGSimpleDatasource with my glassfish build (b33) didn’t work. I got a lot of

java.lang.Exception: Doh! Couldn't instantiate a roller class

Bug 2779 has all the gory details. There is a workaround in b46, which we’ll be upgrading to in my next gf post.

create jdbc resource

Out of the box (WEB-INF/sun-web.xml), Roller looks
for a pool called ‘jdbc/rollerdb’. So ‘tag’ our connection pool with that name by creating a JDBC datasource and roller will use it:

   goldfish # /j2ee/bin/asadmin create-jdbc-resource \
   --user admin --passwordfile /domains/rollerdisco/.aspass -s \
   --connectionpoolid rollerpool jdbc/rollerdb

create a javamail session

We need a JavaMail session with the name we specified in Rollers web.xml earlier. This one talks to a local MTA:

   goldfish # /j2ee/bin/asadmin create-javamail-resource  \
   --user admin --passwordfile /domains/rollerdisco/.aspass -s  \
   --mailhost localhost --mailuser required_although_i_dont_use_smtp_auth --fromaddress gfadmin@yourdomain.com mail/Session

deploy it

You can autodeploy the WARfile (by copying ‘yourwebapp.war’ to /domains/rollerdisco/autodeploy),
but that’ll run the webapp at /yourwebapp. Instead, I’ll use asadmin deploy :

   goldfish # /j2ee/bin/asadmin deploy \
   --user admin --passwordfile /domains/rollerdisco/.aspass -s \
   --upload --contextroot '/' /root/roller31.war

(’—upload’ physically copies the warfile into the appserver, rather than deploying from it ‘in situ’)

can you hear me now?

If you autodeployed, browse to :

http://yourserver:8080/roller31/

and register an admin user, create blogs, etc.

I setup glassfish running on port 80 so
I can just go to

http://goldfish/

One gotcha: roller creates directories under roller-data/ in the glassfish users home directory.
Just don’t wonder what it is and delete it (bad things happen, trust me).

UPDATE:

I’m an ex-tomcat user and I’ve seen JVMs bleed memory over time, so I put a resource control of around 600Mb RAM on the zone. It seems to be using about half that, and hasn’t grow in the last few weeks.

Ubuntu put their postgresql client bits where gems can’t see them.

Google turned up the answer in the past, but today I had to figure it out myself.
So for the next time, here’s how to get the client bits needed for a gem build.

planb $ sudo apt-get install  postgresql-client-8.2 libpq-dev
planb $ sudo gem install postgres -- \
--with-pgsql-include-dir=/usr/include/postgresql \
--with-pgsql-lib-dir=/usr/lib/postgresql

Rails (well, rake) calls out to dropdb and createdb to flush the test database. If you want to do TDD, make sure the rails DB user has ‘createdb’ rights and owns the 3 databases:

postgres@elephantom $ createuser -PREdS railsguy
postgres@elephantom $ createdb -O railsguy live
postgres@elephantom $ createdb -O railsguy dev
postgres@elephantom $ createdb -O railsguy test

dropdb/createdb need access to the ‘postgres’ database to operate. Until you know this,
errors like

FATAL: no pg_hba.conf entry for host “1.2.3.4”, user “railsguy”, database “postgres”, SSL off

will have you staring at database.yml until your eyes cross.

you might as well have a pg_hba.conf line like

#TYPE  DB   USER       CIDR         METHOD
host   all   railsguy    1.2.3.4/32   md5

and have done.