Monday, October 20, 2014

Creating a JSON Schema from a POJO

If you're documenting your REST API it might be useful to show the schema definition behind the JSON objects being used.  The JSON Schema format provides a definition similar to XML's XSD.

It isn't very difficult to generate a JSON schema with Jackson.  Given a simple POJO with some properties which includes a list of another simpler POJO:

public class SimplePojo {

 private Integer id;
 private String name;
 private String description;
 private List children;
 // getters and setters ommitted
public class SimplePojoChild {

 private Integer id;
 private String childName;
 private String childDescription;
 // getters and setters ommitted

We can use the Jackson JsonSchema Module to generate the Schema with code similar to this:
public class JsonSchemaGenerator {

 public static void main(String[] args) throws JsonProcessingException {
  ObjectMapper mapper = new ObjectMapper();
        SchemaFactoryWrapper visitor = new SchemaFactoryWrapper();
        mapper.acceptJsonFormatVisitor(SimplePojo.class, visitor);
        JsonSchema schema = visitor.finalSchema();



This code would generate this json schema:
  "type" : "object",
  "id" : "urn:jsonschema:com:bmchild:model:SimplePojo",
  "properties" : {
    "children" : {
      "type" : "array",
      "items" : {
        "type" : "object",
        "id" : "urn:jsonschema:com:bmchild:model:SimplePojoChild",
        "properties" : {
          "cName" : {
            "type" : "string"
          "id" : {
            "type" : "integer"
          "cDescription" : {
            "type" : "string"
    "name" : {
      "type" : "string"
    "description" : {
      "type" : "string"
    "id" : {
      "type" : "integer"

The only downside is if you're using a different version of jackson (we were using one from the codehaus repo) you'll need to change your json annotations so it will print out correctly.

All the code can be found on My Github Account

Tuesday, September 2, 2014

SQL Server: Get Foreign Key Name by Table and Column

I ran across a scenario where I was trying to drop a column that was a foreign key.  When I executed the code to drop it it said there was a dependent object on the column being dropped.  The dependent object was the FK constraint.  So, I need a programatic way of getting the FK constraint name so it could run in our migrations.

The script came from this SO thread.

Monday, August 18, 2014

Splitting a String by Length or Position

Here is a simple method to split a string into a list of substrings based on length.  For example, given the string "12345678901", if we were to split by 2 we would expect a result like {"12", "34", "56", "78", "90", "1"}.

Here is the method and tests:

Thursday, July 17, 2014

CAS Basic Authentication Filter

CAS is a great single sign on(SSO) solution and spring security also includes a lot of helpful classes to implement it in Java apps.  However, getting CAS to use Basic Authentication took some persuading.

It involved creating a new filter that could be placed in front of CAS's spring filter(  But since CAS's filter only redirects to the login screen if a user isn't logged in, we needed to do some authentication before the filter executes so it can do it's thing (like populating UserAuthorities and UserDetails so we can use spring security's annotations like @Secured, etc).

So below is the new basic authentication filter.  It authenticates via CAS's rest web service so that will need to be enabled.  Once it authenticates it "adds" the service ticket to the HttpServletRequest object.  I say "add" because you can't really add a parameter to the request, you have to wrap it in an HttpServletRequestWrapper.  The whole thing kind of feels like a hack, but I couldn't find, or come up with, a better solution.  

Tuesday, July 1, 2014

More Useful Eclipse Templates

I was moving to Eclipse Luna and I realized I didn't export my templates from kepler.  Here are some useful ones, besides the ones I've posted about before.

And for convenience here is an import xml you can use to load all my favorites.

Friday, June 27, 2014

My Journey Into Data Integration. Do you want to go inside?

Many years ago in my teenage years some friends and I acquired some type of audio storytelling game, similar to Dungeons and Dragons. At one point the heroes come to some ominous looking door that you know hides some particular nasties, but is crucial for the story to continue. The narrator in the story then slyly asks the heroes, "Do you want to go inside?" even though he knows they really have no choice.

So it feels with my data integration journey, which really only amounts to really peeking inside the door at this point.  I know life outside the world of data integration isn't possible for the scenarios I'm facing, but when I see all that is required to make it work I start to cringe.

Why Data Integration

So why am I even looking into real time data integration?  I have a couple of reasons.  The one I get most excited about is an event-driven architecture.  The project I'm on has several different ways that data can change so really the only way to know something happened is to listen for data changes.  To do that we can use a technology called Change Data Capture(CDC)  which basically logs what data has changed.  We could then theoretically take that changed data and then send a message through an enterprise service bus (ESB) or some kind of message queue (MQ)  that we could then use to alert services that something happened they should pay attention to.  This would prevent us from hammering the database as we poll for any bad scenarios we want to avoid. 

For example, say you have a truck load of frozen turkeys.  And say you accidentally set the temperature on the trailer to 60 degrees F.  Now 60 degrees is a lot higher than freezing and if you want the turkeys to arrive to their destination frozen the temperature needs to be corrected.  Now modern freight trucks are pretty high tech and report back all sorts of data to their brokers, such as the temperature in their trailers.  So wouldn't it be nice to receive an alert that the temperature is off the second the data is received? Heck yes it would!

A lot of my thinking into this comes from a similar integration described here. But here is the theoretical model I was thinking of:
Another reason that real-time data integration can be very important is as the name suggests. Integrating data from multiple systems into one single data source for easier development and reporting (aka Business Intelligence(BI)).

If you're like me you've found yourself trying to utilize data from multiple data sources.  And if you're like me you've found that trying to merge the data and perform any sort of operation in the application layer to be a real pain in the butt and it takes FOREVER to build it.  So, the way I see it is that we can have the complexity in the application layer or we can have the complexity in the infrastructure.

Something like this:

So the concept seem pretty straight forward.  You simply have three data stores and you only want to query against one.  Easy enough!  But some interesting question and answers came up as we were thinking about this.

Q. How are we going to get data to the consolidated data store?
A. We'll use some CDC tool!
Q. If we use a CDC tool, is the load on our source data stores going to increase?
A.  A little as we'll need to write and read from the change logs, but hopefully it will be offset by moving any monitoring and BI operations to the consolidated store.
Q. Can we turn on CDC logging on our data stores?
A.  Er...we better ask the System Admins/DBAs
Q.  What level of normalization do we want in the consolidated store?
A.  Good question.
Q.  How are we going to save data that is changed by the users?
A.  Well, we could figure out a two way sync and have it save back to the consolidated store or we could write back to the original source and let it propagate through.
Q. Do the CDC tools allow data transformations?
A.  Some do.
Q.  What tools are even out there?
A.  We've come across DBMoto, IBM's Datastage, Oracle's GoldenGate, Talend's enterprise edition, Informatica also has something.
etc. etc.

So far lots of questions and even less answers, but as we open the door wider and wider we're getting some answers.  I just hope that we're not opening a Pandora's box.

Our next steps are evaluating the CDC tools since this seems to be the biggest unknown at this point.  I'll continue writing about our data integration journey and hopefully it doesn't end with the nasties slaying the heroes.  

Thursday, June 12, 2014

Keeping Code Clean

Melissa Weber and I presented this brown bag on keeping code clean.


One of the main hindrances to teams being able to respond rapidly to new features are technical problems resulting from bad coding practices, also known as technical debt. Melissa and Brett will cover Agile tools and practices that help development teams write better code and increase maintainability. Topics that will be covered include:

  •  Pair programming 
  • Automated Unit Testing
  • Refactoring 
  • Test-Driven Development 
  • Agile Architecture