Wednesday, 31 January 2007

Where's the cheese? ah, Javadoc?

Ever had this scenario?

You're hellishly coding in JDeveloper, 1001 lines of code in just 2 hours, writing some fancy-pancy JSF backing bean that will solve world poverty, and you need to see the Javadoc for one of the underlying JSF core spec API classes. You highlight the class, press F1, JDeveloper then tells you it's searching a http address, and then, um....., ah....., er...... fails to load the Javadoc, or worse hangs..... for some time....., ah......, ah.....ARGH!.... then finally times-out and returns to your code page after a minute or so.

Poof! So much for programmer productivity and being in the programmer "ZONE".

This is a particular problem for me in JDeveloper when my wireless link slows right down, Sun has blocked my IP for spamming again, I'm on the end of a dial-up line (yes, we still have telephones in Australia) or I've taken my laptop to where (iGod forbids) there isn't actually an internet connection (@ my folks' place who are internet heathens and still use the bush telegraph to talk to their friends).

Q) Ignoring why I would undertake such an insane, harming and self isolating action, why does JDeveloper behave in this manner?

A) Because for the respective JSF API, JDeveloper's distribution doesn't point at a local copy of the API Javadoc, but instead references the online doco at Sun's own website via a URL. If JDeveloper can't connect to the internet, it just doesn't show the doco. If the connection is slow, the IDE interface hangs waiting on a timeout or the page finally downloading.

The obvious fix to this problem is to have copy of the JSF API doco locally and JDeveloper will use it rather than the external source.

To do this you can download the Sun JSF 1.1.01 Reference Implementation from here that JDev 10.1.3.1 requires, and unzip to your favourite directory on your local PC.

Next in JDeveloper, select Tools->Manage Libraries->Libraries tab. If you look down the list of extensions, you'll find one called "JSF".


On selecting the JSF option you can see the Doc Path for this particular library is a Sun URL. Unfortunately none of the buttons are enabled to allow you to change this.

The easiest way to fix this, is to create your own library. Return to the User node at the top of the Libraries tab, then select the New button. This displays the Create Library dialog:


You can then create a new managed library that contains the JSF doco. Give the library whatever name you like, and then under the Doc Path tab, select Add Entry button, and specify the root of the API documentation you unzipped (in this case [install-dir]\jsf-1_1_01\javadocs).

Once you've created the new library you then need to include it in your project. You do this by selecting the project you want the library to be added to. For the JSF program example it would be the ViewController project.

To do this you first select the right-mouse button to show the context menu, select Project Properties, then the Libraries node. The Project Properties dialog under the Libraries node shows you all the Managed Libraries used by this project. To add your library, select the Add Library button, select your new library, and you're right to go.


Now when you press F1 on a core JSF class, the Javadoc will display immediately without hitting the internet for the actual documents. As you can probably guess, there are a number of Managed Libraries in JDeveloper that you can make use of local copies of the API Javadoc instead to keep you in the programmer "ZONE".

Sunday, 28 January 2007

Making JDeveloper faster ... another tip

Recently Shay Shmeltzer blogged how to make JDeveloper faster. I attempted to add a comment on my experience to his blog but received a 403 Forbidden message, so instead I'll post my comment here.

I find at sites with aggressive network virus scanners, the speed of JDeveloper on Windows is hindered by the virus scanner inspecting all the JAR files and other files on your local machine during normal JDeveloper r/w to the filesystem. As you can appreciate a JAR file is a zipped file, so the virus scanner has to unzip the JAR to scan for viruses, which is a double speed whammy (technical term for sloooooow).

From experience a version of McAfee disk-hog was 1 culprit, but luckily you can turn the scanner off for certain types of files (eg. JARs) or subdirectories (eg. the JDev install directory or your project directory).

If the local network monkeys have tied down the virus scanner settings via a magical network configuration, you many need to convince them to turn these settings off for your machine. My advice, just make some reason up that includes your boss's name, the CIO's name, and global warming. I find most network admins think all developers are a threat to network security and you'll need to lie through your teeth to get the exemption.

Don't forget your OAS server too, not just your local machine.

Besides who needs a virus scanner these days? Viruses are so 1990s. These days its all about net-bots, phishing and viagra pyramid schemes ;)

Bah! What is JBO-35007?

Within a running JDeveloper ADF Faces application, the error "JBO-35007 row currency has changed" is one that throws new developers off guard. It's easy to leap to the conclusion it's an ADF bug. A search of the OTN forums doesn't provide much help, and the JDev doco is just a tad forgetful on this topic in explaining it in laymens terms (you know, for stupid people like me ;).

Basically, and I do mean basically, the JBO-35007 error is not a bug in ADF, but rather a powerful feature for capturing the inappropriate usage of the browser back button by the user.

To understand the back browser problem in the web world, Duncan Mills and Peter Koletzke's recent Oracle JDeveloper 10g for Forms and PL/SQL Developers text (I recommend this book for beginner JDev ADF Faces programmers) sums this issue up well:

"Users may be accustomed to clicking the browser's Back button to return to the preceding page or the Refresh button to reload the page. This can cause problems with web applications that use a Controller layer, like the JSF controller or Struts, because the browser Back button returns to the preceding page in the browser's page history without calling code in the Controller layer. The controller will therefore, not know the state of the application's data and the preceding page will either not load properly or may place the application into an inconsistent or unstable state. The same problem occurs with the browser's Refresh button, which just reloads the same page, again without calling Controller layer code. This is a problem in all web applications, not only those using J2EE technology or ADF libraries."

I like this simple summary, because a more complex discussion involves stateful web applications, web controllers and conspiracies about J.F. Kennedy. In other words, too much detail to go into in a blog, and besides I've a baby girl to look after.

Anyhow, I mentioned that in ADF the JBO-35007 error is in fact a powerful feature for capturing the inappropriate usage of the browser back button by the user. (How powerful? Well, go code it yourself and find out how difficult it would be to implement)

There is mention of this feature in the following JDev doco page.

