Re: [equinox-dev] Eclipse ViewPart and OSGI Declarative Servicesproblem
Another dependency-injection approach is Spring. Martin Libbert provided a way to bridge extension points w/ spring beans. See his blog at: * http://martinlippert.blogspot.com/2008/05/dependency-injection-for-extensions.html -Original Message- From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Neil Bartlett Sent: Tuesday, November 02, 2010 7:11 AM To: Equinox development mailing list Subject: Re: [equinox-dev] Eclipse ViewPart and OSGI Declarative Servicesproblem Hi Richard, This is a rather challenging area, because the lifecycles of services and extensions are completely unrelated. As you've noticed, creating a component with DS does not mean it will be used by the extension registry. Indeed it cannot be, because the extension registry is more like a factory where new instances are created each time they are needed. I created a small framework to help with this kind of thing: http://github.com/njbartlett/extensions2services. Please be sure to read the manual (in PDF), because it helps to describe the background of the problem, even if you decide not to adopt my solution. Other possible solutions, which all use or include a dependency-injection approach, are as follows: 1) Eclipse Riena -- however Riena does a lot of other stuff that I don't really understand 2) Peaberry is based on Guice 3) Eclipse 4.0 (e4) uses dependency injection everywhere, but this is not much use to you if you are using 3.x. Regards, Neil On Mon, Nov 1, 2010 at 9:17 PM, Richard Catlin richard.m.cat...@gmail.com wrote: I have a ViewPart which depends on an OSGI Declarative Service. I have it configured properly so that the service is injected into the ViewPart via a bind method. I can debug and see that this is working. The problem I am having is that a new instance of the ViewPart is being instantiated for viewing and that the instance that was injected is not being used. Any help is appreciated. Thanks. Richard Catlin ___ 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] Re: [p2-dev] who should declare dependencies on ds?
Re: features and start levels, I thought this could be accomplished via p2 with CUs.(Sent from my Droid) -Original Message- From: Jeff McAffer [j...@eclipsesource.com]Received: 4/3/10 3:49 PMTo: Equinox development mailing list [equinox-...@eclipse.org]Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?yes, partially. Features do not allow you ot set start levels, properties and command line args. So, they are part of the story certainly but products are the tasty recipe.JeffOn 2010-04-03, at 12:29 PM, O'Flynn, Dennis wrote: In your analog, sounds like the pancakes would be a "feature" while the eggs and flour are "plug-ins".(Sent from my Droid) -Original Message- From: Neil Bartlett [njbartl...@gmail.com]Received: 4/2/10 6:51 PMTo: Equinox development mailing list [equinox-...@eclipse.org]CC: P2 developer discussions [p2-...@eclipse.org]Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds? This is the thing about decoupling bundles with services...Eggs do not depend on flour; they know nothing about flour. Flour knows nothing about eggs. We need some kind of knowledge that lives outside of the ingredients -- i.e., a recipe -- in order to make pancakes. Rgds,NeilOn Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer j...@eclipsesource.com wrote: Good point Jason. I would generalize it even more and say that it is not just DI but the decoupling that comes with services (or the extension registry for that matter). We decouple bundles to they don't depend on specific implementations but then do not have a mechanism for spec'ing that they actually need an implementation. There is the component definition in DS etc but p2 or someone else has to read/understand that. The unique thing about DS is that it is even more removed. You could say , "hey, the bundle has DS markup so it must need DS" While that is likely true in many cases, it is also possible that the same bundle could be used with and without DS. It may contain other markup for other DI mechanisms. These have to be dealt with at a higher level as you say. JeffOn 2010-04-02, at 4:40 PM, Jason Barkanic wrote:In general this is a problem with any kind of dependency injection, although in this case nothing is actually being injected, but it is being set up and managed by an outside component. Do you set up a dependency on the dependency injector? How do you best notify clients that they need the dependency injection framework with your config, or else they'll have to set things up themselves? It's not even different implementations of DS, but you could substitute in Blueprint, or Spring, without changing the API (that is if you don't define API to include one particular set of bundles over another). This kind of thing is annoying though (I've been a victim). I'm interested to see what solutions present themselves as more and more people move to DI and Services paradigms. I think good error messages can help, since that might have alleviated your 6 week search in the first place, but that is easier said than done. The error message could make suggestions about why a service lookup failed, but it's hard [impossible] to really know. -JasonPhil Wrote: = I can appreciate the desire to allow different DS implementations but the bottom line is that DS is going to break any RCP application that uses P2 (there may be other fall out as well). My RCP app uses P2 so I thought that I should download 3.6M5 so that I had time to make comments about the API before the API freeze. When I updated not only did my auto update functionality break, but my build server broke also (PDE build with P2). It took 6 weeks of googling before I figured out that there was this new DS bundle that I not only had to include, but I also had to be responsible for starting. All is well for me now, but I fear that this change is going to have a big impact when 3.6 releases. At a minimum this needs to be documented probably both in "What's New" in the "Plug-In Development Environment Guide" and also in the 3.6 Plug-in Migration Guide. Getting the rcpupdate example updated (bug 307558) was a good step in the right direction. Thanks,Phil On Thu, Apr 1, 2010 at 1:50 PM, Thomas Watson tjwat...@us.ibm.com wrote: Note that Equinox does have the ability to declare non-code dependencies in bundle manifests. See Eclipse-GenericCapability and Eclipse-GenericRequire headers at: http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html This could be used by the DS implementation to declare a DS runtime capability and bundles defining DS components could declare a requirement on the DS runtime capability. But this mechanism only describes resolve time dependencies. It still would not
[equinox-dev] P2 Repo for Orbit
Does anyone know if the Orbit P2 repository hosted at download.eclipse.org is valid? When I try to access it, I get the following error. URL: http://download.eclipse.org/eclipse/tools/orbit/downloads/drops/R2009052 9135407/updateSite/content.jar ERROR: Access Forbidden The file permissions are either wrong, or there is no default index file for this directory. Please consider filing a bug https://bugs.eclipse.org/bugs/ against the project to let them know. However, I can access an Orbit P2 Repo from one of the mirrors. URL: http://ftp.ussg.iu.edu/eclipse/tools/orbit/downloads/drops/R200905291354 07/updateSite/content.jar Dennis O'Flynn Technical Consultant One Campus Martius 12W-1104 Detroit, Michigan 48226 313-227-7433 Work 313-227-9230 Fax The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. image001.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] FW: Classloader problem
Anyone have any experience running Equinox using IBM J9? We are having some problems with using IBM J9 that we don't encounter with Sun's JVM. See below... The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: Hawkins, Joel Sent: Friday, June 05, 2009 1:27 PM To: O'Flynn, Dennis Subject: Classloader problem Dennis - In a nutshell - The J9 VM packages many javax xml extension jars and their corresponding apache implementations in the library directory of the JRE. Many of the same packages are supplied by bundles that ship with Eclipse. A number of these bundles export packages without version numbers, and we find ourselves running into class verification errors when the classes provided by the JRE don't match those expected by the bundles. The Sun JVM prepend the apache classes with com.sun., so the problem is partially mitigated. However, for javax.* classes, the potential for trouble remains. Is there a way to alter the contents of the system classpath during osgi startup such that we can suppress these additional classes provided by J9 and resolve them from the bundles provided by Eclipse? Cheers, Joel ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Equinox Features
Created bugz: https://bugs.eclipse.org/bugs/show_bug.cgi?id=273405 BTW - also attached patch From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of O'Flynn, Dennis Sent: Wednesday, April 22, 2009 5:10 PM To: Equinox development mailing list Subject: [equinox-dev] Equinox Features I noticed that the recent I-Build (I20090421-0930) now splits Equinox plug-ins into 2 features: org.eclipse.equinox.core.sdk org.eclipse.equinox.core.sdk. Previously, these were (mostly) provided by a single feature: org.eclipse.equinox. I believe there is a slight problem with the new feature definitions. Some of the plug-ins in the org.eclipse.equinox.core.sdk feature should have execution environment attributes. Specifically: * org.eclipse.equinox.security.win32.x86 ** missing: os=win32 arch=x86 * org.eclipse.equinox.security.macosx ** missing: os=macosx arch=x86 Dennis O'Flynn Technical Consultant One Campus Martius 12W-1104 Detroit, Michigan 48226 313-227-7433 Work 313-227-9230 Fax The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. image001.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox Features
I noticed that the recent I-Build (I20090421-0930) now splits Equinox plug-ins into 2 features: org.eclipse.equinox.core.sdk org.eclipse.equinox.core.sdk. Previously, these were (mostly) provided by a single feature: org.eclipse.equinox. I believe there is a slight problem with the new feature definitions. Some of the plug-ins in the org.eclipse.equinox.core.sdk feature should have execution environment attributes. Specifically: * org.eclipse.equinox.security.win32.x86 ** missing: os=win32 arch=x86 * org.eclipse.equinox.security.macosx ** missing: os=macosx arch=x86 Dennis O'Flynn Technical Consultant One Campus Martius 12W-1104 Detroit, Michigan 48226 313-227-7433 Work 313-227-9230 Fax The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. image001.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Autostarting Bundles
Chris, FYI - I tried using the product def’n editor to set the bundles start levels. I had a problem when using the “default” start level. It set the entry in the config.ini to �...@0”. This caused an error when starting the server-side Eclipse environment. Once I changed these to a specific start level (�...@4”), everything did work. BTW – I was surprised that bundles marked for started were defined via “osgi.bundles”, instead of setting CU’s to update the bundle.info. From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Chris Aniszczyk Sent: Wednesday, April 15, 2009 4:03 PM To: Equinox development mailing list Subject: Re: [equinox-dev] Autostarting Bundles On Wed, Apr 15, 2009 at 2:51 PM, J B moa...@gmail.com wrote: I have a small server-side equinox application running. I would like to autostart a couple of other bundles automatically. The Eclipse-AutoStart is deprecated, and the Bundle-ActivationPolicy only accepts 'lazy' as a value. Is there an accepted way to auto start bundles without having the explicitly in the config.ini? We have used a solution in the past that require the plugins wishing autostart to register an extension to a service that will start them on their behalf. But it seems like there must be a different way. So, is there a reason you need bundles autostarted? Is this something that could be solved using Declarative Services (DS) since DS now listens for lazy bundles? One strategy outside the p2.inf suggestion that Denis mentioned is using a product definition and tweaking the start levels from there. Cheers, -- Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465 http://twitter.com/eclipsesource | http://twitter.com/caniszczyk The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Required bundles for P2 in a server-side equinoxapplication
(note: this may be better suited for the p2-dev email list) I have been trying to something similar. I created by own server-side p2 feature with the following plugins. There are some exec env specific plug-ins that you may/may not need. * org.eclipse.ecf * org.eclipse.ecf.filetransfer * org.eclipse.ecf.identity * org.eclipse.ecf.provider.filetransfer * org.eclipse.ecf.provider.filetransfer.ssl * org.eclipse.ecf.ssl * org.eclipse.equinox.p2.artifact.repository * org.eclipse.equinox.p2.core * org.eclipse.equinox.p2.director * org.eclipse.equinox.p2.engine * org.eclipse.equinox.p2.exemplarysetup * org.eclipse.equinox.p2.garbagecollector * org.eclipse.equinox.p2.jarprocessor * org.eclipse.equinox.p2.metadata * org.eclipse.equinox.p2.metadata.generator * org.eclipse.equinox.p2.metadata.repository * org.eclipse.equinox.p2.touchpoint.eclipse * org.eclipse.equinox.p2.touchpoint.natives * org.eclipse.equinox.p2.updatechecker * org.eclipse.equinox.security * org.eclipse.equinox.security.macosx * org.eclipse.equinox.security.win32.x86 * org.eclipse.equinox.simpleconfigurator.manipulator * org.sat4j.core * org.sat4j.pb * org.eclipse.core.jobs * org.eclipse.core.net * org.eclipse.core.net.linux.x86 * org.eclipse.core.net.win32.x86 * org.eclipse.equinox.frameworkadmin * org.eclipse.equinox.frameworkadmin.equinox * org.eclipse.equinox.p2.director.app * org.eclipse.equinox.p2.directorywatcher * org.eclipse.equinox.p2.console * org.eclipse.equinox.p2.extensionlocation * org.eclipse.equinox.p2.reconciler.dropins * org.eclipse.equinox.p2.updatesite * org.eclipse.equinox.p2.publisher The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of J B Sent: Wednesday, April 15, 2009 3:25 PM To: equinox-dev@eclipse.org Subject: [equinox-dev] Required bundles for P2 in a server-side equinoxapplication I want to include the P2 bundles in my server-side Equinox based application. There is no UI component, and the application runs headless. What are the required P2 bundles necessary to provide provisioning capability? Thanks! Birch ___ 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] Equinox Lauchers for S390
Found them. Thx From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Kim Moir Sent: Wednesday, January 14, 2009 3:23 PM To: Equinox development mailing list Subject: Re: [equinox-dev] Equinox Lauchers for S390 The S390 binaries were never contributed to the cvs repository. They only available binaries are the ones that exist in the S390 zips on the 3.4, 3.4.1 etc. release pages. Kim Andrew Niefer/Ottawa/i...@ibmca Sent by: equinox-dev-boun...@eclipse.org 01/14/2009 10:44 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] Equinox Lauchers for S390 I don't recall ever receiving any S390 binaries. We made the changes to create the fragment and modify the build, but I don't believe the results were ever contributed back. You could ask on the bug, perhaps releng has more details. -Andrew O'Flynn, Dennis dennis.ofl...@compuware.com Sent by: equinox-dev-boun...@eclipse.org 01/14/2009 10:27 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox Lauchers for S390 Are the equinox launchers for S390/S390x that were contributed for Eclipse v3.3 available anywhere? Reference: https://bugs.eclipse.org/bugs/show_bug.cgi?id=171518 https://bugs.eclipse.org/bugs/show_bug.cgi?id=171518 The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. ___ 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] Starting all dependent bundles
You could provide your own customized config.ini. The product configuration editor allows you to specify the config.ini to use. This is defined within the Configuration tab. From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Leen Toelen Sent: Wednesday, January 07, 2009 10:43 AM To: equinox-dev@eclipse.org Subject: [equinox-dev] Starting all dependent bundles Hi, I would like to create a headless product and application meant to be run as a windows service (headless). When creating my product (and product description) I mention all needed plugins. When I export the service, this is my config.ini: osgi.splashPath=platform:/base/plugins/com.my.product.service eclipse.product=service.Product osgi.bundles.defaultStartLevel=4 osgi.bundles=org.eclipse.equinox.com...@2:start,org.eclipse.update.confi gura...@3:start,org.eclipse.core.runt...@start When I check the osgi console I see that all my plugins are resolved but not started, and I need to do this manually. How can I make sure that they are started automatically when the product starts? Regards, Leen Toelen The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] tests are needed for compendium implementations
FYI - not sure if this would be of any interest to your testing needs... Corona has a test framework that runs within an Equinox environment. It allows for a mixture of JUnit 3.8 and 4.1 test cases. We use it to run logical (class-based) test cases as well as integration (service-based) tests. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Watson Sent: Thursday, August 21, 2008 4:50 PM To: equinox-dev@eclipse.org Subject: [equinox-dev] tests are needed for compendium implementations The compendium bundles in equinox are in serious need of automated tests. For the 3.5 release we need to create junit tests for each of the compendium bundles. I have created a new project in compendium to start releasing new testcases for our compendium bundles under: org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.compendium.te sts Chris Aniszczyk was kind enough to contribute a few UserAdmin tests which I have seeded into the new project. I know Simon Kaegi has his own tests for ConfigurationAdmin which I would like to be integrated into the org.eclipse.equinox.compendium.tests. But we have lots of other compendium bundles that need test coverage. Pavlin and Stoyan, do you have automated tests for org.eclipse.equinox.ds, org.eclipse.equinox.io, org.eclipse.equinox.ip, and org.eclipse.equinox.wireadmin that can be contributed for the bundles you own? This is also an opportunity for anyone trying to get familiar or involved with Equinox and OSGi to develop testcases. Any help from the community is greatly appreciated. Thanks. Tom The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Equinox IP log
The Orbit download page contains a zip of all of the Orbit bundles. For example, the Orbit build S20080326131619 provides the zip orbit-S20080326131619.zip that contains all of the Orbit bundles for that release. * see: http://download.eclipse.org/tools/orbit/downloads/drops/S20080326131619/ In addition, there are map files that allow you to fetch any bundle via PDE Build. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Kriens Sent: Monday, April 21, 2008 3:20 AM To: Equinox development mailing list Subject: Re: [equinox-dev] Equinox IP log Is it possible to get all the Orbit bundles in the OBR repository? Kind regards, Peter Kriens On 19 apr 2008, at 11:53, DJ Houghton wrote: John, looks good! Here is the discussion on the Orbit mailing list about hiding the email addresses: http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00732.html In Orbit everything is a third-party bundle. When people commit a new bundle to the repository, they are required to create an IP log XML file: http://wiki.eclipse.org/Orbit_IP_Log and then during the build we parse this information and build a web page for that build. For example: http://download.eclipse.org/tools/orbit/downloads/drops/I20080411183252/ iplog-I20080411183252.html If you want to use this story going forward with the Equinox project, I can work with you to get it going. Jeff McAffer [EMAIL PROTECTED] Sent by: To equinox-dev-bounc 'Equinox development mailing [EMAIL PROTECTED]list' equinox-dev@eclipse.org cc 04/18/2008 10:49 Subject PMRE: [equinox-dev] Equinox IP log Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org Thanks John, this is a good start. I wonder if there is something we can harvest from the Orbit IP log structure. DJ? Thoughts? It would be generally useful to have the CQ numbers associated with the third party code. One important not is that I believe we have a policy about protecting email addresses. We went through this in Orbit where the decision was to not include them. DJ, do you recall anything about this? Either way, unless there is a compelling reason to include them they should be removed. Jeff From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Arthorne Sent: Friday, April 18, 2008 4:00 PM To: equinox-dev@eclipse.org Subject: [equinox-dev] Equinox IP log FYI, I have committed an initial Equinox IP log: http://www.eclipse.org/equinox/documents/iplogs/EquinoxIPlog.html We had initially started with a separate IP log per component, but as I started to update them I found it painful to track the committer lists separately so I combined them. Also there is only one IP log URL that can be linked from http://eclipse.org/projects/listofprojects.php. The third party software list is not yet complete, and I have not processed all the p2 contributions since p2 graduation. Can all committers quickly scan the committer list and ensure they are listed, and their login, organization, and email addresses are correct? I believe we only need to record committers who contributed to the 3.4 release - this excludes people who committed only to the incubator project, and those who only committed prior to the 3.3 release (someone please correct me if this is wrong). ___ 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] DS invocation order of bind and activate(timing issue???)
Not sure if the following is related. Maybe someone more familiar w/
equinox ds/util could comment on this.
1) equinox ds imports packages from util
2) equinox util is NOT lazy started
Q: Is equinox ds dependent upon service provide by equinox util that may
not be yet registered when ds is started before util?
If equinox util was lazy started, than I would assume that the 2nd
startup sequence listed below should have worked.
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Foerster, Stefan
Sent: Monday, February 25, 2008 4:24 AM
To: Equinox development mailing list
Subject: RE: [equinox-dev] DS invocation order of bind and
activate(timing issue???)
I think I've got a test case and test sequence to reproduce the timing
problem.
The problem arises from the start order of the bundles.
if the framework starts the bundles in the following order:
1) org.eclipse.osgi_3.4.0.v20080218
2) org.eclipse.equinox.ds_1.0.0.v20080218
3) org.eclipse.equinox.log_1.1.0.v20071203
4) org.eclipse.equinox.util_1.0.0.v20080218
5) javax.servlet_2.4.0.v200711021030
6) org.eclipse.osgi.services_3.1.200.v20071203
7) a_2.0.0
8) d_2.0.0
everything is OK (see attached running.txt), both services A and D get
activated as expected.
Now, If i stop bundles 2-8 and start them in the following order (bundle
1 was not stopped):
2) javax.servlet_2.4.0.v200711021030
3) org.eclipse.equinox.ds_1.0.0.v20080218
4) org.eclipse.equinox.log_1.1.0.v20071203
5) org.eclipse.osgi.services_3.1.200.v20071203
6) a_2.0.0
7) d_2.0.0
8) org.eclipse.equinox.util_1.0.0.v20080218
I get the timeouts in the SCR (see fail.txt).
I also attached the two bundles I used to debug the problem. The source
code
is located within the OSGI-INF/src.
Based on this observation I think the SCR gets confused and does not
obey the
activation/bind order as I reported before.
-Original Message-
From: [EMAIL PROTECTED] on behalf of BJ Hargrave
Sent: Fri 22.02.2008 20:05
To: Equinox development mailing list
Subject: Re: [equinox-dev] DS invocation order of bind and
activate(timing issue???)
I think you should put this in a bug report against DS.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Foerster, Stefan [EMAIL PROTECTED]
To:
equinox-dev@eclipse.org
Date:
2008-02-22 11:52
Subject:
[equinox-dev] DS invocation order of bind and activate (timing
issue???)
Hello,
I'm having three bundles providing three services using the declarative
service (version 1.0.0.v20080218):
bundle A:
component name=A1 immediate=true
implementation class=A1/
service
provide interface=IA/
/service
property name=service.pid value=A1/
property name=service.ranking value=1000/
reference name=b interface=IB bind=setB unbind=unsetB
cardinality=0..n policy=dynamic/
reference name=c interface=IC bind=setC unbind=unsetC
cardinality=0..1 policy=dynamic/
reference name=d interface=ID bind=setD unbind=unsetD
cardinality=1..1/
reference name=e interface=IE bind=setE unbind=unsetE
cardinality=0..n policy=dynamic/
/component
bundle B:
component name=B1
implementation class=B1/
service
provide interface=IB/
/service
property name=service.pid value=B1/
property name=service.ranking value=1000/
reference name=a interface=IA bind=setA unbind=unsetA
cardinality=1..1/
reference name=d interface=ID bind=setD unbind=unsetD
cardinality=1..1/
/component
bundle D:
component name=D1
implementation class=D1/
service
provide interface=ID/
/service
property name=service.pid value=D1/
property name=service.ranking value=1000/
reference name=logger interface=org.osgi.service.log.LogService
bind=setLog unbind=unsetLog cardinality=0..1 policy=dynamic/
/component
Reading the OSGi DS spec I assume the only valid method invocation order
(if the methods exists and are accessible) is:
1) D1.activate() - some instanceD
2) A1.setD(instanceD)
3) A1.activate() - some instanceA
4) B1.setA(instanceA) and B1.setD(instanceD) in any order
5) B1.activate() - some instanceB
6) A1.setB(instanceB)
Sometimes, it happens that B1 is activated before!!! A1. and I get the
following
order of calls from the OSGi log (calls to setD() are not logged!):
==
1: Debug [51] D1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
2: Info [51] ServiceEvent REGISTERED {service.id=29}
3: Info [54] ServiceEvent REGISTERED {service.id=30}
4: Info [37] ServiceEvent REGISTERED {service.id=31}
5: Info [52] ServiceEvent REGISTERED {service.id=32}
