Tuesday, April 28, 2009

SpringOne 2009 Amsterdam - Day Two - Keynote

Today was another excellent day at SpringOne.

First up was Adrian Colyer's keynote session. Wow. Just a few slides, and a bunch of incredible demos of the power of SpringSource Tool Suite!

Whereas yesterday's demo of roo had all been about assisting the developer in rapid application development, today's demos concentrated in assitance for the testing and operations teams, in rapid deployment to staging and production environments.

Platform as a Service


First up was an example of deploying a web-app to Google AppEngine. First off was an example of local testing, followed by deployment to the cloud for a simple webapp (with a groovlet thrown in for good measure). This was followed by a similar exercise deploying a grails application. Adrian had to make sure to uninstall hibernate (grails uninstall-plugin hibernate) since GAE doesn't support this at the moment, and then install the GAE plugin (grails install-plugin app-engine). Having done this, he quickly created a simple domain class, a controller, and then deployed to the cloud. This is how easy life should be!

Datacentre as a Service


Next up was an example of deploying a dm Server cluster, and a load balancer to Amazon EC2. Again, this was fully integrated within STS. He also showed an interesting website (not part of SpringSource) CloudFoundry, which he used to configure a deployment 'blueprint' (HTTP, dm Server, MySQL), and pass this to EC2. Adrian's vision would be that Spring might support a similar blueprint as a 'deployment context', where 'beans' are individual nodes.

Use your own datacenter as a Service


Adrian's tounge in cheek title for simplifying deployment within your own datacenter. This part concentrated on VM's, and used VMWare Lab Manager connected to SpringSource's datacenter in Southampton.

I'm sure there's a lot of stuff I forgot or misremebered. I will definitely want to watch the presentation again.

Monday, April 27, 2009

SpringOne 2009 Amsterdam - Day One - Key Note

Attended day one of the SpringOne conference in Amsterdam.

Rod Johnson was up first for the keynote. Obviously the question on everyone's lips is what does the acquisition of Sun by Oracle mean for Java?

Rod reckons that the JCP process will undoubtably begin to have a bias towards Oracle, to the detriment of IBM. However, he asserts that the key innovations in Java are being made outside of the JCP process (which repeats his statements from the SkillsMatter / QCon conference in London).

We were then treated to 2 demonstrations.

Roo



The first was for a new build assistant, codenamed "roo" demonstrated by Ben Alex. It comes with a nice command line shell, with syntax very similar to Grails, and excellent tab-completion so you don't have to type out verbose options. It also has excellent support in SpringSource Tool Suite (basically a bespoke version of eclipse - with more complete functionality than the Spring IDE plugins). Forexample, creating an entity was a fairly simple process, resulting in a class that looked something like:


@RooBean // spelling?
@RooToString // spelling?
public class MyEntity {
@NotNull // JSR 303 bean validation support
private String description;
}


The @Roo annotations are all retention source-code only, so roo does not require any runtime dependencies.

They key difference with Grails is that Roo uses vanilla Java, and is statically typed.

The decision matrix for choosing Grails or Roo was presented as:


  • Do you know Java? If not, use Grails.

  • Would you prefer static over dynamic typing (or is someone saying you must use static typing)? If yes, then Roo. Otherwise Grails.



It was impressive. My only concern was with Continuous Integration support. That is, Roo seems to be great within its own shell, or within STS, but what about using Maven / Ant as part of a automated build process. This wasn't really covered. Perhaps the compilation step is simply a @Roo annotation processor step, and there doesn't need to be any fancy maven plugin?

SpringSource AMS


Next up was the SpringSource Administration Management Suite demonstrated by Jennifer Hickey. The demo had a few hiccups, but the concept was extremely intersting (in fact, I changed which session I attended later just to find our more). Its all about providing the sort of Admin / Monitoring that full-blown appservers have, but on top of Tomcat.

In fact, its slightly more than that. The idea is that AMS will be able to administer:


  • SpringSource tc Server. Spring's tailor-made tomcat server.

  • Http Server. To configure load balancing etc.

  • Active MQ message broker.

  • Operating System - only shown with Linux in the demo.