It's really quiet easy to replicate this feature (and error) in action, and useful to do so to learn when this feature shows its warty little head.

1. First create a JSF web page with an ADF Faces table bound to your favourite VO. Include the table selection control, as well as a submit button.


2. Create a 2nd web page as an input form based on the same table.

3. In your faces-config.xml file create a navigation rule from page 1 to page 2.

4. In the first web page change the submit command button action attribute to the new navigation rule

5. Run your app from the table page.

6. Select any record, then the submit button which will navigate to the 2nd page.

7. On the 2nd page, press the browser back button.

8. The browser has returned to a local cached copy of the 1st page. Select any other record, and press the submit button again.

9. JBO-35007 will be raised.

To get around this issue, on the 2nd page we should provide a command button to navigate back to page 1, and discourage the user from using the browser back button.

And as can be seen from the JDev doco note, the row currency token mechanism can be turned off per page through the pageDef for your page, setting the EnableTokenValidation to false. (Be warned you should not flippantly turn this off for pages, or blanket turn it off for all pages, as the mechanism is an important one)

Hopefully in the future Oracle JDev team will provide an advanced feature to allow the user to leap back to the page they back-buttoned away from, or alternative a clearer error message (which you can override anyway). Or possibly future browsers will support a back button Javascript event that will allow a forced page submit to occur.

Wednesday, 24 January 2007

E-Business Suite Q&A with Steven Chan

In an ongoing series of articles, Chris Muir chats to Oracle blogger Steven Chan, Director of the Oracle Applications Technology Group. Steven's blog is one of the few Oracle Applications blogs and a strong source of the technology directions for Oracle's E-Business Suite. Beyond his blog Steven is responsible for integrating components such as Oracle Application Server into the Oracle E-Business Suite Release 11i technology stack. In addition to working with new technology integrations, Steven manages technology adoption programs with selected E-Business Suite customers.

Q) What is your principal role at Oracle?

A) My primary responsibility managing Early Adopter Programs for selected Oracle E-Business Suite technology stack components and advanced configurations. These programs allow selected customers to work with certain configurations or software before they’re released to the general customer community.

For example, I recently ran an Early Adopter Program for integrating Oracle Application Server 10g with the Oracle E-Business Suite. This was a massive 20-month program involving over 260 registered customers worldwide, five interim releases, and Oracle Support and Consulting staff in all geographic regions.

Q) Can you describe your average working day?

A) I’m part of various virtual development teams assembled to build, test and deploy different configurations internally, write or review documentation and training materials, and handle issues reported by anyone who uses it.

Practically speaking, this means that my day consists of bouncing between multiple projects, handling bugs, escalating issues, and generally making a nuisance out of myself. It’s the perfect job for someone with a short attention span. I’m also spending a lot of time, both on the clock and after hours, on my new Oracle E-Business Suite Technology Stack blog.

Q) Your blog is one of the few Oracle Applications blogs. Why did you start blogging about Oracle Applications?

A) A major part of my job is communicating with customers, partners, and Oracle staff on a broad variety of Oracle E-Business Suite technology stack topics such as security, deployment architectures, and our current and future certifications. I do a lot of customer presentations and webcasts, and I also participate in conferences like Oracle OpenWorld and OAUG Collaborate when possible.

This results in a lot of email -- up to 600 emails on a bad day. In self-defence, I started writing a Frequently Asked Questions document about Release 11i technology stack topics (Metalink Note 186981.1). To my surprise, my incoming email volumes turned out to be inversely proportional to the investment in these FAQs: the more time I spent writing about on a particularly topic, the less email I had to answer.

The problem with FAQs, though, is that they’re a one-way medium. Despite our best efforts, I was left with this sense that there’s a lot more that we can do to communicate what’s technically feasible, what’s coming soon, and to learn how customers use our products.

When Oracle endorsed blogging, it was inevitable that I’d try it to see if we could use it to broadcast technical news and tips… and help me reduce my email volumes further. It seems to be working so far, and I’ve been gratified by the huge upswell in traffic and positive response from readers.

Q) How has the blog changed from your original expectations?

A) I originally thought that I’d use it primarily to discuss advanced and special features of the Oracle E-Business Suite’s technology stack components. Reader feedback quickly revealed that there’s a huge, unfulfilled demand for much more basic information.

Also, I’d planned on occasionally publishing interesting tidbits on future versions such as Release 12. I’ve been surprised at the popularity of this topic. As of now, the screenshots of our new Release 12 user interface are far-and-above the most popular topics on the blog.

As one of the first Apps bloggers, I’d expected that this might be a lonely road. The sudden rush of popularity has prompted interest from my colleagues, so I’ve been lucky to convince a growing group of guest editors to contribute some excellent articles. Even at this early stage, we now have some fascinating pieces written by heavy hitters in Support and our own Technology Integration group, and I’m optimistic that I’ll pick up more editors along the way.

Q) How did you first get involved in Oracle Applications?

A) Through the back door during the dotcom boom; I’m not sure I’d get an interview today with the skills I had back then. I originally joined Oracle’s Consumer Packaged Goods group in 1998. When Oracle’s directions changed for that product, I was reorganised into the core group responsible for Release 11i’s Business Intelligence core infrastructure. Following that, I joined the Applications Technology Group, the core department responsible for the Oracle E-Business Suite technology stack, where I’ve been happily ensconced since. I consider this my dream job.

Q) Within the labour market there does appear to be a clear divide between Oracle professionals savvy with Oracle Applications, those who have little experience, and those who prefer to keep it at arms reach. Any comment from your own experience?

A) That seems accurate. The learning curve to become an Apps system administrator can be steep. Not only do you need to have Oracle DBA skills, you also need to understand the Oracle E-Business Suite, too. The amount of material can be sprawling and intimidating to a newcomer.

I’m very pleased to see that we’re now offering a new Oracle certification for Oracle E-Business Suite 11i Applications Technology Certified Professional Administrators. I think this will go a long way to making this area more accessible. In the meantime, Apps DBAs can enjoy a deserved premium for their hard-won skills in the marketplace.

