Using Perf4J with Logback
Perf4J is a great framework for performance logging. It's non-intrusive and really fills the need for accurate performance logging. But despite the fact it supports SLF4J, Logback support is somewhat lacking. Log4J on the other hand has some great appenders for aggregate performance logging and graphing.
I'm a real fan of Logback, so it was a bit of a disappointment that those appenders weren't available for my favorite logging framework. According to the mailinglists and JIRA issues, it should be easy to create a Logback appender, so I got to work.
Luckily, Perf4J has a generic implementation which can be wrapped to be used with any logging framework, a great starting point. After a round of cursing at the screen, I got a working solution. And I learned something I didn't know about Logback appenders: the stop method is never called. Ever. Good one, guys. You need to provide your own shutdown hook in the start method to handle the stopping of your appender. Anyway, it was an easy fix, but kind of defeats the purpose of the lifecycle, which is supposed to handle that stuff.
Ensuring transaction safety when using the MySQL/JPA+Hibernate/Spring mix
When using JPA, using transactions is something one might take for granted. However, when you're using MySQL and you're not in control of the database, you may find yourself debugging a really hard bug: transactions that aren't properly rolled back.
Switching from C3P0 to BoneCP: mind the numbers…
Now and then you want to hit yourself. Or shoot yourself in the head. Like I did today.
Recently, we've been experimenting with BoneCP. Mainly because C3P0 isn't really Java 6 compatible anymore, but also because I like the multithreaded nature of BoneCP. Alas, I forgot to do one thing when switching to BoneCP: look at the documentation of the configuration options. See, C3P0 has timing for idle checks, database checks and so on... When I switched to BoneCP, I just reused those timings, since they worked nicely for the setup we're using.
The catch? Well... C3P0 uses second or millisecond timings, BoneCP uses minute timings. Ouch. So what did we learn today? Measure and read, don't assume. I for one won't make this mistake again.
Propagating security through Spring’s HttpInvoker service export
I've been looking into securing my HttpInvoker exported services lately, and I feel that the current Spring reference falls a bit short when it comes to integrating security into HttpInvoker. They'll point you to AuthenticationSimpleHttpInvokerRequestExecutor, which adds basic authentication to your HttpInvoker calls. You'll then have to use the DelegatingFilterProxy to secure your services on the server side.
But what if you already have your SecurityContext on the client side, say for example in a Spring Rich Client application? It would cause a lot of overhead, as each call will retrieve the security context for the user (which you already have). In comes ContextPropagatingRemoteInvocationFactory. This class is normally used in the RMI exporter context, but suits my use case rather nicely. It put the current security context on the client in the invocation object, and when the invocation is executed on the server, it first sets the current security context (which will normally be thread local) to the enclosed security context.
As HttpInvoker is a Spring specific approach to service remoting, I don't really see any problem with this approach. It's not like someone is going to call a HttpInvoker service by hand (it can be done), and even then they still have to be able to correctly set the security context inside the call. In short, if your web API can be called outside of a Spring context or through Spring without a known SecurityContext (but with a username and password), use DelegatingFilterProxy to secure your remote services. Otherwise use the ContextPropagatingRemoteInvocationFactory. It's so much easier to set up.
Is an OSS project viable with corporate support?
Being a project lead for an open-source project, Spring Rich Client, a lot of times things don't get done due to either manpower shortage or time shortage. Despite wearing the Spring name, we're not a part of SpringSource and as such, don't have the manpower to do all the things we want to do with the framework. Which brings me to the following question: if there isn't a company that has a stake in the survival of the framework, or that generates revenue merely due to the fact the framework exists, is such a framework viable? Just to soothen any panic attacks such a question may provoke within the Spring RCP ranks, I'm not talking about Spring RCP in particular (although there is some relevance to it).
If you look at open-source projects such as Hibernate, JBoss AS, the Spring framework, Guice, ..., you're able to spot a trend: every popular framework has a company behind it with dedicated people, and that generates money on that framework (professional services, consulting, ...). Come to think of it, I can't really think of a succesful open-source project that isn't existing in this format.
I think the right statement here would be that every open-source project is created thanks to all the world-changers out there. But at some point, you need corporate support and a big name behind your framework, or no-one is going to use it. There are plenty of examples out there. Wicket, for example, started out as a SourceForge project and has been adopted by Apache. Result: Wicket is one of the most popular frameworks out there. Who of you have ever heard of jZeno, Sombrero or Jaffa? Here's a hint: they are (or were) all open source web frameworks.
This is one of the most frustrating parts of being an open-source project lead: knowing that your framework is being used more than you'd ever imagined, but getting zero feedback from the companies that generate income due to that framework's existence. Let's take Spring RCP for example. I know for a fact that there are companies out there that are using, and even relying on, Spring RCP. How do I know? I've either gotten questions from them (I'll get back on that in a second), or I just happen to work with them on a project.
Another frustration is some of the questions I get. Sometimes I put a lot of effort in giving an extensive answer, but if someone finds a solution to a general problem, they don't share that solution to the general public. IP stuff, you know. For all I care, IP shouldn't count when using an open source project. You've already committed time to solving the issue, putting it in the framework is only a small effort. Just look at the amount of open-source project forks existing in company repositories... Sometimes one might get depressed.
Perhaps a new license should be created: if you're using an non-corporate backed open source project as a baseline for corporate development, why not donate 1 percent of that project revenue (or budget) to that open source project, say for the first 3 projects you're doing. By the time you're doing the 4th, the funds donated have been put to good use (a new release, possibly dedicated developers, a move to professional project hosting,...) and your company is reaping the benefits from the donations. Due to the donations and the added quality due to those donations, it's even possible that project gets picked up by a company willing to invest in it.
The only problem is see here is greed. It only takes one greedy OSS project lead, not using the received funds to help his project, to tear down the system. But then again, I'm the world-changing type. Perhaps it'll work.
Implementing the Circuit Breaker pattern in Spring with AOP
This is one of my earlier articles
Intro
Most of you are probably wondering right now what a circuit breaker is. Well, it's a pattern I picked up while reading Release It!, a Pragmatic Bookshelf jewel. For those of you who haven't read this book yet, go to the bookstore and get it. It's one of my favorites and it has helped me to become a better developer.
Quoting the book, a circuit breaker 'is a component designed to fail first, thereby controlling the overall failure mode' . Put shortly, it allows you to circumvent a certain subsystem when that subsystem is not healthy.
It can be a very handy component when your system is communicating with several outside systems. When a certain system is failing over and over, you probably don't want your system to keep trying, hoping it will go up again. Using a circuit breaker, you can stop your system, failing fast and more importantly, gracefully.
Combining Liquibase with Spring and JPA
Managing change on source code is easy. Managing change on database schemas is less so. Especially if your application can be used across many database backend (Oracle, MySQL, SQL Server, ...).
Liquibase provides a database agnostic way of managing changes to a database structure. It uses an XML format which contains various changesets for all the changes made to a schema. Ideally, you'll have a changeset per atomic change (adding a column, creating a table, changing an index,...). The beauty of Liquibase is that the database itself is aware about its state. Liquibase implants a versioning table into your schema and uses this table to do the necessary updating.
When using it in combination with Spring and JPA, there are some things you do need to look out for. First of all, the Spring support for Liquibase isn't very big. There's an initiializing bean that updates a schema based on a changelog xml, but that's about it. For example, I wanted to change the names of the tables Liquibase creates for its versioning. The Spring class in Liquibase does not support this feature. Luckily, using the Spring support in Liquibase as a baseline, it's not that hard.
Hibernate Search, JPA and DBUnit
Currently I'm doing a project involving HIbernate Search and JPA. As any good programmer would do, there is a battery of unit tests (better term here is integration tests) for testing my services. To get some managed test data into the database, I'm also using DBUnit.
This combination works perfectly until you start using Hibernate Search and JPA. For example, Lucene (the full text engine behind Search) will only index entities persisted through the entity manager. Since you're loading the data through DBUnit, Lucene won't index any entities. Result: full text searches won't work. Luckily, the solution is quite simple. I'm also using Spring and my DBUnit dataset is already being loaded by the context. The reason for this I explained in the previous post. This gave me the idea to build another class specifically for re-indexing purposes. So I came up with this.
DBUnit, JUnit4 and Spring
Using JUnit with DBUnit is bliss for anyone doing database integration tests. Having a reproducible dataset in your database is vital for writing good integration tests. The problem is, using DBUnit effectively with JUnit 4's annotation based unit testing and Spring can be a pain.
Say you want to have the following:
- load the database once per testcase (not per test, as all your tests rollback the changes they do)
- use the datasource defined in your spring context with DBUnit
Can't that hard, can it?
Don’t forget about C3P0
Using Hibernate is a breeze. You can find numerous tutorials, blog entries and a extensive manual on the net. However, that last item is something people only tend to look at when things go awry and you don't have a clue why. As I had with a MySQL problem recently.
It's a little known fact that the JDBC driver MySQL provides drops connections after being idle for 8 hours. Granted, it can be solved easily by providing a simple parameter on the JDBC url to reconnect when this happens, but it's often overlooked (and not really recommended, as it doesn't really promote safe programming). Another thing easily overlooked is the default pool Hibernate uses for its connections. This pool is, as the manual clearly warns, very basic and doesn't do any clean-up when it comes to idle connections. The result is, after 8 hours of inactivity, your Hibernate application will grind to a halt and only a restart will fix the problem.
Recent Posts
Categories
- Frameworks (10)
- General programming (7)
- Java SE (2)
- Maven (4)
- Security (1)
- Spring (4)
- Spring RCP (1)
- Swing (5)
- Testing (4)
- Uncategorized (7)
- Web services (2)
Archives
- August 2010 (2)
- July 2010 (1)
- June 2010 (4)
- April 2010 (3)
- March 2010 (5)
- February 2010 (3)
- January 2010 (2)
- December 2009 (1)
- October 2009 (8)
- September 2009 (3)
