Adam Bien's Weblog

Main | Next page »

Monday Mar 08, 2010

How To Kill An OSGi Project - With 10 Questions

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:

What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
How many versioned modules will be active at the same time in production?
How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?

The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA.

For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once.

If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare.

Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]

Posted at 10:28AM Mar 08, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[10]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Sunday Mar 07, 2010

Killing Some Bloat in Gothenburg - With Java EE 6

I will spend few hours in Gothenburg at the SDC 2010 conference and give a talk with the title "Lightweight Killer Apps with Nothing But Vanilla Java EE 6". I'm really curious whether my first slide will look familiar to you - people outside Sweden are thinking, that it is the Golden Gate Bridge, what is entirely wrong.

I will have some time after the session. So if you have some questions, want to discuss, or hack some code - just ping me. I planned to spend more time in Gothenburg - a really nice city. Because of the project (over)load, probably caused by the general Java EE 6 take off :-), - I will only spend few hours.

Posted at 10:28PM Mar 07, 2010 by Adam Bien in Events | Kommentare[0]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Saturday Mar 06, 2010

What Is www.sun.com/ponytails/ ?

An interesting URL: http://www.sun.com/ponytails. It gets resolved to: http://www.sun.com/software/opensource/. Now the question - why ponytail? :-)

Posted at 12:51PM Mar 06, 2010 by Adam Bien in Fun | Kommentare[4]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Friday Mar 05, 2010

Best of 2009 - Most Popular Posts (Dead DAOs, Bloat Without EJBs, Java EE vs. Spring, VOs vs. DTOs)

January: In The Age Of DRYness - Do We Really Need Naming Conventions For Interfaces? (11288 Views)
February: DAOs Aren't Dead - But They Either Collapsed Or Disappeared (9565 reads)
March: What You Can Build In 50 Minutes With Java EE 5/6? (25942 views)
April: Lean service architectures with Java EE 6 - And EJB 3 in particular (4304 views)
May: Netbeans 6.7 Beta + Maven = Heaven (more than promising) (11697 views)
June: Real World Java EE Patterns - Rethinking Best Practices Book And Project (15456 views)
July: Lean Java EE 6 Without Spring And Spring 3.0 In Java EE 6 World: Summary and Conclusion (eJug Session) (16203 views)
August: Value Object vs. Data Transfer Object (VO vs. DTO) (15928 views)
September: Why Oracle Should Continue To Push NetBeans (18974 views)
October: (JSF + JPA) - EJB = Bloat (17436 views)
November: Two Amazing NetBeans 6.8Beta Features (8877 views)
December: Java FX Composer / Designer for NetBeans 6.8 - First Smoke Test (15276 views)

The views above are monthly results - not overall views. The actual number should be much higher. RSS/Atom-Feed results are not even included in this statistic. The daily average ranged from 4.5k - 8k.

The stats for the year 2010 are more than promising. February is already the best month ever. Thanks for reading and especially the constructive 2.5k (!) comments.

Posted at 09:56AM Mar 05, 2010 by Adam Bien in Blog Statistics | Kommentare[0]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Sunday Feb 28, 2010

Oracle Data Sheet About ...Glassfish

"...Oracle GlassFish Server is part of the Oracle Fusion Middleware application grid portfolio and is ideally suited for applications requiring lightweight infrastructure with the most up-to-date implementation of enterprise Java, Java EE 6, and Java Web services. Oracle GlassFish Server complements Oracle WebLogic Server, which is designed to run the broader portfolio of Oracle Fusion Middleware and large-scale enterprise applications..." Read the whole paper.

Posted at 10:34AM Feb 28, 2010 by Adam Bien in General | Kommentare[2]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Friday Feb 26, 2010

Jigsaw / JDK 1.7 will be the solution for 80% of the modularization challenges

Jigsaw will come with JDK 1.7 and is now part of the openjdk project and so opensource. Other JDK implementations could simply reuse it.It will become interesting, because:

It will be shipped with every Oracle / Sun JDK 1.7 (at least it was the plan)
Jigsaw will partition JDK 1.7 and will be loaded before most of the rt.jar code. So is already there - no reason to introduce another framework
Its pragmatic: you can split packages across modules. Package splitting isn't a best practice, but makes the incremental modularization of legacy projects a lot easier
Modules are loaded statically - no reloading. This is good enough for the most projects. Its funny - but in most NetBeans RCP / Eclipse RCP projects we had to deactivate the ability to load modules dynamically in production :-). Server operators don't like dynamic behavior either.
It seems like there will be only one classloader, which will load all modules. This will eliminate majority of NoClassDefFoundErrors.
javac will be jigsaw aware - this is a major advantage. Module dependencies should be checked as early as possible - it fits well with the nature of Java.
Jigsaw should increase the classloading performance and significantly reduce the size of the jars and so the deployment

Posted at 11:00AM Feb 26, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[24]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Monday Feb 22, 2010

Simplest Possible EJB 3.1 Timer - Configured Programmatically

@Singleton @Startup public class PeriodicTimer { @Resource TimerService timerService; @PostConstruct public void initialize(){ ScheduleExpression expression = new ScheduleExpression(); expression.second("*/1").minute("*").hour("*"); timerService.createCalendarTimer(expression); } @Timeout public void execute(){ System.out.println("----Invoked: " + System.currentTimeMillis()); } }

A timer doesn't have to be a singleton - it can be a @Stateless and even a @Stateful bean. The method execute() will be invoked every second after the deployment. The programmatic registration is only an option. You could also use annotations for the timer configuration.

How to compile:

You will need the EJB 3.1 API in the classpath (few kilobytes).

How to deploy:

Just JAR or WAR the interceptor with an EJB and put the archive into e.g: [glassfishv3]\glassfish\domains\domain1\autodeploy

Btw. the initial deployment of the entire WAR took on my machine:


INFO: Loading application ProgrammaticallyCreatedTimer at /ProgrammaticallyCreatedTimer
INFO: ProgrammaticallyCreatedTimer was successfully deployed in 316 milliseconds..

How to use:

Another service can be easily injected to the timer and so invoked periodically:


@Stateless
public class HelloService {
    public String sayHello(){
        return "Hello from control: " + System.currentTimeMillis();
    }
}

And: there is no XML, strange configuration, libraries, additional dependencies needed...You will find the whole executable project (tested with Netbeans 6.8 and Glassfish v3) in: http://kenai.com/projects/javaee-patterns/ [project name: SimpleTimer].

Posted at 09:00AM Feb 22, 2010 by Adam Bien in General | Kommentare[3]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Friday Feb 19, 2010

Spring vs. Vanilla Java EE, Real World Java EE Workshop and The Perfect Storm

Next week will be all about Java EE 6. At the ejug conference in Vienna I will start (23.02) with a "fight" against Juergen Hoeller and discuss the Spring vs. Java EE thing. We did it already last year - but now Java EE 6 is out with an API designed by SpringSource. I will also give a dedicated Java EE 6 / EJB 3.1 / CDI / REST / JPA session about Xtreme Lightweight Architectures (you could also call that "weightless" :-)).

The next day (24.02), at the Jax London conference (The Perfect Storm session), I will use more the IDE and "hack" a Java EE 6 application live on stage. I will try to kill some Java patterns with Java FX as well.

The last day (25.02), again in Vienna, I will give a whole day workshop "Real World Java EE (Patterns) - Rethinking Best Practices", somehow related to my latest book. We should have enough time to discuss project specific things and issues. I will try to explain as much as possible with working code...

I'm also already looking forward to the SDC 2010 conference in Gothenborg!

Posted at 09:00AM Feb 19, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[5]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Saturday Feb 13, 2010

Java FX App on the official winter olympics site

The "Medal Visualizer" app: http://www.vancouver2010.com/olympic-medals/geo-view works well. Its actually a good test for the penetration of the Java FX platform. See also Oracle's the press release.

Posted at 10:03PM Feb 13, 2010 by Adam Bien in RIA / Java FX | Kommentare[16]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Wednesday Feb 10, 2010

Glassfish v3 in an (opensolaris) zone ...an interesting error and solution

After the installation of Glassfish v3 in an opensolaris zone, Derby booted perfectly, but Glassfish v3 threw this interesting exception:

Waiting for DAS to start ..Error starting domain: domain1.

The server exited prematurely with exit code 6.

Before it died, it produced the following output:

UTF ERROR ["../../../src/solaris/instrument/EncodingSupport_md.c":66]: Failed to complete

iconv_open() setup

A zone is a lean, isolated kernel with only the essential stuff. It comes without any language and encoding support. The remedy for this problem is the installation of the package (SUNWlang-enUS) with: pkg install SUNWlang-enUS, and setting the preferred language in the .profile to e.g. export LANG=en_US.UTF-8 (thanks Manfred Riem for this hint).

Zones are really interesting for configuration and isolation. They are pretty fast as well. Booting a zone is almost as fast, as deployment of a Java EE 6 application :-) -> on my machine it takes <1 second.

Posted at 10:11PM Feb 10, 2010 by Adam Bien in solaris | Kommentare[0]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices