Re: Contribute to SCA-OSGi integration
Bill, We are prototyping some code which require SCA modules running in an OSGi container, and would be very keen on using your implementation (SCA container built using OSGi). If you have prototype code which already runs with Felix, would it be possible for you to submit the code? At the moment, it would be sufficient for us to have SCA modules running in OSGi with dependency resolution handled by OSGi, and it doesn't matter if the OSGi service registry is not used for service lookup. Thank you... Regards, Rajini On 6/23/07, Bill Barnhill [EMAIL PROTECTED] wrote: Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
Re: Contribute to SCA-OSGi integration
This itest has been fixed now with TUSCANY-1569 so how about including implementation-osgi in the 0.99 release? It would add about 500K of Felix dependencies which doesn't seem a big deal, so i think we should include it. ...ant On 8/20/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I will take a look at the intermittent test failure in itest/osgi -implementation. Thank you... Regards, Rajini On 8/16/07, ant elder [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0 release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgi code has been moved off SNAPSHOTs to use Felix 1.0 so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Ant, Thank you for applying the patch. I will be happy to see implementation-osgi in the release. Thank you... Regards, Rajini On 8/23/07, ant elder [EMAIL PROTECTED] wrote: This itest has been fixed now with TUSCANY-1569 so how about including implementation-osgi in the 0.99 release? It would add about 500K of Felix dependencies which doesn't seem a big deal, so i think we should include it. ...ant On 8/20/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I will take a look at the intermittent test failure in itest/osgi -implementation. Thank you... Regards, Rajini On 8/16/07, ant elder [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgi code has been moved off SNAPSHOTs to use Felix 1.0so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgiis complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
ant elder wrote: This itest has been fixed now with TUSCANY-1569 so how about including implementation-osgi in the 0.99 release? It would add about 500K of Felix dependencies which doesn't seem a big deal, so i think we should include it. ...ant +1 to include it. Yesterday there was a test failing in osgi-implementation, but it just seemed like a small glitch that can probably be fixed today. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
+1 for including it in the release. Simon ant elder wrote: This itest has been fixed now with TUSCANY-1569 so how about including implementation-osgi in the 0.99 release? It would add about 500K of Felix dependencies which doesn't seem a big deal, so i think we should include it. ...ant On 8/20/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I will take a look at the intermittent test failure in itest/osgi -implementation. Thank you... Regards, Rajini On 8/16/07, ant elder [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0 release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgi code has been moved off SNAPSHOTs to use Felix 1.0 so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
On 8/23/07, Simon Nash [EMAIL PROTECTED] wrote: +1 for including it in the release. Simon ant elder wrote: This itest has been fixed now with TUSCANY-1569 so how about including implementation-osgi in the 0.99 release? It would add about 500K of Felix dependencies which doesn't seem a big deal, so i think we should include it. ...ant On 8/20/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Ant, I will take a look at the intermittent test failure in itest/osgi -implementation. Thank you... Regards, Rajini On 8/16/07, ant elder [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0 release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgi code has been moved off SNAPSHOTs to use Felix 1.0so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 to including it from me. Sample looks pretty good. Can we get some suitable words for the CHANGES file from someone about it. Simon
Re: Contribute to SCA-OSGi integration
Hi SCA/OSGi-ers, Just bringing this up again to see if there is any interesting in moving this along still. We've been talking about having a Tuscany 1.0 release in a couple of months, be great if we could have a good OSGi story for that. Also the Apache Felix 1.0 release is out now and the existing implemention.osgicode has been moved off SNAPSHOTs to use Felix 1.0 so we can now include that in releases (though i think one of the itests still has an intermittent failure so would be good to fix that as well). ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contribute to SCA-OSGi integration
Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
That sounds wonderful! I tried out the sample you did on M2, if we could get a similar type of thing going with the current runtime it would be great. Sounds like Bills first patches in this area should be coming any time now. ...ant On 6/29/07, Hawkins, Joel [EMAIL PROTECTED] wrote: Hi SCA/OSGi-ers. I did some initial work back during the M2 days (working with Nicole) to host Tuscany in an Equinox runtime. It looks like I may have some time to re-engage during the next few months, so is there anything in particular that I could be looking at to help move the OSGi efforts ahead? Like Bill and Raymond below, my primary interest is in seeing OSGi used as a container for hosting SCA. Cheers, Joel -Original Message- From: Rajini Sivaram [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Contribute to SCA-OSGi integration Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Sebastien, Graham and I will be looking at the support for packaging of SCA contributions as OSGi bundles, once the work on implementation.osgi is complete. Thank you... Regards, Rajini On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Thanks! Its great to hear you're doing this. A src zip attached to a jira is fine if that's easiest for you, a diff patch is better for updating existing code but as this is mostly new code/modules a zip is likely easiest. It doesn't have to be perfect to submit the patch, its always tempting to polish things first but in some respects its better to start submitting rough code early before its perfected and incrementally improve it within the Tuscany SVN. Worst case is if it turns into a really significant contribution we might need a formal software grant to accept it, unlikely in this case so just post it when ever you're comfortable. ...ant On 6/23/07, Bill Barnhill [EMAIL PROTECTED] wrote: Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
Re: Contribute to SCA-OSGi integration
Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
Re: Contribute to SCA-OSGi integration
On 6/21/07, Graham Charters [EMAIL PROTECTED] wrote: snip I still think that explicit bindings are better. I still think both approaches are valid and it depends on what you're trying to achieve :-) . If you're trying to include OSGi bundles in your SCA domain, the only way to do this is with implementation.osgi. If you're trying to create a peer environment where you interoperate with OSGi bundles but they are not managed by SCA, then binding.osgi makes sense. What do the others on the list think? I'd like to see both approaches implemented in Tuscany :) At least then we have the opportunity to experiment with trying both out which may help highlight the various advantages and disadvantages of each in different scenarios. Now that we have working code from implementation.osgi that can be borrowed from it should not be so difficult to get a binding going. OSGi support has missed the 0.91 release but it would be good to get this in the next release (0.92 in August?) with support for both implementation and binding and some good doc and samples. Would any of you be interested in helping with that? ...ant
Re: Contribute to SCA-OSGi integration
Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi Nicole, I've inlined some comments below. On 20/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Graham, I'm still not sure if the proposal is consistent. Let my explain my concerns: Every OSGi container provides an OSGi registry. In the OSGi enterprise expert group we are currently discussing that proxies for other services (e.g. EJB stateless Bean which is accessible via IIOP) will be created and registered in the OSGi registry. From this point of view, your proposal for the implementation.osgi is consistent. I think it would be nice if OSGi didn't have to care how the service was implemented, and this is what can be achieved with SCA. But do we want to have different behaviour for different SCA implementations types? This is exactly what we don't want. The implementation.osgi approach registers in the OSGi registry whatever proxies SCA gives it. These proxies can be for other implementation types or remote bindings. Their behaviour is consistent. Do you expect for example that an implementation.ejb adds remote proxies to the JNDI service? Or what about implementation.net or implementation.c, do we need now a registry for all implementation types? We shouldn't have to care. If implementation.ejb/c/.net are supported in the SCA runtime, then we will get these for free. It's up to SCA to give us the right proxy which we then make available in the OSGi registry. I still think that explicit bindings are better. I still think both approaches are valid and it depends on what you're trying to achieve :-) . If you're trying to include OSGi bundles in your SCA domain, the only way to do this is with implementation.osgi. If you're trying to create a peer environment where you interoperate with OSGi bundles but they are not managed by SCA, then binding.osgi makes sense. What do the others on the list think? Thanks Nicole P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich next week. Looking forward to meeting you there :-) Yes, I am. I look forward to meeting you there too :-) . -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 17:10 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole, My turn to chip in :-) I think both approaches are valid and tackle two different goals. If I understand correctly, then the binding approach does not hand the responsibility for the OSGi bundles and services to SCA. So this is more of a peer-to-peer runtime view. I think this approach is appealing if you want to keep OSGi outside the SCA domain for either organizational reasons, or because you don't want to model some existing OSGi application in SCA. The implementation.osgi approach is trying to take an SCA assembly view of the problem where you want to describe and manage the assembly of the OSGi assets with other implementation technologies. Here SCA is responsible for managing the OSGi bundles (installation, activation), and ensuring their external dependencies are resolved. I've inlined some additional comments below. On 19/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, I would prefer a solution where you declare explicitly the bindings, not an implicit registration of services. Please find below a snippet of the OSGi prototype provided by Joel some time ago: service name=RetailerService target=RetailerComponent interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer/ referenceRetailerComponent/reference /service component name=RetailerComponent implementation.java class=test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl/ reference name=warehouse target=WarehouseComponentWarehouseComponent/reference /component RetailerComponent will not be registered automatically (without a service). The Service tag provides the information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the OSGi registry. The Client uses a reference with OSGi binding to access the RetailerService: component name=CustomerComponent implementation.java class=test.sca.osgi.binding.client.impl.CustomerComponentImpl/ reference name=retailer target=RetailerServiceRetailerService/reference /component reference name=RetailerService override=may multiplicity=0..n target=Nothing interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer filter=(objectclass=test.sca.osgi.binding.supplychain.Retailer) immediate=false/ /reference In this case the SCA runtime looks up the Retailer OSGi service in the registry
AW: Contribute to SCA-OSGi integration
Hi Graham, I'm still not sure if the proposal is consistent. Let my explain my concerns: Every OSGi container provides an OSGi registry. In the OSGi enterprise expert group we are currently discussing that proxies for other services (e.g. EJB stateless Bean which is accessible via IIOP) will be created and registered in the OSGi registry. From this point of view, your proposal for the implementation.osgi is consistent. But do we want to have different behaviour for different SCA implementations types? Do you expect for example that an implementation.ejb adds remote proxies to the JNDI service? Or what about implementation.net or implementation.c, do we need now a registry for all implementation types? I still think that explicit bindings are better. What do the others on the list think? Thanks Nicole P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich next week. Looking forward to meeting you there :-) -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 17:10 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole, My turn to chip in :-) I think both approaches are valid and tackle two different goals. If I understand correctly, then the binding approach does not hand the responsibility for the OSGi bundles and services to SCA. So this is more of a peer-to-peer runtime view. I think this approach is appealing if you want to keep OSGi outside the SCA domain for either organizational reasons, or because you don't want to model some existing OSGi application in SCA. The implementation.osgi approach is trying to take an SCA assembly view of the problem where you want to describe and manage the assembly of the OSGi assets with other implementation technologies. Here SCA is responsible for managing the OSGi bundles (installation, activation), and ensuring their external dependencies are resolved. I've inlined some additional comments below. On 19/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, I would prefer a solution where you declare explicitly the bindings, not an implicit registration of services. Please find below a snippet of the OSGi prototype provided by Joel some time ago: service name=RetailerService target=RetailerComponent interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer/ referenceRetailerComponent/reference /service component name=RetailerComponent implementation.java class=test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl/ reference name=warehouse target=WarehouseComponentWarehouseComponent/reference /component RetailerComponent will not be registered automatically (without a service). The Service tag provides the information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the OSGi registry. The Client uses a reference with OSGi binding to access the RetailerService: component name=CustomerComponent implementation.java class=test.sca.osgi.binding.client.impl.CustomerComponentImpl/ reference name=retailer target=RetailerServiceRetailerService/reference /component reference name=RetailerService override=may multiplicity=0..n target=Nothing interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer filter=(objectclass=test.sca.osgi.binding.supplychain.Retailer) immediate=false/ /reference In this case the SCA runtime looks up the Retailer OSGi service in the registry and injects it into the CustomerComponent which is the client. From my point of view we need such an OSGi Binding for the communication of SCA components running in different implementation types. If we have only an OSGi implementation type I would use instead of an OSGi binding the OSGI R4 DS (Declarative Services) or Spring OSGi. Both approaches allow OSGi bundles to talk to SCA components built using different implementation types. For the binding approach it's whatever the service with the OSGi binding is wired to in SCA. For the implementation.osgi approach, it's whatever the component reference is wired to. The runtime needs to make good on this relationship. So, an SCA component with an implementation type of OSGi can be directly wired to an SCA component with an implementation of Java, or BPEL, etc... Questions/Remarks to you proposal: A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. From my point of view the provider (in this case Retailer) should decide how
AW: Contribute to SCA-OSGi integration
Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which will be injected via Dependency Injection, e.g. in the Spring implementation type or in the OSGi implementation type with Spring-OSGi support. Could you please describe what you have in mind, e.g. where you are planning to declare the non-OSGi SCA Component? Thanks Nicole -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juni 2007 10:07 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an implementation.osgi /. So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire -- OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service
Re: Contribute to SCA-OSGi integration
Nicole, Here is an example scenario, taken from the supplychain sample in Tuscany. Customer and Warehouse are OSGi bundles, Retailer has a Java implementation. A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. The Retailer Java component has its warehouse reference injected by Tuscany with an instance of the Warehouse, which is registered by the Warehouse bundle and looked up by the Tuscany OSGi implementation provider in the OSGi registry. component name=CustomerComponent implementation.osgi bundle=Customer bundleLocation=file:target/Customer.jar / reference name=retailer target=RetailerComponent/ /component component name=RetailerComponent implementation.java class= supplychain.retailer.JavaRetailerComponentImpl / reference name=warehouse target=WarehouseComponent/ /component component name=WarehouseComponent implementation.osgi bundle=Warehouse bundleLocation=file:target/Warehouse.jar / reference name=shipper target=ShipperComponent / /component Thank you... Regards, Rajini On 6/19/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which will be injected via Dependency Injection, e.g. in the Spring implementation type or in the OSGi implementation type with Spring-OSGi support. Could you please describe what you have in mind, e.g. where you are planning to declare the non-OSGi SCA Component? Thanks Nicole -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juni 2007 10:07 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an implementation.osgi /. So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire -- OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes
AW: Contribute to SCA-OSGi integration
Hi Rajini, I would prefer a solution where you declare explicitly the bindings, not an implicit registration of services. Please find below a snippet of the OSGi prototype provided by Joel some time ago: service name=RetailerService target=RetailerComponent interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer/ referenceRetailerComponent/reference /service component name=RetailerComponent implementation.java class=test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl/ reference name=warehouse target=WarehouseComponentWarehouseComponent/reference /component RetailerComponent will not be registered automatically (without a service). The Service tag provides the information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the OSGi registry. The Client uses a reference with OSGi binding to access the RetailerService: component name=CustomerComponent implementation.java class=test.sca.osgi.binding.client.impl.CustomerComponentImpl/ reference name=retailer target=RetailerServiceRetailerService/reference /component reference name=RetailerService override=may multiplicity=0..n target=Nothing interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer filter=(objectclass=test.sca.osgi.binding.supplychain.Retailer) immediate=false/ /reference In this case the SCA runtime looks up the Retailer OSGi service in the registry and injects it into the CustomerComponent which is the client. From my point of view we need such an OSGi Binding for the communication of SCA components running in different implementation types. If we have only an OSGi implementation type I would use instead of an OSGi binding the OSGI R4 DS (Declarative Services) or Spring OSGi. Questions/Remarks to you proposal: A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. From my point of view the provider (in this case Retailer) should decide how it is accessible, not the client. What happens if Retailer is not declared in the same composite? Are you going to search for matching components in the complete SCA domain? The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. What about dependency injection? Will it also be supported? Looking forward to discussing these topics further with you :-) Best regards Nicole -Ursprüngliche Nachricht- Von: Rajini Sivaram [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 10:04 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Nicole, Here is an example scenario, taken from the supplychain sample in Tuscany. Customer and Warehouse are OSGi bundles, Retailer has a Java implementation. A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. The Retailer Java component has its warehouse reference injected by Tuscany with an instance of the Warehouse, which is registered by the Warehouse bundle and looked up by the Tuscany OSGi implementation provider in the OSGi registry. component name=CustomerComponent implementation.osgi bundle=Customer bundleLocation=file:target/Customer.jar / reference name=retailer target=RetailerComponent/ /component component name=RetailerComponent implementation.java class= supplychain.retailer.JavaRetailerComponentImpl / reference name=warehouse target=WarehouseComponent/ /component component name=WarehouseComponent implementation.osgi bundle=Warehouse bundleLocation=file:target/Warehouse.jar / reference name=shipper target=ShipperComponent / /component Thank you... Regards, Rajini On 6/19/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which
Re: Contribute to SCA-OSGi integration
PROTECTED] Gesendet: Dienstag, 19. Juni 2007 10:04 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Nicole, Here is an example scenario, taken from the supplychain sample in Tuscany. Customer and Warehouse are OSGi bundles, Retailer has a Java implementation. A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. The Retailer Java component has its warehouse reference injected by Tuscany with an instance of the Warehouse, which is registered by the Warehouse bundle and looked up by the Tuscany OSGi implementation provider in the OSGi registry. component name=CustomerComponent implementation.osgi bundle=Customer bundleLocation=file:target/Customer.jar / reference name=retailer target=RetailerComponent/ /component component name=RetailerComponent implementation.java class= supplychain.retailer.JavaRetailerComponentImpl / reference name=warehouse target=WarehouseComponent/ /component component name=WarehouseComponent implementation.osgi bundle=Warehouse bundleLocation=file:target/Warehouse.jar / reference name=shipper target=ShipperComponent / /component Thank you... Regards, Rajini On 6/19/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which will be injected via Dependency Injection, e.g. in the Spring implementation type or in the OSGi implementation type with Spring-OSGi support. Could you please describe what you have in mind, e.g. where you are planning to declare the non-OSGi SCA Component? Thanks Nicole -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juni 2007 10:07 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an implementation.osgi /. So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire -- OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one
Re: Contribute to SCA-OSGi integration
Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an implementation.osgi /. So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire -- OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini
Re: Contribute to SCA-OSGi integration
I will submit the code through JIRA once it is ready. If there is already documentation about the Tuscany SPIs, I would like to use it, otherwise, the samples and the Java implementation seem to be quite useful to get started. OSGi doesn't provide a standard mechanism to start a new runtime, and different implementations use different classes and methods to start up the console. It would have been nice if the FrameworkAdmin service could be used to start up an OSGi runtime within the current VM, but since that doesn't seem possible, we have to rely on dynamically loading up the runtime that is available on the classpath. Equinox has a static method EclipseStarter.startup() which can be used to start a single OSGi runtime in a VM. Apache Felix can be started using new Felix.start(properties, activatorList) which is neater. Knoplerfish runtime can be started using new Framework().launch(). So I think we can get around the fact that there is no standard way to embed a OSGi runtime. We haven't addressed the third aspect that Raymond mentioned (using OSGi as the underlying technology for SCA containers), so it is very useful to know that Bill is already working on it. Since this is orthogonal to the work we are doing, the two can go on in parallel, and yes, it will be good to have subdirectories under contrib for the three so that the code can be shared. Thank you Regards, Rajini
Re: Contribute to SCA-OSGi integration
On 6/5/07, Rajini Sivaram [EMAIL PROTECTED] wrote: I will submit the code through JIRA once it is ready. If there is already documentation about the Tuscany SPIs, I would like to use it, otherwise, the samples and the Java implementation seem to be quite useful to get started. OSGi doesn't provide a standard mechanism to start a new runtime, and different implementations use different classes and methods to start up the console. It would have been nice if the FrameworkAdmin service could be used to start up an OSGi runtime within the current VM, but since that doesn't seem possible, we have to rely on dynamically loading up the runtime that is available on the classpath. Equinox has a static method EclipseStarter.startup() which can be used to start a single OSGi runtime in a VM. Apache Felix can be started using new Felix.start(properties, activatorList) which is neater. Knoplerfish runtime can be started using new Framework().launch(). So I think we can get around the fact that there is no standard way to embed a OSGi runtime. We haven't addressed the third aspect that Raymond mentioned (using OSGi as the underlying technology for SCA containers), so it is very useful to know that Bill is already working on it. Since this is orthogonal to the work we are doing, the two can go on in parallel, and yes, it will be good to have subdirectories under contrib for the three so that the code can be shared. Thank you Regards, Rajini I've created empty modules for these, in trunk for now as we've been using contrib more as dumping ground for old stuff, so feel free to go ahead and start adding code: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-osgi/ https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-osgi/ https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-osgi/ ...ant
Contribute to SCA-OSGi integration
Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini
Re: Contribute to SCA-OSGi integration
On 6/4/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini Sounds really good to me, though I'm no OSGi expert so I've also CC'd a couple of others who've sounded interested in Tuscany's OSGi support in the past in case they're don't see this on the Tuscany mailing list. One approach would be to just start submitting code as that may prompt further discussion. We can get that added to SVN which makes it easier for you and everyone else, and it doesn't have to be beautiful finished code as we don't need to add it to the main build till you're ready. If you're not so familiar with the Tuscany SPIs yet we could set up a module for you with the standard Tuscany boiler plate stuff already done to help you get started. ...ant
Re: Contribute to SCA-OSGi integration
This sounds like a good approach and I would be interested to see an implementation of this in Tuscany. I have a question on having Tuscany in control and starting up the OSGi runtime. I'm no OSGi expert either, but someone once told me that it's hard for OSGi to run inside another runtime that isn't OSGi-aware. Are there any issues here for allowing Tuscany to be embeddable in many environments, not all of which will be OSGi-aware? Simon ant elder wrote: On 6/4/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini Sounds really good to me, though I'm no OSGi expert so I've also CC'd a couple of others who've sounded interested in Tuscany's OSGi support in the past in case they're don't see this on the Tuscany mailing list. One approach would be to just start submitting code as that may prompt further discussion. We can get that added to SVN which makes it easier for you and everyone else, and it doesn't have to be beautiful finished code as we don't need to add it to the main build till you're ready. If you're not so familiar with the Tuscany SPIs yet we could set up a module for you with the standard Tuscany boiler plate stuff already done to help you get started. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi, Please see my comments inline below. Thanks, Raymond - Original Message - From: Rajini Sivaram [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, June 04, 2007 7:22 AM Subject: Contribute to SCA-OSGi integration Hello, I would like to contribute to the SCA-OSGi integration activities. That would be great! I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. I think you covered two aproaches here: 1) An SCA OSGi Binding can enable interworking between SCA components and OSGi services 2) An SCA OSGi implementation type allows deploying existing OSGi applications/bundles in an SCA domain and using them as SCA components The third aspect would be: OSGi can be used as underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. Which OSGi implementation are you considering? Eclipse Equinox, Apache Felix, or? I did a bit invesigation and it seems that Felix provides a way to be embedded. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? On 6/4/07, Raymond Feng [EMAIL PROTECTED] wrote: ... The third aspect would be: OSGi can be used as underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. Which OSGi implementation are you considering? Eclipse Equinox, Apache Felix, or? I did a bit invesigation and it seems that Felix provides a way to be embedded. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
