JNDI failure for WLS deployed ADF applications

One runtime error I've hit a few times now when setting up an ADF application to use a JNDI Data Source via WebLogic Server (WLS) is the following:

(I'll document this issue here to save myself grief later on and hopefully help a few other people out)


The specific error text:

JNDI failure. Unable to lookup Data Source at context jdbc/appDS
Unable to resolve 'jdbc.appDS'. Resolved 'jdbc'.

Note that the text "jdbc/appDS" or "jdbc.appDS" may differ in your specific case dependent on what you did in the following steps.

The error comes about as I've:

1) Modified my ADF BC Application Module AppModuleLocal configuration to use a JDBC DataSource connection type, specifying a datasource name of jdbc/appDS.


Accessed via Model project -> Application Module right click -> Configurations -> select AppModuleLocal then Edit button -> Application Module tab.

2) On the WebLogic Server I've created a data source as following:


This is accessed via opening your WLS console + logging in -> Domain Structure -> Services -> JDBC -> Data Sources.

First note the AppDataSource that I've created, then the JNDI Name that maps back to that specified in the previous step.

Then note that the Targets entry is empty for my configured data source. Effectively I've created the data source in WLS but forgotten to assign it to any WLS server and in this case is what's causing my problem.

To rectify this I click on the data source name -> Targets tab then assign the data source to each server I'm interested in (in this case just the JDev 11g integrated WLS DefaultServer):


On saving the changes and returning to the Data Sources page you should see:


And the problem should now be resolved.

ADF BC: Using Groovy to fetch sequence numbers Part II

I recently posted ADF BC: Using Groovy to fetch sequence numbers for EO/VO attribute default values. This post showed the power of what you can get away with in the new Groovy expressions of ADF Business Components in JDeveloper 11g.

Though power is good (muhahaha!, um, cough), simple is better.

Steve Muench suggested the following to make retrieving sequence numbers a breeze via the Groovy expression facilities.

Readers will be familiar with the common recommendation for ADF Business Components to create a layer of framework extensions, as per Section 33.2 of the JDeveloper 11g Fusion Guide.

With this in mind we can create the following helper method seqNextVal() to fetch the next value for a named sequence in our custom EntityImpl:


...which we can then make use of in our Groovy expression in the Entity Object attribute's default value field:


Remember to set the Value Type = Expression.

Thanks to Steve for his suggestion.

Advert: AUSOUG-Western Australia: Why You can No Longer Avoid JDeveloper

Oracle are building their Fusion Application suite using JDeveloper and the ADF framework. If we think about how long Oracle Forms has been a core development product for Oracle it seems obvious that this new platform will have similar relevance.

