Changed jobs again ... sooner than I like, but we all have our reasons.
For the first time in ages I'm working in a JEE environment that isn't WebSphere. Which means I have to get used to Eclipse without the little IBM dohickeys. From which I learned several useful things (as Pooh would say):
1. Be sure to configure Ant to use the Java environment that Eclipse uses, not another one, or compilation in Ant won't work
2. Make sure that the java environment in Eclipse is a JDK, not a JRE, or things won't compile when you use it in Ant.
Well, with Ruby anyway, at least as a scripting framework.
Learned two excellent principles for getting WebSphere to work well in on-demand virtualization environments like the Amazon EC2 cloud:
I'm changing employers, and before I did I visited the new folks to get a feeling for what I was getting into. Turns out I came away with more than I bargained for ... Danny, a client had asked Tom, a developer to look into the Amazon web services, and Tom's summary, while old news to some of you, made a major shift in how I'm thinking about system deployment.
JavaBridge is fairly well supported on a mailing list at email@example.com -- the archives are available here. Jost Böekemeier, the creator and lead developer monitors the list and frequently answers questions; in response to some of my queries on architecture and performance he made a statement that seems obvious now, but really made the penny drop for me:
Re: Php-java-bridge-users Documenting WebSphere Integration; Uses of the C or PurePHP ComponentsFrom: <php-java-bridge-users@li...> - 2007-08-14 07:50
> the php_java.dll (which I think is what Jost means by the C-based
> extension module ... is this correct?) or alternately the "pure PHP
The php_java.dll or java.so (Unix) is the Java.inc, compiled to native code, yes.
So ... the mystery is solved. The dll for windows and .so library for linux are simply compiled front ends for specific platforms; the speed improvement is the usual improvement one sees for compiled code.
The steps to integrate PHP and Drupal with Apache are well-documented in an IBM tutorial for Windows and Linux. You'll need to register for the IBM website to view it, but it's well worth the few minutes it takes. Note that these installation tutorials are part of a very good larger series on Drupal from IBM, available here as an RSS feed.
Before you begin the tutorial I'd suggest you back up your Apache configuration, in case something breaks in the course of Drupal and PHP integration.
First steps are here
In WebSphere a separate application called the Web Server Plug-In mediates between the HTTP Server and the WAS Application server, determining which URL's seen by the HTTP Server are handled directly and which are passed to the WAS application server for processing in JEE.
Well, I ran this issue to ground, and at the end of the day, while the links plugin strategy works like a charm, the web tools plugins that can work with PDT 0.7 cannot work with RSA due to a early conflict with a number of RSA's plugins, including JSF.
I submitted this situation as an eclipse bug, but (and who could blame them) the web tools maintainers pointed out that compatibility with IBM's V3.2 plug-in's was hardly their problem, and the PDT maintainers pointed out that a 0.7 release (needed because all the IBM tools target a 3.2 eclipse) is hardly theirs.
This post is mainly of interest to developers who use Eclipse, especially IBM/Rational Branded versions.
The web-based software updates/find and install features of Eclipse have significant problems resolving dependencies for additional plugins, at least in the IBM branded versions. You can work around these difficulties and bring more order and control to your installation by using the links based mechanism described below