Latest News from Chris Muir

Oracle Dynamic Tabs Shell - ADF 11gR1 – UI Shell

Mon, 30 Nov 2009 10:30:00 EST

In the latest release of JDeveloper, specifically 11.1.1.2.0 also known as 11g Release 1 also known as Patch Set 1 also known as 11g build 5536 also known as the Shepherd build (cough cough Oracle), Oracle has included a new built in page template known as the "Oracle Dynamic Tabs Shell". This template is part of Oracle's ADF Functional Patterns and Best Practices efforts, also referred to as the "UI Shell". Complete documentation is available here. I'll leave readers unfamiliar with the UI Shell to read Oracle's documentation to understand the basics.

With my current client we're happy with the inclusion of this new UI Shell and we can actively see ourselves using it in the near future. What I wanted to document is my own thoughts and research which may be of use to others, and I hope to further the discussion on the ADF EMG. Note as usual your mileage may vary so take time out to check the facts listed here:

1) The Create JSF Page dialog presents the "Oracle Dynamic Tabs Shell" page template option:

2) The template and its supporting classes are installed in <jdev_home>/jdeveloper/adfv/jlib/oracle-page-templates-ext.jar, though the JDev IDE takes care of importing the template and classes/libraries into your project for you once selected in the Create JSF Page dialog. As the following picture shows an additional library Oracle Extended Page Templates is added to your project:

Side note: Steve Muench has blogged the location of the UI Shell template and supporting classes as a separate download here. This will allow you to take the default UI Shell template and customise to your needs if required. See further points below for why this may be necessary.

2) Our technical team was already getting bogged down in "discussions" of "standard" web page layouts versus RIA layouts. The technical team knows the standard web page layouts weren't suited to RIA applications, but it was hard to argue our case without actually creating a RIA layout. In turn creating a RIA layout that we were happy with was going to take some time, and we're building applications now. With the UI Shell we can short cut the layout "discussions", say this is what Oracle's provided us, it works well and this is what we'll use, allowing us to focus on the more important matter of hand and that's writing the ADF solution for the business.

3) Our overall application is made up of several subsystems (think Oracle Apps with HR, Procurement, Payroll etc). Within the UI Shell the globalTabs facet provides an ideal location to list the subsystems allowing the user to switch between each module:

4) Each subsystem gets its own page based on the template, as in hr.jspx, procurement.jspx and payroll.jspx based on our example.

5) The rest of the application is made up of a number "Activities" that in essence are bounded task flows using page fragments, or in other words the business processes of your application. Each subsystem is free to make use of as many bounded task flows as it sees fit, and in addition a bounded task flow can be used (shared) by many of the subsystem pages.

6) As per the previous point, if you're using the default UI Shell provided through JDeveloper rather than downloading the UI Shell as per Steve Muench's blog above, and you wish to have a common element in every page using the template, you'll need to code them in every page which isn't ideal. The solution is to download Oracle's template and customise it within your own application (or possibly create a number of declarative page components for repetitive content, though this will still require you to load each page component in each page based on the UI Shell template).

7) A key feature of the UI Shell as described in its other name "Oracle Dynamic Tabs Shell" is it shows under each subsystem how to launch a bounded task flow (aka Activity) one or many times:

This may not be ideal for every application, but my current client has a scenario in an existing Oracle Forms application where users open up to 4 sessions. While we're not sure on building an ADF equivalent with a chance to redesign the users' workflow will they still need to do this, if they do we're envisaging that each session can now be as a separate UI Shell Activity under the subsystem page.

8) As discussed in the following ADF EMG thread the UI Shell makes a great addition to the "Master JDev Application Workspace" proposed by Todd Hill bringing a number of composite ADF bounded task flows together.

9) The demonstration UI Shell application shows a basic mechanism of stopping a user leaving an activity once they've made "it dirty". The analogy to this is in the JDev IDE when the user changes the contents of a source file, the tab control title font becomes italic and the user is warned/prompted to save changes if they attempt to close the tab without saving.

Currently this feature should be considered a demonstration feature only as in the downloadable UI Shell demonstration application it has a number of limitations (it is a demo after all). In particular the isDirty() check is only done within a subsystem's activities. Clicking on a different subsystem tab/page doesn't invoke the isDirty() check with the appropriate warning dialog. It would be my assumption that this check would need to be coded in each specific application, reusing the isDirty() facilities provided.

10) For the logoImagePath attribute you can specify the path of the UI Shell log image, but not the size. In the turn the layout tends to assume a horizontal logo. If corporate branding is important to your organisation and they have a long vertical logo, good luck.

11) The default UI Shell has no consideration of security. For instance what subsystems are available under the globalTabs for the current user is your responsibility

12) The overall template does waste some vertical screen real-estate:

See annotations A, B and C.

A can be trimmed by setting the globalSplitterPosition attribute. At this time it doesn't look like B and C can be set in the default UI Shell. Ideally we'd want something like this:

13) The overall template is extremely small – only 74k – wow, Oracle can create something that doesn't take up an entire CD! ;-)

14) I note in the source code downloadable from Steve Muench's blog that there are a few comments that the implementation will change dependent on later updates to the ADF component set presumably available in later JDev releases (ie. see the TabContext.java REMOVE_ME_WHEN_NAVPANE_SUPPORTS_STAMPING comment).

This implies the default functionality of the UI Shell could change in the future which could have issues for your existing applications based on the UI Shell and therefore your regression testing and user experience. It may be necessary to source the UI Shell code and baseline in your code repository rather than being subjected to changes in functionality on upgrading to future JDev releases.

15) As per the UI Shell whitepaper, the 7 zillion steps to reproduce the demonstration UI Shell application do look daunting. However if you're familiar with JDev, page templates and constructing JSF pages it only takes about 20-30 minutes to run through most of the steps. In fact most steps are just setting up dummy task flows and page fragments to show some content within the produced template, nothing really to do with the template itself.

16) You'll need to remind users/analysts/managers etc that what the UI Shell gives in preconfigured layouts, saving developers time and boosting productivity, it takes away in customizable layout of the screen. This is a common point of contention in component based frameworks where a super component gives a large array of features, but the component works as the component works and cannot be easily customised without headache.

ADF EMG goes international - UKOUG style

Sat, 14 Nov 2009 02:19:00 EST

I'm happy to say that the ADF Enterprise Methodology Group is running its first UKOUG presentation this year at their annual technology conference in Birmingham November 30th-December 2nd. This is a pretty exciting development for us, as this will be the first ADF EMG session run outside of the USA!

My colleague in ADF crime Simon Haslam, who organised and ran our OOW sessions this year, invites anybody who is interested in ADF and wants to talk with other users to attend. At OOW we had the rather pleasing experience of several ADF "production" system demonstrations which was pretty cool, and hopefully at the UKOUG we can get some of you to talk about your ADF experiences too.

Unfortunately I'm just on 14590.82kms away (9066.56 miles for our UK friends) and wont be able to make it. If only it was a couple clicks closer, oh, and not across several oceans & continents, and a tad warmer too.

ADF BC Groovy – Showing Old Values Along with New

Fri, 13 Nov 2009 14:45:00 EST

A common requirement in databound applications is to allow the user to view changes before they commit them to the database, showing the user both the original-old value along with the new. This gives users a chance to review their changes visually by comparing the old and new.

For an updated record that has yet been committed to the database, ADF BC stores both the old and new value. Among other reasons ADF BC does this, is it allows the user to cancel any changes, and rather than having to fetch the original value back from the database, ADF BC just retrieves the old value it has cached without a roundtrip to the database.

This cache gives us the ability to solve our original requirements as the ADF BC framework exposes methods to fetch both new and old non committed values from the Entity Object (EO). To fetch the new current value we call the associated accessor such as getPosition() or getName() that was automatically created by the framework in our EntityImpl. To get the old value we use the getPostedAttribute() method passing in the index of the field we wish to fetch.

In JDeveloper 11g through its introduction of Groovy expressions, it's very simple to expose the old value through the Entity Objects:

1) In your required EO create a transient attribute. For example if we want to show the old values for the Position attribute of our EO, we could create a new transient attribute named OldPosition.

2) Ensure the "Persistent" and "Derived from SQL Expression" properties are turned off for the new transient attribute.

3) Set the "Value Type" to Expression and enter the following Groovy expression into the Value field:

adf.object.getPostedAttribute(adf.object.getAttributeIndexOf(model.EmployeesImpl.POSITION))

Note the call to the getPostedAttribute() method, passing in the index of the Position field that it requires.

If the Groovy syntax isn't familiar to you in JDeveloper 11g consult Grant Ronald's Introduction to Groovy.

A bad steer here maybe to try and use ADF Groovy's oldValue and newValue methods. Unfortunately these are only available for Groovy expressions in EO Declarative Validators, not in transient attribute.

4) Expose the attribute through the associated View Objects (VO) if necessary.

At runtime you'll note that initially the OldPosition field shows what's in the Position field. When you change the Position field's value, the OldPosition remains at the pre-cached value. Finally on committing the changes to the database, the OldPosition value is overwritten with the new Position value.

Just how famous can one man get?

Wed, 04 Nov 2009 04:20:00 EST

Between OOW and the AUSOUG conferences it's a bit of a slow blogging time for me, while presentation preparation takes priority. With a little spare time I thought I'd share this photo of some recent booty (and before you get all excited, that's arrrrgh "Pirate" booty, not the other sort):

On the right my coveted Oracle ACE Director of the Year award from Oracle Magazine. In the middle Duke, thrown from James Gosling himself at his Oracle Develop OOW session. And on the left my cherished SAGE Computing Services award.

If the writing is a little hard to read, it says:

Sage Computing Services' own Chris "ACE Director of the Year" Muir - "How famous can one man get" Award - For excessive hard work blogging and general geeky behaviour.

And to think, I thought nobody noticed ;-)

ODTUG Down Under – More ACEs than a Pack of Cards

Mon, 02 Nov 2009 19:50:00 EST

Regular readers already know that ODTUG in conjunction with Oracle Technology Network has invited a number of Oracle ACEs and ACE Directors to present down under. ODTUG has teamed with AUSOUG to give these world recognized presenters (in fact in all cases world award winning speakers) full day slots at the conference that starts next week.

Working with WLS 10.3.1 SQLAuthenticator Password Algorithms

Tue, 27 Oct 2009 11:15:00 EDT

In the previous post we looked at how to configure the SQLAuthenticator password encryption options. Among other encryption algorithms we discovered that on creating a user from the WLS console, WLS would create the associated user in a database table with password "password" encrypted to:

{SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

...when the SHA-1 option was set.

As was mentioned in the previous post, as the database table with its users and passwords may be shared by non-WLS based applications, it's important that those systems can encrypt passwords and compare them to the WLS result. In other words, in the example above, given that WLS generated a SHA-1 encrypted password, if another system uses the same SHA-1 algorithm will it generate the same encrypted password allowing it to compare the database SHA-1 encrypted password against the SHA-1 encrypted password it has?

In order to check we can get the same encrypted results, we'll investigate generating a SHA-1 password using the Oracle database's encryption facilities (so in this case the database acts as the other subsystem), comparing the database's encrypted SHA-1 password to that of WLS.

The following solution owes thanks to Sean at Oracle Support who very patiently led me in the right direction with my findings.

dbms_crypto

Oracle database fans will be familiar with the dbms_crypto package that provides encryption support.

dbms_crypto allows us to generate an encrypted password that we can compare to the WLS result. From table 34-1 of the dbms_crypto link, we note that dbms_crypto supports the following one-way hash algorithms: SHA-1, MD4 and MD5. As WLS via the JCE extensions (see the previous post) supports SHA-1, MD2 and MD5, it's fortunate we picked SHA-1 for this example.

The following anonymous PL/SQL block shows an example using the dbms_crypto package hash function with SHA-1 to produce an encrypted result:


DECLARE
  input_string  VARCHAR2(8);
  raw_input     RAW(128);
  encrypted_raw RAW(2048);
BEGIN
  input_string := 'password';
  raw_input    := utl_raw.cast_to_raw(convert(input_string, 'AL32UTF8','US7ASCII'));

  encrypted_raw := dbms_crypto.hash(src => raw_input, typ => dbms_crypto.hash_sh1);
  dbms_output.put_line('Output: ' || encrypted_raw);
END;
/

Output: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8

Note the output, a hex value, and doesn't match our WLS output for the same plaintext password "password" encrypted with SHA-1.

The missing bit of information (that I haven't found documented) is that WLS after encrypting the plaintext password, as confirmed by Oracle Support, WLS then converts the output to base 64. In the case of the dbms_crypto hash function, it converts the encrypted result to Hex. In order to get the same result you need to convert the Hex output to base 64.

There's a number of different ways to do this. One is to use a Java routine in the database, converting the dbms_crypto Hex result to a byte array, then byte array to base 64. A suitable algorithm would be:


byte[] bytearray = hexStringToByteArray("5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8");
String base64encoded = new BASE64Encoder().encodeBuffer(bytearray);

...where the hexStringToByteArray function is borrowed from Dave L on StackOverflow.

The end result is: W6ph5Mm5Pz8GgiULbPgzG37mj9g= ... finally matching what WLS wrote to the database (missing the algorithm prefix of course).

Conclusion

Why the WebLogic Server's SQLAuthenticator can make use of different encryption algorithm when writing to the database, it's important to ensure that the results are expected and understood and can be used by other subsystems.

My OOW presentations - part II

Sun, 18 Oct 2009 16:53:00 EDT

My 2 presentations for OOW are now available for download from the SAGE Computing Services website here:

SOA Lite: A taste of SOA with a smidgen of Web Services

Oracle JDeveloper 11g JAX-WS Web Services: As easy as 1-2-3: XSD, WSDL, Generate!

Working with WLS 10.3.1 SQLAuthenticator Password Algorithms - Part 1

Mon, 05 Oct 2009 15:00:00 EDT

WebLogic Server 10.3.1 supports loading user credentials and roles from a number of different sources, such as LDAP or a database, through the concept of "Security Providers". In order to work with a database table structure a "SQL Authenticator" provider is required.

Edwin Biemond has a good example of setting up both the database table structures and configuring the WLS SQL Authenticator against these tables. To keep the example simple, for the password field in the JHS_USERS table Edwin's has set the SQL Authenticator to write raw plain text passwords to the table. This makes it really easy for demonstration purposes to see what's written to the database.

To extend Edwin's post, a common requirement will be that:

a) The password value is written in an encrypted form to the database
b) Other non-WLS applications can generate the same encrypted result such that the encrypted passwords can be compared

The need for point "a" is obvious, unencrypted password in the database is a security weakness. But what about "b", why would you want this?

For many organisations the list of users and roles will be stored in database tables, and that information will be sourced by many different subsystems implemented in different technologies. It's not uncommon for sites to have Oracle Forms, .Net, JEE (and ADF of course!) applications all relying on the database user tables for their authentication and authorisation information.

Each of these subsystems would require users to login. The subsystem would then encrypt the password, retrieve the corresponding password from the database for the identified user, and compare the results. If they compare, we have a valid user; if the encrypted passwords are different, ring the alarm bells, we have an imposter (or at least make them login again ;-)

All things would be well with this solution, until you throw in the fact that each subsystem may support different encryption algorithms that would produce different results, effectively failing the encrypted password comparison each time. It becomes essential therefore that WLS's SQL Authenticator supports different encryption algorithms in order to provide as much flexibility as possible.

Password Settings

