pay no attention to the man behind the curtain

Integrating: Jetty, Spring, AspectJ, Wicket, Hibernate, MySQL, ActiveMQ and Atomikos (web archive scope)

2011-06-26T16:31:00.000+03:00

Overview

The Spring framework has long provided an attractive alternative to J2EE application servers (especially prior to the arrival of JavaEE 6). Development teams often opted to go for a setup that uses Spring to manage the application context, coupled with a plain Servlet/JSP container and a good ORM solution.

Indeed, the "Jetty/Tomcat + Spring + Hibernate" stack has served many projects. As growth and complexity kicks in, things like JMS and (not long after that) XA transactions, start becoming a necessity.

It is at that point that teams start discussing the use of an application server, in order to gain a "certified" stack that combines all of the above (and more) facilities. However, some teams want to keep on using the "roll your own" path, by adding these aspects into the mix.

In this entry I will describe a setup that combines the most common JEE APIs using a custom assembly of components. The setup comprises of:

Jetty 7.3.1 (Servlet/JSP)
Spring 3.0.5 (CDI)
AspectJ 1.6.10 (because it is cool)
Atomikos 3.7.0 (JTA with XA support)
Hibernate 3.6.0 (JPA)
ActiveMQ 5.5.0 (JMS)
MySQL (JDBC, using driver 5.1.15)

Note that all of the above are integrated at the Web Archive level (i.e. the libraries are all included in WEB-INF/lib with nothing placed in the JVM classpath). This is because I often choose to "embed" Jetty when working in this mode, using my own custom launcher.

The basics: a Spring-enabled WAR, with Wicket managing the presentation

