Our second official book review in on its way...

by Fábio Souza

Hi everyone, are you doing well? I'm fine, thanks for asking.
Well, I was wondering these days : "It would be a good idea to change the topic for a little while and talk about a product". It seems that someone at Packt Publishing heard me, and, to incentive myself, they invited us to write a review of a new book .
The topic is hot: Webcenter 11g. As you all know (I hope :)) this is a strategic product that arose to compete in the Enterprise 2.0 market.

The book is:
Web 2.0 Solutions with Oracle WebCenter 11g

I'm very excited to read the book, but I can already tell you some good things about it:
- Vince Casarez is one of its reviewers
- It covers all the product's main points (installation, environment setup, custom applications, and so on)
- There is a Oracle WebCenter Spaces Overview

I hope to be posting the review soon!

Ahhh! I almost forgot (kidding, I was planning it) to say that our big friend and also architect master, George Maggessy, helped the writers with his WebCenter knowledge.

See you!

JDeveloper Overview and (book) Review

Dear visitors,
I will pretend I forgot that I'm about a year without posting anything and I will go straight to the subject that I owe to you: The review of the book "Processing XML documents with Oracle JDeveloper 11g". Before start I would like to make an introduction to JDeveloper.

About JDeveloper

Introduction

JDeveloper is the Oracle's Strategic IDE. Besides being used to develop Oracle's products it is a tool that has the goal to support all Oracle's technological stack, and also the majority of Java EE patterns and derivables. For example: you can draw a BPEL flow that orchestrates several services available in Oracle Service Bus, develop WSRP portlets that will be consumed by your Oracle Portal, implement EJBs that can be easily published like Web Services, or even build an portal that follows the E2.0 trend with Webcenter ADF components.

Main features

• Integrated enterprise development environment
• Visual and declarative editors
• Complete development lifecycle coverage
• Built-in development framework
• Advanced features for Java, Database, Web services, SOA, and Web development

Being a developer, I cannot forget to mention the powerful Oracle ADF (Application Development Framework). I will not cover details but worth it is saying that part of the framework is considered a model JSF implementation -- by the way, it was donated to the Apache Foundation -- and it has a powerful abstraction of the model layer (JSR-227) that, with the JDev's drag-and-drop-declarative interface, makes the development of lowly coupled and highly cohesive applications much simpler and more productive.

JDeveloper and Netbeans

Both IDEs are very important and their development will not stop. While support for Oracle's stack will be implemented mostly in JDev, NetBeans will continue to provide a powerful open source IDE.

License:

JDeveloper is a free tool, you don't have to purchase it. Besides, there is a runtime license required for any production application if you choose to use Oracle TopLink or the Oracle ADF. This license is already included in all editions of the WebLogic Server. Nevertheless you can use JDev for development/evaluation. There is no special license for academic/open source use, but in many cases the "Free OTN License Agreement" (check it out) for JDeveloper will cover this type of usage.

This is the information that I've found in Oracle's website (see the links at the end of the article). Remember: "license things" can and do change. Always check them first before using the product.

Curiosities

For those who are willing to know something about the JDev’s origins.

Processing XML documents with Oracle JDeveloper 11g – The Book

Introduction

In my opinion, JDeveloper 11g shows that it has reached a very good maturity with regard to dealing with XML. The idea of this book is to show us several easy-to-use out-of-the-box JDev’s features while, at the same time, it exposes fundamental concepts about XML processing.

Some concepts about XML presented by the book:

• DOM Parser
• SAX Parser
• Validation with XSD
• XML navigation using XPath
• XML transformation using XSLT

Some JDev's features that are also presented by the book:

• XML Edition(by code and also by its own structure)
• Creation of XSD using drag and drop
• Wizard to generate XMLs using XSDs
• Automatic XML validation (using XSD)

