Home » Eclipse Projects » Equinox » Moving application into OSGI bundles: a problem
| Moving application into OSGI bundles: a problem [message #50753] |
Tue, 18 October 2005 06:26  |
Eclipse User |
|
|
|
Originally posted by: eclipse.sunnychan.org.uk
Hi everyone,
I am looking to move one of our application into OSGI bundles so that I
can use it on top of Equinox, however I have a little problem.
Our applications is split into a "common" module which contains some code
common to all the applications, and multiple logic modules which contains
handler to deal with different scenario. The common module parses a XML
config file to instantiate the logic module using Reflection API.
Naturally one would turn the common module and logic modules into bundles,
and in the manifest file saying that the logic bundles depends on the
common modules. However, we have a class loading problem as the common
bundles will not be able to load classes from its child.
I was thinking of using a Fragment bundles to solved this problem. However
it seems to me that there can only be one host for each Fragment bundles,
so it probably doesn't work.
Anybody got any suggestions?
Thanks,
Sunny Chan
|
|
| | | | | | | | |
| Re: Moving application into OSGI bundles: a problem [message #51141 is a reply to message #51002] |
Thu, 20 October 2005 12:38  |
| Eclipse User |
|
|
|
Originally posted by: jacob.blain.christen.entheal.com
Neil Bartlett wrote:
>> I would NOT recommend buddy loading. It is intended to be a last ditch
>> mechanism and is highly experimental.
>
>
> It's interesting that you say that. Buddy loading was the only way I
> knew for getting plugins to load arbitrary classes from downstream plugins.
>
> Suppose I have that old chestnut of a problem: an RCP app that uses
> Hibernate for persistance. How can I best get Hibernate to load my bean
> classes? I can't expect Hibernate to know about
> IConfigurationElement.createExecutableExtension(), nor can I make the
> Hibernate bundle depend on the bundles that contain my bean classes.
> Previously the recommendation on the RCP newsgroup was to use buddy
> loading. Should we use DynamicImport-Package instead? Isn't that just as
> experimental?
DynamicImport-Package is blessed by the OSGi spec, whereas buddy loading
is an Eclipse-ism, and a classic hack at that. There are a couple
different ways to address your problem as described:
1) attach fragments to the bundle containing hibernate that provide the
"downstream" classes that need to be loaded.
2) create some hibernate extension points via the eclipse extension
registry such that downstream classes/bundles can let hibernate know
what needs loading. this would require a thin layer of hibernate
wrapping logic.
3) if you want to use pure OSGi concepts, convert the eclipse extension
registry mechanism into your own similar sort of OSGi service. you
would most likely find yourself to be re-inventing the wheel with this
approach, however, because i do believe the eclipse extension registry
is implemented as an OSGi service. you could, though, forgoe the
extension concept and just provide a hibernate service or somesuch that
responds to downstream invocations upon it, presumably supplying it with
beans to load.
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #51336 is a reply to message #51141] |
Fri, 21 October 2005 21:00 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
"Jacob L E Blain Christen" <jacob.blain.christen@entheal.com> wrote in
message news:dj8h6q$9oq$1@news.eclipse.org...
> Neil Bartlett wrote:
>
> >> I would NOT recommend buddy loading. It is intended to be a last ditch
> >> mechanism and is highly experimental.
> >
> > It's interesting that you say that. Buddy loading was the only way I
> > knew for getting plugins to load arbitrary classes from downstream
plugins.
> >
> > Suppose I have that old chestnut of a problem: an RCP app that uses
> > Hibernate for persistance.
Yup. This is rather the exception however. That is, third party code that
is, in effect, extensible. That's all I meant.
> > How can I best get Hibernate to load my bean
> > classes? I can't expect Hibernate to know about
> > IConfigurationElement.createExecutableExtension(), nor can I make the
> > Hibernate bundle depend on the bundles that contain my bean classes.
> > Previously the recommendation on the RCP newsgroup was to use buddy
> > loading. Should we use DynamicImport-Package instead? Isn't that just as
> > experimental?
>
> DynamicImport-Package is blessed by the OSGi spec, whereas buddy loading
> is an Eclipse-ism, and a classic hack at that. There are a couple
Dynamic Import is certainly part of the OSGi spec and has been for a while.
There are a few issues with using it.
- To address some usecases you would have to do DynamicImport-Package: *.
This can be a performance hit. In Equinox we have done some optimizations
to cache discovered wirings so the searching hit occurs only until the
package is found. Subsequent loads from the package are full speed.
- it is undirected and global. that can be good but it can also be
problematic. A problem case is where you have several suppliers of a
package but you really wanted just a particular one to interact with, say,
Hibernate.
- The use of a dynamic import introduces a dependency. So, for example, if
Hibernate uses dynamic import and it loads a class from bundle B, Hibernate
now depends on B. If B is uninstalled or updated, Hibernate is stopped and
restarted. In some cases this is what you want but in the case Hibernate it
is likely not. Hibernate does not hang onto B's classes, it merely needs
them temporarily while marshaling.
Again, there are pluses and minuses. We added buddy loading as an
experiment to see how such a mechanism would work and if it was useful.
> 1) attach fragments to the bundle containing hibernate that provide the
> "downstream" classes that need to be loaded.
This is slick but has the problem that the fragment has to include the
transitive closure of all types reachable from the types being manipulated
by hibernate or you have to use the fragment to add dependencies to
Hibernate. See the points in dynamic import above.
> 2) create some hibernate extension points via the eclipse extension
> registry such that downstream classes/bundles can let hibernate know
> what needs loading. this would require a thin layer of hibernate
> wrapping logic.
Can you expand on that? How does the hibernate bundle classloader get
hooked into the extension registry? If you can change hibernate code I
agree but assuming you cant? It feels like this might reduce to something
pretty much like the buddy mechanism.
> 3) if you want to use pure OSGi concepts, convert the eclipse extension
> registry mechanism into your own similar sort of OSGi service. you
> would most likely find yourself to be re-inventing the wheel with this
> approach, however, because i do believe the eclipse extension registry
> is implemented as an OSGi service. you could, though, forgoe the
> extension concept and just provide a hibernate service or somesuch that
> responds to downstream invocations upon it, presumably supplying it with
> beans to load.
A couple points here:
- the extension registry is being factored out of the runtime as a
standalone bundle so it will be usable in plain OSGi environments.
- re pure OSGi. Don't push that notion too far. the OSGi spec is nice in
that there is a core framework and a set of services that can be added on.
There isn't any particular value (IMHO) in distinguishing between add-on
services that come from OSGi and those that come from other sources. In
both cases they are likely in additional bundles that you add to your
configuration and use the supplied API.
- the extension registry is (will be) available as a service but that just
means you can "get" the registry via the serives mechanism. Extnesions/ext
pts and services are different but complementary mechanisms. You should use
the one appropriate to your situation.
- If you are able to proactively tell hibernate (whatever) all the classes
that it will need to manipulate then there are many possible implementation
options. I was assuming you could not.
Jeff
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #51598 is a reply to message #50974] |
Tue, 25 October 2005 04:53 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.sunnychan.org.uk
Hi Jeff
Thanks for your reply before hand, I have a much better idea of the issues
surrounding buddy loading, etc. For the time being we can probably live
with it, but I wish that R5 spec would have an offical story for this :-)
Jeff McAffer wrote:
>> I love to get my
>> OSGI bundles working with Knoplerfish - they have a cool interface to
>> start and stop bundles :-)
> Just a thought, run the cool Knopflerfish interface on Equinox. Its all
> just OSGi :-)
I tried (soon after I written the message) and it works great - I can
start and stop bundles, etc with the desktop. I am start feeling the love
for OSGi :-)
Is Equinox going to get it's own HTTP service soon?
>> Will the furture updates to OSGI spec address this?
> It is a common issue but for now, the R4 spec was just published so you have
> a year or two until R5...
Well, I think we should be okay with this for now, but I hope they will
make this a priority for R5 spec - anybody I can "speak" to?
Thanks,
|
|
| |
| Re: Moving application into OSGI bundles: a problem [message #51757 is a reply to message #51619] |
Wed, 26 October 2005 21:47 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
The problem really is that you cannot hook into classloading in OSGi. That
is sort of the point. If you could do buddy loading from outside the
framework then, well, we would not have done buddy loading. I like the
extension idea but there is no way that I see to hook in the extensions in a
seamless, transparent way. We talked about doing buddies as basically just
a service lookup and delegation (Pascal actually implemented it that way)
but we backed out of that due to complexity and lack of usecases.
Jeff
"Jacob L E Blain Christen" <jacob.blain.christen@entheal.com> wrote in
message news:djlrur$rbk$1@news.eclipse.org...
> Jeff McAffer wrote:
> > "Jacob L E Blain Christen" <jacob.blain.christen@entheal.com> wrote in
>
> > Again, there are pluses and minuses. We added buddy loading as an
> > experiment to see how such a mechanism would work and if it was useful.
> >
> >>1) attach fragments to the bundle containing hibernate that provide the
> >>"downstream" classes that need to be loaded.
> >
> > This is slick but has the problem that the fragment has to include the
> > transitive closure of all types reachable from the types being
manipulated
> > by hibernate or you have to use the fragment to add dependencies to
> > Hibernate. See the points in dynamic import above.
>
> Given the described problem space, specifically it's use of Hibernate, I
> believe this to be a capable, if somewhat improper, solution.
>
> >>2) create some hibernate extension points via the eclipse extension
> >>registry such that downstream classes/bundles can let hibernate know
> >>what needs loading. this would require a thin layer of hibernate
> >>wrapping logic.
> >
> > Can you expand on that? How does the hibernate bundle classloader get
> > hooked into the extension registry? If you can change hibernate code I
> > agree but assuming you cant? It feels like this might reduce to
something
> > pretty much like the buddy mechanism.
>
> Indeed it could reduce to buddy loading, as this is what I was aiming to
> "replace" with the ideas I threw out. My focus in such was on
> establishing a contract between Hibernate and it's clients as opposed to
> establishing a mechanism to simply inject classes into an upstream
> bundle's classloader-space.
>
> > - re pure OSGi. Don't push that notion too far. the OSGi spec is nice
in
> > that there is a core framework and a set of services that can be added
on.
> > There isn't any particular value (IMHO) in distinguishing between add-on
> > services that come from OSGi and those that come from other sources. In
> > both cases they are likely in additional bundles that you add to your
> > configuration and use the supplied API.
>
> For "pure OSGi" all I meant was "something that doesn't rely on a
> framework implementation-specific feature." If you can include buddy
> loading support, or it's like, via a system extension then this
> distinction is moot.
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #51837 is a reply to message #51598] |
Wed, 26 October 2005 22:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
"Sunny Chan" <eclipse@sunnychan.org.uk> wrote in message
news:0dcbfebbd1adb8ae6b0628dbe1025d37$1@www.eclipse.org...
> >> I love to get my
> >> OSGI bundles working with Knoplerfish - they have a cool interface to
> >> start and stop bundles :-)
>
> > Just a thought, run the cool Knopflerfish interface on Equinox. Its all
> > just OSGi :-)
>
> I tried (soon after I written the message) and it works great - I can
> start and stop bundles, etc with the desktop. I am start feeling the love
> for OSGi :-)
Great. I'll have to try it too.
> Is Equinox going to get it's own HTTP service soon?
Yes. See http://eclipse.org/equinox/bundles for information on some of the
things that are in the works.
Jeff
|
|
|
Goto Forum:
Current Time: Sun May 11 06:30:42 EDT 2025
Powered by FUDForum. Page generated in 0.06810 seconds |
Home