Zepag's blog

Status of OSGi

2011-06-26T10:18:00.002+02:00

OSGi bashing seems to be a widely appreciated sport these days.
The worrying part is where it comes from.

As a disclaimer, I'd like to state that I quite love OSGi, because it provides dynamic modularity, lifecycle and many other things Java SE is lacking, and something the upcoming Java SE 8 modularity is not likely to provide. Besides that, it's available now and has been for a while!

This being said, OSGi is currently widely-used (at least this is where I see it used, not an exhaustive report):

in the embedded world (where it comes from)
in Software vendors products
in the core of IDEs or tools (mostly Eclipse of course) and application servers
Eclipse RCP rich clients

OSGi coming from the embedded world, the enterprise software scope has only been very recently integrated.
Even though tooling is getting better with time (Bnd, Bundlor, Pax and many more...), frameworks are easing development a lot (Spring dM, iPOJO...etc), and many companies are providing quality solutions and investing in it, OSGi doesn't seem to gain a lot of interest in mainstream development. Let me rephrase this explicitly: OSGi doesn't seem to gain the interest it really diserves.

The main problem is context. When development is shifting towards more deployment flexibility, the rigor of OSGi in this domain is both a bliss and a curse.

a bliss as it makes things really manageable at any scale.
a curse because of the difficulty for newcomers to easily integrate the dependency mechanisms and more important the difficulty to grasp/solve dependency issues.

This last point is quite important, as it is what has made people rant about Maven (and this still goes on) since its inception.

Easing dependency management is already difficult statically, so doing it dynamically is even harder. OSGi is REALLY doing a great job in this domain.

The main issue is that average enterprise developers, not the very clever ones hired e.g. by Oracle for the Glassfish team or by Spring for Eclipse Virgo (shameless plug there, I know or have met with people from these teams ;) ), don't want to deal with dynamic dependencies. Just as they don't want to deal with multicore development. Average enterprise developers want this to be hidden from them. This can be seen in each and every specification of JavaEE which seems recently to focus mostly on ease of development, sometimes leaving out ease of operations and flexibility. Enterprise developers don't want to know about multithreading or dynamic modularity.

Don't get me wrong, I think it's a shame. And once again I think OSGi is one of the best solutions for dynamic modularity.

Still when companies which embraced OSGi and invested a lot in it back out, things don't look very good.Mulesoft's founder Ross Mason started this a while ago after being disappointed by OSGi as a component model for Mule ESB. The Glassfish team embraced it, but only by hiding it behind the custom HK2 core model. The JBoss Team has implemented an abstraction above its microcontainer allowing to use OSGi, once again hiding it behind a custom layer.In the enterprise world, the only major actor (I mean no insult to the very brilliant smaller companies which provide quality OSGi enterprise solutions) embracing the OSGi model directly is (was?) SpringSource/VMWare.

What came as a surprise is Rod Johnson's recent words on that. Rob Harrop also backed this. Their seem to conclude that OSGi is hard to be made productive.Stated like this it's not really fair.There is little doubt OSGi is lacking many productivity boosters now found in modern frameworks: Convention over Configuration, Annotation based development helpers, Aspects, Transactions handling ...etcNevertheless I know for a fact that there are good solutions in the OSGi world. In fact, I think that if one compares OSGi to other dynamic modularity mechanisms, it is quite productive. It should not be compared directly to component models that leave out this dynamicity.

The problem I see is that the OSGi world seems to be stuck in an oldish development model that fits well enough the embedded world it comes from (where the aforementioned development boosters are not really key features). Hence my recent comment on OSGi being stuck in the smart card age, which I should have rephrased as "OSGi is still held back by its embedded focus".

OSGi specifications should now enforce development boosters and not provide them as optional choices.

It should be possible to create an OSGi bundle without a Manifest.mf file.
It should be possible to create an OSGi service providers/consumers just by adding an annotation to a class.
It should be possible to handle transactions easily.
It should be easy to operate bundles replacement.

Well be glad, all of this is possible. Then be sad, as major vendors seem to turn their back on it.

Two things in the end are really missing.
One thing really missing is an official repository (à la Maven Central) for OSGi bundles, provided by the OSGi alliance. Because adapting some existing libraries as bundles is really hard and requires a very good knowledge of the inner mechanisms of OSGi. What Springsource provides could be a good template for this.
The other thing missing is incentive for existing libraries/frameworks to provide OSGi compatible versions of their components. With companies like SpringSource sending mixed messages, it will become difficult to fuel this... Though one can't blame them for thinking that nodejs, rails, grails and such bring a breeze of fresh air to a regular OSGi developer ;)

Feelings and pointers from my Day 1 at Devoxx 2010

2010-11-15T18:37:00.000+01:00

This day (up until now) was dedicated to Hands-on.

I (sadly) arrived a bit late this morning, for what was in fact (not) a "hands-on".
It was a presentation of interesting tools: HDFS/Hadoop, and 2 alternative interaction points with Hadoop/HDFS: Hive (SQL92-like implementation) and Pig (scripted approach)

If you want to have a look at a Map/Reduce implementation with a SQL background, then definitely have a look at Hive!
Otherwise, Pig seems more powerful and should appeal to python-lovers.

In the afternoon, I went for Spring Roo and Spring STS presentations/hands-on.
This freshened up a bit my perception of these tools, as I may have to use a lot their most recent versions in the coming times.

Finally, I had a glance at a presentation about Code/API documentation. 2 pointers there: Bumblebee and JCite.

I'm now going to participate to Groovy/Grails and Spring BOFs.

More feedback to come later on.

(This weBLOG is meant to be read by his author only, If you happen to read it, please flash your memory and fall into sleep mode ASAP)

ExtJS: Structuring your javascript code (1)

2009-12-30T15:37:00.002+01:00

ExtJS and me ;)

In my search for good client application widgets, a few years ago, I started to look at YahooUI.
In these days ("days of yore" would be a tad inappropriate ;) ), YahooUI had some limitations, and only a few "out-of-the-box" widgets for "enterprise" applications.

The following is an approximated history of ExtJS, don't take it for granted... :p

At some point, Jack Slocum forked or bundled, or rewrote a whole lot of YahooUI, known in these days as YahooUI-ext (extension).
This is when I learned about it, thanks to my soon-to-be boss (javascript hacker in his spare time ;)).
Though as the project evolved, and the codebase got almost completely rewritten, the project began to include YahooUI as one of its core mechanims (and therefore YahooUI-Ext was not only an extension to YahooUI anymore), which was the major shift that made the renamed ExtJS a framework in its own right. From now on, YahooUI dependency could be completely removed, and other frameworks could be used as an core mechanism (JQuery, Prototype...).

At some point (version 2.0 and on) a specifically rewritten and optimized extjs mechanism was made available: ext-base. From there on, other frameworks were not even necessary anymore.

Javascript thingy... why OMG why???

In a few previous posts, I've already tried to debunk the javascript monster, in order to show that Javascript is a very good language, and that the monster in the browser is not javascript itself (though as every language, it's far from perfect), but the DOM one has to deal with (which differs from browser to browser).

As a web era guy, I've always felt deeply uncomfortable coding web interfaces with server-side languages (even if they are for rich-client-like applications). It has always made me feel like playing volley-ball knee-deep in liquid honey... (ok this is a weird image, though it conveys the message I guess).

In fact, HTTP is a disconnected protocol, and I've always felt like one should use the best tool on both sides.
Before a few years ago and the dawning of AJAX, the client side was in a "ask-for-page, display-page, submit-form" paradigm which made server-side handling of web sites still relevant.
With AJAX and modern frameworks like ExtJS, it is possible to build your client application with a notepad in an html file, and then provide a backend based on any technology you see fit: JavaEE, .Net, PHP, CGI...
Moreover, if you need to change the UI or refresh it a bit later on, you will have the opportunity to do it without touching the logic-handling backend.

I know for a fact that this ranting is directly (in my case) directed towards frameworks like JSF or GWT (the later being a specific case, as all it does is allowing you to code javascript + HTML + CSS in Java, and also because I think it's a damn good framework).

There are 2 tasks one has to handle with a javascript based framework like ExtJS (in fact 3, because the first is to know a bit more than average about Javascript) in order to achieve productivity:

Use an appropriate tooling: Javascript is not compiled, a validation tool is then required (and code completion is a nice-to-have)
Try to structure your code properly: This is (sadly) not very much documented.

I'll try to detail the second point in this post. For the first one, I'd recommend the use of Aptana, TextMate, or Spket in Eclipse. Visual Studio seems to have some Intellisense features for ExtJS. Learn more here.

The need to structure

When you download ExtJS, you receive a whole lot of good stuff. Among these a lot of examples...

What is hard to do is to try and begin an application.
Very quickly, you'll end up creating a grid, and asking yourself: "My Ajax server-side request seems to be called and returns JSON/XML, then why is it that my grid doesn't show the records?".
You'll soon see that extending the default stores and readers will allow you to whether use browsers' consoles (when they have one) or message boxes in order to give feedback on potential errors.
By default, the framework's widgets are quite silent about this.

Though all the hooks are in place, allowing you to add the expected behaviour (e.g. a popup when server-side errors occur, or even a retry policy, or displaying a loading icon...).

In order to achieve and more importantly maintain that, a bit of structure is necessary.
This is what I'll try and demonstrate in my next blog post.

Mule will do the hard work, I'll do the reading

2009-08-10T22:12:00.001+02:00

http://ddossot.blogspot.com/2009/07/mule-in-action-now-treeware.html
Mule in Action has been out for a while now, though as I don't live overseas (well...depends from the point of view... or not... ;) ) it took a bit of time before I received my order.

I'm now the very glad owner of a "Mule in action" book.

I can only recommend it to anybody wanting to deal with the donkey beast.
It is fully packed with ESBntegration knowledge, from basic to very technical details!

Everything you should know about Mule 2.x is in this book.

Very good work from the very brilliant David and John!

Go and order it!

Jazoon Day 1: Open UAT (Universal Authentication Toolkit) for devices

2009-06-27T09:00:00.002+02:00

Out of Band (OOB) Channels

Visual channel (barcodes)
Audio channel (key encoded by audio)
Manual string comparison (comparing codes)
Accelerometer data (devices shaken together)
Button presses (buttons pressed at the same time)

J2ME Polish

Nice tool to specify the target of the build

ScreenSnap

In-device capture application for Java ME

This Open UAT system would be interesting on Google Android for example...

Jazoon Day 1: Rules engines overview and case study

2009-06-27T08:59:00.003+02:00

Motivation for the use of business rules

updates in business rules have to change overnight

Core idea

Treat business logic as business data

BRMS (Business Rules Management System)

BOM vs XOM

Business Object Model vs Execution Object Model

iLog vs Drools
equivalence of features.

Business Rules format
when

then

Advanced Features

Custom, Higher level business language (translated to the same rules behind the scene
Rule security

Rules engine and SOA

Used for Monitoring of SLA

Rules engine and CEP (Complex Event Processing)

Almost all BRMS have a CEP engine (well to me it seems a bit weird to say that... all engines have it, so it must be useful... :p )

A bit of feedback on 2 projects with iLog and CLIPS.

Jazoon Day 1: Maven 3.x, Tycho

2009-06-27T08:57:00.002+02:00

Lots of attendees!!

Maven 3.0

Fewer modules
Simpler codebase
Better IDEs support
Integration Testing
Backward compatibility

Pom in multiple formats (groovy, ruby)

PluginManager externalized

Queryable lifecycle

Execution plan is defined up front and depending on the environment, what it will execute will be different (compilation with JDT In Eclipse for example)

Plugin Extension Points, Lifecycle Extension Points

Error & Integrity reporting fixed

Mercury

async http client with ssl and streaming PGP, WebDav.
Designed as standalone, Mercury can be embedded
SAT4J (pseudo boolean solver) for dependency resolution

Guice + Peaberry

Plexus will be replaced
Peaberry is the equivalent of Spring dm for Guice

Incremental build support

Extensible reporting

M2Eclipse

Lots of real improvements with Maven 3.0
M2E configuration framework
Real round-trip between Eclipse and Maven Pom! NICE!!!!

Planned for September/October... can't wait... in fact, maybe I won't ;) at least for Maven 3.0!

Nexus presentation: interesting point: compatible with P2 and OBR
http://repository.apache.org
http://repository.sonatype.org
http://oss.sonatype.org
http://osgi.sonatype.org

Hudson

Drools workflow to build release processes
Integrating JSecurity (Apache Shiro)
REST layer
Maven 3.0 like plugins
Eclipse incremental compiler

Gosh this presentation is full of good news! Hopefully the result will be as good as promised...

Jazoon Day 1: Glassfish v3

2009-06-27T08:55:00.003+02:00

RRails native deployment
Modular because of the requirements of Java EE 6 Profiles

Modularity

Based on OSGi (Apache Felix by default)
190 bundles (too many probably, but necessary at first, will decrease through time...or so they say ;))
Modules have responsabilities (provide services) and a lifecycle
Maven was used for the build

