Home » Eclipse Projects » Equinox » Moving application into OSGI bundles: a problem
| Moving application into OSGI bundles: a problem [message #50753] |
Tue, 18 October 2005 10: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 #50810 is a reply to message #50782] |
Tue, 18 October 2005 15:00  |
| Eclipse User |
|
|
|
Originally posted by: eclipse.sunnychan.org.uk
Hi Neil,
Yup, after I posted the message I did a bit more googling and it seems to
be the solution eclipse provide...
However, is there any offical "OSGI" ways round this? I love to get my
OSGI bundles working with Knoplerfish - they have a cool interface to
start and stop bundles :-)
Will the furture updates to OSGI spec address this?
Thanks,
Sunny
|
|
| |
| Re: Moving application into OSGI bundles: a problem [message #50946 is a reply to message #50837] |
Thu, 20 October 2005 01:14 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
ConfigAdmin, Events, UserAdmin, Log, HTTP, Declarative Services and some
others should appear in the Equinox repo in the next few weeks. We are
working through the legal process now.
Jeff
"Ricky" <ImmortalRick@gmx.de> wrote in message
news:op.syunmx1baudqvk@localhost.localdomain...
> > 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.
>
> Maybe a more service oriented approach will help: The logic bundles could
> provide there objects as services. From here there are several paths. The
> common (configurator) bundle could get all services from the service
> registry and configures them (with reflection vodoo or normal method
> calls). Or you use the ConfigurationAdmin Service to inject data into the
> service objects.
>
> Anyway your flow of control changes as things do something useful only
> when everything they needs is present. When using this approach you need
> to be aware that services may not be available. This is fundamentally
> different coding style to normal RCP/Eclipse coding (where you assume
> everything is present). Some helpers whould be (the very static) Service
> Binder or the Service Tracker.
>
> I do not know which parts of the OSGi specification are implemented by
> equinox. All interessing services like User Admin etc seem not to be
> present. What about ConfigurationAdmin?
>
> hth,
>
> Ricky
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #50974 is a reply to message #50810] |
Thu, 20 October 2005 01:22 |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
"Sunny Chan" <eclipse@sunnychan.org.uk> wrote in message
news:0b5d2d780c64dff0a12386937f372513$1@www.eclipse.org...
> Hi Neil,
>
> Yup, after I posted the message I did a bit more googling and it seems to
> be the solution eclipse provide...
I would NOT recommend buddy loading. It is intended to be a last ditch
mechanism and is highly experimental.
> However, is there any offical "OSGI" ways round this?
The official OSGi story is to use DynamicImport-Package. This allows your
common bundle to dynamicaly discover packages/classes. It still has to know
what packages to list. You can use * but that is bad form and may have
performance implications.
The Eclipse way is to use the extension registry. The common plugin would
expose an extension point and the other guys would contribute extensions.
The extensions identify classes (by name) that implement some
interface/extend some type defined by the common bundle. Wehn you want to
instantiate something you look up the extension and use
IConfigurationElement.createExecutableExtension.
> 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 :-)
BTW, the extension registry is currently being separated out so that it will
run standalone or in other OSGi implementations.
> 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...
Jeff
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #51002 is a reply to message #50974] |
Thu, 20 October 2005 10:30 |
| Eclipse User |
|
|
|
Originally posted by: neil.integility.com
Jeff,
> 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?
Regards,
Neil
|
|
| |
| Re: Moving application into OSGI bundles: a problem [message #51058 is a reply to message #51030] |
Thu, 20 October 2005 11:40 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
Normally everything is done directly in the public repository and the
whole code is available all the time.
The situation with those new services is that it is a donation from a
company and this donation has first to be revewied for legal issues by
the donating company. Then it has to be reviewed by us and the
foundation (or something like that).
Once the service will have been contributed to the equinox repository
everything will happen there like explained in the first paragraph.
To summarize this is exceptional.
PaScaL
Ricky wrote:
>> ConfigAdmin, Events, UserAdmin, Log, HTTP, Declarative Services and some
>> others should appear in the Equinox repo in the next few weeks. We are
>> working through the legal process now.
>
>
> I would love to have a repository where all my required classes
> "appear" :) May I ask how the development process works? Is there a
> core group with a private repository which uploads there changes to the
> public equinox repository once in a while? Do the legal issues arise
> because the core group is a company with a ready-to-go OSGi
> implementation?
>
> I am very interested in implementations of these services and would
> like to see how some algorithmic problems are solved (efficent
> filtering of events in EventAdmin or role resolution in UserAdmin).
> Only wondering if it is possible to see some development snapshots.
>
> Regard,
>
> Ricky
|
|
|
| Re: Moving application into OSGI bundles: a problem [message #51141 is a reply to message #51002] |
Thu, 20 October 2005 16: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] |
Sat, 22 October 2005 01: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 08: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 #51619 is a reply to message #51336] |
Tue, 25 October 2005 18:02 |
| Eclipse User |
|
|
|
Originally posted by: jacob.blain.christen.entheal.com
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 #51757 is a reply to message #51619] |
Thu, 27 October 2005 01: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] |
Thu, 27 October 2005 02: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: Fri Apr 26 00:44:28 GMT 2024
Powered by FUDForum. Page generated in 0.04420 seconds |
] 
Search
Help
Register
Login
Home
