1 Apr 10:58
1 Apr 11:53
Service or Export-Package
Hi All,
This is more a generic OSGi question. I understand the difference between Require-Bundle and Import-Package. But what i`m not able to understand is when should I register my class as a service?, and when I should simply export the package, so that other packages can import and use them?
What is the advantage of registering as a service? I`ve gone through the OSGi best practices doc, by BJ Hargrave and Peter Kriens, and read about dynamism of using service. But let me say that i have some core bundles which I am going to always have loaded, then should I expose my classes as a service or use Export-Package alone.. Which is the better practice.?
Thanks,
Srijith.
1 Apr 13:12
Re: Service or Export-Package
On 01/04/2008, Srijith Kochunni <ksrijith-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
Hi All,
This is more a generic OSGi question. I understand the difference between Require-Bundle and Import-Package. But what i`m not able to understand is when should I register my class as a service?, and when I should simply export the package, so that other packages can import and use them?
What is the advantage of registering as a service?
a few more benefits of services:
1) you can use different implementations of a service at the same time
2) services can have rich metadata, which you can use to filter on
4) service implementations are POJOs, no need to create instances
(ie. to use an imported class you may need to create an instance
which can lead to classloading issues that you might not see with
services, as they're created by the registering bundle...)
5) a service has more fine-grained information about who's using it
(as a bundle could get and unget a service during it's lifetime)
I'm sure I've missed other benefits - of course there is a management
overhead to services, but it's not too high compared to the benefits :)
I`ve gone through the OSGi best practices doc, by BJ Hargrave and Peter Kriens, and read about dynamism of using service. But let me say that i have some core bundles which I am going to always have loaded, then should I expose my classes as a service or use Export-Package alone.. Which is the better practice.?
I tend to use Export-Package for static dependencies that I know will
only have a single provider - mostly utility methods - and of course to
provide service APIs ;)
for major bundle dependencies, especially methods involving state,
I would typically use services, because of the benefits I listed above
but there's no golden rule, and a lot of this will come from experience
- you can always migrate to services over time if you keep your code
decoupled (you can use Declarative Services, Spring-DM or iPOJO
to inject services, which minimises their impact on client code)
btw, when separating code into bundles it's a good idea to minimise
dependencies between them by using something like the "CRC card"
design approach - and as part of this exercise see if they look more
like services or exports...
HTH
Thanks,
Srijith.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Cheers, Stuart
1 Apr 15:38
Re: Incubator request for Extensions/Services Integration work
+1
Great! This is a very interesting topic.
Within Riena we are currently using a simple to use ´framework´ to
inject services and extensions
into objects (pojos). Our approach is code based and looks like this.
Inject.service("clazz1").into(target).andStart(context)
Inject.service("clazz2").useFilter(filter).into(target).bind("register").unbind("unregister").andStart(context)
Inject.service("clazz3").useRanking().into(target).bind("register").unbind("unregister").andStart(context)
where ´target´ is the pojo that gets a service/s injected. When services
come and go they will be injected
into or removed from the pojos. The method names for injecting/removing
can be specified with the bind()
and unbind() methods. If they are not defined default method names are
assumed.
With
Inject.extension("point1").into(target).andStart(context)
Inject.extension("point2").useType(interface).into(target).bind("configure").andStart(context)
Inject.extension("point3").expectExactly(1).into(target).andStart()
extension points get injected into pojos as instances of an interface
defined by useType(). If the interface is
not defined explicitly it will be retrieved with reflection from the
bind method. The interface needs only to declare
the getters. Dynamic proxies will be created for this interface which
map the data from the extensions. A few simple
rules are used for the mapping from extension to the properties
(lightweight xml/java mapping).
The source code is available in org.eclipse.riena package
org.eclipse.riena.core.injector. Unit tests are available in
org.eclipse.riena.tests packages org.eclipse.riena.core.extension/service.
Tschüß,
Stefan
Neil Bartlett wrote:
> Hello,
>
> I have been doing some investigative work recently in the area of
> integrating extensions with OSGi services. As a result of this, I have
> developed a small framework for dynamically injecting services into
> extension objects according to metadata defined via the extension
> registry. As a very simple example, suppose we have an extension
> object (e.g. a ViewPart) which has a method
> setLogReader(LogReaderService). We can declare an "injected bean"
> extension as follows:
>
> <extension point="...injectedBeans">
> <bean id="logReaderView"
> class="org...LogReaderView">
> <injectSingle interface="org.osgi.service.log.LogReaderService"
> set="setLogReader"/>
> </bean>
> </extension>
>
> And then the actual view extension as:
>
> <extension point="org.eclipse.ui.views">
> <view class="org...InjectedExtensionFactory:logReaderView"
> name="Log Reader"/>
> </extension>
>
> This results in all objects instantiated from the log view extension
> being dynamically injected with the log reader service as it becomes
> available (and un-injected when it goes away).
>
> I would like to request a work area under the Equinox incubator as a
> home for this code so that others can test it and experiment with this
> and other approaches to the extensions/services integration problem.
>
> Regards,
> Neil
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
1 Apr 15:40
RE: Service or Export-Package
I'd also like to add that with a service model in general
you can also use IoC mechanism such as Spring-DM, OSGi DeclarativeServices,
iPojo and others. IoC is a very sweet programming model that can isolate
you from the fact that services are even being used (and isolate you from the
OSGi API itself)!
(To me, IoC is the KILLER reason to use
services)!
John Wells (Aziz)
jwells-F6+Doa/ZKZs/WgRJbjlA5Q@public.gmane.org
From: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org [mailto:equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org] On Behalf Of Stuart McCullochOn 01/04/2008, Srijith Kochunni <ksrijith-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
Sent: Tuesday, April 01, 2008 7:13 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Service or Export-Package
--Hi All,
This is more a generic OSGi question. I understand the difference between Require-Bundle and Import-Package. But what i`m not able to understand is when should I register my class as a service?, and when I should simply export the package, so that other packages can import and use them?
What is the advantage of registering as a service?
3) you can customize services per clients (see ServiceFactory interface)
a few more benefits of services:
1) you can use different implementations of a service at the same time
2) services can have rich metadata, which you can use to filter on
4) service implementations are POJOs, no need to create instances
(ie. to use an imported class you may need to create an instance
which can lead to classloading issues that you might not see with
services, as they're created by the registering bundle...)
5) a service has more fine-grained information about who's using it
(as a bundle could get and unget a service during it's lifetime)
I'm sure I've missed other benefits - of course there is a management
overhead to services, but it's not too high compared to the benefits :)I`ve gone through the OSGi best practices doc, by BJ Hargrave and Peter Kriens, and read about dynamism of using service. But let me say that i have some core bundles which I am going to always have loaded, then should I expose my classes as a service or use Export-Package alone.. Which is the better practice.?
I tend to use Export-Package for static dependencies that I know will
only have a single provider - mostly utility methods - and of course to
provide service APIs ;)
for major bundle dependencies, especially methods involving state,
I would typically use services, because of the benefits I listed above
but there's no golden rule, and a lot of this will come from experience
- you can always migrate to services over time if you keep your code
decoupled (you can use Declarative Services, Spring-DM or iPOJO
to inject services, which minimises their impact on client code)
btw, when separating code into bundles it's a good idea to minimise
dependencies between them by using something like the "CRC card"
design approach - and as part of this exercise see if they look more
like services or exports...
HTHThanks,
Srijith.
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Cheers, Stuart
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
1 Apr 16:52
Re: Service or Export-Package
On 01/04/2008, John Wells <jwells-2Tjm5za6O7k@public.gmane.org> wrote:
I'd also like to add that with a service model in general you can also use IoC mechanism such as Spring-DM, OSGi DeclarativeServices, iPojo and others. IoC is a very sweet programming model that can isolate you from the fact that services are even being used (and isolate you from the OSGi API itself)!(To me, IoC is the KILLER reason to use services)!
totally agree, dependency injection + services is really neat!
I'd like to add Guice to the above list of IoC frameworks that can
inject OSGi services. See http://code.google.com/p/peaberry for
more info - hope to get an alpha release out sometime this week.
John Wells (Aziz)
2 Apr 03:36
[p2] ECF bundles not up to date in M6
Howday p2'ers, The M6 release of Eclipse/p2 seems to have used a relatively old integration build of the 4 ECF bundles (i.e. they have qualifier v20080317-0809 rather than the 20080324 integration build as I expected from this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 This is not tragic, but it causes us a little bit of consternation because there were some very small API additions for ECF filetransfer during the week of the 17th, and these obviously didn't get into M6 of platform. This means that the next milestone of ECF will include these small API additions...and I wanted to let everyone know this doesn't constitute an API freeze breach...as ECF's filetransfer bundles are frozen at this point (but M6 of platform didn't get these additions during week of 24th). Thanks, Scott
2 Apr 04:39
Re: [p2] ECF bundles not up to date in M6
I'm sorry about the problems this can cause the ECF users, however we tried moving to this most recent build but as you can see, it failed finding the jars on the server during the build http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg11579.html In case of a rebuild we will be looking into addressing this. From: Scott Lewis <slewis@...> To: Equinox development mailing list <equinox-dev@...> Date: 04/01/2008 09:38 PM Subject: [equinox-dev] [p2] ECF bundles not up to date in M6 Howday p2'ers, The M6 release of Eclipse/p2 seems to have used a relatively old integration build of the 4 ECF bundles (i.e. they have qualifier v20080317-0809 rather than the 20080324 integration build as I expected from this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 This is not tragic, but it causes us a little bit of consternation because there were some very small API additions for ECF filetransfer during the week of the 17th, and these obviously didn't get into M6 of platform. This means that the next milestone of ECF will include these small API additions...and I wanted to let everyone know this doesn't constitute an API freeze breach...as ECF's filetransfer bundles are frozen at this point (but M6 of platform didn't get these additions during week of 24th). Thanks, Scott _______________________________________________ equinox-dev mailing list equinox-dev@... https://dev.eclipse.org/mailman/listinfo/equinox-dev
2 Apr 06:46
Re: [p2] ECF bundles not up to date in M6
Hi Pascal, Strange...as I'm quite certain I checked 3/31 afternoon that the jars referenced in this map http://download.eclipse.org/technology/ecf/integration/ecf.filetransfer.map were replicated OK. Even so, this was after M6 build (sunday) anyway. But this brings up a question for us: If people use the dropins and/or plugins directory install, and they put a newer version of a plugin that already exists/is installed as part of platform, what happens? Bad things/is this to be avoided? or can it be safely done? Thanks, Scott Pascal Rapicault wrote: > I'm sorry about the problems this can cause the ECF users, however we tried > moving to this most recent build but as you can see, it failed finding the > jars on the server during the build > http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg11579.html > > In case of a rebuild we will be looking into addressing this. > > > > From: Scott Lewis <slewis@...> > > To: Equinox development mailing list <equinox-dev@...> > > Date: 04/01/2008 09:38 PM > > Subject: [equinox-dev] [p2] ECF bundles not up to date in M6 > > > > > > > Howday p2'ers, > > The M6 release of Eclipse/p2 seems to have used a relatively old > integration build of the 4 ECF bundles (i.e. they have qualifier > v20080317-0809 rather than the 20080324 integration build as I expected > from this bug: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 > > This is not tragic, but it causes us a little bit of consternation > because there were some very small API additions for ECF filetransfer > during the week of the 17th, and these obviously didn't get into M6 of > platform. > > This means that the next milestone of ECF will include these small API > additions...and I wanted to let everyone know this doesn't constitute an > API freeze breach...as ECF's filetransfer bundles are frozen at this > point (but M6 of platform didn't get these additions during week of 24th). > > Thanks, > > Scott > > > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@... > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@... > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
2 Apr 12:03
Re: [p2] ECF bundles not up to date in M6
Scott, the problem with the ECF JARs earlier this week was that they hadn't replicated to our local servers here. So when people (Kim/Pascal) accessed the URLs for the JARs from home it was all good but when the build machine tried, it was redirected to a local machine which didn't have the JARs yet. The easiest fix at the time was to revert our contribution to the one from the previous map file so that's what I did. Like Pascal mentions, we will look into moving up to the new versions. The idea of dropping higher versions of bundles into your dropins folder is referred to around here at the "patch" problem. It is on the list but it is not implemented yet. Currently the workaround is to either use the same bundle versions when exporting, or update the bundle.info file manually with the correct information. equinox-dev-bounces@... wrote on 04/02/2008 12:46:33 AM: > Hi Pascal, > > Strange...as I'm quite certain I checked 3/31 afternoon that the jars > referenced in this map > > http://download.eclipse.org/technology/ecf/integration/ecf.filetransfer.map > > were replicated OK. Even so, this was after M6 build (sunday) anyway. > > But this brings up a question for us: If people use the dropins and/or > plugins directory install, and they put a newer version of a plugin that > already exists/is installed as part of platform, what happens? Bad > things/is this to be avoided? or can it be safely done? > > Thanks, > > Scott > > Pascal Rapicault wrote: > > I'm sorry about the problems this can cause the ECF users, however we tried > > moving to this most recent build but as you can see, it failed finding the > > jars on the server during the build > > http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg11579.html > > > > In case of a rebuild we will be looking into addressing this. > > > > > > > > From: Scott Lewis <slewis@...> > > > > To: Equinox development mailing list <equinox- > dev@...> > > > > Date: 04/01/2008 09:38 PM > > > > Subject: [equinox-dev] [p2] ECF bundles not up to date in M6 > > > > > > > > > > > > > > Howday p2'ers, > > > > The M6 release of Eclipse/p2 seems to have used a relatively old > > integration build of the 4 ECF bundles (i.e. they have qualifier > > v20080317-0809 rather than the 20080324 integration build as I expected > > from this bug: > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 > > > > This is not tragic, but it causes us a little bit of consternation > > because there were some very small API additions for ECF filetransfer > > during the week of the 17th, and these obviously didn't get into M6 of > > platform. > > > > This means that the next milestone of ECF will include these small API > > additions...and I wanted to let everyone know this doesn't constitute an > > API freeze breach...as ECF's filetransfer bundles are frozen at this > > point (but M6 of platform didn't get these additions during week of 24th). > > > > Thanks, > > > > Scott > > > > > > > > > > _______________________________________________ > > equinox-dev mailing list > > equinox-dev@... > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > > > _______________________________________________ > > equinox-dev mailing list > > equinox-dev@... > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@... > https://dev.eclipse.org/mailman/listinfo/equinox-dev
RSS Feed