Q) You've previously had responsibility for running Early Adopter Programs (EAP) in Oracle, specifically the integration of E-Business Suite (EBS) v11 with Oracle Application Server (OAS) 10g. How does an Early Adopter Program vary for E-Business than from other Oracle products?

A) There are some procedural differences in how we distribute and support Early Adopter Program software but our goals are the same, overall: to validate the field readiness of certified configurations with a range of selected customer environments. Specifically, we look carefully at Early Adopter Program participant feedback on our documentation, the ease of installation and configuration, and how well the software meets their needs.

Q) How do customers participate in these programs, and what level of support would an Early Adopter Program E-Business Suite customer expect?

A) Up until now, customers with specific requirements had to hunt down our Early Adopter Programs via Oracle Support or other indirect Oracle channels.

For example, we’re currently running an Early Adopter Program for replacing JInitiator with the native Sun Java plug-in on Windows desktops. Customers having problems with JInitiator are often informed by Oracle Support that an alternative solution is to register for this Early Adopter Program.

That Early Adopter Program is now profiled on our Oracle E-Business Suite Technology Stack blog. I hope to make it easier for Oracle E-Business Suite customers to find this kind of information centrally with this new option.

From a support perspective, Early Adopter Program customers can generally use these configurations in production environments, but this varies on a product-by-product basis.

Q) E-Business Suite v12, a major version with a range of modules, must take a huge amount of development effort from requirements gathering through to the shrink wrapping. Could you describe the effort required by the Oracle E-Business Suite team to bring all of this together?

A) A major release like this takes a coordinated effort across all Oracle divisions, including Development, Support, Consulting, Education, Marketing, and even our internal Applications IT group, which runs Oracle’s own Global Single Instance. They’re often the first users of our new releases.

In terms of scale, these releases involve a myriad of staff, including developers, product managers, QA engineers, documentation writers, support engineers, and our tireless infrastructure teams who update the various development and demonstration environments with every new code drop.

Q) Within E-Business Suite v12 what do you think will be the E-Business Suite killer feature?

A) I’m not really qualified to comment on the functional aspects so I’ll restrict my comments to the technology side. I think that the inclusion of the Oracle 10gR2 Database and Oracle Application Server 10g in Release 12’s technology stack are major steps forward. On top of that, R12 will feature our new Project Swan user interface, the latest Oracle XML Publisher release, and optional integration capabilities with externally-installed Oracle Fusion Middleware products like Oracle Identity Management, Oracle BPEL Process Manager and Oracle Business Activity Monitoring. This adds up to a pretty exciting release from a technology perspective.

Q) The E-Business Suite is a prime user of the Oracle RDBMS and OAS. The perception is E-Business Suite lags in utilising the latest RDBS and OAS features. Any comment?

A) Some new database releases have historically taken a little longer than we’d like to certify with the Oracle E-Business Suite. This is partly due to our desire to deploy these releases in production at Oracle prior to making them generally available. There are certain windows where upgrading Oracle’s own Global Single Instance is avoided – for example, around quarterly or annual earnings periods.

That said, we’re making progress at reducing the lag between the release of a new database version and its subsequent certification with the Oracle E-Business Suite, and we’re continually looking at ways to tighten the process further.

Likewise, we’re working on improving the Application Server release process, particularly in the area of including Oracle E-Business Suite integration tests as part of the exit criteria for the QA phases. We’ve been doing this for years for products like Oracle Discoverer, and we’re now broadening this out to other components in the Oracle Application Server product family.

Q) As one of the largest Oracle RDBMS and OAS users, the E-Business Suite development team must request significant features in the upcoming Oracle core products. What's your experience of how this relationship works between the different product teams and the outcome for the E-Business Suite?

Oracle is committed to success in the ERP industry, and we’re seeing an unprecedented focus on supporting Applications through advances in Middleware and Database technologies.

Q) Oracle has recently made a series of acquisitions in the Identity Management space. E-Business Suite v11 and OAS 10g integration allows v11 users to authenticate against the OID and presumably future releases will see more user information held in OID rather than v11. What will be the impact of the new security packages in future release of E-Business Suite?

A) The biggest impact lies in the change in our overall attitude towards integration and coexistence with third-party products. Previously, we considered the Oracle E-Business Suite to be a stand-alone product with its own user management system.

Today, our designs explicitly consider customer requirements for third-party integration, all brokered through the abstraction and integration capabilities of Oracle Identity Management components packaged as part of Oracle Fusion Middleware and Oracle Application Server. We no longer view the Oracle E-Business Suite as an isolated application, but rather as one part of your overall IT environment. This represents an enormous sea change in attitudes.

Q) Veteran applications developers know that customisation to E-Business Suite and other ERP solutions to suit customer business processes results in an upgrade headache as new versions of the software are released. Some developers now recommend when buying such software solutions, the business should change to match the vendor's package, not the other way around, a case of standards versus flexibility. Can you comment on how E-Business Suite is addressing this issue? Do you have any recommendations from your own experience on how customers should tackle this?

A) This is a classic conundrum, one that I’d be hard-pressed to address effectively within the limited scope of this interview. We draw a distinction between configuration, personalization, and extensibility. Configuration options allow you to define things like flexfields, personalisation options allow you to change the user interface look-and-feel and screen layouts declaratively, and our extensibility options allow you to add new functional flows or override existing business logic.

If you follow our published standards for these three areas, upgrades are generally less painful. But as with all generalisations of this type, your mileage may vary.

If your readers are looking for more information about this rich area, I’d recommend reading this.

Q) What area do you believe provides the biggest frustration to E-Business Suite users and how are Oracle addressing this?

From a technology stack perspective, I think we have two major challenges. Our biggest challenge is reducing the complexity and cost of managing the entire implementation, management, maintenance, and upgrade cycle. We’ve made significant progress in building out the Oracle Enterprise Manager and Oracle Applications Manager capabilities for Release 11i, and I think you’ll be pleased with new features coming in Release 12.

