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.

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.

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…

I was starting to think this might not be such a big deal after all…. wishful thinking: mistake number 1!

I double clicked the setup.exe and started clicking ‘next’ in the wizard. I assumed that leaving the defaults was the best way to go. Defaults are designed for people that don’t know what they are doing, right? Assumptions: mistake number 2! The only thing I changed, was the option to start the database automatically.
When I finished the wizard, I shut down my PC and decided wait until the next morning to check what happened with the database.

When I logged on, I noticed to my surprise that a new user was present: ‘db2admin’. I logged on with my own username and started the database.

Then I tried to access the database with the control center.

I got hit with the error message SQL1035N The database is currently in use. SQLSTATE=57019. The problems and possible solutions I found on the IBM website did not help at all. I tried a couple of things:

• I added my windows user to the group of DB2 ADMINISTRATORS
• I started and stopped the database
• I restarted my machine
• I waited (also one of the suggestions).
• I logged on as db2admin on my machine. I figured that maybe the database was in use by ‘db2admin’. This did not help: when I launched the control center and tried to access anything, I got the same message

I was ready to give up. One of the other developers on the project tried to install DB2 on his machine. Because he heard me complain (I tend to ‘think’ aloud), he used his ‘normal’ windows account as administrator for the database. He managed to get the database up and running in no time. I don’t like to be defeated by some tool, so tonight I started over: I deinstalled DB2, renamed my windows user so it does not contain any spaces (yes you can do that!), created a TOOLDB, lowered the memory use for the instance and clicked ‘finish’.
The database started, and I could access it using the control center! I then created a new database (I needed to use ‘standard’ as type, other types still give me weird errors) and a new user. I then spend some time figuring out how to change the password. I finally came across this link: sqlzoo and decided I was done.

Tomorrow I am going to try to connect Websphere to this database. I hope this will be an easier exercise: my collegue already managed to do this. If I just follow his instructions noting can go wrong, right? Hmm, reading this I can see the two mistakes popping up again: assumptions and wishfull thinking. But then again, nothing would ever happen, if you give up before you even try!

To sum up: I still don’t know exactly what caused the problem, but I learned a couple of interesting lessons:

1. You can actually change your windows username, without having to change anything else.
2. Don’t use the default db2admin as the administrator when you use the personal edition for Windows
3. Try to get a DB2 DBA or Expert sitting next to you, when you click your way though the wizard

Basically it is like installing an Oracle database: all you have to do is click ‘next’. If it fails, you are in trouble and you need an expert. If it succeeds, you were lucky and (people think) you are the expert.

Tags: oracle, db2, database

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….