On Dec 9, 2009, at 10:19 PM, David Jencks wrote:
See also https://issues.apache.org/jira/browse/PLUTO-585
I've been working on getting pluto to run under osgi in geronimo 3,
wiring the pluto components with the osgi blueprint service. I now
have the basic geronimo admin console working this way. (there are
a few exceptions but they aren't related to pluto).
I'm wondering how much of this to push back into pluto, and when.
Geronimo is not yet acting as a osgi rfc 66 web container, so the
web app bits of pluto are currently deployed in geronimo as regular
web apps (which means geronimo processes them into osgi bundles in
its own non-rfc-66 way). I have the blueprint wired bits in a
separate bundle from the web app bits. So, at the moment it seems
to me that the blueprint plan might be interesting but the whole
thing is somewhat geronimo specific at the moment.
As long as we can still build against the trunk, or we are notified
about any changes we need to make to our code, I 'd be interested in
seeing it pushed back to Pluto
I'm also wondering just how well thought out the current assembly/
wiring system is. I saw some evidence of some wiring being done
through the pluto-1-like fishing for components in a registry method
rather than DI. I changed SupportedModesServiceImpl towards a more
DI approach. Is this kind of change OK? Am I missing some
distinction about when DI is appropriate and when it is not so
appropriate? If the answer is that no one has really looked very
hard I may work a bit more on making the wiring more DI and more
consistent.
Any thought on this?
Im not a big fan of the assemblies, nor am I very knowledgeable about
them, but I would like to see a more conventional approach. +1 on
using a DI injection approach. I tried to introduce some of that last
year with the Portlet 2.0 support
