Oracle Blog

Chris Muir's blog

Friday Aug 17, 2012

Just over a year ago Oracle released the 11gR2 branch of JDeveloper starting at version 11.1.2.0.0. The primary reason for that release was giving customer's JSF2.0 support in ADF, though our 11gR1 branch remains for various reasons.

While JSF2.0 is the primary reason to check out 11gR2, there are some minor other benefits including that of ojserver, which is ojdeploy's big brother.

I first became aware of ojserver when Oracle ACE John Stegeman mentioned it when he spotted in 11.1.2.0.0, it's come up on the ADF EMG a number of times, and I've been curious about it ever since. Part of that curiosity is peaked by the fact that ojdeploy is one of Oracle's, let's say, least loved products. I'm not utterly convinced by the naysayers' arguments about ojdeploy, but putting that aside, it does leave us wondering what ojserver does and what problem it attempts to rectify for ojdeploy.

Why ojserver was invented was to address an issue with the Fusion Applications build. To date the statistics for the size and number of libraries in Fusion Apps is rather impressive. And it is ojdeploy's task to build all those libraries and the resulting application. At one stage it was observed the Fusion Apps build times were becoming rather long, and with a bit of analysis it was determined that the start and stopping of ojdeploy for each build component was a large time sink.

Why was this? ojdeploy is ultimately a "headless" JDeveloper which requires it's own JVM to start, run and stop. As you can appreciate that lifecycle takes time. If you call it seven hundred times, that's seven hundred times ojdeploy needs to be start, run and stop. There's not much we can do about the run bit, that's the bit when ojdeploy is actually doing it's real job, but is there anything Oracle could do to fix the start and stop cycle?

Enter odeploy's big brother ojserver.

ojserver is essentially a server version of ojdeploy, in the sense that once started it stays alive and can be asked to, well serve stuff ;-) As such what you can ask ojdeploy to do is rather than build each library itself, just hand the request off to ojserver instead, which has already been started. Brilliant. We no longer have to start and stop the ojdeploy process for each build item, we just start it once at the beginning, and stop it once at the end.

To start ojserver you simply execute the following from the jdeveloper/jdev/bin directory:

ojserver -start

This will start the service on localhost port 2010 by default. You can override this by specifying the address after the -start flag. On starting the server you will eventually see:

INFO: Server ready.

We're now ready to rock n roll with ojdeploy. The following shows you an example of how to call ojserver from ojdeploy from a separate command line, note the additional -ojserver and -address flags:

In context of ojdeploy you will not see much activity in the logs. Rather all activity include build output, errors and more will come from the ojserver logs.

One thing to keep in mind is if you're accessing ojserver remotely from ojdeploy remotely, for the given paths for the ojdeploy -workspace flag and more, ojserver must have access to those paths and the source code. Remember ojserver is just a server version of ojdeploy, there's no magic copying of files between ojserver and ojdeploy, so in terms of building applications and the files it needs, it's the same as ojdeploy.

Note there is currently one known limitation with using ojserver and ojdeploy via Ant (as separate to the command line call above). At the moment the OJDeployAnt taskDef that you define in Ant to call ojdeploy currently does not support parameters for calling ojserver. ER 14464838 has been raised to address this limitation.

In the above example I've truncated some of the Ant property names using "jdev" rather than "jdeveloper" so the code will fit in the width of the blog. Ensure to double check these with your own Ant property names.