Also on the roadmap is for AMS to administer groups of SpringSource dm Server nodes (the OSGi'fied web container (tomcat or jetty), with additional OSGi extenders from Spring).

All in all, a very exciting 2009 for Spring.

Wednesday, October 29, 2008

StackOverflow

So, a while back, I and about 3000 others volunteered for a private beta of StackOverflow

A new website for developers to come with their problems / bugs / stacktraces, and ask for advice.

This website comes from Jeff Atwood of Coding Horror fame, and Joel Spolsky of Joel on Software and FogBugz fame. See the StackOverflow Blog for day to day news on the site.

The private beta finished a while back. I was extremely impressed with the quick response to feedback, and the number of new features continuously being added.

Stackoverflow is quite an interesting social experiment, similar in some aspects to Digg. Interesting questions can be upvoted, and idiotic / spam questions can be downvoted out of existence.  Good answers can also be upvoted. All of these votes count towards a registered user's reputation.

As your reputation increases, you gain extra moderator abilities, such as being able to edit other's posts (to tidy up code sections, etc..) or attach searchable tags to questions. Even higher rep allows you to close posts.

There are, however, some downsides to reputation:
  • People started noticing questions like: 'What keyboard do you use' or 'What is your company dress code' would get mega-rep. So some are now trying to think up similar questions to quickly boost their rep. However, the community has  reacted to this, and most questions of this type are either downvoted, or closed.
  • Some have taken the power to close others questions to extremes, closing questions on a whim, which has annoyed a few people who feel victimised.
Aprt from this, I reckon its a huge success, and will continue to enjoy answering the occasional question I can understand :-)

Tuesday, June 03, 2008

Which certification next

In its most simple terms, there are two reasons why I have an urge to take certification exams:
  • To reassure myself that I am not a complete bonehead
  • To counter my crappy CV writing skills with a list of relevant certifications
Previously, I have mainly gone with Sun's certification offerings:
Now, I was planning on 'completing the set' by taking the SCEA. However, the amount of momentum with Spring is now picking up at a frightening pace. We are in the golden age with Spring right now. So instead, I've decided to take the SpringSource certification.

As with the SCEA, the SpringSource certification requires a lot more effort (and money) be expended, rather than just turning up and answering a bunch of multiple choice questions.

Effectively, there are two paths to follow, as quoted from the website:

A person is eligible for registration if he or she has recently taken the 4-day “CoreSpring” class from SpringSource (or a SpringSource certified training partner in Europe, Africa or the MiddleEast (EMEA)).

A person may also be eligible for registration, without attending the 4-day course, if he or she can demonstrate having significantly contributed to the Spring community or can provide a reference to a Spring development effort in which he or she was actively involved. This person is referred to as a “grandfathered” candidate.

As I've managed to convince my company to pay for a bunch of us to attend this CoreSpring class, I will be opting for the first approach.

I would be interested to know what other people feel on the subject.

Update: Passed the SpringSource certification.... Woo Hoo!

Tuesday, April 22, 2008

Changing Spring Beans Using Properties

If you're reading this article, I assume you know about Spring. I'm currently using Spring 2.0.7, but the following code still holds for Spring 2.5 (although 2.5 now has the context schema if you prefer) Ill hopefully come back and update this later...

I have an application that sometimes needs to be run as a standalone app, and sometimes as a client-server. In other words, my user interface sometimes needs to talk to a command handler running in the same process, and sometimes this command handler needs to be remote.

Lets say my user interface looks like:
package com.acme;
public class UserInterface {
private CommandHandler handler;
public void setCommandHandler(CommandHandler handler) {
this.handler = handler;
}
public String do(String command) {
return handler.handleCommand(command);
}
public static void main() {
ApplicationContext ctx = ...
UserInterface ui = (UserInterface ) ctx.getBean("ui");
System.out.println(ui.do("greet"));
}
}

Where CommandHandler is a interface with a single POJO implementation of:
package com.acme;
public class CommandHandlerImpl implements CommandHandler {
public String handleCommand(String command) {
if ("greet".equals(command)) {
return "hello";
} else {
return "unrecognised command";
}
}
}
When I run this in standalone, I can wire everything like:

<bean id="commandHandler" class="com.acme.CommandHandlerImpl"/>
<bean id="ui" class="com.acme.UserInterface">
<property name="commandHandler" ref="commandHandler"/>
</bean>

Now, for the client-server version, I am hosting my CommandHandler inside tomcat, and using Spring's DispatcherServlet. The code in the web.xml deployment descriptor looks like:

<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>*.service</url-pattern>
</servlet-mapping>

For this configuration, the servlet will look in dispatcher-servlet.xml for the Spring configuration. I am using XFire (although you could use CXF or Spring WS 1.5) as a way of remoting my CommandHandler, so it looks like:

