Generally we don’t mind much about the internals of the frameworks we use (as long as they are good) – the whole encapsulation stuff is the last undoubted good thing. But except for the API (part of which is the configuration) frameworks have another user-facing end – the logging. When we build a system we want it to behave as one system – single configuration from one end, and single log from another (break it to different files, if you wish, but it should still be a unified logging system).

The reality is that there is no standard de-facto for logging. The standard de-jure – JUL, is not very popular because of its lack of functionality (compared to alternatives) and its suboptimal performance. And then there is Log4J, which almost became standard, but did not. And there is logback, which is a Log4J trashover, and there are facades (JCL and SLF4J), which try to unite all this zoo, and some others, which you have probably never heard of, like syslog4j*, logging framework by the Object Guy, jLo, MonoLog, Lumberjack, Houston, JTraceDump, qflog, LN2, TracingClassLoader, SMTPHandler, Log4Ant, Simple Log, Log Bridge, Craftsman Spy, Pencil, JDLabAgent, Trace Log, JDBC Logger, LimpidLog and Microlog.

Let it be, you’d say – why not have many logging tools, which are good and diverse! Well, the problem, as I’ve already mentioned, is that they leak out of the frameworks. Their diverse configuration leaks from one end, while their diverse output from another. Spring uses Log4J over JCL. So does Hibernate. Jetty uses Logback over SLF4J. Some (like Terracotta modules) use plain Log4J, Jersey uses JUL.  This means we end up with 5 separate configurations (Log4J, SLF4J, Logback, JCL and JUL) and 3 different types of log files (Log4j, Logback and JUL). What a system!

To make the long story short – How can we achieve the desired consolidation? Clearly, we need a facade. There are two most commonly used – SLF4J and JCL. JCL is known for its classloader hell, SLF4J is newer, better performing, smarter, simplier to use and generally provides better quality for the same buck (well, no buck – both are open source, of course), so we’ll stick to it. SLF4J is an adapter – thin layer of API to and from different logging implementations. Yap, both ways. It means with SLF4J we can use JUL API on top and log using Log4J in the bottom!

First we need to pick an actual logger. Log4j was considered the best choice up until recently (2006) when Ceki Gülcü decided he needed a fresh start and rewrote from scratch a new Java logging framework, just better than log4j, called Logback. We can give it a try as our underlying logging implementation (we can switch in a moment, as we are using  good facade, remember?).

So, here’s what we have to do:

1. Establish our own good logging:
   1. Add Logback to our classpath
   2. Add SLF4J API to our classpath

   Done here. Now our own brand new code will use top-notch logging.

2. Now for the tricky part. Let’s make the example stack I listed above taking configuration from one source (our config files) and writing to one target (files, listed in our configuration)
1. All the tools using SLF4J will just work. That includes dozen of Apache projects, inc. Camel and Mina, some SpringSource projects and many others.
2. Now let’s start rolling with all the rest. This is how you do it (click to enlarge):
   
1. Jakarta Commons Logging:
1. Remove commons-logging.jar from your classpath. Usually, it is transitive dependency from the framework, so you need to instruct your build tool on how to do it. What a lucky coincidence, I just wrote short and instructive blog post about how to do it!
2. Add jcl-over-slf4j.jar instead. It contains alternative commons-logging API implementation, so the code will run just fine.
2. Log4J:
1. Same goes here! Remove log4j.jar from your classpath (Again, it would usually be a transitive dependency from the framework, look here).
2. Add log4j-over-slf4j.jar instead. It contains alternative log4j API implementation, so the code will run just fine.
3. JUL:
1. Well, you can’t remove JUL from classpath (it’s a part of the JRE, dude). For the same reason SLF4J can’t reimplement JUL’s API.
2. Add jul-to-slf4j.jar. It will translate java.util.logging.LogRecord objects into their SLF4J equivalent.
3. Install SLF4JBridgeHandler and LevelChangePropagator.
4. Expect 20% decrease in performance (so use it wisely).

All done. Now both our code and all the 3rd paries configured from single source and write to single target. Hooray!

