Advert: JDeveloper 11g training course

I'm very happy to announce the arrival of our 5 day JDeveloper 11g training course in Australia.

At SAGE Computing Services we've updated our JDeveloper 10.1.3 course to include the latest ADF Business Component and ADF Faces Rich Client technologies bundled with JDeveloper 11g, the core technology set behind Oracle's upcoming Fusion Applications.

This training course has been updated in conjunction with Netherland's Fusion Middleware and Oracle specialists AMIS, drawing upon Fusion expertise from both sides of the globe. We're very excited by this relationship, formed by Oracle ACE Directors Lucas Jellema and myself Chris Muir, and much hard work behind the scenes by both AMIS and SAGE staff (my extensive thanks to all involved).

If my Google searches prove correct, we may be the first organisations in the world to provide comprehensive ADF BC/ADF Faces RC JDeveloper 11g training besides Oracle itself, a great achievement in my honest opinion.

Interested in checking out our course?

View the complete course agenda in our course catalogue or visit our training web page for more information.

Also check out SAGE's other latest Oracle 11g training courses in Australia including:

• 11g New Features for Developers (1 day)
• SQL 11g (4 days)
• PL/SQL 11g (3 days)
• Application Tuning 11g (3 days)
• Database Administration 11g (5 days)

... plus all your favourite previous versions and other Oracle products, we have most of them, even Oracle Browser would you believe?!

For further enquiries hit our web site and follow the contact us details. We look forward to hearing from you soon.

Enabling SSL and disabling non-SSL under WLS 10.3

After spending a morning reading reams of WebLogic Server 10.3 documentation, I was delighted to discover that configuring your WebLogic Server 10.3 to serve an application via HTTPS/SSL is just a few mouse clicks.  Nice :-)

As such this is a short(ish) post to document my own findings, which may be useful to other readers.  Usual disclaimer, your mileage may vary.  I've yet to test this in a production environment, though I can confirm I've used a packet sniffer to ensure the relayed data is encrypted (well, at least not readable by me, so I assume it's encrypted ;-)

The following describes the steps to get this going.

Assumptions

For this post the assumed environment is as follows: an internal Window server "oberon.sagecomputing.com.au" running a WLS installation in production mode configured with 2 WLS domain servers:

• AdminServer port 7001 (default)
• AdfServer port 7002

On the AdfServer I've deployed our favourite JDeveloper 11g application BookTraining, served at the following URL:

http://oberon.sagecomputing.com.au:7002/BookTraining

Note the 7002 port number of the AdfServer and default HTTP protocol (not HTTPS).

I'm also using the WLS demo identity keystore and demo trust keystore for development/testing purposes.  For production neither of these keystores are appropriate, and you will need to learn how to obtain and configure new digital certificates/keystores.

Enabling SSL under WLS 10.3

Steps to configure WLS for SSL:

1) Open the WLS console

2) Select from the Domain Structure -> (your domain) -> Environment -> Servers

3) Select the server from the Summary of Servers page you wish to configure for SSL.

4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).

5) If WLS is running in production mode, select the Lock & Edit button.

6) Select the SSL Listen Port Enabled checkbox, and enter your preferred port in the SSL Listen Port.

7) Press the Save button.

8) If WLS is running in production mode, select the Release Configuration button.

Now to access my running app using SSL (say configured port 7005), I'd use the following URL:

https://oberon.sagecomputing.com.au:7005/BookTraining

Note the HTTPS protocol and the SSL port 7005, as separate to the original HTTP protocol on port 7002.

Browsers are our enemy

As I'm running with the WLS demo keystores, any browser access to this URL will raise a security error.  For example in Internet Explorer 7 you'll see something like the following:



For development and testing purposes you can pretty much ignore this issue and just accept "Continue to this website".  However for production purposes as indicated earlier you should not use the WLS demo keystores.

Once you click "Continue to this website", your application's pages should be served via HTTPS/SSL.  Under your browser you should see some sort of notification that the traffic is encrypted with SSL (under Firefox this is the little lock symbol bottom right of your browser).

Disabling non-SSL under WLS 10.3

Once you have SSL up and running, you may decide you no longer want to serve unsecure content from your WLS server.  To disable non-SSL traffic follow these steps:

1) Open the WLS console

2) Select from the Domain Structure -> (your domain) -> Environment -> Servers

3) Select the server from the Summary of Servers page you wish to configure for SSL.

4) Under the Settings for (server name) page, select the Configuration tab, then General tab (the defaults).

5) If WLS is running in production mode, select the Lock & Edit button.

6) Unselect the Listen Port Enabled checkbox (not the SSL Listen Port Enabled checkbox).

7) Press the Save button.

8) If WLS is running in production mode, select the Release Configuration button.

Access to the original URL via port 7002 http://oberon.sagecomputing.com.au:7002/BookTraining now raises a forbidden access error.

Application architecture versus WLS SSL configuration

As readers will know, within a WLS installation it has the concept of a server.  Each WLS domain can have 1 or more servers as per my example above where I had the default AdminServer and a separate AdfServer (let's refer to these as a WLS domain server, as separate to a host server in order not to get confused).  Given the understanding above of turning SSL on/off for a WLS domain server, this implies if you want both protected and non protected content in your application, you will need to configure one domain server with SSL turned off, and another domain server with SSL turned on, followed by deploying your separate unsecure and secure content to the respective domain server.

This does present an issue for JDeveloper JSF derived applications, because it dictates a JSF application with both secure and unsecure content will need to be split across domain servers.  As a split JSF application cannot easily share state (though the new remote task flows and bookmarkable URLs supported by JDeveloper 11g's JSF-ADF Controller provide solutions to this problem), this constraint should be considered when architecting your JSF application.  However this is probably a non-issue for most applications as typically all content is secured or unsecured, not a combination of both.

Troubleshooting

Initially under Firefox 3 if I didn't use the full URL of the server such as:

https://oberon:7005/BookTraining

rather than:

https://oberon.sagecomputing.com.au:7005/BookTraining

.... I would receive the following 502 HTTP proxy error raised by the local MS ISA Proxy Server:

"HTTP 502 Proxy Error - The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. (12204) Internet Security and Acceleration Server"

Yet the error didn't happen under IE7.  Why was Firefox hitting our proxy server (which only allows SSL via port 443), yet IE7 wasn't?

It turns out that IE7 has some magical mechanism to work out local servers and exclude the proxy when talking to them (ie. a mechanism which I didn't care to investigate ;-), while Firefox 3 only had a proxy exclusion for servers ending with sagecomputing.com.au.  As such https://oberon always hits the ISA proxy.  This is simply solved by either addition of the oberon server name to the Firefox proxy exclusion list, or specifying the full URL in the browser.

JAX-WS with WS-Security under JDeveloper 11g and WLS 10.3

I've been a little quiet on the blogging front recently while working on a number of JAX-WS WS-Security solutions via JDeveloper 11g and WebLogic Server 10.3, an area I'm no expert, but rapidly gaining an appreciation of the complexities.  Gerard Davison from Oracle UK has been incredibly helpful in finding solutions to my numerous questions about how to get all this working, his blog is well worth checking out if you're interested in JEE web services.

As I've received a number of emails from others on how to get WS-Security working with the new JAX-WS offerings in JDeveloper 11g and WLS 10.3, can I recommend readers check out this post from Gerard that shows the essential steps in configuring both the server and client side working with the numerous required digital certificates.  Once you have that up an running it's fairly easy to extend Gerard's example to include the SOAP body WLS encryption policy (Wssp1.2-2007-EncryptBody.xml) - though make sure you read Gerard's Feb 11th update in the same post as it has an essential fix.

Happy web servicering.

Configuring separate dev-test-prod URLs for your ADF Faces RC application

I was asked the other day how to go about having different context-root URL paths for different deployments of a single JDeveloper 11g ADF Faces RC application, such that we have:

http://www.sagecomputing.com.au/bookingsDev
http://www.sagecomputing.com.au/bookingsTest
http://www.sagecomputing.com.au/bookings

While it would be fairly unusual to have all 3 environments on the same box (well, at least not recommended), in the case of a development and test environment it's quite common to have them on the same box separate from production. As such when developers and testers logon to the combo dev-test box, it's helpful to have different URLs to assist the developers and testers understand which environment they're working on.

As readers will be aware you configure the context-root URL for your application via the default WAR deployment profile for your ViewController project. The profile can be accessed by selecting your ViewController project in the Application Navigator, from the right mouse menu selecting Project Properties, then the Deployment tab:



Selecting the Edit button reveals:



From here you can select the "Specify Java EE Web Context Root" and enter a custom root of your choosing such as:



Note how we've also chaned the Enterprise Application Name. This is necessary to uniquely identify the 3 different deployment profiles if all are deployed to the same application server.

In order to provide 3 separate context roots, simply return to the Project Properties screen and create 2 additional WAR deployment profiles by selecting the New button. This will present the Create Deployment Profile dialog where you can configure another WAR with a unique name:



From there you modify each WAR deployment profile such that you have unique context roots for each, and you'll end up with something like this under the deployment profile in the Project Properties:



(Okay, I admit it, my deployment profile names are uninspired, but it's been a loooooooong week)

From here the preferred way to deploy Fusion Apps in JDev 11g is to select the default EAR deploy option from the Application Navigator's Application Menu:



However this is configured to use the original ViewConroller WAR deployment profile. What we really want is 3 EAR deployment profiles at the Application level.

To view the EAR deployment profiles we select the Application Properties option from the Application Menu above, then the Deployments node:



As you can see we have a default EAR deployment profile. If we select the Edit button and select the Application Assembly node we can see that the EAR deployment profile is configured to use the original WAR deployment profile:



As you can guess all we need to do now is create 2 additional separate EAR deployment profiles that use the different ViewController WAR deployment profiles.

Once we've done this and then select the Application Menu's deploy option we'll see all three EAR deployment profiles available to deploy to our application server:



And once deployed to your application server each separate EAR deployment will use a different URL to access the dev, test and prod applications.