Our second major challenge is keeping up with the ever-evolving set of architectural requirements that you’re faced with when implementing the Oracle E-Business Suite in the field. For example, only a handful of customers were concerned about SSL, DMZs, and Single Sign-On back when their Oracle E-Business Suite users were restricted to employees behind corporate firewall. Today, nearly all customers want to expose some aspect of the Oracle E-Business Suite externally, which triggers these requirements and others for things like reverse proxy servers, load-balancers, and federated security.

It’s a challenge to learn about your new requirements, which is why we encourage you to send us your feedback through the official OAUG channels.

Q) With the new exposure to the other ERP solutions acquired by Oracle, has this allowed the E-Business Suite team to investigate new ideas in the other products and introduce them to E-Business Suite? Any particular features you see as a priority?

A) If it were possible to graph the number of new concepts and approaches we’re working with, it would look like a step function with every new acquisition. The design process for Oracle Fusion Applications is underway now and everyone’s bringing together the best ideas from all of our acquired ERP solutions. It’s hard to single any one thing out as a priority, but the buzz of excitement around the new directions for Oracle Fusion is electrifying.

Q) There has been a large amount of hysteria about the Oracle Fusion marketing label and its impact on existing customer bases in the PeopleSoft, JD Edwards, Siebel and Oracle E-Business Suite arenas. What comments would you like to make from an E-Business Suite perspective?

A) We’ve tried to allay the fears of our customers by reassuring them that they’re not being placed on a forced march to upgrade to any release before they’re ready for it. We know you’ve invested heavily in your current implementations, so we’re giving you the responsibility for setting the pace of your deployment or migration schedule.

This is the goal of our Applications Unlimited program here. If anyone is even remotely concerned about being forced to upgrade or switch, they should contact their local Oracle account team for a discussion about how Applications Unlimited protects their investments.

Q) The United States Sarbanes-Oxley (SOX) Act was created to ensure business has certain controls in place to limit and detect fraud. Its influence has been felt world wide including Australian businesses wanting to trade with the USA. How can E-Business Suite assist in helping customers meet the challenges of SOX?

A) Indeed, the ripples of this legislation have been felt worldwide. The Oracle E-Business Suite has a large number of products and features that can be used to build a compliance system. There’s an extensive body of literature covering this here.

Q) SOA and BPEL are making major inroads into the ERP space. What future support will there be for BPEL, in particular Oracle's BPEL Process Manager in the E-Business Suite?

A) Release 11i can be used today with Oracle BPEL Process Manager and Oracle Business Activity Monitoring to support service oriented architecture designs. In addition, we offer a hosted Integration Repository here.

You’ll continue to be able to use Oracle Fusion Middleware, Oracle BPEL Process Manager and Oracle Business Activity Monitoring with Release 12, and we’re planning to deliver the Integration Repository as part of the R12 Rapid Install. You should look out new web services and other integration capabilities coming in Release 12.

Q) With E-Business Suite v12 behind you, what features do you see in the next release? Any comments to users on how they can help influence this functionality?

A) There are a myriad ways of getting in touch with us, so you might be surprised at how little feedback we actually receive. We have over 30,000 Applications customers today, but strangely, we only hear from a relatively small fraction of you. Make yourself heard! Work with your local OAUG chapter on documenting your requirements and use-cases. If you can, come to Oracle OpenWorld and speak with us directly. Make your Oracle account team earn their licence revenues by reviewing your enhancement requests with them. Drop by our new blogs and post some comments. Although there are few certainties in life, it’s almost guaranteed that we won’t be able to respond to your concerns unless you tell us about them… so speak up!

