Often JEE applications contain property files with environment specific information. Because deployment should be automated, you need some way of dealing with these property files. Basically you have three options:

1. Put a default property file in the ear and edit it after deploying it to the server. This means you have to do some scripting with Perl or some other language.
2. Choose the property file to put in the ear before you deploy. If you choose this option, you need to know the correct property values in advance. Further more, you need to tell maven or ant which property file to deploy by setting some sort of environment flag
3. Store the property file on the system classpath instead of in the ear. This has the disadvantage that you need to restart the server every time you want to change something in the file.

Usually property files are application specific, so I prefer either of the first two options. The other day, however, I got a call from someone who needed to store the property file on the servers' classpath.
Of course(!?) every application server is different. In IBM Websphere you put property files in the [WAS_HOME]/appserver/properties directory and configure the server, so it knows where to find the property file.
(NB: for those of you who have been looking for this feature: it is hidden under Application Servers > [server] > Process Definition > Java Virtual Machine - Custom Properties) The Oracle application server doesn't have a folder like that, nor does it have any options to specify property file locations. So where do you put property files if you want to put them on the system classpath? The Oracle container (OC4J) has two possible candidates for this property file:

• the applib directory
• shared-lib directory.

I decided to do a little test: I created a test application that displays the values in a property file. I used the standalone OC4J(10.1.3) for this test, but it works the same way in the Oracle Application Server 10g. First I tried the applib directory. I deployed the application to the OC4J, stopped the server and copied the property file into the [ORACLE_HOME]/j2ee/home/applib directory. Then I restarted OC4J. The web application displayed the values in the property files correctly. Next, I removed the property file from the applib directory and put it in the [ORACLE_HOME]/j2ee/home/shared-lib directory. I restarted the server and tried again. This time, the property file was not found.
This made me wonder about the differences between the two. The applib directory is used by all applications. Libraries and other files that are put in this directory are loaded before libraries and files in the WEB-INF/lib directory of your ear file. In the Oracle® Containers for J2EE Developer’s Guide 10g Release 2 (10.1.3) , shared libraries are explained in great detail. Basically you use these if you have an application that needs to use a different library than the standard library that is packaged with OC4J. An example can be the XML Parser you want to use, or a different version of the Oracle JDBC driver. Another reason to use shared libraries is to share proprietary classes across specific applications, rather than across all applications. To accomplish this, you obviously need to configure your application to work with the shared libraries. The developers guide describes the steps to do this. So if I really wanted to try if the shared-lib folder works for the property file, I would have to configure the shared libraries and my application. I decided not to bother...I am not sure what happens if the application is clustered, but since this was not a requirement when I got the question, the applib directory looks like the simplest solutions that could work in this particular case.

Filed under Java, Oracle | 2 Comments »

Today the Oracle Technology Network published my article Using Oracle TopLink with the Spring Framework. In this article I explain step by step how to build a sample application using Spring 1.2.8 and Oracle TopLink with Oracle JDeveloper 10g.

JDeveloper has built in support for TopLink, but you can build the sample application with Eclipse as well. Download the sources and follow the steps in the article. Instead of editing the TopLink sessions in JDeveloper, edit the xml files in the Eclipse editor or the TopLink workbench.

Filed under Java, Oracle, Spring | 2 Comments »

I am working on a project where they use IBM tools at the client site: Websphere 5.1.8, DB2 and Eclipse. I already have a MySQL instance running, an Oracle 9 RDMBS and some version of SQL Server that came with Windows XP so I did not install DB2 on my laptop.

Of course it's a bad idea to develop an application on a different platform than the production platform, so inevitably, we ran into trouble. Specifically with datatypes. Some code would run fine on WAS with MySQL but as soon as we deployed it to the (AS400) DB2 environment the JDBC exceptions started flooding.

I decided to take the plunge (I am more an Oracle type of person) and install DB2 Personal Edition for Windows on my machine. This would make my machine more compatible with the production database, although there are differences between DB2 for Windows and DB2 for AS400. I anticipated a long download (I aborted the Websphere download after two hours), but after ten minutes the entire DB2 Personal Edition was downloaded to my machine. Next I unpacked the zipfile. Still everything went smoothly: if only it had stayed that way...

(more...)

Filed under Java | 1 Comment »

A little while ago, we decided to take the new JDeveloper 10.1.3 Early Access edition for a spin. At Xebia we mostly use Eclipse with open source frameworks like Hibernate and Spring. We are very productive and successful, but something is missing from our toolset. Hand-coding the presentation layer and binding it to the services and domain classes is a tedious job, even with frameworks like Spring MVC and Tapestry. Oracle’s ADF Data binding framework provides a solution for this problem. It offers .NET-like capabilities, with all the advantages of Java and open standards. The second reason to try JDeveloper 10.1.3 EA is the emerging EJB 3.0 persistence standard. Both Oracle TopLink and Hibernate implement this standard. And last but not least, Oracle has made a contribution to the Spring framework by adding support for TopLink to the Spring DAO package.
Our assignment was to rebuild our timesheet application using JDeveloper 10.1.3 Early Access edition and Oracle ADF. My expectations were high, based on the skills of my colleagues and my experience with Oracle ADF in earlier versions of JDeveloper.

