The following instructions are some great cheat sheet instructions for getting OWCS 11gR1 up and running on a Mac. I use Tomcat & HSQLDB. Installation works perfectly fine.

These instructions should suffice for setting up a complete installation of Oracle WebCenter Sites 11gR1 on Mac OS X Lion. It also includes the steps required to configure CSDT through Eclipse.

It is assumed that nothing is installed at all - no database, application
server, or even Eclipse.

Download the scripts and instructions here. (right-click & “save as” on a PC)


mkdir /Users/tfield/Metastratus/OWCS11gR1/
mkdir /Users/tfield/Metastratus/OWCS11gR1/home
mkdir /Users/tfield/Metastratus/OWCS11gR1/shared
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base/conf
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base/logs
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base/webapps
mkdir /Users/tfield/Metastratus/OWCS11gR1/catalina_base/work
mkdir /Users/tfield/Metastratus/OWCS11gR1/db
mkdir /Users/tfield/Metastratus/OWCS11gR1/installer
mkdir /Users/tfield/Metastratus/OWCS11gR1/workspace


Download from

sudo mkdir /usr/local/hsqldb
sudo cp ~/Downloads/hsqldb.jar /usr/local/hsqldb/
cd /Users/tfield/Metastratus/OWCS11gR1/db
chmod +x *.sh
java -cp /usr/local/hsqldb/hsqldb.jar org.hsqldb.Server -database.0 file:csdb -dbname.0 csdb



