Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts

Monday, May 24, 2010

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!

Tuesday, March 24, 2009

Java and the Timezones

by Fábio Souza

Timezone, when using Java, can be something tricky. You can get surprised when you change your OS timezone (something common to countries with DST) and it doesn't take any effect on your Java programs. What does Sun have to say about that? It can be found at their FAQ:

Do my operating system's timezone patches fix the Java platform's timezone data?

No. The Java SE platform's timezone data is not read from the local or host operating system. The Java SE platform maintains a private repository of timezone data in locally installed files (.../jre/lib/zi) as part of the Java Runtime Environment (JRE) software. Applying whatever operating system timezone patches (for example Solaris OS, Linux, Windows) will have no effect on the accuracy of the Java SE platform's timezone data.

Sun recommends you to maintain all JVM up to date to avoid Timezone problems. To specific cases where a Timezone update is needed, they provide a tool called TZUpdater. TZUpdater is a JAR that contains timezone informations provided by Olson Timezone Database. To update the JVM's timezone you need to execute TZUpdater's most recent version like this:

java -jar tzupdater.jar -u (don't forget to check if you have read/write access to Java's directory structure)

We are ok about Sun's JVM... But the solution is the same to all JVMs? Not really =), but it is very similar to IBM JVM and Oracle JRockit. In all cases we either have to download a program and execute it to update the installed JVM or wait for the next JVM update release.

Here are some useful links:

Sun:

IBM (thanks to my friend and co-worker Frederico Hakamine):

Oracle:

Wednesday, April 23, 2008

Diagnostics beyond OracleAS Control Console

by Eduardo Rodrigues


One of the many companies recently acquired by Oracle is a small one called "Auptyma", whose founder and former CEO, Mr. Virag Saksena, was previously Director of the CRM Performance Group at Oracle. It's main contribution for Oracle's fast growing product line was its "Java Application Monitor" which is now part of the "Oracle Fusion Middleware Management Packs" (that's where http://www.auptyma.com now takes us to) and was renamed to "Oracle Application Diagnostics for Java" or simply Oracle AD4J (although it's also referred as JADE as in Java Application Diagnostics Expert). Holy alphabet soup!

The "new" component integrates the Oracle Enterprise Manager 10g Grid Control suite but it also lives as a separate product, which is great, specially for us developers. It can be downloaded from http://www.oracle.com/technology/software/products/oem/htdocs/jade.html. The installer is very small and also very easy and intuitive.

AD4J may seem awkward at first, when you notice the fact that it also installs and uses the old Apache JServ and a PostgreSQL database. But it's worth it!

I've tried AD4J with my OC4J 10.1.3.3 standalone and I can say it works pretty well and is certainly a much more interesting and useful diagnostics tool than OracleAS 10g Control Console with JVM metrics enabled. My only extra work was to reinstall JDK 1.5.0_14 and reconfigure OC4J to use it (I was already update 15) because it's the most recent JDK 1.5.0 update currently supported by AD4J.

Its main features includes:
  • Production diagnostics with no application instrumentation, saving time in reproducing problems.

  • Visibility into Java activity including in-flight transactions, allowing administrators to proactively identify issues rather than diagnosing after-the-fact (application hangs, crashes, memory leaks, locks).

  • Tracing of transactions from Java to Database and vice-versa, enabling faster resolution of problems that span different tiers.

  • Differential heap analysis in production applications.

  • Possibility to setup alerts based on configured thresholds and forward them using SNMP (which means potential integration with other enterprise monitoring products like OpenView, for instance)

As you can see, it's a pretty interesting, yet small and simple, diagnostic and monitoring tool for Java applications. You can also check these resources for further info:
Cheers and... keep reading!

Monday, March 31, 2008

Using FindBugs in JDeveloper 10g

by Fábio Souza

FindBugs Logo
These days I've been looking for a good way to incorporate FindBugsTM within my JDeveloper 10g and I couldn't find anything about it on the net. I talked with Eduardo and we both thought it would be a good idea to configure FindBugs as a JDeveloper External Tool (and it is indeed).