The book has 11 chapters and each of those has a well defined scope and they can be read independently (you don't need to follow any particular order). Generally each chapter introduces a different technology with the following order: an overview, discussion about the main features and the demonstration of a practical example. The examples are very simple and made with dozens of print-screens and source codes. Although it has about 370 pages, the big part of them are used to explain these examples, what turns the book more practical than theoretical.

Public

In my vision, the book targets to two types of public:
1 - Advanced Developers: the book can introduce technologies and may be used as a quick reference guide.
2 - Novice Developers: the book introduces fundamental concepts/tools, showing them in a practical way.

What caught my attention

The book talks about several recent technologies that are in evidence. There are chapters about DOM 3.0 LS, XSL-FO, XML conversions, and also Oracle Berkley DB. For each approach concerning XML processing, the author always uses the Oracle’s Implementation (Oracle XDK). This is very interesting because it shows us features that you don’t have when using the default interfaces.

What I missed the most

There are no details about performance or even about how to choose the right technology for the right problem. And... there is no mention of StAX.
Another point to mention is that the book doesn’t talk about the tight-coupling disadvantages that exist when the Oracle XDK implementation is used instead of the default interfaces.

Chapters overview

Chapter 1: Creating and Parsing an XML Document

• Introduction to SAX and DOM

Chapter 2: Creating an XML Schema

• Introduction to Schema (XSD)
• How to create a schema using the IDE and its wizards
• How to create XML based on a schema

Chapter 3: XML Schema Validation

• How to programmatically validate a XML document using schema

Chapter 4: XPath

• How to use the IDE to "query" the XML using XPath
• How to programmatically "query" the XML using XPath

Chapter 5: Transforming XML with XSLT

• Introduction to XSLT
• How to programmatically use XSLT
• How to use Oracle's XSLT extension function to call Java classes (very interesting, and seems very powerful as well)

Chapter 6: JSTL XML Tag Library

• Introduction to the JSTL XML tag library
• How to configure a web project that uses this tag library in JDev
• Using JSTL to parse and transform a XML document

Chapter 7: Loading and Saving XML with DOM 3.0 LS

• What is and how to use it
• Exposes advantages of using it

Chapter 8: Validating an XML Document with DOM 3 Validation

• Shows the "dynamic validation", a very relevant functionality that is part of DOM 3.0 LS. This is a very important stretch that I took from inside this chapter:

Oracle XDK 11g is the only XML API that implements the DOM Level 3 Validation specification (http://www.w3.org/TR/2003/PR-DOM-Level-3-Val-20031215/); however, some of the DOM 3 Validation features are not implemented by the Oracle XDK 11g API. A test was run by W3C to determine which of the DOM 3 Validation methods are supported by the XDK 11g implementation. You can refer to the results of the DOM3 Validation test (http://www.w3.org/2003/11/26-DOM3-Val-Oracle-Result.html) when developing a DOM 3 Validation application.

Chapter 9: JAXB 2.0

• Introduction to JAXB 2.0
• How to use JDev to generate the JAXB classes using a schema
• Introduction to the marshalling/unmarshalling process and to the JAXB 2.0 annotations

Chapter 10: Comparing XML Documents

• Overview about tools that can do XML comparison/diff
• Introduces the Oracle XDK 11g. This tool provides an API to work with comparison/diff and to automate the XSL generation. The second feature is achieved based on the original XML and the XML which we want to transform the original one into. Example: XML1 has X differences comparing to XML2. Using these X differences the API knows how to create an XSL that transforms XML1 into XML2

Chapter 11: Converting XML to PDF

• Overview of several tools that generate PDF files
• Short explanation about XSL-FO
• Demonstration on how to transform a XML into XSL-FO document using XSL
• How to use the Apache FOP API to transform a XSL-FO document into a PDF file

Chapter 12: Converting XML to MS Excel

• Overview about several tools to read/write XLS files
• This chapter is not like the others that introduce some standard patterns and concepts. This one just shows how to use Apache POI-HSSF to work with XLS

Chapter 13: Storing XML in Oracle Berkeley DB XML
This is a very interesting chapter because BDB XML is not a subject that is commonly discussed. It's worth to know the basics because it is an efficient way (and also fast) to store and query XMLs. Main points:

• Overview about Oracle Berkeley DB XML ("an embeddable XML database for storing and retrieving XML documents").
• Using BDB XML from command line (basic operations)
• Using BDB XML with a Java API (basic operations)

Chapter 14: Oracle XML Publisher

• Overview about Oracle XML Publisher (now it is called Oracle BI Publisher) and its advantages over the Apache FOP/Apache POI (shown on chapters 11 and 12, respectively).
• How to use Oracle XML Publisher + XSL-FO to generate PDF (and how it is possible to generate different formats as well)
• How to create and merge XSL-FO docs
• How to merge PDF docs
• How to use the "Data Engine API" to create an XML document from database data

Sources:

Processing XML documents with Oracle JDeveloper 11g
JDeveloper
JDeveloper History
JDeveloper FAQ
Oracle Java Tools FAQ

How to upgrade your Dell’s BIOS directly from Ubuntu

I know this post is totally off topic but I faced this same issue last week and I’m pretty sure this will be very handy for a lot of people out there. So why not share it, right?!

Many people worldwide are migrating from Microsoft Windows to Linux nowadays, specially Ubuntu, which is probably the most friendly and stable distribution currently. I’m sort of one of those people. I’ve always used Unix but mainly at my work environment. But I’ve recently decided to switch one of my desktop PCs, a Dell Optiplex 755, from a 32-bit Windows XP Professional to a brand new 64-bit Ubuntu 10.04. And so far I’m an extremely happy user, I must say (finally making full and intelligent use of my 4GB RAM and certainly much more efficient use of my Core 2 Duo CPU).

Problem was, as I was eager to get rid of my old Windows XP, I didn’t pay attention to details, such as the PC’s BIOS version. By the moment I realized it was still A14 while the most recent was A17, I had already installed Ubuntu without any dual boot option and spent hours installing cool apps and tweaking everything to my own personal taste. As you probably know, flashing the newest BIOS release from Dell without any DOS or Windows partition on the PC would now be quite a handful and would probably involve using some freeware stuff to create a DOS or Windows recovery bootable CD and then execute Dell’s flash utility from an USB drive or something like that.

As usual, I sought help from our good friend Google and found some promising blogs and forums on the subject. However, none gave me a full-circle solution. But after some deeper research, I was able to put all necessary pieces together and compile the easiest steps to flash virtually any Dell’s BIOS directly from Ubuntu’s terminal prompt and using the most reliable source: Dell’s upgrade utility itself.

So, these are the magical steps, compiled from several different forums and articles  (they might work on other Linux distributions as well but I only tried on Ubuntu):

1. apt-get update (not always needed, but won’t hurt)
2. apt-get install libsmbios-bin
3. getSystemId (will display info about your Dell, including BIOS version, System ID and Service Tag)
   
4. Download the most recent BIOS upgrade for your system from http://support.dell.com as you would if using Windows
5. Execute the downloaded utility on a command line. For example: O755-A17.exe –writehdrfile
   This step can be executed on any Windows machine or directly on Ubuntu using Wine (apt-get install wine).
6. (you can skip this step if Wine was used in step 5) FTP or copy the extracted .hdr file to your Ubuntu
7. modprobe dell_rbu (loads the dell_rbu driver)
8. trigger the BIOS upgrade using dellBiosUpdate –u –f <the .hdr file from step 5>
9. reboot the machine (the BIOS will be automatically upgraded during boot)

Voilá! You have safely upgraded your Dell’s BIOS directly from Ubuntu, without having to create any external boot CD or USB drive.

Hope this helps. Enjoy!

Micromanaging Memory Consumption

by Eduardo Rodrigues

As we all know, specially since Java 5.0, the JVM guys have been doing good job and have significantly improved a lot of key aspects, specially performance and memory management, which basically translates into our good old friend, the Garbage Collector (a.k.a. GC).

In almost all articles I’ve read on the memory subject, including those from Sun itself, a particular comment was always present. That briefly is:

The JVM loves small-and-short-living objects.

Don’t “nullify” variables (myObject = null;) when you decide they aren’t needed anymore as a way of hinting the GC that the objects once referenced by those variables are OK to be disposed.

I guess, after reading this “message” so many times, I finally internalized it in the form of a programming style, if I may. It’s actually very simple and takes advantage of a very basic structure, which is extremely common and kind of taken for granted. I’m talking about the very well-known code block. Yes, I’m talking about those code snippets squeezed and indented between a pair of curly braces like { <my lines of code go here> }.

In general, most programmers use these structures just because they have to as they are mandatory in so many portions of the Java language’s syntax. You need them when declaring classes, methods, try-catch-finally blocks, multi-line for loops, multi-line if-then-else blocks, etc. But the detail many programmers seem to forget is that these code blocks may actually be defined anywhere in a method body, unattached to any particular keyword or command. Even more, code blocks can be nested as well.

Besides being syntactically mandatory, the use of code blocks demarcated by opening and closing curly braces also imply a very important feature of the language. Code blocks also define variables scopes! I’ll explain…

Any variable that happens to declared inside a curly-braces-pair-demarcated code block will “exist” only within the context of that particular code block (or scope). Such variables are said to be “local variables”. Actually, if we try to use a local variable outside of its scope, we’ll most certainly get a compilation error, because that variable literally doesn’t exist outside that code block (or scope) where it was declared. And right there lies the very code of this best-practice tip.

Specifying well-defined scopes for all your local variables is actually the best way of hinting the GC about what strong references are or not in use when it kicks in. Simple enough, any strong reference coming from a variable declared inside a scope that is currently not being executed, is clearly to be considered as not in use by the GC, thus increasing the chances of proper and prompt disposal of the referenced object (if no other strong references to it exist, of course).

So, in order to better illustrate my case, here is a simple example. First let’s consider this very innocent piece of code:

public class Foo
{
   public final static void main(final String args[])
   {
        try 
        {
            DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
            DocumentBuilder builder = builderFactory.newDocumentBuilder();
            URL cfgUrl = this.getClass().getClassLoader().getResource("config.xml");
            File cfgFile =  new File(cfgUrl.toURI());

            Document cfg = builderFactory.newDocumentBuilder().parse(cfgFile);
            XPath xpath = XPathFactory.newInstance().newXPath();
            Node cfgNode = (Node)xpath.evaluate("//*[local-name()='config']", cfg, XPathConstants.NODE);

            (...)
           
        } catch (Exception ex) {
           ex.printStackTrace();
        }
    }
}

If we consider that in the very first part, variables builderFactory, builder and cfgUrl are not really needed after cfgFile is instantiated, rewriting that part like this would be preferred:

public class Foo
{
   public final static void main(final String args[])
   {
        try 
        {
            Document cfg;

            {
                DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
                DocumentBuilder builder = builderFactory.newDocumentBuilder();
                URL cfgUrl = this.getClass().getClassLoader().getResource("config.xml");
                File cfgFile =  new File(cfgUrl.toURI());
                cfg = builder.parse(cfgFile);
            }

            XPath xpath = XPathFactory.newInstance().newXPath();
            Node cfgNode = (Node)xpath.evaluate("//*[local-name()='config']", cfg, XPathConstants.NODE);

            (...)
           
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

With that, when the execution is passed the red code block, all local variables declared only in that context will cease to exist for all practical means. This simple example is a mere illustration and certainly doesn’t represent any major benefit but, believe me, in a real life code, using this approach of well-defined scopes for local variables may have a significant and positive impact on your application’s memory consumption profile.

As you can see, this is indeed a very simple Java best-practice tip. It’s easy to adopt, has no collaterals whatsoever and can prove to be very powerful. So, why not use it?

Enjoy!

The X (Path) File

by Eduardo Rodrigues

This week I came across one of those mysterious problems where I had some test cases that needed to verify the content of some DOM trees to guarantee that the test went fine. So, of course, best way to achieve this is using XPath queries. And because the DOM trees involved were all quite simple, I figured writing the XPath queries to verify them would be like a walk in the park. But it wasn’t.

I spent hours and hours trying to figure out what was I doing wrong, googling around but nothing seemed to make any sense at all. Then, just when I was almost giving up and throwing myself through the window, I finally realized that tiny little detail that explained everything and pointed me out to the right solution. The culprit was the default namespace specified in my root element!

Turns out, whenever a namespace URI is specified without any prefix (like xmlns=”http://foo.com/mynamespace”), this is considered to be the document’s default namespace and it usually don’t affect parsers. But, as I found out, it does affect XPath big time. XPath, by definition, will always consider namespaces, even the default one. The problem with that is, because a default namespace don’t have any specific prefix, we completely lose the ability of using the most simple and common path-like approach when writing queries to locate nodes in the DOM tree.

Here’s a very simple example that illustrates the issue very well. Consider the following well-formed XML:

<?xml version="1.0" encoding="iso-8859-1"?>
<HR Company="Foo Inc.">
    <Dept id="1" name=”Board”>
        <Emp id="1">
            <Name>James King</Name>
            <Salary>150000</Salary>
        </Emp>
        <Emp id="10">
            <Name>Jon Doe</Name>
            <Salary>100000</Salary>
            <ManagerId>1</ManagerId>
        </Emp>
        <Emp id="20">
            <Name>Jane Smith</Name>
            <Salary>100000</Salary>
            <ManagerId>1</ManagerId>
        </Emp>
    </Dept>
</HR> 

If I want to check if there’s really an employee named “Jane Smith” earning a 100K salary in the “Board” department, a very simple XPath query such as “//Dept[@name='Board']/Emp[string(Name)='Jane Smith' and number(Salary)=100000]” would easily do the job.

Now just add an innocent default namespace to the root element:

<HR xmlns=”http://foo.com/HR” Company="Foo Inc.">

and try that very same XPath query that worked so well before. In fact, even the most simple of all queries – “/” – won’t work as expected anymore. That’s just because XPath considers the default namespace context and therefore requires it to be referenced in the query. We just don’t have any way of referring to that namespace in the query since it doesn’t have any prefix associated to it. My particular opinion on this issue is that it represents a huge design flaw in XPath specs., but that’s a completely different (and now pointless) discussion.

Unfortunately, there’s no magic in this case. To keep using XPath queries in this kind of situations, we need to use a more generic (and less compact) syntax where we can be more specific about when we do care about fully qualified (or expanded) names and take namespaces into consideration, or if we just care about local names but do not about namespaces. Bellow is the very same query, using this more generic syntax and these 2 different naming flavors, both providing the exact same outcome:

1. If you need (or want) to consider the namespace:
   

   //*[namespace-uri()=’http://foo.com/HR’ and local-name()=’Dept’ and @name='Board']/*[namespace-uri()=’http://foo.com/HR’
   and local-name()=’Emp’ and string(Name)='Jane Smith' and number(Salary)=100000]

2. If you just care about the elements’ names, then just remove the “namespace-uri” conditions:
   

   //*[local-name()=’Dept’ and @name='Board']/*[local-name()=’Emp’ and string(Name)='Jane Smith' and number(Salary)=100000]

The reason why I prefer to use function local-name() instead of name() is simply because, together with namespace-uri(), this is the most generic way of selecting nodes since local-name() doesn’t include the prefix, even if there is one. In other words, even if you had a node such as <hr:Dept>, local-name() would return simply “Dept”, while name() would return “hr:Dept”. It’s much more likely that the prefix for a particular namespace will vary amongst different XML files than its actual URI. Therefore, using predicates that combine functions namespace-uri() and local-name() should work in any case, regardless of which prefixes are being used at the moment.

Enjoy!

References

• http://www.w3.org/TR/xpath/
• http://www.w3schools.com/xpath/default.asp