Since we will use Spring to inject all of the resources (JTA, JDBC connections, JPA Persistence Units, JMS, ...), the first step is to create a Spring-enabled WAR. In this step, we will also integrate Apache Wicket to take over page generation (sorry, but I have long hated JSF and JSP with a passion, so these are the first thing I want to get rid of.

So, we start by updating our web.xml as follows:


 xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 version="2.5">

 My own near-JEE stack

 
  Wicket mode (development/deployment)
  wicket.configuration
  
  
  development
 

 
  my.app.filter.wicket
  org.apache.wicket.protocol.http.WicketFilter
  
   applicationClassName   my.Application  
 
 
  
  my.app.filter.wicket
  /*
 

 
  Main Spring context configuration file
  contextConfigLocation  
  /WEB-INF/applicationContext.xml
 

 
  
  org.springframework.web.context.ContextLoaderListener
 

 
  BASIC

This is all that is needed for web.xml. The rest of the magic lies totally within Spring's configuration file (/WEB-INF/applicationContext.xml).


 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
 xmlns:tx="http://www.springframework.org/schema/tx" xmlns:jms="http://www.springframework.org/schema/jms"
 xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-3.0.xsd
           http://www.springframework.org/schema/tx
           http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
           http://www.springframework.org/schema/jms
           http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">

Note that the references to META-INF/spring/... are presented in the following sections.

Adding the Atomikos JTA implementation

The next step is to create the META-INF/spring/tx-services.xml where we instantiate the Atomikos transaction manager and bind it as our JTA implementation. Note that this is where we need to explaing to Spring that we are using AspectJ and therefore the @Transactional annotation must be handled via @Configurable at the class implementation level.


    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/tx
           http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
           http://www.springframework.org/schema/aop
           http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

 
    class="com.atomikos.icatch.jta.UserTransactionManager"
   init-method="init" destroy-method="close">
  
  
 
 
    class="com.atomikos.icatch.jta.UserTransactionImp">
  
 

 
    class="org.springframework.transaction.jta.JtaTransactionManager">
  
  
 

            class="org.springframework.transaction.aspectj.AnnotationTransactionAspect">
        
    

    
         mode="aspectj" proxy-target-class="true" />

Integrating ActiveMQ as a JMS provider that uses Atomikos for transaction management

The next step is to create the META-INF/spring/jms-services.xml where we define the ActiveMQ broker and tell it to interact with Atomikos for participating in transactions...


    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:jms="http://www.springframework.org/schema/jms"
 xmlns:broker="http://activemq.apache.org/schema/core"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-3.0.xsd
           http://www.springframework.org/schema/jms
           http://www.springframework.org/schema/jms/spring-jms-3.0.xsd
           http://activemq.apache.org/schema/core
           http://activemq.apache.org/schema/core/activemq-core-5.5.0.xsd">

 
    class="org.apache.activemq.ActiveMQXAConnectionFactory">
  
  
         
    
   
  
  
   
    
    
    
    
    
    
   
  
 

 
    class="com.atomikos.jms.AtomikosConnectionFactoryBean">
  
  
  
 

    useJmx="true" persistent="true" brokerName="localhost">
  
   
  
  
   
  
 

 

 
  
  
 

   class="my.application.jms.ClassImplementingMessageListener">

    connection-factory="connectionFactory"
   transaction-manager="transactionManager"
   acknowledge="transacted"
   concurrency="5">

Integrating Hibernate as a JPA provider that uses Atomikos for transaction management

Last but not least, the META-INF/spring/db-services.xml will add Hibernate to the mix, telling it to interact with Atomikos for participating in transactions.

Important Note 1: that I have a lot of ${database.variable} that I usually load from a property file; you should replace this with whatever values are suitable for your case.

Important Note 2: The hibernate.transaction.factory_class is explicitly shown as commented out, as I have seen quite a few people using it (due to picking up old Atomikos documentation) when it is NO LONGER NEEDED for things to work properly (see the Atomikos forum thread referenced in the comment).


    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-3.0.xsd">

    class="com.atomikos.jdbc.AtomikosDataSourceBean"
   init-method="init" destroy-method="close">
  XADBMS
  
   com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
  
  
   
    ${database.url}
    ${database.username}
    ${database.password}
   
  
  
  
  

 

 
   class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy">
  
   
  
 

 
            id="entityManagerFactory"
        class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        
        
        
            
                
                
                
            
        
        
            
                
                 org.hibernate.cfg.ImprovedNamingStrategy
                
                
                 ${database.hibernate.hbm2ddl}
                
                
                
                    com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup

Important Note 3:Remember to use JTA mode for transactions in your persistence.xml, as in:

...

Spring exception translation with AspectJ: bug workaround

2011-06-24T23:12:00.000+03:00

One of the nice features of Spring is the database access exception translation that simplifies error-handling. Most of us enabled it by adding the PersistenceExceptionTranslationPostProcessor (see the Exception translation in the Spring reference).

Unfortunately, when using a "pure-AspectJ" approach, you will find that the out-of-the-box JpaExceptionTranslatorAspect does not recognize the various JPA dialects out there. I was pretty dissappointed when I found that JPA access from @Configurable object instances does NOT undergo "proper exception translation".

Thanks to Martin Deinum's feedback I quickly "restored" this limitation by creating a custom aspect to invoke the "proper" exception translator (which in my case is the HibernateJpaDialect).

So, until this bug is resolved, the following aspect will take care of things:

import org.springframework.dao.DataAccessException;
import org.springframework.orm.jpa.vendor.HibernateJpaDialect;

public aspect HibernateJpaDialectExceptionTranslationAspect {
    pointcut entityManagerCall(): call(* javax.persistence.EntityManager.*(..)) || call(* javax.persistence..EntityManagerFactory.*(..)) || call(* javax.persistence.EntityTransaction.*(..)) || call(* javax.persistence.Query.*(..));
    
    after() throwing(RuntimeException re): entityManagerCall() {
     HibernateJpaDialect hibernateDialect = new HibernateJpaDialect();
     DataAccessException dex = hibernateDialect.translateExceptionIfPossible(re);

     if (dex != null) {
      throw dex;
     } else {
      throw re;
     }        
    } 
}

JDeveloper 11g 11.1.2 is out with Maven support (among others)

2011-06-12T09:34:00.002+03:00

Oracle have released Oracle JDeveloper 11g, version 11.1.2.0.0. Among other new features, such as JSF 2, my favorite is the Maven 2 integration!

Check it out! Download is available (as usual) from the technet site!

IMPORTANT NOTE: SOA & WebCenter are NOT yet available for this release, so you must stick 11.1.1.5 for such projects.

Using Beehive code (BEA WebLogic <=10.3.1) with recent versions of Oracle WebLogic

2011-05-27T14:10:00.001+03:00

Recent versions of the WebLogic Server no longer ship with Beehive libraries. As a result, old code that was based on Beehive must ne re-written so as to remove this dependency.

If you simply must deploy a Beehive project on a newer WebLogic Server, there is way to achieve that. Oracle will NOT support it of course, but if you decide to take the risk and go ahead with this anyway, here is how to do it:

Locate the library "wlw-system.jar" in your old WebLogic installation. Copy it to the library folder of your target domain (the one that is based on a newer WebLogic version that does not have Beehive). The folder is ${DOMAIN_HOME}/lib
Restart your domain's servers (in order to pick up the wlw-system.jar in their classpath)
Using workshop, look up the WebLogic shared libraries that your project uses. These are listed in the project properties at "Java Build Path --> Libraries"

For each shared library go to your Workshop preferences under "WebLogic-->Shared Libraries" and click "Edit.." to see the location of the library. Copy all of the EAR/WAR archives for these libraries into some "staging" folder (e.g. /home/yourusername/app-libs)

Deploy all of the archives (EAR/WAR) that you located in the steps above as shared libraries in your new domain

You may now deploy your application on servers where the shared libraries were targeted.

Using a different HTTP proxy per each JAX-WS client stub

2011-05-25T21:35:00.001+03:00

JAX-WS is about to standardize a web service feature, for specifying the use of a different HTTP proxy per each JAX-WS client instance. This can be extremely useful in complex enterprise IT environments, where network security teams are often paranoid and have different proxies for accessing different parts of the network. No longer do you need to host applications modules on different VMs just because they require different proxy settings. Instead of using the global http.proxyHost and http.proxyPort, you can specify a different proxy per JAX-WS client stub.

Since OFM 11gR1 Patchset 2, one can already exploit this upcoming JAX-WS feature, using WebLogic's ClientProxyFeature API. The approach is described in WebLogic's API Reference.

Although the documentation is pretty straight-forward, it fails to address the fact that the JAX-WS stack will try to retrieve the WSDL during the service instantiation, which leads to the following problem: since the ClientProxyFeature only applies at the web service port level, the following will fail:

// The service location is a runtime configuration value...
    URL wsdlURL = new URL(System.getProperty("serviceLocationAtRuntime"));

    // The below will try to fetch the WSDL from the wsdlURL location
    // The proxy is NOT in effect at this point and will cause a network error
    Service myService = new Service(wsdlURL, ...);

    // The code will never reach this point; so much for ClientProxyFeature
    ClientProxyFeature cpf = new ClientProxyFeature();
    cpf.setType(Proxy.Type.HTTP);
    cpf.setProxyHost(CONFIG.getProxyHost());
    cpf.setProxyPort(CONFIG.getProxyPort());
    servicePort = myService.getServiceSoap(cpf);

The solution is to bundle the WSDL as a resource in your application and instantiate the service using the local copy of the WSDL. Then, after enabling the proxy, you can set the runtime service address via the BindingProvider API.

// Don't go over the network to fetch the WSDL; use it from the classpath
    URL wsdlURL = Service.class.getResource("Service.wsdl");

    // The below will work, but will assume the service address is whatever
    // was defined in your application-bundled WSDL, so we still need to
    // somehow define a run-time location; keep reading to see how we do this
    // after getting the service port
    Service myService = new Service(wsdlURL, ...);

    // Enable the use of an HTTP proxy for this specific port instance
    ClientProxyFeature cpf = new ClientProxyFeature();
    cpf.setType(Proxy.Type.HTTP);
    cpf.setProxyHost(CONFIG.getProxyHost());
    cpf.setProxyPort(CONFIG.getProxyPort());
    servicePort = myService.getServiceSoap(cpf);

    // Now that we have the port, configure the service address using
    // a run-time value:
    URL wsdlURL = new URL(System.getProperty("serviceLocationAtRuntime"));
    BindingProvider bp = (BindingProvider)servicePort;
    bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
        wsdlURL.toString());

    // You can now call the web service via the HTTP proxy
    servicePort.invokeSomeOperation(...);

Mental note to myself # 8734874243

2011-05-18T11:36:00.000+03:00

Oracle SOA Suite 11g -- Repository notes

...because I always forget, let me put these down for my future reference!

Status values for composite instances

The following values are used for the CUBE_INSTANCE.STATE column of SOA Suite's "SOAINFRA" schema.

OPEN states	CLOSED states
INITIATED	PENDING_CANCEL
RUNNING	COMPLETED
SUSPENDED	FAULTED
FAULTED	CANCELED
	ABORTED
	STALE

Some SQL to quickly review statistics regarding the state of composite instances within some time window:

SELECT
  CASE state
    WHEN 0 THEN 'initiated'
    WHEN 1 THEN 'open.running'
    WHEN 2 THEN 'open.suspended'
    WHEN 3 THEN 'open.faulted'
    WHEN 4 THEN 'closed.pending_cancel'
    WHEN 5 THEN 'closed.completed'
    WHEN 6 THEN 'closed.faulted'
    WHEN 7 THEN 'closed.cancelled'
    WHEN 8 THEN 'closed.aborted'
    WHEN 9 THEN 'closed.stale'
    ELSE 'huh?'
  END state_text,
  COUNT (*)
FROM cube_instance ci
WHERE ci.creation_date >= (:startdate) AND ci.creation_date < (:enddate)
group by ci.state;

Status of “recently created” composite instances

What's going on with recently created instances?

SELECT
  CIKEY, STATE, CREATION_DATE, MODIFY_DATE, STATUS, 
  COMPOSITE_NAME, COMPONENT_NAME, COMPOSITE_REVISION, DOMAIN_NAME
FROM cube_instance 
WHERE creation_date >= SYSDATE-1 AND STATE < 5 AND ROWNUM < 20
ORDER BY creation_date DESC;

Status of “recently updated” composite instances

What's going on with recently updated instances?

SELECT
  CIKEY, STATE, CREATION_DATE, MODIFY_DATE, STATUS,
  COMPOSITE_NAME, COMPONENT_NAME, COMPOSITE_REVISION, DOMAIN_NAME
FROM cube_instance 
WHERE creation_date >= SYSDATE-1 AND STATE < 5 AND ROWNUM < 20 
ORDER BY modify_date DESC;

BoneCP: a promising new connection pooling library

2011-04-26T09:30:00.000+03:00

For a long time, we've been stuck with C3P0 and DBCP in the Java connection pooling arena. These tools, each with its own problems, have served us rather well. Competition from "newcomers" such as Proxool does not seem to have made much difference. At least this is what Google Trends comparison indicates.

BoneCP is a new contender in this area which has caught my attention. It is "Apache v2"-licensed, well-documented and (as far as I can tell from my limited use so far) stable and fast.

If you're looking for a C3P0/DBCP alternative it's worth giving a try. The only thing I am rather "nervous" about is the size of its community. It seems to be maintained by few individuals, but so are most new OSS projects prior to gaining wider acceptance.

So go ahead and have a look.

Migrating from Wicket 1.4 to 1.5

2011-04-24T16:17:00.004+03:00

Wicket 1.5 is just around the corner (currently in its 3rd release candidate). I've been peeking into the upcoming release, by moving some 1.4-based code to run against 1.5-RC3. Lots of stuff is documented in the official Wiki, at Migrating to Wicket 1.5. Here's my list of notable changes (i.e. what I had to change in order to get things working with 1.5):

1) Maven dependency has changed

The core artifact id is now "wicket-core" instead of plain "wicket". Change your dependencies. Other artifacts include: wicket-request, wicket-util, wicket-extensions.

2) It's JavaScript (camel-case) not Javascript

Most classes and methods that contain the term Javascript have switched to camel-case. Capitalize the S (and organize your imports, as some of them have moved) and you'll be back in business.

3) Header contribution is now implemented in Component and Behavior.

Most likely you've been rendering into the HTML header with something along the lines of:

 new IHeaderContributor() {
  @Override
  public void renderHead(IHeaderResponse response) {
   response.renderJavascriptReference(...);
  }
 }

No more. The interface IHeaderContributor is now implemented by Component so you can simply override that method and move this code over there. Similarly, Behavior has acquired the nice public void renderHead(Component component, IHeaderResponse response) routine which will basically let you do the same thing while holding a reference to the component where the behavior is attached. This is pretty straight-forward if you're updating a web page (see the Wiki link above). In short however, if you've been extending HeaderContributor itself, you can simply switch to extending a Behavior:

public class MyHeaderContributor extends Behavior {
 private static final long serialVersionUID = 1L;

 public static final JavaScriptResourceReference MY_JS = new JavaScriptResourceReference(
   MyHeaderContributor.class, "some-javascript-resource.js");

 public MyHeaderContributor() {
 }

 @Override
 public void renderHead(Component component, IHeaderResponse response) {
  response.renderJavaScriptReference(MY_JS);
 }
}

Of course, most likely there's already some component/page/behavior class where you'd simply move the code for rendering the header contribution.

4) Template-base CSS and JavaScript (TextTemplateHeaderContributor) must now be contributed to the header.

Just as shown immediately above, you must use the renderHead() method of Component or Behavior. So now you'd render your template with:

@Override
public void renderHead(IHeaderResponse response) {
 super.renderHead(response);

 PackageTextTemplate template = new PackageTextTemplate(
   YourComponentOrPage.class, "YourJavaScriptResource.js");
 response.renderJavaScript(template.asString(yourVariablesModel), "someMarkupId");
}

5) Page mounting

Have a look at the new API for mountPage() and mountPackage() and adjust accordingly. For example:

mount(new IndexedParamUrlCodingStrategy("/staff/details", StaffDetailsPage.class));

becomes:

mountPage("/staff/details", StaffDetailsPage.class));

6) Mounting of global resources

The Application now has methods for mounting resources. Their usage is rather straight-forward. Since the SharedResources.putClassAlias(...) method no longer exists, if you used to mount resources globally like this:

    protected void init() {
        super.init();
        getSharedResources().putClassAlias(org.apache.wicket.Application.class,
            "global");
        getSharedResources().add("images", new MyImageResources());
    }

You will now have to use the mountResource() method like this:

    mountResource("imgres", new ResourceReference(Application.class,
            "imgres") {
        private static final long serialVersionUID = 1L;
        MyImageResources imgres = new ImageResources();
    
        @Override
        public IResource getResource() {
            return imgres;
        }
    });

Jetty 7: add security realm in embedded server

2011-04-22T12:29:00.003+03:00

It's been more than a year since Jetty 7 was released. Still, even today, there exists code based on the 6.x series that has not been subjected to the process of being upgraded to the new version.

Most of the changes have already been documented in the web, so anyone that is starting to switch now, should find it easy: in most cases a quick search with terms describing your problem will immediately get you the answer to any question that may arise.

Surprisingly, this is not always the case. For example, A typical issue is how to configure a user realm (now referred to as a "loginService" in Jetty 7). Failing to configure this will cause a "No LoginService for XXX" exception. A junior developer was fighting with this and had located a nice set of instructions on how to do this with maven (which we use for our builds). The jetty-maven-plugin (note that it is no longer maven-jetty-plugin, the term "jetty" was moved in front of "maven") by editing the pom.xml to include it in the plugin configuration:

            
                org.mortbay.jetty
                jetty-maven-plugin
                ${jetty.version}
                
                    
                        
                            Test Realm
                            ${basedir}/src/test/resources/jetty-test-realm.properties
                        
                    
                
                
                    
                        org.eclipse.jetty
                        jetty-servlets
                        ${jetty.version}

However, this only applies when you use the jetty:run goal to launch your application.

What happens if you want to apply this in your IDE? We usually have a "test launcher" for running the application within the IDE to debug stuff. This launches Jetty from a simple Java application. In this case, you have to configure a realm in your code. I was surprised to be asked how to do this, by a developer that was aware of the POM changes required, but could not locate the respective changes for applying to the code-based launching of Jetty. So this is for all the search engines out there:

If you get:

java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.BasicAuthenticator in org.eclipse.jetty.security.ConstraintSecurityHandler

Then try launching as follows from your code:


  Server server = new Server();

  SocketConnector connector = new SocketConnector();
  // Set some timeout options to make debugging easier.
  connector.setMaxIdleTime(1000 * 60 * 60);
  connector.setSoLingerTime(-1);
  connector.setPort(PORT);
  server.addConnector(connector);

  WebAppContext webAppCtx = new WebAppContext();
  webAppCtx.setServer(server);
  webAppCtx.setContextPath("/");
  webAppCtx.setWar("src/main/webapp");

  HashLoginService dummyLoginService = new HashLoginService(
    "TEST-SECURITY-REALM");
  webAppCtx.getSecurityHandler().setLoginService(dummyLoginService);

  server.setHandler(webAppCtx);

  try {
   server.start();
   System.in.read();
   server.stop();
   server.join();
  } catch (Exception e) {
   e.printStackTrace();
   System.exit(100);
  }

The "software factory"

2011-01-19T22:39:00.008+02:00

Today I was contemplating that I've been working in software R&D for more than 15 years now. I actually started out in my mid teens, developing a CRM application for our family business. However, my first real job was at 20, in my 3rd year as a CS student.

During this time, I've experienced a broad spectrum of environments: from the small, rambo-programmer-syle organizations, to the large behemoths with distributed development teams and CMMI 4 processes. I have participated in projects using various development methodologies (V model, unified process, scrum agile, ...). I have produced software where "the code is the documentation", but also worked in government projects where full end-to-end traceability was required (in fact, looking back I'm not sure whether the team spent more time writing code and testing, or fighting with the Word add-on for Rational Requisite Pro and drawing UML).

This experience in varying work environments and processes has led me to settle in my mind, what I call the "software factory" infrastructure.

Just as all businesses that procure IT systems to help them automate their business processes, so too must solution delivery departments procure systems that support the delivery process.

So, here is my list of essential tools any software development shop needs to have:

Distributed SCM repository (Mercurial & Git are both excellent)
Issue tracking and planning (Redmine is my favorite, but Trac is also good).
Headless builds (I'm fluent with Maven, but you may want to check out alternatives such as Buildr)
Continuous Integration (Jenkins is my cup of tee here. Note that this was formerly known as Hudson)
A provisioning repository for binaries, such as nightly builds and releases (Nexus is an ideal fit for Maven)

I'm even running my one-man personal projects using the above.

I also like some code metrics and quality assurance, but I left it outside the list above as I am not very settled on this topic. Though if you're interested in this, I suggest you look into PMD, CheckStyle and Sonar.

It's not the ESB!!!

2011-01-16T11:50:00.005+02:00

Being the IT architect responsible for integration at Vodafone Greece, has recently put me in the spotlight of several business and technical teams in the company. The reason is that we made a major technical revamp of our integration architecture, which went live in two phases (first in August, the in October). As a result, the systems integration team received a lot of unwanted attention: if anything broke, we were the first ones to point the finger at!

I guess it's normal that upon every major IT deployment, there's always a few quirks and glitches to take care of. Middleware however (by nature) lies at focal point of the IT systems. Nearly all "online" business is either directly or indirectly affected by the ESB, our process engine, rules engine, etc.

Therefore, I was very satisfied recently when a colleague uttered the words:

"Oh, I don't thing it's the ESB... It's probably something in the [system X's] blah blah..."

It appears that people are beginning to trust the new middleware systems... and the should! We passed our first Christmas/New Year's shopping rush with ZERO incidents! For months now, we have been through numerous counts of problem troubleshooting, only to find that some sytem X is responsible for problem Y. And now, slowly but steadily, the psychology that "the middleware is stable" is settling in throughout the company.

We're out of the spotlight... and loving it!

Applying jQuery UI effects in Wicket, using wiQuery

2011-01-06T22:59:00.015+02:00

The wiQuery project neatly integrates two of my favourite frameworks: jQuery(UI) with Wicket. This post discusses how you can exploit jQuery UI effects using wiQuery.

The jQuery core effects (fade in/out, animate, etc) live in package org.odlabs.wiquery.core.effects. The extended jQueryUI effects (bounce, explode, etc) live in package org.odlabs.wiquery.ui.effects.

Adding an effect to a component requires that you simply add an EffectBehavior to it. While this is enough for the effects of jQuery core, it is not sufficient for the additional effects included in jQueryUI. Fortunately, the difference in using a jQuery UI effect is minimal: the approach is basically identical, except that you must additionally override the contribute(...) method, to make sure that the relevant JavaScript is added to the page.

So assuming you are trying to "bounce" a simple label:

<span wicket:id="myLabel">This should bounce...

Here is how you would overrided contribute(...) to include the extended effect.

package test.wiquery;



import org.apache.wicket.PageParameters;

import org.apache.wicket.markup.html.WebPage;

import org.apache.wicket.markup.html.basic.Label;

import org.odlabs.wiquery.core.commons.WiQueryResourceManager;

import org.odlabs.wiquery.core.effects.EffectBehavior;

import org.odlabs.wiquery.ui.effects.BounceEffect;

import org.odlabs.wiquery.ui.effects.EffectsHelper;



public class HomePage extends WebPage {



private static final long serialVersionUID = 1L;



public HomePage(final PageParameters parameters) {

 Label myLabel = new Label("myLabel", "this should bounce");

 BounceEffect effect = new BounceEffect();

 EffectBehavior eb = new EffectBehavior(effect) {

  private static final long serialVersionUID = 1L;



  @Override

  public void contribute(WiQueryResourceManager wiQueryResourceManager) {

   EffectsHelper.bounce(wiQueryResourceManager);

  }

 };

 myLabel.add(eb);

 add(myLabel);

}

}