Olaf Heimburger's Blog

Well.

The second comment on my previous post provoked an answer.

In OC4J you have the ability to use a number of different JNDI context factories. Each of them helps to create an InitialContext and comes with different functionalities.

The most commonly used context factories are:

• internal context factory - you get this one by simply calling the default constructor of InitialContext and don't have an jndi.properties in your class path and are within the OC4J container.
• RMIInitialContextFactory - This one is commonly used to connect to the OC4J container. It ignores every configuration and also doesn't need the "java:comp/env/" prefix. (Here the second comment is true.)
  
• ApplicationClientInitialContextFactory - This context factory takes care of your JNDI environment (esp. in META-INF/application-client.xml) and honor's the "java:comp/env/" environment prefix.

This is the flexibility of OC4J and it is up to you to use the right context factory in your application. Flexibility sometimes has a pay off, but I don't to start a thread on this. Some people love flexibility, eg. some Eclipse zealots...

On the upcoming posts, I'll cover the XML parser and Hivemind configuration issues (Hint: No need to change the source code...).

Stay tuned.

If you're writing a token parser it might be very clear to you what a line like this mean to your parser:
    <td width="100%"
style="border-left: 1px solid #000; border-right: 1px solid #000;
<dhv:evaluate if="<%= !i.hasNext() %>">border-bottom: 1px
solid #000;</dhv:evaluate>">

Hard to spot isn't it?
Well, the problem is the second quote in the style attribute:
    style="border-left: 1px solid #000; border-right: 1px solid #000;
<dhv:evaluate if="<%= !i.hasNext() %>">border-bottom: 1px
solid #000;</dhv:evaluate>">

Tomcat silently handles this incorrect code as correct and will continue.
OC4J on the other hand follows the JSP and Servlet Specifications very close and issues an error.

To solve this problem, you should:

• Read the quote character (") as parenthese and always translate it to open/close semantics.
• Use the right quote character for inner attribute values, eg.
  <td width="100%"
  style="border-left: 1px solid #000; border-right: 1px solid #000;
  <dhv:evaluate if='<%= !i.hasNext() %>'>border-bottom: 1px
  solid #000;</dhv:evaluate>">

Credit

This flaw was also discussed on the OTN Forum.

This nice little gem was posted in the JDeveloper Forum Thread:

To improve the text display of your JDeveloper 10.1.3.x or SQLDeveloper 1.x simply add

AddVMOption -Dswing.aatext=true

to your jdev.conf or sqldeveloper.conf file (location $INSTALL_HOME/jdev/bin).

NB: This only works with JDK 1.5.

I'm about to finalize the work on a Development Environment based on the latest Developer Previews of the SOA Suite and JDeveloper (10.1.3.1) and Oracle XE on RedHat AS 4.3.

Gotcha 1: ORAWSM tables missing.

The installation went very smooth... until the SOA Suite installer was about to execute the "Oracle Web Services Manager Configuration Assistant". This one completely failed. The reason was that the tables and sequences for the ORAWSM user weren't installed before the assistant was started. After creating a simple script by hand and running it within SQLDeveloper I could retry the failing assistant. Now it could finish this step and also the remaining ones.

Update: Tried the install again on a different host. This time I checked the distribution and found the $DISK1/install/soa_schemas directory. This contains the Integration Repository Configuration Assistent (irca) which installs the complete repository.

Once I've finished the installation, I installed a custom made sample
application with some EJBs, a Web GUI and a BPEL process. Easy, but I
couldn't test it properly.

Gotcha 2: BPEL No default domain installed

First problem was the missing domain in the BPEL dehydration store. This
was solved by checking the URLs in the BPEL console configuration (use localhost on DHCP machines) and also by reinstalling the store by executing the domain_oracle.ddl and server_oracle.ddl from $SOA_HOME/bpel/system/database/scripts.

Gotcha 3: No proper TNS connections

By default Oracle XE comes with a "small" database configuration (/usr/lib/oracle/xe/app/product/10.2.0/server/dbs/init.ora). The reason for this particular problem is the number of processes supported by XE. By changing not only the processes value but all other settings to the proposed "medium" values I could get around this issue.

Caveat

These are just the some Gotchas I came across while implementing the development environment. These might not happen during your installation nor while using it. But if it does you have some hints.