On configuring a SQL Authenticator as per Edwin's example, on accessing the Provider Specific information (from the WLS console select Security Realms -> myrealm -> Providers tab -> your named SQL Authenticator -> Configuration tab -> Provider Specific tab), you'll note the following options that influence the generation of encrypted passwords:

* Plaintext Passwords Enabled – true/false – relates how passwords are read from the database table. If true when WLS retrieves the password from the database, and it encounters a non encrypted password, it will undertake a non encrypted comparison between the user's password who is attempting to login against the database retrieved password. If false, WLS will enforce the database password must be encrypted for it to undertake an encrypted password comparison.

The question arises, how does WLS know the database password is encrypted? The answer is derived from the next detailed property Password Style Retained, where WLS when writing a new encrypted password to the database prefixes the encrypted password with the encryption algorithm that was used to encrypt the password. If it's missing, WLS assumes a plaintext password.

If the Plaintext Passwords Enabled property is false, one other side effect is if you attempt to set the Password Style property to PLAINTEXT, then update a user's password in the database, WLS will throw an error stating it doesn't support PLAINTEXT passwords:

[Security:099063]Plaintext password usage was rejected.

Thanks to Ming at Oracle Support for clarifying this property.

* Password Style Retained – true/false – the following properties unlike the Plaintext Passwords Enabled property deal with when updating existing user passwords in the database table, not when the password is read. When WLS writes a password to the table's password field, along with the encrypted text, it prefixes the password with the password algorithm used wrapped in ellipses. For example if the SHA-1 algorithm is used, the password would look like:

{SHA-1}W6PH5MM5PZ8GGIULBPGZG37MJ9G=

If the Password Style Retained property is set to true, and the existing password has a different encryption algorithm to that specified in the Password Algorithm field, WLS will use the latter to update the password. If Password Style Retained is set to false, regardless, WLS will overwrite the password with that specified in the Password Algorithm field.

* Password Algorithm – text field – default SHA-1 – as per the WLS documentation this can be any Java Cryptography Extension (JCE). Questionably what are the allowable values derived from the JCE? These are listed in the JSE 6.0 Java Cryptography Architecture Standard Algorithm Name Documentation.

For password generation we want a hash (aka. message digest or 1-way encryption) algorithm. From the documentation we find that our options are limited to SHA-1 (the default Password Algorithm value), MD2 and MD5.

Note that the JSE documentation states the bit size of the produced message digest (SHA-1 = 160-bit, MD2 = 128-bit, MD5 = 128-bit), which will influence the size of your password field to store the encrypted database value.

The Password Algorithm can be ignored if the Password Style is PLAINTEXT, or, the Password Style Retained is set to true and the password to be updated does not match the current Password Algorithm's specified function.

* Password Style – PLAINTEXT, HASHED, SALTEDHASHED – as guessed the PLAINTEXT option will write the unencrypted password to the database. A value of HASHED implies the Password Algorithm will be used. SALTEDHASHED also produces encrypted passwords though different from HASHED. I'm currently unsure of the difference between HASHED and SALTEDHASHED, the WLS documentation doesn't differentiate between them, though it does result in a different encrypted value.

Testing

Assuming you've configured your SQL Authenticator correctly as per Edwin's post, let's test what the different settings of the properties do.

For our testing let's assume there's always an existing user ALPHA whose password we want to update, as well as new users BETA, CHARLIE and DELTA (and so on) who we want to create with a new password.

First test

Plaintext Passwords Enabled = true
Password Style Retained = true
Password Algorithm = SHA-1
Password Style = HASHED

For the existing user ALPHA the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".

For a new user BETA the password will be set to "password".

First result

Updated user ALPHA password = "password"

For the ALPHA users this result occurs because WLS encounters the Plaintext Passwords Enabled set to true, and the original password stored for the ALPHA user is unencrypted (ie. it's missing the algorithm prefix). WLS therefore decides an update to the password must be a plaintext password update.

New user BETA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

In this case the BETA user makes use of the SHA-1 algorithm.

Second test

Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED

Same as the last test, for the existing ALPHA user the encrypted password doesn't include the algorithm prefix (ie. {SHA-1}), in fact it was created by some other system that doesn't include the prefix. The ALPHA's password will be updated to "password".

For a new user CHARLIE the password will be set to "password".

Second result

Updated user ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

New user CHARLIE password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

In this case the Password Style Retained has overwritten the updated user ALPHA's password style with the new SHA-1 algorithm equivalent as the Password Style Retained = false setting removes the original plaintext algorithm – in other words the SHA-1 algorithm takes precedence. As expected the CHARLIE user's passwords uses the SHA-1 algorithm by default.

Third test

In this test we'll use the existing SHA-1 user ALPHA SHA-1 password, while switching to the MD2 algorithm, while not retaining passwords styles:

Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = MD2
Password Style = HASHED

Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

For a new user DELTA the password will be set to "password".

Third result

Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==

New user DELTA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==

As can be seen WLS switches to the MD2 algorithm in both cases as the Password Style Retained = false property enforces this.

Fourth test

In the last test we'll switch back to the SHA-1 algorithm, and attempt to update the ALPHA user's MD2 password to the SHA-1 equivalent asking WLS not to retain the existing password style:

Plaintext Passwords Enabled = true
Password Style Retained = false
Password Algorithm = SHA-1
Password Style = HASHED

Existing ALPHA password = {MD2}8DiBqIxuORNfDsxg79YJuQ==

Fourth result

Existing ALPHA password = {SHA-1}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

As expected the ALPHA user's password is changed from the MD2 to SHA-1 encrypted password, again as the Password Style Retained = false property takes affect.

Conclusion

At this point we've seen how WLS can generate encrypted passwords using different algorithms down to the database. From here it's important to check the encrypted results in the database are actually "standard". In other words if a competing technology uses the SHA-1 algorithm to encrypt a password for example, will it see the same encrypted result WLS produced. This will be addressed in a following post.

Where real ADF developers meet - OOW09 ADF EMG

Tue, 29 Sep 2009 01:08:00 EDT

Once again the ADF Enterprise Methodology Group is meeting at Oracle Open World to discuss JDeveloper and ADF, and we invite you to join us. This year Simon Haslam has taken the reins and delivered not 1 but 3 sessions at OOW which is an impressive effort.

Of particular interest to me is the "Show me yours!" session where ADF experts will be showing their production level ADF applications, essentially JDeveloper applications in the wild! We encourage you to join us, if not to show and tell, to just hear discussions among ADF experts on what challenges and solutions they're working with each day in the ADF market.

Can't make OOW this year but really want to attend ADF EMG? Are you attending the upcoming UKOUG conference instead? ADF EMG is going international this year, after our success at the ODTUG conference session in the excellent hands of Nathalie Roman, then OOW in October, we're happy to announce we'll be running a session at the UKOUG conference too. Watch this space for more information soon!

Blatant advert: Yes, we still do Oracle Forms development and training

Tue, 22 Sep 2009 09:21:00 EDT

Blatant plug for SAGE Computing Services. Avert your eyes now if you're not interested in the advert.

I was again asked today by a fellow Oracle professional, as we at SAGE present and blog on the latest JDeveloper and APEX technologies among others, does that mean we've dropped Oracle Forms development and teaching our Oracle Forms training course in Australia altogether?

Not at all. Oracle Forms is still a primary area of development for us and many of our customers, and our Oracle Forms training course has been updated every version since 4.5 to 10g, and soon to be Oracle Forms 11g. While our staff have interest in newer technologies, Forms will remain a skillset we'll maintain into the future, as Forms is pivotal to the success of our clients.

Our Oracle Forms training course, as long as our other Australian Oracle training courses can be found on our website.

Another Aussie Oracle blogger - Scott Wesley

Mon, 21 Sep 2009 22:44:00 EDT

Did I already post/tweet/email about Scott and his blog somewhere? I forgot. In the rush up to Oracle Open World, and moving house, I'm losing track big time of what I've done and haven't done. If I turn up to OOW without any pants you'll know why.

Anyhow, Scott Wesley, a fellow SAGE-ite, has taken up the Oracle blog reins, and can be found at Triangle Circle Square. Scott's one of the team's ninja consultants and Oracle trainers, defender of all things Oracle, except JDeveloper it seems, which makes me highly suspicious. Scott's current blog focus is SQL features, which seems oh-so-persistant-store-to-me. However I'm sure the SQL keen among you will enjoy his posts.

For the user groups out there, like much of the SAGE team, Scott is happy to present to your members. Drop us an email to arrange.

Upgrading Oracle WebLogic Servers from 10.3 to 10.3.1

Sat, 19 Sep 2009 09:15:00 EDT

Recently we upgraded our Oracle WebLogic Servers from 10.3 to 10.3.1, and coincidentally migrated a JDeveloper ADF application 11g to 11gR1. ADF applications require a set of libraries that must be deployed to WLS before the ADF application can run, of which we completed successfully, or so we thought. This post documents a little trap for new players when configuring WLS and deployed applications.

On deploying our upgraded ADF 11gR1 application to our WLS 10.3.1 server with the updated ADF libraries, we hit an error on deployment from JDev. The logs showed the following results:

[08:54:26 AM] ----  Deployment started.  ----
[08:54:26 AM] Target platform is  (Weblogic 10.3).
[08:54:39 AM] Entering Target Selection Dialog
[08:54:55 AM] Retrieving existing application information
[08:54:55 AM] Running dependency analysis...
[08:54:55 AM] Building...
[08:54:59 AM] Deploying 4 profiles...
[08:54:59 AM] Wrote Archive Module to C:\JDeveloper\mywork\CR123\trunk\CommonViewController\deploy\CommonViewController.jar
[08:54:59 AM] Wrote Archive Module to C:\JDeveloper\mywork\CR123\trunk\CommonModel\deploy\CommonModel.jar
[08:54:59 AM] Wrote Web Application Module to C:\JDeveloper\mywork\CR123\trunk\ViewController\deploy\App_ViewController.war
[08:55:00 AM] Wrote Enterprise Application Module to C:\JDeveloper\mywork\CR123\trunk\deploy\App_application1.ear
[08:55:04 AM] Deploying Application...
[08:55:06 AM] [Deployer:149191]Operation 'deploy' on application 'App_application1' is initializing on 'ADFServer'
[08:55:06 AM] [Deployer:149193]Operation 'deploy' on application 'App_application1' has failed on 'ADFServer'
[08:55:06 AM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application App_application1 on ADFServer.: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false]..
[08:55:06 AM] Weblogic Server Exception: weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
[08:55:06 AM]   See server logs or server console for more details.
[08:55:06 AM] weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
[08:55:06 AM] ####  Deployment incomplete.  ####
[08:55:06 AM] Deployment Failed

The last set of errors reveals that the server can't find the libraries that the deployed application are dependent on. To highlight them:

[08:55:06 AM] Weblogic Server Exception: weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].
[08:55:06 AM]   See server logs or server console for more details.
[08:55:06 AM] weblogic.management.DeploymentException: [J2EE:160149]Error while processing library references. Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false].

Note how WLS is stating it can't find adf.oracle.domain nor oracle.jsp.next.

This confused us because we could actually see them installed under the deployments tab in the WLS console. However the error in the end was a simple one on our part.

On installing the updated ADF libraries we installed them into the WLS AdminServer managed server. Yet on deploying our application, we chose to deploy the application to a separate WLS managed server called ADFServer (seen in the logs). For the application to find the ADF libraries, they needed to be installed into the ADFServer as well.

To fix this, one option is to head to the WLS console, locate the libraries in the Deployment node, and on selecting each library, under the Targets tab, ensure to allocate the libraries to the correct managed server. Alternatively your other option is to deploy your application to the WLS managed server where the libraries are targeted/installed.

WebLogic Server - Identity vs Trust Keystores

Sat, 12 Sep 2009 17:30:00 EDT

In computing most technologies have lots of terms and acronyms to learn, it's par for the course, you get used to it. However in computer security the frustration is multiplied as there are often many different terms that mean the same thing. It makes implementing security hard, because understanding it is hard, and I'm not surprised why security is considered badly implemented because the average Joe will struggle (and for the record I'm the average Chris so I struggle too ;-).

I've been trying recently to get straight in my head what is stored in the WLS identity and trust keystores, and what the difference between identity and trust is anyhow. Thanks to kind assistance from Gerard Davison, I think I can now post my understandings, and as usual, hopefully the post is helpful to other readers. As noted however security to me is a difficult area, and so be sure to check the facts here, your mileage with this post may vary.

The following WLS documentation attempts to explain the concepts of identity and trust:

http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/identity_trust.htm#i1170342

...in ripping out one of the core paragraphs, with a slight rewrite of my own we can see the concept of identity, and how it relates to the public and private keys:

"The public key is embedded in a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address *as well as the hostname*. *Along with this the digital certificate containing the public key, and the separate related private key, provide identity for the server*."

...ultimately to identify the server, to assert the server is who the server says it is.

The digital certificate containing the public key is also referred to as the "server certificate", as for example in 1-way-SSL traffic between the server and client, the server certificate containing the public key is what is initially passed to the client.

There is a missing piece in the puzzle. Regardless that the digital certificate states the owner of the public key, their name and so on, how does a client know that the "identity" asserted by the digital certificate is true? That's where Certificate Authorities (CAs) come in.

Ignoring self signed digital certificates, a typical digital certificate used on the internet containing the public key and owner details is signed by a trusted CA who has verified the identity of the owner. Presumably when purchasing digital certificates from CAs, this is what some of the cost covers, the CAs research into ensuring that the identity details embedded in the digital cert are actually true.

At runtime on receiving the digital certificate, the client checks the CA and if the CA is one that the client trusts (or a CA in a chain of trusted CAs), then the identity of the server is established/verified.

Thus the "identity" of the server is established by what's stored in the "identity" keystore, and its contents are what are farmed out to clients establishing secure connections with the server, who then verify the supplied digital certificate's CA against the clients own list of trusted CAs. The "identity keystore" is also referred to as the "server keystore", because it establishes the server's identity (ie. I am who I say I am).

WLS side note: As mentioned the digital certificate also includes the host name of the server, or in other words the digital certificate is pegged to that server and that server alone. This implies on that server with its relating digital certificate, *all* of the applications will share that single digital certificate for secure communications. Occasionally a requirement will arise where each application must have its own digital certificate. In WLS because keystores are configured under an individual WLS "managed server", if you have two separate applications, it is not possible to use separate digital certificates for each in one managed server. The solution is to create another managed server with its own keystores.

WLS web service side note: Following on from the previous side note, for web services that use in-message encryption and digital signatures, there is often the requirement for multiple different digital certificates. Under WLS to provision the WS-Security model, WLS has a separate Web Service Security Configuration (WSSC) to provision this setup.

Finally regarding the trust keystore, what is its job in all of this? The trust keystore is typically used for storing CA digital certificates, essentially the CAs who will be used to check any digital certificates that are given to the server at runtime (just the same as the client did above). In the standard 1-way-SSL between a client and the WLS server, the trust keystore doesn't come into the equation as the client has its own trust keystore (containing the CAs) and the server has nothing to verify. Yet in the case of mutual SSL (aka. 2 way SSL) between the client and server, the client and server actually swap each other digital certificates to establish identity of both parties, and in this case the server must be able to test the identity of the client through the CA of the client's digital certificate.

Mutual SSL side note: the setup of mutual SSL is more complicated than this. Readers are advised to refer to the following Oracle article.

Final author's note: if any readers find anything particularly wrong with the ideas presented in this post I'd be keen to hear them please. As I've really only experience with 1-way-SSL, it's hard to know if what I've said applies to the concepts of mutual SSL and other security configurations.

One-Way SSL with JAX-WS Using JDeveloper 11gR1 and WLS 10.3.1

Wed, 02 Sep 2009 11:00:00 EDT

A while back Gerard Davison blogged some simple examples of using WS-Security Policies. Gerard's specific example dealt with the WLS policy Wssp1.2-2007-Wss1.1-UsernameToken-Plain-X509-Basic256.xml. As Gerard notes the said policy (further documented in the WLS 10.3.1 doco here) implements user name tokens, encryption of the tokens and signing of the whole SOAP payload.

The following post strips back Gerard's example to instead to consider the steps in setting up and testing One-Way SSL for a JAX-WS web service generated via JDeveloper 11gR1 and installed in WLS 10.3.1, using the WLS policy Wssp1.2-2007-Https.xml.

Assumptions

This article assumes the reader has the following basic knowledge:

* HTTPS/SSL
* Digital certificates and trusted/certificate authorities (CAs)
* Oracle's WebLogic Server, WLS managed servers and the WLS console

One-Way SSL vs Two-Way SSL

For those not familiar with either, Oracle's WLS documentation has a good explanation of the implementation of and differences between One-Way SSL and Two-Way SSL in the Understanding Security for Oracle WebLogic Server manual.

Steps

To implement a One-Way SSL example we'll run through the following steps:

1) Create a basic JAX-WS web service with JDeveloper 11gR1
2) Generate the digital certificates required for the WLS server
3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy
4) Deploy the running web service to WLS
5) Test the running web service via JDeveloper's HTTP Analyzer
6) Test the running web service via SoapUI
7) Test the running web service via a JAX-WS client
8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted

1) Create a basic JAX-WS web service with JDeveloper 11gR1

This step is documented in a previous blog post Creating JAX-WS web services via a WSDL in JDev 11g. There are also a number of viewlet demonstrations available from Oracle's OTN which show how to construct the WSDL in a drag'n'drop fashion.

The resulting web service we'll demonstrate here is a very simple one. It is comprised of the following solutions:

OneWaySSLExample.xsd


            targetNamespace="http://www.sagecomputing.com.au" elementFormDefault="qualified">

The inputElement and the outputElement will constitute the incoming and outgoing payloads of a simple HelloWorld web service.

OneWaySSLExample.wsdl


             xmlns:tns="urn:OneWaySSLExample.wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
             xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsca="http://www.sagecomputing.com.au">

The overall web service comprises of a single operation accepting the inputElement and outputElement strings as specified in the XSD.

OneWaySSLPortTypeImpl.java

package au.com.sagecomputing.ws;

import javax.jws.WebService;

import javax.xml.ws.BindingType;
import javax.xml.ws.soap.SOAPBinding;

@WebService(serviceName = "OneWaySSLService",
            targetNamespace = "urn:OneWaySSLExample.wsdl",
            portName = "OneWaySSLPortTypePort",
            endpointInterface = "au.com.sagecomputing.ws.OneWaySSLPortType",
            wsdlLocation = "/WEB-INF/wsdl/OneWaySSLExample.wsdl")
@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
public class OneWaySSLPortTypeImpl {

  public String oneWaySSLOperation(String part) {
    return "Hello " + part;
  }
}

A very basic JAX-WS web service accepting the inputElement String and returning the outputElement String prefixed with "Hello ".

Example request SOAP payload


   
   
      Chris

Example response SOAP payload



   
      Hello Chris

The overall application/project structure will look as follows in JDeveloper's Application Navigator:

2) Generate the digital certificates required for the WLS server

In order for a client to undertake a SSL connection with our web service on the WLS server, the WLS server must be configured with a valid digital certificate.

Again note from the Oracle documentation how One-Way SSL works at runtime:

With one-way SSL authentication, the target (the server) is required to present a digital certificate to the initiator (the client) to prove its identity. The client performs two checks to validate the digital certificate:

1. The client verifies that the certificate is trusted (meaning, it was issued by the client's trusted CA), is valid (not expired), and satisfies the other certificate constraints.
2. The client checks that the certificate Subject's common name (CN) field value matches the host name of the server to which the client is trying to connect

If both of the above checks return true, the SSL connection is established.

In this section we consider the digital certificates required for the WLS server.

WLS is an interesting application server in that it keeps two separate Java keystores, 1 for storing the digital certificates for such actions as SSL, and another which is typically used for storing CA digital certificates. The former is referred to as the identity keystore, the later the trust keystore.

The WLS manual Securing Oracle WebLogic Server section 11 Configuring Identity and Trust has a detailed explanation of this setup.

By default WLS comes with demonstration identity and trust keystores containing demonstration digital certificates. As the WLS documentation takes great pains to explain these are for development purposes only and should never be used in a production environment. For the purposes of this blog post if you're testing One-Way SSL in a development environment you can in fact skip this entire step as the demonstration WLS keystores will suffice.

To check that the demonstration keystores are currently installed login to your WLS console, select your server, and under the Configurations -> Keystores tab you'll see the following entries:

Your entries for the file locations of the keystore will be different from my example here dependent on where you installed WLS.

However using the demonstration keystores avoids the whole learning exercise of configuring your own custom digital certificates in WLS which is an important lesson. The following describes those steps in detail, as based off Gerard's original post.

To install our own digital certificate we followed these general steps:

a) Open a command prompt and set the WLS environment
b) Generate our own trusted certificate authority digital certificate
c) Store the private key and digital certificate and import into the identity keystore
d) Store the same digital certificate into the trust keystore.
e) Configure the new keystores in WLS's identity and trust keystore

The following describes those steps in detail. In order to do this we've used WLS utilities to do as much of the work as possible.

a) Open a command prompt and set the WLS environment

Under Windows open a command prompt on the same machine as where WLS is installed, create a temporary directory in your favourite place and cd to that directory, and run your WLS server's setDomainEnv.cmd command. Something like:

"C:\\setDomainEnv.cmd"

Once run ensure you're still in your new directory.

b) Generate our own trusted certificate authority digital certificate

java utils.CertGen -certfile ServerCACert -keyfile ServerCAKey -keyfilepass ServerCAKey -selfsigned -e somebody@xxxx.com.au -ou FOR-DEVELOPMENT-ONLY -o XXXX -l PERTH -s WA -c AU

This generates 4 files: ServerCACert.der, ServerCACert.pem, ServerCAKey.der, ServerCAKey.pem

The utils.CertGen utility is useful for development purposes, but as per the WLS documentation, should not be used for production purposes. Alternatively OpenSSL could be used instead.

Note the use of selfsigned flag. This implies this digital certificate will be used both as the CA in the trust keystore and the served digital certificate in the identity keystore. This is not what we'd do for a production environment using commercial Certificate Authorities, but is sufficient for demonstration purposes in this post.

More information on:

* the WLS CertGen utility can be found here.
* .der vs .pem files can be found here and here.
* WLS provides two utilities der2pem and pem2der can be used to convert between the two file types.

Under Windows you can double click on the ServerCACert.der file to show its contents:

If you have access to the openSSL command line tool you can use it to query the certificate we just created:

openssl x509 -text -inform der -in ServerCACert.der

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0d:a9:d1:4a:0f:0b:b2:61:13:90:89:f5:40:4d:4f:e2
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=AU, ST=WA, L=PERTH, O=SAGECOMPUTING, OU=FOR-DEVELOPMENT-ONLY, CN=/emailAddress=somebody@sagecomputing.com.au
        Validity
            Not Before: Jul  9 07:06:49 2009 GMT
            Not After : Jul 10 07:06:49 2029 GMT
        Subject: C=AU, ST=WA, L=PERTH, O=SAGECOMPUTING, OU=FOR-DEVELOPMENT-ONLY, CN=/emailAddress=somebody@sagecomputing.com.au
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:df:cb:6c:ed:86:75:4c:5b:66:cd:aa:3d:34:8f:
                    
                    73:f6:9c:b5:ed:82:9c:c3:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1
    Signature Algorithm: md5WithRSAEncryption
        b7:fa:1b:8f:c4:ee:af:6b:1d:f0:dc:f4:cf:35:20:f1:df:eb:
        
        0c:fe
-----BEGIN CERTIFICATE-----
MIIC8zCCAlygAwIBAgIQDanRSg8LsmETkIn1QE1P4jANBgkqhkiG9w0BAQQFADCB

i7Pd63d03mWkI85tvsr5Q+40yitOL5JnLsbyHSrM+1aK8kkY7Qz+
-----END CERTIFICATE-----

This identifies information that maybe useful later if we make a mistake, such as the encryption algorithm used (RSA), the size of the keys (1024bit), the serial number of the certificate (a hex number).

c) Store the private key and the digital certificate in the identity keystore

java utils.ImportPrivateKey -certfile ServerCACert.der -keyfile ServerCAKey.der -keyfilepass ServerCAKey -keystore ServerIdentity.jks -storepass ServerCAKey -alias identity -keypass ServerCAKey

d) Store the same digital certificate into the trust keystore
Import the certificate generated in step b into a trust keystore.

keytool -import -v -trustcacerts -alias identity -file ServerCACert.der -keystore ServerTrust.jks -storepass ServerTrustStorePass

e) Configure the new keystores in WLS's identity and trust keystore

To configure the keystores in WLS enter the WLS console, select the managed server you're interested in, then make the following changes under the following tabs:

Configuration tab -> General subtab

SSL Listed Port Enabled = checkbox
SSL Listen Port = 7102 (and different from the Listen Port)

Configuration tab -> Keystores subtab

Keystores = Custom Identity and Custom Trust
Custom Identity Keystore = \ServerIdentity.jks, such as c:\temp\ServerIdentity.jks
Custom Identity Keystore Type = jks
Custom Identity Keystore Passphrase = ServerCAKey
Confirm Custom Identity Keystore Passphrase = ServerCAKey

Custom Trust Keystore = \ServerTrust.jks, such as c:\temp\ServerTrust.jks
Custom Trust Keystore Type = jks
Custom Trust Keystore Passphrase = ServerTrustStorePass
Confirm Custom Trust Keystore Passphrase = ServerTrustStorePass

Configuration tab -> SSL subtab

Identify and Trust Locations = Keystores
Private key alias = identity
Private Key Passphrase = ServerCAKey
Confirm Private Key Passphrase = ServerCAKey

Then save.

After this restart your WLS server and you should see similar messages to the following in the WLS logs:

Alternatively is you see the following messages you have made a mistake in your configuration:

10/07/2009 4:08:30 PM WST>     
<10/07/2009 4:08:30 PM WST>     
<10/07/2009 4:08:30 PM WST>

3) Modify the web service to use the Wssp1.2-2007-Https.xml WLS policy

This can be done in a number of ways in JDeveloper, the easiest of which for this blog post at least is just to insert the @Policy annotation into the JAX-WS endpoint as follows:

(Note if you're using earlier versions of JDeveloper or Eclipse, this mechanism wont work, you must manually add the policies to the WSDL).

package au.com.sagecomputing.ws;

import javax.jws.WebService;

import javax.xml.ws.BindingType;
import javax.xml.ws.soap.SOAPBinding;

import weblogic.jws.Policy;

@WebService(serviceName = "OneWaySSLService",
            targetNamespace = "urn:OneWaySSLExample.wsdl",
            portName = "OneWaySSLPortTypePort",
            endpointInterface = "au.com.sagecomputing.ws.OneWaySSLPortType",
            wsdlLocation = "/WEB-INF/wsdl/OneWaySSLExample.wsdl")
@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
@Policy(uri = "policy:Wssp1.2-2007-Https.xml") 
public class OneWaySSLPortTypeImpl {

  public String oneWaySSLOperation(String part) {
    return "Hello " + part;
  }
}

4) Deploy the running web service to WLS

Within JDeveloper to deploy and run from the integrated WLS, it's simply a case of right clicking on the JAX-WS file and selecting Run.

If you click on the hyperlink provided in the log window, this will open the HTTP Analyzer. From the HTTP Analyzer you can open the WSDL at the top of the window:

Note on deployment to WLS you can see that the Wssp1.2-2007-Https.xml policy has been added to the binding to enforce One-Way SSL, and in addition the service address now runs from HTTPS, not HTTP, on the now enabled SSL port.

5) Test the running web service via JDeveloper's HTTP Analyzer

JDeveloper out of the box includes HTTP Analyzer for testing your web services. It's particularly useful as you don't have to leave the confines of your IDE to test your web services.

In order to run the HTTP Analyzer with SSL'ed web service traffic, you need to make some changes to the configuration of JDeveloper. Selecting the Tools->Preferences menu option, followed by Https and Truststore Settings, you can configure the Client and Server keystores HTTP Analyzer needs to run with SSL.

If you followed my exact instructions on setting up a selfsigned CA into the WLS identity and trust keystores, you need to enter the following options in the Preferences Https and Trusting Settings page:

Client Trusted Certificate Keystore: c:\temp\ServerTrust.jks
Client Trusted Keystore Password: ServerTrustStorePass

Server Keystore: c:\temp\ServerIdentity.jks
Server Keystore Password: ServerCAKey
Server Private Key Password: ServerCAKey

When you run your web service you can access the HTTP Analyzer by clicking on the URL of your served web service in the JDev IDE log window, among other methods.

This presents the following HTTP Analyzer screens:

In the top of the screen you'll see the HTTP Analyzer has formed a dummy request for you to send out based on the web service's WSDL. In my example picture I've filled out the part field and pressed Send Request, of which you can see the reply from the web service on the right hand side.

At the bottom of the screen you can the individual request/responses that were generated in order to service the request.

6) Test the running web service via SoapUI

SoapUI is a popular web service testing tool. I wanted to show how to configure it here to show similar results to the HTTP Analyzer. The following steps were built with SoapUI v3.0.

a) Create a new Project via File -> New soapUI Project
b) In the New SoapUI Project dialog, enter a custom project name, then your WSDL, leave the rest of the fields as default.

c) In the Project list expand your new project to the last Request 1 node, and double click it.
d) This will open the Request 1 window, showing on the left handside the outgoing request payload, where you can modify the inputElement XML element with your name.
e) Pressing the green arrow executes the request against the webservice, you'll now hopefully see the SOAP response on the right handside of the window.
f) Note at the bottom right of the right handside of the window you have the text SSL Info. Clicking on this shows another sub-window with the SSL certificate information that was swapped with the WLS server to undertake the SSL communications.

7) Test the running web service via a JAX-WS client

Assuming under JDeveloper you know how to create a Java Proxy for the deployed web service, you'll end up with the following code:

import clientexamples.SSLUtilities;

import javax.xml.ws.WebServiceRef;

public class OneWaySSLPortTypePortClient
{
  @WebServiceRef
  private static OneWaySSLService oneWaySSLService;

  public static void main(String [] args)
  {
    oneWaySSLService = new OneWaySSLService();
    OneWaySSLPortType oneWaySSLPortType = oneWaySSLService.getOneWaySSLPortTypePort();

    SSLUtilities.trustAllHttpsCertificates(); 

    System.out.println(oneWaySSLPortType.oneWaySSLOperation("Chris"));
  }
}

Note SSLUtilities is a handy class written by Srgjan Srepfler that includes a number of methods for handling and modifying the default SSL behaviour. In our case in writing a simple test client we're not overly concerned about trusting the server's CA, so we can use SSUtilities.trustAllHttpsCertificates to stop the required checking.