Developer features

Integration with IDEs
Fast startup, restart in debug
Exploded directory deployment
therefore... Fast deploy on save
Preserve session across redeployment
Application runner: java -jar glassfish.jar myWebApplication
> Maven/ANT integration
> Award winning UI console

Java EE 6 EJB 3.1 in web apps is really a very nice feature. It also seems that @Resource can now inject elements that come from other sources than JNDI! NICE!!

Runtime

Kernel
startup/shutdown
deployment
configure reading
Services
Java EE 6: Security, Naming Manager
Products; Admin consoles
Containers
Java EE 6: Web Container, EJB Container...
Other possible custom containers (RRails)

Application container

Deployment
Configuration
Commands (CLI, REST operation)

Service Based Architecture

HK2 Services: Abstraction to OSGi services
Per thread / Per scope scopes
Integrated lightweight dependency injection
Based on annotations (Container, Service, Inject...)

OSGi services can be injected with @Resource Java EE annotation.

Jazoon Day 1: Spring 3.0

2009-06-27T08:51:00.002+02:00

Java 5+ foundation

even more support for annotated components
BeanFactory returns typed Beans
T getBean(String name, Class<T> requiredType)
TaskExecutor extends java.util.concurrentExecutor
extended AsyncTaskExecutor supports Callables and Futures
Typed ApplicationListener
ApplicationEventMulticaster detects declared event type and filters accordingly.
Annotated Factory Methods
Use of Meta-Annotations
This is indeed really great! It allows to potentially have only annotations from your own packages in your code.

Portfolio rearrangements

Spring OXM now in the core
Revised binding and type conversion infrastructure: Superseeding standard JDK PropertyEditors

Spring Expression Language Unified

a kind of unified EL++
EL default attributes: systemProperties, systemEnvironment, and any spring bean through its name(s)
Contextual attributes depending on scope (access to request/session attributes for example).

REST Support

Client and server side
Defining URIs
JAX-RS

Declarative model validation

Hibernate Validator, JSR 303
Annotating fields with constraint annotations

Support for Portlet 2.0

action/render/event/resource request mappings

Early support for Java EE 6

JSF 2.0
JPA 2.0
JSR 303

New Namespaces

Scheduling namespace
@Async annotation for methods
@Scheduled for cron-triggered methods
Namespace allows scanning of these annotations, and declarative equivalent Expressions
Custom CRON support

Pruning

Commons Attributes support
TopLink API
Subclass-style Struts 1.X

Deprecations

traditional MVC form controller hierarchy: no new features
traditional JUnit 3.8 test class hierarchy => now Test Context framework

Jazoon Day 1: Concurrency and Performance reloaded

2009-06-27T08:48:00.004+02:00

Already lots of issues in single-threaded applications.
Moore's law is continued by multiple cores.
Concurrent programming is not possible yet, we can only cope with it.

Sadly (or not) concurrency is the main programming focus nowadays.

We have to deal with concurrency explicitely while before you could just wait for the platforms to improve and gain performances ;)

Problems:
- Hardware components are not shareable.
- Access to shared data has to be serialized.
- Databases offer access to shared data.
- Serialization limits scalability.

He then talks about Amdahl's law (parallel computing is limited by the time needed for the sequential part of the computing)
and Little's law (Throughput is inversely proportional to service time).

In Java: locking is pessimistic. Huge problem.

In fact 99% of locks are almost never really contended, and a large part of those will never be contended at all by design.

In Java 1.5, we have Java Locks and system level locks (hotspot profiles the application and determines if a lock is contended or not, and choose one or the other)

Lock coarsening uses one lock only for nearby equivalently locked operations.

Compare And Swap (CAS) used in Atomic classes. Fails only if another threads updates the data during your access. Needs less locking.

Biased Locking:
If a thread continuously acquires a lock, CAS is not used, and the thread keeps the lock until another one is reclaiming it (unbiasing)

How to code this correctly:

java.util.concurrent of course (Atomic*)
Lock striping (ConcurrentHashMap)
Teaching threads to steal (after all Garbage collecting is doing it).

In 1.7: Fork-Join

Fully concurrent lock-free algorithms:
No blocking, threads are never waiting for anything.
Wait free is different of course but should be achieve
Parallel reads, serialized writes

NonBlockingHashMap scales very well up to 1000 CPUs even for R/W, when ConcurrentHashMap doesn't.

Fully concurrent lock-less FIFO?
What does FIFO mean in multicore?
=> Doug Lea's wait-free queue (getAndSet(V))

Things that don't make sense
Iterator
Size
Contains

These are not relevant in highly concurrent environment.
APIs must therefore be re-thought through.

Very nice yet intricate talk. Too bad there's not more time for Dirk Pepperdine to go more into details!

Jazoon Day 1: Keynote by James Gosling

2009-06-27T08:47:00.003+02:00

Starting with the JavaOne video
J.Gosling is then talking about network orientation, and the fact that Java is more about the JVM(s) than the language.

He then demonstrates Glassfish v3 (finally, EJBs in webapps...) and Netbeans v6.7 which looks honestly pretty slick...

Then talks about Real time JVM, and Intelligent Meshes (Sunspot (Squawk) VM, Sentilla.com).

Talking about Hybrid car of Neil Young ;). May I suggest the guy is a little cocky there? ;);)

Performance in java
Actually better than C/C++ in most cases.
He then demonstrates the now common assertion that Moore's law is now wrong if you don't consider the number of cores (not if one takes them into account).

Funny point on the fact that most of what is happening on scientific calculation is driven by the progress of video games.

A bit of advertizing on JDK 7 talk the following day.

Java 6 updates (from 10 on)
Fixes Desktop integration
G1(Garbage first) collector
Compressed pointers 32G==4G

Web as the face of the Enterprise
=> JavaFX: same result as Flash, yet easier... still not convinced by that... :p

OSGi DevCon Europe: Emulation of Devices with Flash and OSGi

2009-06-23T09:05:00.002+02:00

Interesting presentation on the emulation of devices.
The word "Device", in the embedded "world", is used to describe technical component which does only one kind of thing with a clear contract (display, sound, gesture capture...etc).
Therefore, an iPhone is an assembly of devices.
The iPhone development scheme is sadly inefficient in terms of testing.

In order to test devices properly, they are advising to build an OSGi bundle for each device, and a flash interface for the device with xml-sockets (or any other equivalent client technology).

Note that the client part is not mandatory, but allows product owners to define additional features and even capture test scenarios.

Sadly, they are not open-sourcing (yet?) the framework they built for that.

Wow... this was a fully packed day...

OSGi DevCon Europe: RFID and OSGi devices

2009-06-23T09:03:00.001+02:00

Collecting real data and analyse it in the I.T.System.

Learned about MOSGI (JMX for OSGi) RFC 139

Learned about ALE reports which are events published by RFID Readers.

Starting to be a bit tired... too many presentations in one day :p

OSGi DevCon Europe: Transactions with OSGi

2009-06-23T09:01:00.001+02:00

Presentation is very good. Clement Escoffier is very dynamic, and has good vocabulary, and a very pronounced frenchy accent and grammar ;) (who am I to say?)
Very good explanation of the basics of transaction. Should be learned in schools as is ;)

Indeed transactions are hard to handle in a system where the transaction manager bundle or the transaction participants can leave during a transaction!

iPOJO Transaction Handler does that (amongst others). I'm still not clear if this is part of 4.2 release of OSGi.

OSGi DevCon Europe: OSGi + Spring Integration

2009-06-23T08:57:00.001+02:00

A little definition of "Performance"

Response time (classic)
Throughput (concurrent processing)
Utilization (Map-Reduce)

Scalability & Reliability (you have to choose a good balance between both)

Code supernova

Nothing is perfect
Code bases shall grow
Teams grow, you get more people and therefore more bad developers
More bugs.... ad lib...

I really like this concept ;). It fits so many projects have seen which are more patchworks than real products!

Single Thread Breakdown

One thread => single core
You can deal with more requests, but hardly improve a lot the treatment of one.

Synchronous breakdown

doing something, call another component , wait, finish.

Spring Integration is about EIP

Allows decoupling, if you add this to OSGi it's a nice combination.

Very nice and professional demo, done with very nice Spring STS ;)

OSGi DevCon Europe: Nimble

2009-06-23T08:55:00.001+02:00

YA Dependency resolver/Provisionning tool ;)
Looks interesting.

Once again, Artifacts, Capabilities and Requirements (see p2)
The structure there is a "Part" (see p2 IU in a sense)
a "Rule" is a template for a "Part"
It also defines a concept of Extensions.

Gosh... such a short presentation on this results in a mess...

Demo
A lot better with a demo...

Nimble allows you to enforce Policies on provisionning. NICE!!!

http://nimble.codecauldron.org/

OSGi DevCon Europe: p2

2009-06-23T08:54:00.002+02:00

p2, modular provisioning for OSGi

One consistent model from installation to servicing.

Concepts:

Everything is an Installable Unit (IU)
IU can have:
Actions (steps to perform to fully deploy)
Artifact reference (allows to reference dependencies without pointing directly to its location)
Capabilities and Requirements
Artifacts are:
Bytes/content to be installed (JARs, binary executable, RPM, MSI... etc)

God these presentations are too short.. The guy is talking too fast.
In the end, I already thought p2 was a bit of a mess, and as much as I want to like it, I'm still not clearly convinced by it.

OSGi DevCon Europe: Blueprint services

2009-06-23T08:48:00.000+02:00

DI, yet Legacy code-compatible, OSGi Dynamics, Hide OSGi API

Configuration:

Uses the extender pattern: The Blueprint Extender scans bundles to find xml files, creates metadata from them, and then creates beans, services, references.

Manager Types:

Bean Manager: creates POJOs and possibly wire dependencies.
Single Service Reference Manager: one to one mapping with OSGi service
Multiple Services Reference Manager: one to many mapping with OSGi service
Service Registration Manager: Allows to register a POJO as an OSGi service

Bean Manager

takes as input a configuration which is very close from the Spring bean configuration.
No, in fact it is Spring configuration reloaded... ;)

To summarize: BluePrint is a standardization of Spring DM and of Spring DI configuration.
BluePrint already has other implementations (amongst them Geronimo Blueprint by G.Nodet who gave this talk)

OSGi DevCon Europe: POSH

2009-06-23T08:44:00.000+02:00

POSH: Paremus OSGi Shell

RFC 0132

The man is yelling! ;) (Microphone too close to his mouth)

Yet the topic is interesting, it's about standardizing OSGi commands between frameworks.
For example "ss" in equinox is "ps" in Felix...
Not open source... even if pieces of it are part of Newton :p

OSGi DevCon Europe: Pax

2009-06-23T08:37:00.001+02:00

Tools and service implementations (framework independent)
Widely used (Apache Felix, Mule... etc)

PaxConstruct

A bit like maven archetypes (on steroids) for OSGi.
pax-create-project -g foo -a bar
pax-wrap-jar
...etc

PaxRunner

Standard launcher for major frameworks (Apache Felix, Knoplerfish, Equinox, Concierge...)
Does the provisionning of required artifacts
Generates Configuration files
Generates packages for a target platform

PaxExam

Allows testing of OSGi services. NICE!
Compatible with JUnit 4 and Maven for setup.

OSGi DevCon Europe: Remote Services, Yet Another one ;)

2009-06-23T08:05:00.000+02:00

