[equinox-dev] +1 for Markus Keller on rt.equinox.bundles by Stoyan Boshev
Stoyan Boshev voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Lazar Kirchev on rt.equinox.bundles by Stoyan Boshev
Stoyan Boshev voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Glyn Normington on rt.equinox.bundles by Stoyan Boshev
Stoyan Boshev voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Borislav Kapukaranov on rt.equinox.bundles by Stoyan Boshev
Stoyan Boshev voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for John W Ross on rt.equinox.bundles by Stoyan Boshev
Stoyan Boshev voted: +1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS and bundle stop/start
BJ Hargrave wrote: Why doesn't DS just asynchronously process bundles which are lazy activated (not lazy started which is an incorrect term)? Then you have the same behavior (async processing) regardless of whether the bundle is lazily or eagerly activated. The DS components of activated bundles are processed by DS when it receives BundleEvent.STARTED (for normal activated bundles) or BundleEvent.LAZY_ACTIVATION (for lazy activated bundles). These events are processed in DS by a SynchronousBundleListener. Actually DS processes synchronously the components in both cases. The difference comes with the fact that BundleEvent.STARTED is sent by the framework after the bundle's activator is started. We cannot modify DS to process only BundleEvent.STARTED because in this case lazy activated bundles will not be processed at all. What we can do in DS is to process the DS components of a bundle when DS receives BundleEvent.STARTING event instead of BundleEvent.STARTED. This way DS will process the components before the framework calls the bundle activator's start method and the behavior would be similar to the one when processing lazy activated bundles. However, the DS specification always speaks of DS processing started bundles. So, I am not sure whether it is appropriate to process the DS components of a bundle before it is fully started. Stoyan -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_ __hargr...@us.ibm.com_ <mailto:hargr...@us.ibm.com> office: +1 386 848 1781 mobile: +1 386 848 3788 From: John Arthorne To: equinox-dev@eclipse.org Date: 2009/10/26 14:32 Subject:[equinox-dev] DS and bundle stop/start Sent by:equinox-dev-boun...@eclipse.org I came across an interesting problem today involving DS and expicitly starting/stopping bundles. After chatting with Tom he suggested I raise it here for general awareness and to discuss whether the behaviour makes sense. In various places in p2 today we explicitly start bundles for various reasons. We typically use Bundle.start(Bundle.START_TRANSIENT) for this purpose. We are starting to use DS in p2 today, and we have a few places where a bundle acquires a service that it registered via DS in its own BundleActivator.start method. It turns out that DS only processes/starts service components synchronously for bundles that are lazy started. If you start a bundle explicitly the DS processing occurs asynchronously, and as a result the services provided via DS are not available at the time the bundle starts. The result is subtlely different bundle behaviour (or outright failures), if a bundle is started explicitly via Bundle#start versus implicitly via lazy activation: 1) Lazy start case: a) bundle's service component is processed and services provided by the component are registered by DS b) bundle activator starts, and can use services registered in 1a) 2) Activation via Bundle.start(Bundle.START_TRANSIENT): a) bundle's activator starts, and services are not yet available b) bundle's service component is processed and services provided by the component are registered by DS It turns out there is a coding pattern that can be used to make the explicit start case match the lazy start case: *final* Bundle bundle = ...;//get some bundle bundle.start(Bundle.START_ACTIVATION_POLICY); bundle.start(Bundle.START_TRANSIENT); The call to start(Bundle.START_ACTIVATION_POLICY) causes DS to process the bundle and register its component services, but does not start the bundle. The second call to start with Bundle.START_TRANSIENT actually starts the bundle. The moral of the story seems to be that we need to use this "double start" coding pattern anywhere we are starting bundles, because those bundles might be using DS and relying on the activation order. Or, perhaps someone has a suggestion for changes that can be made to the framework or DS so that these cases behave consistently... John___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org 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 . s.bos...@prosyst.com -
[equinox-dev] +1 for Scott Lewis on rt.equinox.incubator
+1 +1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Meaning of a SCR warning message
Hi Michael,
This message means there is a duplicate attempt for binding a service to
a component instance.
Can you reproduce this every time you run your application or it just
happened once?
Does your component have more than one references and at least two of
them are satisfied by one service object (one service object
implementing multiple interfaces)?
I reviewed the DS code and I think the most possible reason for this
warning might be that your component has more than one references and
their interfaces are implemented by one service object. This way SCR
will attempt to bind one and the same ServiceReference object for one
component instance more than once (depending on the count of component
references covered by the ServiceReference's interfaces). I think this
warning is not needed since this is a pretty standard situation. It
should be removed or transformed into a debug message.
If the reason for the warning is the one I described above, you should
not worry about it and you should ignore it.
Stoyan
Michael Furtak wrote:
Hi all,
I am receiving a warning from the DS SCR that reads:
WARNING 11 [SCR] ComponentReference.bind(): service reference {...} is
already bound to instance
org.eclipse.equinox.internal.ds.impl.componentinstancei...@11c55bb
I am not sure what this means or how to go about resolving it. Can
anyone share some insight?
Thanks,
-Mike Furtak
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the
intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please
delete the message and notify the sender so that we may correct our
records.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Determine missing references of a declarative service
There is a console command you could use for that purpose. You should list the DS components with "list" command. Then you can require detail info for a component in the list by typing "component ", where is the component number in the list. You will get static and dynamic information. The unsatisfied references are shown in the dynamic information. Stoyan Kirchev, Lazar wrote: Hello, We are using DS and we need to find missing references of a declarative service. There is no console command to provide this info. Is there some way to achieve this non-programatically? Regards, Lazar ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS activation and error logging
Thomas Watson wrote: > From: > > "Michael Furtak" > > > That is my understanding as well. So I guess what I am wondering is: > > Given the set of Equinox bundles I described (including > org.eclipse.equinox.log), I am not seeing a log file produced or an > exception logged when my run configuration contains very few bundles. Is > my component activation exception perhaps winning a race between the SCR > activation process and the SCR's acquiring of a LogService? > > The LogService does not actually persist the logged events to file. That is left up to a log listener to decide how to persist the log. This is a hint to DS bundle users. It is not very convenient to read the logs when you need to see the problems with DS components. I would suggest to turn on the "print_on_console" trace option of DS bundle. This will show any errors and warnings coming from SCR in the console. It is quite easy to see the problems with your DS components. Another way to turn this feature on is by using the system property "equinox.ds.print=true" Stoyan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS activation and error logging
Michael Furtak wrote: << This behavior is not against the DS spec. In fact it is not described what shall be done in such cases. I think the current behavior is more appropriate than blacklisting the component and never activate it again. Perhaps there should be a limited number of tries for activation and/or timeout for each subsequent activation try. But this seems like a feature request. Ideally this should go also as a DS spec update. I will post an issue to OSGi about that. I agree that the DS spec is not overly expressive with regard to how components that fail to instantiate should be treated. If the activate() method throws an exception it simply says that, "the component configuration is not activated." How would you describe the current algorithm for activation retries? Is it attempting to activate a failed component every time the service space changes? Yes. When a service is registered or modified, SCR scans for newly satisfied components and activates them. The unsuccessfully activated components in previous loops, if they are still satisfied, happen to be in this components list and will be processed for activation by SCR. Stoyan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS activation and error logging
Thomas Watson wrote: > From: > > Stoyan Boshev > > > The DS spec requires that errors and warnings are logged by SCR via the > LogService if available. In your configuration it is provided by the > org.eclipse.equinox.log bundle. If your environment does not have > LogService then you will not be able to see any errors from SCR. > Perhaps the implementation should at least write to System.err when the log service is not available? I agree. This should be better than swallowing the errors. Could you open a new issue about that? ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS activation and error logging
Comments inlined
Michael Furtak wrote:
Hi all,
I have recently upgraded to the release candidate versions of Equinox
3.5 and am seeing some unexpected behavior from DS.
The first question I have is in regard to component activation. In the
RC versions I have noticed that if an exception is thrown in the
activate() method, the SCR will attempt to instantiate the component
again, a variable number of times. As far as I can tell, this number of
times seems to be related to how many other bundles
(components/services) are activated within the framework.
So, for example:
protected void activate(ComponentContext context)
{
System.out.println(“Failing activation”);
throw new RuntimeException();
}
“Failing activation” will be printed once for a run configuration that
includes that bundle, the OSGi bundles, and nothing else. However, if a
number of other bundles are activated, it can appear more than once. Is
the SCR attempting to start this bundle repeatedly? If so, does that
behavior jive with the specification? This behavior is new to the 3.5
releases, and did not occur in 3.4.2.
This behavior is not against the DS spec. In fact it is not described
what shall be done in such cases.
I think the current behavior is more appropriate than blacklisting the
component and never activate it again.
Perhaps there should be a limited number of tries for activation and/or
timeout for each subsequent activation try. But this seems like a
feature request. Ideally this should go also as a DS spec update. I will
post an issue to OSGi about that.
The second question I have is regarding the exception logging behavior
of DS. What has been doubly confusing about this simple example
situation is that I am not seeing any report about the exception thrown
in the activate() method. No log file is generated in the configuration
directory, and no stack trace is printed to the console. (I’m using the
–consoleLog program argument). The strange thing is that if I use a much
more complex run configuration with many bundles using DS, I can slip an
exception into the activate() method of one of them and I will see the
log file and console statements generated.
The set of Equinox jars I am using is (3.5 RC4):
org.eclipse.equinox.ds_1.1.0.v20090601.jar
org.eclipse.equinox.event_1.1.100.v20090520-1800.jar
org.eclipse.equinox.log_1.2.0.v20090520-1800.jar
org.eclipse.equinox.util_1.0.100.v20090520-1800.jar
org.eclipse.osgi.services_3.2.0.v20090520-1800.jar
org.eclipse.osgi.util_3.2.0.v20090520-1800.jar
org.eclipse.osgi_3.5.0.v20090520.jar
Program arguments are:
-console –consoleLog
The DS spec requires that errors and warnings are logged by SCR via the
LogService if available. In your configuration it is provided by the
org.eclipse.equinox.log bundle. If your environment does not have
LogService then you will not be able to see any errors from SCR.
Any thoughts or advice would be appreciated.
Thanks,
-Mike Furtak
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL
AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the
intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please
delete the message and notify the sender so that we may correct our
records.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] SCRManager
Scott Lewis wrote: Question about the SCRManager class in the org.eclipse.equinox.ds declarative services implementation: Is there any way to get at the SCRManager instance programmatically? That is, there is already a command provider that allows console access to the SCRManager (and the ServiceComponents, etc), but is there any service made available for other bundles to access the SCRManager? AFAICT by quick examination of the source, the answer is currently 'no', but would there be some possibility of having such programmatic access in the future? Should an enhancement request be opened? Indeed, now the SCR core is not programmatically accessible. Please open an enhancement request about this. The desire here would be to write some management interfaces/UI that would allow the service component state to be queried (like the SCRCommandProvider does now). This is really an interesting use case. In the ideal case the access to SCR should be done via a service specified by the DS specification. This would allow you to manage the DS components regardless of the SCR implementation. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev Regards, Stoyan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox Declarative Services : Context Class Loader
You should get the latest Equinox 3.5 bundles. The latest stable release is Equinox 3.5M6. I am afraid you will not be able to update only the two bundles because their requirements have changed and they will not run on Equinox 3.4. The best case would be to switch to Equinox 3.5 if possible. Stoyan Sameera Jayasoma wrote: Hi Stoyan, Here are the exact versions of the bundles I am using. org.eclipse.equinox.ds-1.0.0.v20080427-0830.jar org.eclipse.equinox.util-1.0.0.v20080414.jar Can you please tell me versions of the bundle I should use in order to overcome this issue? Thanks Sameera Sameera Stoyan Sameera Jayasoma wrote: Hi all I am using Equinox Declarative Services implementation. When my component gets activated, the “activate” method is invoked on the component implementation class and that is expected behavior. But the context class loader of the thread which invoke the “activate” method is null. I am having problems because of this. Is this the expected behavior in the DS implementation? Any help would be greatly appreciated. Thanks -- Sameera Jayasoma ___ equinox-dev mailing list equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org> 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 . s.bos...@prosyst.com <mailto:s.bos...@prosyst.com> - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org> https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org 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 . s.bos...@prosyst.com - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox Declarative Services : Context Class Loader
Hi Sameera, This was reported and fixed 4 months ago in Equinox 3.5. Which version of org.eclipse.equinox.ds and org.eclipse.equinox.util bundles do you use? Stoyan Sameera Jayasoma wrote: Hi all I am using Equinox Declarative Services implementation. When my component gets activated, the “activate” method is invoked on the component implementation class and that is expected behavior. But the context class loader of the thread which invoke the “activate” method is null. I am having problems because of this. Is this the expected behavior in the DS implementation? Any help would be greatly appreciated. Thanks -- Sameera Jayasoma ___ equinox-dev mailing list equinox-dev@eclipse.org 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 . s.bos...@prosyst.com - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] querying the state of declarative services.
Fredrik Alströmer wrote: Hi, is there any API in the Equinox implementation of declarative services which can be used to query the current state? With state I mean, which are the services known to the SCR, and of those which are not active, which are not satisfied, and of those which are not satisfied, why are they not? Currently there is no API for doing that. If there's no such API, is there a bug report related to this? (A quick search revealed two bugs, enhancements, total concerning declarative services). I'm asking because currently, it's not very convenient to find out why a service isn't active, or even if it is active. Turning on debugging and wading through the slightly cryptic log messages is, although certainly possible in small scale, not really feasible. There is no API, but there are console commands that you could use for the purpose you describe. Any help / comments would be greatly appreciated. Thanks, Fredrik. ___ equinox-dev mailing list equinox-dev@eclipse.org 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 . s.bos...@prosyst.com - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Wire Admin Bug
Please, report a bug here:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox
Later the bug will be reviewed and fixed. If you have already a working
solution (i.e. you have already fixed it) I will appreciate if you can
add a patch to the bug as well.
Stoyan
Alexander Shutyaev wrote:
Hi, all! I started using Wire Admin service, met some problems
concerning wire scopes.
My Producer has "mail.john" in scope, and my Consumer has "mail.*". But
when I connect them with a Wire the resulting scope is empty.
I checked out the specification and the Equinox Wire Admin
implementation source code. It seems like there is a bug, and a wrong
specification implementation.
Section 108.6.5 "Scope name syntax" of the specification says:
Scope names are normal String objects and can, in principle, contain any
Unicode character. Scope names are used with the WirePermission class
that extends java.security.BasicPermission. The BasicPermission class
implements the implies method and performs the name matching. The
wildcard matching of this class is based on the concept of names where the
constituents of the name are separated with a period ('.'): for example,
org.osgi.service.http.port.
If we look into the source code (WireImpl.java:270) [1] we'll see that
name matching for scopes is performed incorrectly (the '*' wildcard is
processed only when it makes up the whole string).
Can you confirm that this is an error and what do I need to do to have
it fixed?
Thanks in advance..
[1]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.wireadmin/src/org/eclipse/equinox/internal/wireadmin/WireImpl.java?revision=1.1&root=RT_Project
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] When is DS done loading services?
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 deadlocks are there regardless of DS.
>
Perhaps, but at least we are not building it into the DS spec or the DS
impl!
> >
> > One possible way to deal with this is through the use of component
> > enablement. Using the original example of service A depending upon some
> > number of service B, if you can know when all the service Bs are
> > available, one can write a component with a dynamic dependency on B.
> > When all the Bs are available then enable the component providing
> > service A (which are declared disabled in its description). The
trick is
> > of course to be able to know when all the service Bs are available such
> > that we are ready to enable serviceA.
>
> And we are back to the core problem: we cannot be sure when all service
> Bs are available.
How can you ever be sure? :-) Unless there is some definition of the
expected set of Bs, it is just random.
> In code which doesn't use DS, start() method will
> serve as a boundary for the service changes - satisfied services will be
> registered while the bundle is starting and any services which becomes
> satisfied will be registered synchronously (the latter is the current
> behavior of DS).
This makes the assumption that bundle will always register their B
during BundleActivator execution. I think this is a fairly tall
assumption. What if a bundle's B depends upon something which is not yet
available? It is very bad form to block the BundleActivator. So such a
bundle, if well behaved, would have to return from the BundleActivator
w/o having registered B and delay registering B until the dependency is
met some time later.
> After all the bundles are activated, we can be sure
> that all services which doesn't depend on external factors will be
> available and the system can be considered ready.
>
You assume ("all services which doesn't depend on external factors")
that all B's have no dependencies and can be registered at will. That is
a pretty big assumption.
Perhaps one thing a DS impl could do, is to register all services for
which all dependencies are currently met synchronously during bundle
activation. All other services would have to handled asynchronously.
This splits the DS work between work that can be quickly done during
bundle activation and work that will take time which is done after
bundle activation. I don't think any change to the DS spec is needed to
allow this behavior.
I totally agree. This is what I actually wanted in the very beginning of
this thread.
--
*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
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 . [EMAIL PROTECTED]
-
stay in touch with your product
-
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
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@eclipse.org 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 . [EMAIL PROTECTED] - stay in touch with your product - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] SCR debug output
You can see in the console only warnings and errors logged by SCR by just setting the "equinox.ds.print" property to "true" and "equinox.ds.debug" to "false". You will see errors that occur in the activities of SCR like processing component descriptions, calling activate/deactivate and bind/unbind methods of components, etc. You will probably not see error in case any service reference is not resolved unless it is caused by a bad component description. Your suggestion about console commads interacting with SCR is very interesting and might help a user to investigate problems with his/her components. But unfortunately there are no console commands for that purpose. Can you please open a bug about that? Regards, Stoyan - Original Message - From: Michael Furtak To: Equinox development mailing list Sent: Tuesday, April 15, 2008 6:34 PM Subject: RE: [equinox-dev] SCR debug output Hi Stoyan, Thanks very much! It's worth noting that the flags didn't seem to be in the latest official release (3.3.2). I had downloaded the 3.4M6a milestone build, though, and got the output you described. Regarding that output, though, I still wasn't able to easily detect the kind of error I frequently run into. The scenario is generally like: Service A references many services (B, C, and D, etc.) all with 1..1 cardinality. Somewhere along the way I figure out that Service A is not activating, but I have no idea which reference is not being resolved (Let's say it's B). So, what I notice are statements like "DEBUG ## Resolver.resolveEligible(): reference 'Service B' of component 'Service A' is not resolved" that show up in many places as the Resolver attempts to do its work. However, these messages are at a DEBUG level, and there are a lot of them. Additionally, I suppose you could say that B may be just about to be introduced, so it's not really concerning that it doesn't exist yet. At any rate, there's a lot of noise to sort through to try to understand why Service A is not present. So I am wondering if you have any other suggestions for how to quickly identify this kind of problem? Might there be console commands that can interact with the SCR to list services that are left unactivated due to unresolved references? If not, would it be a plausible thing for me to write? Thanks, -Mike Furtak THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. ------ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Boshev Sent: Tuesday, April 15, 2008 3:36 AM To: equinox-dev@eclipse.org Subject: Re: [equinox-dev] SCR debug output Hi Michael, You can use these boolean system properties: equinox.ds.debug - Turns on/off debugging of SCR equinox.ds.print - Specifies that logged entries should be printed to the framework runtime console equinox.ds.perf - Enables generating and printing logs about the time performance of the operations executed by the SCR (Useful when the user is interested in the time that is spent in the bind, activate, deactivate methods of his components) I would recommend you to use both equinox.ds.debug and equinox.ds.print properties set to "true" because you will see the debug messages printed in the console. If you turn on only the equinox.ds.debug property, the debug messages will be sent only to the LogService if available. Stoyan - Original Message - From: Michael Furtak To: equinox-dev@eclipse.org Sent: Monday, April 14, 2008 9:03 PM Subject: [equinox-dev] SCR debug output Hi, I frequently find myself in a position of trying to debug why my declarative services are not running. Is there debug output from the SCR that I could be taking advantage of to help this process? If so, what combination of bundles and settings are required to see it? Thanks, -Mike Furtak THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. _
Re: [equinox-dev] SCR debug output
Hi Michael, You can use these boolean system properties: equinox.ds.debug - Turns on/off debugging of SCR equinox.ds.print - Specifies that logged entries should be printed to the framework runtime console equinox.ds.perf - Enables generating and printing logs about the time performance of the operations executed by the SCR (Useful when the user is interested in the time that is spent in the bind, activate, deactivate methods of his components) I would recommend you to use both equinox.ds.debug and equinox.ds.print properties set to "true" because you will see the debug messages printed in the console. If you turn on only the equinox.ds.debug property, the debug messages will be sent only to the LogService if available. Stoyan - Original Message - From: Michael Furtak To: equinox-dev@eclipse.org Sent: Monday, April 14, 2008 9:03 PM Subject: [equinox-dev] SCR debug output Hi, I frequently find myself in a position of trying to debug why my declarative services are not running. Is there debug output from the SCR that I could be taking advantage of to help this process? If so, what combination of bundles and settings are required to see it? Thanks, -Mike Furtak THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. __ NOD32 3025 (20080414) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev __ NOD32 3025 (20080414) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Neil Bartlett
+1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Boris Bokowski
+1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS exception in activate method
I have recently raised the same question in OSGi. It was decided that in this case only "unbind()" methods will be called. The OSGi specification will contain clarification about that in its next release. Regards, Stoyan - Original Message - From: Lukasz Bobowiec To: equinox-dev@eclipse.org Sent: Tuesday, February 19, 2008 6:56 PM Subject: [equinox-dev] DS exception in activate method Hello, I have not found in the OSGi r4 compendium what is the behaviour when an exception is raised in the activate(ComponentContext context) method in a component which is managed by Declarative Services. Does "deactivate()" should be invoked? or only "unbind()" methods? The specification should be more specific in this case. Could you provide me this information? BTW I found that in the old DS equinox implementation no action was taken. However in the ProSyst contribution "unbind()" is invoked on the component instance. --- Best regards, Lukasz Bobowiec Software Engineer, Common Agent Services [EMAIL PROTECTED] (+48 12) 628 9882 IBM SWG Lab, Cracow, Poland IBM Polska Sp. z o.o. oddział w Krakowie ul. Armii Krajowej 18 30 -150 Kraków NIP: 526-030-07-24 Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS KRS 012941, Kapitał zakładowy: 3.073.600 PLN -- ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev __ NOD32 2886 (20080219) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Graduation of Prosyst contributed bundles
Prosyst would like to graduate all of the listed bundles because: - all of them, except for the util bundle, are implementations of OSGi services. Perhaps sooner or later the community might need them - we will support these bundles in the Equinox-Bundles component Concerning your comment about the public API in the util bundle I suggest we continue the discussion in the bug you have opened. Stoyan - Original Message - From: Thomas Watson To: equinox-dev@eclipse.org Sent: Monday, October 15, 2007 5:21 PM Subject: [equinox-dev] Graduation of Prosyst contributed bundles The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services questions
Sorry for my previous email with no actual response! I have sent it by mistake. Please, find my comments below. Best regards, Stoyan - Original Message - From: Jan Stette To: Equinox development mailing list Sent: Tuesday, August 07, 2007 8:12 PM Subject: Re: [equinox-dev] Declarative Services questions Hi Stoyan, we have resolved the problem we were having getting configs through the ComponentContext - there was a mismatch between the component name we were using and the PID that the config was registered with in the Config Admin service. So our mistake! How should we go about raising bugs like the synchronous nature of activateComponent/deactivateComponent? (This one isn't important for us now by the way) The bug tracker is here : https://bugs.eclipse.org/bugs/ You should click on "Report new bug" and then follow the instructions. I could report this bug for you if you don't mind :) One more question: what is the status of the equinox.component bundle in the Equinox incubator at the moment, is it undergoing active development? Are there any roadmaps or rough plans for future releases? According to me, the DS implementation is in pretty complete state. It is beeing tested and the bugs found are being fixed. I don't really know what is the procedure for passing the incubator state and when it would be officialy released. Perhaps someone else could put some light on this? Regards, Jan On 07/08/07, Stoyan Boshev <[EMAIL PROTECTED]> wrote: Hi Jan, >Do you instead rely on getting configuration from the ComponentContext in >activate() methods? The OSGi spec suggests this should work, but it doesn't >appear to be the case with the ProSyst DS implementation anyway. Could you be more specific here? Do you mean that you use ComponentContext.locateService(...) to get Config Admin service? There was a bug in DS exactly in this scenario but it is already fixed (committed on 09.07.07). >(Another discrepancy we've seen in this DS implementation is that calls to >ComponentContext.disableComponent() and enabledComponent() cause >deactivation/activation on the named component to happen synchronously, not >asynchronously as the spec states) Agree. This is a bug and should be reported. Cheers, Stoyan Jan Stette-2 wrote: > > Dear all, > > I'd like to ask anyone on this list: is there anyone out there who is > using > Declarative Services with Equinox in anger? On my current project, we > have > tried to introduce it but have come across some problems. > > First of all, we're using the ProSyst implementation. While we realise > this > is classified as "not release-ready" [ > http://www.eclipsezone.com/eclipse/forums/t97348.html], this is the best > implementation we've found so far. Or is there another, better one out > there? > > My main question is: how do you implement services that are both > declarative, and that also rely on config from the Config Admin service? > We've tried making services both DeclaredComponents and ManagedServices > but > the interaction between the two is hard to manage. > Do you instead rely on getting configuration from the ComponentContext in > activate() methods? The OSGi spec suggests this should work, but it > doesn't > appear to be the case with the ProSyst DS implementation anyway. > > (Another discrepancy we've seen in this DS implementation is that calls to > ComponentContext.disableComponent() and enabledComponent() cause > deactivation/activation on the named component to happen synchronously, > not > asynchronously as the spec states) > > Any suggestions would be most welcome. > > Regards, > Jan > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > -- View this message in context: http://www.nabble.com/Declarative-Services-questions-tf4193314.html#a12038051 Sent from the Equinox - Dev mailing list archive at Nabble.com. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services questions
- 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 . [EMAIL PROTECTED] - stay in touch with your product - - Original Message - From: Jan Stette To: Equinox development mailing list Sent: Tuesday, August 07, 2007 8:12 PM Subject: Re: [equinox-dev] Declarative Services questions Hi Stoyan, we have resolved the problem we were having getting configs through the ComponentContext - there was a mismatch between the component name we were using and the PID that the config was registered with in the Config Admin service. So our mistake! How should we go about raising bugs like the synchronous nature of activateComponent/deactivateComponent? (This one isn't important for us now by the way) One more question: what is the status of the equinox.component bundle in the Equinox incubator at the moment, is it undergoing active development? Are there any roadmaps or rough plans for future releases? Regards, Jan On 07/08/07, Stoyan Boshev <[EMAIL PROTECTED]> wrote: Hi Jan, >Do you instead rely on getting configuration from the ComponentContext in >activate() methods? The OSGi spec suggests this should work, but it doesn't >appear to be the case with the ProSyst DS implementation anyway. Could you be more specific here? Do you mean that you use ComponentContext.locateService(...) to get Config Admin service? There was a bug in DS exactly in this scenario but it is already fixed (committed on 09.07.07). >(Another discrepancy we've seen in this DS implementation is that calls to >ComponentContext.disableComponent() and enabledComponent() cause >deactivation/activation on the named component to happen synchronously, not >asynchronously as the spec states) Agree. This is a bug and should be reported. Cheers, Stoyan Jan Stette-2 wrote: > > Dear all, > > I'd like to ask anyone on this list: is there anyone out there who is > using > Declarative Services with Equinox in anger? On my current project, we > have > tried to introduce it but have come across some problems. > > First of all, we're using the ProSyst implementation. While we realise > this > is classified as "not release-ready" [ > http://www.eclipsezone.com/eclipse/forums/t97348.html], this is the best > implementation we've found so far. Or is there another, better one out > there? > > My main question is: how do you implement services that are both > declarative, and that also rely on config from the Config Admin service? > We've tried making services both DeclaredComponents and ManagedServices > but > the interaction between the two is hard to manage. > Do you instead rely on getting configuration from the ComponentContext in > activate() methods? The OSGi spec suggests this should work, but it > doesn't > appear to be the case with the ProSyst DS implementation anyway. > > (Another discrepancy we've seen in this DS implementation is that calls to > ComponentContext.disableComponent() and enabledComponent() cause > deactivation/activation on the named component to happen synchronously, > not > asynchronously as the spec states) > > Any suggestions would be most welcome. > > Regards, > Jan > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > -- View this message in context: http://www.nabble.com/Declarative-Services-questions-tf4193314.html#a12038051 Sent from the Equinox - Dev mailing list archive at Nabble.com. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services questions
Hi Jan, >Do you instead rely on getting configuration from the ComponentContext in >activate() methods? The OSGi spec suggests this should work, but it doesn't >appear to be the case with the ProSyst DS implementation anyway. Could you be more specific here? Do you mean that you use ComponentContext.locateService(...) to get Config Admin service? There was a bug in DS exactly in this scenario but it is already fixed (committed on 09.07.07). >(Another discrepancy we've seen in this DS implementation is that calls to >ComponentContext.disableComponent() and enabledComponent() cause >deactivation/activation on the named component to happen synchronously, not >asynchronously as the spec states) Agree. This is a bug and should be reported. Cheers, Stoyan Jan Stette-2 wrote: > > Dear all, > > I'd like to ask anyone on this list: is there anyone out there who is > using > Declarative Services with Equinox in anger? On my current project, we > have > tried to introduce it but have come across some problems. > > First of all, we're using the ProSyst implementation. While we realise > this > is classified as "not release-ready" [ > http://www.eclipsezone.com/eclipse/forums/t97348.html], this is the best > implementation we've found so far. Or is there another, better one out > there? > > My main question is: how do you implement services that are both > declarative, and that also rely on config from the Config Admin service? > We've tried making services both DeclaredComponents and ManagedServices > but > the interaction between the two is hard to manage. > Do you instead rely on getting configuration from the ComponentContext in > activate() methods? The OSGi spec suggests this should work, but it > doesn't > appear to be the case with the ProSyst DS implementation anyway. > > (Another discrepancy we've seen in this DS implementation is that calls to > ComponentContext.disableComponent() and enabledComponent() cause > deactivation/activation on the named component to happen synchronously, > not > asynchronously as the spec states) > > Any suggestions would be most welcome. > > Regards, > Jan > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > -- View this message in context: http://www.nabble.com/Declarative-Services-questions-tf4193314.html#a12038051 Sent from the Equinox - Dev mailing list archive at Nabble.com. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services questions
Hi Jan, >Do you instead rely on getting configuration from the ComponentContext in >activate() methods? The OSGi spec suggests this should work, but it doesn't >appear to be the case with the ProSyst DS implementation anyway. Could you be more specific here? Do you mean that you use ComponentContext.locateService(...) to get Config Admin service? There was a bug in DS exactly in this scenario but it is already fixed (committed on 09.07.07). >(Another discrepancy we've seen in this DS implementation is that calls to >ComponentContext.disableComponent() and enabledComponent() cause >deactivation/activation on the named component to happen synchronously, not >asynchronously as the spec states) Agree. This is a bug and should be reported. Cheers, Stoyan Jan Stette-2 wrote: > > Dear all, > > I'd like to ask anyone on this list: is there anyone out there who is > using > Declarative Services with Equinox in anger? On my current project, we > have > tried to introduce it but have come across some problems. > > First of all, we're using the ProSyst implementation. While we realise > this > is classified as "not release-ready" [ > http://www.eclipsezone.com/eclipse/forums/t97348.html], this is the best > implementation we've found so far. Or is there another, better one out > there? > > My main question is: how do you implement services that are both > declarative, and that also rely on config from the Config Admin service? > We've tried making services both DeclaredComponents and ManagedServices > but > the interaction between the two is hard to manage. > Do you instead rely on getting configuration from the ComponentContext in > activate() methods? The OSGi spec suggests this should work, but it > doesn't > appear to be the case with the ProSyst DS implementation anyway. > > (Another discrepancy we've seen in this DS implementation is that calls to > ComponentContext.disableComponent() and enabledComponent() cause > deactivation/activation on the named component to happen synchronously, > not > asynchronously as the spec states) > > Any suggestions would be most welcome. > > Regards, > Jan > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > -- View this message in context: http://www.nabble.com/Declarative-Services-questions-tf4193314.html#a12037987 Sent from the Equinox - Dev mailing list archive at Nabble.com. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