8) Inspect the web service packets on the wire to verify the traffic is indeed encrypted

What neither JDeveloper's HTTP Analyzer nor SoapUI can do is actually confirm for you that the traffic on the network was actually encrypted. To check this we can use a wire sniffing tool called WireShark.

Warning: at some sites using wire sniffing tools like WireShark can be a dismissible offence because you can see private data on the network. Be careful to check your organisation policies before doing this.

Note if you're running the JAX-WS web services via the integrated WLS on the same localhost as SoapUI, you're most likely running through the localhost address. For various technical reasons WireShark cannot sniff packets through localhost or the MS loopback adapter in Windows. Instead we must separate our WLS and SoapUI installations, and place them on different hosts. Let's call them Box1 and Box2, with WLS and SoapUI installed respectively

Once you have both up and running, determine the IP address of Box2. Let's say that IP address was: 101.102.103.104

a) Start WireShark. In the filter box top left enter: ip.addr == 101.102.103.104
b) Select the filter Apply button.
c) Select the Capture -> Interfaces
d) Select the Start button for your ethernet card
e) WireShark is now sitting listening for traffic from the other ip.address of Box2.

f) Now in SoapUI execute the request.
g)In WireShark you should see the incoming requests:

As WireShark works at the network level it sees the individual packets, several of which will comprise the request/response between SoapUI and WLS, effectively an incredible amount of detail. You can select each packet and look at the data contained within in the bottom window of the display. This window shows the data in both hex and raw text, so you'll need to carefully look to see the data contained within. Obviously if the traffic is encrypted you wont see much meaning at all which is what we want! To see the unencrypted traffic, remove the policy from your web service, redeploy it and run the same scenario again.

Thanks

I must aim my very strong thanks to Gerard Davison from Oracle UK with assistance with this article, Gerard's help has been invaluable. Any mistakes in this post are of course mine however, of which I'm sure there will be a few in such a long post.

JDev 11gR1 - af:tree mashup – Using Hierarchical Tables and Drag-n-Drop

Wed, 02 Sep 2009 02:35:00 EDT

This blog post demonstrates creating an ADF Faces RC af:tree component that sources its data from a hierarchical database table, and supports drag n drop of the nodes.

Both these topics have been discussed and demonstrated by other excellent bloggers, the core of this post is to bring both concepts together, with my usual own proof of concept documentation that may be useful to readers.

The ADF Faces RC support for hierarchical data sources was defined by Chandu Bhavsar.

The drag and drop support for af:trees was documented by Luc Bors.

(Definitely the kudos for this post must go to both Chandu and Luc for their posts that sparked the inspiration for mine)

Data model

In this example we'll use the following table:

CREATE TABLE organisations
(org_id        NUMBER(4,0)  NOT NULL
,parent_org_id NUMBER(4,0)
,name          VARCHAR2(35) NOT NULL
,CONSTRAINT org_pk PRIMARY KEY (org_id)
,CONSTRAINT org_parent_fk
 FOREIGN KEY (parent_org_id)
 REFERENCES organisations (org_id));

Note the FK between the table and itself, essentially modelling that an organisation has sub-organisations (or agencies).

The data:

ORG_ID  PARENT_ORG_ID  NAME
------  -------------  -------------------------------
1000    (null)         Sage Computing Services
1010    1000           Training Division
1030    1010           Self Study Program
1040    1010           Classroom Training
2264    (null)         Australian Medical Systems
3210    (null)         Conservation Society
3214    3210           Forests Division
3216    3210           Rivers Division
4394    (null)         Newface cosmetics
3842    (null)         Institute of Business Services
3843    3842           Marketing Services
3844    3842           Financial Services

Hierarchical af:tree

This details the steps to setup an ADF BC layer and ADF Faces RC bindings to support the af:tree with hierachical data from the organisations table, as previously described in Chandu Bhavsar post.

Note the following steps are well documented on Chandu's post, though you will find slightly more detail on creating the correct bindings below:

1) Create a Fusion Web App with an ADF BC Model project and ADF Faces RC ViewController.

Model project

2) In the Model project create an empty Application Module (AM)

3) Create an Entity Object (EO) based on your organisations table in the database.

4) Create two View Objects (VO) based off the same EM. Name the first ParentOrgView and the second LeafOrgView.

5) Modify the ParentOrgView query as follows:

SELECT Organisations.ORG_ID, 
       Organisations.PARENT_ORG_ID, 
       Organisations.NAME
FROM ORGANISATIONS Organisations
WHERE Organisations.PARENT_ORG_ID IS NULL

6) You don't need to modify the LeafOrgView query. For completeness it's described as follows:

SELECT Organisations.ORG_ID, 
       Organisations.PARENT_ORG_ID, 
       Organisations.NAME
FROM ORGANISATIONS Organisations

7) Create a VO Link between the ParentOrgView and LeafOrgView as follows:

Essentially:

ParentOrgView.OrgId = LeafOrgView.ParentOrgId

8) Create a second VO Link between the LeafOrgView to itself as follows:

Essentially:

LeafOrgView (source).OrgId = LeafOrgView (dest).ParentOrgId

9) Externalize the VOs through the AM using the following model:

Essentially:

ParentOrgView1
- LeafOrgView1
- - LeafOrgView2

ViewController project

10) In your ViewController project create a new blank JSF page called treeMashupDemo.jspx.

11) From the Data Control Palette drag the ParentOrgView onto the page as a tree. In the Edit Tree Binding you should see the following:

Note the first level of the tree has been defined as model.ParentOrgView.

12) For clarity when testing later, ensure both the OrgId and Name are included in the Display Attributes.

13) With the model.ParentOrgView node selected in the Tree Level Rules, select the green plus (+) button and select LeafOrgView:

14) With the LeafOrgView node selected in the Tree Level Rules, ensure both the OrgId and Name are included in the Display Attributes.

15) Again with the LeafOrgView node selected in the Tree Level Rules, again select the green plus (+) button, and select LeafOrgView__2:

Note how the Tree Level Rules only has 2 nodes, but to the right of each node is the child of the current node. Of specific interest in the hierarchical relationship between LeafOrgView and LeafOrgView__2.

16) For reference the JSF af:tree code is as follows:

         var="node"
         selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}" 
         rowSelection="single"
         id="t1">

...the bindings look as follows:

..and the page def XML file as follows:


                Package="view.pageDefs">

Testing

On running our web page we see the following:

Note that the tree is happily showing the hierarchical data based on our tree bindings.

Adding drag n drop to the tree

The next set of functionality we wish to add is the ability to drag and drop nodes, or in our case organisations, in the tree. This involves adding support for drag n drop to the tree, as well as behind the scenes updating the dropped organisation's parent_org_id to that of the org_id of the organisation the original was dropped on.

The inspiration of this section comes from Luc Bors blog post, with slight difference in mine some of the supporting code is further spelt out:

1) As a reminder at the moment our af:tree code looks as follows:

         var="node"
         selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}" 
         rowSelection="single"
         id="t1">

2) We then introduce a collectionDragSource and a collectionDropTarget to support the drag and drop within the tree:

         var="node"
         selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}" 
         rowSelection="single"
         id="t1">
                             modelName="DnDOrganisations"/>
                             modelName="DnDOrganisations" 
                           dropListener="#{treeBean.dragAndDrop}"/>

Note both support the MOVE action, they both specify a matching modelName DnDOrganisations, and finally the dropListener maps to a backing bean method we'll define in a moment. It's essential the modelName's match including the case of the name, and we'll be referring to this in the dragAndDrop backing bean treeBean method in a moment.

3) In your adfc-config.xml file declare a bean treeBean of class view.TreeBean:

4) And create a Java class TreeBean in your view package within the ViewController project.

package view;

public class TreeBean {

}

The real work for drag and drop is done in the backing bean method. However in order for the code to work there are a couple of items we need to configure in the Model project:

5) Create an AppModuleImpl for the AM

6) Create a LeafOrgViewImpl for the VO

7) Create a LeafOrgViewRowImpl for the VO and ensure to include the accessors

8) In the AM expose the LeafOrgView VO one more time as its own node (not a child), and call the usage LeafOrgViewAll as follows:

9) Finally the dragAndDrop code is as follows. Note the code includes inline documentation comments that explains what is occurring:

package view;

import model.AppModuleImpl;
import model.LeafOrgViewImpl;
import model.LeafOrgViewRowImpl;
import model.ParentOrgViewRowImpl;
import oracle.adf.model.BindingContext;
import oracle.adf.view.rich.component.rich.data.RichTree;
import oracle.adf.view.rich.datatransfer.DataFlavor;
import oracle.adf.view.rich.datatransfer.Transferable;
import oracle.adf.view.rich.dnd.DnDAction;
import oracle.adf.view.rich.event.DropEvent;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlHierNodeBinding;
import oracle.jbo.Key;
import oracle.jbo.uicli.binding.JUCtrlHierNodeBinding;
import org.apache.myfaces.trinidad.model.CollectionModel;
import org.apache.myfaces.trinidad.model.RowKeySet;

public class TreeBean {
  
  public DnDAction dragAndDrop(DropEvent dropEvent) {
    // The default action - do nothing
    DnDAction result = DnDAction.NONE;

    // Represents the object that was dropped    
    Transferable draggedTransferObject = dropEvent.getTransferable();
    
    // The data in the draggedTransferObject "Transferrable" object is the row key for the dragged component.
    // Note how the DnDOrganisations value in the call to getDataFlavor() matches the collectionDragSource
    // and collectionDropTarget tags model attributes in our page.  It's essential the strings exactly match.
    DataFlavor draggedRowKeySetFlavor = DataFlavor.getDataFlavor(RowKeySet.class, "DnDOrganisations");
    RowKeySet draggedRowKeySet = draggedTransferObject.getData(draggedRowKeySetFlavor);
       
    if (draggedRowKeySet != null) {
      // We grab the tree's data model, essentially the CollectionModel that stores the complete tree of nodes
      CollectionModel treeModel = draggedTransferObject.getData(CollectionModel.class);
       
      // Ask the collection model to set the current row/node to that of the transferrable object that was dropped
      Object draggedKey = draggedRowKeySet.iterator().next();
      treeModel.setRowKey(draggedKey);
    
      // Grab that current row (thanks to the last statements work) and get the row's OrgId. It's essential the
      // OrgId is one of the displayed attributes in the tree binding.
      FacesCtrlHierNodeBinding draggedTreeNode =  (FacesCtrlHierNodeBinding)treeModel.getRowData();      
      oracle.jbo.domain.Number draggedTreeNodeId = (oracle.jbo.domain.Number)draggedTreeNode.getAttribute("OrgId");

      // The dropEvent carries the target/location's row key where the dropped organisations was dropped
      Object serverRowKey = dropEvent.getDropSite();
      RichTree richTree = (RichTree)dropEvent.getDropComponent();
      // This time we use the tree itself to make it's current row that of the server row key (ie. the destination)
      richTree.setRowKey(serverRowKey);
      // And we retrieve that row's index
      int rowIndex = richTree.getRowIndex();

      // The rich tree based on the index allows us to retrieve that current row/organisation's OrgId
      oracle.jbo.domain.Number targetNodeId = (oracle.jbo.domain.Number)((JUCtrlHierNodeBinding)richTree.getRowData(rowIndex)).getAttribute("OrgId");
      
      // At this point we now have the OrgId of the dropped organisation (draggedTreeNodeId) and the OrgId of the
      // organisation that is the target.  From here we simply want to update the dropped organisations' ParentOrgId
      // to the OrgId of the target.  This is best done through the model layer.
      //
      // Normally this would be best done by fetching the appropriate iterator bindings and making the changes through
      // the bindings.  However in this case the tree doesn't expose any iterator for the leaf nodes, so we need to
      // resort to retrieve the Model project's objects and do the work ourself.
      
      // Retrieve the AM and then a handle on the LeafOrgViewAll - this gives us access to all rows regardless of
      // where they exist in the hierarchy
      AppModuleImpl am = (AppModuleImpl)BindingContext.getCurrent().getDefaultDataControl().getApplicationModule();
      LeafOrgViewImpl leafOrgView = (LeafOrgViewImpl)am.getLeafOrgViewAll();
      
      // Given the dragged organisation's OrgId, construct a key object, and then retrieve that row from the VO using
      // the key
      Object[] nodeObjectKey = new Object[] {draggedTreeNodeId};
      Key nodeKey = new Key(nodeObjectKey);
      LeafOrgViewRowImpl nodeRow = (LeafOrgViewRowImpl)leafOrgView.getRow(nodeKey);

      // See below
      boolean parentNode = nodeRow.getParentOrgId() == null;
      
      // Finally update that organisaiton's ParentOrgId to that of the target organisation's OrgId
      nodeRow.setParentOrgId(targetNodeId);

      // And commit the changes – obviously this has side effects on any other uncommitted data, be careful
      am.getDBTransaction().commit();
      
      // If we've moved a parent node to become a leaf, we need to force the parent VO to requery itself to correctly
      // reflect the data change.  This is destructive on the current expand/collapsed state of the tree.
      // I'm not overly sure of a solution for this; maybe a reader can suggest one.
      if (parentNode) {      
        am.getParentOrgView1().clearCache();
        am.getParentOrgView1().executeQuery();
      }
      
      // Indicate to the dragEvent that the operation was succesful and visually the move should occur in the tree
      result = DnDAction.MOVE;
    }
    return result;
  }
}

You'll note in the code I take pains to mention it's essential the OrgId is one of the displayed attributes for the tree. If you fail to supply this the routine has no OrgId attribute to fetch the OrgId value from.

This does pose a problem, because while during testing it's fine to show the OrgId and Name of the organisations in the tree, for production we might not want to show these meaningless internal ID numbers to the user. The simple fix for this is to return to the af:tree and update the af:outputText component who is responsible for what values to show for each node in the tree, changing the EL expression from #{code} to #{code.Name}:

         var="node"
         selectionListener="#{bindings.ParentOrgView1.treeModel.makeCurrent}" 
         rowSelection="single"
         id="t1">
                             modelName="DnDOrganisations"/>
                             modelName="DnDOrganisations" 
                           dropListener="#{treeBean.dragAndDrop}"/>

This ensures only the name attribute is displayed:

JDev/ADF – the importance of getting PS_TXN and PS_TXN_SEQ correct

Tue, 11 Aug 2009 03:03:00 EDT

This is a revisit post about two important database objects for ADF, the database objects PS_TXN and PS_TXN_SEQ. The table and sequence are used by ADF to serialize user session state to the database. An old Oracle OTN whitepaper gives the low-down on these 2 objects.

Without these database objects your application can't scale effectively to multiple users, you'll see some bizarre and wonderful behaviour as ADF chokes on not having the ability to serialize to the database objects. However it's not an ADF problem, the manuals clearly state that you need to grant specific privileges to the database user or create the database objects beforehand.

I know now of 2 projects where serious problems occurred because the database wasn't configured correctly to accept the objects, and found another blog post detailing the same issue.

Pascal Alma's blog post can be found here.

In the 1st project, the developers overlooked giving privileges to the ADF database user schema to create the table and sequence, and didn't undertake load/stress tests to see how the application performed with more than one user. As soon as the application hit production with multiple users, ADF attempted to serialize to the database objects, and the system started hitting a huge array of issues. The worst bit was some of the errors were real red herrings making the problem hard to diagnose. However after much time with Oracle Support assistance the problem was solved. This destroyed the developers' faith in ADF and the users' faith in the developers and new ADF system.