Ok, before I start listing the steps to do it, I must say I'm pretty much aware of the fact that you will probably notice that I'm using Eduardo's JAXB 2.0 configuration steps listed on his previous post "JAXB 1.0 vs. 2.0 in JDeveloper 10g". Well... what can I say? I am a CTRL+C/CTRL+V addicted and I just can't help it! :D
  1. Click the menu item "Tools -> External Tools..."

  2. Press the "New..." button to start the "Create External Tool" wizard

  3. Select "External Program" as the "Tool Type" and press "Next"

  4. Fill the 3 displayed fields as follows:

    1. Program Executable:

      full path to the "java.exe" from your preferred JAVA_HOME (must be Java 5.0 or greater)

    2. Arguments:

      -Dfindbugs.home=. -Xmx256m -jar lib\findbugs.jar -sourcepath "${project.first.sourcepath}" -auxclasspath "${project.classpath}" -html -output "${project.dir}\${file.name.no.ext}.findbugs.html" "${project.outputdirectory}" "${project.outputdirectory}"

      The arguments above will be passed to "java.exe". Notice that we're bypassing "findbugs.bat" and executing the FindBugs JAR file directly. We must do this way because the batch file requires the classpath passed after "-auxclasspath" to be enclosed in double quotes (") and the macro "${project.classpath}" will match that requirement only when there's at least one path including one ore more blank spaces in its directories names.

    3. Run Directory:

      full path where FindBugs is installed.

  5. Press "Next" to advance to "Display" step and fill the 3 fields as you like. I suggest the following:

    1. Caption for Menu Items:

      FindBugs

    2. ToolTip Text:

      Run FindBugs on your project.

    3. Icon location:

      Download and configure this one -> FingBugs icon

    4. Press "Next" to advance to "Integration" step where I recommend selecting "Tools Menu" and "Navigator Context Menu"

    5. Press "Next" to advance to the final step "Availability". Here, you have to choose the option "When Specific File Types are Selected" and then move only the item "Java Project" from list "Available Types" to list "Selected Types"

    6. Press "Finish" and done!

Attention! I got an error while trying to use FindBugs in my JDeveloper 10.1.3.3. When "${project.classpath}" is expanded after "-auxclasspath", it includes the Java library paths as well. But, I don't know why, the default JDeveloper's Java SE library has i18n.jar, sunrasign.jar and the "classes" folder included in its classpath but these three items actually don't exist, so FindBugs will abort when it tries to locate them. I had to remove these items from my JDeveloper Java SE Library classpath to solve this problem.

Now it's all set to use FindBugs! Just right-click on a project in the Application Navigator and select "FindBugs". An HTML report will be generated in project's folder and standard output and error will be sent to JDev's Message View.

Enjoy your new tool!

Tuesday, January 8, 2008

JAXB 1.0 vs. 2.0 in JDeveloper 10g

by Eduardo Rodrigues

Ok, I know JDeveloper 10g already comes with an embedded JAXB compiler which can be found in menu "Tools -> JAXB Compilation...". The only problem with this compiler is that it's a JAXB 1.0 implementation and, believe me, the differences are simply HUGE when compared to it's successor, JAXB 2.0. And all for the very best. To prove my point, let's go through a simple example comparing both JAXB versions.

First of all, let's create a new application in JDeveloper with one empty project called "JAXB 1.0" adding only "XML" to its technology scope:

Click to enlarge

We must have a valid DTD or XML Schema so the JAXB compiler can work. Let's consider this small and simple XML Schema borrowed from a W3C tutorial:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- definition of simple elements -->
<xs:element name="orderperson" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
<xs:element name="title" type="xs:string"/>
<xs:element name="note" type="xs:string"/>
<xs:element name="quantity" type="xs:positiveInteger"/>
<xs:element name="price" type="xs:decimal"/>

<!-- definition of attributes -->
<xs:attribute name="orderid" type="xs:string"/>

<!-- definition of complex elements -->
<xs:element name="shipto">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="name"/>
   <xs:element ref="address"/>
   <xs:element ref="city"/>
   <xs:element ref="country"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
