org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency

Learning Spring MVC has been challenging for me.  I’ve encountered many problems along the way.  The error in the title is a problem I’ve encountered several times for several reasons many of which have been mentioned in sites like Stack Overflow, but not all.

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency

This means that upon attempting to inject a spring component, no implementation was found.  Here are the reasons why this can happen.

No Implementation

The first reason is the most fundamental:  you didn’t bother building the implementation class.  You built the interface, autowired it, but never created a class which implements the Service, Component, or Repository interfaces you’ve built.

You must build a class which has the code “implements MyRepository” and implements all of it’s methods.  Then you must annotate it with, for example, @Repository.

No Annotations

Speaking of annotations.  A common cause of this error is that you’ve implemented the interfaces but you haven’t configured them.  A controller should have @Controller at the Class signature.  The service should have @Service or @Component.  The Repository should have @Repository or @Component.  These are hints to the Spring base scanner to load them when the server starts up.

No Scanner

Spring needs to know where to look for your Spring implementations.  You’ll have a file called [mydispatcherservlet]-servlet.xml.   In it, you must have the following:

This signals to Spring that the components are in com.mycompany.customer or it’s child packages.

Scanner base-package not catching spring components

You may have the component scanner, but your base package may not include all of your components.  For example, you might have a repostory in com.mycompany.customer.repository, but your scan package might be com.mycompany.customer.controller.  It will find the controller, but not the repository.

Another App Causing the Error

This is the one which I spent several hours debugging.  It’s not common, and you won’t find it listed on other sites because it’s not a Spring specific issue, it is an app server/servlet container issue.

I’m using Tomcat with Eclipse.  In Eclipse, you can add or remove your web projects to the Tomcat server, but there may be other apps in the Tomcat webapps directory which never show up in the Eclipse Tomcat server node.  I was having the above error and I tried all of the above solutions with no luck.  I began to wonder if something else in Tomcat could be spitting out the errors so I removed my app from Tomcat.  I surprised to see that the error continued.

Eventually, though, I looked in the Tomcat webapps directory and found a discarded version of the app.  I deleted it, and the errors ceased.  I redeployed my new version and it was fixed.  Good grief!

Advertisements

Maven Project – statement not supported in -source 1.5

Recently, I was working in a project and I coded a multi-catch statement because…you know…they’re cool.  Multi-catches were introduced in Java 1.7 and are not therefore supported with a compiler below 1.7.  Duh-doy!  But I’ve got it covered, right?  My Eclipse IDE is configured to use a 1.8 JDK.  My project is configured to compile with 1.8.  So why am I getting this message?

multi-catch statement is not supported in -source 1.5
(use -source 7 or higher to enable multi-catch statement)

I’ve been using maven with eclipse for 4 years and I’ve never run into this problem because a certain bit of config was always there and I didn’t know it. I found this statement at maven.apache.org

Also note that at present the default source setting is 1.5 and the default target setting is 1.5, independently of the JDK you run Maven with. If you want to change these defaults, you should set source and target as described in Setting the -source and -target of the Java Compiler.

This is how independent Maven is.  It doesn’t care a lick about your IDE configuration or your local JDK.  If you do not tell it to compile at a particular version, it will run by default at 1.5.  If you’re having this problem, the solution is very simple.  Add the following text to the plugins tag of  your project pom.xml.

compiler-plugin

<plugin>

<artifactId>maven-compiler-plugin</artifactId>

<version>3.1</version>

<configuration>

<source>1.8</source>

<target>1.8</target>

</configuration>

</plugin

Now you can multi-catch, lambda, and stream with the cool kids!

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.

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.

The Bible on Documentation of Code

Leviticus 19:38

“And to those who have been given the task of writing the code of the Lord, also too shall they be given the labor of documentation. For it was said upon the mountain of the Lord that undocumented code is an abomination unto the eyes of the Lord and it is like a thorn in the foot to those who shall maintain the code by day.  Thus saith the Lord.”

Hezekiah 13:9

“Comments in your code will reveal the thoughts and intents of the program to all who seek the truth”

From the Sermon on the Mount
And Jesus said, “Blessed are those who document their code, for they might inherit the maintenance of their code and will give praise unto the Lord for it’s clarity.”