The 2nd project is one I'm involved in currently. We were creating new database schemas for the ADF user and for some reason we didn't grant the create sequence privilege, but did grant the create table priv. Luckily I stress tested the app and found the problem fairly early on (with Steve Muench's kind help). However it did take a full 8 hours to debug, so I thought worth documenting here to help others.

What I'd thought I document is what errors you'll see in the WLS logs for JDev 11g build 5188 and JDev 11gR1 build 5407. I don't have an earlier version of JDev to test what happens but Pascal's blog post from above may assist.

Under JDev 11g build 5188 you'll see the following WLS log entries:

First it'll throw errors that it can't retrieve user session state:

SEVERE: Could not find saved view state for token -505abe38
11/08/2009 14:29:29 org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView
SEVERE: Could not find saved view state for token -505abe38
11/08/2009 14:29:29 org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView
SEVERE: Could not find saved view state for token -505abe38
11/08/2009 14:29:29 org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView

At a later point in the logs you'll see exceptions thrown, but they're not very meaningful:

WARNING: ADFc: Error while opening JDBC connection.
oracle.jbo.DMLException: JBO-26061: Error while opening JDBC connection.
 at oracle.jbo.server.ConnectionPool.createConnection(ConnectionPool.java:253)
 at oracle.jbo.server.ConnectionPool.instantiateResource(ConnectionPool.java:168)
 at oracle.jbo.pool.ResourcePool.createResource(ResourcePool.java:546)
 at oracle.jbo.pool.ResourcePool.useResource(ResourcePool.java:327)

Further in the logs you may see the following TNS Listener issue (though this may just be particular to my Oracle XE setup):

Caused by: java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was:
localhost:1521:xe
 at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
 at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:116)
 at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:177)

And you may see NullPointerExceptions dependent on what ADF was attempting to do with the database connection at the time:

Caused by: java.lang.NullPointerException
 at oracle.adf.model.binding.DCIteratorBinding.initSourceRSI(DCIteratorBinding.java:1735)
 at oracle.adf.model.binding.DCIteratorBinding.callInitSourceRSI(DCIteratorBinding.java:1625)
 ... 75 more

Under JDev 11gR1 build 5407 gives you a more meaningful error message:

Again, first you'll see errors that it can't retrieve user session state:

SEVERE: Could not find saved view state for token -ce0efchp5
11/08/2009 2:35:31 PM org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView
SEVERE: Could not find saved view state for token -ce0efchp7
11/08/2009 2:35:31 PM org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView
SEVERE: Could not find saved view state for token -ce0efchp7
11/08/2009 2:35:31 PM org.apache.myfaces.trinidadinternal.application.StateManagerImpl restoreView

But then you'll see a much more meaningful message that ADF can't create the required objects:

oracle.jbo.PCollException: JBO-28006: Could not create persistence table PS_TXN_seq
 at oracle.jbo.PCollException.throwException(PCollException.java:36)
 at oracle.jbo.pcoll.OraclePersistManager.createTable(OraclePersistManager.java:908)
 at oracle.jbo.pcoll.OraclePersistManager.queryNextCollectionId(OraclePersistManager.java:1444)

And further down:

Caused by: java.sql.SQLSyntaxErrorException: ORA-01031: insufficient privileges
 at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:91)
 at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
 at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:206)
 at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:455)
 at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:413)

Hopefully in Googling these error messages and landing on this page, you'll be able to work out how to correctly configure the database objects to avoid these issues.

SoapUI for Web Service Testing

Fri, 07 Aug 2009 02:11:00 EDT

A popular tool for web service testing is SoapUI. The following blog post describes how to use it for testing a simple web service, as well as setting up a series of tests and even load/stress testing. Without a doubt similar documentation is available on the SoapUI website; my post gives my spin on the product that maybe useful to others.

WLS: Nonsensical error message on web services HTTPS policy enforcement

Mon, 27 Jul 2009 22:45:00 EDT

Mostly a post to document something I keep on forgetting, hopefully useful to someone else.

Under WebLogic Server 10.3.1 (and maybe present in earlier versions of WLS?), on testing a deployed web service I occasionally get this HTTP response from WLS:

Error 500--Internal Server Error

javax.servlet.ServletException: unable to send error:
at weblogic.wsee.jaxws.HttpServletAdapter.sendAccessError(HttpServletAdapter.java:240)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:195)
at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:297)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
.. snip ..
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
at com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl.checkIfStandardFaultCode(Fault1_2Impl.java:134)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:126)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:91)
.. snip ..

Note the message half way down the stack trace "Caused by". In turn in the WLS logs I receive the following error:

22/07/2009 12:15:46 PM com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl checkIfStandardFaultCode
SEVERE: SAAJ0435: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
<22/07/2009 12:15:46 PM WST>    <[ServletContext@23322757[app:MyWebServices module:MyWebServices path:/MyWebServices spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@61061d[
POST /MyWebServices/My.Service HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://acme.com/com/my.service"
User-Agent: Jakarta Commons-HttpClient/3.1
Content-Length: 4948

]] Root cause of ServletException.
com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value
at com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl.checkIfStandardFaultCode(Fault1_2Impl.java:134)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:126)
at com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:91)
.. snip ..

You can see between the HTTP error and the WLS logs the same message:

com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: {http://www.w3.org/2003/05/soap-envelope}Client.Access is not a standard Code value

...followed by the SAAJ classes complaining about the SOAP Fault in the stack trace. In guessing what's occurring, the web service or WLS has thrown an error, but in transferring that error to a SOAP Fault response, the SAAJ classes don't think the SOAP fault itself is valid. In other words the real error is obscured because the error mechanism itself is bust.

So ignoring the error mechanism failure, what had I done wrong? After a lot of head scratching, I discovered my mistake.

I'd originally built a client to access my web service at the following URL:

http://MyWlsServer:7001/MyWebServices/My.Service

Subsequently I'd changed my web service to implement SSL via the WLS policy Wssp1.2-2007-Https.xml. To successfully access the web service thereafter I needed to access it at this new URL:

(Note the https delineator and port 7003, my configured WLS SSL port)

https://MyWlsServer:7003/MyWebServices/My.Service

...but in forgetting to change my client to the new URL, the error as above is thrown. Presumably the real error message would be "No such service" or "Service requires HTTPS" or "Chris, you've made another mistake!"

For reference I've tested this the other way around, where the web service isn't enforcing the WLS HTTPS policy, but the client access the https URL, and it works fine. This makes sense as the WLS policy is an enforcement of HTTPS traffic for that specific web service, not implementing HTTPS in general for WLS, that's left up to WLS which we've already preconfigured for WLS traffic. As such we can still use HTTPS for our web service even if the web service isn't enforcing HTTPS.

In addition note because of the generic error message returned here, readers should be careful to ascertain if what I describe in this post actually applies in their case. There's also the good chance this error will be for totally different reasons in different implementations of WLS.

And for the record I'll get around to logging an SR with Oracle Support soon. Anybody want to write the simple test case and steps to reproduce for me please? ;-)

JDev 11gR1: the most obscure new IDE feature

Mon, 13 Jul 2009 20:00:00 EDT

Each new release of JDeveloper brings an explosion of blog posts from the excited JDeveloper advocates and Oracle staff. Within a week or so all the major new features are identified and explained, leaving slow typers like me wondering what to cover to get readers excited.

So for the latest JDeveloper 11gR1 release, I've taken the opportunity to explore for the most obscure feature, the feature hardly anybody is likely to see, or possibly even care about until they discover it.

And today I think I found it. Small celebratory "woohoo!" on my part.

Take a look at this screenshot of the source code of a standard ADF Faces RC page in all its XML glory:

In the next picture I've deleted the af:inputText tag. Besides the removal of the tag, can you see the subtle change in the source code editor? Believe me you'll have to look really hard:

Spotted it? Let me point it out:

Can you see the little pastel pink colour in the new thin left margin that runs down the page? If you float the mouse over the colour you get:

...a little popup that shows the code you deleted. The new margin feature shows visually the addition and removal of code as tied to the IDE's undo history. If you right click on the small colour segment you get a context menu that lets you work with the change:

As promised, I believe this to be the most obscure new feature in JDev11gR1. I set a friendly challenge to readers to find an even smaller obscure new feature in the latest release.

Increasing/decreasing JDev 11g ADF Faces RC page font size at runtime

Tue, 07 Jul 2009 00:08:00 EDT

A feature seen on some web sites is buttons to increase and decrease the text font size. While most browsers supply this functionality by default (eg. In Firefox you can press Ctrl plus or minus), giving web page buttons to do this can assist less computer literate users who may not now about the browser's inbuilt functions.

The solution requires a javascript routine. A quick Google on "javascript increase fontsize" returns a number of useful hits including this one by White Hat Web Design.

White Hat's code is a fairly common example available on the internet for doing just this in a standard web page.

Providing this functionality in JDeveloper 11g's ADF Faces RC requires a bit of tweaking. The following describes the bits of code you'll need.

Javascript

The following code takes the White Hat javascript and tweaks it:


var fontMin=10;
var fontMax=36;
function increaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // here
   for(i=0; i < p.length; i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 14;
      }
      if(s!=fontMax) {
         s += 2;
      }
      p[i].style.fontSize = s+'px';
   }
}

function decreaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // and here
   for(i=0; i < p.length;i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 12;
      }
      if(s!=fontMin) {
         s -= 2;
      }
      p[i].style.fontSize = s+'px';
   }   
}

First tweaks to the original code, note that each method now takes an event object, and then cancels the event on executing the javascript. While I'm not entirely over the need for this, my understanding is it hooks into the ADF Faces RC javascript engine and we'll see a bit further down in this post the usage of the clientListener tags to invoke this javascript. (Some more documentation on the ADF javascript engine would be appreciated Oracle – hint hint).

Secondly note the two commented lines. The original code searched for <p> tags, while in ADF Faces RC pages we need to search for <span> tags, as this is where ADF Faces RC places raw text.

Load the javascript into JSF

In the page we wish to include the javascript we include the following code:

...assuming you stored the above javascript in the ViewController public_html/js subdirectory as fonts.js.

(Alternatively this tag could go into your JSF template so you only need to include it once)

Note that this is in fact a Apache Trinidad component, not ADF Faces RC. As such you also need to change your JSF page's <jsp:root> tag to include the Trinidad HTML tag library as follows:


  xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" 
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html"   
  xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
  xmlns:trh="http://myfaces.apache.org/trinidad/html">

Buttons

Next in order to provide buttons to call the javascript we include the following command controls on our page:

Note the use of the clientListener tag to invoke the javascript functions we defined above.

Near success

At this point if you run your page you should see the fonts scale up and down when you press the relevant commandLink button.

One thing you may notice is that if you have other text based command and go components on the page (eg. <af:commandLink> <goLink>), the text fails to grow or shrink on pressing your new buttons. This occurs because the command and go components are rendered in a HTML < href> tag rather than the <span> tag we coded in our javascript. An easy solution to this is to modify your components as follows:

Original

Fix

As the command control now uses a normal outputText component to render the text, this in turn is rendered as a HTML <span> tag in the end HTML page and will be subject to our javascript routines results.

One other thing you might notice, is in Firefox the font fails to shrink at all. Remember that Firefox has a user preference that stops this from occurring under Tools -> Options -> Content -> Fonts & Colours -> Advanced -> Minimum Font Size, a particularly useful feature on my laptop that runs at 1 sqwillion by 1 sqwillion resolution, where I can't see a d@mned thing.

Oracle ACE Director of the Year

Tue, 30 Jun 2009 17:50:00 EDT

I had the very pleasent surprise at the end of the ODTUG conference this year to be told that I've won Oracle Magazine's Oracle ACE Director of the Year award for 2009. With out a doubt this is an honour and I'm very appreciative to Oracle Corporation and its staff for this award, and especially to those who were kind enough to nominate me.

I was joking with Grant Ronald a few months back that I received my original ACE Director nomination when my first daughter was born, so was looking forward to becoming the grand-poo-bar when my second arrived. Apparently such flippant remarks become reality.

Thanks to everyone who has sent on their congratz via the other media channels including Twitter, LinkedIn, email and more.

I must also give a very special thanks to my "partner" in crime Jenny who gives her generous support and incredible patience in letting me pursue my Oracle activities. Mind you I've kept my side of the bargain and neither of my children yet know what an Oracle database is.

Making JDev just that little faster on WLS

Sun, 28 Jun 2009 18:03:00 EDT

During the ODTUG conference this year Lucas Jellema and myself discovered a little WebLogic Server feature (thanks to a presentation by Chris Bucchere) known as "fast-swap" that may have significant benefits in making the code-deploy-run cycle much shorter with JDeveloper. As usual Lucas is the quickest to the blog punch, and has blogged it here.

Take time to check it out.

If anybody finds any limitations beyond those mentioned in Lucas's post, in particular those relating to JDev and ADF *please*let*us*know* as it will assist the entire JDev community.

Stress & Load Testing Web Apps (Even ADF & Apex) Using Apache JMeter

Wed, 24 Jun 2009 11:00:00 EDT

A couple of years ago I presented Take a load off! Load testing your Oracle Apex or JDeveloper web applications at OOW and AUSOUG. I can't recommend enough the importance of stress testing your web applications, it's saved my bacon a number of times. Frequently as developers, we develop under a single user (developer) model where concurrency issues are easily avoided. When our programs hit production, with just 1 more user, suddenly our programs grind to a halt or fall over in bizarre places. Result, pie on developers' faces, users' faith in new technologies destroyed, and general gnashing of teeth all round. Some simple stress and load tests can head off problems way before they hit production.

(For the remainder of this post I'll infer "stress testing" and "load testing" as the same thing, though strictly speaking one tests for your application falling over, and the other how fast it responds under load)

So how to go about stress testing a web application?

There are numerous tools available to stress test web applications, paid and free. This post will look at the setup and use of Apache's JMeter, my tool of choice, mainly because it is free! ... to undertake a very simple stress test. Apache JMeter is available here, version 2.3.3 at time of writing.

On starting JMeter (<jmeter-home>/bin/jmeter.bat on Windows) you'll see the following:

Creating a Thread Group

From here what we want to do is set up a Thread Group that simulates a number of users (concurrent sessions), done by right clicking the Test Plan node -> Thread Group option. This results in:

As you can see the Thread Group allows us to set a number of threads to simulate concurrent users/sessions, loop through tests and more.

Creating HTTP Requests

From here we can create a number of HTTP requests (Test Plan node right click -> Add -> Sampler -> HTTP Requests) to simulate each HTTP request operation (Get, Post etc), HTTP headers, payloads and more. However in a standard user session between server and browser there can be a huge array of these requests and configuring these HTTP requests within JMeter would be a major pain.

Configuring the HTTP Proxy Server

However there's an easier way. Apache JMeter can work as a proxy between your browser and server and record a user's HTTP session, namely the individual HTTP requests, that can be re-played in a JMeter Thread Group later.

To set this up instead right click the Workbench node, Add -> Non-Test Elements -> HTTP Proxy Server:

To configure the HTTP Proxy Server do the following:

* Port – set to a number that wont clash with an existing HTTP server on your PC (say 8085)
* Target Controller – set to "Test Plan > Thread Group". When the proxy server records the HTTP session between your browser and server, this setting implies the HTTP requests will be recorded against the Thread Group you created earlier, so we can reuse them later
* URL Patterns to include – a regular expression based string that tells the proxy server which URLs to record, and those to ignore. To capture everything set it to .* (dot star). Be warned that during recording however, if you use your browser for anything else but accessing the server you wish to stress test, JMeter will also capture that traffic. This includes periodic refreshes by web applications such as Gmail or Google Docs that you don't even initiate; I'm pretty sure when replaying your stress test, Google would prefer you not to stress test their infrastructure for them; stick to your own for now ;-)