<xs:element name="item">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="title"/>
   <xs:element ref="note" minOccurs="0"/>
   <xs:element ref="quantity"/>
   <xs:element ref="price"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="shiporder">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="orderperson"/>
   <xs:element ref="shipto"/>
   <xs:element ref="item" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute ref="orderid" use="required"/>
 </xs:complexType>
</xs:element>
</xs:schema>


Just copy the code above to a file named "shiporder.xsd" in the project's root directory so it will automatically show in project's "Resources" folder:

Click to enlarge

Now select file "shiporder.xsd" in the application navigator, click the menu item "Tools -> JAXB Compilation..." and fill up the pop-up shown as the screenshot bellow:

Click to enlarge

After pressing the "OK" button, you should see the following scenario:

Click to enlarge

As you can see, the JAXB compiler generates a bunch of classes and interfaces reflecting the structure defined by the compiled XML Schema. If you look closer, you'll notice that some of the classes extend "oracle.xml.jaxb.JaxbNode" (like class ShiporderTypeImpl, for instance). That's because the built-in JAXB compilation feature we just showed relies on a JAXB 1.0 proprietary implementation provided by Oracle in its XML Developer Kit which comes with JDeveloper. You may get more details on this at Oracle XDK Home site.

Continuing with our test case, let's create a sample "testorder.xml" based on our shiporder.xsd schema:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<shiporder orderid="0001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:noNamespaceSchemaLocation="shiporder.xsd">
  <orderperson>Eduardo Rodrigues</orderperson>
  <shipto>
    <name>John Doe</name>
    <address>#100, Oracle Parkway</address>
    <city>Redwood City</city>
    <country>USA</country>
  </shipto>
  <item>
    <title>DVD+RW</title>
    <quantity>50</quantity>
    <price>.50</price>
  </item>
  <item>
    <title>17&quot; LCD Monitor</title>
    <quantity>5</quantity>
    <price>150.00</price>
  </item>
  <item>
    <title>Bluetooth Mouse</title>
    <quantity>10</quantity>
    <price>40.00</price>
  </item>
</shiporder>


To read in and process this sample XML using the package generated by Oracle's JAXB compiler, we must use the JAXB feature called "Unmarshal". To do that, I'll modify class test.jaxb1.TestJAXB1 like this:

package test.jaxb1;

import java.io.File;
import java.util.List;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import test.jaxb1.shiporder.*;

public class TestJAXB1 {

   static JAXBContext context = null;