<import resource="classpath:org/codehaus/xfire/spring/xfire.xml">
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/xfire.service">remote.xfire</prop>
</props>
</property>
</bean>
<bean id="target" class="com.acme.CommandHandlerImpl" />
<bean id="remote.xfire" class="org.codehaus.xfire.spring.remoting.XFireExporter">
<property name="serviceFactory" ref="xfire.serviceFactory"/>
<property name="xfire" ref="xfire"/>
<property name="serviceBean" ref="target"/>
<property name="serviceClass" value="com.acme.CommandHandler"/>
</bean>

And when I want to connect to this my original spring XML now needs to look like:

<bean id="ui" class="com.acme.UserInterface">
<property name="commandHandler" ref="commandHandler"/>
</bean>
<bean id="commandHandler" class="org.codehaus.xfire.spring.remoting.XFireClientFactoryBean" lazy-init="true">
<!-- Assumes war is named web.war -->
<property name="wsdlDocumentUrl" value="http://localhost:8080/web/xfire.service?wsdl" />
<property name="serviceInterface" value="com.acme.CommandHandler" />
</bean>


Phew! Now the next step is to let me choose which bean is injected into the user interface. For this, I like to use a properties based approach. Spring includes a PropertyPlaceholderConfigurer which is normally used for replacing string values, so for example my wsdlDocumentUrl property could have been specified as "http://${com.acme.host}:${com.acme.port}/web/xfire.service?wsdl", and we could have used a PropertyPlaceholderConfigurer to replace the ${..} tokens as Spring startup.

However, we can actually use PropertyPlaceholderConfigurer to inject references to different beans! So lets rewrite the user interface spring file:

<bean id="clientPropertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE">
<property name="location" value="com-acme.properties" />
</bean>
<bean id="ui" class="com.acme.UserInterface">
<property name="commandHandler" ref="${com.acme.connection}"/>
</bean>
<bean id="local" class="com.acme.CommandHandlerImpl"/>
<bean id="remote" class="org.codehaus.xfire.spring.remoting.XFireClientFactoryBean" lazy-init="true">
<!-- Assumes war is named web.war -->
<property name="wsdlDocumentUrl" value="http://localhost:8080/web/xfire.service?wsdl" />
<property name="serviceInterface" value="com.acme.CommandHandler" />
</bean>

And that's it! If we run the user interface with -Dcom.acme.connection=local then the bean named 'local' gets injected in, and everthing runs in the same standalone process. If we run the user interface with -Dcom.acme.connection=remote then the bean named 'remote' gets injected in, and we communicate with a our XFire web service.

Hope this helps :-)

Monday, April 14, 2008

Debugging external tomcat from within Eclipse

I know that Eclipse has a 'Server' view, and that you can debug a Dynamic Web Application project quite easily. However, sometimes I want to start an external tomcat process using ant. Here are three straightforward ant tasks for running tomcat:

<target name="tomcat-start">
<java jar="${tomcat.home.dir}/bin/bootstrap.jar" fork="true">
<jvmarg value="-Dcatalina.home=${tomcat.home.dir}" />
<arg line="start" />
</java>
</target>

<target name="tomcat-debug">
<java jar="${tomcat.home.dir}/bin/bootstrap.jar" fork="true">
<jvmarg value="-Dcatalina.home=${tomcat.home.dir}" />
<jvmarg value="-Xdebug" />
<jvmarg value="-Xrunjdwp:transport=dt_socket,address=7070,server=y" />
<jvmarg value="-Djpda=true" />
<arg line="start" />
</java>
</target>

<target name="tomcat-stop">
<java jar="${tomcat.home.dir}/bin/bootstrap.jar" fork="true">
<jvmarg value="-Dcatalina.home=${tomcat.home.dir}" />
<arg line="stop" />
</java>
</target>


The tomcat-debug target makes use of the Java Platform Debugger Architecture (JPDA) which provides support for remote debugging. Running this ant task will cause tomcat to start, and then await connection from a remote debugger.

To connect to this application from eclipse, click on the 'Debug' icon in the toolbar, and choose 'Open Debug Dialog'. Click on the 'Remote Java Application' node, and click on the 'New' button to create a new launch configuration.

  • Specify the connection type to be 'Standard (Socket Attach)'
  • Specify Connection Properties as localhost, 7070

Press 'Debug' and if all goes well, you should now be debugging your web-application running in the external tomcat.

Wednesday, February 20, 2008

Excellent book on Java transactions

Just finished an excellent book on Java Transactions: Java Transaction Design Strategies

It packs a lot of information into a small book, but in a very clear style of writing, devoid of buzzword bingo (anyone tried to read a book on SOA/ESB recently?!?)

It manages to explain complicated concepts without too much headscratching, and provides focused code examples in EJB 2.x, EJB 3, and Spring for comparison.

A definite must have!