Well my goal is to make james a set of CDI style POJOsHi Alexander,
it is none of my business but it means that you have to migrate the cornerstone and excalibur-datasource stuff as well?! I also assume that you are using a IOC container such as Hivemind or Pico/Nano Container?!
As for datasource stuff i just leave interface dependency
"public MyPOJO(DataSourceStuffInterface ds, OtherDepsHere ...)"
and write dummy implementation of that interface ready to be junit-tested, launched by developer to test the idea of CDI IoC applied to james current code.
Same applies to other non-jdbc related interfaces.
If someone wants he can use cornerstone/excalibur implementations of those interfaces.
My point is to remove ugly configuration code from james and make POJOs not search its configuration itself but accept dependent components as parameters in constructor.
Injection of dependent components (the process of configuring) is a concern of any light-weight container, the exact container (whether it is hivemind/picocontainer) does not matter for me.
As an example I wrote dumb container (one class few K of code) which is configured by standard james-config.xml familiar to james users and developers.
Executive summary: make james a set of POJOs, container does not matter if you have a set of POJOs
Cheers,
Siegfried Goeschl
Siegfried Goeschl
Alexander Zhukov wrote:
Siegfried Goeschl wrote:
Hi Aron,
I would like to point out that there is the James project suffering badly from the Avalonic wars (hence the cross-posting to the James Developer List). They recently had a long discussion to make an Avalon-free JamesNG (http://www.mail-archive.com/[email protected]/) but my gut feeling is that it won't be an easy task.
I am currently working on removing avalon dependence from current v2x source of james and making james a set of POJOs
And I guess by the end of the following week it will be ready to be testable by other developers
Yes you are right the task of throwing out avalon is not easy but its worth the trouble.
It took me about two weeks already - I have pop3 and smtp servers running, but not clean enough to show others.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I vote for the last one + reuse components already written by making them POJOs
I'm not sure what the current mood is - well, my first impression is that removing Avalon make them very happy :-) - but we have to keep the James community informed on our on-going work regarding Fortress and Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
Thanks for the clarifications. I'm very interested in seeing what Excalibur can do to make things easier for the Turbine folks.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
Exactly.
IMHO Fortress is pretty simply already, but we need better documentation and we can definitely make it more simple. The goal of Fortress 2.0 should be to make implementations like yaafi unnecessary.
So, if I'm reading this correctly, Fulcrum will become a more generic component library not necessarily tied to Turbine, right?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