(This article is a reprint of the article I published in the quarterly AUSOUG magazine Autumn 06 edition. I'd like to extend my thanks to Steven Chan for agreeing to the interview, and Stuart Smith and Craig Metters at Santos for their kind assistance and input on this Q&A article)

Friday, 19 January 2007

Using multiple faces-config.xml files in JSF

A client of mine is interested in the segmentation of an ADF Faces application. One file we were particularly interested in segmenting is the faces-config.xml file. Given that the faces-config.xml file includes all entries for managed beans, navigation and other elements it can quickly become huge and cumbersome in a medium to large application.

Given a bit of spare time I decided to research is it possible to split the faces-config.xml file into logical groups?

This post shares my experience in researching this issue. The value in this post is 2 fold; firstly from the issue it attempts to solve, but also second, the different avenues of research available when looking at JSF.

In a new standard JDeveloper ADF BC/JSF application workspace, the faces-config.xml file is placed under the ViewController project WEB-INF directory. At a guess I would say the FacesServlet is hardcoded to search and use the faces-config.xml file from the WEB-INF directory.

Such a guess requires a little research. A look at the Sun's JavaServer Faces Specification v1.1 (found here - select the Maintenance Release 1.1 link and follow the prompts) section "10.3.2 Application Startup Behavior" says that a JSF application on startup will undertake the following operations in order:
  • Search for all resources named "META-INF/faces-config.xml" in the ServletContext resource paths for this web application, and load each as a JSF configuration resource (in reverse order of the order in which they are returned by getResources()).

  • Check for the existence of a context initialization parameter named javax.faces.CONFIG_FILES. If it exists, treat it as a comma-delimited list of context relative resource paths (starting with a “/”), and load each of the specfied [sic] resources.

  • Check for the existence of a web application configuration resource named "/WEB-INF/faces-config.xml", and load it if the resource exists.

If you read through these 3 options, it appears that the 3rd option is the default in our new JDeveloper JSF application. So do the two other options provide us a means to segment our faces-config.xml file?

Option 1 and option 2 don't read particularly well. Maybe to somebody with more J2EE web experience or an interest in reading specifications this isn't double Dutch. As such it's time to find a more readable resource to assist us. The point to be made above though is that the JSF specification can be a useful place for finding out more about the workings of JSF in general.

Currently to my knowledge there are 4 texts that cover the JSF framework:

These books are a tad out of date but give a reasonable base to start with. Of the four books none of them are the golden JSF chalice, but collectively they help nut out JSF concepts and issues.

(Note there are other recent texts available on JSF component building that are less relevant to the discussion at hand, useful for understanding the component architecture and creating new components, but less about the plumbing's of JSF)

Mastering JavaServer Faces in chapter 4 under Configuring a Web Application for JSF - JSF Application Configuration files gives a better understanding of the 3 faces-config.xml options explained above.

For option 1 it states that all JSF implementations will "Look for a resource named /META-INF/faces-config.xml in every JAR resource that is located in the /WEB-INF/lib directory of the Web application. If such a resource exists, the configuration file is loaded at application startup."

This makes sense over the JSF specification, allowing additional JAR files to include their own faces-config.xml file. Great to know but not useful in our case as we want multiple files in our single application.

For option 2 Mastering JavaServer Faces says a JSF implementation will next "look for a context initialization parameter named javax.faces.application.CONFIG_FILES in the web.xml file for one or more JSF configurations that should be loaded. The value of this parameter is a comma delimited list of context relative resource paths (each starting with /). This particular method is useful when you wish to split up a large JSF application into manageable pieces."

Bingo! Exactly what we're looking for. The text then goes onto suggest on how to do this in your web.xml file with the following example:

<context-param>
    <param-name>javax.faces.application.CONFIG_FILES</param-name>
        <param-value>
            /WEB-INF/faces-config1.xml,
            /WEB-INF/faces-config2.xml
    </param-value>
</context-param>


Finally the text suggests that option 3 is ignored if option 2 is specified.

This raises some interesting questions and is worthy of a number of tests in JDeveloper which we'll do next

Does JDeveloper support multiple faces-config.xml files?

In answer to the first it becomes fairly obvious that JDeveloper does support multiple faces-config.xml files, as invoking the New Gallery under an existing JSF ViewController project, selecting the Web-Tier -> JSF -> JSF Page Flow & Configuration (faces-config.xml) option pops up the Create JSF Configuration Flow dialog. This dialog allows you to specify the new faces-config.xml file name, the directory name to place it under, and to include an entry in the web.xml file.


Accepting the defaults creates a new file faces-config.xml and an entry in the web.xml file as detailed in the Mastering JavaServer Faces text:

<context-param>
    <param-name>javax.faces.CONFIG_FILES</param-name>
    <param-value>/WEB-INF/faces-config1.xml</param-value>
</context-param>


You'll note the param-name is different from the Mastering JavaServer Faces entry. We'll assume the JDeveloper entry is correct.

Further to this JDeveloper has out of the box support for multiple faces-config.xml files. One way to open the faces-config.xml file for a JSF ViewController project is to right-click the ViewController project and select the Open JSF Navigation menu option. With multiple faces-config.xml file, this option becomes a submenu with all faces-config.xml files listed allowing you to select the particular file you wish to edit:


JDeveloper then supports the standard Diagram, Overview, Source and History views on each file. Behind the scenes for the Diagram, JDeveloper maintains a diagram file matching the name of the faces-config.xml file with an extension of oxd_faces (eg. faces-config1.oxd_faces). The oxd_faces file stores the visual diagram elements that JDeveloper allows the developer to maintain on top of the faces-config.xml file. I'm guessing that outside of JDeveloper this file is superfluous but when modelling page navigation visually in JDeveloper it is required.

Does option 2 actually override option 3?

Let's now investigate if option 2 overrides option 3, or more specifically, if we include multiple faces-config.xml files as specified in the web.xml file, do they override the original single faces-config.xml file within the WEB-INF directory?

The easiest manner to test this is to create a simple JSF web page that reference a JSF managed bean property. The simple JSF web page contains the following form:

<h:form>
    <h:inputText value="#{myBean.value}"/>
</h:form>


The bean looks like this:

public class MyBean {

    String value = "MyBean";

    public MyBean() {
        System.out.println("MyBean instantiated");
    }

    public void setValue(String value) { this.value = value; }

    public String getValue() { return value; }
}


And the entry to manage the bean within the option 3 stand alone faces-config.xml file like this:

<managed-bean>
    <managed-bean-name>myBean</managed-bean-name>
    <managed-bean-class>MyBean</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
</managed-bean>


On running the application we discover the assumption is incorrect. The <h:inputText> tag's value should be empty if the stand alone faces-config.xml file is not referenced. Instead we see it has the default value "MyBean" extracted from the bean, as well as the message "MyBean instantiated" is printed to the console.

Hmmm, could it be option 2's 2nd faces-config file, namely faces-config1.xml is ignored? Let's extend our example. The web page now contains:

<h:form>
    <h:inputText value="#{myBean.value}"/>
    <h:inputText value="#{myBean2.value}"/>
</h:form>


A new managed bean looks like this:

public class MyBean2 {

    String value = "MyBean2";

    public MyBean2() {
        System.out.println("MyBean2 instantiated");
    }

    public void setValue(String value) { this.value = value; }

     public String getValue() { return value; }
}


... and in the 2nd faces-config1.xml file we include the following managed bean entry:

<managed-bean>
    <managed-bean-name>myBean2</managed-bean-name>
    <managed-bean-class>MyBean2</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
</managed-bean>


A quick test shows that now both <h:inputText> tags have a value at runtime. This proves all faces-config.xml files are referenced regardless. Useful to know and test.

Which order are multiple faces-config.xml files read in?

Given that we have multiple faces-config.xml files, we need to check what order the files are read in. Consider the following scenario:


We have 2 faces-config.xml files, the default faces-config.xml that says page1 shall navigate to page2 on the navigation rule "success". In turn the 2nd file, faces-config1.xml says that page1 shall navigate to page3 on the navigation rule "success".

So which is it? A quick test reveals at runtime that page1 navigates to page2, thus the original faces-config.xml file is read first.

Are there any issues reported for multiple faces-config.xml files in JDeveloper?

Before I recommend a feature I like to do a search on Oracle's OTN JDeveloper forum to see if there are any issues. The issues can be a little hard to find yourself because they can require a production system with multiple users to replicate. Sharing in other users' experiences can assist the issues that may be encountered.

Some issues I found:



Summary on multiple faces-config.xml files

By default JDeveloper creates a faces-config.xml file in the WEB-INF directory of the ViewController project.

Additional faces-config.xml files can be created for a project via the Create JSF Configuration Flow dialog under the New Gallery -> Web-Tier -> JSF options.

Additional faces-config.xml files are specified within the web.xml file.

If present, the WEB-INF faces-config.xml file is read first at runtime, followed by additional faces-config.xml files specified in the web.xml file.

Additional faces-config.xml files allow the logical composition of entries into separate files. For example all navigation rules could be put in one file, managed beans in another, or alternatively all elements for a sub-system such as HR in one faces-config.xml file, the elements for another sub-system such as payroll in another faces-config.xml file.

Recommendations on JSF research

Once you're comfortable with building simple JSF application, expand your reading to include looking at the JSF specification, and review each time a new specification becomes available. Also grab a text on the JSF framework, read from back to front, and then review as your understanding increases.

You'll be surprised how much you pick up on a second or third read of a text. For the JDeveloper developers among us, Oracle's Steve Muench's articles are a key example. Start developing with JDeveloper ADF Business Components and try to understand Steve's scalability papers and you'll be left scratching your head. Give it another 6 months development and a revisit to the article and the penny will drop in most cases.

Frequent the forums and blogs beyond just Oracle's. ADF Faces and JDeveloper are just one set of tools that implement JSF. There are plenty of other forums out there who cover the same topics.

Test test test. Don't trust the documentation and don't trust this post. Don't base design decisions on documentation unless you've tested the theory.

As usual after this research, I discovered beyond the JSF specification and the books listed above, that's JDeveloper's documentation has a good section on this entitled "What you may need to know about multiple JSF configuration files" found here.

I don't know why but I always seem to refer to the JDeveloper documentation last, and am pleasantly surprised to find a section on my research topic.


Finally ..... I'm sure others will have had interesting experiences with multiple faces-config.xml files so it would be great if you could share the issues you've discovered, if not here, maybe on the JDeveloper OTN forum.

Thursday, 18 January 2007

AUSOUG/OAUG 2007 Australian conference update

I might as well take the opportunity to advertise the AUSOUG/OAUG 2007 Australian conference while I'm receiving all these hits via the generous referrals of Steve Muench and Didier Laurent.

If you're an aspiring speaker, or just somebody looking to get away from the northern hemisphere winter and experience Australia's delights later this year, the Australian Oracle User Group in conjunction with the Oracle Applications User Group will be holding their annual conference series on the following dates:

Perth - 20/21 November
Melbourne - 27/28 November

Hopefully you'll pencil these dates in and take time out to head "down under".

(It's a little early for our website to have details yet, so please feel free to post a comment on this forum and I'll endeavor to keep you informed of what's happening).

Sunday, 14 January 2007

JDeveloper Q&A with Steve Muench

In an ongoing series of articles, three Australian JDeveloper developers quiz Steve Muench of Oracle about his past, how he made the transition from Oracle Forms to Java, and on the latest and greatest JDeveloper 10.1.3 release. As an Oracle Ace with a visible web presence and his own blog, Steve is a leading force behind JDeveloper. His articles are a first port of call in making effective use of Oracle's ADF technology stack. Having worked for Oracle on just over 15 years, his fingerprints can be found in many Oracle's solutions.


Q) What is your principal role at Oracle and can you describe your average working day?

A) The job title on my business card is “Consulting Product Manager”. I try to help customers be successful using JDeveloper and Oracle ADF, then take the information I learn by doing this and try to leverage it to provide customer-driven guidance for the planning and implementation of features all across the JDeveloper 10g product. While I might end up getting involved in decisions about any features in the product, I tend to focus primarily on the features that make J2EE application building easier for typical corporate business application developers who might have used Oracle Forms or other 4GL tools in the past.

The fun thing about my job is that there isn’t really a typical day. I might be writing a technical whitepaper one day, writing or reviewing a product specification the next, working on demos to illustrate best-practice coding techniques to customers, fine tuning the next instalment of my Oracle Magazine column, answering users questions on the OTN discussion forum, discussing bugs and resolutions with the developers, working with Worldwide Support to assist on a thorny customer situation, just to name a few of the most typical things. I’m also sometimes involved in doing product evangelization at Oracle Partner, customer, or user group events, but these days most of my customer interaction happens over the internet using the OTN discussion forums or Oracle Collaborate Suite’s iMeeting software. This allows me to interact with many more customers, developers, and support engineers in a day than I could if I would be physically travelling around.

Q) Your Blog along with your strong presence on OTN and Oracle events has made you an Oracle personality in recent years. Ever get recognized on the street?

