Container's hype

[julien1]

I see these days a lot of interest for container development. It seems that, like for AOP, every one is developing its own container, each one claiming that his container his the best (otherwise why not reuse another container instead of reinventing the wheel)

The last one I saw is picocontainer (http://www.picocontainer.org). They say to implement IOC type 3. That means Inversion Of Control type 3, type 3 means they use the following pattern to identify dependency between components.

The rule is to provide one constructor (and only one) per class that want to be a component. The component will thus depends from these identified components.

for instance with class A {}, class B { public B(A a) {...} } :

PicoContainer pc = new PicoContainerImpl();
pc.register(A.class);
pc.register(B.class);
pc.start();

That's very minimalist, will they go further ?

Anyway, my thought is that container developers are missing key points.

Unlike JMX they cannot hot replace components.

It seems also that they don't have an advanced loading mechanism.

It seems that they focus a little bit too much on component dependencies and the pattern Inversion Of Control, and plenty of blah blah blah my container is beautifull.

Maybe I am going to develop my own Container. I have to be original. I will develop the idea I used once when I talked about the RandomInterceptor that made laugh people, that interceptor forwards the call randomly to the successor. There are some ideas to exploit in there I am sure. Then I will blog that my container is the best. Of course, I will not forget to plug an exotic AOP framework within it, to be fully hype certified.

julien

[julien1]

Another funny blog to read :

http://www.freeroller.net/page/cv/20030701#dreaming_of_aop_transactions

this guy believes he has invented something new.

[cv]

I don't believe to have invented something new, at all. But if it's nothing new, then, where's the implementation?

[juhalindfors]

I agree it seems a bit suspicious seeing statically linked dependencies in a component framework -- I wonder what their plans are on supporting systems requiring high availability during maintenance/runtime update of components. Given Java's current classloading model it seems tricky unless you're prepared to throw the whole container away every time you redeploy.

With the new HotSwap technology its manageable but even then you really would want to have the stage 2 implementations at minimum that allow not only the evolution of method bodies but class structure as well.

But I haven't looked at any of their code or their intended target of requirements.

[juhalindfors]

> I don't believe to have invented something new, at
> all. But if it's nothing new, then, where's the
> implementation?

Transactions with AOP? It's in the CVS, jboss-aspects module.

[julien1]

http://sixlegs.com/blog/java/not-a-container.html

[shareme]

maybe they were trying for hot as in hype non loadable components?