Add JXDatePicker to the Netbeans Swing Controls Palette

For small Swing applications, I like to use the Netbeans GUI Builder.  The problem is that there is no date picker.  And today, I really needed a date picker.  Fortunately, there is a solution.  Remember SwingX?  It’s built into Netbeans, and it has a good date picker called JXDatePicker.  Here’s how to get it on your Swing Controls palette so that you can drag it onto your form.

By “palette”, I mean the view that pops up on the right side of the IDE when you use the GUI Builder.  Notice that the Swing Controls palette doesn’t have a date picker of any sort (shame on you Netbeans! This is basic stuff!).

The goal is to get JXDatePicker onto that palette.

1.) Pull up the Palette Manager for Swing/AWT Components.

2.)  Click “Add from JAR”

3.) Browse to [NETBEANS HOME]\ide\modules\ext and select swingx-0.9.5.jar

4.)  This will bring up a list of all the components available for the palette.  Lots of goodies here!  Select JXDatePicker.

5.)  Select Swing Controls

It will immediately show up on your Swing Controls palette.  All that’s left is to drag into onto your GUI!

Integrating CA Software Change Manager with a Java EE application

CA’s Software Change Manager is a tool that we use to manage software and documents.  Although much of our development staff is using GIT, many of our engineers still use SCM (or Harvest as it used to be known).  The primary way our web applications use Harvest is as a version controlled repository for documents.  Our web apps can link directly to the latest versions of documents and can even allow our users to checkout and modify documents through the web.  I’d like to share some of the techniques we’ve used to build a relationship between a Java EE application apps and Harvest.

The obvious choice for using Harvest with java is the JHSDK (Java Harvest SDK).  But through trial and error, I’ve learned that JHSDK fails in Java EE because it’s classes are not thread safe.  At the CA World conference a few years ago, I had the privilege of consulting with the father of Harvest (can’t remember his name) about this problem.  He said that I have two options, make the API thread safe or just make system calls to the command line interface (Harvest CLI).  Not knowing exactly how to make the API thread safe, I chose the latter.  It has never failed us.

Things to consider when designing a Harvest-related web app:

1.  The server on which your app server resides must have a Harvest client installed.   You’re essentially creating an automated Harvest user in your web app.

