AspectJ runtime weaving within a Maven build
In order to perform AspectJ runtime weaving, an agent is required. Here we are using the agent (spring-instrument-3.0.3.RELEASE) provided by the Springframework. So for surefire we have to use a command line argument -javaagent: that specifies the JAR file containing the agent. To keep the build portable we copy that artifact to the build directory first using the maven-dependency-plugin.
Using Nexus and the Nexus REST API for implementing a software update tool
Nexus is using a pretty well documented REST API which is usable externally as well.
For one of my customers I implemented a kind of automatic software update tool that can be embedded into any product. It is based on the Sonatype NEXUS repository manager.
Spring has its own Expression Language as of version 3.0
Recently I have switched from the log4j logging framework to the logback framework. logback seems to have evolved into something better than log4j. It has cool features like the ability of logging into context specific logging files almost out-of-the-box (Using a sifting appender).
However the application has to provide the context (usually as MDC variables) which is kind of boring task to do.
So, I have implemented a fairly generic servlet that is able to provide almost any servlet request information for an active HTTP request. This servlet accepts a set of SpEL expressions (SpEL will be available with Spring 3.0) which are parsed and evaluated.
Finally it produces the evaluation results as MDC variables through the org.slf4j.MDC api (So I guess that might be usable for log4j as well).
slf4jmdc at...SpringExpressionSlf4jMdcRequestFilter mdcKeyExpression contextPath=${request.contextPath};username=${request.userPrincipal?.name}
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
StandardEvaluationContext context = new StandardEvaluationContext(new RootObject(request));
ExpressionParser parser = new SpelExpressionParser();
String[] mdc = StringUtils.delimitedListToStringArray(mdcKeyExpression, ";");
Properties expressions = StringUtils.splitArrayElementsIntoProperties(mdc, "=");
Enumeration> keyNames = expressions.propertyNames();
while (keyNames.hasMoreElements()) {
String key = keyNames.nextElement().toString();
try {
Expression exp = parser.parseExpression(expressions.getProperty(key), new TemplateParserContext());
Object value = exp.getValue(context);
if (value != null) {
MDC.put(key, value.toString());
}
} catch (ParseException e) {
LOGGER.error("Parsing expression", e);
}
}
try {
filterChain.doFilter(request, response);
} finally {
while (keyNames.hasMoreElements()) {
MDC.remove(keyNames.nextElement().toString());
}
}
}
This servlet can be used about anywhere MDC variables are needed!
Migrating Spring projects to Spring 3.0.0 bundle repositories
Since Spring has started its strong support for OSGi, all spring libraries have been turned into OSGi bundles internally. Subprojects (e.g. Webflow) eventually also started to publish their jars using the bundle naming scheme. With Spring 3.0 it looks we are at the final destination. As long as you stick to the more populare frameworks you get a pretty complete repository of Maven artifacts.
On one side it is good to see a unique naming for all of the spring + subproject artifacts. But for those of you starting to migrate existing projects this causes a few headaches. Everything is fine as long as you can get all of your favourite libraries from one of the SpringSpource bundle repositories
SpringSource Enterprise Bundle Repository - External Bundle Milestones http://repository.springsource.com/maven/bundles/milestone SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases http://repository.springsource.com/maven/bundles/release SpringSource Enterprise Bundle Repository - External Bundle Releases http://repository.springsource.com/maven/bundles/external
Fortunately they also provide a really helpful tool for searching their repositories.
But sometimes you won’t find your favourite ones and need to fall back to non-bundle style artifacts from non-Springsource repositories.
And here is the trouble: SpringSource is renaming the Maven artifactId for all of the bundles stored in their repositories (e.g. com.springsource.org.apache.commons.logging is the bundle equivalent of org.apache.commons.logging).
So let’s say you depend on artifact A that comes from the bundle repository (that depends on logging) and also depend on artifact B that comes from the standard maven repository (and also dependes on logging).
This will end up with a 2 dependencies to the logging artifact and Maven will not be able to distinguish since they have a different artifactId.
To resolve that, start adding dependency exclusions and dependencies for first level transitive dependencies.
I’m showing an example for the hades project that actually has a bug in their dependency description.
org.synyx.hades org.synyx.hades 1.0 org.aspectj aspectjrt org.aspectj com.springsource.org.aspectj.runtime 1.6.1
eclipse and corrupt WTP metadata
Yesterday night I had spent an hour or so tracking down a bug that has been bothering me for a while.
The effect of this bug is that projects created with the m2eclipse plugin seem to be missing some important metadata required by the WTP plugins. As a result references to other projects (in workspace) do not show up as JavaEE (J2EE) module dependencies or sometimes even the project properties dialog for JavaEE module dependencies only shows an error.
I had analysed this bug a while ago already but never documented this, some more investigation is still required to figure out what causes this missing metadata and report it to the m2eclipse developers.
Anyway here is how to fix it. Let’s say we have a web project A and a utility project B. You face the situation that project B does not show up as JavaEE module dependency. Open B in the navigator view (so you can see all the metadata files .project, .settings/… etc.).
Look for a file .settings/org.eclipse.wst.common.component! Does it exist? If no just create it, its contents should be like
Next check the .project file
PROJECTNAME
org.eclipse.wst.common.project.facet.core.builder
org.eclipse.jdt.core.javabuilder
org.maven.ide.eclipse.maven2Builder
org.eclipse.wst.validation.validationbuilder
org.eclipse.jdt.core.javanature
org.maven.ide.eclipse.maven2Nature
org.eclipse.jem.workbench.JavaEMFNature
org.eclipse.wst.common.project.facet.core.nature
org.eclipse.wst.common.modulecore.ModuleCoreNature
In my case the file was missing some builders (should not be relevant for the bug)
- org.maven.ide.eclipse.maven2Builder
- org.eclipse.wst.validation.validationbuilder
and some natures (these really hurt)
- org.eclipse.wst.common.modulecore.ModuleCoreNature
- org.eclipse.jem.workbench.JavaEMFNature
el-ri
Occasionally I need the EL reference implementation in my projects. JARS are hard to find. They seem to be provided by JBoss MAven2 repositories only. The repository URL is http://repository.jboss.org/maven2 .
javax.el
el-api
1.2
provided
javax.el
el-ri
1.2
provided
Maven Repository Index
Sonatype one of the companies actively contributing to Maven has brought their Nexus 1.0.0-beta online. Previously I was using mvnrepository for finding Maven artifacts.
I find Nexus much faster and it’s not polluted with ads and other stuff.
Embedding (constant) resources in a web application
Typically a nice looking web application would host plenty of icons in its document directories. Personally I use icons from the tango desktop project a lot. It is a library of hundreds of useful icons in multiple sizes.
So I would pull these file into my web project every time I create a new one and update these files as new tango version are released. This is not very handy as it is hard to synchronize these icons. On top of that code repository operations really slow down when checking out from or committing to the repository (just like it is with jars in the WEB-INF/lib folder).
As I have used Maven now for a while I had the idea of creating a kind of icon project that can be included in any web application just like an ordinary dependeny. This project only contains a project descriptor (pom.xml) which declares it as a project of type war. Further it includes the tango icons in the folder images/tango
plus a WEB-INF/web.xml (without any specific configuration, pretty much empty).
Any project that requires tango dektop icons just declares a maven dependency to this icon project. Any time this project is packaged (as a war file) Maven automatically unpacks the icon project into the packaged project and thus makes sure that it is up to date.
Maven2 eclipse web tools platform integration
When developing web applications it’s always been a hassle to keep the WEB-INF/lib folder up to date especially when starting to experiment with different versions of libraries or frameworks .
In the past (since being a Maven2 user) I helped myself with issuing the mvn war:inplace command to pull in all required libraries into WEB-INF/lib. So, occasionally I only would update my POM and rerun the command to have the latest versions of jars in my project!
This is extremely handy when using profiles for example to switch dependencies between a set of JSF 1.1 or JSF 1.2 libraries. Only with a twinkle I could change the classpath definition for any project. Ok so far this is nice.
For server development I’m working with the WTP plugin which makes handling a server a bit easier. So, regarding my library dependencies I’d feel more comfortable if they were updated every time I started my server (and thus publish the latest project files to the server).
So, I updated my m2eclipse plugin to 0.0.11 and tried to mark the Maven Dependencies Library Container as a J2EE Dependency, restarted my Web Container and was really excited that finally this is supported now. This means all of my dependencies from pom.xml are actually deployed to the server.
Maven Repositories
A short note to keep a few useful Maven repositories in mind.
- http://snapshots.repository.codehaus.org
- http://people.apache.org/repo/m2-snapshot-repository
- https://maven-repository.dev.java.net/

