turbine-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tobias rademacher" <tobias.rademac...@innowake.de>
Subject AW: AW: Dependency hell in 2.4 (was AW: troubles migrating to turbine 2.3)
Date Fri, 06 Aug 2004 09:48:04 GMT
Hi Henning,

> >BTW Any roadmap ideas? ;)
> Only for 2.3. I plan to CfV for 2.3.1 very soon now. I was hoping that
> the Torque guys would get their act together for 3.1.1 but it doesn't
> seem that they will.

Unfortunaly it the Antilope Application does not work with 2.3.x as
the Antilope folks already use the Pipline. New users are told to look into
that Application. Flux is not longer supported. So this where 
I see some problems when 2.4 stay unreleased over a long time ;).

> [1] Personally I always had an ambient look at those "end all, rule
> all, do all" frameworks like Avalon, HiveMind or Spring.

Peter already told me the troubles and nigthmares with Avalon Containers.
Fulcurm is really not bad -  With a small set of modifications the
services should work independently in every IoC Container.

I personally unterstand the "eat your own dogfoot" philosophy and
so the descision of using Avalon. 

HiveMind seems to be not very stable for production. IMHO is really
to overconfigurable, not marture and I personally stay way from 
non standard configuration files (the HiveMinders seem to promote there
non-xml syntax but I think configuration with go into the Annoation direction
for most cases and XML will stay where Annotations don't work).

Spring is a very invasive framework. The services are deployable in every
IoC 2 or IoC 3 Type Container. In Spring you have not to use the
DAO Framework or the Spring-MVC but you may. With some code teaks and
clue code we currently run Turbine 2.4 on top of Spring not on Avalon.

I personally guess that IoC is just 
desing technique and Depencendy Injection is quite cool but if the
containers change too frequently  is not worth a pence.

> The endless
> in-fighting around Avalon, the Avalon PMC, the Merlin project, the new
> proposed top-level Metro project are not building trust in their code
> (in my eyes).

If this is really the case it could be the death of the hole project.
What about the Keel Container? Is Keel more stable?

> And I think, that the IoC metaphor is already overrated, dragged
> around too much and (also IMHO) not really feasible for some aspects
> of a project. Just another buzzword.

Yes definitely. Some certain rumors about the new EJB Standard 3.0
shows that the hole IoC carousel influences the next
standards. No matter if you personally use EJB or not this shows
the great impact of all this leightweight container rank growth
of the last couple of month.

> I was never really able to figure out how to translate e.g. our
> logging approach with log objects and logging into categories into an
> IoC approach.

IMHO logging belongs in the AOP world, definelty not all kind of logging,
but the main part of course. Seperation of Context is fine, but there
are more elegant techniques for certain things available.

Personally the thing bothers me a lot about Avalon: You "pollute" your own code
with container dependenies (avalon xxx.jar) as you have do resolve the depending services
our own. The same is true about the thousands Naming Lookup you have to do
whenever you want to use services of a Session or a Entity Bean.


To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

View raw message