Auto-Deploying to Tomcat from CruiseControl with Maven

We have a web project that gets built using Maven; it was relatively simple to get this running under CruiseControl since CC has pretty good Maven2 support. However, we also wanted to have a successful build actually deployed to a Tomcat somewhere at a known location so that people could always check out the latest version. I played around with various maven plugins for working with Tomcat, but had a really hard time getting them to work properly.

Exposing the Stereo Knobs

As I mentioned in my last post, I’m about to implement an algorithm that involves a bunch of constant coefficients that we might be wanting to play around with. In order to make them easy to play with at runtime, we’ll go the JMX route. First, the service code will just have the coefficients injected as dependencies: public class MagicalAlgorithmServiceImpl { protected int coefficientOne; protected int coefficientTwo; public void setCoefficientOne(int one) { .

Customer Engagement

Where I work, we have a product group that functions as our product owners for Scrum development. Fortunately, they are co-located, which generally makes them pretty accessible for clarifications, although they do have this habit of having to be in a lot of meetings (hi guys). So today I sat with one of them to work out a fairly complicated user-specific algorithm for sorting a bunch of movies and TV shows.

Keep It Simple, Stupid

Well, I just spent a couple of hours last night trying to get the Cargo Maven2 plugin to work the way I wanted it to, which was to be able to control an already-installed local Tomcat by saying mvn cargo:start and then having that process exit. Now the whole motivation was to try to get CruiseControl to redeploy the latest version of our webapp after a successful build. Due to various undeploy/deploy cycle PermGen memory leaks, and because it’s on a shared server, I essentially wanted to just have CC do a mvn cargo:undeploy cargo:stop cargo:deploy cargo:start.

Using Interface Hierarchies to Enforce Access Protection

The “implements” relationship in Java between a class and its interface provides for abstract data types where the client of the interface can’t get at the guts of the implementation to muck around with it. I recently encountered this where we had a user object that needed to behave differently based on different login states. We decided to use the State Design Pattern, where we would have the user object delegate to a state object for its state-specific behavior.

TestUtil: Package for Unit Testing Setters/Getters

In a comment on an earlier post, a reader Tatsu reported on the TestUtil package from the GTC Group that’s a step ahead of us in this discussion. Here’s a sample snippet of all you have to do to test the setters/getters of a Java class: public void testSettersAndGetters() { assertTrue(TestUtil.verifyMutable(underTest, 1, 0)); } where underTest is the instance of the class you are testing (created and injected in the setUp method of your JUnit).

Unit Testing Boolean Setters and Getters

It’s crunchtime down on the ranch, so just a quick post today: public class Foo { protected boolean theBool; public void setTheBool(boolean b) { theBool = b; } public boolean getTheBool() { return theBool; } } with: public class TestFoo extends TestCase { private Foo foo; public void setUp() { foo = new Foo(); } public void testSetsOwnTheBoolForSetTheBool() { foo.theBool = true; foo.setTheBool(true); assertEquals(true, foo.theBool); foo.theBool = true; foo.setTheBool(false); assertEquals(false, foo.

Unit Testing Setters and Getters for Java Base Types

Yesterday we took a look at some “stock” unit tests for Java bean-style setters and getters, where the underlying property was an object. The tests for properties with base types will be similar, but slightly different. One nice thing about the object tests are that they can use the assertSame assertion (essentially that two objects are == each other) to make sure that the setters/getters do exactly what you thought they would.

Unit Testing Setters and Getters

So here’s a question for the masses: is it worth it to unit test simple setters and getters? I would contend that if you can automatically generate the code for them, you can also automatically generate the unit test code that tests them (I smell a new ELisp command coming…). So what code should this tool actually generate? Here’s my first cut, assuming we’re going to use EasyMock: Let’s say the name of the bean is foo, and it has class Foo (we’ll go into unit testing beans of base type in a later post).

More on Calling Domain Object Methods From JSPs

This is to follow up from yesterday’s post about calling domain object methods from JSPs. If you’ll recall, there were three methods proposed: controller call: make the call in the controller, and pass the results as extra entries in the model data transfer object: put the logic in a special object that provides no-argument methods for retrieving the data in the JSP page taglib: create a taglib that essentially just allows the JSP to call the method itself Having thought a bit about this for a day on the back burner, I’m pretty sure that going the taglib route is not quite the appropriate one here, at least for this method call (which was essentially a range query); so I think it comes down to either the controller call or the DTO.