Remote Services demo

service.exported.* properties for registered services
NICE!!! OSGi service exposed with CXF
NICE' !!! Discovery mechanism is in the works for the client side

Presentation of an Asynchronous remoting example/experiment.
This is not really available right now... and seems to be an example implementation.
Yet interesting ;) implemented by an OSGi Event dispatcher that allows to decouple from the implementation.
Drawbacks: No guaranteed delivery, No error handling with existing API. At least not yet, but this is experimental.

Demo of ActiveMQWrapper behind the EDS (EventAdmin is the point of contact)

http://cxf.apache.org/distributed-osgi.html (RI of OSGi 4.2 Remote Services)
http://lightsabre.fusesource.org (OSGi Asynchronous Messaging, experimental)

OSGi DevCon Europe: Persistence

2009-06-23T08:01:00.002+02:00

OSGi Persistence

Java Persistence standards

JPA
OXM: JAXB 2.X
EDIT (see comments)
OXM: SDO 2.1.1 JSR 235

Eclipse Link

JPA, MOXy (Object-XML), EIS, SDO, DBWS (XML-relational...Oracle :p)
Currently JPA 1.0 compatible, and working on 2.0

MOXy

Complete Object-XML mapping
Provides external mapping file! NICE!!! Never understood why they didn't give that option in JAXB...

EclipseLink available as OSGi bundles

Supports usage of standard APIs (Persistence.createEntity, JAXBContext.newInstance(), commonj.sdo.HelperProvider)
Supports modular packaging
Decouples application from provider (Through JPA tag)

Challenges for OSGi and JPA

Bootstrap in JPA scans the classpath
Provider needs access to domain model classes
Needs access to JDBC driver (addressed RFC 122)

Challenges for OSGi and JAXB

Spec SPI does not support registration of providers
Provider needs access to domain model classes
Though supports passing domain model classloader

Challenges for OSGi and SDO

Spec hardwires everything so it doesn't support custom providers

JPA 2.0 will include dynamic resolution.

OSGi DevCon Europe: Remote Services

2009-06-23T07:57:00.001+02:00

Module management in java

Mystical class path
In the end, classpath is flat
With OSGi: explicit dependencies, yet declarative
Allows events, dynamic handling, introspection
Services in OSGi allow to reduce coupling, but when package dependencies are explicit it limits the modularity.

Service Registry

Registering services by name, therefore allowing to reference a service without dependency on the implementation

Distributed OSGi

Remote can be separate machine, or separate JVM
Why? Isolation, Redundancy, Distribution is needed by your architecture

OSGi 4.2 Remote Services

Service Hooks (can intercept service requests)
Proxies
Intents (denotes an abstract distribution capability, requires mutual agreement, derives from SCA)

Very Nice: R-OSGi Deployment definition tool for Eclipse!

Remote Services Mostly based on the fact that services are stateless.

Work in progress: replication,Research prototype: Cirrostratus

Interesting as this allows completely virtual deployment of bundles.

Though it is unclear how much of what is presented is actually really available. Presentation is tough to follow, yet very interesting.

To summarize, seems that for stateless services, OSGi 4.2 would be enough, Cirrostratus prototype deals with state replication, service migration and hardening policies.

OSGi DevCon Europe: Keynote

2009-06-22T21:48:00.000+02:00

Keynote

Detailed description on what's going to be available in next releases (Core, Compendium and Enterprise).

Launching:

Need for a standardized launching system
Allows to embed easily the framework in your application
Using the service system of Java 5 (META-INF/services)

Service Hooks

Allows to listen service access events, therefore allowing interception for example.
FindHook, EventHook and ListenerHook.

Negative Permissions

Java 2 permissions: Very heavy to enumerate explicitely what is authorized and skip what is not.
Adding DENY and ALLOW. This is very nice! If it could just be implemented this way in Java 2 permissions...

Remote Services

RFC 119 (Formerly Distributed OSGi)
Remote access to OSGi services, protocol-independent.

Blueprint extender

RFC124
Provides Spring DM-like Functionality
Provides Service damping (wait until service is available) which is a very nice feature!
Defined through XML, a Blueprint container retrieves Metadata for Beans, Services, and References, and then creates corresponding elements from these metadatas.

Enterprise release

Transactions, JDBC, JMX, JNDI, JPA, Connectors

Experimental

TSL Tiny script language
Uses reflection but simplifies syntax (no new commands)
Sounds fun!

Nested frameworks

Application servers need an application model
in OSGi: Application==set of installed bundles
Compromise: frameworks should be nested

Java Modularity

module keyword would be nice for OSGi
The rest is over simplistic and will probably introduce more issues than it will solve... and BTW, it will only be available in Java 7 (why a language feature for that????)

BTW First time I hear a dog barking in a conference ;);)

Conferences in Zurich, day 1 : OSGi DevCon Europe

2009-06-22T08:31:00.000+02:00

Starting my blog marathon, especially for you, my reader ;).

Today is the day before bootstrap of Jazoon.
Today is community day and offers 2 conferences: One about Glassfish, and another about OSGi.

I must say I would have loved to attend both, but, as always in this kind of conference, you have to make tough choices.

Well... not so tough, as OSGi DevCon talks have a lot of diversity whereas Glassfish talks are a lot about Glassfish...
Let's say I used diversity as a filter and leave it at that.
I'll definitely try to attend some Glassfish 3.0 talk during Jazoon anyway.

So stay tuned for regular updates my dear reader, and have a nice monday!

My wishes for a better Maven 2

2009-05-27T16:34:00.003+02:00

My main concern with maven builds is their lack of stability. Mostly in terms of dependencies.

This is why I think that the following simple (apparently as I guess implementing them, though it seems simple to me, would possibly imply errors in exotic plugins) wishes would save the day of a whole lot of people (including of course... me ;) ).

First things first: Exclusions.

In a perfect world, everybody would declare dependencies properly (with a proper scope defined for
each, and optional dependencies declared... optional...) and versions resolutions for conflicting dependencies would work exactly as expected.
If you have used any of the repositories out there (even official ones) you know that some weird dependencies can irrupt in your project's Manifest.mf file, WEB-INF/lib folder, or any other proper place to put transitive or direct dependencies of your artifact.
Moreover, if you are building complex multi-modules project, you'll know that versions are not always resolved as they should.

Right now, the only option is to exclude artifacts one by one. What a pain in the arse!
Please please please, add wildcard exclusion!!!, or even better, a <transitive>true|false</transitive> element to the <dependency/> element.

One step further: I don't care about transitive

In some cases, you'd want to experiment, or are quite sure about the dependencies you want, but for a precise reason, don't want to retrieve any of the transitive dependencies.

It would be really nice to add a <transitive>true|false</transitive> element to the <dependencies/> element of the pom.

You would then be able to declare all the dependencies of your project without relying on transitive mechanisms.

This would really be an asset when you are handing over your build to maintenance, or building a stable release.

Even better: How about making this automatic

How nice would it be in this case that when the project is in the early dynamic phases, you specify your basic dependencies and retrieve the rest transitively, and...
...then...
At some point where you want to stabilize things or be sure of the outcome, you just launch for example: mvn dependency:flatten and "Voilà!" your pom.xml now contains all your project's transitive dependencies, with appropriate scopes computed, and the aforementioned <transitive>false</transitive> element added to the <dependencies/> element.

I for myself would find this very intuitive and simple to use, without interfering with the current behaviour of maven at first glance (backward compatibility my friend!).

For something completely different: splitting the local repository

This last wish is likely to remain a wish as I think it would require too much work.
But it's a sad thing that the local repository is not split between a plugins repository and a artifacts repository in some way.
The plugins repository would contain plugins and all their dependencies, and the artifacts repository would contain other artifacts and their dependencies.
This would disallow the intrusion of plugins' dependencies in your build.

Though this wish would not be a real issue anymore if the previous wishes could be granted.

To sum it up: Dynamics and Automation, plus Control!

Maven 2 is a great tool and offers a very good way to have build with dynamically changing dependencies. When set up, you don't always have to go and look for the latest build of your dependencies, and can automatically retrieve them.

Though sometimes, a bit more control is needed, and it would be very nice to have this kind of choice.

EDIT: After wishing I did my homework and went voting for http://jira.codehaus.org/browse/MNG-1977 Go there and vote for it!!!

Dwell in hell JaxB!

2009-03-02T19:49:00.005+01:00

Feel free to join the JaxB bashing... ;)

As pointed by David Josh is not really happy about JaxB's behaviour.

It is even worse than Josh thinks or experienced, as the specification is based on the fact that your objects are plain Java Beans (with all the quirks of this damn spec...).

I had an equivalent unpleasant surprise while giving a training on JaxWS (which specifies the use of JaxB recently) last december.

The week before this training, I had worked on a domain-driven persistence design, with immutable objects, write-only repositories and read-only fast-lanes (will soon blog about it hopefully if it's interesting enough)...
With this purist state of mind, I started creating in front of all the "students" a beautiful domain with Immutables (BTW I should have stuck with the default examples, though I wanted to demonstrate how easy it is to use JaxWS starting from scratch).
Yet be warned, an Immutable cannot be a JavaBean, as these beasts can only be created with the default no-args Constructor and their state modified by their getters/setters....

Isn't that the stupidest thing in the world????

What would be a best candidate for disconnected transfer (HTTP usually with WS) than an immutable object?

I know for a fact that an External view of the service should separate my domain from the view I give from it to the outside, yet even if good APIs exist for the copy of the states of beans, it's still a shame to be forced into java beans which are only useful for damn Swing developments (BTW I think I could wish hell to swing for being part of the JDK and being the motivation for the addition of a default implementation of database and web services inside the JDK/JRE.... what a nonsense).

So in the end I completely agree with Josh and am still looking for a better ways to use immutables in J(2)EE applications. It seems that the whole platform was build without these beasts in mind.

Users are crappy designers

2009-02-16T22:44:00.001+01:00

This title is of course a bit abrupt on purpose.
What I mean is users are very often crappy "web applications" designers... still abrupt, but scoped ;). Though I'm not sure they would be good designers for any other type of application, but they are definitely used to using them a lot more.

Let's illustrate that.

In I.T. brand new projects are quite rare, therefore implying lots of rewriting from existing applications. As of brand new projects, they are often inspired by existing ones developed for the same system, or from a previous product built by the integrator.
A user, or "core-business" worker, has a tendency (and we all share this burden) not to change his habits. And former application is part of these habits, along with massive paper usage, attachments to emails, client-server applications (even though this last point is not really directly relevant to the user, its side-effects cripple today's web applications, as we'll see further in this post).

Gathering requirements

A real effort of will is necessary when gathering requirements to avoid asking any questions to the user about how he thinks the UI should look like. This will most likely not help you design your application in any way.

False approach to novelty

Adding a new face on an existing fat-client application by building a copy-cat web application is really a bad idea.
It may look cleaner (though this depends on taste, but web applications are a lot easier to style and to adapt visually than fat clients) though is not bringing any functional novelty, and often opposite to the all-powerful user's habits (keyboard shortcuts for example) without improving the tool in the aspects of the work the user has to do.

Real knowledge of the work flow

Still the user has his hands on the treasure of treasures: the definite requirements a.k.a. the work flow a.k.a. the part that is almost never in the requirements.
Of course I'm insisting on "almost", as in fact I've seen a lot of projects where it's almost too much detailed, to the point that it's really hard, for anybody trying to build a use-able tool out of it, not to get confused or to discuss for pointless hours about it.
Because, face it, users, or even somebody talking for them, are hard beasts to tame, and even harder to have around. In most cases they are your legendary beast, you'll only read about them in the magic books of basic requirements. In Software Eden (the one advocated by Agile practices) the user is always at hand and grants you with insightful help all the time.
Hey! Stop that dream for now! 'not talking about ideal situations there!

Real lies about the work flow

