You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by David Jencks <da...@yahoo.com> on 2009/12/10 07:19:21 UTC
Pluto under osgi
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.
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?
many thanks
david jencks
Re: Pluto under osgi
Posted by Gonzalo Aguilar Delgado <ga...@aguilardelgado.com>.
I personally would love to have this developed.
Un unfortunately cannot help much here. But will be great have news of
the
progress.
Great work David!
El mié, 09-12-2009 a las 22:19 -0800, David Jencks escribió:
> 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.
>
> 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?
>
> many thanks
> david jencks
>
>
>
Re: Pluto under osgi
Posted by David Jencks <da...@yahoo.com>.
I committed a fairly substantial DI refactoring in rev 89368. It
works in geronimo under osgi assembled with blueprint, but I haven't
figured out how to test the spring assembly. This should not affect
jetspeed since the only changes in the portlet container are a javadoc
typo fix and a suggestion not to use the PortletContainerFactory.
I'd really appreciate some help figuring out how to test the spring
assembly since there is a very good chance I didn't port all the xml
changes correctly back from the blueprint version. I'd also like to
find out how to run the tck :-)
many thanks
david jencks
On Dec 11, 2009, at 12:00 PM, David Sean Taylor wrote:
>
> On Dec 11, 2009, at 11:01 AM, David Jencks wrote:
>
>>
>> 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?
>
>
> Yes, we as in Jetspeed and any other projects using Pluto.
>
>
>> What do I need to do to check compatibility?
>
> Either check out the project and build it, or work with me, I can
> also check the compatibility as you go, with your help of course
>
Re: Pluto under osgi
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Dec 11, 2009, at 11:01 AM, David Jencks wrote:
>
> 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?
Yes, we as in Jetspeed and any other projects using Pluto.
> What do I need to do to check compatibility?
Either check out the project and build it, or work with me, I can also
check the compatibility as you go, with your help of course
Re: Pluto under osgi
Posted by David Jencks <da...@yahoo.com>.
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
Re: Pluto under osgi
Posted by David Sean Taylor <da...@bluesunrise.com>.
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