• Search for:
• 
  This work is licensed under a Creative Commons Attribution 2.5 Canada License.

• Similar Posts

  • WebObjects Deployment and Servlet Single Directory
  • Tomcat ♥ WebObjects?
  • WebObjects officially cross-platform again
  • bbum’s blog-o-mat: WebObjects Pub Night @ WWDC 2005
  • WebObjects 5.2.3 Update ate my StartupItem

• Pages

  • About
    • Bookshelf
    • Colophon
    • Comment Community
    • Contact
    • Music
    • My (not so) Secret Identities
    • Presentations
  • Archives
  • Asides
  • Photos
  • WordPress
    • Akismet Credit Inserter
    • Post Revision Display

• My Other Places

  • Mindfulseeing.com (photoblog)
  • Flickr/dnorman
  • Teaching & Learning Centre
  • The University of Calgary

• Recent Comments

  • Alan Levine on Is Flutter a CCK for WordPress?
  • Chris Lott on on the insanity of an automaker bailout
  • Chris Lott on content is not enough
  • So much to write about, so little time « Random Thoughts on content is not enough
  • Alan Dove on How to migrate from Drupal 5 to WordPress 2

• Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

I’d never tried deploying a WebObjects app under Tomcat (or JBoss, or any other J2EE container) before. I’d always just stuck with the built-in WebObjects appserver, and did the config/management in JavaMonitor. Well, it’s now a Really Good Idea™ to make sure any app you want to deploy on non-MacOSX boxes will work in the servlet engines.

So, I did a quick RTFM. (twice, because it’s taking longer for it to soak in after midnight after a busy day of WWDC) Then I twiddled the appropriate bits in my XCode project build settings. Built the .war bundle. Downloaded Tomcat (for servlet spec 2.2), copied the .war into the webapps directory, and lit it up. It just worked. Mostly. Except for funky CSS stuff (because I don’t have any freaking idea how to deploy a Tomcat/WO app, and stuff that’s normally vended via Apache is now just firing 404s).

But, what I care about is that it works!!! We’ve now got (ok. it’s been in WO for a long time now, but I just took advantage of it - cut me some slack) what appears to be an easy way to deploy a WebObjects app on any platform that can run Tomcat. That’s pretty sweet. We’ll be hitting the WebObjects Lab this morning to get some more stuff figured out, but this is looking promising now!

The WWDC session on deploying WO apps on JBoss was pert’ near useless. I did manage to make a bee-line to the mike for Q&A to ask wtf the deal was with cross-platform deployment.

Just to document the event:

OK. Now to sleep.

Someone on the WebObjects-Dev list, known only as “LD” just posted a tip about getting CodeSense completion working in XCode2 for WebObjects code. I took his tip and wrote an easy-peasy shell script that got the job done on my 2 machines.

If you need to enable CodeSense completion for WO, just grab a copy of this script, and run it in Terminal.

$ ./xcode_webobjects_codesense

You may first need to chmod +x xcode_webobjects_codesense first, to get it executable, but that’s about all.

Thanks to LD for the detailed description!

David just published a great post on developing with WebObjects. He really boils down the WebObjects development experience into a few bullet points, which I will copy/paste here for searchability…

The last point is really the best one - I’ve come across this so many times on CAREO and Pachyderm. We’ll be building away and I’ll just stop and say something lame like “Wait - this is getting too complicated. There has to be an easier way…”

Lazy binding is the smarter way to initialize variables only once, and only when needed. David LeBer just posted a couple of articles showing how lazy binding is useful in WebObjects apps.

• Lazy WOComponent ivar initialization
• Programatically creating a WODisplayGroup

Well, not exactly alive, but it’s working. It’s freaking working! I can now insert new records (creating new xml documents) and save them, run queries, edit records, and save those changes. Whew.

There is some final cleanup I want to do (finish migrating from DOM4J to JDOM, clean out all of the debugging spaghetti outputs, and comment the heck out of it), then I’ll package it up and drop it on Sourceforge.

This has been one of the most frustrating projects I’ve ever done (and I’ve been involved with some doozies). It was frustrating simply because I wasn’t able to grok some of the finer points of EOF’s behind-the-scenes magic. Thanks to King for providing insight (it wouldn’t have ever worked without his guidance!)

I’m completely sure there is some stuff I’ll need to modify, and it’s entirely possible I’m doing stuff the Wrong Way, but it’s working well enough to be used, and that’s what counts…

UPDATE: Just updated the adaptor to use an EO_PK root of the current database, which will increment primary keys in a predictable way. Very cool. Works quite nicely. Now to generate some metrics on the whole operation. Tomorrow…