Users really know what they have to do and how, and at some point you may have a good grasp on it.
This is the time, you know, this time just the day before the official release, that it hits you abruptly on the forehead: Users' lies about his work flow.
In the requirements, during the demo, you'll face a real user or a simili-user that will act like a theoretically perfect user.
Let's face it though: Users are not perfect, and often will leave out things that are crucial in applications design, like timing, context, concurrent use of other applications...etc
These "lies" are not intentional, this is what people often call omissions, though when users are omitting things like the coffee break that makes it necessary to save forms before they are submitted in order to be able to work on them later on, or the fact that they will often have to work on behalf of some other user, or working offline, accessing the application through a PDA, being notified of anything important immediatly (with a very relative sense of immediatly standing from 1 sec. to 1/2 hour, to the infamously unprecise ASAP...).
All these questions should be brought up front, though are usually not part of the "noble" requirements.
One may argue that they should be and I cannot agree more.
Just keep in mind that users will have bad ideas on how it should be done, and which technology to use. They just know about their agenda, how to do their core-business, and have habits (which may include technology bits...).

So where do we go from here

Do never forget to ask the users about their habits.
In order to build on them for better functionalities, better tools.
In order to replace bad habits with better functionalities, better tools + training ;)

Do never forget to ask the users about their timing.
Because their minute-to-minute agenda will have a very important impact on the outcome.
Because you need to taylor the system to their agenda, even if they don't already know how.

Meme(me)

2008-10-02T23:26:00.000+02:00

From David:
1. Take a picture of yourself right now.
2. Don’t change your clothes, don’t fix your hair…just take a picture.
3. Post that picture with NO editing.
4. Post these instructions with your picture.

Javascript: The Black Beast of Aaaaarrrrgggghhhh (part 3)

2008-09-11T12:31:00.013+02:00

With this third part, we're starting to dig into the interesting bits: modules or how to manage the scope of your code.
EDIT: Modules are delayed to a further blog post :p

But before this, let's talk about something else as an appetizer.

Boolean(false) is truthy

Javascript shares the burden of C-Style truthy/falsy concept. These are non-boolean expressions that can be treated as a boolean value. It is both powerful and very dangerous, because (once again) it presumes the developer already knows everything about the language's subtleties.

So let's first list the falsy elements, all the rest being truthy: 0,false (of course), empty string: "" or '', null

Presented this way, it seems quite simple... though there are some quirks due to where and how you're going to take advantage of these evaluations.
For example, 0 evaluates to false, while '0' evaluates to true (non-empty string). This sounds easy once again, but can be tricky when you receive a variable value and just test it this way: if(myVar){...}. It can lead to very counter-intuitive tests...

var myVar=new Boolean(false);
if(myVar){
    alert("true");
// Never use alert() in real applications, it blocks all javascript execution in all tabs of a browser until you close it.
}

This is one example of code where one should stop thinking in another language's logic (Java or C# for example). new Boolean(false) is an object, and an object is always truthy, ending up with an alert popup showing "true".
Though if you replace if(myVar)... with if(myVar==true)... the test will end up as expected, with nothing happening.
This can be confusing... I agree, and it did confuse me. Until I heard about the === operator. In javascript, == was designed as a tolerant operator, which accepts 1=='1' as a true assertion. So in later versions of javascript (when war between Netscape and IE was raging a while ago), a new === operator was introduced for a comparison of references. This operator is the one you'd want to use in order to be sure that an object is the same as another.

Oh and by the way, this may not be the last of my posts about javascript... so I'm going to drop in some of the references I used, in order not to forget them, and leave you my dear only reader with something else to read ;).

a Blog post about Truthy falsy
The source of all javascript wisdom ;): Sir Crockford.

Javascript: The Black Beast of Aaaaarrrrgggghhhh (part 2)

2008-09-09T12:21:00.023+02:00

First part of this "series" introduced basic concepts of the javascript language.
This new entry will introduce the functional nature of javascript.

In javascript, there is (almost) no limit to where a function can be defined (as opposed to a class language like java for example). It doesn't even have to have a name and can be defined anonymously. A function can also be created as a local variable in another function's body (inner function).

Functions represent the real power of javascript. Not understanding them means not understanding javascript.

Javascript uses functions all around. Functions are objects, and as such can be passed as parameters to other functions, or returned from other function's invocation.

As there is no proper class, one may think that there is no such thing as a method. This is not really the case. In fact one may call "method" any function defined as an attribute to an object.


var myObj={
    myAttribute:"valueOfAttribute",
    myMethod: function(){
        if(console){
            console.log("hello universe");
        }
    }
};

Functions are (almost) always stored in a variable of some kind, and can even be stored in local variables.
In fact, defining a function in an html script tag like this:


function myFunction(){
    if(console){
        console.log("hello universe");
    }
}

... is completely equivalent to the following definition:


var myFunction=function(){
    if(console){
        console.log("hello universe");
    }
};

This form is much clearer, as there is now no ambiguity about its object nature and about where it is stored... at least when you understand another little thing...

The global object:

In javascript, if you don't use the var keyword, or if you define variables in no specific construct (e.g. not in a function, an object, an array, or any conditional construct like if, for...etc), variables are defined as attributes to the global object. The global object depends on the runtime you are coding for. In a browser, this global object is the window object.

Now read my lips: "GLOBAL OBJECT IS EVIL". This global space is the worst place for the definition of your code. Oh, and by the way, variables defined without the var keyword are always defined as attributes of this global object, regardless of their scope.

So, what's the solution to this?

Create your own namespace!

You'll often ear about namespaces in the javascript world. In fact, this just refers to a container (javascript object) containing all the objects, states and functions needed for your code. This allows you not to pollute the global namespace (though this is not sufficient to disallow access to private states, wait for 3rd part of this blog series on the module pattern).

YahooUI started this trend with the YAHOO namespace. Other frameworks have also created their namespace(s) (Ext.* for ExtJS, dojo.* for Dojo, a global "$" or "jQuery" object for JQuery, Prototype.* for prototype, etc...). This allows the use of various "libraries" that are less likely to collide, or at least in a more controlled fashion.

As demonstrated in previous blog entry, creating an object, and therefore a namespace, is very easy:


var MyNamespace={};

And now adding elements to this namespace is as easy as invoking


MyNamespace.myElement="element's value";
MyNamespace.myFunction=function(){
    if(console){
        console.log("hello universe");
    }
}

You can see that the function we mentionned before is now defined in a custom object (namespace) and that we can therefore invoke:


MyNamespace.myFunction();

This exemple is of course very simplistic, and not very secure. In fact any code can replace these states, because objects don't have scopes! Let's detail this mind-boggling fact.

Objects don't have scopes, functions do

When you create an object, its state is public and accessible to any code that has access to the object in the first place. Any other code can add, remove and update entries from this container.

The only mean of reducing scope in javascript is functions. Hence the functional nature of the language.

Whatever is defined in a function is only accessible to this function and to any other construct defined in this function. The only visible thing from a given function, is the result from its invocation.


var myFunction=function(){
    var myVar="hello universe";
    // let's create an object accessing this 'private' state
    var result={
        myPublicVar:myVar+", I'm a public variable"
    };
    return result;
}
// next line will output undefined, because myVar is local to the function only.
console.log(myFunction.myVar);
// the next one will output 'hello universe, I'm a public variable', because the object returned by the invocation has access to the context of the function it was defined in (by the way, this is what is usually called access through a closure).
console.log(myFunction().myPublicVar);

As you may have noticed, and as a little conclusion to this post, one thing you really have to be careful with when reading or writing javascript code, is the presence of (). Whether a function is invoked or not is really important. This will determine whether you are left with the function object itself, ready to be invoked at will, or with the result from this function's invocation.

This is it for the moment. next entry will deal with the constructors (and the other ways to invoke a function), the concept of module, the truthy/falsy idea, and also give credit to the reference(s) used to build this little introduction to javascript ;).

Javascript: The Black Beast of Aaaaarrrrgggghhhh (part 1)

2008-06-21T23:51:00.004+02:00

I've really wanted (and still want) to have a grasp on how Javascript should be coded the Javascript way.

As a regular Java (and occasionally other languages) developer, I've sometimes used javascript with this constant sense of weirdness on the edges, and without being able to grasp the concepts in it.
In fact, the browsers' DOM and the history of the Javascript implementations in browsers contributed to this fuzziness (as we'll see later).

Basic concepts:

Javascript has very little to do with Java. In fact its name only contains java for marketting purposes of that time. Javascript is a language from the C family like java and uses a lot of the same operators and syntax.

This can be confusing, because Java and Javascript are indeed very different.

While Java is based on classes and inheritance between classes, Javascript is based on objects and inheritance between objects.
Javascript is also a prototype-based language (which is I think the hardest part to grasp...).

This may sound a bit abstract, but one cannot hope coding proper javascript without at least understanding these concepts.

A little pause

Before we start explaining the previous concepts, you must be aware that Javascript's history has been very clumsy to say the least.
Some good decisions were taken, and some very bad ones.

Most of the bad decisions were made during the browsers' war (Netscape vs Internet Explorer) with a purpose to attract developers from Java/C++ or VBScript for example.

These bad decisions leave strange reserved words in the language (like 'abstract' or 'interface' which are never used,) that should never be used or even cannot be used, and constructs that come from other worlds.

If you add to that the incompatibilities of APIs and models between browsers, it's easy to understand why Javascript is still often considered as a toy language.

So don't be surprised by the number of things that should not be used or touched in Javascript.

Javascript is not a toy language, nor a poor OO language.

In fact, in a way, Javascript is more OO than Java is ;).
In Javascript (almost) everything is object (think instances, forget about classes!).

Here's a list of the things that are NOT objects in Javascript:

numbers

strings

booleans

null

undefined

Everything else is objects.
Yes, everything.
Keep that in mind, and remember (again) that I said Object (instance), not Class.

One really clever thing that was done in javascript is the merging of Objects and Hashtable.
A new Object is an empty container of key/value pairs.

For example, one can create an object using:


var myObject={};

As Javascript is loosely typed, there is no class definition. You just created an Object with nothing in it.


var user={
    firstname="Pierre-Antoine"
    ,'lastname'='Grégoire'
    ,age=31
};

As you can see, it's quite easy to create an object using key/values.
As you also probably noticed, keys can be String, therefore allowing access to members in two ways:

using the dot notation: user.firstName

using the subscript notation: user["firstname"]

This is it for this first short part. Next blog entry will introduce the functional nature of Javascript.

SpringOne08: RESTFUL Web Services

2008-06-21T10:36:00.002+02:00

Late publication, didn't have the time back then ;)

A general presentation of REST:
- Everything is a resource (which has a value to the user). These are expressed by URIs and nouns
- Uniform interface (GET, HEAD, POST, PUT, DELETE, OPTIONS, and optionally TRACE)

GET: safe operation (can be repeated) that retrieves a representation of the Resource.
GET is Cacheable (Servers return ETag or LastModified)

HEAD: identical to GET without response body, only headers.

POST: creates a new Resource (Typically as a child to another Resource)
POST /hotels/1/bookings/ for example returns a location like: /hotels/1/bookings/50/

PUT: updates a resource or creates a resource when the destination URI is known.
As opposed to POST this can be repeated affecting the same resource.

DELETE: IdemPotent, if an item is not there, it doesn't fail.

OPTIONS: retrieves allowed HTTP methods on a resource.

Resource reprensentations => multiple representations (html, image, json... etc)

Stateless conversation: no HTTP Session! State is maintained through transitions between links. As a result, the result is very scalable and enforces loose coupling.

Hypermedia: fancy word for links ;), XLink is a spec for that and allows seamless evolution.

SpringOne08: MDA and Spring

2008-06-21T10:33:00.001+02:00

Late publication... didn't have the time back then ;)

Capgemini NL featured talk.
Begins with some basic concepts of MD*.

Then describes what an MDA tool is supposed to do and who's going to use it.
This is one point of view.

Pitfalls:
- Prevent "architecture-driven modeling" using markings.
- Keep applying traditional patterns of re-use, even if code generation can allow to generate a lot of boiler-plate code.
- Don't "u-em-ellify" everything.
- Don't touch your generated files (I tend to disagree... it just means that you need appropriate tools for that, though it does have problems with refactoring, and he recommends using Abstract classes).

Recommended tooling:
- MDA tools: OSS=> OAW, Acceléo Commercial=> OptimalJ
- be sure to have markings available

