All GroundSide Blogs
Blogs hosted on GroundSide.com

I'll be slowly retiring the GroundSide server so change your feeds to the new home of the GroundBlog on http://blogs.oracle.com/groundside/

If you are, then you need to view and respond to this announcement which I've posted on the OTN discussion forum...

We are now mere days away from shipping the new JDeveloper 11g Handbook - A guide to Fusion web development".
Copies will be physically available next Monday just in time for Oracle Openworld. All of us authors will be there at OOW and we'll be more than willing to sign copies - if you can find us. I guess we could make it a kind of competition!
Hopefully the Oracle Bookstore in Moscone West will have a few copies to sell and you'll be able to flick though (and win!) a copy in the OTN Lounge

The new OTN Sample code site (see the entry "New Service for OTN Members: Public Sample Code Repository" in the OTN homepage) has been recently been introduced and like many folks I've been itching to start using as a great place to store all of those samples that people keep asking me about.
For my first project, however, I decided that this would be a great place to put the sample application code that accompanies the upcoming JDeveloper 11g Handbook. My main interest here was to see how simple it was to work directly with the Subversion source control repository associated with a project. i.e. Could I work directly from within JDeveloper on a samplecode.oracle.com project.
Well the answer is yes, and it's pretty easy, certainly much easier than working with sites like SourceForge in the past which has been a whole mess of private / public key stuff and Plink.
Having requested my new project and once the basic site was created from the template all the information I actually needed was available on the Subversion link of the project homepage:

Then on that page you have information about how to checkout from SVN from the command line. The key part here is to take the relevant URL:

and then use that in your JDeveloper version navigator to create the connection:

And you're done. I can now check out and check in to the project directly from JDeveloper in the normal way. Notice I did get a warning about the site certificates not being trusted but JDeveloper allows you to ignore that on a temporary or permanent basis. I'll look into that one, it's no big deal.

For the security chapter of the Fusion development book I’ve been polishing off the security section with the basic use case of how to take the identity that the user has authenticated to the container with and then using that to interrogate the database to get useful information about the user (for example their real name). This is a pretty common requirement and we did something like it in the last book to set up PL/SQL context for a session.

There are several ways to approach this problem; the most linear thought-line being:
OK I have the Java EE container username in the HTTP session, so I can call a method on the AM that passes that information in, queries the User table and then returns the name information for storage in the session.
Well that’s fine but it has several flaws:

• We don’t really need to pass the principal name to the ADF BC layer it’s already available via the SessionImpl.getUserPrincipalName()
• Why pass the information back into a session state variable at all? We can just define a single row VO which points to the user state information and bind the client to that to get to the information when needed. The advantage of this is that I won’t have to do additional work in the session when / if the user logs out and changes identity.

So I had a clear idea of how I wanted to do this but the problem remains - how do I refresh the UserInfo VO when the login happens - so that it does not contain stale information?

My first stab at this ran into a brick wall, I defined a custom method on the UserInfo VO which grabbed the User Principal, assigned that to a bind variable and re-executed the query on the VO.

I could see this was working just fine, when called from my JSF Login action, however, big problem, my UI fields bound to the UserInfo VO attributes kept coming up blank.

Nothing to do here but switch on a bit of logging to see what is going on:

-Djbo.debugoutput=console

Then I saw the problem - the technique that I was using to handle the login was essentially starting in a new ADF BC session (because I was doing a re-direct as a lazy way to prevent me from having to set up a bunch of screen refresh PPR which is fine in the use case I have). So looking at the log I could see the bind variable being set up correctly, the query on UserInfo executed, then the whole thing repeated this time with the default value of the bind variable rather than the User Principal name value I’d set up. Bummer.

Step back, think about the problem….

Ok, so the VO is being refreshed with the default value of the Bind Variable - what if I could set the default value of the bind to the User Principal name? If did that I’d never even have to call a VO method to set the Bind Value, it would all be automatic.

Of course in 11g we have Groovy expressions which can be used in a whole bunch of places, validation of course and setting default values, both for EO attributes and for Bind Variables - Ahah!

In the end it turned out to be too chuffing easy, all I had to do was set the default value of the bind variable on UserInfo to an expression rather than a literal value and then use the expression viewObject.DBTransaction.session.userPrincipalName. That’s it.

With this in place there was no need to make a call from the client login code at all, it was all just automatic. I ended up with a simple VO with no impl files and all the refreshing is handled implicitly, even as you switch users. It all goes to prove that the Groovy expression capability in 11g is one of the most useful new features that we put in for the BC layer.

Easy when you know how….