   public static void main(String[] args) {
      try {
         context = JAXBContext.newInstance("test.jaxb1.shiporder");
         Unmarshaller unmarshaller = context.createUnmarshaller();
         Shiporder order = (Shiporder)unmarshaller.unmarshal(new File("testorder.xml"));
         System.out.println("Items included in order #"+order.getOrderid()+" are:");
         
         for (ItemTypeImpl item : (List<ItemTypeImpl>)order.getItem()) {
            System.out.println("\t:. "+item.getTitle()+" - "+
               item.getQuantity()+" item(s) at $"+item.getPrice()+" each");
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}


Making a long story short, the "magic" performed by the Unmarshaller is basically to parse the XML using the classes generated by the JAXB compiler to map its entire content into memory. It's just like using a DOM parser to load the XML's DOM tree into memory. The advantage here is that the names, attributes and methods in JAXB generated objects strictly reflect the XML's structure defined by its schema making it much easier and more intuitive to work with them instead of a pure DOM tree. Running the test above, the outcome should be:

Click to enlarge

Quite easy. You'd probably think: Well... I'm ok with that. It's easy enough already. The question is: is that so??? NOT!!!

Now I will repeat the same test case described above only upgrading from JAXB 1.0 to JAXB 2.0. First, we'll need to get a working implementation of JAXB 2.0. I recommend Sun's reference implementation which can be downloaded here (at the time I was writing this post, version 2.1.6 was the latest one). Just follow the instructions in that page to install it correctly and notice the bin subdirectory containing some scripts, including "xjc.bat" (for Windows; "xjc.sh" for Unix). This is the script supplied to execute JAXB 2.0 compilation. The trick here is to embed it in JDeveloper as an "External Tool". I'll show you how to do that step-by-step:

  1. Click the menu item "Tools -> External Tools..."

  2. Press the "New..." button to start the "Create External Tool" wizard

  3. Select "External Program" as the "Tool Type" and press "Next"

  4. Fill the 3 displayed fields as follows:

    • Program Executable:
      full path to the script "xjc.bat" which sould be <Sun_JAXB_2.1.6_install_dir>/bin/xjc.bat (or "xjc.sh" on Unix)

    • Arguments:
      -d "${project.first.sourcepath}" -p ${promptl:label=Target Package Name} "${file.path}".

      Press button "Insert..." to see all macros available (i.e.: ${file.path}).

      The arguments above will be passed to the script "xjc.bat". Execute it with no arguments in a command prompt to see a help on all possible arguments. The default is to compile a XML Schema but you can use -dtd to compile a DTD instead, although it's an experimental feature.

    • Run Directory:
      <Sun_JAXB_2.1.6_install_dir>/bin


  5. Press "Next" to advance to "Display" step and fill the 3 fields as you like. I suggest the following:

    • Caption for Menu Items:
      Compile XML Schema with JAXB 2.0

    • ToolTip Text:
      Compile a XML Schema with JAXB 2.0 Reference Implementation by Sun Microsystems

    • ToolTip Text:
      ide.fileicon:<SUN_JAXB_2.1.6_install_dir>/bin/xjc.bat


  6. Press "Next" to advance to "Integration" step where I recommend selecting "Tools Menu" and "Navigator Context Menu"

  7. Press "Next" to advance to the final step "Availability". Here, I recommend choosing the option "When Specific File Types are Selected" and then move only the item "XML Schema Type" from list "Available Types" to list "Selected Types"

  8. Press "Finish" and done!
Now we have the same built-in "JAXB Compilation" functionality described before but now using Sun's JAXB 2.1.6. So, let's repeat the same test case using our new tool.

First, create a new empty project called "JAXB 2.0" also adding only "XML" to its technology scope.

We'll need to create a JAXB 2.0 library and add it to the project:

Click to enlarge

The important here is to add the following archives, located in directory <Sun_JAXB_2.0_install_dir>/lib, to the library's class path: jaxb-api.jar, jaxb-impl.jar and jsr173_1.0_api.jar.

Now just copy files "shiporder.xsd" and "testorder.xml" from project "JAXB 1.0" to this new project's root directory. Also be sure that the sources directory configured for the project exists and, if it doesn't, create it manually. That's needed because Sun's JAXB 2.1.6 compiler won't create its output directory automatically and the process will fail if that directory doesn't exist. Finally, select file "shiporder.xsd" in the Applications Navigator and execute our newly created menu item "Tools -> Compile XML Schema with JAXB 2.0"

Click to enlarge

Define "test.jaxb2.shiporder" as the "Target Package Name" when prompted. After execution, you should see the following output:

Click to enlarge

Just click the "Refresh" button on the Applications Navigator and the new package "test.jaxb2.shiporder" will appear. At this point we can already make a simple comparison:

Click to enlarge

As you can see, instead of generating 16 interfaces, 15 classes and 1 property file, JAXB 2.0 generated only 4 classes! And like it was not enough, if you look inside those 4 classes you'll notice that they are all very simple POJOs!!!

Take class "Shiporder.java" for example:

//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.5-b01-fcs 
// See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
// Any modifications to this file will be lost upon recompilation of the source schema. 
// Generated on: 2008.01.09 at 12:41:26 PM BRST 
//

package test.jaxb2.shiporder;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for anonymous complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * &lt;complexType>
 *   &lt;complexContent>
 *     &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       &lt;sequence>
 *         &lt;element ref="{}orderperson"/>
 *         &lt;element ref="{}shipto"/>
 *         &lt;element ref="{}item" maxOccurs="unbounded"/>
 *       &lt;/sequence>
 *       &lt;attribute ref="{}orderid use="required""/>
 *     &lt;/restriction>
 *   &lt;/complexContent>
 * &lt;/complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "orderperson",
    "shipto",
    "item"
})
@XmlRootElement(name = "shiporder")
public class Shiporder {