A confirmed JDeveloper cynic, Penny Cookson has finally been bitten by the JDeveloper bug, and like any Oracle geek can be found playing with the new features in her office in the small hours of the morning (CM - really, it's true ;-)

If you're interested in learning why Penny, a long time Apex advocate is now preaching about JDeveloper, and you're located in Perth Western Australia, join us on April 2nd to hear Penny's AUSOUG-WA presentation about JDeveloper 11g.  Penny will discuss why you should look at JDeveloper and demonstrate some of the smart and cute new features in JDeveloper 11g.

More details about the event can be found here.

AUSOUG-Western Australia is also looking for more presenters at their monthly meetings.  If you're interested in presenting please drop me an email.  Email me at chrisSTOPmuirATsagecomputingSTOPcomSTOPau.

ADF BC: Using Groovy to fetch sequence numbers for EO/VO attribute default values

I've recently been fooling around with the new ADF Business Component support for Groovy expressions in JDeveloper 11g, and thought I'd share the following discovery.

(Usual caveat this hasn't yet been tested in a production system, so your mileage may vary)

JDeveloper's ADF BC supports a number of different mechanisms to fetch database sequence numbers for Entity Object & View Object primary key attributes when a new record is created.

One such method is to override the create(AttributeList) method in the Entity Object and include the following Java code:

@Override
public void create(AttributeList attributeList) {
  super.create(attributeList);
  SequenceImpl seq = new SequenceImpl("LOG_SEQ", getDBTransaction());
  Number seqNextval = seq.getSequenceNumber();
  setId(seqNextval);
}

This example retrieves the next value from the database's LOG_SEQ sequence and writes it to the local Entity Object's ID attribute via a call to setId().

This minor piece of code can now be replaced with a Groovy expression in JDeveloper 11g's ADF Business Components.

If we open the Entity Object editor, then double click the primary key attribute we're interested in populating with the sequence number, we can now enter the following Groovy expression for the Value field with the Expression radio button selected:

(new oracle.jbo.server.SequenceImpl("LOG_SEQ", (cont)
object.getDBTransaction())). (cont)
getSequenceNumber()

The following picture shows the entry in context of the Edit Attribute dialog:

Note in the expression how we must explicitely name the package + Java class for the SequenceImpl as we don't have a mechanism for importing classes in the simple Groovy expression.  In addition for the getDBTransaction() call we need to make reference to the Groovy "object" expression (or is that class? Whatever).  "object" passes a copy of the Entity Object class to the Groovy expression evaluator allowing it to call methods of the Entity Object, in this example getDBTransaction().  More information on Groovy expressions can be found in Steve Muench's following blog post.

The advantage of this Groovy approach is one less reason to code in Java in JDeveloper if you feel the desire (though the Java code example from above isn't exactly difficult).  The disadvantage of this approach, I can imagine it would be difficult to debug if something went wrong.

In conclusion we can see the power of the new Groovy expressions supported through JDeveloper 11g and ADF Business Components.

Join 180 members of the ADF Enterprise Methodology Group (+ minor name change)

Just a small note for the millions of my readers (hi Mum!) who care about such, that the ADF Methodology group (that's group with a lower g) has been renamed the ADF Enterprise Methodology Group (that's group with an upper G) to better reflect, um, well if you're really interested it's documented here.

(It would be appreciated if Oracle employee's in charge of websites and similar that link to the original group could update any link names please)

For those who'd like to know more about the group, following is a little marketing spin to drag you in:

You can easily tell when a tool has matured to being a productive environment. Software developers move from playing and learning features, to supporting production systems and discussing best practices and development methodologies to ensure the success of their next project.

The ADF Enterprise Methodology Group is such a place for community discussions based around JDeveloper best practices and methodologies for ADF Enterprise development. On a day by day bases ADF "experts" (that's anyone that knows what ADF stands for ;-) chat about high level ADF concepts, beyond the how-do-I-get-it-to-work posts on the OTN JDeveloper Forums.

If you'd like to discuss best practices, steps and processes for a successful ADF project, please join us at:

http://groups.google.com/group/adf-methodology

We look forward to talking to you on the group soon.

JDev IDE: defaulting to the source code editor for web pages

Recently Vivek Kumar posted about Improving Performance in JDeveloper 11g. Among other suggestions his second one caught my eye: "Configure JDeveloper to open jsp/jsff's in source view". This particular suggestion applies not only to JDev 11g, but also JDev 10g (and possibly earlier versions too, none of which I have installed to check). Unfortunately Vivek didn't give details of how to configure this so I thought I'd do it here.

On opening a web page in the IDE, there is a noticable delay while JDev initializes the WYSIWYG design editor. This becomes painful if you want to only make a small code change in the web page's source code. It becomes doubly painful as there is an infrequent bug in JDev 11g build 5188 where the design editor refuses to show the page's contents unless you flick between the source code and design editor views.

As such Vivek's suggestion took my eye and reminded me we can easily change the default behaviour of JDev to open web pages in the source code editor instead, to avoid these minor annoyances.

The option to do this is under the Preferences dialog invoked via the Tools menu, then selecting the File Types node:


As can be seen from the above picture, selecting the Default Editors tab displays all the different file types JDeveloper works with. For standard JSF pages with an extension of .jsp or .jspx, we can select the JSP Source option and switch its Default Editor option from Design to Source as I've done in this example.

One minor caveat to note is JDeveloper does remember for each file what editor type you were last using, so this change only applies to new files.