A) After 16 years at Oracle, I definitely recognize a lot of customer faces when I attend events like OpenWorld or user groups, but I unfortunately don’t have any funny stories to tell about being recognized in the street. I started my blog in January 2003 out of my personal frustration of not having enough time to write a proper book on Oracle ADF. It was the second best thing I could think of to help get users information about making the most of Oracle ADF. There is a lot of leverage in putting something in writing so that people can teach themselves how to “fish”, so to speak. Before taking a job with Oracle in 1990, my original goal in life was to be a math teacher, so I love explaining complicated things to people in terms they can understand. The blog lets me do it as my time allows.

Q) Besides JDeveloper you are known for your work on Oracle Forms v4.x & v5.0. How did you go making the transition between the 2 technologies? Do you still think about problems in terms of Forms solutions?

A) My journey from Oracle Forms to Java had a 3-year interim “layover” in the world of object-oriented development working as the lead product manager on the Project Sedona development team. This was work we did at Oracle to pioneer a complete object-oriented development environment before Java appeared on the scene. We now think of it as a useful “research project” that was ahead of its time, since many of the ideas embodied in that project have reappeared in JDeveloper and Oracle ADF. My initial learning curve in moving from a relationally-minded developer to one who could think in objects happened during that project, so by the time we began reimplementing the Project Sedona ideas into what became JDeveloper and ADF, I was over that hump. I can’t say that I think like a Forms developer any more, but I do understand how Oracle Forms developers work and think from having worked so long with Forms before. I used this intuition to help guide the initial design of the Oracle ADF framework, working in tandem with Oracle Applications teams, and use it to help plan and drive future feature work to keep making areas of the product that are still complicated a little easier with every release. We began a focused education campaign in the last year on helping Forms developers get their footing in the J2EE world with lots of targeted technical content on OTN and Oracle Developer Days seminars around the world. We’ve been getting great feedback from this effort so far from existing Forms users who’ve been wanting to get started with J2EE for their next major projects.

