Hey Peter, thx. It's worth reading. IMHO I would do anything done with Monitors within a Aspect. AOP is better to encapasulate things which can lead to a bad code smell (ShotGunSurgery, http://c2.com/cgi/wiki?CopyAndPasteProgramming) and hurt the DRY principle...
-- tobias rademacher [sofwareentwickler] innoWake gmbh innovative.software.development(); graf-arco-strasse 18 | 89079 ulm-donautal fon: +49 (0)7 31 - 5 50 27 - 0 fax: +49 (0)7 31 - 5 50 27 - 20 [EMAIL PROTECTED] www.innowake.de > -----Urspr�ngliche Nachricht----- > Von: Courcoux Peter, Slough [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 30. Juni 2004 16:30 > An: 'Turbine Users List' > Betreff: RE: Container Support in Turbine > > > The following document, which I believe was written by Alex > Karasulu may be > of interest to anyone looking at IOC containers. The bit on container > independence might be particularly appropriate. > > http://incubator.apache.org/directory/subprojects/eve/components.html > > Regards, > > Peter > > -----Original Message----- > From: tobias rademacher [mailto:[EMAIL PROTECTED] > Sent: 30 June 2004 13:44 > To: Turbine Users List; [EMAIL PROTECTED] > Subject: AW: Container Support in Turbine > > Hi Eric, > > > Now, the nice thing about using the Avalon based components > > is that they > > will run unchanged in both the Excalibur and Merlin containers. > > Additionally, since Avalon is an Apache project, using them > > follows the "Eat > > your own dog food" approach. We get great support from the > > Avalon mailing > > list, and many of the Fulcrum components run in either > > Excalibur or Merlin > > containers in their unit tests. Some even run in BOTH containers! > > The __interfaces__ you write for Avalon should compatible > with all other > IoC containters - despite the Component inferface dependency. > All you have to do is to provide several implementations. > Other framworks tend to be more non-invasive. In fact this is > just a matter > of taste. > Everybody knows that frictionless/architecuturless components > are currently > just a dream ;) > > As Avalon does not resolves dependecies by itself (you have > to do the lookup > in IoC Type I) > this is the only resaon for reimplemention. Maybe some taff > guy (or even a > girl ;) ) > has a great idea who to abstract with with > yet-another-cool-way-to-create-an-apdater ;). > > > > Having said that though, Turbine is an open source project, > > and if you have > > an itch, scratch it.. I would be happy to see > > Pico/HiveMind/Spring/Name > > your container support added to Turbine. The components in > > Fulcrum (like > > Security) right now work just with Avalon containers. > > However, this is > > mainly an artifact of the principle developers using Avalon > > containers. If > > someone wanted to abstract out the container aspects of > > Fulcrum Security so > > it would run in multiple containers, as long as there where > > sufficient unit > > tests, I'd be happy to have that. > > Of course. I tend to agree and will discuss this point in the team. > __Maybe__ we can provide the > Spring-Hibernate-Flucrum-Security stuff for the > community?!?. > If not I could try to remplement it at home. It's really a > pice of cake. > > > > > Heck, someone wrote a SimpleContainerService which in turn > > looked components > > up from a chain of containers, returning the component the > > first time it > > resolved properly. That way the rest of the application > > doesn't know/care > > what container is being used. > > As having said: frictionless/architecuturless components are > just a dream > but not impossible ;) > Has someone a cool concept/idea/thought convering this? > > > -- > tobias rademacher > [sofwareentwickler] > > innoWake gmbh > innovative.software.development(); > graf-arco-strasse 18 | 89079 ulm-donautal > fon: +49 (0)7 31 - 5 50 27 - 0 > fax: +49 (0)7 31 - 5 50 27 - 20 > [EMAIL PROTECTED] > www.innowake.de > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
