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.

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 no 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.

Please Use the Stripes Framework

I’ve use Struts and played with Spring.   Stripes is so much easier.  It takes Java EE and makes it almost as fun as using something like Ruby on Rails.  It is annotations over configuration framework, which may take a little getting used to, but once you’re into it you just sail right along into programming heaven.

I’m just a Regular Average Java Programmer (RAJP), so I can’t give you a technical point by point on why to use Stripes.  I’ll leave that to the experts.  Stripes:  A successful first project

But here’s the way I look at it.  Stripes is focused on one thing:  request plumbing.

It takes a GET or a POST and sends it to the right Action Bean (controller) and to the right event (Action Bean method).  The Action Bean does stuff with the data and then chooses a view.    It maps data from the model to the view and it maps data from the view into the model.  And then it give you really cool little helpers like validation, layout managers, and interceptors to handle cross-cutting concerns like, say, security.

It does not persist data.  It says, “Hey, there’s lot’s of cool ways to handle data.  That’s not our job.  Do it how ever you want to.”  (see EJB and JPA and DAO/Transfer Object, Stored Procedures, and such).

It does not (like JSF) give you fancy view components for building web pages.  It says ,”Hey, there’s all kinds of cool stuff that web developers use like HTML, JSP, CSS, and Javascript.  Have fun!”

It does not handle dependency injection.  It says “Hey! There’s these things called EJBs and Spring Beans that do DI really well.  Give them a try!”

It’s light-weight and focused on wiring things together without a bunch of XML.  It’s goal is to handle all of the wiring for data binding and navigation (much like Ruby on Rails) in order to free you up to build your system.

I use it with JSP, JPA and EJBs.  One guy on my team uses Spring Beans instead of EJBs.  One gal on my team uses JDBC DAO and Stored procedures instead of JPA.  If you like, you could use a different view framework like FreeMarker.  Stripes doesn’t care.  It plays well with others.

The more I use it, the better I like it.  It has never disappointed!

Please use Stripes.  We’re a small, but very satisfied community.  More people should be using it.

How do I change the JDK home for Netbeans?

I recently upgraded my JDK and I started getting this message when I launched Netbeans.

Cannot locate java installation in specified jdkhome: [some outdated path].  Do you want to try to use default version?

I’m capable of ignoring messages like this for months, but when I tried to start a new Maven web application, it balked.  It’s simple enough to fix, but it wasn’t obvious to me.  So here you go.

Step One

In your Netbeans home directory (for example, C:\Program Files\NetBeans 7.0.1), open up the netbeans.conf in the etc directory (C:\Program Files\NetBeans 7.0.1\etc\netbeans.conf).

Step Two

Theres a property called netbeans_jdkhome.  Change the value to match the JDK you want Netbeans to use (for example, C:\Program Files\Java\jdk1.6.0_25).

Step Three

Save your changes

Step Four

Restart Netbeans

Recant: Scalable.DEFINITION != Elastic.DEFINITION

In my earlier post, That’s Right Oracle…, I stated that

What we used to call scalable is now called “elastic”

Ok, so it turns out that’s not exactly true.   Scalable and elastic should always go hand in hand when describing the properties of a Cloud architecture, but the term elastic emphasizes a more efficient tempering of the scale.

Gartner gives an excellent summary:

Scalable and Elastic: The service can scale capacity up or down as the consumer demands at the speed of full automation (which may be seconds for some services and hours for others). Elasticity is a trait of shared pools of resources. Scalability is a feature of the underlying infrastructure and software platforms. Elasticity is associated with not only scale but also an economic model that enables scaling in both directions in an automated fashion. This means that services scale on demand to add or remove resources as needed.

However!!!  You buzzword-dropping execs are not off the hook here!  You’re not impressing anyone!  😉  Consider speaking with you’re own words once and a while.  I know that creating a buzz is good for business.  You can make something out of nothing with a powerful enough word.  

 

Java 7 (2011) and Java 8 (2012)- “Let’s get the platform moving again.”

Lest there be any doubt of Oracle’s commitment to the Java SE core, Mark Reinholt shared the previously TOP-SECRET projections for future Java SE releases. He shared his wishlist of core language enhancements which I’m quite sure some other blogger (most likely a JE…Java Expert) will cover ad nauseum (thank you, by the way, whomever you are, that will be awesome).  I look forward to be as confused about Lambda’s as I was about Generics.

The reason I am excited, is that I don’t want to believe that Java is becoming a legacy platform…like my first two platforms did (COBOL and Powerbuilder).   I’m sensing a willingness from Oracle to take some bold moves to bring Java into the 21st century of coding innovation.

Bravo!