The end HTTP Proxy Server setting will look something like this:

You'll note the HTTP Proxy Server has a Start button. We can't use this just yet.

Configuring your Browser

In order for the JMeter HTTP Proxy Server to capture the traffic between your server and browser, you need to make some changes to your browser's configuration. I'm assuming you're using Firefox 3 in the following example, but same approximate steps are needed for Internet Explorer.

Under Firefox open the Tools -> Options menu, then Advanced icon, Network tab, Settings button which will open the Connection Settings dialog.

In the Connection Settings dialog set the following:

* Select the Manual proxy configuration radio button
* HTTP Proxy – localhost
* Port – 8085 as per the JMeter HTTP Proxy Server option we set earlier
* No Proxy for – ensure that localhost and 127.0.0.1 aren't in the exclusion list

The above setup makes an assumption that the server you want to access is accessibly without a further external proxy required.

Recording your HTTP session

Once the browser's proxy is setup, to record a session between the browser and server do the following:

1) In Apache JMeter hit the Start button on the HTTP Proxy Server page
2) In your browser enter the URL of the first page in the application you want to stress test

Thereafter as you navigate your web application, enter data and so on, JMeter will faithfully record each HTTP request between the browser in server against your Thread Group. This may not be immediately obvious, but expand the Thread Group and you'll see each HTTP request made from the browser to server:

As can be seen, even visiting 1 web page can generate a huge amount of traffic. Ensure to stop recording the HTTP session by selecting the Stop button in the JMeter HTTP Proxy Server page.

Configuring the Thread Group for replay

Once you've recorded the session in the Thread Group there are a couple of extra things we need to achieve.

For web application's that use Cookies and session IDs (JDeveloper's ADF uses a JSessionID for tracking sessions) to track each unique user session, we cannot replay the exact HTTP request sequence with the server through JMeter, as the session ID is pegged to the recorded session, not the upcoming stress test sessions.

To solve this in JMeter right click the Thread Group -> Add -> Config Element -> HTTP Cookie Manager. This will be added as the last element to the Thread Group. I usually move it to the top of the tree:

Next we need to configure the Thread Group to show us the results of the stress test. There are a number of different ways to do this, from graphing the responses, to showing the raw HTTP responses. In this post we'll take the later option.

Right click the Thread Group -> Add -> Listener -> View Results in Tree, which will add a View Results in Tree node to the end of the Thread Group:

Finally save the Thread Group by selecting it in the node tree, then File -> Save.

Running the Thread Group

To commence your first stress test run, it's best to leave the number of spawned sessions to 1, just to see the overall test will work in it's most basic form. The default Thread Group number of threads is set to 1, so there is no need to make a change to do this.

To run the test, simply select the Run menu -> Start. On running the Thread Group, you'll see the top right of JMeter has a little box that tells if it's still running, and the number of tests to go vs total number of tests:

Once the tests are complete, this indicator will grey out.

We can now visit the View Results Tree:

This shows the HTTP requests that were sent out and on selecting an individual request, you see the raw HTTP request and the actual response. You'll note the small green triangles showing a successful HTTP 200 result. If different HTTP errors occur the triangles show different colours. Also remember that sometimes application errors don't perculate up to the HTTP layer in your web application, so you should check your application's logs too (in the case of a JEE application, this will be your container's internal logs).

Running a Stress Test

The obvious step from here is to change the Thread Group number of threads to a higher number.

From here take time out to explore the other features in JMeter. It includes a wide range of features that in particular make it useful for regression testing.

Caveats

Firstly remember when doing this you're not only stress testing your application, your stress testing a server, potentially stress testing databases, stress testing your networks and so on. Therefore you can have an affect on anybody sharing those resources. "Hard core" stress tests should be on separate infrastructure, after hours, aiming for as little impact on those around you!

Also keep in mind, besides seeing your application fall over at 2 users, 10 users, 100 users, which is an important test, try to be realistic about your stress tests. Stress testing you're brand-new-application to a 1 million concurrent users is probably not being realistic. How many concurrent user requests do you really expect and what response times do you need? Normally when I ask managers this question they'll answer with, "oh we have 1000 concurrent users, the application must support that many at any one time". However what they really mean is the application has 1000 users, potentially all logged into the application (ie. sessions) at the same time, but not necessarily hitting the server with HTTP requests at any onetime.

ADF Faces RC: turning off the browser's autocomplete functionality

Thu, 11 Jun 2009 00:10:00 EDT

Modern browsers include an autocomplete function, effectively a poplist that shows the user's most recent entries for a set field in a list, for the user to choose from.

There are times when this functionality isn't desirable, such as credit card numbers, password fields and similar.

As detailed in the following Mozilla Developer Center page, both IE and FF support an autocomplete="off" attribute on form and input controls to suppress the browser's autocomplete functionality. Unfortunately this feature is not part of the HTML standards, and in turn is not a property of the equivalent tags in ADF Faces RC for JDeveloper 11g build 5188 (ER with Oracle Support pending).

There is a JavaScript solution that readers may be interested to see, and I thought this a good post because it shows the mechanism for calling JavaScript through the ADF Faces RC tags, something that I seem to be doing more and more.

The following example shows how to turn the autocomplete off at the form level:



  
  
  
  ...so on...

Points to note:

* The use of the "load" clientListener at document level to call the disableAutoComplete. This is the equivalent of the HTML body tags onLoad attribute.

* The use of the clientComponent="true" attribute in the form tag. This forces ADF Faces RC to generate a HTML form component with the same id in the resulting HTML page to be rendered. This is essential as the disableAutoComplete method requires the form id in the DOM in order to find the form via it's call to getElementById and turn off the autocomplete function.

Q&A With Grant Ronald

Tue, 09 Jun 2009 13:45:00 EDT

(This is a reprint of an article published in the UKOUG's Select magazine early this year)

When talking about Oracle Forms and JDeveloper, one Oracle personality stands out among others - long time blogger Grant Ronald from Oracle Corporation UK. Grant has for a long time “pimped” Oracle Forms and its big brother JDeveloper at Oracle events and user groups events around the world. His popularity is shown by his blog receiving on average 2000 hits per day. Lately, to reassure Oracle customers that Oracle intends to keep on supporting Oracle Forms and show that Forms has a future inline with JDeveloper, Grant has been responsible for the Oracle’s Forms Modernization message.

Chris Muir from SAGE Computing Services Australia conducted the following Q&A session with Grant to get the low down and latest on Forms and JDeveloper, as well as a little about Grant himself.

CM: What role do you currently play at Oracle and what does your day job entail?

Grant Ronald: Well, my title says “Group Product Manager” and the products I cover are Oracle Forms and Oracle JDeveloper. As a Product Manager you are responsible for the success of the products in your area. That encompasses everything from working with developers on features, the marketing department on campaigns or delivering presentations at events like Oracle World. In the morning you can be rolling your sleeves up and getting into code with a developer, and in the afternoon you can be meeting with the CTO. It’s that varied.

CM: How did you get into this Oracle gig anyhow? What’s your background at Oracle and computing in general?

Grant Ronald: Back in the early ’80s, home computing was slowly starting to take off with computers like the Sinclair Spectrum, Vic20 and BBC home computers, and it seemed like a new an innovative field to get involved in when I left school. So I got my degree in Computing Science then joined a small IT outfit in the UK that eventually got consumed by EDS. It was a pretty typical development role for about seven years, mainly focused on military applications, and my last job was designing, developing and leading the team for the development of the user interface for a military email system.

This took me up to 1996 when I fancied a change, and Oracle was looking for people with development experience on Unix and Motif in their support organization. So I joined Oracle Support where I eventually headed up the group who supported the local EMEA (Europe, Middle East, Africa) teams in Forms, Reports and Discoverer. Given that I was working closely with the Oracle Product Management team in this role, I was eventually persuaded to make the jump into Oracle Development!

CM: Ok, now for some tough questions worthy of any Q&A: You’re currently known via your blog for discussions on Oracle development including Forms and SOA, and presentations in Oracle Developer Days around the world. Previously you were also known for you work on JDeveloper. Why the change? Has Oracle internally panicked about the impression (my emphasis) customers are getting that Oracle has killed Forms, and now the need for Forms advocates?

Grant Ronald: There has not really been a change. The thing is, we’ve never stopped talking about Forms. I’ve got the air miles and passport stamps to show that we were still presenting Forms at Oracle World, ODTUG (Oracle Development Tools User Group), UKOUG (UK Oracle User Group), DOAG (German Oracle User Group) and dozens of other events covering EMEA, APAC and the Americas.

The Forms OTN page is still a hive of activity: news, events, whitepapers and how-to’s. Maybe people thought we had stopped talking about Forms because we were also talking about other technologies as well. Ten years ago if you developed on an Oracle database then you pretty much used Forms, simple as that. But the world has changed and there are other things to talk about now. Which makes sense, if you think about it; there is more need and more demand to be talking about the “new” stuff, especially when it is evolving at such a rate.

CM: On discussing Forms and considering that some Oracle customers are confused on the future of Forms, can you outline Oracle’s commitment to Forms in terms of existing versions and Oracle Support?

Grant Ronald: I think the strongest statement we have is the fact that we published a statement of direction five years ago and that statement remains true today. We’ve always said that we are committed to Forms and that there have been no plans to desupport it. That line has never changed. Regarding support, we’ve recently just extended the support date for 10.1.2 (the latest release of Oracle Forms) and Forms 11g is in development, having already had positive reviews from our beta testers. So we are lengthening the support dates, we are working on the next release and we are also discussing enhancements and features for post 11g. I think that’s all good news.

CM: Could the problem with Oracle Forms just be an image problem? It’s never been known for sexy development (a’la grey screens of boredom), and especially now that the web world, web rich clients, AJAX etc have taken off.

Grant Ronald: The sweet spot for Oracle Forms has always been the ability to rapidly develop rich, transactional business applications. So you see Oracle Forms applications in your government offices, airlines and bank back-offices etc. The need for visual “bells and whistles” is less at the fore than, for example, an online shopping application where a user makes a snap decision, often based on visual aesthetics, as to whether they will use the site.

But there is nothing to stop you pushing the boundaries of the visual aspects of Oracle Forms. We have customers who are using some of the features of Oracle Forms, like PJCs and Java beans, to really push the boundaries of the Forms UI. Like this story. So there is nothing to stop you modernizing your Forms application, starting with an update of the user interface.

CM: So what plans do Oracle have in addressing Forms customers?

Grant Ronald: We are continuing to present at all the major events and user groups. In addition, we’ve launched a focus page. This includes recorded webcasts on Forms strategy, calling web services from Forms and Forms new features. There are also white papers and customer stories as well. This is also being backed up by a roadshow which to date has hit nearly 20 countries.

For those Forms customers who are taking a step into the Java world, we have a dedicated site on OTN as well as dedicated developers guides, books and Oracle University courses.

CM: Consider an Oracle shop with a large legacy Oracle Forms application that is running well but in a desupported version of Forms. Should they have any intentions of upgrading their Forms installs and what are the risks if they don’t?

Grant Ronald: Our roadmap for Forms customers is “upgrade and integrate”. So the first point to consider is upgrade. There are, of course, benefits of upgrading but you also have to consider the risk of not upgrading: running your business applications on desupported software that is neither security nor bug patched, or being certified on newer OS or database versions. Are you managing the risk that some piece of this stack may change and destabilise your applications (e.g. a forced O/S upgrade), or are you just hoping that this software tower will hold up with no means of support. It’s your call.

Which takes us to the next point: integration. By web deploying your Forms on the application server, you are positioning yourself on a platform on which you can integrate both your legacy applications, and new services and applications.

By following the “upgrade and integrate” roadmap, you can limit the risk to your business applications while still positioning yourself for your long-term strategic goals.

CM: Consider an Oracle shop with a large amount of SQL and PL/SQL programmers who are cognisant in Forms. Which Oracle development technology should they pick for maintenance and extension of the existing system: Forms, Apex or JDeveloper/ADF?

Grant Ronald: The simplest answer is really to pick the technology/tool that suits you best. If you are extending your existing Forms application it may be that you build new business logic in the database that could be shared between Forms, Java and Apex applications. Or you might decide that you really want to exploit the power of Java and so JDeveloper and ADF would be a natural choice. Many customers are closely aligned with Oracle’s business applications and so the Oracle Fusion technology stack may drive the choice of development tool. I try to discourage customers to think in binary terms when choosing tools. The reality is that you will probably have a mix.

CM: You mention that JDeveloper and ADF would be the natural choice for an Oracle developer. Why?

Grant Ronald: As I mentioned earlier, I look after Oracle Forms and Oracle JDeveloper. One reason for this split in roles is to bring my 4GL Forms experiences into JDeveloper and Oracle ADF. When I first joined the JDeveloper team I was amazed how developers were willing to write lines of code for common actions that I set with the click of a checkbox in Forms. Part of my job is to ensure that the kind of rich features a Forms developer takes for granted are implemented in JDeveloper and Oracle ADF.

JDeveloper and Oracle ADF is also a natural choice because it’s the route our own Applications Division is taking. Our next generation Fusion applications are being built using JDeveloper and ADF. So, as the technology choice for Oracle’s own Fusion Applications, the technology is built with the Forms/Database and PL/SQL developers in mind. No other tool or framework can make this claim.

CM: What skills do you see a Forms developer needing in moving to ADF, and what approach do you suggest to a development team in minimising this learning curve?

Grant Ronald: There is a learning curve in moving to any new technology but with JDeveloper and ADF we are really smoothing out that learning curve and lowering the barrier at which you can start to become productive.

Of course, the bottom line is that you will need some Java knowledge, but how much depends on how far you want to get below the covers and customize the behaviour of the framework.

With an overview of ADF and some basic Java language skills, you can go a long way: building business services, validation, page flow, rich UI interaction, LOVs, graphs – stuff that you couldn’t even consider if you weren’t using ADF.

But if you have made a strategic choice to develop on the Java platform, I’d expect you to still have some members of your team who have a more advanced knowledge of the platform so they can make architectural decisions and set up best practices. We are also working on giving you the learning aids to get up to speed. We have developed a number of Oracle University courses specifically targeted at the Forms audience moving to Java. There are a number of books already published and more in the pipeline that are aimed at opening up the platform. And of course, we have a dedicated focus page on OTN and the essential ADF developer guides for 4GL developers.

CM: Recently you’ve been focusing on SOA technology integration with Forms. Why advantages do you see this combination providing? What challenges do Forms programmers face with integration?

Grant Ronald: The benefits of a service based approach are already well documented: loosely coupled, reusable implementations of business processes gives a more flexible, agile architecture that is better aligned to the business.

Much of the work we are doing with Oracle Forms now is to allow your existing Forms application to hook into the SOA world. The ability to call out to web services and for those services to call back asynchronously is one example.

CM: Grabbing your crystal ball, given your long-term experience in development, where do you see Oracle development in 10 years time?

Grant Ronald: I think the clearest view of the future can be seen in Oracle’s own business applications. Oracle’s Applications Division have upgraded to the most recent version of Forms, while looking to exploit the benefits of a services oriented architecture and a standards based platform. Using JDeveloper and Oracle ADF, they are taking developers from a background including Forms, PL/SQL and Peopletools, and making them productive on the Java platform.

I think this gives the clearest indication of where Oracle development is heading and I think there is a great comfort in knowing that the technology choices you are making are the ones Oracle is betting its business applications on as well.

CM: Finally, moving out of the Oracle arena, what keeps you kicking out of work? I know you play in a band.

Grant Ronald: I play a bit of keys in a band, and that mixed with a few weekends out biking helps balance out all the fun I have at Oracle!

Book Review: Processing XML Documents with JDeveloper 11g

Wed, 03 Jun 2009 07:30:00 EDT

The thing about book reviews, like movie reviews, is the interpretation by the reviewer is subjective. The trick is for you the review reader to work out does the reviewer have the same tastes and likes as you. If yes that should mean that the book review will be relevant to you potentially giving a recommendation that suits your needs. If no you might miss a really good book or waste a couple of those hard earned squid.

REA Is Where RIA Becomes the Norm

Tue, 02 Jun 2009 22:00:00 EDT

Do you believe that the day when programmers could focus on one language in their jobs is gone? Thanks to the ever-changing IT landscape and the uncertain financial times, contemporary developers are expected to work with a wide range of platforms, frameworks, languages as essentially “masters of all and specialists in none.”

OTN Article - Taking an Oracle ADF Application from Design to Reality

Thu, 28 May 2009 09:58:00 EDT

I'm happy to announce that a 5 part article Taking an Oracle ADF Application from Design to Reality authored by Penny Cookson and myself has been published on Oracle's Technology Network.

I'd like to thank Penny for her assistance in writing the article, Steve Muench and John Stegeman for their ideas (supplied directly and indirectly), Grant Ronald for his review and Justin Kestelyn's OTN team for their hard work.

Java Developer Journal - JDeveloper - an IDE that moves with the times

Wed, 27 May 2009 00:47:00 EDT

I'm happy to announce that an article of mine has recently been published in the Java Developer Journal, titled "JDeveloper - an IDE that moves with the times". You can pick up the full JDJ magazine here or the online article here.

Thanks to Teri Whitaker and Shay Shmeltzer for their assistance with this article.

JDeveloper next version - new features sneak preview

Tue, 26 May 2009 03:47:00 EDT

Jakub Pawlowski has spotted the beta documentation for the next release of JDev, great work Jakub. Best to check it out now, as the URL indicates this is a beta release and the URL may not be there for long.

As Jakub has pointed out, there's a great new calendar component arriving. I remember asking for something like this a year or so ago, and the Oracle Gods have delivered. Great work :-)

Some other things I spotted from a quick scan:

1) Dashboard component

