You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Simon Funnell <si...@googlemail.com> on 2009/11/18 23:06:17 UTC
Not Mine
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
Alien Ideas
Posted by Simon Funnell <si...@googlemail.com>.
Stefano Bagnara wrote:
> I'm not sure that "next generation frameworks" means "declarative logging.
>
Neither do I, but by definition one generation follows the next and the
current generation doesn't properly address the issue while the next
does. Its not just logging however, there are other things, like
inheriting exception handling policies, security and other cross cutting
concerns.
> IMHO declarative logging (the way you described it) cannot and will
> never replace standard logging. It could be used together, but not
> replace all of logging.
>
I disagree of course, but only in principle. It's a simple matter of
adding logging(and other things) 'after' the functionality instead of
'before' it in the inheritance chain.
Many components in James extend AbstractLogEnabled putting it 'before',
I realise this is a stumbling block but its not a massive problem.
> It would be a PITA to mantain that style of declarative logging.
Maybe, but I don't think so. If everything is well documented, it
shouldn't be a problem.
> BTW
> if you have more documentation, examples, code, evangelization
> articles, to help me why declarative logging will be used in the next
> generation framework I'd be very happy to read it. I'm very interested
> in improving the logging aspect of libraries/application as I feel the
> logging one of the most problematic issues in current design. I don't
> like per class logging (Log.getLogger field), either static or per
> instance and I prefer injecting logging services, but I still don't
> see how to completely remove logging in favor of a declarative
> approach.
How about writing components with no references to loggers or logging
whatsoever? (Your mind will instinctively reject this idea...as time
goes by you will accept it as the best way...a bit longer and it will
become the norm....its already the norm in some organisations....) It's
really simple, you add logging (and other things) after, not before.
This is the point of components, they are not classes, a good component
model supports coupling/binding of functionality at any time. In my eyes
(and with the design I am following) a component 'is' a framework, all
of its elements are pluggable and you can change individual elements, or
add more elements, on a per request basis.
Generational inheritance is not suitable for everything.
Look at it this way, if you view James as a community of components and
initially this community does not have a logging component, so sorts
mail without logging. A logging component now comes along but because we
are using generational inheritance the new logging component literally
has to mate with existing components to create a new generation of
components that have the logging gene{for example, getting a logger
property (gene?) by extending the parent AbstractLogEnabled). This is
not want we want, instead what we want is our new logging component to
come along and share its inherent ability with the rest of the
components in a transparent fashion. In this alternative scenario other
components in the community that make up the application inherit logging
capabilities through 'nurture' rather than 'nature', i.e. components can
become more sophisticated by inheriting from peers as well as parents.
> Can you take a class from our repository and show how to
> refactor it to use declarative logging (also including the declarative
> logging part needed to produce the same log).
>
> Stefano
>
This is probably a good idea and something I have been looking at doing
but I would like to continue studying the code base at present while I
get a clear idea of the way forward. The SMTPServer package looks a good
target, it has separate classes for each command and is the kind of
thing I am looking for. Would it be a good idea to have a wiki page with
some clear terms and definitions like what is a container, what is a
framework, what is a component, etc? I think it would be good at least
summarise their responsibilities and relate them to James concepts. I
think it mentions something along those lines on the wiki somewhere and
I don't mind starting it off. You may already have definitions for these
terms and if so please point me in their direction.
Regards,
Simon
P.S. I am using logging as an example of cross cutting concerns, which
is a much more general problem.
>
>> Regards,
>>
>> Simon
>>
>>
>>
>>
>> Stefano Bagnara wrote:
>>
>>> Simon,
>>>
>>> Sorry for being pragmatic, but your framework will have to deal with
>>> this comments if you want to start telling "our framework" instead of
>>> "my framework".
>>>
>>> If the framework needs so much text to be explained then it will
>>> probably be not good for James. We need something that people already
>>> know, or alternatively something that people is able to grasp without
>>> reading pages of docs. Maybe you want to try with concrete examples,
>>> diagrams, but not so much text. I admin I read all you wrote and I
>>> still don't understand how your framework works. Bad thing.
>>>
>>> You propose a new container framework using interfaces to be
>>> implemented. in 2009 this is a bad practice, currently frameworks use
>>> @annotations, AOP, agnostic (pojo) dependency injection. If we want an
>>> interface based framework then Avalon does a damn good job here,
>>> already.
>>>
>>> You also will need a good understanding of other frameworks so to
>>> publish a comparison and use common terms defining what makes your
>>> framework special. What is the most similar framework around, what
>>> does your framework do better? Does your framework try to solve
>>> container issues (class loading, component isolation,
>>> componentreloading, deployment) or application assembly (dependency
>>> injection, component configuration, service discovery/linking,
>>> configuration)?
>>>
>>> Stefano
>>>
>>> 2009/11/18 Simon Funnell <si...@googlemail.com>:
>>>
>>>
>>>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: Not Mine
Posted by Stefano Bagnara <ap...@bago.org>.
2009/11/19 Simon Funnell <si...@googlemail.com>:
> Hi,
>
> I will pose it as a 'user' request, this should clarify things:
>
> Can James be designed in a way that allows it to be deployed in both legacy
> and next generation frameworks?
This is already happening in trunk.
> Next generation frameworks attempt to address issues such as declarative
> logging and the like ;)
I'm not sure that "next generation frameworks" means "declarative logging.
IMHO declarative logging (the way you described it) cannot and will
never replace standard logging. It could be used together, but not
replace all of logging.
It would be a PITA to mantain that style of declarative logging. BTW
if you have more documentation, examples, code, evangelization
articles, to help me why declarative logging will be used in the next
generation framework I'd be very happy to read it. I'm very interested
in improving the logging aspect of libraries/application as I feel the
logging one of the most problematic issues in current design. I don't
like per class logging (Log.getLogger field), either static or per
instance and I prefer injecting logging services, but I still don't
see how to completely remove logging in favor of a declarative
approach. Can you take a class from our repository and show how to
refactor it to use declarative logging (also including the declarative
logging part needed to produce the same log).
Stefano
> Regards,
>
> Simon
>
>
>
>
> Stefano Bagnara wrote:
>>
>> Simon,
>>
>> Sorry for being pragmatic, but your framework will have to deal with
>> this comments if you want to start telling "our framework" instead of
>> "my framework".
>>
>> If the framework needs so much text to be explained then it will
>> probably be not good for James. We need something that people already
>> know, or alternatively something that people is able to grasp without
>> reading pages of docs. Maybe you want to try with concrete examples,
>> diagrams, but not so much text. I admin I read all you wrote and I
>> still don't understand how your framework works. Bad thing.
>>
>> You propose a new container framework using interfaces to be
>> implemented. in 2009 this is a bad practice, currently frameworks use
>> @annotations, AOP, agnostic (pojo) dependency injection. If we want an
>> interface based framework then Avalon does a damn good job here,
>> already.
>>
>> You also will need a good understanding of other frameworks so to
>> publish a comparison and use common terms defining what makes your
>> framework special. What is the most similar framework around, what
>> does your framework do better? Does your framework try to solve
>> container issues (class loading, component isolation,
>> componentreloading, deployment) or application assembly (dependency
>> injection, component configuration, service discovery/linking,
>> configuration)?
>>
>> Stefano
>>
>> 2009/11/18 Simon Funnell <si...@googlemail.com>:
>>
>>>
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Not Mine
Posted by Simon Funnell <si...@googlemail.com>.
Hi,
I will pose it as a 'user' request, this should clarify things:
Can James be designed in a way that allows it to be deployed in both
legacy and next generation frameworks?
Next generation frameworks attempt to address issues such as declarative
logging and the like ;)
Regards,
Simon
Stefano Bagnara wrote:
> Simon,
>
> Sorry for being pragmatic, but your framework will have to deal with
> this comments if you want to start telling "our framework" instead of
> "my framework".
>
> If the framework needs so much text to be explained then it will
> probably be not good for James. We need something that people already
> know, or alternatively something that people is able to grasp without
> reading pages of docs. Maybe you want to try with concrete examples,
> diagrams, but not so much text. I admin I read all you wrote and I
> still don't understand how your framework works. Bad thing.
>
> You propose a new container framework using interfaces to be
> implemented. in 2009 this is a bad practice, currently frameworks use
> @annotations, AOP, agnostic (pojo) dependency injection. If we want an
> interface based framework then Avalon does a damn good job here,
> already.
>
> You also will need a good understanding of other frameworks so to
> publish a comparison and use common terms defining what makes your
> framework special. What is the most similar framework around, what
> does your framework do better? Does your framework try to solve
> container issues (class loading, component isolation,
> componentreloading, deployment) or application assembly (dependency
> injection, component configuration, service discovery/linking,
> configuration)?
>
> Stefano
>
> 2009/11/18 Simon Funnell <si...@googlemail.com>:
>
>> 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
Re: Not Mine
Posted by Stefano Bagnara <ap...@bago.org>.
Simon,
Sorry for being pragmatic, but your framework will have to deal with
this comments if you want to start telling "our framework" instead of
"my framework".
If the framework needs so much text to be explained then it will
probably be not good for James. We need something that people already
know, or alternatively something that people is able to grasp without
reading pages of docs. Maybe you want to try with concrete examples,
diagrams, but not so much text. I admin I read all you wrote and I
still don't understand how your framework works. Bad thing.
You propose a new container framework using interfaces to be
implemented. in 2009 this is a bad practice, currently frameworks use
@annotations, AOP, agnostic (pojo) dependency injection. If we want an
interface based framework then Avalon does a damn good job here,
already.
You also will need a good understanding of other frameworks so to
publish a comparison and use common terms defining what makes your
framework special. What is the most similar framework around, what
does your framework do better? Does your framework try to solve
container issues (class loading, component isolation,
componentreloading, deployment) or application assembly (dependency
injection, component configuration, service discovery/linking,
configuration)?
Stefano
2009/11/18 Simon Funnell <si...@googlemail.com>:
> 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
Re: Not Mine
Posted by Simon Funnell <si...@googlemail.com>.
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
Re: Not Mine
Posted by Eric MacAdie <er...@MacAdie.net>.
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