Q) Can you give an idea on the JDeveloper team and size, how it is dispersed, how this affects(ed) the build process and delivering the end product.

A) The sun never sets on the JDeveloper team! We have over 150 people working in various roles on the product comprising (in no particular order): developers, development managers, QA engineers, build engineers, doc writers, product managers, customer evangelists, and usability engineers. We’re spread out in development centers in Redwood Shores, Bangalore, Reading (UK), Pleasanton, Colorado, and probably a few more places I’m forgetting. Through the magic of the Internet we are part of a single, big virtual team. Our build engineers have automated the mechanism of producing nightly builds combining the collective work of all the developers, including automated testing and reporting to keep everyone honest and managers aware of project status, bug counts, and other stats.

Q) The JDeveloper team is actively visible on the OTN Forums and Oracle events around the world. What’s the goal behind this activity?

A) This is our primary opportunity to learn how customers use the product, what problems that have while getting started, and what they like and dislike about it. A good amount of our team members participate in the forum because they like this customer contact. One great thing that’s been happening over the last few years is that more and more our customers are helping each other in the forum, creating more of a true community feeling rather than just a place to ask questions of Oracle people exclusively. Often the customers who’ve been using our tools on a project for months will have unique insights that our daily use of the product wouldn’t give us. So it’s great to have both there in one of the most active discussion forums on OTN.

Q) Oracle and the JDeveloper team are actively involved in the Java Community Process with other key industry representatives to improve Java and J2EE. What’s your opinion on the success or failure of the collaborative process and Oracle’s input?

A) I think customers appreciate it when multiple vendors cooperate on designing a common standard and then compete on providing the best implementation of it. We’ve participated actively in many JCP expert groups, with driving roles most recently in the JSF, EJB 3.0, but with dedicated involvement in many others. It’s often a thankless job since it takes a lot of time to hammer out a good spec that’s been giving enough time to go through wide community review. I think the results have been overwhelmingly positive to date.

Q) For Java programmers questions about IDEs invoke a holly war between Eclipse and Netbeans. How do you think JDeveloper differentiates itself from these products?

A) We try to differentiate ourselves by providing an order of magnitude more end-to-end, integrated functionality, and since making JDeveloper 10g free in June of 2005, we try to make sure price is no longer a differentiator. With other free IDE’s, it’s up to you to scout out the collection of plug-ins you want to use and not all of them are free. When you plug them together, you can end up with functionality that doesn’t quite seem like it was built by the same company, since in fact, it wasn’t. JDeveloper 10g delivers the functional breadth of a tool like Visual Studio Enterprise Architect Edition, but for free and on an open deployment architecture.

Our goal since 1997 has always been to provide a product that addresses the complete development lifecycle and simplifies complex business application development. We have a demanding set of internal customers in the form of the Oracle Applications division, where over 4000 developers use the JDeveloper/ADF technology stack to build self-service web application modules for the eBusiness Suite. We’ve built a product that was good enough for ourselves to use, and in the process tried to make sure it was appealing to external customers as well. We’ve steadily improved the usability every release to be more visual, and more productive than ever.

Since Eclipse, NetBeans, and IntelliJ started with a sharp focus exclusively on the Java coding experience, until recently their code-focused development features like refactoring were more extensive than JDeveloper 10g’s. We’ve completely remedied this in our JDeveloper 10g Release 3 (10.1.3) product. We started by implementing the hard, enterprise features like the Oracle ADF framework, visual page design, built-in performance profiling, UML modelling, database design, and other features. These have taken years to get right to a totally integrated experience. It’s going to be arduous for these other players who started with the lower-level Java coding features to move “upmarket”, if you will, to provide a similar end-to-end experience for the corporate application developer.

Q) What comments would you make to traditional Forms developers with few Java or object oriented skills in making the leap to JDeveloper 10.1.3 for development? Do you believe the ease and usability of Oracle Forms development will be seen with a 3GL such as Java?

A) My advice would be to leverage the resources we’ve made available at the J2EE Application Development for Forms and Designer Developers site, read the back issues of my Oracle Magazine DEVELOPER:Frameworks column, attend one of our Developer Days seminars, and then pick a small, yet real-world application to build while they learn the ropes. We have numerous lessons focused specifically on helping Forms users grasp the concepts and working approach of JDeveloper/ADF. A developer with 15 years of experience in working with Oracle Forms often forgets that its taken them 15 years to learn all the ins and outs of the Forms product. The JDeveloper/ADF environment is consciously design to work a lot like the Forms design experience, and the features of the ADF framework handle all of the same things that the Forms runtime makes easy for developers in that product. I’m not saying there is no learning curve, by no means. But, due to the modular, consistent architecture of ADF, once you grasp the fundamentals, putting together the pieces is not as hard as it initially looks.

Q) JDeveloper 10.1.3 marks a significant milestone in the product’s history by moving away from UIX technology to the adoption of JavaServer Faces in Oracle’s own flavour ADF Faces. What decisions were made in deciding JSF was the best future for JDeveloper and its web developers?

