Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...
Sunday, 9 December 2012
Securing your Tomcat app with SSL and Spring Security
If you've seen my last blog, you'll know that I listed ten things that you can do with Spring Security. However, before you start using Spring Security in earnest one of the first things you really must do is to ensure that your web app uses the right transport protocol, which in this case is HTTPS - after all there's no point in having a secure web site if you're going to broadcast your user's passwords all over the internet in plain text. To setup SSL there are three basic steps...
Labels:
Configuration,
HTTPS,
Security,
Spring,
Spring Security,
SSL,
Tomcat,
XML
Saturday, 24 November 2012
Ten Things You Can Do With Spring Security
One
You can specify the authorisation provider of your choice in your Spring XML config file. You do this by configuring an authentication-manager as defined in Spring’s http://www.springframework.org/schema/security/spring-security-3.1.xsd schema. The simplified authentication-manager element definition looks something like this:<xs:element name="authentication-manager"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="authentication-provider"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="security:any-user-service"/> <xs:element name="password-encoder">...</xs:element> </xs:choice> <xs:attributeGroup ref="security:ap.attlist"/> </xs:complexType> </xs:element> <!-- This is BIG --> <xs:element name="ldap-authentication-provider">...</xs:element> </xs:choice> <xs:attributeGroup ref="security:authman.attlist"/> </xs:complexType> </xs:element>
This means that, for example, you can use any number of authentication providers including basic authentication and JDBC authentication as shown in the snippet below:
Labels:
Annotations,
Configuration,
LDAP,
Schema,
Security,
Spring,
Spring Security,
XML,
XSD
Wednesday, 14 November 2012
CaptainDebug Wins an Award
Yes, you heard it here first, I’ve won an award for a program that I’ve written. I can safely say that I’ve never won an award for any program I’ve ever written in my life, in fact this is the only competition in which any of my code has been nominated
What, you may ask what have I won?
What, you may ask what have I won?
Sunday, 11 November 2012
Is Programming the Art of Making the Right Decision?
If you’ve read my previous blog on using Explicit Locking, you may remember that I wrote some sample code that transferred cash between two random bank accounts using the following algorithm:
You may also remember that this was multithreaded code originally written to create a deadlock. In order to demonstrate Explicit Locking’s Lock interface and ReentrantLock implementation I needed to add a thread locking mechanism to my straight-forward Account POJO and so, the question was: how should I do this?
IF fromAccount is locked THEN IF toAccount is locked THEN withDraw money from the fromAccount deposit money into the toAccount END IF END IF
You may also remember that this was multithreaded code originally written to create a deadlock. In order to demonstrate Explicit Locking’s Lock interface and ReentrantLock implementation I needed to add a thread locking mechanism to my straight-forward Account POJO and so, the question was: how should I do this?
Labels:
Aggregation,
Anti-Pattern,
Inheritance,
Java,
Motivation,
Multi-Threading,
MultiThreading,
Object Orientation,
OO,
Pattern
Tuesday, 6 November 2012
Investigating Deadlocks – Part 5: Using Explicit Locking
In my last Investigating Deadlocks blog I looked at fixing my broken, deadlocking balance transfer sample code using both Java’s traditional synchronized keyword and lock ordering. There is, however, an alternative method known as explicit locking.
Explicit locking is based around the Lock interface and its ReentrantLock implementation. Lock contains a bunch of methods that give you lots more control over locking than the traditional synchronized keyword.
The idea here of calling a locking mechanism explicit rather than implicit is that the explicit means that it is not part of the Java language and that classes have been written to fulfill the locking functionality. Implicit locking, on the other hand, can be defined as locking that is part of the language and is implemented in the background using the language keyword synchronchized.
You could argue as to whether or not explicit locking is a good idea. Shouldn’t the Java language be improved to include the features of explicit locking rather than adding yet another set of classes to the already enormous API? For example: trysynchronized().
You could argue as to whether or not explicit locking is a good idea. Shouldn’t the Java language be improved to include the features of explicit locking rather than adding yet another set of classes to the already enormous API? For example: trysynchronized().
Explicit locking is based around the Lock interface and its ReentrantLock implementation. Lock contains a bunch of methods that give you lots more control over locking than the traditional synchronized keyword.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Wednesday, 31 October 2012
Implementing Continuous Delivery is Easy... isn't it?
Last week I saw the following email quite rightly thanking a bunch of developers for their herculean efforts in managing against, the odds, to launch a web app on time for an industry show. It went something like this:
“We've had late nights, all nights, plans A - E, last minute AAARRRGGGHHHs, frantic calls to the server company, web servers going down on launch day, cancelled holidays, tension and early stage Stockholm Syndrome. Yet somehow we did it and are still talking to each other. The following people should stand up and take the applause they justly deserve because it has been a truly amazing effort: Laura, Mo, Sir Chris, Jason, Alistair, Andy, Jess, Victoria, Greg, Ben and Bradley1.”
...and therein lies the problem.
“We've had late nights, all nights, plans A - E, last minute AAARRRGGGHHHs, frantic calls to the server company, web servers going down on launch day, cancelled holidays, tension and early stage Stockholm Syndrome. Yet somehow we did it and are still talking to each other. The following people should stand up and take the applause they justly deserve because it has been a truly amazing effort: Laura, Mo, Sir Chris, Jason, Alistair, Andy, Jess, Victoria, Greg, Ben and Bradley1.”
...and therein lies the problem.
Labels:
Agile,
change,
Continuous Delivery,
Continuous Integration,
Delivery
Sunday, 28 October 2012
Investigating Deadlocks – Part 4: Fixing the Code
In the last in this short series of blogs in which I’ve been talking about analysing deadlocks, I’m going to fix my BadTransferOperation code. If you've seen the other blogs in this series, you'll know that in order to get to this point I’ve created the demo code that deadlocks, shown how to get hold of a thread dump and then analysed the thread dump, figuring out where and how a deadlock was occurring.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Thursday, 25 October 2012
Investigating Deadlocks – Part 3: Analysing the Thread Dump
In my previous two blogs in this series, part 1 and part 2, I’ve demonstrated how to create a piece of bad code that deadlocks and then used this code to show three ways of taking a thread dump. In this blog I’m going to analyze the thread dump to figure out what when wrong.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Tuesday, 23 October 2012
Investigating Deadlocks – Part 2: Obtaining the Thread Dump
One of the most important requirements when investigating deadlocks is actually having a deadlock to investigate. In my last blog I wrote some code called DeadlockDemo that used a bunch of threads to transfer random amounts between a list of bank accounts before grinding to a halt in a deadlock.
This blog runs that code to demonstrates a few ways of obtaining a thread dump.
This blog runs that code to demonstrates a few ways of obtaining a thread dump.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Thursday, 18 October 2012
Investigating Deadlocks – Part 1: Creating a Deadlock
I’m sure we’ve all been there: it’s late, you’re hungry, your server has hung or your application’s running at snail’s pace, and there’s someone breathing down your neck wanting you to fix the problem before you go. One of the possible causes of your application hanging unexpectedly is a threading issue known as a Deadlock.
Without going into too much detail, threads can be in one of a number of states as shown by the UML state diagram below...
Without going into too much detail, threads can be in one of a number of states as shown by the UML state diagram below...
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading.,
Threading
Monday, 8 October 2012
Apple Mac Time Machine Runs Very Slowly
Not a lot of people know this, but I write many of my blogs in The Wolverhampton Art Gallery’s cafe: the food’s really good and, for a provincial art gallery, there are some very fine painting to be seen producing an atmosphere I find conducive to writing.
Labels:
Apple,
Mac,
MacOS,
Performance,
Spotlight,
Time Machine
Sunday, 30 September 2012
A Footnote on Accessing Request Parameters using Spring 3 MVC
I recently got a comment on my blog: Accessing Request Parameters using Spring 3 MVC, pointing out something that I didn’t know about Spring’s @RequestParam annotation. The comment, from salient1, went like this:
Labels:
Annotations,
Java,
MVC,
Spring
Tuesday, 25 September 2012
Spring 3.1: Caching and EhCache
If you look around the web for examples of using Spring 3.1’s built in caching then you’ll usually bump into Spring’s SimpleCacheManager, which the Guys at Spring say is “Useful for testing or simple caching declarations”. I actually prefer to think of SimpleCacheManager as lightweight rather than simple; useful in those situations where you want a small in memory cache on a per JVM basis. If the Guys at Spring were running a supermarket then SimpleCacheManagerwould be in their own brand ‘basics’ product range.
If, on the other hand, you need a heavy duty cache, one that’s scalable, persistent and distributed, then Spring also comes with a built in ehCache wrapper.
If, on the other hand, you need a heavy duty cache, one that’s scalable, persistent and distributed, then Spring also comes with a built in ehCache wrapper.
Labels:
cache,
Configuration,
ehcache,
Maven,
Spring,
Spring 3.1,
XML
Tuesday, 18 September 2012
Spring 3.1 Caching and Config
I’ve recently being blogging about Spring 3.1 and its new caching annotations @Cacheable and @CacheEvict. As with all Spring features you need to do a certain amount of setup and, as usual, this is done with Spring’s XML configuration file. In the case of caching, turning on @Cacheable and @CacheEvict couldn’t be simpler as all you need to do is to add the following to your Spring config file:
<cache:annotation-driven />
Labels:
cache,
Configuration,
Spring,
Spring 3.1,
XML
Friday, 14 September 2012
Spring 3.1 Caching and @CacheEvict
My last blog demonstrated the application of Spring 3.1’s @Cacheable annotation that’s used to mark methods whose return values will be stored in a cache. However, @Cacheable is only one of a pair of annotations that the Guys at Spring have devised for caching, the other being @CacheEvict.
Like @Cacheable, @CacheEvict has value, key and condition attributes. These work in exactly the same way as those supported by @Cacheable, so for more information on them see my previous blog: Spring 3.1 Caching and @Cacheable.
@CacheEvict supports two additional attributes: allEntries and beforeInvocation. If I were a gambling man I'd put money on the most popular of these being allEntries. allEntries is used to completely clear the contents of a cache defined by @CacheEvict's mandatory value argument. The method below demonstrates how to apply allEntries:
Like @Cacheable, @CacheEvict has value, key and condition attributes. These work in exactly the same way as those supported by @Cacheable, so for more information on them see my previous blog: Spring 3.1 Caching and @Cacheable.
@CacheEvict supports two additional attributes: allEntries and beforeInvocation. If I were a gambling man I'd put money on the most popular of these being allEntries. allEntries is used to completely clear the contents of a cache defined by @CacheEvict's mandatory value argument. The method below demonstrates how to apply allEntries:
Labels:
Annotations,
cache,
Java,
Spring,
Spring 3.1
Saturday, 8 September 2012
Spring 3.1 Caching and @Cacheable
Caches have been around in the software world for long time. They’re one of those really useful things that once you start using them you wonder how on earth you got along without them so, it seems a little strange that the Guys at Spring only got around to adding a caching implementation to Spring core in version 3.1. I’m guessing that previously it wasn’t seen as a priority and besides, before the introduction of Java annotations, one of the difficulties of caching was the coupling of caching code with your business code, which could often become pretty messy.
However, the Guys at Spring have now devised a simple to use caching system based around a couple of annotations: @Cacheable and @CacheEvict.
However, the Guys at Spring have now devised a simple to use caching system based around a couple of annotations: @Cacheable and @CacheEvict.
Labels:
Annotations,
cache,
Java,
Spring,
Spring 3.1
Thursday, 23 August 2012
Using Spring Profiles and Java Configuration
My last blog introduced Spring 3.1’s profiles and explained both the business case for using them and demonstrated their use with Spring XML configuration files. It seems, however, that a good number of developers prefer using Spring’s Java based application configuration and so Spring have designed a way of using profiles with their existing @Configuration annotation.
Labels:
Annotations,
Java,
Profiles,
Spring,
Spring 3.1
Friday, 10 August 2012
Using Spring Profiles in XML Config
My last blog was very simple as it covered my painless upgrade from Spring 3.0.x to Spring 3.1.x and I finished by mentioning that you can upgrade your Spring schemas to 3.1 to allow you to take advantage of Spring’s newest features. In today’s blog, I'm going to cover one of the coolest of these features: Spring profiles. But, before talking about how you implement Spring profiles, I thought that it would be a good idea to explore the problem that they’re solving, which is need to create different Spring configurations for different environments. This usually arises because your app needs to connect to several similar external resources during its development lifecycle and more often and not these ‘external resources’ are usually databases, although they could be JMS queues, web services, remote EJBs etc.
Labels:
Java,
Profiles,
Spring,
Spring 3.1,
XML
Sunday, 29 July 2012
Upgrading to Spring 3.1
A few days ago I thought that it was about time to upgrade my sample code to Spring 3.1, after all it’s been around for a respectable amount of time and has a couple of bug fix releases.
Upgrading to Spring 3.1 is very simple of upgrading your Maven version number and rebuilding, something like this:
Upgrading to Spring 3.1 is very simple of upgrading your Maven version number and rebuilding, something like this:
Labels:
DefaultListableBeanFactory,
Java,
Spring,
Spring 3.1,
Upgrade
Tuesday, 24 July 2012
Getting Started with Spring Social - a Footnote
If you’ve seen my last blog, you’ll know that I’ve been talking about writing the smallest and simplest Spring Social application that I could think of that can read and display your user’s private Facebook data.
If, by any chance, you decide to use the Facebook Github sample as inspiration for your own application then you’ll need to register your application with Facebook or other Software as a Service (SaaS) provider.
If, by any chance, you decide to use the Facebook Github sample as inspiration for your own application then you’ll need to register your application with Facebook or other Software as a Service (SaaS) provider.
Labels:
Facebook,
Java,
OAuth,
SaaS,
Software as a Service,
Spring,
Spring Social
Thursday, 19 July 2012
Getting Started with Spring Social - Part 2
A few weeks ago I wrote a blog demonstrating what I thought was the simplest application you could write using Spring Social. This application read and displayed a Twitter user's public data and was written as an introduction to Spring Social and the social coding arena. However, getting your application to display your user’s public data is only half the story and most of the time you’ll need to display your user’s private data.
In this blog, I’m going to cover the scenario where you have a requirement to display a user’s Facebook or other Software as a Service (SaaS) provider data on one or two pages of your application. The idea here is to try to demonstrate the smallest and simplest thing you can to to add Spring Social to an application that requires your user to log in to Facebook or other SaaS provider.
In this blog, I’m going to cover the scenario where you have a requirement to display a user’s Facebook or other Software as a Service (SaaS) provider data on one or two pages of your application. The idea here is to try to demonstrate the smallest and simplest thing you can to to add Spring Social to an application that requires your user to log in to Facebook or other SaaS provider.
Labels:
Facebook,
Java,
OAuth,
SaaS,
Software as a Service,
Spring,
Spring Social
Monday, 2 July 2012
OAuth 2.0 Webapp Flow Overview
In my last few blogs I’ve been talking about accessing Software as a Service (SaaS) providers such as Facebook and Twitter using Spring Social. Some of you may have noticed that my sample code may have been a bit thin on the ground as I’ve being trying to describe what’s going on in the background and what Spring Social is doing for you.
So far I taken a bird’s eye view of OAuth defining it as the need for your application to get hold of an Access Token so that it can access your user’s private data from an SaaS provider without the need for your users to give your app their credentials. I’m concentrating on OAuth 2.0 and I’ve also hinted that before it can request an Access Token your app needs something called an Authorization Code, which it combines with its app secret.
This blog zooms in some more and hopefully explains what going on - at least in the case of OAuth 2.0.
So far I taken a bird’s eye view of OAuth defining it as the need for your application to get hold of an Access Token so that it can access your user’s private data from an SaaS provider without the need for your users to give your app their credentials. I’m concentrating on OAuth 2.0 and I’ve also hinted that before it can request an Access Token your app needs something called an Authorization Code, which it combines with its app secret.
This blog zooms in some more and hopefully explains what going on - at least in the case of OAuth 2.0.
Labels:
Facebook,
OAuth,
SaaS,
Software as a Service,
Spring Social,
Twitter
Tuesday, 26 June 2012
The OAuth Administration Steps
In my last blog I summarised the point of OAuth as the need for your application to get hold of an Access Token so that it can access your user’s private data from a Software as a Service (SaaS) provider’s website such as Twitter or Facebook without the need for your users to give your application their credentials.
This blog takes a look at the setup steps necessary for this hypothetical application to become OAuth compliant and when I say “setup steps”, at this stage I’m merely talking about a boring administration step that you must complete, but don’t worry as there isn’t that much to it.
This blog takes a look at the setup steps necessary for this hypothetical application to become OAuth compliant and when I say “setup steps”, at this stage I’m merely talking about a boring administration step that you must complete, but don’t worry as there isn’t that much to it.
Labels:
Admin,
Facebook,
OAuth,
Software as a Service,
Spring Social,
Twitter
Friday, 22 June 2012
Facebook and Twitter: Behind the Scenes
In my last blog I created a simple Twitter application that uses the Spring Social Twitter module to access a user’s public time line data. As I said in that blog, the example isn’t particularly complicated and I’ll be adding extra features later. Before I do that I wanted to explain a little about what a Software as a Service (SaaS) provider, such as Facebook and Twitter, is and show something of what the Spring Social API is doing for you.
Labels:
Facebook,
Java,
OAuth,
Social,
Software as a Service,
Spring,
Spring Social,
Twitter
Monday, 18 June 2012
Getting Started with Spring Social
Like me, you will not have failed to notice the current rush to ‘socialize’ applications, whether it’s adding a simple Facebook ‘Like’ button, a whole bunch of ‘share’ buttons or displaying timeline information. Everybody’s doing it including the Guys at Spring, and true to form they’ve come up with a rinky-dinky API called Spring Social that allows you to integrate your application with a number of Software as a Service (SaaS) feeds such as Twitter, Facebook, LinkedIn etc.
This, and the following few blogs, takes a look at the whole social scene by demonstrating the use of Spring Social, and I’m going to start by getting very basic.
This, and the following few blogs, takes a look at the whole social scene by demonstrating the use of Spring Social, and I’m going to start by getting very basic.
Labels:
Java,
Social,
Software as a Service,
Spring,
Spring Social,
State Machine,
Twitter
Monday, 11 June 2012
Tuesday, 5 June 2012
Defining a Class’s Responsibility - Naming Part 4
Previously, I discussed CRC cards and revealed a big secret in that the crucial thing about a CRC card is that it forces you to explicitly think about and write down your class’s responsibility, and that being able to define a class’s intent in this way is crucial to creating a viable name. I strongly believe that well defined responsibility and a good name equals good software and so, this blog contains a few guidelines that may be helpful.
Wednesday, 30 May 2012
CRC Cards - Naming Part 3
Another way of specifying a class’s name is to use CRC cards. Proposed by Kent Beck and Ward Cunningham1, I first came across these many years ago in Grady Booch’s book ‘OO Analysis and Design’. CRC initially stood for Class, Responsibilities and Collaborators, though in today’s single responsibility principal world, Responsibilities has been quietly renamed Responsibility.
Labels:
CRC Cards,
Naming,
Object Orientation,
OO
Monday, 21 May 2012
Clues from Classification: Naming Part 2
My last blog took a quick look at the fundamental OO rule that states that class names must be a noun. It highlighted the problem that even if you apply it correctly you can still end up with badly named classes and is partly a result of trying to apply the flimsy and lax rules of the English language to the need for precision in software development.
The question is, what are we trying to achieve when we name an object?
The question is, what are we trying to achieve when we name an object?
Monday, 14 May 2012
What's in a Name? Part 1
One of the things that we all do on a daily basis in our work is to name objects. It’s an activity that we take for granted without ever giving it much thought. It’s also something that we often get wrong and sometimes do badly and there are a couple of reasons for this
Labels:
Naming,
Object Orientation,
OO
Monday, 30 April 2012
Implementing the State Machine Pattern as a Stream Processor
In my last blog, I said that I really thought that some of the Gang Of Four (GOF) patterns were becoming somewhat obsolete, and if not obsolete then certainly unpopular. In particular I said that StateMachine wasn’t that useful as you can usually think of another, simpler way of doing whatever it is you’re doing rather than using it. In order to make amends, both for preaching obsolescence and for the hideous ‘C’ code that I attached to the end of my last blog, I thought that I’d demonstrate the use of StateMachine in converting Twitter tweets into HTML.
Labels:
Java,
Object Orientation,
OO,
Pattern,
State Machine,
Strategy
Tuesday, 10 April 2012
The Importance of Questioning
One of the comments my about my last blog Design Patterns, The Emperor’s New Clothes and Catch 22 was that “one of the most valuable things these patterns offer is vocabulary. They give something a name.”, which is an important point that I think I missed. The idea is that once something has a name then it’s something you can easily communicate about. For example, it’s easier to say “I’ve used a Singleton” rather than “I’ve created this class where there’s only ever one instance and that instance is available to all other classes in the application”
Labels:
Anti-Pattern,
Gang Of Four,
GOF,
Java,
Naming,
Object Orientation,
Observer,
OO,
Pattern,
Strategy
Tuesday, 3 April 2012
Design Patterns, The Emperor’s New Clothes and Catch 22
When writing this blog one of the things I do before I metaphorically put pen to paper is to verify what I’m going to write is correct and I usually do that by either checking a text book or looking on the Internet. Now, my last blog described the Strategy Pattern and, of course I double checked that I wasn’t presenting the Bridge Pattern which has a UML diagram that’s very similarl to Strategy. In doing this it occurred to me that the Gang Of Four (GOF) design patterns have been around a few years (again I double checked Design Patterns: Elements of ReusableObject-Oriented Software by the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides was first published in 1994) and that over the years these ideas have been copied and republished in numerous blogs and on a multitude of web sites. It then occurred to me that if these patterns have been around for such a long time, then why is it that they aren’t that well known and more widely used on a daily basis?
Labels:
Design,
Gang Of Four,
GOF,
Object Orientation,
OO,
Pattern
Tuesday, 27 March 2012
The Strategy Pattern
In a recent blog on I received a comment from Wojciech Soczyński about how the “strategy” pattern can be used to enforce the Single Responsibility Principle (SRP) when using Tell Don't Ask (TDA). At some point I plan to discuss this further, but first thought that it would be a good idea to define the Strategy Pattern using the ShoppingCart example that I used a couple of weeks ago in my Tell Don’t Ask and its follow up Disassembling Tell Don’t Ask blogs:
Labels:
Java,
Object Orientation,
OO,
Pattern,
Strategy
Thursday, 22 March 2012
A Ranking Order for Coding Priorities
In my previous blog I light-heartedly asked whether or not you should tailor your coding style to suit the business domain that you’re working in. The idea is that different business domains will demand different things from their software in terms of coding style. For example, software written for the defence market must be robust as a crash my cost lives, whilst software written for a market that under goes constant legislative changes, such as taxation, must be written for maintainability, and in advertising, where the projects and software lifespan are short then software should be written to be reusable.
Labels:
Agile,
Process,
Single Responsibility Principal (SRP),
SOLID
Tuesday, 20 March 2012
Horses For Courses
Over the years I've worked on projects in various problem domains including electricity metering, defence, taxation and banking and, if you've followed my blog over the last year or more then you may have realised that I currently work for an advertising company. In working in the advertising domain the main thing that I've noticed about projects is that they usually have shorter development timescales for a given set of functionality and, once completed, the software's natural lifespan is also fairly short. All of this got me thinking...
Labels:
Design
Thursday, 15 March 2012
Integrating Spring Into Legacy Applications
One of the things that all Spring developers like to do is to shoehorn Spring into any application they work on - it’s one of my guilty pleasures in life: you see some code, think it’s rubbish because it contains several well known anti-patterns and then think how cool it would be if this app was a Spring app.
When working with legacy code, you can’t convert it into a fully fledged Spring app over night, that takes time. What you need to do is to add Spring code a little at a time: piece by piece and there’s one good way of doing that.
When working with legacy code, you can’t convert it into a fully fledged Spring app over night, that takes time. What you need to do is to add Spring code a little at a time: piece by piece and there’s one good way of doing that.
Labels:
ApplicationContext,
Java,
Legacy,
Object Orientation,
OO,
Pattern,
Spring
Tuesday, 13 March 2012
Disassembling Tell Don't Ask
In my last blog I defined Tell Don’t Ask (TDA) using a simple shopping cart example. In it the shopping cart was responsible for working out the total cost of the items in the cart as opposed to the client asking for a list of items and then calculating the total cost itself. The TDA example is shown below:
Thursday, 8 March 2012
Defining Tell Don't Ask... well almost...
I’ve been wanting to write about ‘Tell Don’t Ask’ for some time now, mainly because it’s often espoused as the ‘right’ way to design a program and I've seen lots of Java code that doesn't use it. ‘Tell Don’t Ask’ isn’t a new idea, it’s been around for some time under other guises: in the OO world I’ve seen it called “Objects Do Things” and a long time ago when I was a Windows SDK C++ programmer it was called “Objects Aren’t structs”.
The big idea is that object A tells object B what to do and object B tells C as shown in the diagram below:
The big idea is that object A tells object B what to do and object B tells C as shown in the diagram below:
Labels:
Java,
Object Orientation,
OO,
Tell Don't Ask
Tuesday, 6 March 2012
Using Maven's -U Command Line Option
In my experience when working on a multi-model project, the developers on that project tend to grab hold of all the project’s source code and build it all using some kind of Maven build-all POM project. You know the sort of thing I mean: a build-all module is a module that contains a list of other modules that get built is a specific order. I use one to build the CaptainDebug github samples and it looks like this:
Labels:
Maven
Thursday, 1 March 2012
Configuring the Maven Tomcat Plugin
My last blog explained the relationships between Mavan life-cycles, build phases and goals from a height of about 3 miles. In explaining Maven’s goals I mentioned the tomcat:redeploy goal without really defining where it came from. Well, the answer is that the tomcat:redeploy goal isn’t a default goal or part of the default Maven installation, it’s part of the tomcat-maven-plugin.
Labels:
Integration Tests,
Maven,
POM,
Tomcat
Tuesday, 28 February 2012
A Birds's Eye View of Maven
One of the things that we do on a daily basis is use Maven to build our projects by issuing build commands such as mvn install. Maven then looks at our project’s configuration file, affectionately known as a POM, magically figures out what do and, hey presto, your build is complete. I imagine that we do this so often that we never think about what’s going on behind the scenes, and in some cases without ever understanding what’s going on either.
Labels:
Maven
Thursday, 23 February 2012
Is Java's String Class a God Object?
In October I wrote a blog entitled Top Trumps in God Objects where I talked about the discovery of an object I’d found with 167 disparate methods that linked this object with all other parts of the application and, as you’d expect, followed the general criteria for a God or Monster Object. It was recently pointed out to me that method count alone isn’t an indication that an object is a God Object
Tuesday, 21 February 2012
Isn't Java a Civilised Language?
A few weeks ago I was given the opportunity to learn iOS programming. My boss decided that I was more of a ‘computer scientist’ rather than a developer, and this meant that I could apply my knowledge to developing an iPad application or two - all I’d need to do was to learn Objective-C and the iOS SDK: after all, how hard can it be?
Labels:
Java,
Objective-C,
Reference Counting
Thursday, 16 February 2012
Using Spring’s SimpleMappingExceptionHandler
My last few blogs have talked about Spring’s @ExceptionHandler annotation and how you can use it to deal with errors on a controller by controller basis to give you fine-grained control over how you handle errors in your code. The question to consider now is whether or not you always want such fine grained control, to which I’m guessing that in certain circumstances the answer will be no, and so to accommodate this Spring have provided us with the SimpleMappingExceptionHandler.
Labels:
Exceptions,
Java,
Spring
Tuesday, 14 February 2012
Spring 3 MVC Exception Handlers and @ResponseStatus
My last couple of blogs have covered Spring’s MVC @ExceptionHandler annotation outlining where and why you should use it. Today’s blog wraps up the discussion on the basics of @ExceptionHandler by taking a look at the companion annotation @ResponseStatus.
Labels:
Annotations,
Exceptions,
Java,
Spring
Thursday, 9 February 2012
Spring 3 MVC Exception Handlers and Multiple Exception Arrays
My last blog was the first in a short series of blogs examining Spring 3 MVC’s exception handling annotations. It covered the basic usage of the @ExceptionHandler annotation with a few pieces of demo code and no contrived scenarios. Today’s blog continues where I left off and examines @ExceptionHandler in more detail.
Labels:
Annotations,
Exceptions,
Java,
Spring
Tuesday, 7 February 2012
Spring 3 MVC Exception Handlers
The majority of the Spring 3 error handling sample code that I’ve come across only ever seems to give the simplest overview of its usage, yet how we handle errors is, some would say, more important than how the normal code works. This was borne out the other day when I came across a simple ‘GOTCHA’ in a Spring 2 error handler that brought a whole website down and almost killed the server, but more on that later.
Today’s blog examines the scenario of creating a simple Spring 3 servlet exception handler using the @ExceptionHandler annotation.
Today’s blog examines the scenario of creating a simple Spring 3 servlet exception handler using the @ExceptionHandler annotation.
Labels:
Annotations,
Exceptions,
Java,
Spring
Thursday, 2 February 2012
Unreachable Catch Block - A Most Unobvious Bug
Earlier today I was working on some HTTP comms code adding a few changes, which are of no consequence here. One of the things that the code did was to read data from a server and, if the read failed, then it re-newed the connection and retried the read. The code ran something like this:
Labels:
Exceptions,
Java
Tuesday, 31 January 2012
Autowiring Using @Value and Optional Properties
Last October I wrote a blog entitled Autowiring Property Values into Spring Beans describing how to use Spring’s @Value annotation to inject property values into your beans from both a property file and Java system properties. Last week, I came across this little gotcha whilst helping out on another project....
Labels:
Annotations,
Autowired,
Java,
Properties,
Spring
Thursday, 26 January 2012
Adding Version Information to your JAR’s Manifest
One of the handy things about using Maven is that, by default, the names of the artifacts it creates include the current version number from the POM's version tag. It doesn’t matter what type of artifact it is, whether it’s a JAR, WAR or EAR you generally end up with something like this:
And this is all usually fine when you’re dealing with a project that’s built solely using Maven. It does, however, become a little more inconvenient if you’re developing JAR files with Maven, but your WAR file is developed using Ant.
my_module-1.2.3-RELEASE.jar
And this is all usually fine when you’re dealing with a project that’s built solely using Maven. It does, however, become a little more inconvenient if you’re developing JAR files with Maven, but your WAR file is developed using Ant.
Labels:
Maven,
POM,
Properties
Tuesday, 24 January 2012
Approaches to XML - A Review
A couple of weeks ago I wrote a few articles about XML highlighting several possible approaches to parsing it using a couple of different situations. The blogs in the series were:
The story I used was Pete’s Perfect Pizza about a small high street pizza company that grows into an international business. The idea was that the fictitious programmer of the piece, our hero, is an absolute beginner and jumps straight in and choosing XML without considering any other design options.
The story I used was Pete’s Perfect Pizza about a small high street pizza company that grows into an international business. The idea was that the fictitious programmer of the piece, our hero, is an absolute beginner and jumps straight in and choosing XML without considering any other design options.
Labels:
XML
Thursday, 19 January 2012
SLF4J Dependencies and LocationAwareLogger.log Method Not Found Exception
I recently wrote a new module for incorporation into a couple of our web-applications. Everything seemed perfect - the hoards of unit tests passed, the integration tests succeeded and everything seemed hunky-dory. The module was added to the web-apps POM files and the source code amended to use the new functionality. The web-app was deployed and then
Labels:
Error,
Exceptions,
Java,
SLF4j,
Tomcat
Tuesday, 17 January 2012
Spring 3 and Apache Commons JCS Exception
I’ve seen a couple of projects in the last few months that have needed to cache data between requests. The developers, not wanting to write their own caching module, decided that Apache Commons JCS fitted the bill and added it to their Maven POM using the latest version:
Labels:
Apache Commons,
cache,
Error,
Exceptions,
JCS,
Spring
Thursday, 12 January 2012
Approaches to XML - Part 4 - XMLBeans
If you remember from my previous blogs, I’m covering different approaches to parsing XML messages using the outrageously corny scenario of Pete’s Perfect Pizza, the pizza company with big ideas. In this story, you are an employee of Pete’s and have been asked to implement a system for sending orders from the front desk to the kitchen and you came up with the idea of using XML. You’ve just got your SAX Parser working, but Pete’s going global, opening kitchens around the world taking orders using the Internet.
But, hang on a minute... didn’t I say this in my last blog? Déjà vu? Today’s blog is the alternative reality version of my JAXB blog as the scenario remains the same, but the solution changes. Instead of demonstrating JAXB, I’ll be investigating XMLBeans.
But, hang on a minute... didn’t I say this in my last blog? Déjà vu? Today’s blog is the alternative reality version of my JAXB blog as the scenario remains the same, but the solution changes. Instead of demonstrating JAXB, I’ll be investigating XMLBeans.
Tuesday, 10 January 2012
Approaches to XML - Part 3 - JAXB
If you remember from my previous blogs, I’m covering different approaches to parsing XML messages using the outrageously corny scenario of Pete’s Perfect Pizza, the pizza company with big ideas. In this story, you are an employee of Pete’s and have been asked to implement a system for sending orders from the front desk to the kitchen and you came up with the idea of using XML. You’ve just got your SAX Parser working, but Pete’s going global, opening kitchens around the world taking orders using the Internet. He’s hired some consultants who’ve come up with a plan for extending your cosy XML message and they’ve specified it using a schema. They’ve also enhanced your message by adding in one of there own customer schemas. The result is that the following XSD files land in your inbox and you need to get busy...
Thursday, 5 January 2012
Approaches to XML - Part 2 - What about SAX?
My last blog introduced the idea that there are different ways to approach XML parsing and highlighted the point that XML is NOT A STRING; rather it’s an object oriented document model that can be represented using a string. Today’s blog continues this discussion using my Pete’s Perfect Pizza scenario. If you remember, Pete’s just popped his head around the door
Tuesday, 3 January 2012
Approaches to XML - Part 1 - XML is not a String...
XML has been around a long time: from memory, I’d guess that it’s about 12-14 years old by now; it’s a mature product with, in computing terms, a long history. So, is there anything new that I could possibly add to this subject? How you approach XML is really down to you and your situation, with the emphasis being on situation. At one extreme, you may be involved in a cosy ‘in-house’ project, where one in-house system has to talk to another. At the other extreme, you’re in a situation where you’re handed an XML schema that will, one day, comprise the conversation between your system and some other system in a far away country written by a different set of developers.
Subscribe to:
Posts (Atom)