Danny Angus wrote:
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> wrote:
I think your "James is a POJO chameleon" idea makes a lot of sense. If
we make it easy for 3rd parties to wrap James up, they'd do the heavy
lifting of packaging the code up for you and making it deployable to
their systems. Is there anything screwy about picking the Spring
framework as the official container into which James is poured?
Couldn't that just be how James is shipped from the core team?
IMO Yes... but ... we first need to be sure that we haven't missed any
subtle but fatal gotcha's
I really suggest reading this old threads:
SpringJames vs. JamesNG
http://www.mail-archive.com/server-dev@james.apache.org/msg03576.html
Maven 2 and XBean
http://www.mail-archive.com/server-dev@james.apache.org/msg06246.html
Central class for service injection
http://www.mail-archive.com/server-dev@james.apache.org/msg08541.html
And expecially this one:
Re: [jira] Commented: (JAMES-495) Decide how to replace Avalon
Configuration (28/05/2006 16.09)
http://www.mail-archive.com/server-dev@james.apache.org/msg07490.html
I think that finding an answer to the last question will make anyone
more aware of what it means pojoification for James.
IMHO the key is make every component a container managed component, so
embracing avalon much more by creating avalon managed factories wheneven
you need to create components that need lifecycle. Once every component
will be top level (declare in the assembly) and
generated/fine-grained-componetns will be created by top-level factories
then a move to another container and a removal of avalon specific stuff
will be possible.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