* syslog4j claims it is cross-platform. Well,  I’ll just quote: “Is Syslog4j cross-platform? Yes! Syslog4j UDP/IP and TCP/IP clients should work in any typical Java JRE environment.”

1. Same dependency, different jar names, two examples here:
1. The Jakarta Commons renaming effort: commons-io:commons-io:1.3.2 and org.apache.commons:common-io:1.3.2
2. The Spring Framework artifacts naming convention alternatives: spring-beans, spring-context, etc in repo1 versus org.springframework.beans, org.springframework.context, etcin
   SpringSource EBR.
2. Different packaging of the sample classes, many examples here:
1. OSGi repackagings: asm:asm:3.2 and org.objectweb.asm:com.springsource.org.objectweb.asm:3.2.0
2. Modularization of Spring 2.5.6: as single jar and as spring-whatever multiple modules
3. Xerces and Xalan are included in JDK since 1.5. They are still present as transitive dependencies in all the tools which support JDK 1.4.
4. Alternative packagings with and without dependencies: cglib:cglib and cglib:cglib-nodep
5. Project merges like Google collections, which are now included in Google Guava
3. Deliberately reimplemented interfaces, for example for bridging legacy APIs to new implementation, such as in SLF4J.
4. Your patches for 3rd-party tools.

All those may end up with 2 or more classes with the same name in the classpath. Why it is bad? Java class identifier consists of fully-qualified class name and the classloader that loaded it, so if two classes with the same name reside in same classpath JVM considers them to be the same class, and only one of them will be loaded. Which one? The first classloader encounters. Which one will it be? You have no idea.
When the duplicated classes are exactly the same, you will never notice. But if the classes are different, you’ll start getting runtime exceptions, such as NoSuchMethodError, NoClassDefFoundError and friends. That’s because other classes expect for find one API, but encounter another one – wrong class was loaded first. Not fun.

Now, when you know how evil they are, let’s take those bastards down!

Maven 2/3

There is no simple way (Maven’s tagline) to exclude some dependency from all the scopes. I’ll show two cases – manual exclusion and working with IntelliJ IDEA:

1. Stage 1: exclude all the banned dependencies one by one:
1. Manually edit Maven’s poms
1. For each evil dependency:
2. Find which top-level dependency brings the evil transitive hitcher with it. This is done by using Maven Dependency Plugin:

   mvn dependency:tree -Dincludes=commons-logging:commons-logging

3. You’ll get something like this:

   [INFO] com.mycompany.myproduct:rest-client:1.0
   [INFO] \- org.springframework:spring-webmvc:jar:3.0.5.RELEASE:compile
   [INFO]    \- org.springframework:spring-core:jar:3.0.5.RELEASE:compile
   [INFO]       \- commons-logging:commons-logging:jar:1.1.1:compile

4. Go to the pom.xml with your dependency management (you use dependency management, don’t you? If you don’t, don’t tell anyone, go and start using it) find spring-webmvc dependency and add an exclusion to it:

   1     <dependency>
   2     	<groupId>org.springframework</groupId>
   3     	<artifactId>spring-webmvc</artifactId>
   4     	<version>3.0.5.RELEASE</version>
   5         <exclusions>
   6             <exclusion>
   7                 <artifactId>commons-logging</artifactId>
   8                 <groupId>commons-logging</groupId>
   9             </exclusion>
   10         </exclusions>
   11     </dependency>

2. Working with IntelliJ IDEA:
   
1. Open Maven Dependencies Graph.
2. Filter it by the dependency you are looking for.
3. Select it and press Shift-Delete.
2. Good job! Your nailed them down in the current version of your build. But what happens when someone adds a new 3rd party dependency and brings some bad stuff with it as transitives? You need to protect your build from this scenario. So, stage 2: Fail the build if one of the banned dependencies ever added to the build with Maven Enforcer Plugin. Add the plugin to your root project pom:

   1 <project>
   2   <build>
   3     <plugins>
   4       <plugin>
   5         <groupId>org.apache.maven.plugins</groupId>
   6         <artifactId>maven-enforcer-plugin</artifactId>
   7         <version>1.0</version>
   8         <executions>
   9           <execution>
   10             <id>enforce-banned-dependencies</id>
   11             <goals>
   12               <goal>enforce</goal>
   13             </goals>
   14             <configuration>
   15               <rules>
   16                 <bannedDependencies>
   17                   <excludes>
   18                     <exclude>commons-logging</exclude>
   19                     <exclude>cglib:cglib</exclude>
   20                   </excludes>
   21                 </bannedDependencies>
   23               </rules>
   24               <fail>true</fail>
   25             </configuration>
   26           </execution>
   27         </executions>
   28       </plugin>
   29     </plugins>
   30 </build>
   31 </project>

3. As I mentioned, using the Enforcer plugin won’t exclude the unwanted dependencies, it only will fail the build. Once that happened (and trust me, it will), you need to go and exclude them manually, as described in Stage 1 above.

And we are done with Maven. Not fun? Switch your build tool!

Ivy

Well, comparing to Maven it’s emabrassing how easy is to add global exclusion in Ivy. All you need to do is add exclude tag, and it will do the job for all the transitive dependencies, both in current and future use:

1 <dependencies>
2     <dependency org="org.springframework" name="spring-webmvc"
3 rev="3.0.5.RELEASE" conf="compile->default"/>
4     <exclude org="commons-logging"/>
5 </dependencies>

Done.

Gradle

Since Gradle uses Ivy under the hood, here comes the same ease, but even groovier:

1     configurations {
2         all*.exclude module: 'commons-logging'
3         all*.exclude group: 'cglib', module: 'cglib-nodep'
4     }

That’s all! Now your code is bullet-proof from classloading conflicts and you can do nasty class-replacing stuff, for logging or pleasure.

Guess what? It was awesome!

Here’s my summary:

General:

The conference was combined with Rich Web Experience 2010, which probably, was the right thing to do for the first ever project automation seminar. It was announced 2 months ago, bringing 52 registrants (out of ~400 total for both events). Pretty impressive for such a short notice on such a narrow subject. The organization was fantastic, everything felt well-planned and well-orchestrated. It was my second NFJS conference, and like with the first one, they delivered!

Sessions:

The first speaker in the conference was the one and only Douglas Crockford in his notorious Quality talk. Top quality (pun intended) – funny, entertaining, and touching the right points. Bottom line – read The Mythical Man-Month and Literate Programming.

Yet another keynote was devoted to actually Project Automation. Hans Dockter laid down his vision on the topic, the idea being – we are entering very interesting times, better understanding of the needs combining with the right tools will enable us whole new level of project automation, way beyond what we are used to today.

Lots of fun and enriching talks, like Tim Berglund‘s Complexity Theory and Software Development or an experts panel, moderated by Ted Neward (who honestly tried to recall who I was and where did we met), and tons of useful and deep sessions and workshops, just to name a few: Fred‘s modularity and smart BRMs talks, Kohsuke’s updated Doing More with Hudson, Git, Sonar and Liquibase sessions from Matthew McCullough, Olivier Gaudin and Tim Berglund. The integration with Rich Web Experience gave the participans the opportunity to mix and match the sessions, and there was a lot of stuff to attend – HTML5, CSS3, Flash, iOS and Android development, Grails, Wicket and what’s not! 10 parallel sessions in any given time, now go choose one!

The sessions I gave:

First of all, it was my first speaking experience outside of Israel. I think I did well. At least the feedbacks say so The high speaker:attendee ratio produced small classes with live interaction, I loved it. As I suspected, 90 minutes are too long, looks like 60 minutes is my favorite format, but I managed to keep the audience awake

Here are my sessions:

• Maven 2 Gradle how to move away from Maven2 to Gradle (using gradle2maven, maven-metadata plugin or even manually). Demo included converting the whole Artifactory project to Gradle.
• Java Build Tools Jungle – overview the tons of Java build tools. Winners are (in that order): Gralde, Buildr, SBT.

By the way, Prezi rocks, as usual.

My next goal – speaking in a bigger seminar around spring 2011, probably on different topic, more relevant to my new job.

Florida:

December 1st – 30ºC, sun and ocean. That’s a typical room view. No additional comments needed, I guess.

Everglades and alligators rock too. It looks like this.

1. It is fragile.
2. It uses maven-help-plugin. Did I say fragile?
3. Changes in pom.xml aren’t reflected in your build – you need to regenerate the gradle build files (writing them over, destroying all changes you made – the script isn’t perfect in that sense).
4. Probably some annoying bugs.

Now it’s time for something more serious – the m2metadata plugin. In an essence, it takes metadata from Maven’s Project Object Model and builds Gradle project out of it.

More specifically it does the following:

1. Ask Maven to parse poms and settings xmls as it does during regular Maven build.
2. Set group, version and status (snapshot/release) for Gradle project.
3. Apply Gradle plugins according to packaging (jar -> java, war -> war). Currently those two are the only supported, but more are coming.
4. Get some metadata from well-known Maven plugins and configure Gradle plugins with it. This step currently includes setting Java compiler level and configuring sources and resources directories.
5. Add repositories.
6. Add dependencies (both external and inter-project).

That’s about it.

Now for the dark side. Currently, the m2metada-plugin clashes with maven-plugin (classloading issues). It can be worked around, but:

1. Maven-plugin is bundled, so it must be explicitly removed by deleting jars from Gradle’s lib directory.
2. The true power of m2metadata plugin is using it together with maven-plugin. M2metadata-plugin retrieves metadata part of maven build, while maven-plugin runs Maven’s runtime to execute goals like generating poms and deploying to maven repositories.

Yet another, more methodological than technical downside of m2metadata-plugin is that it preserves the usage of pom.xml. It works, so you don’t touch it, and it stays forever instead of being replaced with fully-blown build.gradle. For that concern, I see clear benefits in using the script solution, which trashes the pom.xml, leaving you with pure-gradle solution, and in conjunction with the idea-plugin gives you all you need to start going.

All in all, once the classloading issues will be sorted out, It looks to me that the mission of creating migration tool can be considered as accomplished.

You can find my work here (Usage guide in Wiki, TODOs in issues). I am going to present it (together with the script, which,as mentioned, has it own benefits) at The Project Automation Experience 2010 in the Java Build Automation Tools Jungle session. The presentation will be posted here once it will be ready.

• Properties file with server and database details (resides in classpath in this example):

1    db.host=localhost
2    db.port=27017
3    app.db.name=app

• If you don’t use Java-based container configuration (you should start using it!):

1. application-config.xml (or whatever you call it):

   1<beans xmlns="http://www.springframework.org/schema/beans"
   2       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   3       xmlns:context="http://www.springframework.org/schema/context"
   4       xsi:schemaLocation="http://www.springframework.org/schema/beans
   5           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
   6           http://www.springframework.org/schema/context
   7           http://www.springframework.org/schema/context/spring-context-3.0.xsd">
   8    <context:property-placeholder 
   9                location="classpath:db.properties"/>
   10    <bean id="mongo" class="com.mongodb.Mongo">
   11       <constructor-arg value="${db.host}"/>
   12       <constructor-arg value="${db.port}"/>
   13   </bean>
   14   <bean id="db" 
   15      class="com.mongodb.spring.config.DbFactoryBean">
   16       <property name="mongo" ref="mongo"/>
   17       <property name="name" value="${app.db.name}"/>
   18   </bean>
   19</beans>

2. The com.mongodb.spring.config.DbFactoryBean class:

   1 public class DbFactoryBean implements FactoryBean<DB> {
   2    
   3        private Mongo mongo;
   4        private String name;
   5    
   6        @Override
   7        public DB getObject() throws Exception {
   8            return mongo.getDB(name);
   9        }
   10   
   11       @Override
   12       public Class<?> getObjectType() {
   13           return DB.class;
   14       }
   15   
   16       @Override
   17       public boolean isSingleton() {
   18           return true;
   19       }
   20   
   21       public void setMongo(Mongo mongo) {
   22           this.mongo = mongo;
   23       }
   24   
   25       public void setName(String name) {
   26           this.name = name;
   27       }
   28 }
   

• If you do use Java-based container configuration – here’s your @Configuration class:

1    @Configuration
2    public class ApplicationConfiguration {
3    
4        @Value("${app.db.name}")
5        private String appDbName;
6    
7        @Value("${db.host}")
8        private String dbHost;
9    
10       @Value("${db.port}")
11       private int dbPort;
12   
13   
14       @Bean
15       public DB db() throws UnknownHostException {
16           return mongo().getDB(appDbName);
17       }
18   
19       @Bean
20       public Mongo mongo() throws UnknownHostException {
21           return new Mongo(dbHost, dbPort);
22       }
23   }

That’s, actually, it – enjoy. If you feel some part of the puzzle is missing, please leave a comment.

Spring Batch is a superb batch framework from, well, Spring. It covers all the concepts of batch architecture and, generally, spares you from reinventing the wheel. It’s cool, really. If you have batch-oriented application, you must go and take a look at Spring Batch. And if you don’t know what batch-oriented application is, just think about reading-validating-saving-to-db a zillion text files every night, unattended. Now you know what batch-oriented application is, go and look at Spring Batch.

Welcome back. As you’ve seen, Spring Batch constantly saves its state in order to be able to recover/restart exactly when it stopped. JobRepository is the bean in charge of saving the state, and its sole implementation uses data access objects layer, which currently has two implementations – in-memory maps and JDBC. It looks like this:

Of course, the maps are for losers testing,  JDBC implementation is the one to use in your production environment, since you have RDBMS at your application anyway, right? Or not…

Today, when NoSQL is gaining momentum (justified, if you ask me) the assumption that  “you always have RDBMS in enterprise application” is not true anymore. So, how can you work with Spring Batch now? Using in-memory DAOs? Not good enough. Installing, setting up, maintaining, baby-sitting RDBMS only for Spring Batch meta-data? Hum, you’d rather not. There is a great solution – just keep the meta-data in the NoSQL database you use for the application itself. Thanks to Spring, the Spring Batch architecture is modularized and loosely-coupled, and all you have to do in order to make it work is to re-implement the four DAOs.

So, here’s the plan:

• Implement *Dao with NoSqlDb*Dao
• Add them to Spring application context
• Create new SimpleJobRepository, injecting your new NoSqlDb DAOs into it
• Use it instead of the one you would create from JobRepositoryFactoryBean
• …
• Profit

That was exactly what I did for our customer, implementing the DAOs using MongoDB. Guess what, you must go and take a look at MongoDB.  It’s lightning-fast, schema-less document-oriented database, that kicks ass. When you suddenly have a strange feeling that RDBMS might not be the best solution for whatever you do, chances are you’d love MongoDB, as I do now. There are use-cases, in which you just can’t implement whatever you need to do with relational storage. Well, I lied. You can. It will take a year, it will look ugly and perform even worse. That’s my case, and I am just happy the year is 2010 and we know by now that one size doesn’t fit all.

I have to admit -implementing Spring Batch DAOs with MongoDB was fun. Even Spring Batch meta-data model, which was designed with relational storage in mind, persists nicely in MongoDB. Should I even mention that the code is cleaner comparing to JDBC? Even on top of JDBC template?

Now go and grab the Spring Batch over MongoDB implementation and the reference configuration: http://github.com/jbaruch/springbatch-over-mongodb. I have used the samples and the tests from original Spring Batch distribution, trying to make as few changes as necessary. You’ll need MongoDB build for your platform and Gradle 0.9p1 to build and run. (Why Gradle? Because it is truly a better way to build).

If you use MongoDB – enjoy the implementation as is. If you use some other document-oriented DB, the conversion should be straightforward. In any case, I’ll be glad to hear your feedback.

Last JavaEdge I delivered a session about Java build tools landscape. My impression from this overview is solid – Gradle rocks. It is a best of breed and takes the best from Ant and Maven2, leaving the downsides of both behind. Take at look, it is worth it (Prezi rocks too, but it’s another blog post).

