Using the Java Persistence API with a Visual JSF Web Application

I just finished trying out the Using the Java Persistence API with a Visual JSF Web Application tutorial. It’s pretty straightforward and easy to follow. The effect was positive. I was not immediately successful at runtime.

Here’s the problem I encountered:

In the section “Creating a Java Persistence Entity Class Representing the Users Database Table”, either a step was left out, or there was some sort of glitch. This is what my Persistence Units (persistence.xml) screen looked like after I completed this step:


Note that the “Include Entity Classes” box is empty. When you try to run the web app, you get the following error:

Caused by: Exception [TOPLINK-8034] (Oracle TopLink Essentials - 2.0 (Build b58g-fcs (09/07/2007))): oracle.toplink.essentials.exceptions.EJBQLException
Exception Description: Error compiling the query [select c from Users as c]. Unknown abstract schema type [Users].

The solution is to open persistence.xml (Project–>TestModelApp–>Source Packages–>META-INF–>persistence.xml) and click the “Add Class” button. Select com.samples.model.Users. Rebuild. Redeploy.

The JPA design is a bit of an adjustment to me. I’m just getting used to seeing annotations in my beans (for Java Web Services), and now I have to adjust to seeing SQL code. It’s like the Data Access Object(DAO) and the bean are combined in one class. It’s different, but I’m not sure if it is good, bad, or just…well, different. I’m curious about how this will look in more complex data models where one bean may contain references to several other beans as instance variables. Just how many database transactions will it take to build one of these? As I’m writing this, it’s occurring to me that the answer is, “Well, just as many as there would be if you had written the JDBC code yourself, dumbass!”. Perhaps that’s true.

The main thing to take away from this is that

  1. I didn’t use a DataProvider (proprietary to Netbeans)
  2. I was able to bind the Persistence Unit in the visual designer (not drag n drop, but good enough)
  3. My data access (Persistence Units) are reusable
  4. Although I’m not sure if the JPA classes constitute a separate tier, at least they’re kept in a separate Netbeans Project so that they can be freely associated with other applications without duplication.

This is positive. I may even like it.


Some really good Visual Web JSF links

Dr. Winston Prakash is a Senior Staff Engineer at Sun Microsystems and works on Visual Web in Netbeans (formerly known as Project RAVE and Java Studio Creator). I’ve run into 3 really good pages that have this guy’s name on them:

Understanding Netbeans Visual JSF Web Application

This is a great article about what Netbeans Visual JSF does for you in your JSF programming. If you’re already familiar with JSF and you want to understand what Visual JSF is actually doing, then you need to check this out from the Visual Web guru. It gives a basic summary of the technology and it shows details about what code gets generated, what libraries get included, what happens at run time, and understanding the life cycle of a managed bean.

If you are interested in reading the minds of the Visual JSF team to see what you might expect in the future, read this wiki page:

Architectural Changes for Visual Web Next

Reading it is a similar experience to when I was a kid reading the Holiday edition of the Sears catalog and circling the things I wanted from Santa with a crayon. But just as the bold red disclaimer at the top of the wiki page points out, Santa makes NO PROMISES.


And finally, Using the Java Persistence API with a Visual JSF Web Application . I will spend my work day stepping through this tutorial and telling you what I think. It was just one of those golden titles that showed up while I was googling for answers. I haven’t used JPA yet, but I’m sure interested in it. It piqued my interest at both the Javaone and Oracle OpenWorld conferences last year.

Visual Web JSF and data: questions, considerations, thoughts

If you arrived at this blog post hoping to find answers you will be cursing me within the next 30 seconds. This is a post for questions and snarkicism. In evaluating Netbeans Visual Web JSF and Woodstock, I am now turning my attention to data.

