james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Funnell <simonfunn...@googlemail.com>
Subject Re: Not Mine
Date Wed, 18 Nov 2009 23:59:58 GMT
Eric MacAdie wrote:

Erm, I am not sure if my aim is replacing Avalon. I would have no 
problem recommending other projects other than my own. In fact at stage 
that is exactly what I would do. Spring is well supported and mature, it 
has a lot of great features my doesn't. Guice also, after some study I 
am thinking of actually employing it myself. I guess another way to look 
at it is like this, can James components be designed in a fashion that 
accommodates a broader range of frameworks? I think the answer is yes.

I hope this is a bit clearer.

Simon


> If I understand this thread correctly, you want to replace Avalon with 
> a custom framework. I think that this is not a good idea. Moving from 
> an obsolete framework to a custom framework seems like jumping out of 
> the frying pan and into the fire. I think it would be better to use 
> something that has traction in the larger Java community, like Guice 
> or Spring.
>
> Eric MacAdie
> Pronounced: muh-KAY-dee
>
> Simon Funnell wrote:
>> Hi,
>>
>> By the way, its only 'my' framework by virtue of the fact there is no 
>> 'our' to refer to. I could probably refer to it as 'the' framework 
>> with you being able to infer what I am referring to from experience, 
>> but its actually called 'Platformed' and I intend to make it open 
>> source. Also, after some research and reflection, I actually think 
>> its much more suitable (it was designed for this purpose). There is 
>> no escaping some of the differences in approach however. I am quite 
>> willing to invest some time implementing some things which you can 
>> take a look at, it really wouldn't take to long to modify some 
>> existing code. Avalon defines interfaces such as Loggable(?) but 
>> there is no equivalent concept with what I am doing because all 
>> things are inherently loggable, components do have to be built in a 
>> way that enables loggability (and lots of other things) though. It 
>> basically means breaking down some of the existing code into smaller 
>> chunks that can pieced together. These smaller chunks could be 
>> recomposed into an alternative implementation of existing classes and 
>> I could also use these smaller chunks in a different arrangement. As 
>> I say, I could implement an example which would allow people to make 
>> an evaluation about any sort of decision or what not.
>>
>> I think you might actually like it, it was written a while ago and 
>> its only by looking at it closely again that I remembered how much 
>> work I put into it. My last email didn't accurately reflect the whole 
>> architecture, the micro virtual machines I have touched on are 
>> extensible through 'operations'. Current James classes have methods 
>> such as initialize, service, destroy etc, I would have to replace 
>> these methods with actual classes (which implement an interface 
>> called Operation). Operations are stateless instances that implement 
>> functionality, micro virtual machines provide the operations with a 
>> context upon which to operate. Different micro virtual machines can 
>> have contexts like application/session etc depending on what's 
>> required. If you wanted to log the state of any given machine, at any 
>> stage, you just plug in a logging operation at the necessary place. 
>> This can be done dynamically, like for example an individual client 
>> matching some criteria. The smaller things are, the more reusable 
>> they are. I could very easily create an adapter that takes existing 
>> mailet/matchers and transforms them into Operations for  micro 
>> virtual machines processing the spool.
>>
>> I've probably said too much/too little so I wont post again until I 
>> get some feed back, or have something working, which ever comes 
>> first. I am still interested in producing some documentation as well, 
>> suggestions are welcome.
>>
>> Thanks,
>>
>> Simon
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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