Noel,
By mentioning JNDI I guess you are talking about ServiceLocator
pattern, right? It is considered as anti-pattern.
Not here:
snip /
What is your point Noel?
That there is a usefulness, and that the supposed positioning of the pattern as an anti-pattern isn't even agreed
Steve Brewin wrote:
I think James would secure itself most against the future by
developing a set of functional POJO's independent of any container.
+1
It would then be the responsibility of those who care to assemble them
into a deployable entity for the container of their choice.
+1
Steve,
I am slowly working on changes to Cornerstone. These changes
may allow
JAMES components to be independent of IoC container. Or more
accurately
will grant Contextualized Lookup (Avalon) components an alternate
capability in a Constructor Dependency Injection world. In
no part of
the
Folks,
Ah, but what is a well-established Java API for containers?
Without a shadow of a doubt JSR 77 and 88, and the Geronimo team's
understanding of containers and components are the most relevent
direction for JAMES. They have a GBean architecture and go to some
effort to generate MBean
Issac,
Yup yup, I am still on it :-)
I have reworked many of the comps in Cornerstone.
I plan to roll them into FtpServer ahead of James (easy to iron out bugs
there)
- Paul
Hello all,
Could you please provide a quick brief on the status of the CDI transition?
Are there any deadlines or
Folks,
Today I have been changing Cornerstone to have CDI capability. At least
I've completed two of three - ConnectionManager and Store
(ObjectRespository). SocketManager is yet to do. See
https://svn.apache.org/repos/asf/avalon/trunk/planet/cornerstone
This will allow us to begin work on
Steve
No disagreement in principle. Refactoring the bulk of James into POJOs would
be a good thing.
Refactoring the bulk of James to also have POJO capability ... (we'd not
be taking avalon capability).
Just not good enough on technical merit alone. I don't see
a 'killer' reason. Without one I
Noel,
Huh? No they aren't. Quite the opposite. You had advocated that years
ago, and there was resistence to doing so. There are a few mailets with
Avalon ties, but those are being removed. Mailets will depend upon standard
services, such as JNDI, not Avalon.
I think that I suggested that
Folks,
OK, so perhaps this idea is not as controversial as the subj line would
indicate. Is there any interest (beyond me) for refactoring the James
server implementation to allow non-Merlin/Avalon use ?
We're finding that Constructor Dependency Injection (CDI) is pretty
popular now. There is a
Steve,
Yup I forgot the the internals of Mailet are entangled with Avalon. I
was on this list a couple of years ago advocating separations, and don't
really want to go back into those discussions. When 3.0 is mooted, and
backward compatability for mailets is not required, someone ping me :-)
10 matches
Mail list logo
