Re: OSGi
Locked
 
|
Adrian,
Did This go anywhere? > Adrian Crum wrote: > > That looks great! Thanks for sharing! > > BJ and I had discussed developing something like this a while back. > It would be > great if we could find a way to integrate OSGi instead of re- > inventing the wheel. > > > Porter Woodward wrote: > > > Hey all - > > > > out of curiousity, has anyone here looked at OSGi? In a lot of > ways it > > seems like there would be an interesting fit / refactoring of > OFBiz that > > could be done using OSGi as a basis. An implementation of OSGi > > (Equinox) is used as the foundation for Eclipse. I've also > noticed that > > Felix (originally known as Oscar) - another open source OSGi > > implementation - is now an Apache Incubator project. And another > OSGi > > implementation can be had via Knopflerfish. And, the upcoming > Spring > > release is adding support for OSGi. > > The basic distributable chunk of code in OSGi is referred to as a > > Bundle. All in all it looks like an excellent way to bundle and > deploy > > components (service bundles), manage their life-cycle, and resolve > > dependencies. It would almost seem possible to re-bundle most OFBiz > > component jars as OSGi bundles (not necessarily an optimal > approach) - > > which would allow for the dynamic loading/unloading of components > with > > relative ease. > > > > More information is available at: > > > > http://www.osgi.org/ > > > > - Porter Woodward > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
|
No. Some time ago (before Porter's email) there was considerable discussion
about exploring the possibility of loading/unloading individual components, automatic component updates, etc. We fleshed out a few ideas on how to set up component version numbers and check component dependencies, etc, then the wind got knocked out of our sails when someone pointed out that the class loader doesn't support those kinds of operations. All of that is beyond my expertise, so I just dropped it. I don't know if BJ went any further with it on his own. OSGi looked like something that would make the task easier, possibly even solving the class loader problem. I can't be sure though, because - like I said - that kind of development is beyond my abilities. I revisited the idea at the developers conference, and a few of the developers felt it would be a great capability to have, but the discussion didn't go any further than that. Christopher Snow wrote: > Adrian, > > Did This go anywhere? > > >> Adrian Crum wrote: >> >> That looks great! Thanks for sharing! >> >> BJ and I had discussed developing something like this a while back. >> It would be >> great if we could find a way to integrate OSGi instead of re- >> inventing the wheel. >> >> >> Porter Woodward wrote: >> >> > Hey all - >> > >> > out of curiousity, has anyone here looked at OSGi? In a lot of >> ways it >> > seems like there would be an interesting fit / refactoring of OFBiz >> that >> > could be done using OSGi as a basis. An implementation of OSGi >> > (Equinox) is used as the foundation for Eclipse. I've also noticed >> that >> > Felix (originally known as Oscar) - another open source OSGi >> > implementation - is now an Apache Incubator project. And another OSGi >> > implementation can be had via Knopflerfish. And, the upcoming Spring >> > release is adding support for OSGi. >> > The basic distributable chunk of code in OSGi is referred to as a >> > Bundle. All in all it looks like an excellent way to bundle and >> deploy >> > components (service bundles), manage their life-cycle, and resolve >> > dependencies. It would almost seem possible to re-bundle most OFBiz >> > component jars as OSGi bundles (not necessarily an optimal approach) - >> > which would allow for the dynamic loading/unloading of components with >> > relative ease. >> > >> > More information is available at: >> > >> > http://www.osgi.org/ >> > >> > - Porter Woodward >> > > > > > |
|
|
I vaguely remember a discussion about hot loading changes.
like can happen in tomcat. I don't remember specifically dealing with OSGI Since it is already part of tomcat, I think it would be best to go with what is already available. Unfortunately, do to many design changes, I lost interest in following up. I am first interested in have freeze point that we can build on, before I am interested in working on this further. Adrian Crum sent the following on 4/3/2007 7:17 AM: > No. Some time ago (before Porter's email) there was considerable > discussion about exploring the possibility of loading/unloading > individual components, automatic component updates, etc. We fleshed out > a few ideas on how to set up component version numbers and check > component dependencies, etc, then the wind got knocked out of our sails > when someone pointed out that the class loader doesn't support those > kinds of operations. All of that is beyond my expertise, so I just > dropped it. I don't know if BJ went any further with it on his own. > > OSGi looked like something that would make the task easier, possibly > even solving the class loader problem. I can't be sure though, because - > like I said - that kind of development is beyond my abilities. > > I revisited the idea at the developers conference, and a few of the > developers felt it would be a great capability to have, but the > discussion didn't go any further than that. > > > Christopher Snow wrote: >> Adrian, >> >> Did This go anywhere? >> >> >>> Adrian Crum wrote: >>> >>> That looks great! Thanks for sharing! >>> >>> BJ and I had discussed developing something like this a while back. >>> It would be >>> great if we could find a way to integrate OSGi instead of re- >>> inventing the wheel. >>> >>> >>> Porter Woodward wrote: >>> >>> > Hey all - >>> > >>> > out of curiousity, has anyone here looked at OSGi? In a lot of >>> ways it >>> > seems like there would be an interesting fit / refactoring of >>> OFBiz that >>> > could be done using OSGi as a basis. An implementation of OSGi >>> > (Equinox) is used as the foundation for Eclipse. I've also >>> noticed that >>> > Felix (originally known as Oscar) - another open source OSGi >>> > implementation - is now an Apache Incubator project. And another >>> OSGi >>> > implementation can be had via Knopflerfish. And, the upcoming Spring >>> > release is adding support for OSGi. >>> > The basic distributable chunk of code in OSGi is referred to as a >>> > Bundle. All in all it looks like an excellent way to bundle and >>> deploy >>> > components (service bundles), manage their life-cycle, and resolve >>> > dependencies. It would almost seem possible to re-bundle most OFBiz >>> > component jars as OSGi bundles (not necessarily an optimal >>> approach) - >>> > which would allow for the dynamic loading/unloading of components >>> with >>> > relative ease. >>> > >>> > More information is available at: >>> > >>> > http://www.osgi.org/ >>> > >>> > - Porter Woodward >>> > >> >> >> >> > > > |
|
|
Adrian/BJ,
Thanks for the responses. OSGi integration sounds like something for the ofbiz wishlist/roadmap?. Cheers, Chris On 4 Apr 2007, at 00:15, BJ Freeman wrote: > I vaguely remember a discussion about hot loading changes. > like can happen in tomcat. > I don't remember specifically dealing with OSGI > Since it is already part of tomcat, I think it would be best to go > with > what is already available. > Unfortunately, do to many design changes, I lost interest in > following up. > I am first interested in have freeze point that we can build on, > before > I am interested in working on this further. > > > Adrian Crum sent the following on 4/3/2007 7:17 AM: >> No. Some time ago (before Porter's email) there was considerable >> discussion about exploring the possibility of loading/unloading >> individual components, automatic component updates, etc. We >> fleshed out >> a few ideas on how to set up component version numbers and check >> component dependencies, etc, then the wind got knocked out of our >> sails >> when someone pointed out that the class loader doesn't support those >> kinds of operations. All of that is beyond my expertise, so I just >> dropped it. I don't know if BJ went any further with it on his own. >> >> OSGi looked like something that would make the task easier, possibly >> even solving the class loader problem. I can't be sure though, >> because - >> like I said - that kind of development is beyond my abilities. >> >> I revisited the idea at the developers conference, and a few of the >> developers felt it would be a great capability to have, but the >> discussion didn't go any further than that. >> >> >> Christopher Snow wrote: >>> Adrian, >>> >>> Did This go anywhere? >>> >>> >>>> Adrian Crum wrote: >>>> >>>> That looks great! Thanks for sharing! >>>> >>>> BJ and I had discussed developing something like this a while back. >>>> It would be >>>> great if we could find a way to integrate OSGi instead of re- >>>> inventing the wheel. >>>> >>>> >>>> Porter Woodward wrote: >>>> >>>>> Hey all - >>>>> >>>>> out of curiousity, has anyone here looked at OSGi? In a lot of >>>> ways it >>>>> seems like there would be an interesting fit / refactoring of >>>> OFBiz that >>>>> could be done using OSGi as a basis. An implementation of OSGi >>>>> (Equinox) is used as the foundation for Eclipse. I've also >>>> noticed that >>>>> Felix (originally known as Oscar) - another open source OSGi >>>>> implementation - is now an Apache Incubator project. And another >>>> OSGi >>>>> implementation can be had via Knopflerfish. And, the upcoming >>>>> Spring >>>>> release is adding support for OSGi. >>>>> The basic distributable chunk of code in OSGi is referred to as a >>>>> Bundle. All in all it looks like an excellent way to bundle and >>>> deploy >>>>> components (service bundles), manage their life-cycle, and resolve >>>>> dependencies. It would almost seem possible to re-bundle most >>>>> OFBiz >>>>> component jars as OSGi bundles (not necessarily an optimal >>>> approach) - >>>>> which would allow for the dynamic loading/unloading of components >>>> with >>>>> relative ease. >>>>> >>>>> More information is available at: >>>>> >>>>> http://www.osgi.org/ >>>>> >>>>> - Porter Woodward >>>>> >>> >>> >>> >>> >> >> >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
|
In reply to this post by BJ Freeman
I've been in touch with the apache felix OSGi mailing list and we may
be able to get some help (when the time is right) looking at the possibility of OSGi: http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/ 200704.mbox/%[hidden email]%3e Any thoughts? Thanks in advance ... On 4 Apr 2007, at 00:15, BJ Freeman wrote: > I vaguely remember a discussion about hot loading changes. > like can happen in tomcat. > I don't remember specifically dealing with OSGI > Since it is already part of tomcat, I think it would be best to go > with > what is already available. > Unfortunately, do to many design changes, I lost interest in > following up. > I am first interested in have freeze point that we can build on, > before > I am interested in working on this further. > > > Adrian Crum sent the following on 4/3/2007 7:17 AM: >> No. Some time ago (before Porter's email) there was considerable >> discussion about exploring the possibility of loading/unloading >> individual components, automatic component updates, etc. We >> fleshed out >> a few ideas on how to set up component version numbers and check >> component dependencies, etc, then the wind got knocked out of our >> sails >> when someone pointed out that the class loader doesn't support those >> kinds of operations. All of that is beyond my expertise, so I just >> dropped it. I don't know if BJ went any further with it on his own. >> >> OSGi looked like something that would make the task easier, possibly >> even solving the class loader problem. I can't be sure though, >> because - >> like I said - that kind of development is beyond my abilities. >> >> I revisited the idea at the developers conference, and a few of the >> developers felt it would be a great capability to have, but the >> discussion didn't go any further than that. >> >> >> Christopher Snow wrote: >>> Adrian, >>> >>> Did This go anywhere? >>> >>> >>>> Adrian Crum wrote: >>>> >>>> That looks great! Thanks for sharing! >>>> >>>> BJ and I had discussed developing something like this a while back. >>>> It would be >>>> great if we could find a way to integrate OSGi instead of re- >>>> inventing the wheel. >>>> >>>> >>>> Porter Woodward wrote: >>>> >>>>> Hey all - >>>>> >>>>> out of curiousity, has anyone here looked at OSGi? In a lot of >>>> ways it >>>>> seems like there would be an interesting fit / refactoring of >>>> OFBiz that >>>>> could be done using OSGi as a basis. An implementation of OSGi >>>>> (Equinox) is used as the foundation for Eclipse. I've also >>>> noticed that >>>>> Felix (originally known as Oscar) - another open source OSGi >>>>> implementation - is now an Apache Incubator project. And another >>>> OSGi >>>>> implementation can be had via Knopflerfish. And, the upcoming >>>>> Spring >>>>> release is adding support for OSGi. >>>>> The basic distributable chunk of code in OSGi is referred to as a >>>>> Bundle. All in all it looks like an excellent way to bundle and >>>> deploy >>>>> components (service bundles), manage their life-cycle, and resolve >>>>> dependencies. It would almost seem possible to re-bundle most >>>>> OFBiz >>>>> component jars as OSGi bundles (not necessarily an optimal >>>> approach) - >>>>> which would allow for the dynamic loading/unloading of components >>>> with >>>>> relative ease. >>>>> >>>>> More information is available at: >>>>> >>>>> http://www.osgi.org/ >>>>> >>>>> - Porter Woodward >>>>> >>> >>> >>> >>> >> >> >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |