I’ve been doing a bunch of portlet development recently. Most recently, I’ve focused on portlets that can work in an Oracle portal environment.
As with recent JSR-168 Portlet development, the goals involved not just creating a semi-useful portlet, but also learning a bit about the difficulty and feasibility of developing in a particular environment, and creating some documentation about the process and any gotchas that I ran into.
With that in mind, I set off to “port” my Recently Updated Pages portlet so that it works in Oracle. Now, it’s already a JSR-168 portlet, so that should help tremendously all on its own. It was also suggested that I focus on using JDeveloper and leveraging it’s Faces To Portlet Bridge.
I started by downloading JDeveloper and attempting to walk through it’s Tutorial.
JDeveloper is an IDE. It’s got a lot of Wizards and Visual Studio-esque GUI designing parts. It also comes with an embedded Oracle Webcenter Server (aka: Webcenter Preconfigured OC4J). Webcenter is an application server. You wouldn’t use the embedded one that comes with JDeveloper for production, but it’s handy for development. Or at least that’s the theory. Contrary to what I might have thought originally, rather than developing for the Oracle Portal application, the current idea is to develop portlets for this Webcenter, which seems to do alot of things at once, including serving portal applications.
Unfortunately, JDeveloper runs rather strangely on my Mac. Which is to say that the embedded webcenter was rather reluctant to appear. I mean that quite literally, the server start/stop icons simply would not be loaded into JDeveloper’s menus and toolbars about… 80% of the time. The reason for this behavior remains a mystery for me to this day. After poking at the problem for a considerable chunk of time, I posted to the JDeveloper forum, but there was no help for me there. I could have tried the OC4J forum or the Webcenter forum, but by that time I had given up, and instead installed VMware Fusion (beta), with Fedora Core 6 on top of that. JDeveloper runs quite consistently and gives me (almost) no trouble at all in that environment.
More on Webcenter
Webcenter is not a portal application. It’s an application server. Which is to say: part of what I find interesting (read: annoying) about this whole Webcenter application server thingy as opposed to just having a portal app to develop on is that, as far as I can tell, I’m expected to write the portal app as well as the portlet for the portal app. So, for example, when I developed the Recently Updated Portlet for Liferay, I didn’t have to worry about logins and security and such: it comes with the portal app. Why this is important is that it makes using some of the standard portlet features (edit mode, for example), rather easy. The issue being that in order for a portal app to allow the edit mode to be available, it has to be able to uniquely identify the user. This means the edit mode is only availble to logged in users. So when I try to port the Recently Updated Portlet to a Webcenter app, I am now faced with the choice of either ignoring customization for the moment, or learning how to deal with Webcenter’s login/security framework. Yuck. Since I was on a prototype mission, I left the customization out for the time being.
More on JDeveloper
But is JDeveloper an IDE? Eh. Sort of. It has some decent portlet Wizard creation features. And the embedded server seems to do what it’s supposed to, but it’s not much of a contender in the IDE world. Some things that were truly unimpressive:
- If I reference a non existent object that I plan to create soon, just not this second, the IDE does it’s appropriate syntax highlighting thing. Red underlines! Bad reference! So that’s fine, and appropriate. What’s not fine is that if I create the object later, the IDE won’t stop complaining about the “bad” reference. Even if I remake the project, and the compiler reports no errors, the IDE apparently cannot figure out what the reference refers to. To fix this, I have to delete the offending code, and retype it in.
- Similarly, if the classpath doesn’t have a particular library that I’m trying to use. I might notice this, after I’ve written some code that refers to it. For example: import org.apache.log4j.Logger; Adding log4j.jar to the classpath is not always sufficient to make the errors go away. I have been required to save and close the text editor window, and reopen it to get JDeveloper to stop complaining.
- On another note, settings I can manipulate in a Wizard are not necessarily available as editable later. So, I don’t have a problem with mucking around in xml files for the purpose of setting properties, but if the wizard created the XML file, I don’t know what else it’s created. This makes the fabulous creation wizard less useful. If I can’t go back and make changes later, I might as well just do it from scratch by myself. Let me rephrase that: I’d rather do it from scratch by myself. At least I know what I’ve done.
Error handling was also a little unpleasant, as exceptions could be logged in several different places, and the exceptions oracle would throw were often reported with very little useful information.
And a screenshot…
It’s not pretty, but it works: