Oleg Besedin wrote:
Did you say why you cannot install your plugins in a lower start level?
IMHO, reliance on a start levels should be avoided:
- start levels don't scale if you are putting together an application
that combines features created by separate development teams (i.e.,
Feature
As to the question of DS, let's not forget that it is just an
instrument. From what I understand, its goal is to help developers
work around OSGi complexities. If it does not help, it needs to be
fixed.
I am all for fixing DS if it is flawed. But your argument against using
startlevel can
, 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
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *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
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
BJ Hargrave wrote:
As to the question of DS, let's not forget that it is just an
Richard S. Hall wrote:
I don't think that what I said makes any assumptions about knowing the
exact dependencies. I think my point agrees with what you are saying,
which is that you have to wait for all plugins to start up (including
waiting for their dependencies on each other to be
Danail Nachev wrote:
Richard S. Hall wrote:
I don't think that what I said makes any assumptions about knowing the
exact dependencies. I think my point agrees with what you are saying,
which is that you have to wait for all plugins to start up (including
waiting for their dependencies on
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
Richard S. Hall wrote:
Danail Nachev wrote:
Richard S. Hall wrote:
I don't think
I feel that changing DS to perform service registration synchronous
with
bundle activation will likely result in deadlocks when there are
complex
service dependency graphs.
This won't be any different from what is done now manually. The
potential for deadlocks are there regardless of
Danail Nachev wrote:
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-
stay in touch with your product.
-
Richard S. Hall wrote:
Danail Nachev wrote:
Richard S.
BJ Hargrave wrote:
I feel that changing DS to perform service registration synchronous
with
bundle activation will likely result in deadlocks when there are
complex
service dependency graphs.
This won't be any different from what is done now manually. The
potential for
I totally agree. This is what I actually wanted in the very beginning of
this thread.
OK, but I certainly did not understand that at the beginning :-)
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
:
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
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
:
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
:RE: [equinox-dev] When is DS done loading services?
But even DS only knows about started bundles
16 matches
Mail list logo