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 13:31:02 GMT
Hi Peter,

> Eric is talking about cutting a 'milestone' release of 2.4 
> this weekend for
> people who wish to use a cut of cvs with the pipeline (for example the
> antelope project).

This would be really cool ;).

> Having done it a couple of times, I think turbine 2.3 --> turbine 2.4
> migration is pretty straight forward at present.

..not if you don't exactly use all the snapshot versions of commons 
used in Antilope.
Actually this is more a problem of dicipline of the commons guys.
Its somewhat lame to release something with a unstable API. But even
M$ did this - consider the drama when .NET Beta1 increases all
developers have to change there current code. There are many critical
voices about the way Sun deals with Java, but thanks to the Sun guys
I never experienced such problems when migration a beta-JDK probject
to a new one - even with a couple language changes (Merlin beta to Merlin Release,
same can be reported about Tiger).
Having said all of that the commmons projects defintily needs some sort of
chair, but actually its in the responsiblity of every developer if he 
uses a snapshots or not. IHMO APIs and Interfaces should be stable whereas
implemenations may differ.

> Having spoken at length with Eric recently, we are both 
> tending towards
> proposing Excalibur-Fortress as the default container for Avalon style
> components in turbine 2.4. If anyone has anything to 
> contribute on this
> topic, please do so. It would be great to get opinions...

The avalon guys should really minimize the container locks or stop spanning
yet another freaky container syndrome. ;) I hope can work luckly now with
the excalibur stuff, keeping my fingers crossed.

> SOC and IOC work for me and I find the Avalon framework 
> interfaces very
> convenient. 

Does they support higher levels of Dependency Injection now?

> Keel uses Fortress also as its container, but as you say, it 
> should be easy
> to add wrappers or adapters to allow components to work in 
> many different
> containers.

Yes definitly. There are some modifications necessary. I minor problem
are the lifcycle methods, but they can be abstracted away. All what have to
be done is defining a minimum set of interfaces and bases classes working
completly idependent in all sort of containers.

> I think Eric is interested in the Spring service. Could you 
> contribute it?

I hope I am allowed to do. If not I can write some new by my own in
order to avoid licences clashes. Actutally you have to reimplementd all
Manager Components access the DB using Hibernate. Having done this you have
to modify some Turbine Components in order to get it working painlessly with
Spring. Spring has a different philosophy. The Container Registry is bind
to the servlet context which means that you have to switch some components 
(Tools, AccessControler, LoginAction, LogoutAction, etc.) to work request orientent
and not on to of the more static factory like conecpt TurbineServices introduces.


> -----Original Message-----
> From: tobias rademacher [mailto:tobias.rademacher@innowake.de] 
> Sent: 06 August 2004 10:48
> To: Turbine Users List; hps@intermeta.de
> Subject: AW: AW: Dependency hell in 2.4 (was AW: troubles migrating to
> turbine 2.3)
> 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 on
> 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.
> Toby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> Scanned for viruses by MessageLabs
> Scanned for viruses by MessageLabs. The integrity and 
> security of this message cannot be guaranteed. This email is 
> intended for the named recipient only, and may contain 
> confidential information and proprietary material. Any 
> unauthorised use or disclosure is prohibited.

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

View raw message