Getting started

After a brief introduction of Oracle ADF everybody started building the application. Right away we got lost: the workspace and project organization in JDeveloper 10.1.3 is very different from Eclipse. Unfortunately it has also changed compared to previous JDeveloper versions, so it took a while before we were on our way. Deleting files from both the project and the file system has always been very awkward and the embedded OC4J gave us a lot of headaches (out of memory exceptions and mySQL datasource trouble).

The domain classes and the services layer

Because we were rebuilding an existing application with a simple domain we generated the EJB entity beans from the database. This went smooth with both the Oracle RDBMS and MySQL. We did find a strange bug: when the access type is changed from property to field, JDeveloper still generates the annotations on the properties (“getXXX” methods). This results in an error when the entity beans are deployed to OC4J. We did not want to spend too much time on the business services, so we decided to generate an EJB Session Bean. Unfortunately, we happened to have an entity bean named “Resource”. The generated session bean did not compile because javax.ejb.Resource is imported when you have “@Resource” in your code. We had to either refactor this domain class or use a fully qualified name cast every time we used this class. We tried to refactor the bean but had no success: renaming a EJB 3.0 entity bean does not work in this version of the IDE.
We added some existing business methods of the original application to the session bean:

public void addProject(Project newProject) {
  //do work
}

Now it was time to start with the interesting part: exposing the services to the presentation layer.

Creating the Data Control

Apart from using a new tool that was an early access release, building our domain and service layer was not too difficult. We created a Data Control for our service bean. This created xml files for the entity beans as well. Our custom methods were present in the xml file as you can see in the xml code snippet:

<MethodAccessor IsCollection="false" Type="void" id="addProject" ReturnNodeName="Return">
  <ParameterInfo id="project" Type="nl.inspiring.utees.blog.model.Project" isStructured="true"/>
</MethodAccessor>

We did notice some strange behavior: JDeveloper generated two xml files (ReadOnlyCollection.xml and ReadOnlySingleValue.xml) in the source directory of the project that were not based any class in our source code. They seem to represent some data type, but there is no documentation about these files.

Building the Web Layer

Now that we exposed our business layer, we were ready to use it in the front end of the application. Most of us decided to use ADF Faces. It soon became clear that using ADF Faces with data bindings is very complex. JDeveloper generates faces-config.xml, backing beans, page definitions, a binding context, iterators etc. Most of us managed to create a page that displayed a read only table with data from a database table. Adding a form to insert a row using one of our custom services proved to be a bigger problem. There are a lot of widgets you can use and the difference between controls like ADF Input Form and ADF Parameter Form are not very intuitive. We also learned that in the Data Control Palette a domain class used as a parameter is not exposed the same way a domain class used as a return type is. We had to rewrite our service methods using the fields as parameters to be able to use the drag and drop functionality. At the end of the day, nobody had built a fully functional web application and most of us had become frustrated with JDeveloper and ADF.

Evaluation

I got some valuable feedback building this application with my colleagues:

• I underestimated the productivity loss people experience when they are forced to use another IDE. To complicate matters we used the early access edition and ran into a couple of bugs. These two factors were a big turn off for a lot of us.
• The current Data binding framework (JDeveloper 10.1.2) works great for ADF BC. For other frameworks like Oracle TopLink with EJB session beans or Spring it is not mature enough yet. Once domain classes can be exposed as parameters and all the Data Control implementations are finished, I expect it will be even better than the current version. Programmers are then no longer forced to use a proprietary framework like ADF BC to be productive.
• Not everybody likes JSF. We had a rather long discussion about ADF Faces and JSF. Some of us fear it will be a monster like the EJB specification (used to be). Others think it is a specification that will give Java developers .NET-like productivity but with the open standards and open source that Java offers.
• Because both the JSF and ADF Data bindings were new for most of us, the assignment became too complicated and we ended up being confused instead of productive.

Personally, I am still very enthusiastic about the latest developments in EJB 3.0 persistence,Oracle ADF Data bindings and even JDeveloper. I’ll try to convince my colleagues again as soon as Oracle finishes the enhancements of the Data binding framework. To keep things simple, I won’t use the ADF Faces right away, but save those until JDeveloper 10.1.3 has become the production version. As far as I am concerned the verdict isn’t out yet….

Filed under Java | 1 Comment »