The only fly in the ointment I found is lack of good maven2 to Gradle convention. Gradle has good maven support. First of all, it can use dependenices’ POMs to determine their transitive dependencies. Second, it has Maven plugin, but it works in the opposite direction – it can generate POM for your project, built with Gradle. I need the other side – something similar Gradle has for Ant – ant.importBuild() imports an Ant build into the Gradle project, and each Ant target is treated as a Gradle task. This is cool! Franky, I need much less with Maven.

Here’s the shopping list: I need to generate the following settings from POM.xml

• Dependencies (inc. scopes and exclusions)
• Correct plugins selection (e.g. war for web application module)
• GroupId
• Version
• Repositories
• Compiler level settings
• All those with full multi-module support
• All those with reuse support from inheritance and settings.xml

After a short search I discovered JIRA issue GRADLE-154,  in which Antony Stubbs asks for a subset of such functionality, and finally attaches a small Groovy script that parses given POM.xml and dumps to the console dependencies in Gradle format. That was a great start for me, but the drawbacks were obvious – no support for multi-module projects (I can’t recall when I saw single-module project last time), no support for parts, coming from settings.xml, etc. One specific pom.xml file in view has very little to do with the effective pom in runtime. You already got it, right? The parsing should be done on the effective pom, which is easily obtained using maven-help-plugin. So, having effective pom in hand, I can rip it apart and build nice set of build.gradle files, and the settings.gradle for the multi module support, and they include all the items from the above list!

I can assure you there are some bugs here and there in this script, but generally it works, and I managed to migrate fairly complicated project with war assembly, transitive dependencies, poms inheritance, artifacts exclusions etc. in a single click. “Is this cool or is this cool?”

So, grab the script, and give it a shot. It has two flags: -verbose prints out Maven output during effective pom resolution and -keepFile keeps the effective pom file for you.

Note the new task in the generated gradle.build – replacePoms. The idea is to solve the lack of IntelliJ Gradle integration when it comes to dependency management (IDEA knows how to run the build). Gradle generates poms for your modules. The gradle.build knows to copy them to the place where IntelliJ needs them. Just run “build replacePoms”, and IDEA will recognize dependencies from Gradle! Yup!

Enjoy.

P.S. You should check the new gradle-m2metadata-plugin, it’s the real thing – Maven3 embedded  into Gradle’s plugin. It gets all the metadata in runtime!

P.P.S. Sorry for my Groovy, it’s not my mother tongue.

First, problem definition:
Let’s take, for example, some serious global financial company, which needs training in Spring, Hibernate and JAX-RS. My contact point is a nice Training Activities Administrator. She just organized “Micro-Expressions Training for HR” and her next task is to organize my Java course. What do you say, will she be able to install IntelliJ IDEA (or Eclipse?), Spring 3 bundles, Hibernate dependencies and Jersey? And yes, the classroom network is detached from both Intranet and Internet (BIG financial company, remember?). Oh, I almost forgot a bonus – the training workstations rollback all changes after every restart.

Now, here are two possible provisioning solutions:

1. Come over day before for installs. Well, probably the classroom is occupied with another course. If not, the guy that should let me in the classroom, the network, and the computers is busy, sick or in Thailand, but probably all three in the same time. Ah, and I have another work to do on this day! And the customer won’t pay for it anyway. You got the point – bad idea.
2. Prepare the labs on CDs. Well, it generally works, most of the software courses delivered that way, one successful example is SpringSource trainings. You get nicely branded CD full of all you need – The IDE, the dependencies, and the labs source code. Good stuff, really. It works for SpringSource because of the high volume of catalog courses they deliver. They have a stock of identical CDs they use during every single training, worldwide. When it comes to tailor-made courses, things are different. No course is similar to any other course, the topics, installs, dependencies and exercises are unique set each time. That rather complicates the CDs craft – composing, burning, labeling. I don’t say it’s impossible – I did it for each and every course, but it’s a real PITA. And thanks to the reverting workstations, students will have to copy, extract, setup, define variables every day from scratch over and over again. Did I mention PITA?