A) Customers complain that the best practices for implementing web application UI’s on the J2EE platform have evolved too many times over the last years. First servlets, then JSP pages, then JSP Pages with tag libraries, then JSP pages married with Struts. Struts is also not the only game in town, so a thousand flowers have bloomed trying to build a better mousetrap. We built UIX because our own Oracle Applications development teams needed a higher-level, component-based, event-driven way to build rich, real-world web user interfaces with attractive and often complex, interactive behaviours. By working extremely hard as part of the JSF expert group to bring the expertise we gained by implementing UIX to the table, we were able to strongly influence the design and implementation of the JSF spec. This allowed us to redevelop UIX on top of an industry standard so our hundred or so components can now be used in any JSF-compliant IDE. Our strong support behind JSF reflects our conviction that it is a robust technology that should insure developers can learn it and stick with it for a long time to come. That said, we’ve also invested in improvements in our support for Struts because many, many users are using that today, so whether you initially start using JSF or wait a while longer and stay with Struts and JSP, we’ve got you covered with visual productivity features across the board.

Q) Besides ADF Faces and refactoring, what other new features do you see key to JDeveloper 10.1.3?

A) JDeveloper 10.1.3 has so many cool new features, it’s hard to pick just a few. We’ve improved code navigation, refactoring, team development, modelling, web services, web development, mobile development, Swing development, XML development, and database development. We’ve invested a lot of effort in the ADF framework layers to make working with all backend technologies easier, and made them work especially seamlessly with the new JSF view-layer technology, in addition to their existing support for JSP and Swing. 10.1.3 is really a huge step up for users in all areas of the product.

Q) The next versions of JSP, JSF and J2EE (now JEE) are around the corner. What changes do you envisage will occur to JDeveloper because of this?

A) We’re already supporting all of the latest standards in the 10.1.3 release, like JSF, J2SE 5.0, JAX-RPC web services, EJB 3.0, etc., so I don’t expect anything radical to be changing based on what you’ve mentioned in the future.

Q) There are frequent criticisms raised by beginner and experienced JDeveloper users, that documentation leaves something to be desired, incomplete JDocs with nothing but function names, cookie-cutter examples that through simplicity ignore the gotcha’s, and poor support from Oracle Support. How are these criticisms being addressed by the JDeveloper team?

A) We’ve provided meaty technical whitepapers and demos to supplement our online reference documentation, but it’s a fair point that one thing we’re missing is a proper developer’s guide that you can read cover to cover and get up to speed. We’re directly addressing this issue by providing two ADF Developer’s Guides in the 10.1.3 timeframe. These are readable manuals that cover the end-to-end development experience of using Oracle ADF in JDeveloper for building applications. One guide will focus on the experienced Java developer and one guide on the Forms/4GL developer. Each guide covers the same basic ground of building an end-to-end demo application and explains all the details that make it up, but the guides are separate to cater to the recommended business tier technologies for these two distinct audiences as well as to best cater to each group’s existing skillset. We’ll continue providing new Oracle by Example tutorials that have proven popular as well. We have a new “Cue Cards” system in the 10.1.3 product to provide interactive tutorials on all the application building basics, so we hope through these various initiatives to really improve the out of box experience. We routinely do support trainings and interact with support when they need assistance from development, so they will be ready to support the 10.1.3 product when customers start needing time-critical help with issues.

Q) JDeveloper as a product has seen many changes since its introduction in 1998. In this time the technology stack has changed frequently, more recently in the web sphere leaping from JSP, UIX and Struts to JavaServer Faces. This presents a challenge to old and new developers alike. Do you see a future of stability or more change?

A) As I mentioned above, we see JSF as hopefully the last “paradigm shift” in J2EE web interface building technologies. As part of the expert group, we’ve insured it is open and extensible enough to permit vendors to develop rich, sophisticated component libraries without having to change the fundamental model of how things fit work or what a developer needs to know to build applications with JSF components. So, in short, I see a future of more stability in this areA)

Q) Java and its relating thick web technology stack has come under attack more recently by reported simplified development web frameworks such as Ruby on Rails (and potentially Microsoft’s .Net). What’s your analysis on these technologies and their contrasts with Java and the facilities provided through JDeveloper?

A) I’ve only just scratched the surface of Ruby on Rails, but my impression of watching the online screencasts of building an “application” in 10 minutes is that I could build that same application in less time with JDeveloper and ADF. Functionality-wise, JDeveloper 10.1.3 holds it own in any kind of comparison with Microsoft Visual Studio 2005, except that our fully-loaded product is free and the applications you build with it can deploy to any platform.

Q) With the significant 10.1.3 release behind you, what new features are we likely to see in JDeveloper’s future? Any features that will disappear?

A) We’re working hard on making it easier to build end-user customization into applications, which is a required feature for many portal-style applications in the real world, but very hard to implement in general. We’re also investing a lot of energy in taking our declarative development features in ADF Business Components to the next level to further simplify the next wave of common application patterns that we see our internal and external customers doing most frequently. Finally, we’re already well along the path to implementing additional ADF Faces JSF controls that improve the AJAX-style interactivity of the browser interface. Same JSF architecture, even richer component options being added to the already rich set we offer today. These are all ingredients that are tablestakes features for the coming Oracle Fusion Applications wave, but have the nice side-effect of bringing incredible new power to all JDeveloper/ADF users in the process.

Q) Oracle recently announced that ADF Faces, Oracle's JavaServer Faces implementation will be donated to the Open Source Apache Faces project as Apache Faces Cherokee, with key Oracle programmers supporting the initiative. What were the reasons for the donation and what key benefits will this provide ADF Faces users in your opinion?

I don’t think I can do a better job than Jonas has already done on answering this question here: http://www.orablogs.com/jjacobi/archives/001574.html :)

(This article is a reprint of the article I published in the quarterly AUSOUG magazine Summer 06 edition. I'd like to extend my thanks to Steve Muench for agreeing to the interview, and Brenden Anstey from Delexian and Ray Tindall from Sage Computing Services for their input on this Q&A article.)