Well, breakthrough may be a bit much, but we did figure out some stuff today, and it’s going to work quite well…

King just spent an hour with me pouring over the JavaXStreamDBAdaptor code, trying to help me figure wtf was going on (i.e., it wasn’t behaving as expected, leaving it unable to properly insert new documents).

We were looking at the code, and then King had an idea. “Open the EOModel for the xml database,” he said. I cracked it open. “Try it with the _gid attribute set a a non-class-property.” OK. I hit the little diamond widget to tell EOF not to let me access the _gid primary key attribute directly. Recompiled, tweaked some code, and BOOM. It was kinda sorta working. Almost.

The hard part, that I’d been struggling with for the entire week, was basically caused by approximately 30 pixels of diamond widget in EOModeler. 5 days of feeling like an incompetent bumbling moron, caused by a checkbox. Not sure if that clears me or validates the feeling…

It’s not completely working now, but I’ve got a very clear path in front of me, and know exactly where stuff should go. I’m going to try to get to some of it this weekend, but that may prove difficult (with Evan’s second birthday party on Sunday! WOOHOO!).

During our latest Pachyderm development sessions, that pesky EOModeler-deletes-the-.svn-directory issue reared it’s ugly head. I was using the workaround (rename the “good” eomodel file, checkout a new one, move the .svn from the new copy to the “good” copy, nuke the new one, rename the “good” one back to the proper filename), and I accidentally deleted the “good” model file - blowing away a couple hours of carefully saved work. Doh.

King to the rescue! He just whipped up the EOModeler SVN Patch Application Enhancer to prevent the nuking of the .svn directory within the .eomodeld directory.

If you use WebObjects and Subversion, grab a copy of this patch! It will save you time, grief, and grey hair.

UPDATE: King just sent me a URL to another project that does the same fix-EOModeler thing… This one was created waaaay back in February 2003. Doh.

UPDATE 2: Another way may have been to use the rmm utility that moves things to the Trash instead of nuking them instantly… I’ve installed rmm, and will try to be using it instead of a forced recursive sudo root rm command. Sure, it’s like having training wheels, but also like having a safety net

Just a note to myself to buy Practical WebObjects (found out about the book here. From the book’s page:

It also goes into Unit testing, Kerberos authentication and a bunch of other intermediate/advanced topics. It’s about time there was a book that was more than a tour of WebObjects Builder…

I know, I know… I said I wasn’t planning on switching any time soon… What can I say? I was reading through the Wordpress site, looking at the docs, etc… and thought it looked very compelling. Kinda like MovableType done out in the open.

Anyway… I really liked the layout and functionality of my Blosxom weblog, so I’ll be slowly migrating this Wordpress site to match that.

Sorry for any inconvenience with the move. Google will catch up in a couple days…

Testing update via Ecto…

I finally got a version of the JavaEOXMLSupport.framework working to the level that it could actually be used in a project. The previous version was usable for read-only cases, but was pretty useless for editing/writing XML.

I had to rethink the strategy a bit. The previous strategy treated every Element in a document as an individual EO. That works conceptually, because it’s easy to model (you can model the XML schema in EOModeler, and use that, in theory - King even wrote a tool to generate an EOModel from a schema!) It’s harder to implement this, however, because individual EOs are somewhat separated from the DOM - they don’t know where they are within the DOM, etc… Also, in this model, it was very hard to add new elements to an existing document. Say a document didn’t have a keyword when it was pulled from the database. This strategy makes it difficult to add a classification.keyword.string if there isn’t one already… (how do you add an element into a DOM tree when you don’t know where you are in that tree?)

The current strategy is to treat the XML document itself as the EO, and to teach the Key Value Coding methods in that EO class (EOXMLRecord) to dig into the DOM as needed, and provide a nicely wrapped EOXMLElement class for each DOM Element ( the EOXMLElement wrapper provides Key Value Coding interface on the DOM Element so it plays nicely with WebObjects). This 2-class strategy (one to integrate with EOF, one to integrate with DOM) also makes it drop-dead simple to add new elements - they’re created on the fly when requesting their values, so it should Just Work if you try to add an element where there isn’t one (like adding a new classification.keyword.string, for instance…)

I’m 100% sure there are some Hummer-sized caveats and special cases and bugs looming in there, but the hard part is done - it works! I’ll clean up the code, write some documentation and sample apps, and update the Sourceforge project as soon as I get a chance (may not be until September, though, since I’m being simultaneously buried by the Pachyderm…)

← Previous Page — Next Page →