    @XmlElement(required = true)
    protected String orderperson;
    @XmlElement(required = true)
    protected Shipto shipto;
    @XmlElement(required = true)
    protected List<Item> item;
    @XmlAttribute(required = true)
    protected String orderid;

    /**
     * Gets the value of the orderperson property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getOrderperson() {
        return orderperson;
    }

    /**
     * Sets the value of the orderperson property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setOrderperson(String value) {
        this.orderperson = value;
    }

    /**
     * Gets the value of the shipto property.
     * 
     * @return
     *     possible object is
     *     {@link Shipto }
     *     
     */
    public Shipto getShipto() {
        return shipto;
    }

    /**
     * Sets the value of the shipto property.
     * 
     * @param value
     *     allowed object is
     *     {@link Shipto }
     *     
     */
    public void setShipto(Shipto value) {
        this.shipto = value;
    }

    /**
     * Gets the value of the item property.
     * 
     * <p>
     * This accessor method returns a reference to the live list,
     * not a snapshot. Therefore any modification you make to the
     * returned list will be present inside the JAXB object.
     * This is why there is not a <CODE>set</CODE> method for the item property.
     * 
     * <p>
     * For example, to add a new item, do as follows:
     * <pre>
     *    getItem().add(newItem);
     * </pre>
     * 
     * 
     * <p>
     * Objects of the following type(s) are allowed in the list
     * {@link Item }
     * 
     * 
     */
    public List<Item> getItem() {
        if (item == null) {
            item = new ArrayList<Item>();
        }
        return this.item;
    }

    /**
     * Gets the value of the orderid property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getOrderid() {
        return orderid;
    }

    /**
     * Sets the value of the orderid property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setOrderid(String value) {
        this.orderid = value;
    }
}


"public class Shiporder {". No interfaces being implemented, no classes being extended at all. Only a simple JavaBean with its attributes and their respective accessors. The "magic" here is done thanks to the annotations. They perform the actual mapping between the XML's structure defined by the compiled XML Schema and the classes derived from that compilation process.

I think it's pretty obvious to see the huge advantages of JAXB 2.0 when compared to version 1.0. The compilation of a XML Schema produces much fewer classes and those classes are simply annotated POJOs. This certainly implies a much faster, lighter and easier to understand XML binding.

Besides, there are some other details that makes JAXB 2.0 even more beneficial. Javadocs are automatically generated, it relies on cutting-edge XML parsing technology called "Streaming API for XML" which basically gives much more precise control over XML document processing. For further info on this, read "Oracle StAX Pull Parser Preview" and "JSR#173 homepage". Finally, as opposed to the known limitations of JDeveloper's built-in JAXB 1.0 compiler, Sun's JAXB 2.1.6 supports:

  • Javadoc generation

  • The key and keyref features of XML Schema

  • The List and Union features of XML Schema

  • SimpleType mapping to TypeSafe Enum class and IsSet property modifier

  • XML Schema component "any" and substitution groups

  • Customization of XML Schema to override the default binding of XML Schema components

  • On-demand validation of content based on a given Schema

To run the same unmarshalling test, just create class "test.jaxb2.TestJAXB2" as follows:

package test.jaxb2;

import java.io.File;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;
import test.jaxb2.shiporder.Item;
import test.jaxb2.shiporder.Shiporder;

public class TestJAXB2 {

   public static void main(String[] args) {
      try {
         JAXBContext context = JAXBContext.newInstance("test.jaxb2.shiporder");
         Unmarshaller unmarshaller = context.createUnmarshaller();
         Shiporder order = (Shiporder)unmarshaller.unmarshal(new File("testorder.xml"));
         System.out.println("Items included in order #"+order.getOrderid()+" are:");
         
         for (Item item : order.getItem()) {
            System.out.println("\t:. "+item.getTitle()+" - "+
               item.getQuantity()+" item(s) at $"+item.getPrice()+" each");
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}


This is slightly different from class "test.jaxb1.TestJAXB1" but, after running it, you should see exactly the same outcome:

Click to enlarge

Well, that's it. I think I've made my point. So good luck in your JAXB 2.0 adventures!