2) Hierarchy Viewer

3) ADF BC - Integrating Service-Enabled Application Modules

4) Whole new manual Desktop Integration Developer's Guide

5) Manual for potentially a new product Oracle Help (at least I hadn't heard of it before)

...and so on... it's worth a stroll through the documentation to check out new features. I'd appreciate if you find any more, to post them as a comment on this blog post please.

I'm happy to announce...

Sun, 10 May 2009 08:49:00 EDT

I'm happy to announce the arrival of Jessica Muir, a calm and collected little 3.5 kilo girl. Mum and Jessica are doing just fine, while Dad is running a quick "education" campaign with Jessica's 2yr old sister about the merits of little sisters.

Our new arrival spells a few weeks break from blogging, normal services will resume shortly.

JAX-WS: Throwing generic SOAPFaults under WLS 10.3

Wed, 06 May 2009 08:59:00 EDT

(With apologies I accidentally deleted this post. This is a repost).

Typically thanks to the WSDL operations including a <soap:fault> element, when generating JAX-WS 2.1.x endpoints from the WSDL, the JAX-WS engine will also create @WebFault classes to mirror the <soap:fault>. As such the programmer can throw the @WebFault class to cause a SOAP fault to be returned to the caller.

However what if the WSDL operation doesn't include an explicitly defined fault for the operation? How does the programmer throw a fault without a @WebFault class? The simple answer is add it to the WSDL and regenerate, but some of us don't have that luxury, the WSDLs are given to us.

If you're using SOAP 1.1 the following code will allow you throw a generic SOAP fault from your JAX-WS endpoint:


SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://schemas.xmlsoap.org/soap/envelope/", "Client"));
throw new SOAPFaultException(sf);

Note the QName uses the SOAP 1.1 namespace and "Client" fault code.

The SOAP 1.2 equivalent code:

 
SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);

In this example the QName uses the SOAP 1.2 namespace and "Receiver" fault code.

(Later edit – for the record both these mechanisms can also be used in a custom JAX-WS protocol (SOAP handler) or logical handler).

In the SOAP 1.2 case you'll see something like the following SOAP fault returned from the web service call:

 
  
     
        
           
            S:Receiver  
           
           
            Your error message  
           
           
              
               javax.xml.ws.soap.SOAPFaultException: Your error message

Specifically for Oracle's WebLogic Server (WLS) v10.3, we need to make a slight change to the SOAP 1.2 code by supplying the specific SOAP protocol to the SOAPFactory.newInstance call:


SOAPFactory fac = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);

If you don't do this the web service will return an empty HTTP body (though the HTTP header will include a "500 internal server error"), and you'll see the following Java Stack Trace:


java.lang.RuntimeException: javax.xml.ws.soap.SOAPFaultException: Your error message

6/05/2009 10:18:23 com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl getFaultSubcodes
SEVERE: SAAJ0303: Operation getFaultSubcodes not supported by SOAP 1.1 
6/05/2009 10:18:23 com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit handle
SEVERE: Not supported in SOAP 1.1
java.lang.UnsupportedOperationException: Not supported in SOAP 1.1
 at com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl.getFaultSubcodes(Fault1_1Impl.java:220)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAP12Fault(SOAPFaultBuilder.java:404)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAPFaultMessage(SOAPFaultBuilder.java:172)
 at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:249)
 at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
 at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
 at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:134)
 at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:272)
 at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:185)
 at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:180)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at weblogic.wsee.jaxws.JAXWSServlet.service(JAXWSServlet.java:64)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
 at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at weblogic.security.service.SecurityManager.runAs(Unknown Source)
 at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
 at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
 at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

(I don't usually include the complete stack trace in a blog post, but in this case the error is so obscure, it'll help others with Google searches)

I'm currently unclear on why this occurs under WLS. Having tested the original code on Netbeans 6.5 & Glassfish 2, it doesn't have the same issue. I note WLS 10.3 uses JAX-WS 2.1.3 and Glassfish 2 uses JAX-WS 2.1.4, so it may be a simple fix in the later JAX-WS release.

Thanks very much to Gerard Davison from Oracle UK for his assistance on resolving this one.

JAX-WS: Throwing generic SOAPFaults under WLS 10.3

Tue, 05 May 2009 22:25:00 EDT

Typically thanks to the WSDL operations including a <soap:fault> element, when generating JAX-WS 2.1.x endpoints from the WSDL, the JAX-WS engine will also create @WebFault classes to mirror the <soap:fault>. As such the programmer can throw the @WebFault class to cause a SOAP fault to be returned to the caller.

However what if the WSDL operation doesn't include an explicitly defined fault for the operation? How does the programmer throw a fault without a @WebFault class? The simple answer is add it to the WSDL and regenerate, but some of us don't have that luxury, the WSDLs are given to us.

If you're using SOAP 1.1 the following code will allow you throw a generic SOAP fault from your JAX-WS endpoint:


SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://schemas.xmlsoap.org/soap/envelope/", "Client"));
throw new SOAPFaultException(sf);

Note the QName uses the SOAP 1.1 namespace and "Client" fault code.

The SOAP 1.2 equivalent code:


SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);



   
      
         
            S:Receiver
         
         
            Your error message
         
         
            
               javax.xml.ws.soap.SOAPFaultException: Your error message

Specifically for Oracle's WebLogic Server (WLS) v10.3, we need to make a slight change to the SOAP 1.2 code by supplying the specific SOAP protocol to the SOAPFactory.newInstance call:


SOAPFactory fac = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);

If you don't do this the web service will return an empty HTTP body (though the HTTP header will include a "500 internal server error"), and you'll see the following Java Stack Trace:


java.lang.RuntimeException: javax.xml.ws.soap.SOAPFaultException: Your error message

6/05/2009 10:18:23 com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl getFaultSubcodes
SEVERE: SAAJ0303: Operation getFaultSubcodes not supported by SOAP 1.1 
6/05/2009 10:18:23 com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit handle
SEVERE: Not supported in SOAP 1.1
java.lang.UnsupportedOperationException: Not supported in SOAP 1.1
 at com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl.getFaultSubcodes(Fault1_1Impl.java:220)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAP12Fault(SOAPFaultBuilder.java:404)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAPFaultMessage(SOAPFaultBuilder.java:172)
 at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:249)
 at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
 at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
 at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:134)
 at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:272)
 at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:185)
 at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:180)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at weblogic.wsee.jaxws.JAXWSServlet.service(JAXWSServlet.java:64)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
 at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at weblogic.security.service.SecurityManager.runAs(Unknown Source)
 at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
 at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
 at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

JAX-WS: A @SchemaValidation Custom Handler to Alter Framework SOAP Faults

Mon, 04 May 2009 20:56:00 EDT

A few days ago I blogged about suppressing the SOAP fault detail Java stack trace on WebLogic Server when using the JAX-WS @SchemaValidation annotation for your web services. One of the problems with the @SchemaValidation annotation is dependent on the error in your incoming SOAP payload, you may get all sorts of potential errors returned in a SOAP fault.

Standalone WLS ADF deployment – Be careful which URL you use

Mon, 27 Apr 2009 22:24:00 EDT

We hit a problem with JDeveloper 11g ADF applications deployed to WebLogic Server 10.3 that's worth sharing.

Under JDev 10.1.3 we could access our remotely deployed ADF applications on OAS through a URL similar to:

http://host:port/context-root/faces/page.jspx

...this is in fact how JDev 10.1.3 ran apps on the integrated OAS/OC4J container.

However on attempting to run a new ADF 11g application on a standalone WebLogic Server, if we used a similar URL as above, then attempted to navigate to any other page via a JSF navigation rule and command control, the original page would show, no navigation would occur, no errors in the logs would be reported.

It's very hard to debug without an error at least somewhere. This left us scratching our heads, and a SR to Oracle Support followed.

