james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Zhukov <zhu...@ukrpost.net>
Subject Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Date Wed, 23 Feb 2005 15:52:31 GMT
Siegfried Goeschl wrote:
> Hi 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?!
Well my goal is to make james a set of CDI style POJOs
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/server-dev@james.apache.org/) 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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message