This is a touchy issue with me. I am hard-core about separation of concerns. I’m like the kid who will NOT eat the macaroni and cheese if the spinach is touching it! I don’t want any data access code touching my presentation layer!!! NO TOUCHY! This is why I cannot use the primary data binding method in Netbeans: dragging a table to a data control. Sorry. Can’t do it. I did not bust my butt learning java only to return to Powerbuilder-style data binding. Yo! Shoutz to the Powerbuilder Datawindow!! You rocked the 90’s! The Datawindow was one of the greatest software components of all time! But the days of throwing data access, business logic, and presentation into one bucket are gone. Oh, and I’m sure I’ll hear from some of my Powerbuilder friends spouting off about how NVOs (Non-Visual Objects) and Stored Procedures solve these design issues (almost as lame as my Perl friends who spout off about just how Object-Oriented Perl is now…right, like a Perl programmer cares about object-oriented design)…but anyway…I don’t like the idea of binding database tables to GUI components.

Perhaps I’m misunderstanding this whole thing. Perhaps the DataProvider object does constitute a separation of concerns. Perhaps it also promotes reusability. Further research is necessary for me to determine this. All I know at the moment is that the database programmer/DBA wants to back this thing with Oracle Stored Procedures, and you can’t drag a Stored Procedure onto a control. You get three choices (as far as I can tell): Drag a Table, Drag a View, and Drag a Web Service. I don’t see JPA, Beans, EJB, or Stored Procedures. If you want to use those, I guess you need to give up the nifty drag n drop data binding features and code it your damn self!

The following Q&A from an Ask the Experts for Netbeans 6 is relevant to my post:


Michele Giuliano: I’m trying to convert my erp (written in Powerbuilder) in Java using NetBeans 5.5.1 and Visual Web Pack. I have used CachedRowSetXImpl and CachedRowSetDataProvider to manage the da develop with visual web pack. Is it right?


David Botterill: There are really lots of background questions that need to be asked to get the correct answer for this. But, given the information at hand, EJB is a better choice. If you are building an ERP, you will have lots of business logic that needs to live somewhere. If you go from a web client through the visual web dataproviders and CachedRowSet, you really only have a two-tier architecture, (client)-+-(data). In your case, you really need at least one other “middle” tier that contains the business logic for your system. The business logic is the value of your system and needs to be reusable and easily maintainable. This is the purpose for component-based architectures like EJB. You will thus have a (client)-+-(business logic)-+-(data) architecture. This allows you to change out the client while preserving your business logic. You CANNOT capture complex business logic like ERP in data access routines via dataproviders and CacheRowSet. Even the JSF backing beans will not really allow your business logic to remain autonomous since you’ll usually have framework-specific code living there. Another advantage of using this architecture is the ability to use something like Java Persistence API (JPA) on in the data tier and also this will allow you to expose your business logic via web services.

Perhaps I truly can’t bake my cake and eat it, too…at least not yet. This little nugget from the Architectural changes for Visual Web Next gives me hope for the future:

Data binding enhancements

Dataprovider is one of the main mechanism to bind data to the components. Eventhough, dataprovider is nothing but a thin API to support uniform way for the components and DesignTime System to interact, it can be consider proprietary, since it introduces “non standard” API with package name “*” in the source. It may be possible to hide the dataprovider, so that the user need not have to know about the dataprovider externally. This is already accomplished for table component.May in the future, we should

  • Promote Java Persistence API as the main data access mechanism
  • The DesignTime System must be able to bind collection of POJOs to components
  • When database table is drag and drop bind using JPA than CachedRowset
  • Complete designtime support to create Entity Bean and corresponding Controller for binding

Finally, we must get rid of the need for a live database connection even after the table is bound to the component. One solution for this is to use only JPA for binding. If Cachedrowset need to be supported for backward compatibility, then database schema should be persisted in the project for offline access later.

Let’s get busy with this one Netbeans!

Task-Oriented vs. Object-Oriented GUI

I’m reading the excellent resource Sun Web Application Guidelines . I’ve been looking for this kind of resource for years! Love it! In section 5.5, they offer a great suggestion for transitioning an Object-Oriented GUI into a more Task-Oriented GUI. I’ve been interested in this topic for a few years, and I’d like to summarize my thoughts. Keep in mind, I’m not a usability or GUI expert. I’m just a….well, you know the title of my blog…time for a new acronym.