Turns out under JDev 11g you cannot include the page file extension in the URL any longer when accessing an ADF application (regardless if it's on an integrated or standalone WLS). You must use:

http://host:port/context-root/faces/page

If I'd carefully looked at how JDev 11g deploys and runs the ADF applications on the integrated WLS I would have realised this because that's what appears in the log window, but I hadn't noticed the subtle change in the URL. It's possibly something that wouldn't catch somebody new to JDev/ADF, but more likely to catch us old hands out with prior 10.1.3 knowledge. You're more likely to hit this problem on a standalone WLS as when running applications within JDev it forms the URL for you for the integrated WLS, but on the standalone WLS you need to work it out for yourself.

Note that the JDev 11g Fusion Guide under section 32.9 notes the URL syntax as:

"http://<host>:port/<context root>/faces/<page>"

....but what it doesn't bother to note is <page> should be the page name without the file extension.

Thanks to the Oracle Support staff and the Oracle JDev development team behind the scenes who discovered my error.

JAX-WS @SchemaValidation: suppressing the SOAP fault detail Java stack trace on WLS

Wed, 22 Apr 2009 23:10:00 EDT

This post gives a solution that has been given in numerous other locations and the solution is even fairly obvious, but I needed a location to record it, so here it is.

Recently Gerard Davison at Oracle UK detailed the JAX-WS @SchemaValidation tag.

The default behaviour of Oracle's WebLogic Server 10.3 on receiving a SOAP payload that doesn't conform to the WSDL/XSDs in a JAX-WS endpoint method with the @SchemaValidation annotation is to throw a SOAP fault.

Under SOAP 1.1 the SOAP fault payload returned to the client includes a faultcode, faultstring, faultactor (optional) and detail (optional) component.

Under SOAP 1.2 the SOAP fault includes a Code, Reason, Node (optional), Role (optional) and Detail (optional) component.

Assuming SOAP v1.2, given the @SchemaValidation annotation and invalid SOAP payload, we may see the following SOAP result from our JAX-WS web service:

(Click the picture to expand it)

As you can see the SOAP 1.2 fault includes the Code, Reason and Detail components. As can also been seen the Detail component includes the full Java stack trace(I've snipped the stack trace for brevity).

It may be undesirable to return the complete Java stack trace in the SOAP fault and you may wish to turn this off. If you look closely at the error message the answer in how to do this is revealed. Effectively we need to configure the WLS server to include the following option on startup:

-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false

For WLS 10.3 this entry should be included in your startWebLogic.cmd file.

For a standalone WLS this file is found under:

<WLS_HOME>/user_projects/domains/<YOUR_DOMAIN>/bin

For the integrated WLS within JDeveloper 11g it's found under:

<JDEV_HOME>\system\system11.1.1.0.31.51.88\DefaultDomain\bin

Locate the following entry in the startWebLogic.cmd file:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%

..and change it to:

set JAVA_OPTIONS=-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false %SAVE_JAVA_OPTIONS%

On restarting the WLS server, and reinvoking the web service with an invalid SOAP payload, the SOAP fault will now look like:

ADF Faces RC – displaying user help

Wed, 15 Apr 2009 00:57:00 EDT

ADF Faces RC under JDeveloper 11g supports different mechanisms for displaying runtime help to users linked with an on-screen component. I had a chance to play with this today and (once again) thought I'd document my findings here as I found the Oracle documentation somewhat confusing (or maybe it's just me).

The Oracle documentation that describes how to get this working can be found in section 16.5 Displaying Help for Components of the Oracle JDev 11g Fusion Web Developer's Guide. It's worth noting you should read the entire section 16 Displaying Tips, Messages, and Help as there are a few assumptions in section 16.5 that you've read the earlier parts.

Help types

A subset of the ADF Faces RC components include support for displaying help, through the inclusion of the helpTopicId attribute on the component's tag.

ADF Faces RC provides for 3 different help types for the components that support help:

· Definition – places a question mark icon near the component which when the user hovers the mouse over the component, help text is displayed. The exact location of the question mark icon relative to the component depends on the type of component. Section 16.5 of the Oracle documentation dictates this.

· Instructions – typically displays a note window (that looks like a speech bubble) over the component when the user clicks in the field, where the note window shows the help text. For panel headers and query object components the help text appears inline with the component rather than as a note window.

· External URL – displays a similar question mark icon to the "Definition" help type above, except when the user clicks on the icon (rather than hovers over the icon with the mouse pointer), launches a separate browser window opening an external URL.

Providing Definition or Instructions based help

The setup for providing either Definition or Instructions based help is as follows:

1. Within your ViewController project create a Java class that extends oracle.adf.view.rich.help.ResourceBundleHelpProvider. In the following example I've created the class MyHelpProvider under the package view.help

2. We next need to create the file adf-settings.xml to configure the custom ResoureBundleHelpProvider. This file is meant to go under the ADF META-INF node in the Application Resources options within the Application Navigator:

Unfortunately I can't find an easy way to create this file under this node. The easiest way seems to be to locate the <app_dir>\.adf\META-INF directory under Windows explorer or similar, and manually create the XML file in there. Once done return to JDeveloper and restart it. On JDeveloper reopening you should see the file added as per above.

(The Oracle documentation is incorrect in instructing you to create the adf-settings.xml file under the ViewController's META-INF directory. It should be the <app_dir>\.adf\META-INF directory as specified above).

The contents of the adf-settings.xml file are as follows:

Note the help-provider-class mapping that points to the package.name of our Java class, namely view.help.MyHelpProvider.

The <property>'s tags define the resource properties file that contain our help text to display for each help-enabled component. In this example I've created a file helpFile.properties (the extension is dropped in the adf-settings.xml file) in the view.resources package. We'll look at this next. The property-name as far as I can tell can be anything you want and has no effect elsewher. I'm not entirely sure why it's included; presumably it's possible to have multiple resource files?

3. The contents of helpFile.properties file are as follows:

As you can see in the properties file we have key-value pairs, specifically the help ID and the associated text. Of special note, see that each key is either completed with the word DEFINITION or INSTRUCTIONS. It is this that determines the help type for the component. (Somewhat confusingly INSTRUCTIONS is a plural, and DEFINTION is singular)

4. Finally we need to bind the help key from the properties file to the actual ADF Faces RC component on a web page:

Note for the 2 input text controls above the helpTopicId parameter. Note how these map back to what I had in the properties file minus the DEFINITION or INSTRUCTIONS suffix. Those suffixes are only included in the properties file. As such the properties file determines the behaviour of the help and components in this case.

Providing External URL based help

To configure the external URL help type we return to our custom MyHelpProvider class and override the super getExternalUrl method as follows:

In the 2nd if statement we've added the ability to capture the helpTopicId and return an alternative URL which will be used for the new browser window. As you add more components that require help, you simply add more if statements with associated URLs.

Further functionality

If you wish to configure multiple helper classes the adf-settings.xml file allows you to include a filter via the prefix attribute on the help-provider tag as follows:

In this case only helpTopicIds with the prefix MYHELP_ will be passed to the MyHelpProvider class.

In addition the Oracle documentation specifies how to use a managed bean help file, which is relatively simple, or XLIFF based help files. I don't have any experience with XLIFF files so I'll leave readers to read the Oracle documentation.

Credit

Thanks to user518058 and Frank Nimphius on the JDev OTN Forums for posting about a couple of the implementation issues with the user-help.

JNDI failure for WLS deployed ADF applications

Tue, 31 Mar 2009 04:34:00 EDT

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

Thu, 19 Mar 2009 22:11:00 EDT

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

Tue, 17 Mar 2009 06:58:00 EDT

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

Tue, 10 Mar 2009 00:07:00 EDT

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)

Thu, 05 Mar 2009 02:05:00 EST

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

Mon, 02 Mar 2009 20:35:00 EST

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.

Advert: JDeveloper 11g training course

Wed, 18 Feb 2009 01:54:00 EST

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

Tue, 17 Feb 2009 00:00:00 EST

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

Sun, 15 Feb 2009 20:36:00 EST

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

Fri, 06 Feb 2009 01:58:00 EST

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.

Configuring a JDev 11g ADF Security app on standalone WLS against MS Active Directory

Thu, 15 Jan 2009 00:05:00 EST

These notes describe my research and (finally successful) efforts to:

Build a standalone WebLogic Server (WLS) 10.3 server
Build an ADF Fusion Application using ADF Security
Deploy to a standalone WebLogic Server (WLS) 10.3 server
Configure WLS 10.3 to use MS-Active Directory (MS-AD) for user authentication

The following describes the numerous steps to get to this point, mainly for my documentation purposes, but possible useful to readers. Usual caveat: your mileage may vary.

Build a standalone WebLogic Server (WLS) 10.13 server

Follow my instructions via my previous post: Configuring WebLogic Server Domain/Machine/Server instances with the JDeveloper 11g ADF installer

That post was inspired by:Duncan Mill's A Rough Guide To Installing and Setting up WebLogic 10.3 Production for Running ADF Applications

Configuring JDeveloper's connection to the WLS server

I'll assume it's fairly easy for readers to setup a connection in JDeveloper to your standalone WLS server. Note that the WLS domain option must match the domain you created in the previous section (ie. ADFDomain), and the port number that of the AdminServer (ie. 7001).

Build an ADF Fusion Application

I wont bother to describe creating a basic ADF Fusion Application using ADF BC and ADF Faces RC. The following screenshot of the Application Navigator shows the basic project files for my sample. Note the 2 web pages: ViewClients.jspx and ViewClientNames.jspx.

Configuring your Fusion Application to run with ADF Security

A useful link for understanding this section: Frank Nimphius's ADF Security Part 2: Setup and Authentication

Via the Tools -> Configure ADF Security option invokes the ADF Security wizard. The following screen shots show the configuration for my application.

Step 1 of 6 – Enable ADF Security page

Step 2 of 6 – Select authentication type page

Step 3 of 6 – Select identify store page

Step 4 of 6 – Enable automatic policy grants page

Step 5 of 6 – Specify authenticated welcome page

Step 6 of 6 – Summary page

Mapping MS-Active Directory roles against Application Roles

A useful link for understanding this section: Andrejus's Baranovskis's Practical ADF Security Deployment on WebLogic Server

Before completing this section you need to:

1) Think about the roles of your application – say, admin, hr, sales etc
2) Thing about how these will map to your MS-Active Directory (MS-AD) roles

We'll refer to #1 as Application Roles, and #2 as Enterprise Roles.

These could have the same names with a 1 to 1 mapping, or different names, or even a 1 to many mapping.

For purposes of this post we'll assume there is a single MS-AD enterprise role Corporate Services that we want to map against our single application role AppCorporateServices.

As per Andrejus's post above we configure Enterprise Roles to Application Role mappings in our application's jazn-data.xml file. It is accessible via the jazn-data.xml file created by the ADF Security wizard, located in Application Navigator -> Application Resources -> Descriptors -> META-INF -> jazn-data.xml.

On opening the jazn-data.xml file, select the Overview tab at the bottom of the editor window, then the Manage Users and Roles button top right of the editor. This invokes the Edit JPS Identity & Policy Store dialog.

We define our Enterprise Roles under the Identify Store -> jazn.com -> Roles section as follows:

We define our Application Roles under the Application Policy Store option. You'll first need to create the store, then you define the individual Application Roles as follows:

Note that under the Member Roles tab we map the Enterprise Role against the Application Role:

Restricting access to web pages through the Application Roles

A useful link for understanding this section: Andrejus's Baranovskis's Practical ADF Security Deployment on WebLogic Server

Returning to the jazn-data.xml file's Overview tab, and selecting the Web Pages option, add the Application Role with View privileges against the ViewClientNames page:

Note that Andrejus's post goes on to tell you about configuring the weblogic.xml file. This should have been done by default via the ADF Security wizard.

Deploying the app to a standalone WebLogic Server

Assuming you've created a connection to your standalone WLS server in JDeveloper and the WLS server is up and running, select the Application Navigator -> Application Menu (top right drop down) -> Deploy -> To -> (your connection name).

During the deployment you'll see the following dialog offering you which server to deploy to, I'll assume you've setup 2 servers, so deploy to ADFServer:

Wait for a successful deployment.

Post deployment steps

Useful links in understanding this section:

Steve Muench's Simplified ADF 11g Application Credential and Policy Migration to Standalone WebLogic Servers
Andrejus's Baranovskis's Practical ADF Security Deployment on WebLogic Server

As per Steve's article, as of JDev 11g build 5188 the JDeveloper deployment tools doesn't migrate your application's security completely to WLS. As such you need to follow these further steps:

Follow Steve's steps 1, 2 and 3 on the WLS server.

Copy your application code to a directory accessible via the standalone WLS server.

Assuming you've configured the app with a database connection and jazn-data.xml entries, follow his step 3.4. Note that:

The APPWORKSPACEDIR is where you copied the application code to in the previous step
The APPNAME is configured in JDeveloper as your Application name (ie. TestStandaloneWLSSecurity)
The DEPLOYAPPNAME is configured in JDev under Application Properties -> Deployment -> Edit -> General -> Application Name, and will be the enterprise application when the application is deployed to WLS (ie. TestStandaloneWLSSecurity_application1)

On your WLS server locate the file system-jazn-data.xml. It's typically located under (WLS_HOME)\user_projects\domains\(your domain name)\config\oracle.

Follow Steve's step 3.5. For the record I usually only have an instance of JpsXmlEnterpriseRoleImpl to replace, not JpsXmlUserImpl.

Restart the WLS server

Testing before configuring for MS-Active Directory

At this stage before configuring WLS to use MS-Active Directory for authentication, it's worth checking that your deployed application is correctly deployed and configured to use security. As such we'll create a temporary role and user account to test access to our webpages.

Login to the WLS console.

Navigate to Security Realms -> myrealm -> User and Groups tab -> Groups, and create a group called Corporate Services.

Create 2 users test1 and test2. Allocate user test1 to the new Corporate Services group.

As such, because test1 has the Corporate Services enterprise role, mapped to the AppCorporateServices application role, that grants access to the ViewClientNames page, only user test1 should be able to access that page.

On attempting to access the ViewClientNames page as test2 you should get a 403 forbidden if you logged in successfully.

On attempting to access the same page as test1, it should correctly show.

On attempting to access the ViewClients page, as either authenticated user, neither have access so you should get a 403 forbidden response.

Remove the test users and test group.

Configuring MS-Active Directory on your standalone WLS

Follow my instructions via my previous post: Configuring WLS With MS Active Directory

Other useful posts to aid understanding of configuring WLS authentication providers:

Frank Nimphius's How-to configure OID for authentication in WebLogic Server
Edwin Biemond's Using OpenLDAP as security provider in WebLogic

Note as per the following OTN post it is important to reorder the authenticators such that the AD authenticator comes first in the list, and it's control flag is set = SUFFICIENT.

At this point you should have everything in place.

Post note

Thanks to all parties above, in particular Andrejus, Frank, Steve and Edwin, who either posted blog entries or forums posts as well as talking to me offline, your assistance in getting this together is appreciated.

Q&A with Grant Ronald - UKOUG Oracle Scene mag Winter 2008

Wed, 14 Jan 2009 19:06:00 EST

For those readers who are members of the UKOUG, check out in your Winter 2008 (Issue 36) edition of the UKOUG Oracle Scene mag the article "Q&A with Grant Ronald". Grant was kind enough to have a chat to me about all things Forms & JDeveloper related.

The article blurb:

When talking about Oracle Forms and JDeveloper, one Oracle personality stands out among others - long time blogger Grant Ronald from Oracle Corporation UK. Grant has for a long time "pimped" Oracle Forms and its big brother JDeveloper at Oracle events and user group events around the world. His popularity is shown by his blog receiving on average 2000 hits per day. Lately, to reassure Oracle customers that Oracle intends to keep on supporting Oracle Forms and show that Forms has a future inline with JDeveloper, Grant has been responsible for the Oracle's Forms Modernization message.

... hopefully you're a member of the UKOUG and can check this article out.

JAX-WS Provider API based endpoints in JDev 11g

Mon, 12 Jan 2009 22:45:00 EST

This post constitutes my notes on implementing JAX-WS Provider APIs for web service endpoints in JDeveloper 11g. Usual caveat: your mileage may vary. In particular I may have screwed up the terminology, so please do your own reading to back up my findings.

My understanding is JDeveloper 11g has no inherit GUI facilities that support the JAX-WS Provider API, the JDev productivity features focus on the Service Endpoint Interface (SEI) JAX-WS approach, which is probably fine for 99% of the JAX-WS implementations.

As readers know the standard JAX-WS solution inheritly uses the JAXB XML binding style. My understanding is JAXB binding is ideal in most uses of JAX-WS, particularly for small well defined XML payloads. However for an upcoming project we're not sure of the size of our incoming payloads (we may have to use XBRL) so I wanted to explore other options over JAXB. If you have a large and variable XML payload structure JAXB may be less than ideal thanks to the Java object structures JAXB creates, which at design time can be (dependent on your web service XML payload) large and complex to maintain, and at runtime possibly a large memory footprint. The JAX-WS Provider API instead allows alternative binding styles such as DOM, SAX or StAX that have different advantages and disadvantages in parsing XML documents and retrieving results, which may be more suitable depending on your defined web services XML payload structures.

The following example demonstrates creating a Provider endpoint through JAX-WS in JDeveloper 11g. The steps assume a JDeveloper 11g application "JaxWsProviderExample" based on the Generic Application template, and a single project "ProviderProject" with no project technologies initially.

1. Via the ProviderProject project properties, select Libraries and Classpath, and add the JAX-WS RI Web Services library:

2. For your web service define the XML schema with the incoming and outgoing payloads. Create the XML schema in the project subdirectory /public_html/WEB-INF/wsdl. In this example the XML schema is named sage.xsd:

The demonstrated XML schema in this example is nothing spectacular, just an incoming payload called Event demonstrating an embedded complexType BookingType, and a simple outgoing string payload named Response.

3. Create a WSDL for the web service and place it in the same /public_html/WEB-INF/wsdl subdirectory.

Refer to this previous blog entry for creating a WSDL step by step with JDeveloper 11g's GUI WSDL builder. In addition check out the following viewlet from Oracle that not only shows you creating the WSDL via the JDev 11g builder, but uses drag n drop, and generates a JAX-WS SEI implementation with little hassle.

In this example the WSDL is named sageWsdl.wsdl:

Note from this WSDL example we're using SOAP v1.2. Please, no laughing at my sophisticated service/port/porttype/message names! ;-)

4. Create our Java implementation of the Provider API. In the following example I've created a class au.com.sagecomputing.ProviderImpl:

Note:

The getXMLFromSource method is not pivotal to this example (credit to Rahul Biswas for the source)
The @WebServiceProvider annotation maps back to port/service/namespace names in WSDL.
The @BindingType annotation is only necessary as we're using SOAP v1.2. If you forget this line and you've specified SOAP v1.2 in your WSDL you'll receive a runtime exception about the wrong content-type header as follows (solution documented here):

SEVERE: Unsupported Content-Type: application/soap+xml; charset=UTF-8 Supported ones are: [text/xml]
com.sun.xml.ws.server.UnsupportedMediaException: Unsupported Content-Type: application/soap+xml; charset=UTF-8 Supported ones are: [text/xml]

Regardless of the number of operations defined in the WSDL, all will be passed to the chokepoint invoke method. This means you need to interpret the incoming request using whichever binding style you've chosen (in this example javax.xml.transform.Source) and determine which operation the XML payload represents.

5. You'll note on creating the above class the @WebServiceProvider line will have a lightbulb code-insight hint in the JDeveloper Java editor. Select the lightbulb and then select the single option to configure the web.xml file for your project. This will result in a web.xml file as follows:

6. The JAX-WS RI implementation requires the file sun-jaxws.xml in your /public_html directory. Create this file; example content based on the implementation shown in this post is as follows:

A handy reference for the sun-jaxws.xml file can be found here.

By careful to ensure the port name and url-pattern attributes match those specified in your WSDL and web.xml files respectively.

7. At the end of the above 6 steps you're application should look as follows:

8. Running the ProviderImpl via the JDeveloper web service tester tool (right click the ProviderImpl.java, select Test Web Service) shows the following results:

(Yes Gerard, I'm back to using HTTP Analyzer, not SoapUI! ;-)