[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] When is DS done loading services?
|
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Richard S. Hall wrote:
> Danail Nachev wrote:
>> I'm not sure what is the application being discussed here, but here is a
>> use case:
>>
>> An RCP application is being built, which is headless and when launched
>> does some processing and then exits (Update manager refreshes the
>> installation?). This application supports plugins. So, when the
>> application is launched it should get reference to all plugins and use
>> them do its thing. I don't think it is possible to deal with the
>> dynamics of OSGi registry in this case - the application needs to know
>> the available plugins upfront (or it can use the extension registry).
>>
>
> Did you say why you cannot install your plugins in a lower start level?
It seems that there is much better workaround for the Otto problem:
using a component in a bundle with the highest start level will cause
the DS to process this component last. Perhaps, everybody else has this
in mind from the beginning, but I failed to see it:) Note that this
workaround requires:
* components to be processed in the order they receive
* when a component is activated, all dependent components are processed
synchronously
If those two conditions are not met, the workaround won't work. I don't
remember such requirements in the specification, so it is implementation
dependent.
>
>> Such usage of OSGi may not be very natural (an application which doesn't
>> change while running), but OSGi provides other advantages beside the
>> dynamic environment.
>>
>> Another thing is how bundles are developed usually: if a bundle provides
>> services w/o dependencies, they are registered in the Activator's start
>> method. If a bundle provides services with dependencies upon another
>> services, the bundle opens a tracker and register the service when all
>> its dependencies are satisfied. Because the tracker is opened in the
>> start() method, the service is registered immediately (in the same
>> start() method call). The current DS operation is similar to: when the
>> bundle is started, it spawns a thread which registers what it is needed.
>> This doesn't feel natural.
>>
>
> I think these are the issue you always have when you have a bunch of
> things that need to be started and there are dependencies among them. If
> your assumption is that none of your plugins depend on each other, then
> I understand why it appears like this is easy situation to resolve for
> your core component since it just needs to be injected with all plugins.
> However, if there are dependencies among plugins, even if there is no
> dynamism, then you still have to wait for everything to come up to
> handle the ordering of dependencies before you can continue.
It seems that you incorrectly assumes that the exact dependencies are
known. The case might be that there are optional things, but
unfortunately you need to snapshot the available dependencies and start
doing what you do. It is of no use if the service is available later (at
least in the case I describe), because you cannot just plug them in the
process (they missed some steps of the processing or sth.).
>
>> Another effect of the synchronous processing: it will clear up the
>> meaning of framework started event: With DS handling services
>> asynchronously, framework started has no meaning, because the framework
>> isn't ready when the event is delivered (same with start level changes)
>> - DS is still registering services.
>>
>
> Well, the framework is ready. The services aren't.
Overall, the system is not ready. I'm starting to question what is the
purpose of the framework started event. Knowing that all bundles are
activated is of no use, if they register their services afterwards (of
course, there are cases which are against this, but they aren't many).
>
>> OSGi supports dynamic changes, but I think it should be left to the
>> clients to decide whether they need it. Using a subset of the OSGi
>> features is perfectly OK, IMHO.
>>
>
> Agreed.
>
> -> richard
>
>> --
>> Danail Nachev
>> Senior Software Engineer/Development Tools
>> ProSyst Labs EOOD
>> -------------------------------------------------
>> stay in touch with your product.
>> -------------------------------------------------
>>
>> Cortez, Otto wrote:
>>
>>> Is that true of all extension of the
>>> org.eclipse.core.runtime.applications extension point, that they don’t
>>> start until the platform has been initialized? Even when they run in
>>> any thread and not just the main?
>>>
>>>
>>>
>>> I would be happy enough to be able to say: if you declare your services
>>> in this way, we will wait for those to be initialized before we start,
>>> otherwise we won’t guarantee your service will be available. I was
>>> hopping to be able to do that through DS, so waiting for the DS thread
>>> to stop seems fine, although it would be nice to have a more formal way
>>> to do this, through public API.
>>>
>>>
>>>
>>> In our application, we don’t expect bundles to be started and stopped
>>> dynamically (at least not too often), so we are really only worried
>>> about knowing what services there are at the initial startup.
>>>
>>>
>>>
>>> I was trying to figure out a good way to safeguard against the dynamism
>>> of the services. I don’t think there is an issue with the services
>>> which require 0..1 or 1..1 instances of another service, but I don’t
>>> know what to do about the services which require 0..n and 1..n because
>>> you don’t really know how many more services there might be without
>>> doing what DS seems to already do, look through the manifests and find
>>> the declared services. I suppose you could also wait for the platform
>>> to stop starting bundles, but then DS could still be running so I’d
>>> still need a way to know when it was done.
>>>
>>>
>>>
>>> Thanks,
>>> Otto
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* equinox-dev-bounces@xxxxxxxxxxx
>>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Thomas Watson
>>> *Sent:* Wednesday, September 03, 2008 1:30 PM
>>> *To:* Equinox development mailing list
>>> *Subject:* RE: [equinox-dev] When is DS done loading services?
>>>
>>>
>>>
>>> I think part of the problem here is the term "application". In this case
>>> we are talking about an RCP application which is defined as an Eclipse
>>> extension to the org.eclipse.core.runtime.applications extension point.
>>> When launching Eclipse the default application is started after the
>>> platform has been initialized and the start-level has reached the final
>>> state.
>>>
>>> RCP applications have historically depended on the platform to be "fully
>>> booted" and ready before their application is started. This mentality
>>> does not mix well with the dynamic nature of OSGi services. When DS is
>>> added to the mix the boot sequence become less predictable because
>>> services are not registered synchronously as bundles get started during
>>> the bootup process (incrementing the start-level). Currently the Eclipse
>>> application container just assumes the application is ready to launch
>>> after the the platform has been initialized and the final start-level
>>> has been reached.
>>>
>>> To work around the issue you will need to do something like BJ says and
>>> make the application handle dynamic service registrations. The problem
>>> you will run into is that the Eclipse application container has no idea
>>> that your Eclipse application depends on services before it is ready to
>>> launch. So in addition to making your application handle dynamic
>>> services, you will also need to handle waiting for your "required"
>>> services to be available in your application start method before
>>> allowing your application start method to continue to bring up your
>>> application. Or you can simply allow your application to start and put
>>> safeguards in to handle when a service is not available yet.
>>>
>>> It would be great if we could figure out a better way to mix the use of
>>> extensions and services together in an Eclipse application.
>>>
>>> Tom
>>>
>>>
>>>
>>> Inactive hide details for BJ Hargrave---09/03/2008 02:04:43 PM---But
>>> even DS only knows about started bundles. If a bundle is sBJ
>>> Hargrave---09/03/2008 02:04:43 PM---But even DS only knows about started
>>> bundles. If a bundle is started after DS has processed some bundle, then
>>> new services can
>>>
>>>
>>> From:
>>>
>>>
>>>
>>>
>>> BJ Hargrave/Austin/IBM@IBMUS
>>>
>>>
>>> To:
>>>
>>>
>>>
>>>
>>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>>
>>>
>>> Date:
>>>
>>>
>>>
>>>
>>> 09/03/2008 02:04 PM
>>>
>>>
>>> Subject:
>>>
>>>
>>>
>>>
>>> RE: [equinox-dev] When is DS done loading services?
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>> But even DS only knows about started bundles. If a bundle is started
>>> after DS has processed some bundle, then new services can be registered.
>>> There is no way for DS to know about all possible services being ready
>>> since some may come from bundles yet to be started. The best DS could
>>> tell you is that it is done processing services from bundles that are
>>> currently started.
>>>
>>> It is far better in the long run for the application to handle dynamism.
>>> Anything you do today to try and enforce some ordering will likely fail
>>> in the future when some thing changes about the set of installed
>>> bundles.
>>>
>>> --
>>>
>>> *BJ Hargrave*
>>> Senior Technical Staff Member, IBM
>>> OSGi Fellow and CTO of the OSGi Alliance <http://www.osgi.org/>_
>>> _hargrave@xxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>
>>>
>>>
>>>
>>>
>>> office: +1 386 848 1781
>>> mobile: +1 386 848 3788
>>>
>>>
>>>
>>>
>>> From:
>>>
>>>
>>>
>>> "Cortez, Otto" <OttoCortez@xxxxxxxxxxxxx>
>>>
>>> To:
>>>
>>>
>>>
>>> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>>>
>>> Date:
>>>
>>>
>>>
>>> 2008/09/03 02:48 PM
>>>
>>> Subject:
>>>
>>>
>>>
>>> RE: [equinox-dev] When is DS done loading services?
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> It is more important for us to know what functionality is installed and
>>> available before parts of the application execute then it is for us to
>>> support dynamism. I would like to keep the dynamism if we can, but to do
>>> that and provide reliable execution I think the application would need
>>> to guarantee that all services known through the bundle manifests will
>>> be initialized before we start processing. I guess using extensions
>>> might be a better fit.
>>>
>>> I’m not sure if we need DS to synchronously register services as much as
>>> some way to listen to DS events or know its state, like is it just
>>> sitting around waiting for more bundles to be activated or deactivated.
>>> I was focused on services being managed by DS since I thought DS would
>>> know weather it was done initializing all services listed in the active
>>> bundles’ manifest files and then we would be able to say to users which
>>> may supply functionality, well if you use DS then we could guarantee
>>> that we wouldn’t start until DS had initialized your services.
>>>
>>> Thanks,
>>> Otto
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *
>>> From:* equinox-dev-bounces@xxxxxxxxxxx
>>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] *On Behalf Of *BJ Hargrave*
>>> Sent:* Wednesday, September 03, 2008 7:22 AM*
>>> To:* Equinox development mailing list*
>>> Subject:* Re: [equinox-dev] When is DS done loading services?
>>>
>>>
>>> The whole point of services is that the are dynamic. The fact the DS is
>>> "processing" them on behalf of some bundle does not mean that another
>>> bundle should know or observe that.
>>>
>>> Bundles which depend upon a service need to deal with that service's
>>> dynamism. You can't assume a bundle's activator or starting a bundle
>>> will synchronously register some services. I would not support an option
>>> for DS to synchronously register services during bundle start as this
>>> means people will improperly use that.
>>>
>>> You may also be seeing an impedance mismatch between the lifecycle of
>>> extensions and services. Extensions become active when the bundle is
>>> resolved while services become active only when the bundle is started.
>>> Switching to use extensions will not allow for dynamism (unless you want
>>> to write all the code to use the extension registry API to do so.)
>>>
>>> You may be able to use startlevels to mitigate the issue (make sure all
>>> bundles providing service B are started before bundles using B), but
>>> this is also a hack. It would be better if service A dealt with the
>>> dynamics of service B such that service A has a dynamic dependency on
>>> service B and is able to accept B's being registered and unregistered at
>>> any time.
>>> --
>>>
>>> *BJ Hargrave*
>>> Senior Technical Staff Member, IBM
>>> OSGi Fellow and CTO of the OSGi Alliance <http://www.osgi.org/>_
>>> _hargrave@xxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>
>>>
>>>
>>>
>>>
>>> office: +1 386 848 1781
>>> mobile: +1 386 848 3788
>>>
>>>
>>>
>>> From:
>>>
>>>
>>>
>>> Stoyan Boshev <s.boshev@xxxxxxxxxxx>
>>>
>>> To:
>>>
>>>
>>>
>>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>>
>>> Date:
>>>
>>>
>>>
>>> 2008/09/03 07:51 AM
>>>
>>> Subject:
>>>
>>>
>>>
>>> Re: [equinox-dev] When is DS done loading services?
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi Otto,
>>> I guess your problem is connected to the asynchronous processing of the
>>> DS services.
>>> As far as I understand the situation is: your application bundles are
>>> started, then your application is started but at this moment not all of
>>> the DS services are inited yet because they are being asynchronously
>>> processed.
>>>
>>> Unfortunately currently there is no way to find out when DS completes
>>> the DS services processing.
>>> I think if there was an option that DS bundle process the DS services in
>>> the started bundles synchronously, it would solve your problem. So I
>>> will open bug(enhancement) about that and hopefully this will be
>>> implemented soon.
>>> As a possible workaround you could observe the running threads and when
>>> the thread with name "Component Resolve Thread" disappears this would
>>> mean that DS bundle has no more work to do and eventually all of your DS
>>> services are processed. I realize this is not a clean solution (that's
>>> why I call it workaround) but at this moment I cannot find out a more
>>> appropriate working solution without modifications in the DS bundle.
>>>
>>> Stoyan
>>>
>>>
>>> Cortez, Otto wrote:
>>>
>>>> I made a post to the Eclipse newcomers group a few weeks ago, but did
>>>> not get a response. I don’t know if this is the appropriate place for
>>>> this question, but hopefully someone can point me in the right
>>>> direction.
>>>>
>>>>
>>>>
>>>> We are building a headless RCP application and we would like to use DS
>>>> to make functionality available. The problem we are running into is
>>>> that not all of the services we declared through DS get loaded and are
>>>> visible before our application executes.
>>>>
>>>>
>>>>
>>>> For example, I have a service A which needs 0..n instances of another
>>>> service B. The issue I'm running into is that if the implementations of
>>>> service B are spread across several bundles, then the service A will
>>>> not
>>>> have seen all instances of service B when it is called since the
>>>> application starts (and sometimes ends) running before DS is done
>>>> looking through all the bundles and registering all the services in the
>>>> active bundles.
>>>>
>>>> Is there a way to know when declarative services is done looking
>>>> through
>>>> the active bundles and loading the services found in them? Am I missing
>>>> something?
>>>>
>>>>
>>>>
>>>> It seems that using the plug-in registry may solve this issue. Is that
>>>> perhaps a better way to go?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Otto
>>>>
>>>> This email and any files transmitted with it are confidential,
>>>> proprietary
>>>> and intended solely for the individual or entity to whom they are
>>>>
>>> addressed.
>>>
>>>> If you have received this email in error please delete it immediately.
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>
>>> --
>>> ---------------------------------------------------------
>>> dipl. eng. Stoyan Boshev . Department manager
>>> ProSyst Labs EOOD
>>> 1606 Sofia, Bulgaria . 48 Vladajska Str.
>>> Tel. +359 2 953 05 88; Fax +359 2 953 26 17
>>> Mobile: +359 88 898 29 17_
>>> _http://www.prosyst.com <http://www.prosyst.com/> . s.boshev@xxxxxxxxxxx
>>> ---------------------------------------------------------
>>> stay in touch with your product
>>> ---------------------------------------------------------
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@eclipse.org_
>>> _https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>> This email and any files transmitted with it are confidential,
>>> proprietary
>>> and intended solely for the individual or entity to whom they are
>>> addressed.
>>> If you have received this email in error please delete it immediately.
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@eclipse.org_
>>> _https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________
>>>
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>> This email and any files transmitted with it are confidential,
>>> proprietary
>>> and intended solely for the individual or entity to whom they are
>>> addressed.
>>> If you have received this email in error please delete it immediately.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