New acronymn:

RAJP – [raj-pee] Regular Average Java Programmer.

As a RAJP, I’m not concerned with breaking new ground or anything, I just want my users to be happy. So here are my thoughts.

[EDIT:  Alas, Sun is no more, and I cannot found this outstanding document anywhere] The difference between Task-Oriented GUI (let’s call it TOG) and Object-Oriented GUI (let’s call it OOG) can be understood by this nifty diagram from Section 5.5 of Sun Web Application Guideline.

An OOG application requires knowledge of the information hierarchy of the system. When you’re navigating an OOG app, you’re navigating the various objects that make up the system (Procurements, Budgets, Purchases Orders, etc.). You kind of have to be a subject matter expert to be successful with an OOG app.

A TOG application relates directly to the tasks that make up your job (Procure Goods, Manage Budget, Make Purchase, etc.). The issue here is that if you have a lot of different kinds of information to manage, then a task list could be overwhelming. Say each domain has an average of five different tasks and you have ten different domains. That’s fifty tasks!

So we break our tasks into groups by domain. But wait! Domains are really a part of the information hierarchy. So we’ve organized our tasks by object domain. In my experience, regular average users think in terms of tasks AND objects. Enter the Common Tasks Page!

“To make existing OO applications into real task-oriented products would take a rebuild from the ground up, based on data from a thorough task analysis of prospective users. However, until products can be rebuilt, a good way to help the user of existing products is to provide a list of tasks and a set of wizards or other means to help perform those tasks. The list of the most common tasks is presented in what is called the Common Tasks page.

The design for the Common Tasks page should be different from other pages in the application (for visual uniqueness and identifiability). The goal is to provide users with quick access to tasks that are supported by key product features. When there are more than a few tasks, the page is divided into sections where functional groups of tasks are separated from each other. For example, functional groups might include configuration and troubleshooting.” – from Section 5.5 of Sun Web Application Guideline

Here’s a super diagram from Sun to illustrate a Common Tasks Page


Note that the Navigation Tree on the left is OOG but the Common Tasks Page is TOG.

I REALLY like this design and will be using it in my prototype regardless of which tools we choose.

Valuable Woodstock Resource

In Undesirable reloads with JSF Tree component, I expressed a little frustration with the lack of documentation about Visual Web JSF. Although Netbeans hasn’t really delivered, Woodstock has. I want to highlight one resource in particular that I anticipate to be very valuable to a regular, average java programmer like me.

Sun Web Application Guidelines – Version 4.0

This was originally intended for Sun apps, but it has been presented a best practices guide for anyone build JSF/Woodstock GUIs.

More later…

BTW, Download Netbeans 6.01 and then new Woodstock 4.2 plugins. Good stuff!

Obstacle #2: Scrolls

I’ve been using the Glassfish Admin Console application as a model for how my prototype looks. It’s built in Woodstock JSF, and I think it is a nice example. I was a little disappointed to find out that they achieved the scroll bar for the Navigation tree with Frames, but it seems to work well.

So my current solution for Scrolls is Frames.

Frames, in fact, are used to layout the entire Glassfish Admin Console application (too decent effect). So my prototype looks almost exactly like the Glassfish app.


Relative Size/Layout of Components

This is listed as Obstacle #4 in my previous post.I can paint a really pretty absolutely positioned and sized GUI in the Design view; however, I would like a relatively positioned and sized GUI in the browser. In particular, I would like for my GUI to fill the browser space and keep nice proportions.

I have a solution, but it is not 100% satisfactory.

For each of the major components (Group Panel, Tree, and Common Tasks Section), I’ve set the height and width style properties to % instead of px. I left the Tree width at absolute width to keep up snug up against the Common Tasks Section

  • Group Panel – 100%, 100%
  • Tree- 100%, 250 px
  • Common Tasks Section – 100%, 80%

So now I get this nice resizable layout in my browser:


But now I’m left with this in the design tab: