Java

Spring can be configured in lots of different ways and using context specific XML configuration is one of the preferred approaches. Context specific configuration in other words is simply a chunk of XML specific to a single concern (e.g. servlet config, jpa config, and whatever else you need). A classic example of this is the servlet-config.xml that the Dispatcher Servlet binds against: {% highlight xml %} fitTrackerServlet org.springframework.web.servlet.DispatcherServlet contextConfigLocation /WEB-INF/config/servlet-config.xml {% endhighlight %} Other Context specific configuration files can be registered by hacking your web.xml. Here’s an example for defining a place to stick JPA related cruft: ...

Some of my learning notes about using the excellent Spring MVC framework to build a simple MVC based web application. Spring MVC is an action oriented framework. For a good overview on the differences between UI Component and Action oriented frameworks checkout this link. In action oriented MVC land, the controller dispatches to a specific action, based on information in the request. Each action does a specific thing to transform the request and take action on it, possibly updating the model tier. This approach does not try to hide the request/response model of the underlying HTTP, and it also says absolutely nothing about the specifics of the HTML/CSS/JS comprising the UI. ...

Maven dependencies: <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.21</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-entitymanager</artifactId> <version>4.1.9.Final</version> </dependency> <dependency> <groupId>javax.transaction</groupId> <artifactId>jta</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>3.2.0.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-orm</artifactId> <version>3.2.0.RELEASE</version> </dependency> Entity Manager Factory Used to bootstrap JPA and also Hibernate inside our application. The LocalContainerEntityManagerFactoryBean which is packaged in the spring-orm.jar, references the defined persistence unit. <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> <property name="persistenceUnitName" value="punit" /> <property name="dataSource" ref="dataSource" /> <property name="jpaVendorAdapter"> <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"> <property name="showSql" value="true" /> </bean> </property> <property name="jpaPropertyMap"> <map> <entry key="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect" /> <entry key="hibernate.hbm2ddl.auto" value="none" /> <entry key="hibernate.format_sql" value="true" /> </map> </property> </bean> Transaction Manager The JpaTransactionManager (packaged within spring-tx.jar) which sucks in a reference to the entityManagerFactory, is responsible for taking care of transactions within the JPA layer. ...

Occassionally the need to do multiple side-by-side deployments of the same packaged application can arise. In a scenario recently faced, it was useful to have multiple versions of our packaged EAR deployed and configured slightly differently (for example: with and without security in QA environments). As the application is expected to run hot 24/7, the need for a simple side-by-side versioning (e.g. v1, v2) scheme was also important. Allowing us to deploy v1, and later breaking (incompatible) versions v2, v3, given our service consumers the freedom to upgrade when convenient. ...

Java EE is packed tight with useful functionality. The humble Interceptor provides cross cutting functionality external to the targetted code, without modifying the code itself. In other words AOP. The API is rather simple an involves using @AroundInvoke. The following highlights just how simple it is to log all EJB service call execution times, without the need to modify a single bean. META-INF/ejb-jar.xml <?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1"> <display-name>SerivceModuleEJB</display-name> <assembly-descriptor> <interceptor-binding> <ejb-name>*</ejb-name> <interceptor-class> net.bencode.common.ServicePerformanceInterceptor </interceptor-class> </interceptor-binding> </assembly-descriptor> </ejb-jar> ServicePerformanceInterceptor.java ...

Well first time for everything. Messing around with some JAX-WS web services, wanted to spin up my favourite SOAP frontend, soapUI. On my Mac. Annoyingly it would just immediately hang. Completely frozen. soapUI by default will try and render a web page on startup. This doesn’t seem to work out so well when running on OSX. A handy little article I found on Anton Perez’s blog, made my day. Start ‘Activity Monitor’ and Force Kill your dead soapUI process. In Finder, /Applications/SmartBear/soapUI-5.0.0.app > Show Package Contents. Edit /Applications/SmartBear/soapUI-5.0.0.app/Contents/java/app/bin/soapui.sh. Uncomment this line# JAVA_OPTS="$JAVA_OPTS -Dsoapui.browser.disabled=true". Edit /Applications/SmartBear/soapUI-5.0.0.app/Contents/vmoptions.txt. Add -Dsoapui.browser.disabled=true. Start soapUI. Checkout these commented lines in soapui.sh…our fix ready to go: ...

Lately I’ve gleened some “real world” Apache Ant tips and tricks from some really impressive Java EE developers I’ve had the opportunity of working with over the last year. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications. ...

So I’ve been using WebSphere for a while now, and continue to discover new functionality in this powerhouse of an application server. This post focuses on performing background work in WebSphere Application Server (WAS) 7.0, which is an EE 5 compliant container. Firstly a quick outline of the problem. Across a series of web service calls, there exist a number of intensive processes that need to take place. I wanted a way to perform work this asynchronously somewhere else within the application server, without being bound to the request/response cycle that HTTP web services impose…in essence making the actual service calls appear super snappy. ...

Java EE application servers at times can feel big and heavy…as in behemoth. I’m “lucky” enough to work with an old version of WebSphere AS on a daily basis at the moment. To keep things fast, I’ve resorted to using lighter weight containers for the job at hand. Tomcat is king when it comes to meeting the servlet specification, and no more. Its hell fast. As a result is very lean on what it offers out of the box. I needed to whip up a quick and dirty REST API using Tomcat and ideally using something based on JAX-RS. RESTEasy is a JBoss project that provides and surfaces various frameworks (e.g. Jackson for JSON serialisation) for building RESTful services, and is a fully certifed and portable implementation of the JAX-RS specification. Perfect. ...

When its comes to laying out slightly complex forms in AWT or Swing, using the baked-in layout managers (BoxLayout, FlowLayout, GridLayout) can feel frustrating. Thankfully I stumbled across the JGoodies FormLayout layout manager whilst working on some Swing applications using IntelliJ IDEA 13. IDEA has an integrated visual GUI builder, that makes it really quick and easy to mock up FormLayout controlled layouts, but for the most precise level of control I found handcrafting to be very clean and simple. ...