2.  Because you’re using a CLI instead of JHSDK, you have to retrieve errors and exceptions by reading logs.  Each Harvest command creates its own log file on the server.  So you have to manage log files in real time.  We create a new log file with a new random name with every command.  After the command runs, we check the log messages so that we can send the messages (including errors) back to the browser.  And finally, we delete the log file.  This is handled differently for asynchronous calls (see #5).

3.  Each Harvest command must contain user credentials.  When the user logs in, you could capture his/her username and password, but this isn’t very secure.  Ultimately, you want to use an auth file on the server.  This can be generated with a command using the username and password one time and never again (unless the password changes).  You name the auth file after the user name and then you can reference it anytime you need it.  The svrenc command looks like this:

String[] command = new String[11];
int i = 0;
command[i++] = “svrenc”;
command[i++] = “-f”;
command[i++] = userName+”.auth”;
command[i++] = “-usr”;
command[i++] = userName;
command[i++] = “-pw”;
command[i++] = password;
command[i++] = “-dir”;
command[i++] = siService.getAuthRootPath();
command[i++] = “-o”;
command[i++] = log;

4.  Building commands can be error prone if it’s done in one big String.  Fortunately, Java’s Runtime class takes a String array.  It’s best to build your commands this way. (see above example for building a command)

5.  Commands can be run asynchronously for long-running processes by putting the command into a thread.  As the thread runs it writes the progress of the log file output into the database and the client polls it with AJAX calls.  That way you can show progress on the process.

6.  When the user needs to view a file, it’s easier and quicker to use SQL rather than the hco command to get a blob and stream it out to the browser

7.  When the user needs to checkout a file (hci command), you’re checking it out to the server’s file system then streaming a copy of that file back to the web browser.

8.  To check in a file, upload the file through the web browser to the exact spot where it was checked out to, then run the hco command on it.

9.  Finally, use the documentation.  It comes with your installation and is called “CA Software Change Manager Command Line Reference Guide”.  Everything you can do with the SCM client can be done via the CLI, and therefore can be done in a web app.

Integrating your web apps with CA SCM can be a very powerful asset to your users.  We allow users to list, view, and manage files, promote/demote packages, edit forms, create comments, and approve/deny packages.  We had hoped that CA would be a decent web version of SCM, but it never happened, so we built the parts that we need.  We’ve been very successful, and using CLI calls has been very reliable.

Testing Web Services in Glassfish 3

In Glassfish 2, the admin console had a separate node for web services.

Once there you could click on one of the services a get this page

Notice the “Test” button.  That will take you to a page that will allow you to test all of your service operations.  Handy.  But in Glassfish 3, there is no node for web services.  I was dismayed when I found this.  How will I test my service on the server?  No worries.  It’s still there.  It’s just moved, and it takes a few more clicks.

Click on the Applications node and navigate to the web application that contains the web service you want to test.  You’ll find this page detailing the application and it’s modules.

You’ll notice that under the action column you see two rows with links for View Endpoint.  When you click on that link, you will find the link for testing your service.  It’s the same page as in Glassfish 2.  It looks like this.

The result of running your operation is a display of both the SOAP Request and the SOAP Response.

This testing mechanism in Glassfish is invaluable.  Take advantage of it.

For an in depth read on web services in Glassfish, check out Java expert Aran Gupta’s article Creating and Invoking a Web service using GlassFish in NetBeans, IntelliJ, and Eclipse

How Java Control Panel settings blocked my Java Web Start app

Java Web Start is a really handy way of deploying Java client applications through the web.  Often times resources, such as jar files, have to be provided for the app to work.  And if any of those jar files requires access to system resources, then they must be digitally signed.

If any of the jars that need to be signed are not, then the app will not launch.  You will receive the following.

Unable to launch the application

And if you click “Details” you will see which resource was not signed.  ”Found unsigned entry in resource”

This is the error some of my users were receiving when they tried to launch my application.  Not all, but some. All my jars were signed.  I checked.   Upon investigation I learned that a setting in the Java Control Panel was preventing the launch.

You launch the Java Control Panel by clicking the Java icon in the Windows Control Panel.  It looks like this:

The setting that concerns this issue is locating under the Temporary Internet Files>>Settings.

The users that could not launch my application did not have “Keep temporary files on my computer” checked.  After checking it, the app launched properly.  I don’t know exactly why this fixed the problem, but it’s fixed and I’m happy.

Why I don’t use Java Server Faces (JSF)

(WARNING:  This article contains a fair amount of arrogance, bias, and perhaps some ignorance.)

I came into the Java development world ten years ago not knowing anything about basic web development.  I barely knew HTML.  I didn’t know anything about CSS or Javascript.  My customer needed a web developer and I volunteered to leave my Java client development to build Java web apps.   I took classes, went to JavaOne (many times).  But not once did I see anything that looked like a professional web application.  Every example looked like something a middle-school kid built.  Where were the Java web developers who were truly web developers?  I’m sure there are some.  Maybe you are such a programmer.

Then came JSF.  JSF promised to be the answer for Java web developers, who like me, didn’t really know how to do standard web programming.  Implementations like Richfaces, Icefaces, and ADF Faces sprang into being.  And with ADF Faces, we were promised that we could actually build pages with a drag-n-drop interface.  WOW!  Now we could build applications that looked like big boy web applications…without having to learn what the big boys know.  We could even incorporate so-called Web 2.0 elements.  WE   COULD   BE   COOL,  TOO.  Sounds great.

But these are the reasons that I didn’t stick with it:

One:  JSF isn’t easier than standard web programming

JSF promises to make java web development easier and quicker.  But when you get beyond the basics of JSF, it becomes very complex.  The behind-the-scenes is even more complex, and requires an expert to optimize.  Why invest all your time learning a the technology who’s programming interface has very little in common with the standard web toolkit?  Why not just take the plunge and learn the technologies that the JSF framework is working so hard to generate:  HTML, CSS, and Javascript? It’s not that hard.  There are middle schoolers learning to do it just fine. (ok, I admit that there are some middle-schoolers that could kick my ass in web programming)

There’s nothing that you can do in JSF that you can’t do better with a basic MVC framework (like Stripes), a style sheet, and a few JQuery scripts.

Two: At the mercy of the implementation

JSF is extensible.  Theoretically, you can build your own presentation layer components.  I even took a class that showed me how to do it.  But in reality,  I never even attempted it.  I just used the components that were available, and tried to make it work.  But if I wanted to accomplish something that wasn’t covered by the JSF library I was using, I was just screwed.  Even though I’d seen what I wanted in other web applications, I couldn’t always accomplish it with JSF.

Three:  You’re cut off from the rest of the web community

Have trouble finding good support on JSF problems?  How many web developers do you know who actually use JSF or have even heard of it?  The vast majority of web developers code with HTML, CSS, Javacript on top of server side technologies like PHP, Java EE (not including JSF), and .Net.  I would encourage you to consider stepping into the wider community of web development.

Four:  The web is meant to be stateless

HTTP is a stateless protocol.  That means the web is inherently stateless.  If you try to make it stateful, then you’re creating a list of problems that have to be managed (memory, performance, keeping track of the state, keeping data fresh, etc.)  JSF is a stateful technology.  The state is maintained in a tree structure on the server side or the client side for EACH user session.    If you use the client side, you have performance issues passing state back and forth for every request.  If you use the server side to hold state, than you have to manage the memory used on the server.    Perhaps it’s  better to go with the flow and keep the web stateless.

Five:  Be honest.  Are you just using JSF as a crutch?

I used JSF because I was too lazy to learn the standard web toolkit.  I was lured in by the pre-styled, pre-built drop in components.   I wanted to continue using my java client skills.  Java was the only thing I wanted to use because it was the only thing I knew how to do.  I was using JSF as a crutch.  There are good reasons for using JSF, but that is not one of them.

Conclusion

JSF is not all bad.  It has lot’s of good stuff, like data binding, navigation, and validation.  But JSF isn’t the only java framework that does that.  Stripes does it, and does it much easier (as you can tell I really like Stripes).

I know this guy who has been very successful with JSF, but I received a very weird question from him once.  He asked me how to build a basic alphabetical navigation for his page.  I guess RichFaces didn’t have one of those components.  I told him that it just took a little HTML.  He asked me if I could send him some.  I was embarrassed for him.  He had been developing web apps for years.

Don’t be that guy.  Pick up a few books.  Read a few blogs.  Learn how to develop web pages.  Don’t use JSF to avoid learning the web.

Netbeans: Session Beans for Entity Classes

Netbeans really hit a home run when it automated the creation of session beans from entity classes.  It also does a good job creating entity beans.  It’s a win-win (God!  I can’t believe I just wrote the phrase win-win).   It makes good use of the facade design pattern and gives you a service that you can inject into your controller.

Generated Entity Beans

First, let’s talk about what you get when you let Netbeans generate your entity beans.  You might say, “Well Mr. RAJP, I’m perfectly capable of creating my own damn entity beans.”  To which I say “Fiddlesticks.  You’re wasting your employer’s valuable time!”

The entity bean that Netbeans generates gives you everything you need (and perhaps more) just by selecting a table in a list.  Netbeans generated entity bean come with the following features:

1. Declares each field in the table with an estimation of the proper type and annotates maximum sizes, default values,  whether it can take a null value, and whether it is the primary key.
2. It maps all of the database relationships with @OneToMany, @ManyToOne, and @ManyToMany depending on how well you designed your database.
3. It creates a nested array of @NamesQueries searching on each field.
4. It generates all the getters and setters
5. It overrides hashCode() , toString(), and equals()

The only modifications I ever have to make is to add a sequence generator to the primary key and add a few more named queries.

“But David! This is too easy.  Shouldn’t I have to work harder to get my job done?”

“No.  This gives you more time to build your damn system.  Now swallow your pride and code!”

Generated Session Beans for Entity Beans

This is where things get really cool.  For years I’ve been coding a service class, and doing it poorly.  Being a lowly RAJP (Regular Average Java Programmer), I was building a static service of operations to perform on the entity beans.  Basic CRUD plus a few custom business functions.  Did it work?  Yes.  Should I have created some sort of service that could be injected into my controller?  Yes.  Am I too lazy to do anything that cool?  Definitely.

When I upgraded to Netbeans 7.1, and was generating some entity beans, I happened to notice an option to generate “Session Beans for Entity Classes…” in the New menu.  Honestly, I had know idea what this would do.  When I did it though, which was as simple as selecting from a list of entity beans, it gave me something totally cool.  It gave me a set of stateless EJB classes replete with EntityManagers already hooked up to my persistence unit.  But wait!  There’s more!  It gave me a nicely designed AbstractFacade for the EJBs to extend with all the CRUD methods I would need.  It’s so nicely designed, in fact, that it can be extended by any session bean you generated from an entity.  It’s all generical and stuff.

Netbeans got it right!  This is a far better a design than what I could have produced myself.  This is a design worthy of a JE (Java Expert).

The only slightly weird thing is that the session bean never uses the named queries in the entity bean.  It handles all of it’s operations with JPAs CriteriaQuery class.  But that’s just fine with me.  When I need it, I just add another operation to the session bean to call named queries.

Now I have a set EJB facades that I can inject into my controllers.  I use Stripes ActionBean for my controllers, by the way.  It’s a kick ass stack.  JSP, Stripes, EJBs, JPA, Glassfish, and Netbeans.

Netbeans team, you NAILED this down TIGHT! Yessir!

 

Simple Authentication Solution with the Stripes Framework

This security solution will probably not stand up to the scrutiny of a JE (Java Expert), but I’m cool with it.  It’s probably all you’re really looking for.  Something basic and simple.  If you’re new to Stripes check out Stripes Quick Start Guide

The solution requires 4 elements:

1. @DoesNotRequireLogin Annotation
2. Security Interceptor
3. Security Action Bean
4. JSP login form

@DoesNotRequireLogin Annotation

Creating a Java annotation is very simple.  As a RAJP (Regular Average Java Programmer), I was intimidated at first.  What if I’m not smart enough to figure this out?  What will the JEs think?  ARRRG!  Relax.  It’s easy

That’s it.  You have an annotation.  Now let’s see what you can do with it!

Security Interceptor

see Stripes’ documentation on interceptors http://www.stripesframework.org/display/stripes/Intercept+Execution

An interceptor breaks in at a certain stage of the Stripes life cycle.  In this case, we want it to run any time an action is requested so that we can see if the action requires a login.  Then we make a decision.  Either let the request pass through, or do something else.  In this case we’re asking if the Action Bean that is being requested is annotated with @DoesNotRequireLogin.  I set it up that way instead of @RequiresLogin because the only thing that doesn’t require login is the login.  So I annotated that bean with @DoesNotRequireLogin.  Any other bean has to pass the treacherous isLoggedIn method.  Anything that fails this gets returned back to the login screen.  Also notice that we are implementing the Interceptor interface of which the intercept method is required for implementation.

Action Bean

The action bean serves as the controller.  It can be called upon by any page by setting the beanClass property of a form or link.  The @UrlBinding annotation is where you specify why URL will map to this bean.  The default is to go to the login event because it’s annotated with @DefaultResolution.  All this does is forward the request to the login jsp.  The first instance variable is an EJB that handles data access for the login transaction.  The next two are the variables that will be bound to the login form.  The submitLogin method is the event that the login form will call.  Got it?  That was a lot.  You may need to reread and take a closer look at the tiny picture of my code.

Notice that the class has a @DoesNotRequireLogin annotation.  A request to this Action Bean will pass through the security interceptor.  The submitLogin event processes the login form and uses the EJB to decide whether it passes.  If it doesn’t, we add an error message and return the request back to the login screen.  If it passes, it uses the path variable to forward the request on to wherever the user was trying to go in the first place.

Notice the annotations on the userId and password.  This is Stripes super easy way of doing form validations.  It runs the validation before the action event (submitLogin)  is run and will automatically return to your form with errors if they fail.

Finally, you need a logout event.  This returns the loggedIn session attribute back to false and forwards the request back to the login form.  You’ll just need to throw a logout link somewhere in your application.

Login Form

The login page is a very basic login using a handful of Stripes tags.

It’s a little clipped so you don’t see the layout rendering and the closing div and such, but that’s not what’s important here.   I want you to note just a few things.

1. The form uses Stripes tags instead of regular HTML tags.  You tell it what Action Bean to submit the form to (see beanclass in the stripes:form…this is our security action bean), and then you tell it what event should handle it (see the stripes:submit tag name property…this is the submitLogin event in the security action bean)
2. When you use Stripes tags for the inputs, Stripes automagically maps the data input to the instance variables in the Action Bean .  The values of the name attributes have to match the variable names in the action bean (userId and password which have to have getters and setters for it to work).  Pretty handy if you’re used to getting stuff out of the Request and setting them into the variables yourself.
3. Look at the <stripes:errors> tag.  If the security action bean says the login failed or if the input fields don’t pass validation, it forwards the request back to the login screen and displays the errors in the stripes:errors tag.  Simple. Elegant.

That’s it.  Any request that comes into this application will be intercepted by SecurityInterceptor, and if the requested action bean does not have the @DoesNotRequireLogin, it will ask if the person is logged in, etc.  And in our case, the security action bean will be accessed.  It will route the request to the login page.  The form will submit back to the security action bean (and will pass the interceptor) and go straight to the submitLogin event for processing.  If the login should fail, the request will be returned to the login page with an error message that says so; otherwise, it’s on to the application!

Ok, JEs (Java Experts), you’re welcome to cut this into shreds, but the rest of RAJPs are satisfied…at least this one is.