And there is a third solution. The best one. You can use Enterprise Repository Manager to recreate students environment in a couple of minutes in any given time. Now, it rocks. It really is. Watch the steps:

1. Customer Requirements
   1. Two simple installs, every Training Administrator and/or Sysadmin can manage:
      1. IntelliJ IDEA (next-next-next) from JetBrains site. Or Eclipse?
      2. Maven2 (unzip) from Apache site.
   2. Create .m2 directory under user home for Maven user settings.
   3. Permission to connect your notebook to the class’ Intranet. It is isolated, the machines revert themselves, shouldn’t be a problem.
2. Exercises development
   1. Develop the exercises on  your notebook with all the Maven goodies – pom.xml, dependencies, superb IntelliJ-Maven integration (or Eclipse?).
   2. Install Artifactory locally (you’ll see why Artifactory and not Nexus in the following steps). I mean – download and unzip, heh. Run it (not even as a service)
   3. Import your local repository to Artifactory (can’t do it in Nexus #1) – zip it and make half-dozen of clicks in Artifactory UI.
   4. Deploy the exercises to the local repository. They probably won’t compile – they are exercises, right? Then just zip them and deploy from UI. Students will download them through Artifactory UI.
   5. Take the Artifactory down. You are ready to go to class.
3. Exercises delivery
   1. “Good morning, students!” – deliver the hell of the course, get to the hands-on part.
   2. Connect your notebook to the class’ Intranet, get dynamic IP (yap, dynamic is good enough).
   3. Get Artifactory up and running.
   4. Let the students browse to Artifactory’s homepage. There they will found Maven Settings Generator (can’t do it in Nexus #2), which will generate settings.xml to work with your instance of Artifactory from their machines. All they need to do is check “Mirror-Any”, select “repo” and save the generated file under .m2 directory. That’s all, their machines are fully configured to get all the dependencies needed for Spring, Hibernate, Jersey, and whatever you need for your training.
   5. Let the students browse the repository to download the exercises zip, unzip it, export Maven project into IntelliJ IDEA (or Eclipse?) and just start working!

As you saw, using Artifactory as labs delivery platform dramatically simplifies both lecturer’s and student’s life, enabling rapid exercises development and rollout without any preparation from student’s part and minimal preparation from training organizer’s part, all those thanks to Maven2 dependency management capabilities, good IDE Maven integration, and, of course, Artifactory’s ease of use. And frankly, there is nothing I love more than ease of use. Maybe only chocolate ice-cream.

Now, to the story.
On the surface it looked easy. We obtain connection, bla-bla, executeQuery, ResultSet.hasNext, etc. Works like a charm on clearly installed application. Once they populate the database with their home-made utility for migration from excel… boom. Thier code works, our throws IOEXception – “system cannot find the path specified”. The root of the exception somewhere inside the driver. Google suggests to update the driver to the last version. No prob! Done. Of course I move it from Tomcat’s share to the application lib on that occasion.
Guess what? Our code works like charm, but all other updates in application start failing on it can’t manually commit when auto-commit is on! As I understood it, they just didn’t turn auto-commit off, and the old buggy driver forgave them!

What can you do? The old driver stops working on durty database, the new driver won’t work with their application code. You can’t change the source of their driver wrapper to turn the auto-commit off, because it is closed-source, and you can’t be sure decompiler did a perfect work (and usually it don’t).

Anyway, we rolled-back the driver version, returned it to Tomcat’s shared lib, and went to their JDBC wrapper to look which shaman ceremonies they perform to make it work. We’d better not. They cast the driver to the actual jTDS class and call all kind of implementation methods. I am thankful to them they wrapped all those inside their JDBC wrapper, so all we needed to do is to replace JDBC code with some really strange calls like getQueryResults, which gets the SQL string (not parametrized, of course), and returns array of strings (contatining all the data, including dates and numbers).

So, what do you say? Any better way to do it except coding to the bug?