On Dec 10, 2009, at 3:41 PM, David Sean Taylor wrote:
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
Does "we" == jetspeed2? What do I need to do to check compatibility?
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
I've been looking into this a bit more, it looks like quite a bit more
wiring can be done through DI, either spring or blueprint. Haven't
quite figured out how to hook the ee components up to the DI
components yet... not hard in osgi, but less clear to me in non-osgi
spring.
thanks!
david jencks