Advantages of MDA:
- From his experience, MDA allows to shift most of the issues in an application from the boilerplate code towards the business code. It seems obvious, but it's always nice to have additional practical feedback.
- Development and/or project speedup (I guess it depends on the side of the project and the extent of the use of MDA).
- Consistent code: enforce architectural patterns
- more flexibility

Prerequisites:
- knowledge of the models / languages
- more tools, more learning curve
- creating templates is hard: garbage in == garbage out

In the end a quite conventional talk, yet interesting.

SpringOne08: Spring Web Services

2008-06-12T13:54:00.003+02:00

Read the interesting (IMNSHO) bits below.

Spring Web Services is Contract-First.

Tools for contract infering from an xml instance:
Trang, XMLSpy, Microsoft XML to Schema (and an additional: Oxygen XML does that if I remember well). Why isn't there a java library for that (for use in IDEs and scripts)?

(Of course) contract first is really a good practice, and schemas (once you get to know them) are really a very expressive language for message content description.

New in Spring Web Services 1.5:
- JMS and Mail transports (a bit of overlap with Spring Integration... though this may merge sooner or later).
- WSS4J support (including client-side)
- WS-Addressing support
- OSGI Bundles

SpringOne08: Spring Integration

2008-06-12T00:41:00.004+02:00

Great talk, great features, though you can find everything he presented on the site and blog entries.

I'll probably blog on this subject as soon as I give it a try.

SpringOne08: Spring Batch

2008-06-11T16:45:00.007+02:00

This illustrates (and answers) a question I've always asked myself: Why shouldn't we code batch jobs in java...? In fact It's a lot more portable, testable and encapsulate-able than most of the usually used languages/platform nowadays.

Spring Batch 2.0 will be Java 5 ready.

Really interesting talk, yet already partly seen last year, and...I passed out a bit.

It seems that there is an underlying convergence between Spring Batch and Spring Integration (after all Batches are only integration operations that are longer or operate on larger sets of data, with a bit more requirements in the failure handling...)

SpringOne08: Security

2008-06-11T15:03:00.007+02:00

Not Ben Alex, but let's not judge the speaker so fast ;)

Interesting demo showing a completely unsecured Spring-based (of course) application completely secured on the fly using Acegi...uh sorry Spring Security (I actually got used to Acegi ;)). Quite classical, but enhances the improvements in the configuration.

A few interesting things to know:
- new Spring 2.x namespace for lighter configuration.
- Only one filter: DelegatingFilterProxy with a filter chain behind.
- REST Support: you can specify the method (POST, PUT, DELETE...) in the intercept-url element.
- very nice ldap-user-service configuration... worth checking!!!
- Embedded Apache DS: very nice!
- easy to mix and match multiple schemes: OpenId for authentication, and JDBC for user details or NTML for Authentication and Active Directory for User details.

He mentions an interesting possibility: only testing the securisation of methods by completely removing the call to the underlying method. Sadly he doesn't go into details.

A nice practice also: securing based on permissions and not on roles. This is much better for further evolutions. Roles change, permissions less likely.

In the end (I knew a bit from the tests I did recently) Spring Security is an improvement in terms of useability, (if not in features, it keeps the plethora of features of the original), on Acegi.

SpringOne08: Persistence Optimizations

2008-06-11T14:03:00.007+02:00

DBA-Developer relationship, try to improve it... ok... too bad DBAs are not there to here that ;)

Operational considerations:
- Data volumes, row sizes
- Growth estimates, update frequencies
- Availability requirements
- Testing/QA requirements

Guidelines:
- appropriate data types
- small rows
- split large tables with one-to-one table containing fewer used fields
- improve indexes
- normalize data
- partition data (if available)

Most important: application tuning:
- keep transactions short
- bulk processes => off-hours
- understand locking (on writes, on reads...escalation of row locks to table locks in case of many reads...)

ORM tuning:
- watch Criteria, no NULLS in the WHERE clause, they are not indexed
- like with % at the beginning: no index either
- pick an appropriate TransactionManager (only use XA when accessing JMS and database together)
- use READONLY, try to avoid SERIALIZABLE
- use lazy-loading
- use caching

JDBC Tuning:
- set the fetch size on connections (defaults to 10 for Oracle driver...) lessens the network roundtrips

Hibernate Tuning:
- use "select" fetch mode for relationships needed sometimes - results in 1 or 2 queries.
- use "join" fetch mode for relationships needed all the time (try to limit to one per object)
- use "batch-size" to prefetch a number of proxies and/or collections

Bulk operations:
- do it in the database to avoid network (SQL statement, stored procedure, native data load tools...)
- if you need to do it from the application: JdbcTemplate (batchUpdate), SimpleJdbcInsert (executeBatch), Spring Batch (BatchSqlUpdateItemWriter), Hibernate (set hibernate.jdbc.batch_size and flush and clear session after each batch)

SQL Tuning:
- Capture SQL
- Run EXPLAIN
- adjust: analyse, tweak optimizer, add index
- repeat until adequate performance
- ASK for help from your DBA ;)

OpenSource JDBC monitors:
- p6spy
- Elvyx
- JDBCSpy

Database specific tools:
- MySQL (slow query log with --log-slow-queries or --log-queries-not-using-indexes)
- Oracle: Enterprise Manager, Statspack
- Oracle XA: Monitor Top SQL

Interesting tips for Oracle:
- Use the call to a function setting the module name in Oracle in the validation query for the connection
- Use explain and autotrace in Oracle SQL Developer
- Use ANALYSE TABLE [table] COMPUTE STATISTICS
- Use ANALYSE INDEX [index] COMPUTE STATISTICS

Database Tuning:
- Memory (Global Area SGA, Session Area PGA)
- Disk (Block size, File placement)

Talks about a ProxyDatasource during Q&A. This seems to allow to transmit the credentials of the interactive user. Could be interesting for refactoring of legacy Oracle Forms applications.

SpringOne08: Spring 2.5 to Spring 3.0

2008-06-11T12:19:00.010+02:00

This presentation talks about 2.5 and the future (3.0).

2.5 summary:
- 2.0 kernel so-to-say plus additional features.
- end of 1.3 support (who cares? ;););) )
- JDK 1.6 support: JDBC 4.0, JMX MXBeans (supports runtime snapshots)
- AspectJ load-time weaving (available in 2.0 but not mainstream as in 2.5) through a platform support or a generic Spring VM agent using <context:load-time-weaver />
- JEE 5.0 support (JPA support is improved, EclipseLink support) and all other JEE 5.0 APIs

A bit of details on 2.5:

JSR 250 Common Annotations:
Good: @PostConstruct, @PreDestroy
Bad: @Resource ;);) of course, this annotation is a bit limited (injects a resource from JNDI from a name in a setter or field)... yet a standard. Life is a bitch... though Spring allows using it without JNDI :).

Other annotations:
- @WebServiceRef/@EJB (should have been named @EJBRef... life is really a bitch)
- @TransactionAttribute (EJB 3 transaction demarcation... a bit limited)
- @PersistenceContext / @PersistenceUnit already supported in 2.0: JPA resource injection

@Autowired Spring annotation
- on fields, configuration methods, constructors
- nice sweet-spot between autowiring by type and autowiring by name: annotation-driven, less wild-guessing.
- @Qualifier allows to narrow the potential autowired components if multiple are available. This is also available in the xml syntax in beans. Qualifier can be a bean name or an annotation applied to a bean.

@Configurable with AspectJ
- classes can be weaved and may be created by using a simple "new" constructor call!
- using <context:load-time-weaver aspectj-weaving="on"/> and <context:spring-configured /> (and of course the appropriate class-loader/agent).

@Transactional with AspectJ
- using <context:load-time-weaver aspectj-weaving="on"/> and <tx:annotation-driven mode="aspectj" transaction-manager="......
- avoids creation of proxies by using load-time weaving.
- also works for private and protected methods, and for code from same component (common problem with proxies).

Annotated MVC:
- @Controller, @RequestMapping...etc (I already tested it, you should try it ;) )
- allows POJO Controllers for classic methods, or in portlets...

Test Context Framework:
- @ContextConfiguration, @TransactionConfiguration
- works with JUnit 4.4 (@RunWith(SpringJUnit4ClassRunner.class)) and TestNG
- no use of class hierarchies... nice and light ;) (a bit troubling though as the test almost contains anything except metadata....)

Recommandations:
- Option 1: XML-based configuration complemented with annotations.
- Option 2: more radical: Fully annotated components. (Not that much an XML hater... so it seems a bit over-strict)...
- Externalized configuration => XML
- Embedded configuration => Annotations
- Find the balance, and mix and match!!!

Spring 3.0 insights:
- Spring 2.5.5,2.5.6 up until July (OSGI refinements)
- Spring 3.0 RC1 (August)
- Spring 3.0 GA in Q4: Java 5 in the core (internal use of Generics and varargs), support of Portlet 2.0, preparation of Servlet 3.0, => REST support, EL support, conversational support...
- Backwards compatibility with removal of deprecated APIs.
Pruning and Deprecation:
-prune: Commons Attributes
-prune: Toplink (EclipseLink)
-deprecated: pre JDK 5.0 support

SpringOne08: Keynote

2008-06-11T09:30:00.010+02:00

9h30, Keynote should start any minute.

First, the main local organizer of Spring One talks about his baby: Parleys. He shows off a very nice Flex-based UI. Flex is definitely nice, and what they've done with id also! Check for version 2 of Parleys very soon, it's great!

Rod Johnson:
A bit of commercial Blah... (sorry, but that's it... :P) though the content is quite relevant.
This quickly turns into a (little bit) more technical talk.
It also contains interesting bits that I didn't know of or have not yet tested:
- Use of qualifiers in Annotation and XML configuration
- support for Meta-Annotations (annotate annotations ;)) which allows to use your own meta-tagging for your component types and then annotate them with Spring Annotations , the org.springframework.stereotypes package also provides sensible defaults.
- Junit 4 support through specific runner (haven't had the opportunity to test it yet, but will indeed do it very soon!)

Spring Integration is mentionned there, and I think (see later in this post) that this may be very soon a very important Spring project...

Enters Keith Donald who talks about the web tier.
Interesting Javascript module... worth following...

Rod Johnson again:
Spring Powered applications: replaces more and more the JEE container.
Decoupling of business logic from deployment platform in terms of choice. (can be argued with their new server which relies a lot on Spring ;) ).
Obviously leads to Springsource Application Platform.

Christian Dupuis:
Nice presentation of STS. Should have been preceded by a SpringSource AP in-depth presentation.

Peter Cooper-Ellis, comes from BEA, and gives a little talk about his view of SpringSource and Spring.

Rod Johnson:
Predictions => most interesting: app server and ESB fusion (see Spring integration merging with Spring AP ;), it seems so obvious)

Spring One minus One

2008-06-10T22:28:00.001+02:00

Just to tell the few potential readers of this blog that I'll blog about Spring One the two coming days from Antwerpen, Belgium.

Almost-paired programming, the shrink principle and beer

2007-10-26T23:49:00.000+02:00

This strange thought occured to me yesterday:
It is quite disturbing to see how coding can be close to a psychiatric sickness.

I was gently coding through a piece of code while being often disturbed by phone calls, meetings and other daily stuff.

The obvious outcome was a messy code with an almost as much messy runtime result.

At that precise moment, I was having a hard time focusing on this "algorithm" and the fact that the states in my java code could possibly be accessed from multiple threads was going to make things less easy.

Therefore, with all that mess in my mind and my phone ringing now and then, I started commenting my code to make it readable (a bad habit indeed, as code should be self-readable by separating concerns in methods with readable names and sharing states in richly defined objects... but anyway...).

When I was over commenting, the code did not behave any better, but was interweaved with rich textual descriptions.
Though it seemed that the added comments did not go further than the limitations I was already feeling (remember? difficulty to focus and phone ringing).
The comments themselves where sitting on top of the pile of messy code I had produced, with no added value as they were a direct transcription of how I was reasoning at that moment.

So I decided to remove all these comments and to create a few rich immutable objects for states, and using ConcurrentHashMap and Atomic* all around.
My code was indeed completely thread-safe.

But still... its behaviour was the same: not what I expected.

So I decided to call in for help.