sudo mkdir /usr/local/apache-tomcat-6.0.35
sudo ln -s /usr/local/apache-tomcat-6.0.35 /usr/local/apache-tomcat
cd /usr/local/apache-tomcat-6.0.35/
sudo mv ~/Downloads/apache-tomcat-6.0.35.tar .
sudo tar -xf apache-tomcat-6.0.35.tar
sudo rm apache-tomcat-6.0.35.tar
sudo mv apache-tomcat-6.0.35/* .
sudo rmdir apache-tomcat-6.0.35


sudo cp /usr/local/hsqldb/hsqldb.jar /usr/local/apache-tomcat/lib/


See attached,, for customizations
relating to setting environment params, classpath, etc.

cd /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin
sudo cp -R /usr/local/apache-tomcat/conf/* /Users/tfield/Metastratus/OWCS11gR1/catalina_base/conf/
sudo chown tfield /Users/tfield/Metastratus/OWCS11gR1/catalina_base/conf/*
sudo cp /usr/local/apache-tomcat/bin/ /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin/
sudo cp /usr/local/apache-tomcat/bin/ /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin/
sudo chown tfield /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin/*
cd /Users/tfield/Metastratus/OWCS11gR1/catalina_base/bin
cp /usr/local/apache-tomcat/bin/ .
cp /usr/local/apache-tomcat/bin/ .
chmod +x *.sh


See attached server.xml

vi /Users/tfield/Metastratus/catalina_base/conf/server.xml




cd /Users/tfield/Metastratus/OWCS11gR1/installer
mv ~/Downloads/WCSSites11 .
cd WCSSites11/ContentServer
chmod +x *.sh
vi cscore.xml

  • Add “Mac OS X64″ to the list of platforms that can run the Tomcat package in cscore.xml (line ~526)
  • Un-comment HSQLDB from the TOMCAT package (line ~1906)



Installation Directory : /Users/tfield/Metastratus/OWCS11gR1/home
Installation Type : Single server
Shared Folder Path : /Users/tfield/Metastratus/OWCS11gR1/shared
Host Name : localhost
Port Number : 8080
Platform Type : APPSERVER
Application Server : Tomcat 6.0.32+/7.0.23+
Server Path : /Users/tfield/Metastratus/OWCS11gR1/catalina_base
Database : HSQL Database Engine
JNDI Data Source Name : csDataSource


  • download Eclipse Java EE version (Helios minimum, Juno works)
  • unzip it and move the eclipse folder to /Applications


Copy the com.fatwire.eclipsecsdt_1.2.jar jar file from the
file in the installer folder to your /Applications/eclipse/plugins folder


  • Create a new workspace in /Users/tfield/Metastratus/OWCS11gR1/workspace
  • Open the workspace
  • Open the Oracle WebCenter Sites Perspective
    (Window > Open Perspective > Other > Oracle WebCenter Sites)
  • Synchronize all files to workspace Oracle > WebCenter Sites Sync

Current snapshot builds of the GSF (as available on the GSF website) have “some issues” with the installation on 11gR1, mostly around permissions, that do not arise on 7.6. I’m working on addressing these and hope to have it sorted out in the next week or so.

Meanwhile, here are some step-by-step instructions that will take you through complete installation of the GSF on a virgin 11gR1 installation. They are aimed at a trained WC Sites administrator / developer.

If you have any questions or corrections, please let me know.


Core GSF Installation

  1. Download GSF kit from site
  2. Copy the GSF jar to war (webapps/cs/WEB-INF/lib)
  3. Copy the “gsf” folder to webapps/cs
  4. Start cs and deploy elements that ship with the GSF using CatalogMover
  5. Log in to the UI, choose Admin site and GSF application
  6. In the WEM ui, go to the WEM admin app
  7. Create a new site
  8. Add users and roles to site
  9. Add CS Admin, GSF, Contributor, and WEM admin app to the new site
  10. Add CS Admin, Contributor, and WEM admin apps to the GST site (also)
  11. Log out & log in (this might be done in one step)
  12. Select GST site and open the CS Admin app
  13. Using the “replacement tree”, select Sites > GST > Asset types, and disable all asset types. Repeat the process and ENABLE all asset types starting with GST*
  14. In the admin ui, select Sites > YOUR NEW SITE and enable asset types GST*, CSElement, Template, SiteEntry, Page, Page Attribute, Page definition, and AttrTypes
  15. Search for all attributes & share them with your new site! Repeat for definitions.
  16. In your site, create a new CSElement called exactly: “GST/Dispatcher”. It will be automatically populated. Delete the XML comment if there is one. Change the action from “…ActionController” to “” (for now - let’s start simple)
  17. Create a new SiteEntry called “YOURSITE/Dispatcher” using the element you just created. Wrapper, uncached. (This is a workaround to the fact that the SiteEntry asset is created but is not accessible in your site)

Configuring the GSF Vanity URL support
This topic is a little more involved and is not necessary for initial development, so I’ll cover it in another post, later.

Creating a sample site in the GSF

  1. Create a new GSTAttribute called “body”, make it text.
  2. Create a new GSTDefinition called “MyArticle” containing the following:*h1titlte,*metatitle, *metadescription, linktext, body, *metakeyword
  3. Create a new Flex child under GST Attribute called YOURSITEContent and enable it for your site, edit the asset type so that it “can be child”
  4. Create a new template called “Microsite” for asset type YOURSITEContent and subtype “MyArticle”. Usage: Layout; type: JSP; code: from microsite.jsp file in the GSF kit; cached.
  5. Create a new pageDefinition called “Blank”
  6. Create a new named association under “Page” called “-”, Description “Contains”, Child Asset “Any”, Page Subtypes “Blank”. Exists, Multivalued. (this retrofits the unnamed association into the 11g page asset)
  7. Switch to contributor UI and create a new YOURSITEContent (definition MyArticle)
  8. Save it, then select a template (Microsite), then save it AGAIN
  9. Create a new Page called “MainNav”
  10. Create sub-pages under MainNav called “Home”, “About”, “Contact”
  11. Hook up your new MyArticle to the Home asset’s Contains slot.
  12. Create 2 new MyArticles and add them to the About and Contact Contains Slots.
  13. Once this is finished, your microsite template should render your site and create a full nab bar

All done!

The GST Site Foundation (”GSF”) was designed for FatWire Content Server 7.6, and it has proven very useful for many customers. With the release of Oracle WebCenter Sites 11gR1, some significant changes were made that impacted the GSF. The biggest by far is the change to the role of the Page asset.

Pages in 11gR1 are “Complex Assets” that are “templatable”, which means they can be assigned attributes via definitions. (Strictly speaking they are not Flex assets, because they can’t be assigned parents, be involved in related item recommendations, among other things, but they do share this definition feature.) In addition, the UI integration of the Page asset in the new Contributor UI is much tighter than it was in the Advanced UI in Content Server 7.6.

The GSF assigned the 7.6 Page asset the role of “provider of navigation structure” only. In 11gR1, the Page is positioned to be a web-referenceable asset (”WRA”) itself. This means that the 11gR1 is architecturally incompatible with the GSF’s use of the Page asset. An adjustment must be made.

Strictly speaking, the GSF 1.3 will work on 11gR1. Instructions on how to do it will be provided in the next post. No changes need to be made to the GSF architecture, and all previous sites will continue to work.

GSF 1.3 is compatible with Oracle WebCenter Sites 11gR1 for sites built with the 7.6 / GST 1.0.3 architecture specification.

To take advantage of the NEW features in 11gR1 with the GSF, some changes to the architecture are required. Primarily, it is necessary to expand the role of the Page asset to allow it to also be a WRA. Once this is done, Pages can take advantage of full WRA roles. There are a some code issues that arise though when switching architectures. The <gst:navigation> and <gst:multilingual-navigation> tags stop working properly, because they expect the Page asset to have an unnamed association to the WRA, and we don’t have to do this in 11gR1 anymore.

We are planning to release a final 1.3 edition of the GSF in late July, 2012 (it’s almost ready to go, we’re just addressing some 11gR1 installation complications). Immediately after that, a new branch will be created for version 2.0, which will include native support for 11gR1 features. Stay tuned in the month of August for details about this change.


Metastratus Web Solutions

Hello! It seems that a bit of time has gone by since I’ve dusted off this blog. A long while, perhaps, based on the number of spam comments in the moderation queue. In any event, I’m going to start again. I’ll cover several topics, but be warned, I’m going to get technical.

Over the last few months I’ve ramped up my consulting company, Metastratus Web Solutions, quite a bit, and have taken a few steps back from FatWire Software where I’ve been parking most of my working hours over the last few years. Part of that is due to the fact that FatWire was recently acquired by Oracle. (That is a whole topic itself). Long story short, Metastratus is now an Oracle Gold partner and I’ve set out as an elite team of WebCenter Sites (formerly FatWire Content Server) specialists, to help customers with their implementations.

That’s going well. We were lucky in that we hit the ground running. Metastratus has been in operation for almost two years now and we have a team of 5 today, myself included. In the last couple of months, we’ve opened a US company, have started hiring, and began building relationships with several key partners in this small but rapidly growing community. And we’re hiring.

I must admit that getting all of this set up has been a huge amount of work, and so it’s really at the front of my mind a lot these days. Consequently, it’s going to probably dominate the blog for a bit. But besides just the whole setup topic, I’ll be posting technical topics regularly, and I won’t be able to resist the occasional personal post too. Some of you know that I’ve been pretty involved in the creation of the GST Site Foundation (”GSF”), so you can look here for posts on that topic too.

So that’s the intro for now. Watch this space, and please don’t hesitate to comment below.

As for now, its’ time to head home to prepare for a concert! The Etobicoke Community Concert Band is performing its first series concert, “From Rags to Riches”, tonight at ECI. It’s my first concert since coming back after a brief hiatus, so I’m looking forward to it. Very short rehearsal schedule though so we are hoping for some good celestial alignment (today is the Rapture (revised) after all).

Over the last several years, I’ve managed to migrate my mac through hardware updates and OS updates without having to rebuild my system from scratch. Pretty cool, I thought - I used to have to do that about once every nine months on my PC.

Well, this August I finally bit the bullet. I wanted to clean out some unused but obscure files and basically get my system humming again. So, I fired up SuperDuper!, imaged my Mac, and then popped in my system disk and wiped it completely clean.

I installed Mac OS X 10.4 (Tiger) but first I had to choose the file system. I noticed that I now had the choice of selecting HFS+ (Journalled) (case-sensitive) that I don’t remember seeing earlier. Interesting. A case-insensitive file system can be really annoying - as a Java developer working on some pretty old code, I’ve got the infamous COM/com package naming convention issue to deal with among other things. When I rebuilt my computer, I went for the (case-sensitive) option to see how it would go.

I quickly installed all of my apps (a cookbook for rebuilding your computer from scratch is a handy file to keep on your hard drive just in case you need to actually use your backups now and then). After a week or so of testing, I was satisfied that all was well. This was great - I now had a case-sensitive file system and a regular Mac and everything just worked.

… until someone asked me to work on a web page using Dreamweaver.

I bought Adobe Creative Suite 3 Web Premium basically as soon as it came out. Native Intel support was key for me, and there were some pretty cool features in Dreamweaver, FireWorks and Photoshop that I wanted to try out. I had it installed on my mac before the rebuild, but left it to last afterwards because I don’t use it all that much and it really takes a long time to install anyway.

Bad idea. Apparently CS3 won’t install on HFS+ (journalled) (case-sensitive). I should have expected this. Dreamweaver 8 didn’t work on a case-sensitive file system either, but I figured Adobe would have fixed this when they bought Macromedia.

Long story short, I needed to reformat my hard drive to HFS+ (journalled) just to be able to install CS3. I couldn’t even install CS3 on a dedicated partition - it needs the system partition to be case-insensitive.

I thought about it for a bit and then eventually fired off an email to Dave Nanian at Shirt Pocket. The plan was to image my case-sensitive drive with SuperDuper!, wipe my Mac, reformat the drive with a case-insensitive file system, then restore from my image. Dave thought it would work so I set my plan aside for 3 months till I had either a huge need or an extra half day to do the conversion. (100GB takes a long time top copy back and forth).

Well, yesterday I tried it out and after working through a couple of glitches, it worked! Perfectly!

The technical instructions:

Steps to convert your HFS+ (journalled) (case-sensitive) file system to a HFS+ (journalled) file system without having to re-install your whole OS

- Install ShirtPocket software’s SuperDuper! Pay for it.
- Create a full image of your hard drive on a remote volume using SuperDuper!’s standard mechanism. Use a remote volume, like another firewire-equipped Mac or an external hard drive. I chose to skip all the caches but that’s up to you - the default settings work fine.
- Create a second image just in case
- Test out the image: open it and spot-check some of your files. They’ll work but it’s comforting to see them actually working.
- Insert your Mac OS X disk (or the restore CD that came with your Mac) and restart, holding down C
- Pray
- Open Disk Utility and reformat your drive using HFS+ (journalled). Name it the same thing as it was named previously.
- Plug in the drive holding the backup into your Mac. Booting from CD you don’t get network support, so if your image is on an external Mac, like mine was, you’ll have to boot the second Mac in FireWire Target Disk Mode.
- Select your drive and click on the restore tab. Navigate to your image and select it, then drag your target disk onto the Destination box.
- Make sure erase is unchecked; click restore.
- Reboot
- Rejoice
- Flame Adobe about the case-sensitivity issue

Now, to be honest, the above instructions were my plan. It didn’t quite go as planned. I had 3 issues.

First, I had used a sparseimage (read/write image) in SuperDuper! because it’s the default recommendation. The problem is, Disk Utility doesn’t like restoring from a sparseimage, and these images are greyed out. I ended up having to convert my sparseimage to a dmg using Disk Utility on my other Mac (a G5 iMac) (don’t try doing this over the network if you place any value on your time). That worked fine.

The second problem I had was a little more disturbing. Disk Utility told me to drag my target drive onto the Destination box, but there was nothing to drag! I could not figure out how to restore back onto my main hard drive. Nice: I had the drive wiped but could not restore it. I never found out how to do this but did find an easy way to do this through the command-line version of Disk Utility. As such, the instructions above are amended as follows:

- Plug in the drive holding the backup into your Mac. Booting from CD you don’t get network support, so if your image is on an external mac, like mine was, you’ll have to boot the second Mac in FireWire Target Disk Mode.
- Quit Disk Utility
- Open Terminal
- Type the following:
# asr /Volumes/MountedExternalDrive/path/to/your-image.dmg --target /Volumes/YourDestinationDriveName -noverify
and press return
- Wait a really long time. For my 100GB 7200RPM 2.5″ drive this took about 5 hours
- Reboot
- Rejoice
- Flame Adobe about the case-sensitivity issue

After rebooting, I fired up OnyX and ran basically all of the standard cleaning and maintenance jobs, the rebooted again. I figured it was worth pro-actively running some of these jobs rather than letting my Mac find issues related to obscure filesystem issues.

After the second reboot, everything was running perfectly. I was able to install Adobe CS3 and it worked.

Plus, as an added bonus, SuperDuper! recognizes most of the files on the old image as being the same as the ones on the new drive, which means my next backup was still just an incremental backup. If you don’t know what I’m talking about, read about SuperDuper! here.

That’s basically it. As far as I’m concerned, Dave saved me hours of rebuilding. Plus, having a perfect backup of my hard drive each night is good for peace of mind too. I’m not sure how SuperDuper! will play with Leopard now that it’s out (though he does talk about it here), but one thing’s for sure, given some of the upgrade issues, I’ll be running a full backup before upgrading.

Well that’s it. A successful but scary project, and now I’m back up and running… and ready to try my Leopard upgrade…


Since switching to Mac OS X 10.4’s mail client, I have noticed that my email coming through my own server has been listed as “Received” four hours later than when it actually landed in my mailbox. I thought it was just some minor issue on my desktop until I heard about this from someone else using the same mail client.

I had worked around it by having Mail display the “Date Sent” field instead of the “Date Received” field, which instead shows the time the composing mail client sent the message instead of the time my POP server received the message. But with multiple people complaining about this issue, I decided to look into it.

The problem was not immediately obvious. The email messages looked as if they were properly formatted, but after consulting the Internet Message Format specification I discovered what was happening. It turns out that my mail server was using a valid but obsolete date format to indicate the time zone. Specifically, it was displaying dates like this:

Fri, 21 Sep 2007 20:07:09 GMT

When in reality it should be displaying that date like this:

Fri, 21 Sep 2007 20:07:09 +0000

This format would have been fine too:

Fri, 21 Sep 2007 20:07:09 +0000 GMT

Section 4 of the spec specifically states that applications that conform to the specification must not generate invalid dates, but must be able to interpret them. So what does that mean?

Well, it means that my mail server was not conforming, and that my mail client ( was also not conforming. That explains why so few people ran into this issue: you have to encounter both bugs to see the problem.

So what to do? Since I run the mail server, I can at least try to configure my way out of the conformance issue. As for the Apple Mail client, well, the best I can do is report a bug (Bug ID 5503215) and hope it gets fixed. It’s a minor bug, and I assume that Apple will be able to fix it soon if it is deemed to be important enough, but it’s certainly not within my control.

Back to sendmail. Sendmail is notorious for being difficult to work with. Its configuration files are so complex that there is a second format for a “simplified” configuration file that you “compile” into the regular configuration file. A quick internet search, however, led me to the setting that controls the mail server’s time zone: You just have to define the variable confTIME_ZONE in your .mc file and set it to the right value and you’re off to the races.

Perfect, that’s just what I wanted. So what is the right value? Well, that’s another issue altogether. Sendmail documentation is not very helpful here. It provides some help but not nearly enough. Here is what I have been able to piece together:

Leaving the variable blank will use the “system’s” time zone. I assume this is what was happening on my server, but I don’t really know what this means.

Setting the variable to “USE_TZ” will cause sendmail to use the value of the TZ environment variable. The problem here is that sendmail is executed in a way that makes defining this variable in the environment a little tricky. The last thing I needed was another tricky configuration setting so I nixed this option

The last option is to set it to an actual time zone explicitly. The format for this string, however, is not very flexible. The example provided in the Sendmail Installation and Operation Guide is PST8PDT. It turns out that the format is defined like this: The first three characters are the string representation of the time zone name for standard time, the next character is a digit that represents “the difference from GMT” for the time zone, and the last three characters represent the string representation of the time zone for daylight savings time. In this case, Pacific Standard Time, 8 hours “different” and Pacific Daylight Time.

Without going on a rant about poorly conceived this particular format is, let me just say that it doesn’t quite scale very well, or apply particularly well if you want to set your server to GMT and ignore daylight savings time. RFC 2822 at least talks about several email time zone strings for Eastern, Central, Mountain, and Pacific time that conforming applications must understand, so if you’re setting confTIME_ZONE you should probably just stick to one of these values. My server is in the Eastern Time Zone so I set my value to EST5EDT.

I made those changes, restarted the server and that fixed the problem. My mail client now understands when my mail message was received properly, and my server is configured to generate date stamps properly.

To summarize, to get sendmail to emit a proper date format, add the following to your



define(`confTIME_ZONE', `EST5EDT')

then re-save it. You will then need to recompile your file and then restart sendmail by typing make install restart from your /etc/mail folder.

/etc/mail/# make install restart

At that point you will be good to go.

Happy mailing!

Welcome to my blog.

I launched this blog not because I am ready to stand up on a soapbox and start pontificating, but primarily because I once in a while have a few ideas worth sharing, or at least worth not losing.

Topics, I assure you, will be all over the map. I’ll attempt to categorize them should you want to subscribe, but please don’t expect regular updates.

Thanks for visiting, and feel free to leave your comments against any post.