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: [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]