I turned to one of my dear colleagues, and asked him to lend me a bit of his time in order to have a second look on my piece of code.
In fact, I couldn't even think of a new way to look at it.

Indeed, he gently accepted and sat next to me in order to look at my uncommented (if he reads this, he'll eventually remember telling me how messy and uncommented it looked ;) ) piece of over-immutable code.

And then began an uncontrolled shrink scene.

Here's how this dialog (approximatively and "embellished" a bit) turned out:

me: "So here's my code, here is what it does, and things are all immutable and stuff..."
colleague-shrink: "Mmmmh mmh... So here's your code, here is what it does, and things are all immutable and stuff?"
me: "eh yes, look I've toggled breakpoints all around and I can't seem to see anything wrong"
colleague-shrink: "Mmmmh mmh... So You've toggled breakpoints all around and You can't seem to see anything wrong?"
me: "Oh no! this little thingy was there all the time...my algorithm was missing one point and I was looking for a synchronization issue. Well thank you for solving this issue with me!"

And then it occured to me that (even if my colleague would probably have solved this problem quite fast) the only presence of a real person to whom you explain your code acts like a catharsis for solving bugs.

Though this is not very new and one of the basis of paired programming, the parallelism with the shrink made me a bit uneasy.

Do I have to pay my colleague now, in order for the treatment to be efficient? ;)

So I now decided that this would now be rewarded by beers. So if you happen (or happened) to be my code-shrink, don't hesitate to reclaim your beverage!

Spring One (day3) : Spring Batch

2007-06-22T14:26:00.001+02:00

Last presentation!!!
Spring IDE's presentation occured at the same time, but as I already knew a bit about it... I skipped. But go and get release 2.0 (released next week if I'm not wrong) it is amazingly productivity-inducing!

And now on to Spring Batch.
This new product of the portfolio allows to deal with batching.
It was a project built by Accenture and is now a co-project of Accenture and Interface 21.

It starts from the statement that nothing exists covering that subject in Java, and that there's a common misconception about the fact that Batch is not possible nor efficient in java.

It seems really complete and well-thought and is already production-grade.

I really dig the Enterprise Message-driven processing, sadly it's not targetted for version 1.0.

Features:

multiple formats for files

Automatic retries

Job control language (start, stop, suspend, cancel)

status and statistics

Entry points for launch (http, Unix script,incoming message, etc...)

Ability to run concurrently with OLTP system

Ability to use multiple transaction resources

Support services (logging...etc)

It really deals very well with batch retries at multiple levels, with a fairly rich set of possibilities.
Coding is (obviously one would say) POJO based, and batch behaviour is non-invasive.
Business logic is completely separated from job execution policies.

The really interesting stuff not mentionned but implicit is that jobs can now be thoroughly unit tested (not integration tested, UNIT tested with mocks and everything!!).

JMX Management is soon to be released. (How about batches launched from JRuby?)

Roadmap:
Milestone 2 is soon to be released.
In the future:
Partitioned container,SEDA,Grid, ESB support, and more...

Spring One (day3) : Spring, dynamic languages and DSLs

2007-06-22T13:23:00.000+02:00

Rob demonstrates how to use JRuby with java with Spring and standalone.

A little demo of the spring integration.

Followed by a demo of mscript.db allowing to interact with JMX using JRuby scripting. Very powerful indeed. This will be in my toolbox ASAP! ;)

He also advertises "The Ruby way" as a good book to read for starters on Ruby.

Then on to the DSLs!
It is sad to see that support is for now a little hacky (fun and well done though) and that official support won't be there until Spring 2.2 or 2.3.

Definitely worthy of attention at the end of the day.

Spring One (day3) : ROO

2007-06-22T10:59:00.000+02:00

ROO or Real Object Oriented programming.

It is a really nice framework part of the portfolio and enforcing the concepts part or Eric Evans' book on Domain driven design.

It's really a nice way to deal with the anemic model issue and is nicely integrated with tooling (Eclipse, Maven 2...etc).

The smashing fact is that it generates and deals with DTO generation and assembly bazed on Dozer (3.4).
They are useful as form backing objects and for remoting.

Until now, it is the really neatest and newest stuff I've seen in this conference.

Please please please go and see Spring ROO (possibly still named Acegi ROO at that time though)!!!

Spring One (day3) : OSGI

2007-06-22T09:38:00.000+02:00

This presentation nicely sums up OSGI.
Key assets are:

Visibility: a bundle is a black box if not explicitely specified. Nice but does not fit with the current classloading designs where everything is in the same space (more or less)

Operational control: see modules and their status, install, activate,...bundles.

Dealing with dynamics: types and services can be exported and contributed (passive and active contribution respectively because services changes are dynamically seen).

Then what about OSGI and Spring?
How do you split applications into a number of OSGI bundles
Bundles need: instanciation, configuration, assembly, decoration.
This should not be coded, this is (mostly) boiler-plate code.

The purpose is to keep the Spring development model.

Main entrypoint there is an OSGI bundle-based application context.

Interesting thing is that beans can easily be exposed with a specific namespace (<osgi:service/> and <osgi:reference/>) and all the lifecycle and (re)binding of services is dealt with by Spring OSGI.

The ConfigurableBundleCreatorTests are interesting for integration testing. It can run the test of your code inside of an OSGI container. This is really a great progress, mostly if one can set it up for testing Eclipse plugins...

Provisioning with Maven and Ivy is also a catch and is planned for after version 1.0 (part of Maven support already is included in pre 1.0 though).

Spring One (day2) : New features in Spring 2.1

2007-06-21T17:58:00.000+02:00

This will be a list of what is described:

Platforms:

JDK 1.6 (JDBC 4.0, JMX MXBeans, JDK ServiceLoader API)

Java EE 5.0 (Servlet 2.5,JSP 2.1, JSF 1.2, JTA 1.1, JavaMail 1.4,EJB 3.0 session beans,JPA even inside JEE 5.0 server, Deployment as JCA 1.5 RAR file, Websphere integration through specific addons)

OSGI support (allows a similar programming model between OSGI or J2EE deployment)

Configuration:

JSR 250 Common annotations(now supported by all JDK 1.6 and Java EE 5, and JDK 1.5 with the common annotations jar)

@Autowired annotation (fits well between name and type autowiring)

"context" configuration namespace (convenient context-relative functionalities)

@Component annotation

AspectJ Support:
cf. previous presentation I blogged about.

@Configurable Revisited:
no AspectJ compiler necessary (based on load-time weaving)

JMS Message Listener Containers:
"jms" XML Schema Namespace

JCA 1.5 Namespace also

still to come (not in RC versions):
Junit 4 support and Rhino/javascript support.

Spring One (day2) : Concurrency and Spring

2007-06-21T16:46:00.000+02:00

First a definition of the Java Memory Model based on:
- Ordering
- Atomicity
- Visibility

Interesting thing I missed, volatile keyword guarantees atomic R/W on lon and double types.

He then goes on quoting stuff from Java Concurrency in practice (Brian Goetz), e.g. the Holy Bible ;).

Once again I see somebody enforcing the need of immutable objects! So people! Use them!!!!!!!! It IS the key to safe publication.

Spring One (day2) : WS-DuckTyping

2007-06-21T14:03:00.000+02:00

How to extend the concept of Duck typing to webservices.

Duck typing is a feature of dynamic languages: "if it walks like a duck and sounds like a duck, then its a duck".

Basics are:

Don't validate incoming messages

Use XPath

Don't create stubs and skeletons.

One rule is: sending should be conservative, and receiving liberal.

Schematron seems interesting in this approach because it is based on finding tree patterns (RelaxNG also does this).
More simply, XPath allows to look for an info without assuming that the surroundings (things out of the path) have any strict structure.

Spring WS 1.0 RC2 is out and based on contract-first and XML use without directly doing XML.

There are a lot of cool XML and particularly XPath helpers in this release, even if you don't need to use it for web services.
XPathTemplate, NodeMapper, and annotations make it very handy and easy to use XML with the ability to switch implementations.

Spring One (day2) : Advances in AOP

2007-06-21T12:16:00.000+02:00

This time a quite technical presentation.

First half is an introduction to AOP and AspectJ syntax (code, annotations, xml) with pros and cons for the different syntaxes.

Interesting thing in Spring 2.1 is the new Native AspectJ weaving.
Also of interest is now the bean(*) syntax. This allows to create pointcuts based on beans characteristics (name for example).

He then demonstrates how you can use AspectJ to enforce Architecture designs.
For example showing errors at compile time when somebody access data from the ui layer. You can basically enforce things by modifying compiling behaviour. Interesting, but this can become really messy if done too loosely.

Adding mixin to interfaces is also interesting when you have to deal with boilerplate code for implemented interfaces (for Example the *Aware interfaces whose method implementations is 99,99% of the times the same).

Interesting usage is also the ability to implement retry/failover strategies for remote services using around advices.

Sadly AOSGI is only mentionned but not discussed in details. That was the reason of my presence in the first place in this presentation... :P

Overrall it's interesting to see how AOP is now so widely used ;) (when using Spring at least).

Spring One (day2) : Keynote

2007-06-21T10:12:00.001+02:00

This keynote describes the Spring Portfolio starting with a really funny (crazy?) show of Adrian with a duck and a chicken hand puppets... in a personal interpretation of DuckTyping.

Interesting info: Spring projects will now have a release train "a la" Eclipse.

Second speaker is Eric Evans. Another soothing/sleep inducing voice, yet an interesting talk about the concepts of Model/Domain driven design.
I can't wait to read his book I just bought yesterday. ;)
Really hard to sum-up again. I'll be glad to see it on Parley.

I liked the idea that quality of the code produced by a team is usually driven by the 2nd worst programmer, because all the team is already focusing on the very known worst programmer and doing damage control ;).

The conclusion is that one should establish a Context Map of a system and build an anti-corruption layer. I think I'll elaborate on this in a future post because this is really interesting, and this post is getting messy :P

A very nice analogy of these context maps is living cells in organisms.

In the end Eric Evans'talk was a great non-technical talk!

Spring One : after 1st day

2007-06-21T08:29:00.000+02:00

A (once again not that great...Spring One should really happen in France ;)) meal and a few glasses of fresh white wine later, David, Torsten and I went back to the hotel in order to have a few beers by the pool.

I guess the visit of centre-town will be for tomorrow.

Spring One : SOA without Hype

2007-06-20T17:44:00.000+02:00

Brilliant presentation about pragmatic SOA.

Hard to sum up, but very fun and interesting.

A few fun points about SOA's absurdities, WS-(death-)star specs, and about REST.

Hope this will be very soon on www.parley.com.

I'll remember the sentence: "tooling is often used to cope with a crappy product"...

Also possibility of creating an SOA based on emails and XMPP is intriguing.

Spring One : JSF and Spring

2007-06-20T16:50:00.000+02:00

Colin is a great speaker, though his voice is so soothing that you'd fall asleep :P.

First a general presentation of web frameworks and Spring /JSF.

Interesting point: when using scopes like session, request, be careful of the scoping of injections.
For example if you inject a request scoped bean in a session scoped bean, the request scoped bean will only be created once per session... not the expected behaviour!

there's now an <aop:scoped-proxy /> that provides a proxy of the bean that recreates the bean for example for each new request.

Then Colin goes on with the longest silence in a conference ever while going through his file system... very strange!

Then the rest of the talk describes the variable resolvers, navigation handlers... etc

Colin really talks more about Spring Web flow than Spring with JSF anyway.

Spring One : SCA

2007-06-20T15:43:00.000+02:00

Keywords for SCA:

- Assemblies (component, reference, promote, properties, bindings)
- Policies (intent, policyset, WS-Policy*)
- Client & Implementation models (java, C++, php, COBOL, ... etc)

see http://www.osoa.org.

Presentation of SCA is hard to sum-up yet very interestingly layered like Spring. Analogies with Spring are also interesting:
- Assemblies => context
- Policies and intent => AOP + annotations
- Implementation Model => bean :P or so

The Java implementation model, lifecycle, asynchronous/conversational state, callback (and so on) are sadly defined through YASLF ;) (Yet Another Specific Language Feature) though Spring support should allow to bypass these specific annotations and just expose a Spring bean.

