logoStashPNGI was having a problem where Stash (which was installed as a service) wasn’t starting up properly and giving me a page that made it look like there was a problem with the database.

I have a local MySQL on the same machine as the Stash server, and both that service and the Stash server are set to automatically start up. Continue reading

I needed to convert an existing Netbeans build to use Maven in order to stabilize the code and support Test Driven Development.

Generally this was a fairly simple process: just move all the source files and resources to the right folders in a new Maven project, and add the dependencies.

Everything was going swimmingly until I ran my first tests and got this really lovely set of errors that didn’t really tell me what was going on:

Now at this point I normally just do a few Google searches and find out how somebody else has solved this problem, but I really wasn’t having any luck at all finding an answer.

I did run across a couple of posts that mentioned seeing this error when using multiple persistence units in the persistence.xml.

Now my project does have a persistence unit for testing outside GlassFish (my chosen EJB container), so my first thought was to move that PU to the “right” place for my tests. So I copied the persistence.xml from src/main/resources/META-INF to the src/test/resources/META-INF and changed them so there was only one PU in each.

Well, that seemed to work for a minute, no more exception on the compile step. But now I had a new problem: I was getting an error that the PU couldn’t be found:

Tests in error:
testinsertTrackingCustomerUnFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingWithoutCustomerUnFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingCustomerFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingWithoutCustomerFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU

So doing a bit of digging, it appears that the persistence.xml only gets copied once and only from the src/main/resources/META-INF folder.

I must have tried a thousand different permutations and combinations until I realized that I could have an ugly workaround that is not ideal.

The issue is that if both have the “exclude-unlisted-classes” set to true, the javac compiler tries to recreate the annotation classes during the compiler:compile and of course fails on the second PU because the classes have already been created.

So to get this to work, I set the “exclude-unlisted-classes” to false for one of the PU’s, which gets me the generated meta classes, and the tests fail (because the PU doesn’t include the required entities).

I then flip the flag back to true, and run the build again. Since the classes have already been compiled, the compile:compile doesn’t run, and the tests can succeed.

And then finally, I run across a bug report on the NetBeans site: http://netbeans.org/bugzilla/show_bug.cgi?id=183779. Now this bug talked about setting some compiler flags (in particular -proc:none which tells the compiler not to generate meta classes).

Workaround was proc:none to the javac compiler args as described here: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html

Now my Maven build works like a charm. Both persistence units are defined in my persistence.xml, and both have the “exclude-unlisted-classes” set to false, and not only do my tests work, but the deployment is now successful as well.

After getting my new Mac Mini pretty well set up with my development tools, I started playing with Amazon AWS. When trying to connect to one of my instances using their built in tool, Firefox bailed and I was presented with a prompt asking me if I wanted to install Java:

To open “Firefox,” you need a Java SE 6 runtime. Would you like to install one now?

Now this message looked very official, and I’d seen it before when starting up something on a new Mac that required Java, but since I’d already installed the latest JDK I was thoroughly confused. I thought, “OK, maybe you didn’t install Java after all”

So I popped open a terminal and

mini:~ robweaver$ java -version
java version “1.7.0_09″
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode.

OK, so that’s not it – so I changed browsers and tried the browser check at http://javatester.org again, only to get the same results …

Ouch – so I dug around a bit, and couldn’t find anything about how to fix it. And in fact the little bit I did find only confirmed that the browser plugin was active and the right version.

So finally I decided to punt and just let it install – Clicking the button to to let it start ran a package that looked like it was installing something, and when it was done another trip to javatester.org showed that somehow the plugin had been fixed and was now giving me the right version of Java in all my browsers.

Java Version tester

The only thing I can guess is that there was something that had to be set up on first use, but it did give me a start when being asked to install Java SE 6. Fortunately, whatever it did, it didn’t muck with my JVM and I’ll just have to hope that it didn’t break anything elsewhere.


I recently read a post on LinkedIn on the WAFUG group by Andrew Hedges:

Frameworks or libraries?

“Frameworks are larger abstractions than libraries. Abstractions leak, cost performance and take up mental resources.” … http://tr.im/20fm

Is the whole framework craze overkill for most projects? At what point does it make sense to use a framework over libraries that just do what you minimally need? Is it better to start with a large, leaky abstraction or only impose it if/when the project gets big enough to need it?

The answer to this for me is “it depends”, and it’s what keeps architects up at night. Frameworks are usually attempts to encapsulate some best practice or design patterns in a way that will help the developer achieve some gain in productivity, scalability or reliability.

During the dotBomb era, I worked for a small boutique consulting company designing web sites for a lot of startups. All of them were convinced they would be the next big thing, and most of them had extremely aggressive targets for scalability.

Because of this, we spent quite a bit of time with various frameworks trying to understand the balance between the complexity introduced and the scalability that the framework would give us. At the time, Sun was busy pushing the EJB framework, which was a study in how to over-engineer software. The big benefit promised by EJB was that you could theoretically scale your application to infinity and beyond. The downside was that it basically took a huge team of rocket scientists to get off the ground (this was not the nice simple POJO based EJB of today).

What we found was that in most cases, we could get the same sort of scalability for our clients out of simple Model 2 JSP based applications (MVC approach) by taking care to design the application from the database forward. By using the database for what it is really good at (caching, storing and reading data), building DAOs to interact with the database, and factoring the business logic out of the JSP’s, we were able to build a reliable MVC framework that we used with many clients. The framework was very similar to Struts, which didn’t yet exist, and which we started using once Struts2 was released.

Turns out that the amount of traffic that you have to experience to require the overhead of a complex framework like EJBs is not realistic for any but a handful of web sites.

Fundamentally as an architect, it’s my job to figure out what the real problem is, to solve that in a way that will answer the business need (immediately),  and to build it in a way that will allow for some level of deviation from today’s needs (future scalability and flexibility). So for almost every case that we came across, there was too much complexity and overhead in the EJB framework to make adoption a valid choice back then. Not only did an EJB design require significantly more developer work than the alternatives (making it more costly and harder to change), the initial application wouldn’t perform as well (since it was burdened with all the code that was required to make it scale seamlessly).

All of that said, EJB is also a great study in how a framework can be improved. With the current value proposition of EJB3, the objections that were so clear before have gone away: it no longer takes a rocket scientist to engineer EJBs, and in fact any complexity is fairly well hidden from the developer. Most of the overhead of the framework has been moved into the run-time, so it scales much more appropriately.

As an architect, my decision becomes much easier to include a framework like EJBs when it both saves development time, and gives me a clean and simple path to change. There’s always a balancing act between the time to market, and anticipated change in the application too. I worked on some applications that used MS Access or Domino to get off the ground quickly because when used as a framework those applications are great RAD tools. You can prototype and get to the 95% level of usability for an application very quickly, and for many apps this is better than good enough.

The problem with these (as with almost any framework) is when you get to the point you need to do something that the framework wasn’t designed for. You built a killer app in Access, and now you want to roll it out to the entire company. Well, even though Access claims to work for multiple users, turns out it is a pain, and uses some very archaic methods for things like sharing the database. And even if you reengineer it to store your data in an enterprise DB, it still has the problem of needing to be deployed somewhere or being shared (which again runs you into the locking and corruption problems).

Every problem requires thought and some knowledge of the limitations of the tools in your tool box. By understanding the business problem, and coming to a reasonable understanding of what sorts of changes you can anticipate (including unanticipated ones), you can choose the right level of complexity to solve the problem for today and tomorrow.