Interestingly enough the Conversational and asynchronous mechanisms seems brand new to me in SOA in general (from the implementation point of view at least) as usually this is dealt with low-level solutions like a MOM.

Basically the Spring mechanism for this maps on sca descriptors quite closely.

On the OSS implementation side for java, Tuscany and Newton (based on OSGI).

Spring One : Introduction to Spring Web Flow

2007-06-20T15:05:00.000+02:00

It's interesting to compare this version of the presentation with the early drafts presented last year.

Spring web flow is indeed more mature now and integrates well with JSF or Spring MVC.
It is well fitted for Wizard-like web interfaces with a rich state management.

What's interesting is that the state can be stored to anything (not only Http session, but also database for long running flows for example).

Spring One: lunch

2007-06-20T14:37:00.000+02:00

No more lunch for us... lunch delivery obviously failed which lead us to have a wonderful belgian lunch.
And yes, Quick fastfoods are Belgian food... or not!

Spring One : GWT/Spring

2007-06-20T12:05:00.001+02:00

Interesting presentation with mostly features of GWT plus a few integration points for Spring Business layer.

Sadly, no insight on future support for Java 5 Annotations, and no first idea of the upcoming version 1.4 which deals with the IsSerializable vs. Serializable issue amongst other things (modular RPC services for example removing the need for GWTHandler in order to integrate wutg spring).

Conclusion: until further notice, DTOs should be used with the addition of a specific Service Facade Layer to the business layer and a DTOConverter (Special mention for Spring's BeanUtils for the copy of objects' states).

My own conclusion: wait for version 1.5 of GWT for a more completely useable GWT, and keep experimenting with it.

Spring One: keynote

2007-06-20T11:40:00.000+02:00

Keynote just finished.

It surprisingly and interestingly began with a demo of Spring .NET project and how similar developing for .NET or Java is with Spring.

A lot of marketting stuff for 3/4 of the rest of the show.
The major intend was to justify the venture funding of 10M$ for Interface 21.
Interesting thing here (from a 'technical' point of view) is that 4 Full Time Employees(FTE) will be allocated to the web part of the portfolio, and about 3 to the core Spring functionalities (against a round value of respectively 1 and 1 cumulating the work of all contributers).
An analogy between the Eclipse and Spring momentums also made a bit of sense.

For the last quarter of it, a description of a few projects of the Spring portfolio took place.
Interesting emphasis on Spring Batch project as a replacement for existing legacy batch processing.
Spring Web flow and its JSF support was also interesting.
Spring IDE (my own personal favorite ;)) had an interesting little demo. Christian has really worked his $ss off on this! New features are stunning and already cover upcoming Spring 2.1.

Overall the keynote was a bit boring for the marketting part (after all the audience is not made of funders nor shareholders) but gave an insight of future developments around OSGI and Web-related projects.

I'm now waiting for a GWT/Spring presentation that should wake me up (I woke up at 4 this morning)...

Spring One: before

2007-06-20T09:05:00.000+02:00

Just arrived in Antwerpen.

Little breakfast in the hall next to Rod Johnson rehearsing his keynote speech in a corner of the room.

2 hours of keynote indeed diserve a rehearsal!

Exceptions, the Widest net effect and a new Exception catching syntax

2007-04-24T20:18:00.001+02:00

One annoying thing with Exceptions Catching in java is obviously the fact that a lot of APIs still throw checked Exceptions (not inheriting from java.lang.RuntimeException) to your face, therefore forcing you to deal systematically with things that sometimes cannot be recovered from in your application.

This often used to imply the horrible "wide net" effect, when one uses too wide a net to catch exceptions (and even sometimes never dealt with them in order to get rid of them... but this never happens anymore :P ).

One interesting and possibly easy to integrate evolution to the java language would be the possibility to catch multiple exceptions in one go as follows:

catch([MyException,AnotherException] e){
    throw new WrapperException("Something bad occured in my code, but I won't deal with it, though this gives you a context ;)",e);
}

In this case, in current java constructs, this would end up with:

catch(MyException e){
    throw new WrapperException("Something bad occured in my code, but I won't deal with it, though this gives you a context ;)",e);
}catch(MyException e){
    throw new WrapperException("Something bad occured in my code, but I won't deal with it, though this gives you a context ;)",e);
}

Or more probably because nobody likes repeated code:

catch(MyException e){
    dealWithException(e);
}catch(MyException e){
    dealWithException(e);
}

Or even for lazy people:

catch(Exception e){
    throw new WrapperException("Something bad occured in my code, but I won't deal with it, though this gives you a context ;)",e);
}

I vote for it... do you? ;)

TDD, TET, and TTD...

2007-04-17T18:51:00.000+02:00

As I am quite test infected these days, I tend to make my tests run AFAP (As Fast As Possible...).

This is quite an important topic when dealing with UNIT tests. In fact it's as much crucial as encapsulation of the System Under Test. If your tests run fast, you'll run them often. Hence the "make your tests run AFAP with a good TET (Test Execution Time) when using TDD (or not).

This is not quite new and has been advocated by anonymous people like Martin F. (Except for the TET part which I own a copyright for.... not...)

This is where enters TTD.

I found myself reverting from an everyday use of MyEclipse with JBoss 4.0.x to a WTP 1.5.x/JBoss 4.0.x pair.
And believe me... it's hell on earth! I was trying to explain to a colleague of mine how Struts 2 (interceptors... etc) and Spring work together, and believe me, it's really hard to demonstrate anything efficiently when you never know the status of your deployments and when a modification of a files "sometimes" triggers an awfully slow ant task making a full redeployment of the web application!

So it really seems that TTD (Time to deployment) affects a lot the productivity of a developer. Yet again nothing new, but it is very disappointing to see how a tool like WTP handles such a crucial task.

My conclusion is that I'm working right now on a "Workspace to File system synchronizer" allowing to keep part(s) of your workspace in sync with another part of the file system (for example a folder in JBoss's deploy folder, or in Tomcat's webapps folder) hooked on the Platform's events.

This way, with a great TET and a marvellous TTD, I'll be able to attain my goals ASAP.

Mocking, Stubbing, and Usurping

2007-03-22T14:27:00.010+01:00

This post won't be about mockery in general, nor will it be about a famous "Love boat" captain (ok ...not the same "spelling" ;) ).

What I want to talk about is Mock Objects and Stubs used in strategies for Unit Testing.

When you have to Unit test a piece of code, (if your purpose is really to Unit test it), you'll often need to isolate it from the surrounding layers/components.

In order to achieve this, two common tools are used: Mocks and Stubs (Though other variants are available).

Let's begin with Stubs (in unit testing vocabulary). A Test Stub is a test-specific implementation of the contract of the object/component it is supposed to replace. It is ment to return the value this component is supposed to return. This Stub can also return a wrong value or throw an Exception in order to emulate error cases and test the robustness of our system under test.

A Mock object adds some behaviour testing to the Stub. This means that in addition to the returning of values and throwing of exceptions, it also checks the input it gets from the system under test, the number of times each method has been called...etc

So why does this post's title mentions Usurping?

Now comes the part where I'll present a solution I came up to for Java applications and baptized Usurper.

When you're creating your own Stubs or using a Mock Object framework (easymock, jmock...etc) you need to feed them with the expected return values.

It can sometimes be quite tedious to create a value object's instance, and even more if your Mocked component is supposed to return a list of 100 users for example.

This is where Usurper comes in handy.

If you have a User Value Object like this one:

public class User{
private String firstName;

private String lastName;

private Integer age;

private boolean administrator;

// getters and setters ...toString() method...
}

Here's how you can create a list of 100 User objects using Usurper.

// CREATE THE USURPER GENERATOR
UsurperGenerator<User> userGenerator
= new UsurperGenerator<User>(User.class);

// GENERATE A LIST OF USER VALUE OBJECTS
List<User> userList =
userGenerator.generateUsurperList(100);

And you're done!

At least for now if you don't need to test the contents of the object.
In fact, the content of the generated usurper object is something like this:

org.org.usurper.User@1632c2d[
lastName=dCOuSJOZQZ
administrator=false
age=814857147
firstName=Zq8R9bH7LJ
]

This is because the default field handlers allocate a random value to the fields in your object.
So this is the part where you'll say to me this is no use at all.
Well I'll answer that from now on this is up to you!!! ;)
You can easily implement:

handlers for types of properties
handlers for specific properties (for example a specific handler for the property age of the User class)

This way you can customize the way some fields are dealt with.
For example, the BigInteger type is not handled by default. You can easily create your own implementation in a global text fixture of to a specific test's local fixture:

// CREATE THE USURPER GENERATOR
UsurperGenerator<User> userGenerator =
new UsurperGenerator<User>(User.class);

// REGISTER CUSTOM PROPERTY TYPE HANDLER
Set<Class> handledTypes = new HashSet<Class>();
handledTypes.add(BigInteger.class);
userGenerator.registerPropertyTypeHandler(
new AbstractPropertyTypeHandler(handledTypes) {
public Object handle(Object targetObject, Class attributeClass,
String attributeName, Map parentHandlers) {
return new BigInteger(24, new Random());
}
});

// GENERATE A LIST OF USER VALUE OBJECTS
List<User> userList =
userGenerator.generateUsurperList(100);

This is just one basic (and probably meaningless) example of what you can easily do with Usurper.

Note that Usurper supports by default:

Generation of array properties: if your property is a BigInteger[], all you have to do is define a handler for the BigInteger type.
Generation of Collection properties: if your property is a List<BigInteger>, Set<BigInteger> or Map<BigInteger,BigInteger>, all you have to do is also to define a handler for the BigInteger type.
Generation of Enum properties: a default handler gives random values for Enum types.
Generation of Value Object properties: if your property is another value object, you can easily register it through the use of the ValueObjectPropertyTypeHandler.

If you want to learn more, and hopefully give it a try and adopt it (it is LGPL licensed), follow this link:
http://www.org-libs.org/org-lib-usurper

Paroli aux agi

2007-01-05T22:15:00.000+01:00

How much can a thoughtfully elaborated language evolve? How much without implying a sufficient amount of thinking about the real purpose of such an evolution?

This sounds philosophical but is not the start of a discussion about philology (litteraly "the love of words" in ancient greek and J.R.R Tolkien's speciality), as what I'm going to talk about is the current evolution of the java language and the java platform as a whole.

There seems to be so much debate on language subjects such as closures and erasure/reification... All these debates are really interesting and I think these are indeed good moves.

But this seems like pulling a beautiful napkin on a dirty table : JEE...Well ok this is a bit exagerated, but I mean that the focus on ease of development for this release of the platform completely removed the focus from the ease of management of applications at runtime.

All this focus on ease of development and productivity improvements is a really good move anyway. But I think that if the brilliant minds discussing on these difficult language/JVM subject could allocate a bit of their time to JEE's architecture, we would finally have something a little bit more production-ready than now.

Do I need to remind that nowadays each and every peace of software is upgradeable and manages its version in one way or another (Firefox, Eclipse, Linux with packages, all MacOS software, even Microsoft software...etc).

Yet JEE 5.0 applications still don't/won't have any conventions on versions of deployed artifacts...
Is this because this kind of version management is complete fantasy?...no.

In fact, OSGI implementations already provide this scheme for java applications. A fair amount of java developers have already experienced this through the plugin and update site mechanism of Eclipse through the Equinox OSGI implementation.
The very famous Spring framework also provides an alpha OSGI support for Spring-enabled applications.
A JSR has even been started proposing the support by the JDK and/or J2EE of OSGI.

So why in the hell WHYYYY did some "clever" folks think they could flush this away (sewers once again) and try to push in the JDK a somehow neither tested nor sufficient JSR for a Java Module System (JMS acronym is already used BTW)...instead of contributing improvements to the already tested and proven useful OSGI initiative.
If you look at how this JSR (see 2.6) sweeps away OSGI in a paragraph as simplistic, you can see how much the "not invented here" motto can get in action...

It's a bit sad to see how the focus on the language and/or a narrow view of the use of java is done at the expense of the view on architecture and/or live management of applications in IT systems.

The same way Esperanto was a good idea and a cleverly elaborated language, is java becoming a very clever language with no soul?

This seems a bit desperate, and as much as I value the language improvements, I do value a lot more OSGI, Eclipse RCP and Spring framework, not because of a hype surge, but for their fair usefulness and clean design.

Wouldn't it be a lot cleaner to have a common jar pool/repository in a j2ee server (clearly specified in the repository) with a simple version handling (similar for example to the structure of a Maven or Ivy repository), and to add, say, a "dependencies.xml" file to the different deployable. This, along with a clear classloading scheme in the specification would allow people to deal with versions management.

(BTW the JSR 277 people didn't even think about J2EE when elaborating it...what a clever move........not!)

Wouldn't it be clean to have a "myapp-1.0.0.war" archive in a JEE server, and just have the ability to replace it at runtime by dropping a "myapp-1.0.1.war" and let the server handle the replacement and the dynamic linkage to the appropriate libraries?

This definitely wouldn't be easy to implement, but woudn't it be a better place for the focus of brilliant minds than a meaningless struggle with Rubyists?

I for myself prefer a lot design to language improvements.

Mobilis in mobili

2006-12-17T23:14:00.000+01:00

As I tend to notice, working in the IT field can be really rewarding and also humongously frustrating.

While being part of an intense brainstorming with co-workers whose work you value very much (and hopefully who value yours...) is indeed really rewarding, it is a job where congratulations are quite rare.
In fact, each and every member of your family and/or friends (those ones not part of the geeky crowd of course) think your daily work consists in installing windows XP on computers and debugging the latest Canon printer.

The main issue with this is not the incommodities of the week-ends spent fixing your family's computers (well not only that...), but the real problem is that the role of IT workers is not at all clear for the society we all live in.

For a little comparison, while mostly none of us has ever put a foot in a sewer system, we have quite a good idea of what it looks like (maybe a bit false, but yet a good grasp) and we do recognize the utility of having people working on it... and moreover we won't ask these people if we know them to come home for a good dinner and a toilet flusher replacement.

Difficulty is that, even inside the IT field, it is quite hard to keep on the track. You can never rest and think you've learnt everything for the coming ten years (but that's the beauty of it).

As the Nautilus' motto "Mobilis in mobili" expressed it, IT field is constantly moving in a moving society...
The problem being IT should be part of the society and not a wonderful submarine lost in the society's deep sea...

So we have two separate moving things:

A ocean of People's view on IT, not even close to the point. Yet this view is shifting; but at a slow pace.
A flow of the IT field, moving at a great speed, with such a thick hull that nobody can imagine what's inside.

What do you think "normal folks" think about when they see commercials about blade servers on TV? What do you think they'll understand when they'll be served Web 3.0 and SOA 3.0 next to Windows Vista Extra and diapers?

IT vocabulary has become so gibberish and acronyms so much the focus of IT business that nobody, except if properly documented, can have the equivalent of the grasp we have of the people working in sewers...

So I urge each and every IT worker in the world to go out of its dark and badly ventilated office and explain to the world that his job is as valuable as any other in the world, and using as many metaphors as needed, to explain what he's really doing!

This way we'll be able to synchronize a bit these flows...and integrate IT in our society.

Get your hash covered!

2006-08-31T23:26:00.000+02:00

Today, after a long and truly joyful refactoring session, I stumbled on this article about hashcode() method's coverage.
Which reminded me of David dossot's blog entry dealing with the problem of coverage.

It made me wonder a lot about the big difference between rich client software and J2EE middle tier software : test coverage.

If hashcode() methods' coverage is so hard to obtain or at least can be so boring to do when you have tenth of value objects in your code, at least it can be done!

I for myself feel completely lost and have no clue on how to unit test the code of an eclipse plugin or the code of an Eclipse RCP app...

As a good (well trying to...) J2EE developer and POJO fan, I tend to encapsulate all my specific logic in specific as-POJO-as-can-be classes.

Therefore making these classes testable.

But what about the real tricky-buggy part of these apps: GUI!

I for myself am missing a lot of tricks and patterns for testing this.
And by testing, I mean unit-testing. Because GUI also diserves it. And not only integration tests.

In the end when you think about the code of an Eclipse plugin's UI and the strategies you'd have to use to unit-test it... hashCode() seems like bliss ;)

My Kingdom for a release!

2006-08-24T23:54:00.000+02:00

After yet another day of pom.xml and settings.xml and other properties tweaking, I must admit I'm quite satisfied with my Maven 2 builds.

Still it is not completely satisfying...

The main problem I can think of if that almost 2 thirds of the plugins available on the apache and codehaus repositories are not even officially released.

And I'm not even talking about the exotic plugins generating weird things or weaving any exotic kind of AOP ;)...

Some of the core features can completely be ruined from an automatic update to another (my last memory of it is the site plugin now ruined by a beta functionality from the skin plugin...).

Problem is that even released plugins are often tied to beta ones.

So I beg the maven plugin developpers to gather and to try and elaborate a Callisto-like release!

This will benefit to both users and plugin developers.
Even if some plugins are buggier than others, at least it will not feel like walking on a pile of rolling stones all the time ;)

Driving the change

2006-08-09T17:23:00.000+02:00

I'm having a hard time finding people who are never in a destructive state-of-mind in the IT field.
Each and every people has a good reason at a given moment to resist to change.

It seems difficult for everybody to realize that embracing changes before they occur is the key to longevity and sanity in the IT field.

The problem with IT systems is the same as with employment. Stability and Longevity are now enforced by constantly moving ahead. Trouble comes when people are in a Cobol-ish/Mainframe-ish state of mind, thinking that every single piece of an IT System is destined to last whatever happens.

In the end everyone finishes up blaming the audacious for the sake of costs and responsability.

In fact it is difficult to handle change when you're not driving it. I guess that's why I tend to go to the change orientation part, so that I can precede change instead of being its victim.

So at the end of the day is it really a matter of resistance to change or more a matter of resistance to change driven by others?

Erasure/Reification and Forward compatibility...

2006-07-20T08:09:00.000+02:00

Recently, while I was trying to build a core mocking API based on reflection with JDK 5.0 (what one would do during his spare time...), the amazing subject of (type) Erasure with Generics appeared to me...

(For those already knowing everything about erasure, roll a 20 and go to number 2) Thanks to JDK 5.0 Generics, most people think that Collections can now be brilliantly assigned specific types of objects, removing the clutter of casting-all-around. Don't be afraid, but Generics in JDK 5.0 are not really the Generics you think they are! For reasons detailed below, Generics where sacrificed at the altar of Erasure! So let's be more specific. When you declare... say... a Map<String,BigInteger> myBigIntegerMap and a Map<String,Float>, the compiler will replace them with a Map and a Map! The compiler keeps all the code in a common class and adds some type conversions and type checks along with bridge methods for the specific types you declared, but it completely erases your beautiful type arguments from the runtime code. This is (insert dramatic drum roll here) type ERASURE (insert crash of cymbals here)!
The positive effect is that it ensures backward/forward compatibility by (almost) not modifying existing collections and avoiding the mess that can be found in recent version of #ed languages and described in David dossot's blog entry. The negative one is that you will never be able to discover these types by reflection, because nothing differs myBigIntegerMap.getClass() from myFloatMap.getClass()... and you'll have the surprise to see that (myBigIntegerMap instanceof Map) is a true statement! I can't wait to see the java puzzlers derived from these Generics...
The opposite system of Erasure is Reification. In this system, information is kept at runtime as first-class entities and can therefore be accessible for the true happiness of ORM tools developpers and such... Tough talks went on long before the release of Generics with JDK 5.0 about whether backward/forward compatibility could be attained with reification. It appears that such a goal could be attained, but is not even planned (as I know of) for JDK 6.0...

So knowing that two questions pop out of my humble mind:

Does a software of any kind always has to ensure backward and forward compatibility, even when slowing down innovations?
Do JDK 5.0 code really has to run with older JRE's?

If you answered yes to any of these questions, then ask yourself : should these requirements be mainstream, or handled by adapters?

JDK should at least handle backward compatibility and moreover migration compatibility. Meaning that interoperability should be a real asset! This doesn't mean that Generics should be reduced to Erasure for the sake of it!
This just means that :

adapted Serializers could be coded in order to ensure compatibility with existing older codebase used through RPC calls
adapters could be coded for older codebase used in the same VM.

So what do we do now?
I for myself saved my day by just asking myself the right question : what is the most elegant way of getting to my goal as I can not wait for JDK 8.0 ? ;).

My own solution was an annotation added to the Collection attribute I wanted to attain by reflection. Annotations can be attained at runtime by reflection, and are checked by the compiler. This adds a little bit of clutter and doubles the declaration of my type argument(s) but it does the job!
So I now have to declare :
@CollectionRuntimeInfo{type=Integer.class}
private List<Integer> myIntegerList;
@CollectionRuntimeInfo{type={String.class,Integer.class}}
private Map <String,Integer> myIntegerMap;

So I was just wondering that if instead of replacing Erasure with Reification, the compiler could automatically add an annotation to the Generics with the type arguments, we would save the day without affecting the forward/backward compatibility paradigm!

But I'm not (and will surely never be) part of the JCP, and am probably occulting a lot of potential issues... but it's still worth looking ;)

From software to detergentware...

2006-07-09T19:12:00.000+02:00

Web 2.0, Ajax, SOA 2.0 and 3.0; those are magic words to the ears of the Gartner-worshipers all over the the world. Adding buzz-words to buzz-words seems to be the latest trend in technological cocktails.
In fact, more than mere words, it is interesting to see how software retailers and software makers are now kept away from these buzz words.

Do you remember the beginning of the web Era? How many managers or marketing people have mispronounced or misunderstood the technical web jargon? But this was a jolly foolish time when marketing of software was technologically-driven!
Third millennium has dawned the era of real marketing in software!

Computing has never been about technologies by themselves... in fact it is more about who's going to use these technologies. And this is of course the job of marketing to link companies to their customers. Customers looking for incredible things like QoS, TCO and RoI...
But until last year or so, the frontier between technical concepts and marketing concepts was a one-way ride...

So where do Web 2.0 and SOA 2.0 come from? Are these merely technical concepts?

To me they are blankets pulled over the software market in order to convey a clear message :
"Web or SOA are dangerous investments for your company? Forget about this, Web 2.0 and SOA 2.0 are there! And believe me or not, they are simpler to use and provide a better result!"
So even if this sounds like the "even whiter than white" you could hear in any detergent commercial, this has two opposite side effects:
on one hand it brings a new interest from cautious companies to the products, but on the other hand it conveys the ambiguous message that older or not labelled Web or SOA implementations are hell on earth.

And this is where things are slowly shifting. The same way economy influences politics, economy and market clearly influences technology...
You'll say to me that this is not new, but it is quite disturbing to realize that in order to talk about the technologies you implement and/or originate, you have to adapt yourself to these marketing concepts...

In fact this shift is quite important and is quite representative of what's at stake in the coming years.
Open source project without a clear marketing plan are more and more out of the game, but more than that, they have to adapt to the advices of marketing/management gurus like Gartner. First SOA has been sold like a complete replacement of the frightening EAI acronym. Then SOA has turned from an abstract concept like OOP or AOP to a complete marketing concept shadowing the beauty of the described technology. And the whole World Wide Web (and all the underlying concepts) is now versionned by absolutely arbitrary and meaningless numbers.

But don't be mistaken, branding is quite important! Yet as long as a brand is applied to a product. But let's imagine that from now detergents enter in the era of "detergent 2.0"... and that each and every detergent company who wants to be taken seriously has to print a beautiful "detergent 2.0" logo on the product. You'll soon see all the products branded with this logo... and the concept being completely blown away.

There's hopefully still some room for products branded with reason and offering a good balance between technological efficiency and QoS/TCO/RoI.

But it is now a full-time job to invent detergent names for software and to understand what's white and what's whiter...

It's fresh! fresh!

2005-03-22T10:33:00.000+01:00

... exciting!
It's always great to begin something like a blog, to publish your deepest thoughts...
This is so not what I'm going to do here.

You won't have even a bit of my deepest thoughts to admire, and this will be mostly about funny and stupid things I will notice, or I'm fond of, and about my everyday's work .

So feel free to comment my words of wisdom (a.k.a. bullshits).