Re: [equinox-dev] Committer disagreement resolution guidelines

[BJ Hargrave]

Most committers are already subscribed to the repo and see all… the messages. 
So @ mentioning a committer group will not put more email in the committer’s 
inboxes. They were already going to get the email.

--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargr...@us.ibm.com


From: equinox-dev  on behalf of Aleksandar 
Kurtakov 
Date: Monday, June 20, 2022 at 07:17
To: Equinox development mailing list 
Subject: [EXTERNAL] Re: [equinox-dev] Committer disagreement resolution 
guidelines
I' ve opened https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1437 to 
see what we can get out of this discussion. Please vote/comment/etc. so we can 
get some good longterm solution. On Mon, Jun 20, 2022 at 1:28 PM Christoph 
Läubrich
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I' ve opened https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1437 to 
see what we can get out of this discussion. Please vote/comment/etc. so we can 
get some good longterm solution.

On Mon, Jun 20, 2022 at 1:28 PM Christoph Läubrich 
mailto:lae...@laeubi-soft.de>> wrote:
Yes, but as you mention I need to

a) got to project site (often hard to find if not linked as project name
!= github repo name)
b) got to
https://projects.eclipse.org/content/thomas-watson-project-lead-equinox
for exmaple
c) then click on the user
d) then there is a small button to gihub (not sure if always, because
eclipsename != github name in many cases) then copy that name and build
a list of potentially everyone...

No think about someone wants to ask any commiter to review its PR, now I
need to just randomly choose people, while with a public team I could do

@commiters can please someone review my PR or let me know what is missing

Given that there is already an automated script for syncing the infos to
github, I assume it should be possible to automate this so we have these
info as a Github "Team" and as the info is not private there should not
be an issue to make it explicit and a "public team"?

Am 20.06.22 um 12:21 schrieb Ed Merks:
> Note that every project has portal information where you can see who is
> involved and see who leads:
>
> https://projects.eclipse.org/projects/eclipse.equinox/who
>
> That also has navigation (PROJECT LINKS section on the right) to the
> container in the project hierarchy, e.g.,
>
> https://projects.eclipse.org/projects/eclipse/who
>
> I expect we'd not want to duplicate this information because who is
> going to keep that information current?
>
>
> On 20.06.2022 12:06, Christoph Läubrich wrote:
>> Alright, do you think it would be possible to have (beside the private
>> groups) maybe have for each Gitgub repo one
>>
>> @commiters
>> @project-lead
>> @pmc
>>
>> I really miss that info (not only in eclipse projects) to have a clue
>> how to ask "anyone" e.g. for PR or in this case clearance of
>> disagreement, so using "private" groups seem inappropriate here anyways.
>>
>> Am 20.06.22 um 12:03 schrieb Aleksandar Kurtakov:
>>> Link definitely is correct but seems to be "protected" in some way.
>>> As a project lead I can even start discussion among project leads.
>>>
>>> On Mon, Jun 20, 2022 at 1:02 PM Ed Merks 
>>> mailto:ed.me...@gmail.com>
>>> <mailto:ed.me...@gmail.com<mailto:ed.me...@gmail.com>>> wrote:
>>>
>>> It's not visible to me either...  Maybe the link is wrong...
>>>
>>> On 20.06.2022 11:59, Christoph Läubrich wrote:
>>>  >
>>>  > Hm.. it seems this is not visible because I'm not part of the
>>> group...
>>>  > that's really annoying...
>>>  > Am 20.06.22 um 11:51 schrieb Aleksandar Kurtakov:
>>>  >> We have
>>>  >>
>>> https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads<https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads>
>>>
>>> <https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads<https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads>>
>>>
>>>
>>>  >>
>>> <https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads<https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads>
>>>
>>> <https://github.com/orgs/eclipse-platform/teams/eclipse-platform-project-leads<https://github.com/orgs/eclipse-platform/teams/eclipse-platfo

Re: [equinox-dev] Issue with OSGI Annotations

[BJ Hargrave]

You should use maven scope=provided for the org.osgi.service.*.annotations artifacts. They are not meant for runtime use and should not be part of a resolution operation. Don't install them in an OSGi framework.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: "Kanika Khattar" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] [equinox-dev] Issue with OSGI AnnotationsDate: Wed, Feb 23, 2022 23:26  
Hi All,While using OSGI Annotations in my project, I am getting a few issues. It will be great if you can help me with the same.
 
Below are the issues:
1. !ENTRY org.osgi.service.metatype.annotations 4 0 2022-02-24 09:43:01.813!MESSAGE FrameworkEvent ERROR!STACK 0org.osgi.framework.BundleException: Could not resolve module: org.osgi.service.metatype.annotations [219]Unresolved requirement: Require-Capability: osgi.compile.time.only; filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"at org.eclipse.osgi.container.Module.start(Module.java:463)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)!ENTRY org.osgi.service.component.annotations 4 0 2022-02-24 09:43:01.887!MESSAGE FrameworkEvent ERROR!STACK 0org.osgi.framework.BundleException: Could not resolve module: org.osgi.service.component.annotations [239]Unresolved requirement: Require-Capability: osgi.compile.time.only; filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"at org.eclipse.osgi.container.Module.start(Module.java:463)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
 
 
2. Activate method gets called when Configuration Policy is set to OPTIONAL. When Configuration Policy is REQUIRE, the activate method is not called.
 
Thanks & Regards,
Kanika
 
 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xml

[BJ Hargrave]

If you need to connect to existing Eclipse extension points, such as writing Eclipse plugins which must integrate into the existing Eclipse plugins, then you will probably need to use the Eclipse extension registry model.
 
If you are doing anything else, use OSGi Services via the OSGi Declarative Service model. OSGi services are bound by the bundle lifecycle which means a bundle must be started to register or use services and when a bundle stops, it releases any registered or used services (the mechanics of this are nicely handled by OSGi Declarative Services).
 
The Eclipse extension model predates the adoption of OSGi by Eclipse and has an undesirable life cycle binding. Eclipse extensions are bound to the resolved state (when a bundles class loading dependencies are met and the bundle can have a class loader) which means starting and stopping a bundle have no bearing on the bundle's use of extensions. This can be very awkward especially during development. In Bndtools (tooling for OSGi bundle development), we have Eclipse plugins and must use Eclipse extension points to integrate with the IDE, but due to the life cycle binding of Eclipse extensions, we are moving to a facade model when we have a bundle which uses Eclipse extension and delegates to another bundle using OSGi services. This allows use to easily replace the bundle proving OSGi services while the facade bundle is statically bound to the Eclipse extension point registry.
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: "Thomas Watson" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xmlDate: Wed, Sep 29, 2021 09:01 
That is a bit of a dramatic statement that can open a can of worms.  The extension registry and the Eclipse platform model with its many extension points does what it does very well.  If you are developing bundles that plugin to the Eclipse platform do not "feel bad" about using the right technology.  Many times that will be writing an extension and defining a plugin.xml.  If you are not plugging into the Eclipse platform then use the technology that suits your needs.  I agree the OSGi service registry and actually the use of Declarative Services is a very good mechanism that has many advantages.
Tom 
 
 
- Original message -From: "Jürgen Albert" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xmlDate: Wed, Sep 29, 2021 7:45 AM 
Yes, the plugin.xml is a leftover of the early days. OSGi offers the far superior mechanism of Declarative Services. I'd strongly recommend to avoid the old extensions wherever possible.
Regards,
Jürgen.
Am 29/09/2021 um 14:23 schrieb Mickael Istria:

Right, plugin.xml is an Eclipse-specific format for extensibility, which is not part of OSGi specification. Support for this "extension registry" of plugin.xml files is part of the org.eclipse.equinox.registry bundle. I believe it's totally possible for Equinox to work comforming to OSGi spec without this bundle. 

 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
--Jürgen AlbertCEOChair Eclipse OSGi Working Group Steering CommitteeData In Motion Consulting GmbHKahlaische Str. 407745 JenaMobil:  +49 157-72521634E-Mail: j.alb...@datainmotion.deWeb: www.datainmotion.deXING:   https://www.xing.com/profile/Juergen_Albert5LinkedIn: https://www.linkedin.com/in/juergen-albert-6a1796/RechtlichesJena HBR 513025
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
  

___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Should OSGi bundles always export all packages?

[BJ Hargrave]

That advice is too broad. A bundle should export the package which are its API. That is, the packages which users of the bundle need access to in order to use the bundle. Packages which are implementation detail should not be exported to properly encapsulate implementation detail. Some bundles will export no packages since they are pure implementation. Some bundle are pure API and thus will export all packages. But it is not true that all bundles should export all packages.
 
If every bundle exports all packages, then where is any modularity and encapsulation of implementation detail?
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] Should OSGi bundles always export all packages?Date: Mon, Dec 2, 2019 10:31 
Hi OSGi experts,In one of the Eclipse releases a warning was activated that a pluginmust  exports all its packages. It is possible to change this for aworkspace but IMHO this new default is wrong.Plug-ins should not always export all packages as IMHO this defies thepurpose of a good module system. Internal stuff should be hidden.Can you clarify what the OSGi recommended way is? Seehttps://bugs.eclipse.org/bugs/show_bug.cgi?id=544977Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com ___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] In which thread are OSGI services started

[BJ Hargrave]

The DS specification says nothing about what thread a DS component's method is invoked upon. It may be someone else's thread or a thread that SCR manages in an executor. But as a component implementer you MUST NOT assume anything about the thread upon which your component's methods are invoked. (Other than it is not your thread to use for long periods of time.)
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] Re: [equinox-dev] In which thread are OSGI services startedDate: Wed, Sep 4, 2019 14:44 
Thanks Neil and BJ. What if I use OSGi ds (Felix) to define the service? 
 
 
Best regards, Laes 

Neil Bartlett  schrieb am Mi., 4. Sep. 2019, 14:44:
Short answer is that you should not make any assumption about the thread that your component is activated.
 
Long answer is that for an immediate component, it is likely to be activated in whichever thread called Bundle.start(). For a lazy service component, it is likely to be activated in whichever thread called BundleContext.getService().
 
But the outcome is the same. You are always "borrowing" a thread and should never do long running work in the activate method of a component. If you have any such work to do, then you should spin it out as a thread or submit it to an executor service.
 
Neil 

On Wed, 4 Sep 2019 at 13:41, Lars Vogel  wrote:
Friends of Equinox,If I create an immediate OSGi service, in which thread is it created?How about lazy OSGi services?The background of my question is that I would like to replace anEclipse early startup extension with an immediate OSGi but I'm notsure if that would block the main thread until the service has beencreated.Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] In which thread are OSGI services started

[BJ Hargrave]

It is undefined by the DS specification. SCR is free to use any thread to invoke DS component methods.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] In which thread are OSGI services startedDate: Wed, Sep 4, 2019 08:41 
Friends of Equinox,If I create an immediate OSGi service, in which thread is it created?How about lazy OSGi services?The background of my question is that I would like to replace anEclipse early startup extension with an immediate OSGi but I'm notsure if that would block the main thread until the service has beencreated.Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com ___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] understanding resolving results

[BJ Hargrave]

See https://github.com/bndtools/bnd/pull/2867 for how Bnd deals with using Eclipse bundles.
 
In summary, Bndtools uses Import-Package with bundle-symbolic-name and bundle-version attributes because Eclipse is terrible at managing packages and Require-Bundle is too promiscuous.
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Martin Lippert Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox Dev Cc:Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving resultsDate: Tue, Jun 25, 2019 09:21 
Hey!Quick follow-up on this one:it turned out that the resolver is perfectly correct and that there is indeed a subtle difference between those two installs. The orbit bundle for “javax.ws.rs” seemed to be the culprit. Both builds got the exact same version of the bundle, but when looking inside of the bundle into the manifest, those are slightly different. One version adds a version constraint to a package-import, the other one not. And the version constraint causes the trouble, in combination with a require-bundle on org.eclipse.core.runtime.What is the best practice these days when using org.eclipse.core.runtime? Import the used packages instead to avoid the re-export of system packages (in this case javax.xml.annotation.bind)?Thanks a lot for your help, so much appreciated !!!Cheers,-Martin> Am 12.06.2019 um 15:03 schrieb Thomas Watson :>> What happens if you run with -clean.  Does the bad install still have the uses constraint error?  Before doing so you may want to backup the configuration/ folder so you can get back to the "bad" state.  Equinox caches previous runs wiring state.  When additional bundles are installed they are resolved with the previous wiring state as a starting point.  That means the additional bundles must be able to resolve with the decisions made by the resolver when it resolved the initial set of bundles.  Some cases these decisions from the resolution cache may prevent additional bundles to resolve.  When using -clean this will re-resolve all bundles again, it actually installs all the bundles again from scratch.>  > You didn't give much detail on how the two environments got to their current state, so I am not sure if that is what is happening in this case or not.  If running with -clean gets you to a state that has no resolve errors then I would bet something like this is happening.  On the other hand if -clean with one environment cause errors but in the other environment results in success then we do have an anomoly to investigate.  I would start by gathering resolution trace for the two runs.  I would start with the top level resolver trace option (which is pretty noisy, but gets you the most data about what the resolver is doing):>  > org.eclipse.osgi/resolver=true>  > At this point I assume you know how to enable trace for Eclipse (e.g. specify config.ini option osgi.debug= or use -debug launch option).>> Tom>  >  > - Original message -> From: Martin Lippert > Sent by: equinox-dev-boun...@eclipse.org> To: Equinox Dev > Cc:> Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving results> Date: Wed, Jun 12, 2019 5:46 AM>  > Hey Mickael,>> > So I am looking for strategies to debug and understand this.> >> > Have you tried starting with the `-console` flag to use the OSGi console and compare the effect of the "start" action on both packages?>> Thanks for the suggestion, not sure I understand this.> Doing a “start” on a “package” ?!?>> I can see the details about the package-use-contraint violation using the “diag” command and understand the issue, but I am wondering why the resolver decided to not wire it differently, as it is on a different install with the same set of bundles around. There must be a reason for this… :-)>> Cheers,> -Martin ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://www.eclipse.org/mailman/listinfo/equinox-dev>  >> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Meta-Type Annotations

[BJ Hargrave]

The Metatype annotations are already available on Maven Central/JCenter. Since the annotation classes are not visible/used at runtime, I am curious as to why Eclipse needs to distribute them?
 
Also, what part of Eclipse will even process the Metatype annotations? Does PDE do that? As far as I know, only Bnd processes Metatype annotations. Unless PDE processes the annotations, there is little point in distributing them with Eclipse IDE.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Peter Nehrer Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: Re: [equinox-dev] Meta-Type AnnotationsDate: Tue, Apr 4, 2017 8:36 PM 
Thanks Scott. I'll try submitting a CQ for a subset of that jar (just Meta Type annotations). I was thinking if those classes were already distributed with some Eclipse code (rather than just being attached to a CQ) then I would be able to repackage them, but maybe that's not even true.> On Apr 4, 2017, at 5:17 PM, Scott Lewis  wrote:>> Hi Peter,>> FWIW, ECF depends upon and distributes org.osgi.service.remoteserviceadmin.* as part of ECF's RSA impl. We use a piggy back CQ:>> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8527>> Not that I'm recommending this for metatype annotation classes. Seems to me it would be better placed as part of Equinox SDK...along with the metatype impl?>> Scott On 4/4/2017 11:15 AM, Peter Nehrer wrote:>> Hello, I'm looking for annotation types in package org.osgi.service.metatype.annotations but can't seem to be able to find them anywhere in Equinox. Looking at https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8618, the latest attached jar (https://dev.eclipse.org/ipzilla/attachment.cgi?id=12761) does have those annotations, but I can't find that jar included anywhere in Eclipse (git, build, p2 repo... anywhere); not even Orbit has the latest version. Where do I need to look? Has Equinox only consumed portions of that jar? If so, would it be OK to extract the Metatype annotations and still be covered by the same CQ? I'd appreciate any pointers anyone might have. Thanks! --Peter>> ___>> equinox-dev mailing list>> equinox-dev@eclipse.org>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit>> https://dev.eclipse.org/mailman/listinfo/equinox-dev>>> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://dev.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev 
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Meta-Type Annotations

[BJ Hargrave]

It is in that attached jar you mention :-) Look again!
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Peter Nehrer Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [equinox-dev] Meta-Type AnnotationsDate: Tue, Apr 4, 2017 2:15 PM 
Hello,I'm looking for annotation types in package org.osgi.service.metatype.annotations but can't seem to be able to find them anywhere in Equinox. Looking at https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8618, the latest attached jar (https://dev.eclipse.org/ipzilla/attachment.cgi?id=12761) does have those annotations, but I can't find that jar included anywhere in Eclipse (git, build, p2 repo... anywhere); not even Orbit has the latest version.Where do I need to look? Has Equinox only consumed portions of that jar? If so, would it be OK to extract the Metatype annotations and still be covered by the same CQ?I'd appreciate any pointers anyone might have. Thanks!--Peter___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev 
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists

[BJ Hargrave]

Having only one exporter of a package is generally the best way to avoid choice :-)
 
The import [4.2.1,4.4) seems very odd. Why the upper limit on 4.4? This seems to ignore semantic versioning. I would have expected [4.2,5). Similarly [4.3.3,) is too broad. I would have expected [4.3,5). These version ranges would appear to be hand written as Bnd would not make those choices.
 
org.eclipse.aether.transport.http needs to be fixed to widen the import range for org.apache.http.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Andreas Sewe Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox Cc:Subject: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it existsDate: Fri, Mar 17, 2017 12:03 PM 
Hi,I am currently investigating a nasty uses conflict (Bug 513809 [1]) thatcauses severe problems in several Oxygen M6 EPP packages (at least Javaand JEE) and I could really need some help from an OSGi expert.First, the wiring problem in question *does* have a solution, but -cleandoesn't find it. Is this an Equinox bug or simply a known limitation,given the NP completeness of bundle resolution?Second, some of the Import-Packages' version ranges look either overlyspecific [4.2.1,4.4) or overly broad [4.3.3,), so I wonder *if* thisproblem could be prevented by fixing those Import-Packages (under theassumption that all bundles in question adhere to semantic versioning).Anyway, here's the uses conflict I was talking about:> Chain 1:>   org.eclipse.aether.transport.http [osgi.identity; type="osgi.bundle"; version:Version="1.0.1.v2014"; osgi.identity="org.eclipse.aether.transport.http"]>     import: (&(osgi.wiring.package=org.apache.http)(&(version>=4.2.1)(!(version>=4.4.0>      |>     export: osgi.wiring.package: org.apache.http>   org.apache.httpcomponents.httpcore [osgi.identity; type="osgi.bundle"; version:Version="4.3.3.v201411290715"; osgi.identity="org.apache.httpcomponents.httpcore"]>> Chain 2:>   org.eclipse.aether.transport.http [osgi.identity; type="osgi.bundle"; version:Version="1.0.1.v2014"; osgi.identity="org.eclipse.aether.transport.http"]>     import: (&(osgi.wiring.package=org.apache.http.auth)(&(version>=4.2.1)(!(version>=4.4.0>      |>     export: osgi.wiring.package=org.apache.http.auth; uses:=org.apache.http.protocol>   org.apache.httpcomponents.httpclient [osgi.identity; type="osgi.bundle"; version:Version="4.3.6.v201511171540"; osgi.identity="org.apache.httpcomponents.httpclient"]>     import: (&(osgi.wiring.package=org.apache.http.protocol)(version>=4.3.3))>      |>     export: osgi.wiring.package: org.apache.http.protocol; uses:=org.apache.http>     export: osgi.wiring.package=org.apache.http>   org.apache.httpcomponents.httpcore [osgi.identity; type="osgi.bundle"; version:Version="4.4.6.v20170210-0925"; osgi.identity="org.apache.httpcomponents.httpcore"]In my opinion, the above could be solved by wiring all packages importedby bundle org.apache.httpcomponents.httpclient 4.3.6.v201511171540 tothe packages exported by bundle org.apache.httpcomponents.httpcore4.3.3.v201411290715 (as is done in Neon.3), but apparently the presenceof a newer version of org.apache.httpcomponents.httpcore is too temptingfor Equinox.Any insights on this issue are really appreciated.Best wishes,Andreas[1] --Codetrails GmbHThe knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtPhone: +49-6151-276-7092Mobile: +49-170-811-3791http://www.codetrails.com/Managing Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] security exceptions using Felix config admin withEquinox

[BJ Hargrave]

Why does Felix CM call doPrivileged with an ACC from the object it is about to call? That is pointless since that object will soon be on the call stack and thus its permissions will be tested.
 
Perhaps the problem is solved by using the one arg version of doPrivileged:
 
      AccessController.doPrivileged(new PrivilegedExceptionAction() {
               public Object run() throws ConfigurationException {
                   service.updated( properties );
                   return null;
               }
            });
 
 
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Derek Baum Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: Re: [equinox-dev] security exceptions using Felix config admin with EquinoxDate: Wed, May 18, 2016 3:16 PM Hi,
 
I’ve also posted this to the Felix dev list, as the problem occurs when using Felix config admin with Equinox runtime.
 
I’m using org.eclipse.osgi_3.10.101.v20150820-1432.jar
 
Thanks,
 
—
Derek
 
 
On 18 May 2016, at 18:58, Derek Baum  wrote: 


I’m running with a SecurityManager installed and a trivial security.policy that grants AllPermission.
 
This works fine when running using the Felix runtime; however when I switch to Equinox I get security exceptions.
 
I’m not yet sure whether the problem lies with Felix config admin (1.8.8), Equinox runtime or elsewhere.
 
 
I’ve diagnosed the cause of the failure as follows:
 
Felix config admin ManagedServiceTracker, uses doPrivileged() to invoke the service.updated() method, with a new AccessControlContext:
 
      AccessController.doPrivileged(new PrivilegedExceptionAction() {
               public Object run() throws ConfigurationException {
                   service.updated( properties );
                   return null;
               }
            }, getAccessControlContext( service ) );
 
    AccessControlContext getAccessControlContext( final Object ref ) {
        return new AccessControlContext( new ProtectionDomain[]
            { ref.getClass().getProtectionDomain() } );
    }
 
 
Felix and Equinox return different ProtectionDomain implementations:
 
org.apache.felix.framework.BundleProtectionDomain
org.eclipse.osgi.internal.loader.ModuleClassLoader$GenerationProtectionDomain
 
 
Both implementations extend ProtectionDomain, but the Felix implementation uses the 4-arg constructor:
 
     The permissions granted to this domain are dynamic; they include     both the static permissions passed to this constructor, and any     permissions granted to this domain by the current Policy at the
     time a permission is checked.
 
while the Equinox implementation uses the 2-arg constructor.
 
    The only permissions granted to this domain
    are the ones specified; the current Policy will not be consulted
 
 
So the problem arises because Felix config admin is using doPrivileged() with a new AccessControlContext(), constructed using the target classes ProtectionDomain, and the ProtectionDomain returned when running on Equinox, does not consult the current policy, so my security policy containing grant AllPermission is ignored.
 
 
I’ve taken a quick look at the Equinox config admin implementation, and it doesn’t use doPrivileged() or a new AccessControlContext(),
so the issue does not arise.
 
 
Any opinions on whether this issue lies in Felix config admin, Equinox framework, or elsewhere?
 
 
Thanks,
 
—
Derek
 
 
 
 
 
 
 
 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Merge of equinox committer groups

[BJ Hargrave]

+1
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Thomas Watson/Austin/IBM@IBMUSSent by: equinox-dev-boun...@eclipse.orgTo: "Equinox development mailing list" , "P2 developer discussions" Cc:Subject: [equinox-dev] Merge of equinox committer groupsDate: Tue, Mar 1, 2016 8:50 AM Right now the equinox project has the following sub-projects, each with their own committer groupsrt.equinox - parent project, no real code here, but it does contain the websitert.equinox.framework - where the OSGi framework and Equinox native launcher livesrt.equinox.bundles - where everything else is, besides p2rt.equinox.p2 - where p2 isI plan to request the foundation fold rt.equinox.framework and rt.equinox.bundles into the parent project rt.equinox.  I do not think there is a need to separate committers of the various equinox bundles from committers of the framework/launcher or the website.  I do not plan to request p2 be folded into rt.equinox unless the existing p2 community of committers request that to happen.  p2 is a fairly large codebase so it makes sense to keep it separate if the committers want that.  But the rest of Equinox is not that large and maintaining 3 separate committer groups is not worth it in my opinion.Committers, please voice your concerns if you have them.Tom 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] dependency on org.osgi.annotation?

[BJ Hargrave]

> From: Stephan Herrmann 

> On 05/07/2015 05:21 PM, BJ Hargrave wrote:
> >  > User has an arbitrary plugin project which obviously depends 
ono.e.osgi.
> >
> > Well I would say that no one should depend upon org.eclipse.osgi. 
> It is an implementation of the OSGi core spec. If you are writing
> > bundles, then you are dependent on the OSGi API and should put 
> osgi.core and possibly osgi.annotation on your compile path. These
> > jars are available from OSGi Alliance website, Maven Central, 
> JCenter, ... and include their source.
> 
> Are you saying no-one should use type org.osgi.framework.Bundle, 
forexample???

Of course not. I am saying you need to compile against API jars (e.g. 
osgi.core, osgi.annotation) and not against implementation jar (e.g. 
org.eclipse.osgi). I do this all the time (with bnd/bndtools and not PDE) 
and don't have the issues you raise here.

> You read "depends" and think of a dependency declared by OSGi means,
> but that's not what I was saying. I'm speaking of the situation of
> all plug-in developers using Eclipse PDE + JDT (independent of whether
> you like PDE or not).

Well PDE is the source of the problem since it uses the manifest as both a 
build input and a build output.

> 
> 
> > Perhaps JDT is a bit too sensitive for what it not a real 
> compilation but instead just providing hover information.
> 
> You're interpretation of "compile" is narrower, than what I'm talking 
about.
> 
> Let me explain:
> Eclipse has a single component, which is responsible for many tasks,
> from creating detailed information for various views and hovers,
> over providing the precise semantic information for refactoring,
> up-to producing executable class files. We traditionally call this
> component the "compiler".
> The compiler *must* report any failed attempt to resolve a type.

Well the failed attempt to resolve a type is only an issue if the purpose 
is to create a class file. But if it is to provide hover information, then 
the missing types are not fatal. It is just reduced information available 
to the hover information.

> You seem to be saying, Eclipse shouldn't use the compiler in this way,
> but that discussion is moot.
> 
> >  > BTW, when I classified ProviderType as API, I certainly wasn't 
implying
> >  > "runtime" API. These things are compile time API, just like 
@NonNull
> >  > (which, too, has retention CLASS).
> >
> > It is necessary to compile the source. But what you are describing
> is not really compiling the source but using the source to
> > provide some hover information. So missing things should not blow 
> the whole thing up since it is not a real compilation.
> 
> You're missing the analogy to @NonNull.
> There is one more perspective between *building* o.e.osgi and *runtime*:
> Client compilation.

Well my point is the clients should not compile against an implementation: 
org.eclipse.osgi. They should compile against the API.

> But as mentioned: this is a different discussion than how to reconcile
> the incomplete artifact o.e.osgi with JDT.

I guess we disagree that org.eclipse.osgi is "incomplete". As an 
implementation, it is fully complete. It should not be used as a compile 
time dependency.

> 
> 
> I was hoping that this list could be the place for discussing,
> how to improve the experience when developing Equinox bundles
> within the Eclipse IDE with PDE and JDT.

Well I suggest that (1) JDT not have a fatal error here since the goal is 
not to generate a class file and (2) PDE should (a) not use manifest as a 
build input (but I realize that will not happen since PDE is what it is 
and why I don't use it) and (b) support a way to specify compile 
dependencies different than runtime dependencies so you can compile 
against OSGi API and not OSGi implementation. 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] dependency on org.osgi.annotation?

[BJ Hargrave]

> From: Markus Keller 

> I think we had the same discussion about a year ago: 
> 
> Bug 436469: Declare compile-time (build-time) dependencies in manifest 
> Bug 434243: Import org.eclipse.osgi[.services] as source => compile 
> errors for missing @ConsumerType 
> 
> The problem is still the same: Stephan and I think that builds 
> a) should not be monolithic, and 
> b) should not require external dependency information 

Well, first the build which makes org.eclipse.osgi is OK since it does 
build. The issue is with someone else's build using org.eclipse.osgi as a 
build dependency.

The build-time (aka compile-time) dependencies do not have to be the same 
as the runtime dependencies. That is, if you are making a bundle and using 
OSGi APIs, then you should compile against the OSGi API (e.g. osgi.core, 
osgi.annotations) rather than against an OSGi implementation (e.g. 
org.eclipse.osgi). The issue here is that the build wants to build against 
the implementation (org.eclipse.osgi) and this causes issues for JDT 
trying to display information about a CLASS retention annotation which is 
available when building org.eclipse.osgi but not when (improperly) using 
org.eclipse.osgi as a compile-time dependency.

> 
> It should be possible to build bundles that depend on other bundles 
> by just pointing the build process at the bundle's sources and at 
> its pre-built dependencies. 

Again, there is a distinction between compiling against API or against 
implementation. A bundle should compile against the API and not against 
the implementation.

> 
> But this is currently not possible because build-time dependencies 
> are missing in the bundle metadata. 
> From http://www.osgi.org/Technology/WhyOSGi : 
> "The OSGi programming model realizes the promise of component-based 
systems."
> 
> The final step to actually realize this promise would be to allow 
> for component-based builds. 

Building against the same bundle you run against is not necessarily the 
right thing. You should compile against the lowest version of the API you 
need so you can run against any implementation of a compatible version of 
the API. That is a component based build.

PDE is the source of problem here in that it treats the manifest as both 
an input to the build and an output of the build. This makes a proper 
build hard since you cannot easily specify different jars to compile 
against (API) than to run against (implementation). Bug 436469 suggests 
adding more information to the manifest to deal with this problem. 
bnd/bndtools is a better component build tool for Eclipse since it does 
not use the manifest as a build input which allows for different 
compile-time than runtime.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] dependency on org.osgi.annotation?

[BJ Hargrave]

> From: Stephan Herrmann 

> I was asking about the following scenario:
> 
> User has an arbitrary plugin project which obviously depends on 
o.e.osgi.

Well I would say that no one should depend upon org.eclipse.osgi. It is an 
implementation of the OSGi core spec. If you are writing bundles, then you 
are dependent on the OSGi API and should put osgi.core and possibly 
osgi.annotation on your compile path. These jars are available from OSGi 
Alliance website, Maven Central, JCenter, ... and include their source.

> I'm not speaking of building o.e.osgi, but about consuming.
> 
> In the workspace s/he has references to o.e.osgi as jar with source 
> attachment.
> 
> When the user browses / inspects types from o.e.osgi, JDT uses the jar 
plus
> its source attachment in order to present javadoc hovers and such.
> Behind the scenes javadoc computation uses the sources and compiles them
> on the fly in order to provide semantic, rather than syntactic 
information.
> 
> The problem is: this in-memory compilation of attached sources fails due
> to unresolved references to an annotation type "ProviderType".
> Normally, JDT's javadoc hovers would know the fully qualified name of
> any annotations and even support navigation to the type. For 
ProviderType
> this is not possible, because that name cannot be resolved.
> Still worse, for the javadoc of any API method that mentions another 
type
> which in turn is annotated as @ProviderType this transitive lookup 
fails,
> causing JDT to abort this compilation because obviously our classpath
> is incorrect. Hence semantic information for javadoc hovers may just be
> unavailable for affected elements.

Perhaps JDT is a bit too sensitive for what it not a real compilation but 
instead just providing hover information.

> 
> BTW, when I classified ProviderType as API, I certainly wasn't implying
> "runtime" API. These things are compile time API, just like @NonNull
> (which, too, has retention CLASS).

It is necessary to compile the source. But what you are describing is not 
really compiling the source but using the source to provide some hover 
information. So missing things should not blow the whole thing up since it 
is not a real compilation.

>  If an API exposes annotations, the
> declaration for that annotation must be visible for compilation of 
client
> source. If the annotation would be relevant only while compiling 
o.e.osgi
> itself, then I would deem a retention SOURCE much more suitable. By 
saying
> "CLASS" you are making this annotation *visible* to *compilation* of 
client
> sources, but you are not telling, what the annotation is. In terms of 
API
> Tools this should be considered as an API leak.
> But these are semantic issues, not relevant to the tooling problem at 
hand.
> 
> IMHO, either the source attachment is incomplete or the bundle must 
declare
> a dependency on the artifact containing the annotation declaration.

It is wrong to declare a dependency from org.eclipse.osgi to the 
osgi.annotations since such a dependency is a runtime dependency and there 
is in fact no runtime dependency on these annotations. Just a compile-time 
dependency. And in the situation you describe, the source code does not 
really need to be compiled.

> 
> The question is: how do you advise JDT to perform its on-the-fly 
compilation
> while working on a client project depending on o.e.osgi, which is 
available
> as jar + source attachment? 

How about don't fail when you can't find something just to make hover 
information? :-)

> Currently, JDT concludes that the sourceattachment
> of o.e.osgi is broken.
> 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] dependency on org.osgi.annotation?

[BJ Hargrave]

> From: Stephan Herrmann 

> I've observed, that JDT has problems working with class file
> plus source attachment of org.osgi.framework.Bundle et al.
> Reason: when compiling the attached sources we can't find
> the annotation type org.osgi.annotation.versioning.ProviderType.
> I see that Equinox has the corresponding jar in its git repo,
> but the deployed org.eclipse.osgi doesn't seem to contain any
> hint on where this type could be found.

So you issue is that the org.eclipse.osgi jar file does not contain the 
annotation classes?

If you are compiling the OSGi sources in the  org.eclipse.osgi repo, you 
can get the annotations jar from the git repo too. I don't believe any of 
the Equinox source uses the OSGi versioning annotations.

> 
> Now, if the annotation had retention SOURCE, one might argue
> that after compilation the annotation no longer exists
> (which would still create a challenge for the compiler to
> find that the annotation we don't find is missing for a good
> reason - for detecting the SOURCE retention we would need to
> find the annotation in the first place).
> 
> With a CLASS retention, however, this annotation should IMHO
> be considered part of the API and without a dependency this
> makes it a secret clause as part of the public API, mhhh...

No. CLASS retention is not part of the runtime API since such annotations 
are not visible at runtime. They are visible at tool time such as when bnd 
packages bundles and uses information from the versioning annotations. 
Therefore the tools need access to the annotation types (which they will 
make sure they have). You also need access to compile the classes and the 
source repo provides the annotations in jar form.

> 
> Am I misreading something? Any suggestions how the compiler
> can cope with this fatal error on a published artifact?

I am not entirely clear on what you are doing here. Perhaps you can 
explain in more detail.

> 
> Who is supposed to use the information about this annotation?

Tools like bnd. They advise tools about the package version and whether 
types in the package are provider or consumer role. See the OSGi Semantic 
Versioning paper for more information on these roles. 
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

> How does that instance get access to the annotation definition?

The tool must of course have knowledge of the semantic meaning of the 
annotations. Since the tool is not loading the classes (and they are CLASS 
retention), the tools processes the class file'  bytecodes.
> 
> FYI, the problem occurs when JDT/UI functionality requests
> the resolved types of methods in the given interface.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] equinox ds

[BJ Hargrave]

OSGi is using Felix SCR. Currently private builds of the development work. 
I expect that Felix SCR will ship in a time such that OSGi could use the 
final build for the RI. You should check with the Felix SCR guys.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Scott Lewis 
To: equinox-dev@eclipse.org
Date:   2015/02/20 12:40
Subject:Re: [equinox-dev] equinox ds
Sent by:equinox-dev-boun...@eclipse.org



On 2/20/2015 9:10 AM, Cristiano Gavião wrote:
Hi Scott,

Felix SCR guys already implemented some tasks related to RFC 190:

https://issues.apache.org/jira/browse/FELIX-4403
https://issues.apache.org/jira/browse/FELIX-4769
https://issues.apache.org/jira/browse/FELIX-4405
https://issues.apache.org/jira/browse/FELIX-4391

Not done yet:
https://issues.apache.org/jira/browse/FELIX-4401

I have played a bit with the version 2.0.0-SNAPSHOT a month ago, but 
looking the code today it seems that they returned to 1.8.3-SNAPSHOT. Will 
question them about that.

regards,

Cristiano

Thanks Cristiano, I will track the Felix SCR work/version/bugs as well.

BJ:  What is being used for the R6 ref impl?  (some snapshot version of 
Felix SCR?)

Thanks,

Scott
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] equinox ds

[BJ Hargrave]

See http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08088.html
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Scott Lewis 
To: Equinox development mailing list 
Date:   2015/02/19 20:04
Subject:[equinox-dev] equinox ds
Sent by:equinox-dev-boun...@eclipse.org



Questions:

1) Has the org.eclipse.equinox.ds implementation of Declarative Services 
yet incorporated the additions from RFC190?  The version in Mars M5 
appears to be org.eclipse.equinox.ds_1.4.200.v20131126-2331 which based 
upon qualifier I would guess doesn't have support for RFC190, but wanted 
to ask anyway.

2) Assuming the answer to 1 is 'no', what implementation(s) of DS *do* 
currently support RFC190?

3) Are there plans to update org.eclipse.equinox.ds to support RFC190?

Thanksinadvance,

Scott



___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Exporting packages without a version

[BJ Hargrave]

equinox-dev-boun...@eclipse.org wrote on 2014/12/11 09:08:19:

> From: Dennis Hübner 
> To: equinox-dev@eclipse.org
> Date: 2014/12/11 09:10
> Subject: [equinox-dev] Exporting packages without a version
> Sent by: equinox-dev-boun...@eclipse.org
> 
> Hi equinox-dev team,
> 
> I have a question regarding exporting an unversioned package.
> If I look over the bundles in eclipse, the most of them (expect of 
> some orbit bundles) exports packages without a version.
> We do it likewise e.g.:
> 
> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-Name: Xbase Runtime Library
> Bundle-SymbolicName: org.eclipse.xtext.xbase.lib
> Bundle-Version: 2.8.0.qualifier
> Bundle-RequiredExecutionEnvironment: J2SE-1.5
> Export-Package: org.eclipse.xtend2.lib,
>  org.eclipse.xtext.xbase.lib,
>  org.eclipse.xtext.xbase.lib.internal;x-internal:=true,
>  org.eclipse.xtext.xbase.lib.util
> 
> In an osqi container I see that this packages are exported with 0.0.
> 0 it doesn’t care what the bundle-version is:
> osgi>  b 584
> org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]
>   Id=584, Status=RESOLVEDData Root=/Users/dhuebner/Entwicklung/
> xtext-new/eclipse/configuration/org.eclipse.osgi/584/data
>   "No registered services."
>   No services in use.
>   Exported packages
> org.eclipse.xtend2.lib; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib.internal; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib.util; version="0.0.0"[exported]
>   Imported packages
> com.google.common.annotations; version="15.0.0" 
> 
> co
> 
> osgi>  b 626
> org.eclipse.xtext.xbase.lib_2.8.0.v20141037 [626]
>   Id=626, Status=RESOLVEDData Root=/Users/dhuebner/Entwicklung/
> xtext-new/eclipse/configuration/org.eclipse.osgi/626/data
>   "No registered services."
>   No services in use.
>   Exported packages
> org.eclipse.xtend2.lib; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib.internal; version="0.0.0"[exported]
> org.eclipse.xtext.xbase.lib.util; version="0.0.0"[exported]
>   Imported packages
> com.google.common.annotations; version="15.0.0" 
> 
> com.goo
> 
> I thought, that if my bundle exports a package without a version, it
> means, that the version is the same as a Bundle-Version. But from 
> what I see in the osgi console it seems that I’m wrong.

If the manifest file in the bundle does not export packages with a 
version, then the version of the packages is 0.0.0. 
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#emptyVersion

Some tools which take input for the manifest may put the bundle version on 
the exported packages if no version is specified (in the generated 
bundle). But that is a tool choice and not part of the OSGi 
specifications.

> 
> osgi> b org.eclipse.xtend.lib
> org.eclipse.xtend.lib_2.8.0.v20141037 [544]
>   Id=544, Status=RESOLVEDData Root=/Users/dhuebner/Entwicklung/
> xtext-new/eclipse/configuration/org.eclipse.osgi/544/data
>   "No registered services."
>   No services in use.
>   Exported packages
> org.eclipse.xtend.lib; version="0.0.0"[exported]
> org.eclipse.xtend.lib.annotations; version="0.0.0"[exported]
>   Imported packages
> com.google.common.annotations; version="15.0.0" 
> 
> ...
> org.eclipse.xtext.xbase.lib; version="0.0.0" 
> 
> org.eclipse.xtext.xbase.lib; version="0.0.0" 
> 
> org.eclipse.xtext.xbase.lib.internal; version="0.0.0" 
> 
> org.eclipse.xtext.xbase.lib.internal; version="0.0.0" 
> 
> org.eclipse.xtext.xbase.lib.util; version="0.0.0" 
> 
> org.eclipse.xtext.xbase.lib.util; version="0.0.0" 
> 
>   No fragment bundles
>   Required bundles
> osgi.identity; osgi.identity="org.eclipse.xtext.xbase.lib"; 
> type="osgi.bundle"; version:Version="2.8.0.v20141037"
> osgi.identity; osgi.identity="org.eclipse.xtend.lib.macro"; 
> type="osgi.bundle"; version:Version="2.8.0.v20141037"
> 
> My question is, which package will be wired if an another bundle 
> require (using Require-Bundle) an xbase.lib bundle with version 
> constraint 2.8.0?
> 
> 

No one should use Require-Bundles. It is so messy. But if you require a 
bundle, you get the package in the actual bundle that is required.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] persistently identify a container

[BJ Hargrave]

I think this is in the problem space of RFC 183. 
https://github.com/osgi/design/raw/master/rfcs/rfc0183/rfc-0183-CloudEcosystems.pdf
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list 
Date:   2014/10/30 10:11
Subject:Re: [equinox-dev] persistently identify a container
Sent by:equinox-dev-boun...@eclipse.org



I changed the subject of the chain also, it was (no subject) before :) 

We could provide some UUID that represents the storage area used for the 
running framework.  But that also has issues because we allow multiple 
instances to be run out of the same read-only storage area.  But I could 
see that working as long as you ensure that you only launch one framework 
per framework storage area.  Perhaps you should open a bugzilla to 
discuss.  We could consider prototyping something in Equinox and then if 
it turns out to work well propose it back to the OSGi specification. 

Tom





From:Cristiano Gavião  
To:Equinox  
Date:10/29/2014 01:10 PM 
Subject:Re: [equinox-dev] (no subject) 
Sent by:equinox-dev-boun...@eclipse.org 



I wrongly pressed the button before complete the message, sorry.

The question is, what is a good alternative to persistently identify a 
container in the network? 

2014-10-29 16:07 GMT-02:00 Cristiano Gavião : 
Iwould like to create a master table of installed OSGi framework 
containers in the network (using Zookeeper or other like it) and 
centralize configuration properties for them.

Initially I thought about using the 
org.osgi.framework.Constants.FRAMEWORK_UUID property. But I found that 
this value is generated every time the framework is relaunched.

-- 
"Tudo vale a pena se a alma não é pequena..." 



-- 
"Tudo vale a pena se a alma não é pequena..." 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

Here is why gogo.command can cause file installer to be swept upon the 
refresh:

gogo.command exports log:

Export-Package: 
org.osgi.service.log;uses:="org.osgi.framework";version="1.3"

And file installer imports log. So, depending on how the resolution goes, 
file installer can depend upon gogo.command. So if gogo.command is then 
refreshed, file installer will also be refreshed. And given the bad 
locking design in file installer, file installer will deadlock.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Apache Felix Developers 
Cc: Equinox development mailing list 
Date:   2014/09/29 15:19
Subject:Re: [equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



Ok here goes:

Using the following class:

https://gist.github.com/rotty3000/fcd47c42cb0a12141f52

compile and execute with:

java -classpath  FIAndEquinoxTest

Once running, drop 
http://archive.apache.org/dist/felix/org.apache.felix.gogo.command-0.12.0.jar 
into the ${user.home}/osgi-deploydir

Get a stackdump using jstack (get pid from jps)

You'll see the very same result from the earlier dumps I posted.

NOTE: ODDLY, This only seems to happen with org.apache.felix.gogo.command.

On Mon, Sep 29, 2014 at 2:39 PM, Raymond Auge  
wrote:
I've reproduced the issue with a minimal impl. I'll post that shortly.

On Mon, Sep 29, 2014 at 1:53 PM, Jamie G.  
wrote:
FileInstall and Equinox should be able to play nicely together - that
combination has been used in Apache Karaf deployments for a while...

Could you try out your scenario with a Karaf container with Equinox
set as its OSGi core?

--J

On Mon, Sep 29, 2014 at 2:57 PM, Raymond Auge  
wrote:
> Ok, so I did have:
>
> a) some fileinstall artifact handlers in a bundle being refreshed
> b) config admin bundle being refresh
>
> Both of those would probably have pulled FI into the fresh.
>
> However, I removed those (and delete the equinox state) but still get 
the
> same exact issue.
>
> On Mon, Sep 29, 2014 at 1:12 PM, Raymond Auge 
> wrote:
>
>> Ok, sooo I think I understand the issue.
>>
>> We have a protocol handler deployed for fileinstall's custom artifact
>> handling.
>>
>> I guess that must be pulling FI into the fresh.
>>
>> I'll take that bundle out and see if I get the same problem or not.
>>
>> - Ray
>>
>> On Mon, Sep 29, 2014 at 1:06 PM, Raymond Auge 
>> wrote:
>>
>>> Sorry I forgot to mention I'm cross posting to felix list also.
>>>
>>> Anyhow, here is a stacktrace which shows the locking (search for
>>> fileinstall).
>>>
>>> - Ray
>>>
>>> On Mon, Sep 29, 2014 at 12:57 PM, BJ Hargrave 
>>> wrote:
>>>
>>>> Is there a bug/issue with the details? I don't know any details here.
>>>> What is the "concurrency issue with package refresh"?
>>>> --
>>>>
>>>>  *BJ Hargrave*
>>>> Senior Technical Staff Member, IBM
>>>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>
>>>> *hargr...@us.ibm.com* 
>>>>
>>>> office: +1 386 848 1781
>>>> mobile: +1 386 848 3788
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From:Raymond Auge 
>>>> To:Equinox development mailing list ,
>>>> Apache Felix Developers 
>>>> Date:2014/09/29 12:52
>>>> Subject:[equinox-dev] fileinstall & equinox solution
>>>> Sent by:equinox-dev-boun...@eclipse.org
>>>> --
>>>>
>>>>
>>>>
>>>> Will there ever be a solution to the fileinstall on equinox issue?
>>>>
>>>> It seems that fileinstall has not worked on equinox for some time due 
to
>>>> the concurrency issue with package refresh.
>>>>
>>>> I believe 3.1.10 is the last version that works on equinox.
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>  (@rotty3000)
>>>> Senior Software Architect
>>>> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
>>>> ___
>>>> equinox-dev mailing list
>>>> equinox-dev@eclipse.org
>>>> To change your delivery options, retrieve your password, or 
unsubscribe
>>>> from this list, visit
>&

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

This thread owns that lock:

"fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10 
tid=0x7f7324017000 nid=0x2b89 waiting on condition 
[0x7f738bdfc000]
   java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for  <0x000787811a98> (a 
java.util.concurrent.CountDownLatch$Sync)
 at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
 at 
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
 at 
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)

And then while holding that lock, calls refresh on the framework which is 
an asynchronous operation.

This seems like a bad design for file installer. You generally should not 
hold lock while triggering an async operation that can call back into you 
on another thread.

File installer is borked. If you can figure out how to not get fail 
installer swept up on the refresh you can avoid the design flaw in file 
installer but file installer needs a better locking design. I do not see 
any issue with Equinox here.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   BJ Hargrave/Austin/IBM@IBMUS
To: Equinox development mailing list 
Date:   2014/09/29 14:13
Subject:Re: [equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



The second thread dump shows that the fileinstaller BundleActivator.stop 
method is blocked 

"Refresh Thread: Equinox Container: b0d7b641-fc47-0014-11e3-e5afcb018d39" 
daemon prio=10 tid=0x7f732a74e800 nid=0x2b87 waiting on condition 
[0x7f738bffd000] 
   java.lang.Thread.State: WAITING (parking) 
 at sun.misc.Unsafe.park(Native Method) 
 - parking to wait for  <0x000783a3fa20> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) 
 at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) 
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 

 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
 

 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
 

 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
 

 at 
org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171) 

 at 
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827)
 

 at 
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
 

 at java.security.AccessController.doPrivileged(Native 
Method) 
 at 
org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820)
 


on the same lock as the file installer's directory watcher. 

"fileinstall-/home/rotty/AS/liferay-portal/osgi/modules" daemon prio=10 
tid=0x7f732401f800 nid=0x2b8b waiting on condition 
[0x7f738bbfa000] 
   java.lang.Thread.State: WAITING (parking) 
 at sun.misc.Unsafe.park(Native Method) 
 - parking to wait for  <0x000783a3fa20> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) 
 at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) 
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 

 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
 

 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquir

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

The second thread dump shows that the fileinstaller BundleActivator.stop 
method is blocked 

"Refresh Thread: Equinox Container: b0d7b641-fc47-0014-11e3-e5afcb018d39" 
daemon prio=10 tid=0x7f732a74e800 nid=0x2b87 waiting on condition 
[0x7f738bffd000]
   java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for  <0x000783a3fa20> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
 at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
 at 
org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
 at 
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827)
 at 
org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1)
 at java.security.AccessController.doPrivileged(Native 
Method)
 at 
org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820)

on the same lock as the file installer's directory watcher. 

"fileinstall-/home/rotty/AS/liferay-portal/osgi/modules" daemon prio=10 
tid=0x7f732401f800 nid=0x2b8b waiting on condition 
[0x7f738bbfa000]
   java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for  <0x000783a3fa20> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
 at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(ReentrantReadWriteLock.java:776)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:355)
 at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
 
This seems like the file installer is blocking Bundle.stop. It would seem 
that BundleActivator.stop should interrupt those watcher threads to allow 
an orderly shutdown.

There may be a second order issue of why file installer is getting swept 
up on the refresh. But the first order problem is why wont file installer 
stop when requested.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/09/29 13:47
Subject:Re: [equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



Sorry, I thought I linked one, but apparently missed the link.

when I did have pieces which may have pulled in FI
https://gist.github.com/rotty3000/33a5f1fb0b1c3627a20a

after removing those pieces
https://gist.github.com/rotty3000/8c0a41b6aa633c1aebd7



On Mon, Sep 29, 2014 at 1:40 PM, BJ Hargrave  wrote:
Stacktrace? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list , 
Apache Felix Developers  
Date:2014/09/29 13:07 
Subject:Re: [equinox-dev] fileinstall & equinox solution 
Sent by:equinox-dev-boun...@eclipse.org 



Sorry I forgot to mention I'm cross posting to felix list also. 

Anyhow, here is a stacktrace which shows the locking (search for 
fileinstall). 

- Ray 

On Mon, Sep 29, 2014 at 12:57 PM, BJ Hargrave  wrote: 

Is there a bug/issue with the details? I don't know any details here. What 
is the "concurrency issue with package refresh"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list , 
Apache Felix Develop

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

Yes. It does appear that you have allowed fileinstaller to become sucked 
up on the refresh. Is there a reasonable small test case to reproduce and 
see why fileinstaller is being refreshed?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/09/29 13:47
Subject:Re: [equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



Sorry, I thought I linked one, but apparently missed the link.

when I did have pieces which may have pulled in FI
https://gist.github.com/rotty3000/33a5f1fb0b1c3627a20a

after removing those pieces
https://gist.github.com/rotty3000/8c0a41b6aa633c1aebd7



On Mon, Sep 29, 2014 at 1:40 PM, BJ Hargrave  wrote:
Stacktrace? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list , 
Apache Felix Developers  
Date:2014/09/29 13:07 
Subject:Re: [equinox-dev] fileinstall & equinox solution 
Sent by:equinox-dev-boun...@eclipse.org 



Sorry I forgot to mention I'm cross posting to felix list also. 

Anyhow, here is a stacktrace which shows the locking (search for 
fileinstall). 

- Ray 

On Mon, Sep 29, 2014 at 12:57 PM, BJ Hargrave  wrote: 

Is there a bug/issue with the details? I don't know any details here. What 
is the "concurrency issue with package refresh"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list , 
Apache Felix Developers  
Date:2014/09/29 12:52 
Subject:[equinox-dev] fileinstall & equinox solution 
Sent by:equinox-dev-boun...@eclipse.org 




Will there ever be a solution to the fileinstall on equinox issue? 

It seems that fileinstall has not worked on equinox for some time due to 
the concurrency issue with package refresh. 

I believe 3.1.10 is the last version that works on equinox. 

-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

Stacktrace?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list , Apache 
Felix Developers 
Date:   2014/09/29 13:07
Subject:Re: [equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



Sorry I forgot to mention I'm cross posting to felix list also.

Anyhow, here is a stacktrace which shows the locking (search for 
fileinstall).

- Ray

On Mon, Sep 29, 2014 at 12:57 PM, BJ Hargrave  wrote:
Is there a bug/issue with the details? I don't know any details here. What 
is the "concurrency issue with package refresh"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list , 
Apache Felix Developers  
Date:2014/09/29 12:52 
Subject:[equinox-dev] fileinstall & equinox solution 
Sent by:equinox-dev-boun...@eclipse.org 




Will there ever be a solution to the fileinstall on equinox issue? 

It seems that fileinstall has not worked on equinox for some time due to 
the concurrency issue with package refresh. 

I believe 3.1.10 is the last version that works on equinox. 

-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] fileinstall & equinox solution

[BJ Hargrave]

Is there a bug/issue with the details? I don't know any details here. What 
is the "concurrency issue with package refresh"?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list , Apache 
Felix Developers 
Date:   2014/09/29 12:52
Subject:[equinox-dev] fileinstall & equinox solution
Sent by:equinox-dev-boun...@eclipse.org



Will there ever be a solution to the fileinstall on equinox issue?

It seems that fileinstall has not worked on equinox for some time due to 
the concurrency issue with package refresh.

I believe 3.1.10 is the last version that works on equinox.

-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Compilation error in Java 7

[BJ Hargrave]

This probably has to do with compiling against classfiles built with the 
undocumented javac option "-targer jsr14". Such class files work fine with 
javac 1.6 which recognized the generics information. However javac 1.7 
does not and sees the classes only a "raw" view. You either need to keep 
using javac 1.6 or get updated jar files which are not compiled with 
"-target jsr14". 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Aruna Karunarathna 
To: equinox-dev@eclipse.org
Date:   2014/09/22 06:10
Subject:[equinox-dev] Compilation error in Java 7
Sent by:equinox-dev-boun...@eclipse.org



Hi Devs,

I have a code segment as follows.

IQuery it = null;

Following is my dependency


org.eclipse.equinox
org.eclipse.equinox.p2.metadata
2.1.0.v20110510


when I try to compile in Java 6 it works perfectly. But when I tried to 
compile with java 7 it gives me the following error.

java: type org.eclipse.equinox.p2.query.IQuery does not take parameters

Any idea what I'm doing wrong here? Do we need a later version in order to 
work with Java 7?

Regards,
Aruna___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Declarative Service and support of TargetPID ?

[BJ Hargrave]

I don't believe it does. Support for target PIDs is not even in the DS 
spec yet. It will be added in the next spec release via RFC 190 [1].

[1] 
https://github.com/osgi/design/raw/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Cristiano Gavião 
To: Equinox development mailing list 
Date:   2014/08/25 09:44
Subject:[equinox-dev] Declarative Service and support of TargetPID 
?
Sent by:equinox-dev-boun...@eclipse.org



Hello,

I'm trying to create a Configuration using a targetPID as defined in 
Configuration Admin Service spec 1.5(cmpn.5.0).

I created a factory config using this targetPID: 
servicefactory1|org.c4biz.utils.osgi.itests.samples.bundle|88.0.0
and CM seems have properly created the PID and properties are ok too:
 
servicefactory1|org.c4biz.utils.osgi.itests.samples.bundle|88.0.0-1408970963277-1

Even the configuration being properly created my declarative services 
based component (using configuration-policy = require) are not being 
activated with that configuration. but when I try with 'servicefactory1' 
only it works as expected.

So, am I missing something or Equinox DS doesn't support TargetPID yet ? 

thanks,

Cristiano___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Resource not found inside bundle

[BJ Hargrave]

The problem is: What is the context class loader of the thread? Did you 
set one up? OSGi is generally mute on the subject of context class loaders 
and does not mess with them.

Since you know that the resource is visible to your bundle, it would be 
better to use your class' class loader to call getResources.

ClassLoader loader = getClass().getClassLoader();
...
Enumeration urls = loader.getResources("api_mapping.xml");


-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   David Cao 
To: Equinox development mailing list 
Date:   2014/07/28 16:51
Subject:Re: [equinox-dev] Resource not found inside bundle
Sent by:equinox-dev-boun...@eclipse.org



So I see conflict answers ... 

To Raymond, I will give a quick try from the Activator of your method. 
Thank!!

To BJ, the code is something like this,

ClassLoader loader = Thread.currentThread().getContextClassLoader();
...
Enumeration urls = loader.getResources("api_mapping.xml");
...

Do you see a problem? What I am doing here is to convert an existing web 
app into OSGi framework via Servlet bridge for Tomcat 6. The classloading 
code is from the non-bundle web app ...

thanks a lot!!



On Mon, Jul 28, 2014 at 5:14 PM, BJ Hargrave  wrote:
That file does appear to be in the classpath. The picture shows it in 
WEB-INF/classes which is in the Bundle-ClassPath. What does the code look 
like that is trying to access the file? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list  
Date:2014/07/28 16:02 
Subject:Re: [equinox-dev] Resource not found inside bundle 
Sent by:equinox-dev-boun...@eclipse.org 




That file is not in the classpath of the bundle and so you can't use the 
"resource" API. 

However, you can use the "entry" API (which talks about the bundle rather 
than about the bundle's classpath).

e.g. 

URL url = bundle.getEntry("api_mapping.xml");

IF you have a class however, and you need to get to the bundle of the 
class, you can do

Bundle bundle = FrameworkUtil.getbundle(this.getClass());

URL url = bundle.getEntry("api_mapping.xml");

HTH 


On Mon, Jul 28, 2014 at 12:57 PM, David Cao  wrote: 
Hello there, 

I have a bundle jar file basically converted from a .war file, with 
"Bundle-ClassPath" set as follow, 

Bundle-Localization: plugin 
Bundle-ClassPath: WEB-INF/classes, 
 WEB-INF/lib/activation-1.1.jar, 
 WEB-INF/lib/antlr-2.7.5.jar, 
... 
Import-Package: javax.servlet, 
 javax.servlet.http, 
 org.osgi.framework;version="1.3.0", 
 org.osgi.service.http;version="1.2.0", 
 org.osgi.util.tracker;version="1.3.1" 


There is an internal class which depends on a "api_mapping.xml" file which 
is located under "WEB-INF/classes" (shown below). However, the class 
complains unable to find the .xml file.  

I wonder if I missed some manifest descriptors for resources? does anyone 
have an idea why this is happening? Thanks a lot!! 



​ 




___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Resource not found inside bundle

[BJ Hargrave]

That file does appear to be in the classpath. The picture shows it in 
WEB-INF/classes which is in the Bundle-ClassPath. What does the code look 
like that is trying to access the file?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/07/28 16:02
Subject:Re: [equinox-dev] Resource not found inside bundle
Sent by:equinox-dev-boun...@eclipse.org



That file is not in the classpath of the bundle and so you can't use the 
"resource" API.

However, you can use the "entry" API (which talks about the bundle rather 
than about the bundle's classpath).

e.g.

URL url = bundle.getEntry("api_mapping.xml");

IF you have a class however, and you need to get to the bundle of the 
class, you can do

Bundle bundle = FrameworkUtil.getbundle(this.getClass());

URL url = bundle.getEntry("api_mapping.xml");

HTH


On Mon, Jul 28, 2014 at 12:57 PM, David Cao  wrote:
Hello there,

I have a bundle jar file basically converted from a .war file, with 
"Bundle-ClassPath" set as follow,

Bundle-Localization: plugin
Bundle-ClassPath: WEB-INF/classes,
 WEB-INF/lib/activation-1.1.jar,
 WEB-INF/lib/antlr-2.7.5.jar,
...
Import-Package: javax.servlet,
 javax.servlet.http,
 org.osgi.framework;version="1.3.0",
 org.osgi.service.http;version="1.2.0",
 org.osgi.util.tracker;version="1.3.1"


There is an internal class which depends on a "api_mapping.xml" file which 
is located under "WEB-INF/classes" (shown below). However, the class 
complains unable to find the .xml file. 

I wonder if I missed some manifest descriptors for resources? does anyone 
have an idea why this is happening? Thanks a lot!!



​




___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Resolver Problem with guava and e4 (javax.annotation)

[BJ Hargrave]

Importing what you export is only useful when the bundle contains other 
packages which actually use the exported package. For example, a bundle 
implements the OSGi Event Admin service. That bundle can export the 
org.osgi.service.event package and also import it. The bundle is happy to 
use any (version matching) org.osgi.service.event package.

But if the bundle is just a "container" of packages which it exports for 
other and does not itself use the packages in anyway, then there is less 
value in also importing the packages. Say a bundle just contains the 
org.osgi.service.event package and exports it as well as imports it. If 
this bundle is resolved to import the package, the bundle is essentially 
empty. It is not exporting the package and has no other packages.

I don't know the make up of the bundles in question here. But is may or 
may not make sense to import the packages being exported. What the bundle 
contains will influence the choice. That being said, there is little harm 
in also importing the packages, so it is a safe (but perhaps of little 
value) choice.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Andreas Sewe 
To: equinox-dev@eclipse.org, orbit-...@eclipse.org
Date:   2014/07/11 04:38
Subject:Re: [equinox-dev] Resolver Problem with guava and e4 
(javax.annotation)
Sent by:equinox-dev-boun...@eclipse.org



David M Williams wrote:
> I notice in Orbit, all our "javax.annotation" bundles follow the import
> what you export pattern  that's good, such as
> 
> *Export-Package*: javax.annotation;/version/="1.2.0",
>  javax.annotation.security;/version/="1.2.0",
>  javax.annotation.sql;/version/="1.2.0"
> *Import-Package*: javax.annotation;/version/="1.2.0",
>  javax.annotation.security;/version/="1.2.0",
>  javax.annotation.sql;/version/="1.2.0"

Is this "import what you export" best practice for *all* javax.* bundles
in Orbit? As far as I can see, some of them don't follow this policy
(javax.xml.bind, for example, whose packages are also provided by the
system bundle provides at least from Java 7 onwards) and I am wondering
whether it's worth opening bugs for this.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[BJ Hargrave]

You don't have to manage the instance. The framework, per spec, must cache 
the instance the return it for future BundleContext.getService calls.

I am quite sure Equinox is fine here. Never heard of a problem in this 
area. You don't mention what version you use.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/04/28 16:24
Subject:[equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



Hey all,

I have to write code as follows in a ServiceFactory impl in order for my 
factory to always return the same instance per bundle running on 
equinox 3.8.0.v20120529-1548

===
public HttpService getService(
Bundle bundle, ServiceRegistration registration) {

HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

if (httpServiceImpl != null) {
return httpServiceImpl;
}

httpServiceImpl = new HttpServiceImpl(
bundle, contextController, legacyServiceIdGenerator);

serviceMap.putIfAbsent(bundle, httpServiceImpl);

return httpServiceImpl;
}
===

This seems clearly wrong as per the spec. 

It's certainly calling the getService method of the ServiceFactory which 
I'm guessing means it's not incorrectly registered.

What could I be doing wrong? Was this ever a bug in equinox that was later 
resolved?

-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
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] OSGi R6 Log service ?

[BJ Hargrave]

The framework should register an org.osgi.service.log.LogService upon 
startup. Implementing the LogService in the Equinox framework is an 
implementation decision and not required by the OSGi specs.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Cristiano Gavião 
To: Equinox development mailing list 
Date:   2014/04/10 09:39
Subject:[equinox-dev] OSGi R6 Log service ?
Sent by:equinox-dev-boun...@eclipse.org



Hello,

I read here [1] that a R6 Log Service will be part of Luna. But I 
couldn't find any reference to that in bugzilla or any RFC [2].

Could someone explain me this change or point me to the right place?

thanks,

Cristiano

[1] - http://projects.eclipse.org/projects/rt.equinox/releases/4.4.0/plan
[2] - http://wiki.osgi.org/wiki/RFCs
___
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] branch for R6

[BJ Hargrave]

Just put a copy of osgi.annotation.jar in your repo. It's not big :-) Then 
you are self-contained.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/04/10 09:44
Subject:Re: [equinox-dev] branch for R6
Sent by:equinox-dev-boun...@eclipse.org



Next concern is that this is a cross repo dependency.

Is it ok for a bundle in one repo to reference a bundle in another repo?

jars.extra.classpath = 
platform:/plugin/org.eclipse.osgi/osgi/osgi.annotation.jar

Aren't these repos "theoretically" standalone for the purpose of building?

- Ray


On Thu, Apr 10, 2014 at 9:08 AM, Thomas Watson  
wrote:
For what its worth, the equinox build does build against the OSGi classes 
from other bundles in equinox.  BJ says, people should also not compile 
against an OSGi framework implementation to get OSGi packages.  That may 
be true, but in equinox our bundles most definitely do compile against 
org.eclipse.osgi to get the core osgi packages because in our build 
org.eclipse.osgi is considered just another bundle.  That is just how our 
mavin/tycho build works.

Other than that tidbit I agree with BJ about how to proceed with the 
annotations.jar.

Tom



BJ Hargrave---04/10/2014 06:49:08 AM---See  
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/osgi/os


From: BJ Hargrave/Austin/IBM@IBMUS
To: Equinox development mailing list , 
Date: 04/10/2014 06:49 AM
Subject: Re: [equinox-dev] branch for R6

Sent by: equinox-dev-boun...@eclipse.org



See 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/osgi/osgi.annotation.jar
. The projects build.properties includes it as an extra jar: 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/build.properties#n34
 

The org.osgi.annotation.versioning package is not a runtime package. 
Therefore, an OSGi framework must not include that package and must not 
export that package at runtime. People should also not compile against an 
OSGi framework implementation to get the OSGi packages. 

Your project can do the same for osgi.annotation.jar as the 
org.eclipse.osgi project. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list  
Date:2014/04/09 22:26 
Subject:[equinox-dev] branch for R6 
Sent by:equinox-dev-boun...@eclipse.org 



Is there an rt.equinox.framework R6 branch? 

I don't see one which includes org.osgi.annotation.versioning package. 

The latest http spec depends on this annotation unless I strip the Version 
package annotation from this work. 

Thoughts? 

-- 
Raymond Augé (@rotty3000) 
Senior Software Architect 
Liferay, Inc. (@Liferay) 
___
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




-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
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] branch for R6

[BJ Hargrave]

See 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/osgi/osgi.annotation.jar
. The projects build.properties includes it as an extra jar: 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/build.properties#n34

The org.osgi.annotation.versioning package is not a runtime package. 
Therefore, an OSGi framework must not include that package and must not 
export that package at runtime. People should also not compile against an 
OSGi framework implementation to get the OSGi packages.

Your project can do the same for osgi.annotation.jar as the 
org.eclipse.osgi project.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/04/09 22:26
Subject:[equinox-dev] branch for R6
Sent by:equinox-dev-boun...@eclipse.org



Is there an rt.equinox.framework R6 branch?

I don't see one which includes org.osgi.annotation.versioning package.

The latest http spec depends on this annotation unless I strip the Version 
package annotation from this work.

Thoughts?

-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
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] Serious problems with EE Java 1.8 (and EE resolving in general) on Luna

[BJ Hargrave]

If you change the underlying JRE, you should probably launch with -clean 
to flush the cached resolve state.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Tom Schindl 
To: equinox-dev@eclipse.org
Date:   2014/04/09 08:16
Subject:[equinox-dev] Serious problems with EE Java 1.8 (and EE 
resolving in general) on Luna
Sent by:equinox-dev-boun...@eclipse.org



Hi,

I'm encountering strange problems with Luna M6 and EE 1.8. The scenario
is like this:

We provide a prebuilt distro where bundles require an EE of 1.8 if I
download this distro and launch the IDE with a JDK 1.7 naturally those
bundles do not resolve but stay in the INSTALLED state and a diag
appropriately tells me

> osgi> diag 205
> org.eclipse.fx.core [205]
>   Unresolved requirement: Require-Capability: osgi.ee; 
filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> 
> osgi> 

Everything ok but now the strange thing starts to happen. If I shutdown
the IDE and then launch with JDK8 the bundles do not get resolved either
and diag reports the same problem so it looks like the resolve is cached!

BTW the same is true the other way round as well:
* Launch with Java8 (EE 1.8 bundles are RESOLVED)
* Launch with Java7 (EE 1.8 bundles are STILL RESOLVED)

I think this is a major Bug in Equinox on Luna!

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] [http-service] ongoing work

[BJ Hargrave]

Please do NOT put the package in org.eclipse.osgi.services. That is plugin 
is an abomination for runtime use. 

For the updated http service impl, the impl project should include the 
org.osgi.service.http package and export/import it.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2014/03/27 09:43
Subject:[equinox-dev] [http-service] ongoing work
Sent by:equinox-dev-boun...@eclipse.org



FYI, my ongoing work is here:

https://github.com/rotty3000/rt.equinox.bundles/tree/rfc-189 (the new 
in-progress impl)
https://github.com/rotty3000/rt.equinox.framework/tree/rfc-189 (adds 
proposed http API only)

Feedback welcome.

-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
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] I'm getting null for "org.osgi.framework.version" property from equinox Luna system bundle

[BJ Hargrave]

Hmm. Open a bug please.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Cristiano Gavião 
To: Equinox development mailing list 
Date:   2014/01/18 22:41
Subject:Re: [equinox-dev] I'm getting null for 
"org.osgi.framework.version" property from equinox Luna system bundle
Sent by:equinox-dev-boun...@eclipse.org



BJ,

the sentence bellow is still returning null: 

frameworkVersion = (String) getSystemBundleContext().getProperty(
Constants.FRAMEWORK_VERSION);


2014/1/18 BJ Hargrave 
The FrameworkDTO contains the framework launch properties. Not all of the 
properties available to BundleContext.getProperty. So unless a property is 
passed to the FrameworkFactory.newInstance method (the launch properties), 
it wont be visible in FrameworkDTO. Unless you need a DTO to send the 
information out of the VM, just use BundleContext.getProperty. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Cristiano Gavião  
To:Equinox development mailing list  
Date:2014/01/18 11:18 
Subject:[equinox-dev] I'm getting null for 
"org.osgi.framework.version" property from equinox Luna system bundle 
Sent by:equinox-dev-boun...@eclipse.org 



Hi, I'm trying to get "org.osgi.framework.version" property from 
framework DTO, this way:

FrameworkDTO framework = getSystemBundleContext().getBundle().adapt(
FrameworkDTO.class);

frameworkVersion = (String) framework.properties
.get(Constants.FRAMEWORK_VERSION);

but the value that I'm receiving is null. Is this a bug?

Btw, how could I know what is the name of the osgi framework?

org.osgi.framework.Constants.FRAMEWORK_VENDOR property contains 
"Eclipse". But I couldn't find any reference to Equinox...

 thanks and regards,

Cristiano
___
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




-- 
"Tudo vale a pena se a alma não é pequena..." 
___
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] I'm getting null for "org.osgi.framework.version" property from equinox Luna system bundle

[BJ Hargrave]

The FrameworkDTO contains the framework launch properties. Not all of the 
properties available to BundleContext.getProperty. So unless a property is 
passed to the FrameworkFactory.newInstance method (the launch properties), 
it wont be visible in FrameworkDTO. Unless you need a DTO to send the 
information out of the VM, just use BundleContext.getProperty.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Cristiano Gavião 
To: Equinox development mailing list 
Date:   2014/01/18 11:18
Subject:[equinox-dev] I'm getting null for 
"org.osgi.framework.version" property from equinox Luna system bundle
Sent by:equinox-dev-boun...@eclipse.org



Hi, I'm trying to get "org.osgi.framework.version" property from 
framework DTO, this way:

FrameworkDTO framework = getSystemBundleContext().getBundle().adapt(
 FrameworkDTO.class);

frameworkVersion = (String) framework.properties
 .get(Constants.FRAMEWORK_VERSION);

but the value that I'm receiving is null. Is this a bug?

Btw, how could I know what is the name of the osgi framework?

org.osgi.framework.Constants.FRAMEWORK_VENDOR property contains 
"Eclipse". But I couldn't find any reference to Equinox...

  thanks and regards,

Cristiano
___
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] Class visibility without declared dependency

[BJ Hargrave]

> From: Stephan Herrmann 
> >
> > What kind of experiments?
> 
> bundle Provider:
> Export-Package: provider;include:="C1";my-attr="foo",
>   provider;include:="C2";my-attr="bar"
> 
> bundle Client:
> Import-Package: provider
> 
> Activator uses classes provider.C1, provider.C2, provider.C3.
> Only C2 is found at runtime.
> 
> But I see now that this is an incomplete experiment, see below.
> 
> > Export-Package can indeed export the same package multiple times with
> > different attributes. For example it's possible to exports multiple
> > versions:
> >
> >  Export-Package: org.foo; version=1.0, org.foo; version=2.0
> >
> > and this bundle can be wired by importers importing either version
> > [1.0,2) OR [2.0,3). That is, the importer may match any one of the
> > exports, they do not need to match all.
> 
> Maybe the problem is at the import side, not the export side.
> When I modify the client declaration:
>Import-Package: provider;my-attr="foo"
> then C2 is no longer found, but C1 is. Makes sense.
> 
> I had implicitly hoped that omitting my-attr would lead to importing
> the merge of both export declarations. This seems not to be the case.
> 
> I interpret this as:
> - a bundle may multiply export the same package with different 
attributes
> - a bundle can import the same package only once, selection will be 
based
>on attribute matching (or s.t. like last-save-wins if attr. not 
specified)
> Please correct me if this is wrong.
> 
> This gets me thinking how I can group the necessary declarations
> so that each importing bundle will find a matching and exhaustive
> export declaration.

You should also set mandatory:=my-attr on each export of provider so a 
hapless importer does not import some random subset of your package.

But this whole thing seems like overkill. Why don't you simply export the 
whole provider package and have the importers import the whole package. 
Packages are a unit and should be shared as a unit. The include/exclude 
directive was put in place to handle stupidly designed packages with 
public implementation types the should not be shared. 

I admit to not having followed this thread extremely closely, but I don't 
recall any justification for what you are proposed (exporting a single 
class from a package). Just because something can be done does not mean it 
should be done.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

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

Re: [equinox-dev] Impl of OSGi Subsystem spec?

[BJ Hargrave]

> From: Scott Lewis 

> First question:  Does Equinox Kepler implement the OSGI R5 Subsystem 
> specification?

Not to my knowledge. There is one in Apache Aries.

> 
> A broader question:   Does the RT project have a listing of the various 
> OSGi specs/chapters...and what implementations are provided by RT 
> projects for given specs?   ECF, for example, has impls of both the 
> Remote Service and Remote Service Admin specifications, but I'm not at 
> all sure about a number of others (e.g. transaction spec, provisioning, 
> subsystem, etc).  Would it make sense to have a RT page/pages that has 
> that information for interested consumers?  I've had several consumers 
> ask me directly about such information, and I'm probably not the only 
one.

It would be good to have such a page. The only thing close is the 
following which may be a bit out of date.

https://en.wikipedia.org/wiki/OSGi_Specification_Implementations


-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

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

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

[BJ Hargrave]

Then you probably have your own way to populate your 
PermissionCollections. However in Equinox which supports the OSGi 
permission specifications, the way to populate the PermissionCollections 
is via PermissionInfos which require the "0,1,2" constructors. 

If you have special permissions that cannot have those sort of 
constructors, then you can't use the OSGi permissions specifications and 
will need to customize a framework implementation to use your own 
permission management model.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/18 12:29
Subject:Re: [equinox-dev] PermissionInfoCollection issues with 
perms cloning
Sent by:equinox-dev-boun...@eclipse.org



PS: We were not loading our permissions from a standard policy file. Hence 
how we ended up with what we have.


On Thu, Apr 18, 2013 at 12:26 PM, Raymond Auge  
wrote:
Ok, I stand corrected. After looking at the code for PolicyParser it seems 
the 0, 1, 2 rule is indeed the case.

Other documentation seems to have implied that an arbitrary number of 
constructor arguments were acceptable:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA

However, I guess each of these different policy files must have it's own 
parser.

Sorry about my confusion.

- Ray

Thx


On Thu, Apr 18, 2013 at 12:05 PM, BJ Hargrave  wrote:
> Essentially the PermissionInfoCollection.addPermissions method 
> attempts to create a "copy" of the permission for the purpose adding
> to it's collection. 

Also, to be clear, there is no copying going on here. The code needs to 
construct a Permission object from the information in the PermissionInfo. 
The PermissionInfo contains the class name of the permission type with 0, 
1 or 2 String arguments for the constructor. This very much the same as 
would be done by the Policy object to create permissions based upon the 
grant information in the policy file. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

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




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
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] PermissionInfoCollection issues with perms cloning

[BJ Hargrave]

> Essentially the PermissionInfoCollection.addPermissions method 
> attempts to create a "copy" of the permission for the purpose adding
> to it's collection.

Also, to be clear, there is no copying going on here. The code needs to 
construct a Permission object from the information in the PermissionInfo. 
The PermissionInfo contains the class name of the permission type with 0, 
1 or 2 String arguments for the constructor. This very much the same as 
would be done by the Policy object to create permissions based upon the 
grant information in the policy file.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

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

Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

[BJ Hargrave]

I think it is pretty clear that permission classes must have a public 
constructor that is either empty or takes one or two strings. This is 
effectively required by the Java policy file grant format:

  grant {
  permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", 
"read";
  };

and by the OSGi spec:

permissions ::= ( ’(’ qname (quoted-string quoted-string?)? ’)’ )+

If your permission classes do not conform to this convention, how do you 
create PermissionInfos for them? (Of course we are discussing 
PermissionInfoCollection which maps PermissionInfos into a 
PermissionCollection.) 

You seem to be proposing something rather large which is a replacement of 
the PermissionInfo encoded format [1] which is the serialized form of 
permissions in the OSGi spec.

What do the constructors look like on your permissions?

[1] 
http://www.osgi.org/javadoc/r5/core/org/osgi/service/permissionadmin/PermissionInfo.html#getEncoded%28%29

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/18 11:23
Subject:Re: [equinox-dev] PermissionInfoCollection issues with 
perms cloning
Sent by:equinox-dev-boun...@eclipse.org



Hey guys, thanks for responding.

Forgive me for using the work "clone" (however, it really should be a 
clone in my mind, the base class should have implemented Cloneable in 
addition to Serializable).

Essentially the PermissionInfoCollection.addPermissions method attempts to 
create a "copy" of the permission for the purpose adding to it's 
collection.

However, there is nowhere in the spec that states a permission impl must 
have either a 0, 1 or 2 String constructor. 

The only requirements are:

- they extend from the base Permission class
- thereby should be Serializable
- they be immutable.

So, the "reconstitution" if you will, using the 0, 1 or 2 String 
constructor is really just working on assumption and accidentally works 
because all of the implementations in standard java are just that simple.

I'm proposing a different "copy" mechanism that will work for any 
implementation based on the assumption that they respect Serializable as 
they must. I'm not quite sure what that looks like yet, but I have a few 
ideas.

However, before going that far, I'm trying to see if I can make a change 
in our code to avoid the need the change the equinox impl... but i'm 
struggling with this.

Sincerely,
- Ray


On Thu, Apr 18, 2013 at 8:02 AM, BJ Hargrave  wrote:
Can you please provide more detail on the issue? What do you mean by 
"cloning"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788




From:Raymond Auge  
To:Equinox development mailing list  
Date:2013/04/17 18:23 
Subject:[equinox-dev] PermissionInfoCollection issues with perms 
cloning 
Sent by:equinox-dev-boun...@eclipse.org 



Hello All, 

The current implementation of PermissionInfoCollection uses a rather odd 
method of cloning permissions which breaks our implementation. 

Would anyone object to a new cloning technique which relies purely on 
serialization (which is a required interface of permission impls)? 

I'll provide an impl unless someone has a problem with changing the 
current mechanism. 

Thoughts? 

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc.  
--- 
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012 
___
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




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
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] PermissionInfoCollection issues with perms cloning

[BJ Hargrave]

Can you please provide more detail on the issue? What do you mean by 
"cloning"? 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge 
To: Equinox development mailing list 
Date:   2013/04/17 18:23
Subject:[equinox-dev] PermissionInfoCollection issues with perms 
cloning
Sent by:equinox-dev-boun...@eclipse.org



Hello All,

The current implementation of PermissionInfoCollection uses a rather odd 
method of cloning permissions which breaks our implementation.

Would anyone object to a new cloning technique which relies purely on 
serialization (which is a required interface of permission impls)?

I'll provide an impl unless someone has a problem with changing the 
current mechanism.

Thoughts?

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
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] bundles wiring and redeployment issues - hotswap

[BJ Hargrave]

To discuss, lets define some package names:

package mybean contains MyBean
package myservice contains MyService

The export for package myservice must have a uses constraint on mybean 
since a type in mybean appears in the signature of a type in myservice.

Bundle C must import both package mybean and myservice since it uses types 
from both. When you update the package exporting mybean, you will need to 
refresh all the bundles which import mybean in order for them to 
re-resolve to the updated package. So Bundle C must be stopped, 
re-resolved and restarted. This cannot be avoided.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "matteo rulli" 
To: , 
Date:   2013/01/30 11:47
Subject:[equinox-dev] bundles wiring and redeployment issues - 
hotswap
Sent by:equinox-dev-boun...@eclipse.org



I'm facing the following issue under OSGi environment: let's say I have a 
bundle A exporting com.mybiz.example package. This package, in its 1.0.0 
version, contains a bean class MyBean so that
 
public class MyBean {
 int var;
 public MyBean() { }
 public int getVar() { return var; }
 public void setVar(int v) { var = v; }
}
 
Bundle B exports an interface MyService which uses MyBean:
 
public interface MyService {
 public MyBean getMyBean();
}
 
Note: in our architecture, MyBean must be a class and not an interface.
 
Bundle C uses MyService as a declarative service in this way:
 
private AtomicReference _serv = new 
AtomicReference();
public void addMyService(MyService serv) {
 //this method is the one called by declarative services when Bundle B 
is started
 _serv.set(serv);
}
 
public void run() {
 ...
 
 MyBean x = _serv.getMyBean();
 //use x ...
}
 
Now the problem arises if I need to do a hot fix on MyBean class. 
Let's say I need to add a field and some methods.
Then, I've got a running OSGi environment where bundles A,B,C are 
deployed. 
 
My requirement is that I cannot stop any bundle.
 
So, under these hypotheses, I deploy a new version of my bundle A, say 
A_1.1.0.jar. Now I'm not able to make bundle C to use the new version of 
MyBean class contained in A_1.1.0.jar.
 
How can I do it?
 
Thank you very much!
 
Best regards,
matteo___
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] FW: [primarycontacts] Voting Now Open: OSGi Enterprise Release 5 Reference Implementations and Compliance Tests For Approval

[BJ Hargrave]

The Eclipse Foundation is a Contributing Associate member of the OSGi 
Alliance. Contributing Associate members are not eligible to vote on 
approvals for specifications, reference implementations and compliance 
tests.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "Mike Milinkovich" 
To: , "'Runtime Project PMC mailing list'" 
, 
Cc: e...@eclipse.org
Date:   2012/11/15 10:16
Subject:[equinox-dev] FW: [primarycontacts] Voting Now Open: OSGi 
Enterprise Release 5 Reference Implementations and Compliance   Tests For 
Approval
Sent by:equinox-dev-boun...@eclipse.org



Greetings,
 
Does the Equinox team or the RT PMC have any advice as to how the Eclipse 
Foundation should vote ?
 
 
From: primarycontacts-boun...@mail.osgi.org [
mailto:primarycontacts-boun...@mail.osgi.org] On Behalf Of John Ehrig
Sent: November-15-12 12:42 AM
To: primaryconta...@mail.osgi.org
Subject: [primarycontacts] Voting Now Open: OSGi Enterprise Release 5 
Reference Implementations and Compliance Tests For Approval
 
Dear OSGi Strategic or Principal Member Primary Contact: 
 
The OSGi Alliance Expert Groups, and Board of Directors, have approved the 
below referenced materials to be sent to you for your approval as final 
reference implementations and compliance tests. 
Per Section 10.1 of the OSGi Alliance Intellectual Property Rights Policy 
we would like you to cast your vote to approve these materials. 
http://www.osgi.org/wiki/uploads/About/OSGi%20Alliance%20Intellectual%20Property%20Rights%20Policy.pdf
 
You may approve/not approve/abstain from voting for the Reference 
Implementations and Compliance Tests by casting a single vote.  Please 
indicate this by stating "On behalf of my organization, I [approve/do not 
approve/abstain from voting] all the OSGi Alliance Reference 
Implementations and Compliance Tests referenced below" by appending your 
reply to the top of this e-mail; or you may cast 2 individual approve/not 
approve/abstain votes, one for each individual Reference Implementations 
or Compliance Tests - please specify precisely your voting preference for 
each and every one of the 2 materials under ballot. 
 
The voting period starts immediately and ends January 18, 2013 at 11:59 PM 
PST.   Timing is, as always, crucial, so please reply back to me with your 
vote as soon as you can. 
 
Only Strategic and Principal Members may vote. For Contributing Associates 
and Invited Researchers, this email is an informational notice of the 
voting period and the materials under ballot. 
 
The OSGi Enterprise Release 5 Reference Implementations can be found at: 
https://www.osgi.org/hudson/job/build.enterprise/188/artifact/osgi.ri/generated/osgi.ri.enterprise.jar
 
The OSGi Enterprise Release 5 Compliance Tests can be found at: 
https://www.osgi.org/hudson/job/build.enterprise/188/artifact/osgi.ct/generated/osgi.ct.enterprise.jar
 
Additional info can be found at 
https://www.osgi.org/members/Release5/HomePage
Please also let me know if you have any questions. 
 
Regards, 
 
John Ehrig
OSGi Alliance Executive Director
___
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, PDE and packages from the ExtensionClasspath (e.g. JavaFX)

[BJ Hargrave]

> > Fragment-Host: system.bundle; extension:=extclasspath
> 
> Would this extension:=extclasspath cause problems to other
> OSGi-Implementations like e.g. felix?

A compliant framework should reject this manifest since the standard 
directive does not specify a valid value.

If you are thinking of having a non-standard, Equinox-specific value for a 
standard directive, why not just add an Equinox-specific manifest header 
or Equinox-specific directive?

Fragment-Host: system.bundle; x-appclasspath:=ext

This does not sound like it would work in general anyway. What happens 
when the framework is launched from code whose classpath does not include 
ext? I assume the option here is either use the bootclasscloader for the 
parent of the classloader used to load the framework or use the current 
classloader for the parent of the classloader used to load the framework.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

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

Re: [equinox-dev] Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy

[BJ Hargrave]

There is no Bundle-BuddyPolicy header in the OSGi spec. This is probably 
why you cannot find information about it at the OSGi website.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Libor Jelinek 
To: equinox-dev@eclipse.org, 
Date:   2012/07/10 15:13
Subject:[equinox-dev] Bundle-BuddyPolicy vs. Eclipse-BuddyPolicy
Sent by:equinox-dev-boun...@eclipse.org



Hi Equinox developers,
I would like to ask you for clarification about state 
of Equinox-specific's Eclipse-BuddyPolicy header vs. Bundle-BuddyPolicy.

I'm having a debate with Ceki Gulcu (a great man behind Log4J and Logback) 
whether OSGi-fied Logback bundle should include or not include 
Eclipse-BuddyPolicy in its MANIFEST.MF.

This is just a one of methods how to contribute logback.xml at 
runtime. But there was an opinion at logback-dev mailinglist that 
Eclipse-BuddyPolicy is somehow deprecated are there is "more standard" 
OSGi Bundle-BuddyPolicy for the same purpose. Unfortunately I can't find 
any info about this header at osgi.org website [1].

Methods are summarized by me at at [2].

My questions:

1) Is Eclipse-BuddyPolicy deprecated or not recommended?

2) What's the meaning and state of Bundle-BuddyPolicy?

3) Is Bundle-BuddyPolicy really OSGi standard header for this purpose?

Links:
[1] http://www.osgi.org/Specifications/ReferenceHeaders
[2] 
http://devblog.virtage.com/2012/07/logback-and-eclipse-attaching-logback-xml/

--
Hezky den / Have a nice day
Libor JELÍNEK

VIRTAGE SOFTWARE // software - design - web
Lucni 542 // 285 04 Uhlirske Janovice // Czech Republic
support: +420 315 555 488 // cell: +420 777 205 142
email/jabber: ljeli...@virtage.com // web: www.virtage.com

Visit our developer adventures at http://devblog.virtage.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

Re: [equinox-dev] target version of osgi specs for juno

[BJ Hargrave]

Several of the OSGi spec implementations in Equinox Juno are used as RI 
for OSGi Compendium 4.3: DS, Metatype, Coordinator, Initial Provisioning, 
Event Admin, Wire Admin. So all those implementations are at the 
Compendium 4.3 level.

I don't know the status of the other OSGi spec impls in Equinox Juno.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Raymond Auge 
To: Equinox development mailing list , 
Date:   2012/07/03 12:14
Subject:[equinox-dev] target version of osgi specs for juno
Sent by:equinox-dev-boun...@eclipse.org



Hey All,

I'm wondering which specific versions of the 4 enteprise/compendium spec 
are the basis for juno. Is it still this jar from orbit:

http://download.eclipse.org/tools/orbit/downloads/
http://www.eclipse.org/downloads/download.php?r=1&file=/tools/orbit/downloads/drops/R20120526062928/repository/plugins/osgi.enterprise_4.2.0.v201108120515.jar

or can we use the newly released 4.3 compendium jar?

Thanks,

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
8-9 October 2012 | Liferay North America Symposium | 
liferay.com/northamerica2012
16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
___
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] Some Packages must be imported outside of Eclipse

[BJ Hargrave]

This is why you should use something like bndtools to make your bundles. 
Hand editing your manifest's package statements is not a good idea.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "." 
To: Equinox development mailing list , 
Date:   2012/06/20 17:10
Subject:Re: [equinox-dev] Some Packages must be imported outside 
of Eclipse
Sent by:equinox-dev-boun...@eclipse.org



Hello Richard,

thanks for your answer.

If it's not recommend to change the property to make packages like 
javax.* directly available: Is it possible in Eclipse to automatically 
import such packages when I use classes from them? I want to avoid the 
effort to manually check all my classes for imports from everything 
except java.* and manually adding these packages to the bundle manifest 
before I export the bundle as JAR.

Regards,
Rene

 Original Message 
Subject: Re: [equinox-dev] Some Packages must be imported outside of 
Eclipse
From: Richard S. Hall 
To: Equinox development mailing list 
Date: Wed Jun 20 2012 22:26:55 GMT+0200
> On 6/20/12 16:17 , . wrote:
>> Hello,
>>
>> if I start a OSGi bundle in Eclipse (Equinox) not only java.*, but 
>> also packages like javax.* are directly available and therefore must 
>> be not imported in the bundle manifest.
>
> I would expect that you can import the javax.* packages, but you are 
> correct that you shouldn't/can't import the java.* packages.
>
>> In contrast, when I run a bundle outside of Eclipse (also in Equinox; 
>> with startup.bat/startup.sh and config.ini) all used packages except 
>> java.* MUST be imported, otherwise it results to Class Not Found 
>> Exceptions.
>>
>> What is the reason why e.g. javax.* are not available outside of 
>> Eclipse without importing them? Is it possible, e.g. with a parameter 
>> in the config.ini, to make these packages directly available or in 
>> other words create the same runtime environment like in Eclipse?
>
> The reason is historical, I'd guess.
>
> You can configure this via the org.osgi.framework.bootdelegation 
> framework configuration property, but I'd recommend against doing so. 
> Double check, but I'd expect that you can import the javax.* packages 
> in Equinox when running in Eclipse...you should always import 
> everything except java.* packages...
>
> -> richard
>
>>
>> Thanks in advance!
>>
>> Regards,
>> Rene
>> ___
>> 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] looking up binaries

[BJ Hargrave]

You can certainly construct Req/Cap relationships between bundle to ensure 
they a provisions and resolved together. But that does not help in 
actually loading the native code. System.loadLibrary still needs to be 
called.

The only thing that might help would be for the framework to eagerly load 
all the native libs in the selected Bundle-NativeCode clause as part of 
the resolve process for a bundle. That is, the framework itself would call 
System.loadLibrary on all the native libs. There is an ordering issue, but 
I guess you could load them in the order they appear in the selected 
Bundle-NativeCode clause. Any later calls to System.loadLibrary by the 
bundle would be no-ops.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Scott Lewis 
To: Equinox development mailing list , 
Date:   2012/06/10 19:54
Subject:Re: [equinox-dev] looking up binaries
Sent by:equinox-dev-boun...@eclipse.org



Could capabilities be used to represent dependencies between native 
libraries? 

Scott

On 6/10/2012 2:23 PM, BJ Hargrave wrote: 
'cause that is the way it was designed in Java? System.loadLibrary is 
typically called from some class' static initializer to define the native 
methods of the class. System.loadLibrary calls ClassLoader.findLibrary to 
request advice in locating the native library. For bundle class loaders, 
this can then provide the location of the native library mentioned in the 
bundle's Bundle-NativeCode manifest header. 

In your example, since a class in bundle 1 has a static initializer 
calling System.loadLibrary("1"), then that code needs to first trigger a 
class loader from bundle 2 where  that class' static initializer calls 
System.loadLibrary("2"). This will then make sure lib2.so is loaded before 
lib1.so. 

In general, the native code support in Java is really only useful for 
loading JNI native libraries. How the dependencies of the JNI native 
libraries are met is not addressed. 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788






From:Pascal Rapicault  
To:Equinox development mailing list , 
Date:2012/06/10 16:48 
Subject:[equinox-dev] looking up binaries 
Sent by:equinox-dev-boun...@eclipse.org 



Hey, 

I have a situation where the binaries for my application are spread across 
multiple bundles and those libraries depend on each others. For example, I 
have bundle1 that carries lib1.so and I have bundle2 that carries lib2.so, 
and bundle1 depends on bundle2. When I try to load lib1.so if lib2.so has 
not yet been loaded, then the loading of lib1 will fail.

Is there a fundamental reason why we loading of the libraries could mimic 
the loading of classes?

Thx

Pascal

___
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] looking up binaries

[BJ Hargrave]

I don't think modifying java.library.path in the fly will work. See 
http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/

Like I said, native code support in Java kind of sucks. I would hope that 
Java 8 will improve things since Jigsaw will slam into this as well.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Pascal Rapicault 
To: Equinox development mailing list , 
Date:   2012/06/10 20:29
Subject:Re: [equinox-dev] looking up binaries
Sent by:equinox-dev-boun...@eclipse.org



The suggested approach would work but is rather painful. I have about 50 
bundles delivering legacy native code so making sure that there is java 
code initializing all the libs does not seem like it would work all that 
well, and I'm not sure that I would not end with cyclic dependencies.
At this point I have a script that extracts all the binaries into a lib 
folder and just set the os level library path... So much for modularity. 

I was hoping that with the ability to change the java.library.path 
dynamically at runtime[1] and the manifest information pertaining to 
native code, it would be possible to dynamically set the java.library.path 
upon loadLibrary to cause the right libs to be part of the library path.

What do you think?

Pascal

[1] - 
http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/


On 2012-06-10, at 5:23 PM, BJ Hargrave wrote:

'cause that is the way it was designed in Java? System.loadLibrary is 
typically called from some class' static initializer to define the native 
methods of the class. System.loadLibrary calls ClassLoader.findLibrary to 
request advice in locating the native library. For bundle class loaders, 
this can then provide the location of the native library mentioned in the 
bundle's Bundle-NativeCode manifest header. 

In your example, since a class in bundle 1 has a static initializer 
calling System.loadLibrary("1"), then that code needs to first trigger a 
class loader from bundle 2 where  that class' static initializer calls 
System.loadLibrary("2"). This will then make sure lib2.so is loaded before 
lib1.so. 

In general, the native code support in Java is really only useful for 
loading JNI native libraries. How the dependencies of the JNI native 
libraries are met is not addressed. 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788






From:Pascal Rapicault  
To:Equinox development mailing list , 
Date:2012/06/10 16:48 
Subject:[equinox-dev] looking up binaries 
Sent by:equinox-dev-boun...@eclipse.org 



Hey, 

I have a situation where the binaries for my application are spread across 
multiple bundles and those libraries depend on each others. For example, I 
have bundle1 that carries lib1.so and I have bundle2 that carries lib2.so, 
and bundle1 depends on bundle2. When I try to load lib1.so if lib2.so has 
not yet been loaded, then the loading of lib1 will fail.

Is there a fundamental reason why we loading of the libraries could mimic 
the loading of classes?

Thx

Pascal

___
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] looking up binaries

[BJ Hargrave]

'cause that is the way it was designed in Java? System.loadLibrary is 
typically called from some class' static initializer to define the native 
methods of the class. System.loadLibrary calls ClassLoader.findLibrary to 
request advice in locating the native library. For bundle class loaders, 
this can then provide the location of the native library mentioned in the 
bundle's Bundle-NativeCode manifest header.

In your example, since a class in bundle 1 has a static initializer 
calling System.loadLibrary("1"), then that code needs to first trigger a 
class loader from bundle 2 where  that class' static initializer calls 
System.loadLibrary("2"). This will then make sure lib2.so is loaded before 
lib1.so.

In general, the native code support in Java is really only useful for 
loading JNI native libraries. How the dependencies of the JNI native 
libraries are met is not addressed. 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Pascal Rapicault 
To: Equinox development mailing list , 
Date:   2012/06/10 16:48
Subject:[equinox-dev] looking up binaries
Sent by:equinox-dev-boun...@eclipse.org



Hey, 

I have a situation where the binaries for my application are spread across 
multiple bundles and those libraries depend on each others. For example, I 
have bundle1 that carries lib1.so and I have bundle2 that carries lib2.so, 
and bundle1 depends on bundle2. When I try to load lib1.so if lib2.so has 
not yet been loaded, then the loading of lib1 will fail.

Is there a fundamental reason why we loading of the libraries could mimic 
the loading of classes?

Thx

Pascal

___
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] Service Lookup by GUID very Slow

[BJ Hargrave]

Equinox also indexes by objectClass alone. So I am not sure what the 
discrepancy is here. Would be nice to have the test case code to analyze. 
Stanley, can you post a gist with the code?

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "Richard S. Hall" 
To: Equinox development mailing list , 
Date:   2012/05/04 13:16
Subject:Re: [equinox-dev] Service Lookup by GUID very Slow
Sent by:equinox-dev-boun...@eclipse.org



Just a side comment...

On the Felix framework, it is technically possible to index services on 
arbitrary service properties, but we don't provide any configuration 
properties to do so. By default, we only index on objectClass, which I 
assume Equinox does as well.

If all of your services have the same objectClass, then it will regress to 
a linear search. There is no other magic to make it faster in Felix. I 
would expect something similar in Equinox. If that is not the case, then 
yeah it sounds like there is an issue.

-> richard

On 5/4/12 12:41 , stanley_p...@dell.com wrote: 
Tom,
 
You are right on. I am using a simple filter. We just added a GUID 
property to each service. Two follow up questions:
 
-We ran the same tests on Felix and Knopflerfish and get 100ms 
response time. This is about 50X. I am wondering there may be something 
wrong in the environment. Do you think JVM settings like Perm generation 
size helps? I have Xmx=2GB, Xms=1GB and XXMaxPermSize=64MB.
-Do you think lazy service creation may be the reason? Is lazy 
creation the default? How to configure it?
-Can you outline the steps to use ServiceTrackerCustomizer to 
build index? Do you mean trapping the registration events and build the 
needed indexes?
 
Thank you,
Stanley
From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Friday, May 04, 2012 5:40 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Service Lookup by GUID very Slow
 
I was also not sure what you meant by GUID.  After some thought I think 
you probably mean the service id or perhaps the service pid (service.id 
and service.pid properties)?

And by lookup I assume you are using some kind of service filter, for 
example "(service.id=23)" with a call to 
BundleContext.getServiceReferences.  I will say that the service registry 
is not optimized for this kind of lookup.  You are far better keeping your 
own data structure that optimizes the lookup over the set of service 
references and indexes on the keys that you want to use to lookup service 
references.  This can easily be done with a ServiceTrackerCustomizer.

Tom



BJ Hargrave---05/03/2012 10:04:05 PM---What is service lookup by GUID? 
Services don't have globally unique identifiers. Can you provide more 
information on the specif


From:

BJ Hargrave/Austin/IBM@IBMUS

To:

Equinox development mailing list , 

Date:

05/03/2012 10:04 PM

Subject:

Re: [equinox-dev] Service Lookup by GUID very Slow




What is service lookup by GUID? Services don't have globally unique 
identifiers. Can you provide more information on the specifics of your 
lookup? Such as the code snippet? 

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788






From: 
To:, 
Date:2012/05/03 16:54 
Subject:[equinox-dev] Service Lookup by GUID very Slow 
Sent by:equinox-dev-boun...@eclipse.org 




In an experiment to have 200K of services registered, the service lookup 
by GUID is exceedingly slow – more the 4 seconds per lookup. 
 
There are enough RAM (8G) and heap (2G) allocated. 
 
What would be the reason of the slowness of the lookup? Any settings to 
start the framework to improve this? 
 
 
Thanks, 
Stanley___
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


<><><><><><><><><>___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Service Lookup by GUID very Slow

[BJ Hargrave]

What is service lookup by GUID? Services don't have globally unique 
identifiers. Can you provide more information on the specifics of your 
lookup? Such as the code snippet?

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   
To: , 
Date:   2012/05/03 16:54
Subject:[equinox-dev] Service Lookup by GUID very Slow
Sent by:equinox-dev-boun...@eclipse.org



In an experiment to have 200K of services registered, the service lookup 
by GUID is exceedingly slow – more the 4 seconds per lookup.
 
There are enough RAM (8G) and heap (2G) allocated.
 
What would be the reason of the slowness of the lookup? Any settings to 
start the framework to improve this?
 
 
Thanks,
Stanley___
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] +1 for Silenio Quarti on rt.equinox.framework by BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave 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 Bogdan Gheorghe on rt.equinox.framework by BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave 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 BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave voted:
+1
Required. Must not be blank.

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] same bundle in multiple regions

[BJ Hargrave]

You can install the same bundle (same bits) using different locations 
strings. But a location string is a unique identifier for an installed 
bundle. Use the 2 argument version of BundleContext.installBundle using 
unique location strings to install a bundle from the same URL multiple 
times.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Borislav Kapukaranov 
To: equinox-dev@eclipse.org, 
Date:   2011/09/23 06:58
Subject:[equinox-dev] same bundle in multiple regions
Sent by:equinox-dev-boun...@eclipse.org



Hey folks,

I have a question on installing a bundle from the same location.
Take the latest Virgo 3.0.x as a good example of more than one region and 
connect with telnet to each console.
If you try to install a bundle from the same location in both regions via 
each region's console this will fail with something like "Bundle already 
installed...".

Is this working as designed? Shouldn't it be possible to install a bundle 
from the same location(same string) if it's in different regions - Equinox 
may treat it as a different bundle and create it its own data folder, id, 
etc?
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg06875.html suggest 
that should be possible, as the first installation won't be visible to the 
context of the other region.

Thanks,
Bobby___
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] Multiple bsnversion in equinox

[BJ Hargrave]

Yes. Location is an opaque string. While the framework may interpret the 
string as a URL to obtain the bits of a bundle, it is otherwise an opaque 
string.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "Todorova, Katya" 
To: Equinox development mailing list 
Date:   2011/06/24 12:13
Subject:Re: [equinox-dev] Multiple bsnversion in equinox
Sent by:equinox-dev-boun...@eclipse.org



So location uniqueness is based on simple string comparison? 
I thought Equinox resolves the string passed as location and compares 
files to which locations point... 

So you say that if I install ./temp/my.jar and ./temp/../temp/my.jar it 
will result in two bundles installed and that's the correct behaviour? 

Thanks for your help,
Katya


-Original Message-
From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of John W Ross
Sent: Friday, June 24, 2011 6:25 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Multiple bsnversion in equinox

I'm not sure I understand why you're surprised?

If you install a bundle with the same location and the already installed 
bundle is visible to the context, the install will succeed and you will 
receive a reference to the already installed bundle. If the already 
installed bundle is not visible to the context, the install will fail and 
you will receive a BundleException indicating the operation was rejected 
by a hook. This will happen regardless of the value of the bsnversion 
property because locations must be unique.

If you install a bundle with the same bsn and version as an existing 
bundle, and the location is unique, and the bsnversion property is set to 
'single', the install will fail and you will receive a BundleException 
indicating the bundle is a duplicate. If the bsnversion property is set to 

'multiple', the install will succeed and you will receive a new Bundle 
object with a unique ID. Whether or not the bit source is the same should 
not make any difference as far as I know.

~ John





"Todorova, Katya"  
Sent by: equinox-dev-boun...@eclipse.org
06/24/2011 08:27 AM
Please respond to
Equinox development mailing list 


To
Equinox development mailing list 
cc

Subject
[equinox-dev] Multiple bsnversion in equinox






Hi, 
 
I start Equinox with org.osgi.framework.bsnversion=multiple and try to 
install one bundle twice:
 
osgi> install reference:
file:C:\eclipses\eclipse-SDK-3.7RC4-win32-x86_64\eclipse\plugins\com.ibm.icu.source_4.4.2.v20110208.jar

Bundle id is 5
 
osgi> install initial@reference:
file:C:\eclipses\eclipse-SDK-3.7RC4-win32-x86_64\eclipse\plugins\com.ibm.icu.source_4.4.2.v20110208.jar

Bundle id is 6
 
The installation is successful even if locations strings are not equal but 

resolve to the same file.
Is that expected? 
 
Thanks, 
Katya___
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

[equinox-dev] +1 for John W Ross on rt.equinox.bundles by BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave voted:
+1
It is stupid that the portal requires you to enter a vote comment.

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 BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave voted:
+1
It is stupid that the portal requires you to enter a vote comment.

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 BJ Hargrave

[portal on behalf of BJ Hargrave]

BJ Hargrave voted:
+1
It is stupid that the portal requires you to enter a vote comment.

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] Replacement for PackageAdmin.getBundles

[BJ Hargrave]

I guess this is a good opportunity to fix your code :-)
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Neil Bartlett 
To: Equinox development mailing list 
Cc: "Richard S. Hall" 
Date:   2011/02/22 12:49
Subject:Re: [equinox-dev] Replacement for PackageAdmin.getBundles
Sent by:equinox-dev-boun...@eclipse.org



Hi Richard and BJ,

I know the PackageAdmin is optional. Pragmatically though it's been
present in every framework for so long that it's availability is
assumed. I'm guilty myself of simply getting it as a service without
null-checking the result, and I'm sure a lot of production code out
there does the same.

Cheers
Neil

On Tue, Feb 22, 2011 at 5:22 PM, Richard S. Hall  
wrote:
> On 2/22/11 12:19, Richard S. Hall wrote:
>>
>> On 2/22/11 12:12, Thomas Watson wrote:
>>>
>>> No, package admin may not be available on all future framework
>>> implementations of R4.3. I have no plans to remove it from equinox 
because I
>>> know it is used by many clients and I don't want to break them. I 
would hope
>>> that most framework implementations would have the same concern and 
will
>>> keep an implementation of PackageAdmin around for a long time.
>>>
>>> I'm not sure I understand the seriousness of this "breaking change"
>>> though. There is an alternative way of doing this as BJ suggests. 
Also,
>>> PackageAdmin may have been a mandatory core service in OSGi R4.2
>>> specification, but it has not always been so. Previous releases of the 
core
>>> specifications made the PackageAdmin service optional. Although I 
don't
>>> think there is any reasonable core framework implementation available 
that
>>> does not provide PackageAdmin at the moment.
>>
>> I guess I didn't even remember making them mandatory...the R4.2 spec 
still
>> has sentences like this:
>>
>> "For example, a Framework vendor could supply the
>> optional services like Permission Admin service and Start Level service
>> with
>> Framework extension bundles."
>
> Sorry, I read "Permission Admin" as "Package Admin", but I'm still 
trying to
> see in the spec where it says Package Admin is mandatory. See this in 
7.1.3:
>
> "The Framework’s system bundle should provide a Package Admin service
> for the Management Agent."
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>> Tom
>>>
>>> -equinox-dev-boun...@eclipse.org wrote: -
>>>
>>> To: Equinox development mailing list 
>>> From: Neil Bartlett 
>>> Sent by: equinox-dev-boun...@eclipse.org
>>> Date: 02/22/2011 10:46AM
>>> Cc: Equinox development mailing list 
>>> Subject: Re: [equinox-dev] Replacement for PackageAdmin.getBundles
>>>
>>> BJ, could you confirm that the old API will still be available in
>>> all frameworks... otherwise this would be a serious breaking
>>> change for existing clients.
>>>
>>> Sent from my BlackBerry
>>>
>>> On 22 Feb 2011, at 16:09, BJ Hargrave >> <mailto:hargr...@us.ibm.com>> wrote:
>>>
>>>> There is no replacement for that method. You can just grovel over
>>>> the bundles to find this information. Seems like a job for a
>>>> utility class...
>>>>
>>>> That method was not a good fit for packageadmin anyway since it
>>>> nothing to do with the wiring state of the bundles.
>>>> -- *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: Gunnar Wagenknecht >>> <mailto:gun...@wagenknecht.org>>
>>>> To: equinox-dev@eclipse.org <mailto:equinox-dev@eclipse.org>
>>>> Date: 2011/02/22 07:08
>>>> Subject: [equinox-dev] Replacement for PackageAdmin.getBundles
>>>> Sent by: equinox-dev-boun...@eclipse.org
>>>> <mailto:equinox-dev-boun...@eclipse.org>
>>>> 

>>>>
>>>>
>>>>
>>>> Hi,
&g

Re: [equinox-dev] Replacement for PackageAdmin.getBundles

[BJ Hargrave]

This would be a good time to move away from using PackageAdmin service 
(and Start Level service) if possible.

As Richard pointed out, PackageAdmin is a service, so code always had to 
be prepared for it to not be available.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list 
Date:   2011/02/22 12:14
Subject:Re: [equinox-dev] Replacement for PackageAdmin.getBundles
Sent by:equinox-dev-boun...@eclipse.org



No, package admin may not be available on all future framework 
implementations of R4.3.  I have no plans to remove it from equinox 
because I know it is used by many clients and I don't want to break them. 
I would hope that most framework implementations would have the same 
concern and will keep an implementation of PackageAdmin around for a long 
time.

I'm not sure I understand the seriousness of this "breaking change" 
though.  There is an alternative way of doing this as BJ suggests.  Also, 
PackageAdmin may have been a mandatory core service in OSGi R4.2 
specification, but it has not always been so.  Previous releases of the 
core specifications made the PackageAdmin service optional.  Although I 
don't think there is any reasonable core framework implementation 
available that does not provide PackageAdmin at the moment.

Tom

-equinox-dev-boun...@eclipse.org wrote: -

To: Equinox development mailing list 
From: Neil Bartlett 
Sent by: equinox-dev-boun...@eclipse.org
Date: 02/22/2011 10:46AM
Cc: Equinox development mailing list 
Subject: Re: [equinox-dev] Replacement for PackageAdmin.getBundles

BJ, could you confirm that the old API will still be available in all 
frameworks... otherwise this would be a serious breaking change for 
existing clients. 

Sent from my BlackBerry

On 22 Feb 2011, at 16:09, BJ Hargrave  wrote:

There is no replacement for that method. You can just grovel over the 
bundles to find this information. Seems like a job for a utility class...

That method was not a good fit for packageadmin anyway since it nothing to 
do with the wiring state of the bundles.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788






From:Gunnar Wagenknecht 
To:equinox-dev@eclipse.org
Date:2011/02/22 07:08
Subject:[equinox-dev] Replacement for PackageAdmin.getBundles
Sent by:equinox-dev-boun...@eclipse.org



Hi,

What's the recommended replacement for
org.osgi.service.packageadmin.PackageAdmin.getBundles(String, String)? I
was looking for a similar method in the new org.osgi.framework.wiring
package. But it appears that there is none. I haven't checked the
changes for M6, though.

-Gunnar



-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/

___
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

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Replacement for PackageAdmin.getBundles

[BJ Hargrave]

There is no replacement for that method. You can just grovel over the 
bundles to find this information. Seems like a job for a utility class...

That method was not a good fit for packageadmin anyway since it nothing to 
do with the wiring state of the bundles.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Gunnar Wagenknecht 
To: equinox-dev@eclipse.org
Date:   2011/02/22 07:08
Subject:[equinox-dev] Replacement for PackageAdmin.getBundles
Sent by:equinox-dev-boun...@eclipse.org



Hi,

What's the recommended replacement for
org.osgi.service.packageadmin.PackageAdmin.getBundles(String, String)? I
was looking for a similar method in the new org.osgi.framework.wiring
package. But it appears that there is none. I haven't checked the
changes for M6, though.

-Gunnar



-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/

___
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] Plans to replace the Console with GoGo for Indigo

[BJ Hargrave]

If the plan is to replace the internal console with a bundle-supplied 
console (e.g. GoGo; and I think this is a fine plan), then I think the 
-console argument either needs to be deprecated (and now would be a great 
time to put people on notice) or we need to plan for the -console argument 
to eventually start the bundle-supplied console once the internal console 
is gone.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Jeff McAffer 
To: Equinox development mailing list 
Date:   2010/12/02 20:00
Subject:Re: [equinox-dev] Plans to replace the Console with GoGo 
for Indigo
Sent by:equinox-dev-boun...@eclipse.org



IMHO the bar for Indigo is pretty low.  We need to make sure that Gogo can 
run properly on Equinox.  All servicability extension work can be focused 
on using Gogo. Having a way to disable the current console would be 
interesting but not essential.  Don't want the console?  don't put 
-console on the command line. 

I'm reluctant to put any logic in the framework or launcher to choose 
between consoles or search for console implementations or...  People 
shipping configurations where they want to use Gogo should setup their 
config to have Gogo installed and started.  We may choose in the future to 
supply such a setup from Equinox and there can even be a bundle that looks 
for a -gogo command line arg but that should not be in the framework impl.

So, what do we actually have to do here?

Jeff


On 2010-12-02, at 1:44 PM, Thomas Watson wrote:

This is the kind of thing I want to address for 3.7 to enable the use of 
bundles on top of the framework to provide the console. Ideally this would 
involve a way to configure the framework so that the -console option just 
did what you need to get your bundles started as well as completely 
disabling the console support built into the framework. I think that is 
part of the solution proposed in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603

Tom



"Kirchev, Lazar" ---12/02/2010 10:52:30 AM---For the 
extraction of the console in a separate bundle there is a bug opened: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169


From:

"Kirchev, Lazar" 

To:

Equinox development mailing list 

Date:

12/02/2010 10:52 AM

Subject:

Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo



For the extraction of the console in a separate bundle there is a bug 
opened:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169603
and a patch is provided there. 

One of the reasons for considering the moving of the console out of the 
framework is that adding new features to the console while it is in the 
framework will increase the size of the framework. The current built-in 
console lacks telnet supportability features for example. Now if the 
console stays in the framework, it will not include such features. But 
such supportability features also improve usability. Probably we should 
provide them as an optional bundle - anyone who needs them to install this 
bundle? What I have prepared for the incubator is meant to run as a Gogo 
command, but it easily may be changed to support both cases – as a Gogo 
command, and the ConsoleSession interface available since 3.6.

Also, currently the only way to run Gogo on top of Equinox is to start 
Equinox without the –console option, and make Gogo bundles initially 
started. So it is not possible to pass –console and start either one, or 
the other. Probably add an option to specify the console jar/jars, if a 
console different from the built-in should be started?

Lazar



From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Thursday, December 02, 2010 5:50 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Plans to replace the Console with GoGo for 
Indigo
We also must consider the amount of work it would take to extract the 
console out and test it properly. I am reluctant to do any of that work 
when we want to eventually replace the console implementation with the 
gogo shell and a bundle that bridges the old equinox command 
implementations to the new shell.

Tom



Jeff McAffer ---12/02/2010 09:37:45 AM---The disadvantage is 
usability. Right now you get equinox and run with -console and its all 
good. If we break it out you'll ha 

<34743407.jpg>
From:
<34519726.jpg>
Jeff McAffer 
<34743407.jpg>
To:
<34519726.jpg>
Equinox development mailing list 
<34743407.jpg>
Date:
<34519726.jpg>
12/02/2010 09:37 AM
<34743407.jpg>
Subject:
<34519726.jpg>
Re: [equinox-dev] Plans to replace the Console with GoGo for Indigo




The disadvantage is usability. Right now you get equinox and run with 
-console and its all good. If we break it out you'll have to get two 
bundles and make sure that the console 

Re: [equinox-dev] Bug in event admin

[BJ Hargrave]

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox then select 
component Compendium and start the summary with [eventadmin].
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   "Alan D. Cabrera" 
To: equinox-dev@eclipse.org
Date:   2010/09/12 20:58
Subject:[equinox-dev] Bug in event admin
Sent by:equinox-dev-boun...@eclipse.org



I found a bug in event admin but am not sure where I should report it. Can 
someone point me to where bugs are reported?


Regards,
Alan

___
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 the system bundle

[BJ Hargrave]

We don't you just wait for the FrameworkEvent.STARTED event?

 * This event is fired when the Framework has started after all 
installed
 * bundles that are marked to be started have been started and the 
Framework
 * has reached the initial start level. The source of this event 
is the
 * System Bundle.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"Kirchev, Lazar" 
To:
"equinox-dev@eclipse.org" 
Date:
2010/04/14 08:21
Subject:
[equinox-dev] Starting the system bundle
Sent by:
equinox-dev-boun...@eclipse.org



Hello,
 
We are implementing logic which depends on the system bundle being put in 
ACTIVE state after all bundles, which should be running, are started. 
However, it turned out that actually the system bundle is put in ACTIVE 
state just before the bundles are started. This is evident from the method 
StartLevelManager.doSetStartLevel(…), which is called from the 
EquinoxLauncher. There is a comment in the code, that putting the bundle 
in ACTIVE state “should be done just before firing the STARTED event for 
the system bundle” but is done earlier, because “some depend on the system 
bundle being in the ACTIVE state when they are starting”. Do you think it 
is possible to change the current behavior and put the system bundle in 
ACTIVE state after the other bundles are started, as it is in the OSGi 
spec?
 
Kind regards,
Lazar Kirchev___
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: AW: [equinox-dev] Question on programatic close of the runtime

[BJ Hargrave]

Lets assume you start the Equinox instances with your own launcher using 
the Framework launch API. After that code launches the framework, it parks 
a thread on Framework.waitForStop. Then when your servlet calls stop on 
the system bundle, once the framework has indeed stopped, the thread 
parked on waitForStop will awaken and can then tidily end the VM's life 
perhaps including System.exit. (This is all standard OSGi and requires no 
Equinox specifics.)
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:

To:

Date:
2010/03/12 12:15
Subject:
AW: [equinox-dev] Question on programatic close of the runtime
Sent by:
equinox-dev-boun...@eclipse.org



Hi all,

our application (BTW: we are talking about SMILA) is a backend server, 
with instances running on a cluster. What do you suggest to remotely 
shutdown the OSGi instances on each cluster node?

We cannot expect an administrator to log on every machine and to exit the 
OSGI console by typing "close". 

Therefore I had the idea to provide this functionality via HTTP. So it's 
an external call that stops bundle zero and after a configurable timeout 
calls System.exit() (hopefully giving the runtime enough time to savely 
stop all bundles). So the System.exit() is done on purpose by an 
administrator.

One way of connecting remotely would be to use telnet and then send a 
close command to the OSGi console. But this is cumbersome. Is this "safer" 
than my approach as after Framework.close() this does also call 
System.exit() ?

Bye,
Daniel


-Ursprüngliche Nachricht-
Von: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] Im Auftrag von Neil Bartlett
Gesendet: Freitag, 12. März 2010 17:54
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Question on programatic close of the runtime

Tim,

I agree but it's a matter of who is responsible for doing this. The
launcher code that created the framework and started it should be
responsible for shutting down the VM, after calling
Framework.waitForStop(). If a bundle calls System.exit() then it is
assuming too much about the environment in which it is deployed.

Neil

On Fri, Mar 12, 2010 at 4:47 PM, Tim Diekmann  wrote:
> Hi,
>
> while calling stop() on the system bundle is the correct and recommended 
approach, it is not always sufficient in production environments.
>
> The framework will only end if the main() method that started it runs 
out or someone calls System.exit(). However, for the main method to end, 
all non-daemon threads have to be ended first. Bundles may have started 
non-daemon threads. If you have started Equinox with the console enabled 
that would be difficult and you continue to have a process lingering 
around and no OSGi framework.
>
> System.exit() is the safest choice to ensure that the process has died.
>
> Keep in mind that on shutdown Equinox is persisting its state and a call 
to System.exit() during that phase may cause cache corruption.
>
>   Tim.
>
> "It is a simple task to make things complex, but a complex task to make 
them simple."
>  -- Fortune Cookie
>
> On Mar 12, 2010, at 2:34 AM, Neil Bartlett wrote:
>
>> Daniel,
>>
>> Stopping bundle zero is not a hack; this is the normal way to
>> programmatically shutdown OSGi. However:
>>
>> 1) There is no need to check that the bundle is active first. Calling
>> stop() on an already stopped bundle simply has no effect (likewise
>> calling start() on an already active bundle has no effect).
>>
>> 2) There should be no need to wait for the framework to stop and then
>> call System.exit(). Exiting the JVM should be the responsibility of
>> whoever created and started the framework, i.e. the launcher. Calling
>> System.exit() directly from within a bundle will cause big problems if
>> your bundle is deployed to a framework embedded in a larger system,
>> e.g. an application server.
>>
>> In other words, the code could be as simple as this:
>>
>>_componentContext.getBundleContext().getBundle(0).stop();
>>
>> Regards,
>> Neil
>>
>> On Fri, Mar 12, 2010 at 10:16 AM,   wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I would like to expose the functionality to close the Equinox runtime 
via an
>>> HTTP request. Therefore I have implemented a Jetty ContextHandler as 
an
>>> DeclarativeService. I used the FrameworkCommandProvider as an example 
on how
>>> to close the runtime, but I was not able to get access to the 
Framework
>>> class to call method close() on it.
>>>
>>>
>>>
>>> I came up with a workaround for that, wh

Re: [equinox-dev] Question on programatic close of the runtime

[BJ Hargrave]

Do I smell DOS attack? :-)
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Neil Bartlett 
To:
Equinox development mailing list 
Date:
2010/03/12 05:35
Subject:
Re: [equinox-dev] Question on programatic close of the runtime
Sent by:
equinox-dev-boun...@eclipse.org



Daniel,

Stopping bundle zero is not a hack; this is the normal way to
programmatically shutdown OSGi. However:

1) There is no need to check that the bundle is active first. Calling
stop() on an already stopped bundle simply has no effect (likewise
calling start() on an already active bundle has no effect).

2) There should be no need to wait for the framework to stop and then
call System.exit(). Exiting the JVM should be the responsibility of
whoever created and started the framework, i.e. the launcher. Calling
System.exit() directly from within a bundle will cause big problems if
your bundle is deployed to a framework embedded in a larger system,
e.g. an application server.

In other words, the code could be as simple as this:

_componentContext.getBundleContext().getBundle(0).stop();

Regards,
Neil

On Fri, Mar 12, 2010 at 10:16 AM,   wrote:
> Hi all,
>
>
>
> I would like to expose the functionality to close the Equinox runtime 
via an
> HTTP request. Therefore I have implemented a Jetty ContextHandler as an
> DeclarativeService. I used the FrameworkCommandProvider as an example on 
how
> to close the runtime, but I was not able to get access to the Framework
> class to call method close() on it.
>
>
>
> I came up with a workaround for that, which is basically like this:
>
>
>
> Bundle bundle = _componentContext.getBundleContext().getBundle(0);
>
> if (bundle.getState() == Bundle.ACTIVE) {
>
> bundle.stop();
>
>  while (bundle.getState() != Bundle.RESOLVED) {
>
> // WAIT N milliseconds and REPEAT at most M times
>
>  }
>
> }
>
>  System.exit(0);
>
>
>
>
>
> This works fine for me, although it seems to be a hack stopping bundle 
with
> Id 0. Are there better ways to achieve my goal ? Are there any ways to 
get
> access to the Framework class ?
>
>
>
>
>
> Bye,
>
> Daniel
>
> ___
> 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] problem with ServiceTracker.open() and refreshThread in Equinox

[BJ Hargrave]

Yes, open a bug Tim. I can see that a fix is needed here.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Tim Diekmann 
To:
Equinox development mailing list 
Date:
2010/01/29 22:46
Subject:
[equinox-dev] problem with ServiceTracker.open() and refreshThread  in 
Equinox
Sent by:
equinox-dev-boun...@eclipse.org



I ran into a problem with Equinox 3.5.1.R35x_v20090806:

In my log file I find the following exception stack trace after calling 
PackageAdmin.refreshPackages(null).

org.osgi.framework.BundleException: Exception in 
com.tibco.xxx.Activator.start() of bundle com.tibco.xxx.
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:805)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272)
at com.tibco.xxx.refreshRuntime(xxx.java:872)
at com.tibco.xx.access$6(xxxImpl.java:569)
at com.tibco.xxx$2.run(xxxImpl.java:229)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: The service has been 
unregistered
at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getReferenceImpl(ServiceRegistrationImpl.java:277)
at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.lookupServiceRegistrations(ServiceRegistry.java:867)
at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getServiceReferences(ServiceRegistry.java:290)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.getAllServiceReferences(BundleContextImpl.java:577)
at 
org.osgi.util.tracker.ServiceTracker.getInitialReferences(ServiceTracker.java:360)
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:321)
at com.tibco.xxx.start(xxx.java:150)
at com.tibco.xxx.Activator.start(Activator.java:39)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:782)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:773)

The exception is thrown while starting a bundle after the refreshPackages 
call. I assume the refreshThread is still ongoing in the background and as 
part of the process stops and restarts bundles, which causes OSGi services 
to be unregistered and then (hopefully) registered again.

The ServiceTracker of the bundle that is started wants to look for all 
services that have a certain property set. However, during the initial 
scan of all services, one of them is unregistered, which causes the seen 
exception.

There seems to be a race condition in which lookupServiceRegistrations() 
acquires the lock to ServiceRegistry and copies the results to an 
ArrayList.

private List lookupServiceRegistrations(String clazz, Filter filter) {
List result;
synchronized (this) {
if (clazz == null) { /* all services */
result = allPublishedServices;
} else {
/* services registered under the class name */
result = (List) publishedServicesByClass.get(clazz);
}

if ((result == null) || (result.size() == 0)) {
return Collections.EMPTY_LIST;
}

result = new ArrayList(result); /* make a new list since we don't want to 
change the real list */
}

In the meantime the service is unregistered and removed from 
allPublishedServices:

void removeServiceRegistration(BundleContextImpl context, 
ServiceRegistrationImpl serviceReg) {
// Remove the ServiceRegistrationImpl from the list of Services published 
by BundleContextImpl.
List contextServices = (List) publishedServicesByContext.get(context);
if (contextServices != null) {
contextServices.remove(serviceReg);
}

// Remove the ServiceRegistrationImpl from the list of Services published 
by Class Name.
String[] clazzes = serviceReg.getClasses();
for (int i = 0, size = clazzes.length; i < size; i++) {
String clazz = clazzes[i];
List services = (List) publishedServicesByClass.get(clazz);
services.remove(serviceReg);
}

// Remove the ServiceRegistrationImpl from the list of all published 
Services.
allPublishedServices.remove(serviceReg);
}

However, lookupServiceRegistrations() goes on to iterate over the result 
list and runs into the exception above.

for (Iterator iter = result.iterator(); iter.hasNext();) {
ServiceRegistrationImpl registration = (ServiceRegistrationImpl) 
iter.next();
if (!filter.match(registration.getReferenceImpl())) {
iter.remove();
}
}


Has anyone seen this? Is this a know problem? I guess I could file a bug 
for this.

Thanks,

   Tim.

"It is a simple task to make things complex, but a complex task to make 
them simple."

Re: [equinox-dev] some issues in creatingfilters

[BJ Hargrave]

If the filter string is invalid, createFilter will throw an 
InvalidSyntaxException.

If that does not happen, then the filter string is fine.

>From the code snippet, I don't know what the value of the mode variable 
is. What you should do is print out filter.toString() and see what the 
final filter is.

We also can't see what Dictionary or ServiceReference you are attempting 
to match against the filter against. So it is possible the nothing matches 
your filter.

Finally, I think the argument to the services console command must be a 
valid filter string. "-l bundleId" is not a valid filter string which is 
why you get an exception.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
prof_trg 
To:
equinox-dev@eclipse.org
Date:
2009/11/15 07:30
Subject:
[equinox-dev] some issues in creatingfilters
Sent by:
equinox-dev-boun...@eclipse.org




Hello,
I have some issues in creatingfilters..
in fact, only simple filters are accepted like : 
 filter = context.createFilter("(" + Constants.OBJECTCLASS + "=" +
IMyInterface.class.getName() + ")");
 
however, the filter has filtered nothing if the syntax is like the
following,  :
 filter = context.createFilter("(&(" + Constants.OBJECTCLASS + "=" +
IMyInterface.class.getName() + ")" +
 "(" + 
mode + "=" +  true+ "))");
when I taped the command "services -l bundleID" , an exception occured;
error in character 1 "("...
So w*how can I validate the syntax of filters..and what is the origin of 
the
exception in your opinion (the previous syntax seems correct..)

Regards
-- 
View this message in context: 
http://old.nabble.com/some-issues-in-creatingfilters-tp26358700p26358700.html

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

Re: [equinox-dev] OSGi DevCon London Call for Papers

[BJ Hargrave]

Please use http and not https to avoiding being asked for credentials.

http://www.osgi.org/DevConLondon2010/HomePage
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"Ian Skerrett" 
To:
, "'Runtime Project PMC mailing list'" 

Date:
2009/11/03 09:22
Subject:
[equinox-dev] OSGi DevCon London Call for Papers
Sent by:
equinox-dev-boun...@eclipse.org



OSGi Alliance is have a DevCon at the JAX conference in London.  The Call 
for Papers is out now; deadline is Nov 27.
 
https://www.osgi.org/DevConLondon2010/HomePage
 
Ian
 
 
Ian Skerrett
Director of Marketing
Eclipse Foundation
613-224-9461 ext. 227
blog: ianskerrett.wordpress.com
twitter: https://twitter.com/ianskerrett
 ___
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 and bundle stop/start

[BJ Hargrave]

Why not have DS hand off processing of the components to another thread 
when the LAZY_ACTIVATION event is received? This will allow the bundle 
start to complete while the DS processing occurs async.

I don't think we should change to process on STARTING.

This whole discussion seems to point out that we are, perhaps unwisely, 
blending using DS and BundleActivator where the activators have a 
dependency on DS having alread processed the bundle. Perhaps what is 
needed is a form of immediate component that is not activated when DS 
processed the bundle but is activated when the bundle's STARTED event is 
fired. This would delay creation of the immediate component until the 
bundle activation was lazily triggered and allow the immediate component 
to be injected with any other services of the bundle.

This design change seems a much better idea that combining 
BundleActivators and DS with specific ordering.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Stoyan Boshev 
To:
Equinox development mailing list 
Date:
2009/10/27 11:24
Subject:
Re: [equinox-dev] DS and bundle stop/start
Sent by:
equinox-dev-boun...@eclipse.org





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 patter

Re: [equinox-dev] DS and bundle stop/start

[BJ Hargrave]

Yes. No bundle should expect another bundle to register some service 
during it activation. A bundle should depend upon services using DS or 
ServiceTracker (or even ServiceListener).
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Thomas Watson/Austin/i...@ibmus
To:
Equinox development mailing list 
Date:
2009/10/27 09:54
Subject:
Re: [equinox-dev] DS and bundle stop/start
Sent by:
equinox-dev-boun...@eclipse.org



Hmmm, I thought the original design of lazy activation and DS components 
was to synchronously make service components available in the service 
registry as long as they are immediately resolvable. The reason for this 
was to ensure these services were synchronously available before we 
entered the Eclipse application entry point.

This points out a deficiency in the way most of Eclipse handles dynamic 
registration of services. If every eclipse bundle was written from day one 
to handle dynamic registration and unregistration of services then it 
would not matter that the service registration happened asynchronously. 

Tom



BJ Hargrave---10/26/2009 03:27:34 PM---Why doesn't DS just asynchronously 
process bundles which are lazy activated (not lazy started which is an 
incorrect term)? Then


From:

BJ Hargrave/Austin/i...@ibmus

To:

Equinox development mailing list 

Date:

10/26/2009 03:27 PM

Subject:

Re: [equinox-dev] DS and bundle stop/start



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. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
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

___
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 and bundle stop/start

[BJ Hargrave]

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.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
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

Re: [equinox-dev] MetaType Service

[BJ Hargrave]

You would need to write your own Metatype Service implementation (eg. by 
deriving from the Equinox implementation) to suppory your custom 
extensions.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Ali Naddaf 
To:
Equinox development mailing list 
Date:
2009/10/24 23:50
Subject:
[equinox-dev] MetaType Service
Sent by:
equinox-dev-boun...@eclipse.org



Hello everyone.

I like to use the MetaType service but need to add some extra 
"attributes" to the AD element of the xml descriptor. Looking at the 
schema, it seems that it permits such extensions (it has  
in the complex type definition for the AD type) but if I do so, how can 
I use the MetaType service to retrieve these extra attributes? Is there 
in that service an API that returns something like a Map for the 
attributes? I couldn't find one.

Many thanks,
Ali.
___
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] Question about DI/ DS and Application model

[BJ Hargrave]

> because services from lazy activated bundles are available prior to 
being started

Technically that is not true. Services from lazy activated bundles are 
available prior to being *activated* but the bundle must have been 
started. That is, not in RESOLVED state; STARTING or ACTIVE.

> Since the bundle providing the extension is STARTED at this point, and 
all other lazy activated bundles are STARTING

This sounds like a start ordering issue. Since extensions are active in 
the RESOLVED state, the system will need to be configured such that all 
bundles which will use extension to access services are started before 
they will ever attempt to access the service.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
John Arthorne 
To:
Equinox development mailing list 
Date:
2009/09/17 10:17
Subject:
Re: [equinox-dev] Question about DI/ DS and Application model
Sent by:
equinox-dev-boun...@eclipse.org




There is a mismatch, although use of DS brings the lifecycles closer 
together because services from lazy activated bundles are available prior 
to being started. I think the main problem here though is initializing 
executable extensions after they have been instantiated to provide them 
with the services they need. Since the bundle providing the extension is 
STARTED at this point, and all other lazy activated bundles are STARTING 
(and hence their services available to the SCR), I don't see the lifecycle 
difference causing a problem (although it's quite possible I'm missing 
something as I'm still relatively new to DS). 

John 



BJ Hargrave  
Sent by: equinox-dev-boun...@eclipse.org 
09/16/2009 10:29 PM 

Please respond to
Equinox development mailing list 


To
Equinox development mailing list  
cc

Subject
Re: [equinox-dev] Question about DI/ DS and Application model








Isn't there a big problem with the life cycle mismatch between services 
and extensions? Services require a bundle to be started. Extensions 
require a bundle to be resolved. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788


From: 
John Arthorne  
To: 
Equinox development mailing list  
Date: 
2009/09/16 21:58 
Subject: 
Re: [equinox-dev] Question about DI/ DS and Application model 
Sent by: 
equinox-dev-boun...@eclipse.org






Eventually someone has to decide which implementation of 
IMetadataRepositoryManager is going to be used. I think in the case of an 
application it is quite reasonable for the application to make this 
decision directly (by looking up the service, perhaps with some filter 
that helps to select the manager to use). By moving the lookup of 
IMetadataRepositoryManager into a DS component it just hides the fact that 
it is a simple service lookup and doesn't seem to offer any advantage. 

I think because both the service declaration, the implementation, and the 
client are all in the same bundle it's not a particularly interesting 
case. However I could imagine in more complex cases something like your 
solution 3 would be interesting. An executable extension factory could 
allow the services required by an executable extension to be injected into 
it rather than having the extension reach out. 

You'll see another package "solution3" in the bundle where I was playing 
around with another approach. I'm not sure it's any better than your 
solution 1 but you can take a look. 

John 

Pascal Rapicault/Ottawa/i...@ibmca 
Sent by: equinox-dev-boun...@eclipse.org 
09/16/2009 04:00 PM 

Please respond to
Equinox development mailing list 



To
Equinox development mailing list  
cc

Subject
[equinox-dev] Question about DI/ DS and Application model












Today I have done some more DI exploration using DS to see how it fits 
with the constructs we have in eclipse and I'm struggling to integrate in 
a nice way with the application model (I mean without using static) and 
I'm looking to know how others are doing this?
The one line summary of my experiment is: I have a class that does some 
work (named RepositoryDumper), it needs a service (RepoMgr). I want now to 
create an eclipse application that invokes the RepositoryDumper and I 
would like to not have to acquire the RepoMgr service manually.

Here is what I have been exploring with:
Solution 1:
I have an application declared in the plugin.xml. I have created a DS 
component that instantiates RepositoryDumper. However the question now is 
how does the application (remember that an eclipse application extension 
needs to provides n class) can get a hold of the RepositoryDumper instance 
that got created by DS:
- 1.1: Ugly -> Store the instance RepositoryDumper in the Activator of the 
plug-in
- 1.2: Get the RepositoryDumper be registered as a Se

Re: [equinox-dev] Question about DI/ DS and Application model

[BJ Hargrave]

Isn't there a big problem with the life cycle mismatch between services 
and extensions? Services require a bundle to be started. Extensions 
require a bundle to be resolved.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
John Arthorne 
To:
Equinox development mailing list 
Date:
2009/09/16 21:58
Subject:
Re: [equinox-dev] Question about DI/ DS and Application model
Sent by:
equinox-dev-boun...@eclipse.org




Eventually someone has to decide which implementation of 
IMetadataRepositoryManager is going to be used. I think in the case of an 
application it is quite reasonable for the application to make this 
decision directly (by looking up the service, perhaps with some filter 
that helps to select the manager to use). By moving the lookup of 
IMetadataRepositoryManager into a DS component it just hides the fact that 
it is a simple service lookup and doesn't seem to offer any advantage. 

I think because both the service declaration, the implementation, and the 
client are all in the same bundle it's not a particularly interesting 
case. However I could imagine in more complex cases something like your 
solution 3 would be interesting. An executable extension factory could 
allow the services required by an executable extension to be injected into 
it rather than having the extension reach out. 

You'll see another package "solution3" in the bundle where I was playing 
around with another approach. I'm not sure it's any better than your 
solution 1 but you can take a look. 

John 



Pascal Rapicault/Ottawa/i...@ibmca 
Sent by: equinox-dev-boun...@eclipse.org 
09/16/2009 04:00 PM 

Please respond to
Equinox development mailing list 


To
Equinox development mailing list  
cc

Subject
[equinox-dev] Question about DI/ DS and Application model








Today I have done some more DI exploration using DS to see how it fits 
with the constructs we have in eclipse and I'm struggling to integrate in 
a nice way with the application model (I mean without using static) and 
I'm looking to know how others are doing this?
The one line summary of my experiment is: I have a class that does some 
work (named RepositoryDumper), it needs a service (RepoMgr). I want now to 
create an eclipse application that invokes the RepositoryDumper and I 
would like to not have to acquire the RepoMgr service manually.

Here is what I have been exploring with:
Solution 1:
I have an application declared in the plugin.xml. I have created a DS 
component that instantiates RepositoryDumper. However the question now is 
how does the application (remember that an eclipse application extension 
needs to provides n class) can get a hold of the RepositoryDumper instance 
that got created by DS:
- 1.1: Ugly -> Store the instance RepositoryDumper in the Activator of the 
plug-in
- 1.2: Get the RepositoryDumper be registered as a Service and have the 
application get this service. I don't like this because now 
RepositoryDumper is visible to everybody just so I can get access to it

Solution 2:
This solution assumes that the declarative approach to the eclipse 
application model is the hindrance and works around it by registering an 
ApplicationDescriptor (org.osgi.service.application). To do so I create a 
DS component that instantiates the RepositoryDumper and also register an 
ApplicationDescriptor as a service. This has the nice attribute that 
everything gets injected and that the application is only available to run 
if all the necessary pieces are available. However it requires a lot of 
code since one has to implement ApplicationDescriptor and 
ApplicationHandle, and I don't think this application would even be 
launchable using the -application argument.

Solution 3:
This solution is an hybrid between 1 and 2 using the 
IExecutableExtensionFactory. 
There is a DS component that creates the RepositoryDumper and register a 
service, let's call it X. Then let's make the class specified in 
application extension (in the plugin.xml) implements 
IExecutableExtensionFactory and have it get the service X. This solution 
allows to have the application construction be completely done by 
injection however given that the application is contributed through 
extension registry it still is visible even though not ready to run.

How are others doing this? Is this a real problem or is it just me? Should 
I just not worry about that and use static fields?
Btw, the code is available /cvsroot/rt 
org.eclipse.equinox/incubator/p2/bundles/org.eclipse.equinox.p2.diagnostic 
Only solution 1 and 2 are available.

Thx for your attention and feedback

PaScaL___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mail

Re: [equinox-dev] Problem when BundleContext.getAllServiceReferences(null, null);

[BJ Hargrave]

You can only get services for which the caller has 
ServicePermission(serviceName, "get"). If your bundle has no service 
permissions, you will get no services.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/09/14 06:24
Subject:
[equinox-dev] Problem when BundleContext.getAllServiceReferences(null, 
null);
Sent by:
equinox-dev-boun...@eclipse.org



Hi, I am getting null object when I try to get AllServices references in 
Equinox framework using :
 
 Result = bundleContext.getAllServiceReferences(null, null);
 
This problem only happens when I use Equinox with security, getting all 
services references if I do not active the security in Equinox.
 
Do I need any special permission? I do not get any AccessControlException 
at all, so I suppoused that I did not need any permission.
 
Do I need to have “GET” permission for any Service?if this is, the problem 
is that I don’t know what Services I have in the framework.
 
Any idea?
 
Thank you in advance
 
David
 ___
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] Problem with custom local permissions

[BJ Hargrave]

Have you written (or installed) a bundle which reads the permissions.perm 
file, parses the text into PermissionInfos and calls either 
PermissionAdmin or ConditionalPermissionAdmin to set the permissions of 
the bundle?

permissions.perm files are not read by the framework. You need s security 
policy bundle installed (for example, as I describe above) to set bundle 
permissions. The framework is policy free.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/09/04 07:59
Subject:
[equinox-dev] Problem with custom local permissions
Sent by:
equinox-dev-boun...@eclipse.org



Hi,
 
I have the next scenario: 
Bundle Service which has a method called addVALUE as  shown:
 
public boolean addValue(String key, Object value) {
 
SecurityManager security = System.getSecurityManager();
  if (security != null) {
security.checkPermission(new PlatformConfigurationPermission(
PlatformConfigurationPermission.WRITE_VALUE)); 
  }
 
}
 
The problem is that other  bundle  called consumer which has the next 
permissions.perm file, tries to call this method getting the Security 
Exception shown below:
 
#TestPlatformConfiguration Permissions File
(java.io.FilePermission "C:\TestingLog3.log" "write")
(es.citic.osgi.system.platformConfiguration.PlatformConfigurationPermission 
"PlatformConfigurationPermission" "writeValue")
 
 
The Exception which was got is:
Java.security.AccessControlException: Access denied 
(es.citic.osgi.system.platformConfiguration.PlatoformConfigurationPermission 
PlatformConfigurationPermission writeValue)
 
 
My PlatformConfigurationPermission class extends from Permission.
 
What am I missing in this implementation?
 
It looks like as does not recognice what I am writing in the 
permission.perm file.
 
Any idea
 
Thank you in advance
 
David___
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] Unclear warning in DS when a service component provides inexisting/unimplemented interface

[BJ Hargrave]

You should probably open a bug for this.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "Kirchev, Lazar" [l.kirc...@sap.com]
Sent: 06/30/2009 02:11 PM ZE2
To: 
Subject: [equinox-dev] Unclear warning in DS when a service component   
provides inexisting/unimplemented interface



Hello,

We are using declarative services and we came across the following
situation. There are two components, A and B. A provides an interface
and B references this interface. If the interface which A provides does
not exist, or is not implemented, when the framework tries to create an
instance of component B, a warning that there is probably a circular
dependancy is logged. This does not help to find the real problem - that
the interface does not exist and there is no such service.

In ComponentReference.getMethod(...), if the result of the call
InstanceProcess.staticRef.getService(...) is null, then it is assumed
that serviceObject cannot be created because of circularity. But
InstanceProcess.staticRef.getService(...) returns null both when there
is circularity and when the service object cannot be retrieved from the
bundle context.

Also, if the component state is checked with the component command, it
is Satisfied, saying in the dynamic information part that all references
of the component are satisfied.

Is this the intended behavior of DS?

Kind regards,
Lazar Kirchev
___
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] org.osgi.framework.system.packages.extra system variable

[BJ Hargrave]

That property is new for OSGi 4.2 which Equinox 3.5 implements.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "Chris Hopkins" [chopk...@cra.com]
Sent: 06/30/2009 10:45 AM AST
To: "Equinox development mailing list" 
Subject: [equinox-dev] org.osgi.framework.system.packages.extra system  variable



Hi all -



I'm trying to get access to the
com.sun.java.swing.plaf.windows.WindowsComboBoxUI class within my
Equinox plug-in. I noticed back in April that Tom had referenced a
org.osgi.framework.system.packages.extra system variable that can be set
to add packages to the list of available packages that the framework
recognizes. However, I can't seem to get it to work. I set the
following:



org.osgi.framework.system.packages.extra=com.sun.java.swing.plaf.windows



but when I start Eclipse I still cannot import the WindowsComboBoxUI
class.



Am I setting the property incorrectly?



I am still using Eclipse 3.4 but I have defined a Target Platform for
this workspace that includes the jars below. I pulled them from a RC
version of Equinox just prior to the official Galileo release.



org.eclipse.equinox.ds_1.1.0.v20090513.jar

org.eclipse.equinox.event_1.1.100.v20090513.jar

org.eclipse.equinox.log_1.2.0.v20090513.jar

org.eclipse.equinox.util_1.0.100.v20090429-1630.jar

org.eclipse.osgi.services_3.2.0.v20090513.jar

org.eclipse.osgi.util_3.2.0.v20090429-1630.jar

org.eclipse.osgi_3.5.0.v20090513.jar



Thanks,

Chris




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] Permission Admin Service Problem

[BJ Hargrave]

Did you start Equinox with security on? Those services are not registered 
unless you start the framework with security on.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "David Conde" [dco...@citic.es]
Sent: 06/26/2009 12:21 PM ZE2
To: "'Equinox development mailing list'" 
Subject: [equinox-dev] Permission Admin Service Problem



Hi everyone,



I would like to use the method getPermissions from Permission Admin Service
in order to get Local permissions information from a bundle location. I have
read that this bundle is already integrated in the framework, and looking
for it in the Equinox bundles I did not found it, but when I tried to get
the service I got NULL, as this service was not installed in the framework.
So, my question is, do I have to download this bundle from anywhere?Is this
bundle still used in OSGI? I read that ConditionalPermissionAdmin service
appeared in newer version of OSGI in order to provide more security
capabilities to OSGI than Permission Admin.



Thank you in advance



David

___
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] Creating heavy weight DS Components

[BJ Hargrave]

One idea is to use a separate component factory for the service(s) 
provided by the BIG component. Reference the component factory from the 
"main" component. When the main component is activated and has completed 
the long running task on the thread, a single instance of the factory 
component is created which then provides the service.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Andrew Teirney 
To:
equinox-dev@eclipse.org
Date:
2009/05/29 17:48
Subject:
[equinox-dev] Creating heavy weight DS Components
Sent by:
equinox-dev-boun...@eclipse.org



I currently have several use cases whereby I am using declarative
services to inject dependent services into a component instance, lets
call this component BIG.

The component BIG is intended to provide several services, however
before it can provide the services it needs to be able to utilize
those dependent service for a setup operation that can take some
lengthy amount of time (needs to access several databases/files).

At present I have been trying to do this in the activate method,
however this does have a time limit and if I understand things
correctly if this time is exceeded then the component will be disposed
of if its takes too long to construct.

So, to get around this in the activate method I spawn a thread that
does the processing in the background, and when it completes I
register the services programatically. This thread obviously has to
take into account any of its services being ripped out from underneath
whilst its using it, and the component itself being deactivated.

What I am wondering is whether this is the best possible solution to a
component being a heavyweight service (in that it takes some time to
properly construct). Other than the complexity of the solution another
aspect I don't like is that the services a component provides are not
part of the declarative services xml (a mild annoyance).

If anyone has any tips/pointers on perhaps how to handle this
heavyweight component creation problem I am encountering that would be
appreciated.

CU,
Andrew
___
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 Bind/Unbind Method Signatures

[BJ Hargrave]

The DS 1.1 spec does NOT require bind and unbind methods for a reference 
to have the same signatures. If the Equinox DS impl requires them to, 
please open a bug.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Andrew Teirney 
To:
equinox-dev@eclipse.org
Date:
2009/05/28 20:18
Subject:
[equinox-dev] Declarative Services Bind/Unbind Method Signatures
Sent by:
equinox-dev-boun...@eclipse.org



Does a declarative services components unbind method have to have the
same signature as its corresponding bind method?

I have noticed in the commit...

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/model/ComponentReference.java?root=RT_Project&view=diff&r1=1.8&r2=1.9


In that change this results in at lines 462,463 for the unbind
invocation using the method parameters as obtained from the bind
method, this results in an IllegalArgumentException if the unbind
method does not have the same signature as the bind method.

CU,
Andrew.
___
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] Framework launching and class loaders

[BJ Hargrave]

You can't "override" exported packages. But, if you use the same package 
version number as exported by a bundle, the framework will prefer an 
already exported package when resolving. Since the framework exports the 
system packages first, then they are preferred.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Jansson Patrik 
To:
Equinox development mailing list 
Date:
2009/05/26 04:43
Subject:
RE: [equinox-dev] Framework launching and class loaders
Sent by:
equinox-dev-boun...@eclipse.org



What will happen if I let the org.eclipse.osgi.services bundle remain 
resolved in my OSGi framework and the system bundle export the same 
version of org.osgi.service.cm? Which package will be imported by other 
bundles (eclipse implementation of ConfigurationAdmin being one of them)?
 
That way, I don't have to care about exporting packages inside 
org.eclipse.osgi.services that is not mutually shared by the launcher and 
bundles inside the framework. So, what I'm asking for is a way to override 
a specific package exported by a bundle (but not all of them), is that 
possible?
 
Thanks,
-Patrik

From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of BJ Hargrave
Sent: den 25 maj 2009 15:12
To: Equinox development mailing list
Subject: Re: [equinox-dev] Framework launching and class loaders

The org.osgi.service.cm package has 2 "version" in your example. One 
loaded from a bundle and used by the ConfigurationAdmin service 
implementation and the other on the application classpath. You need to 
either use reflection to use the service (then you don't need the version 
on the classpath) or you need to configure the framework to export the 
version on the package on the application classpath from the system bundle 
(org.osgi.framework.systempackages.extra) so that the ConfigurationAdmin 
bundle uses that version of the package. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com 

office: +1 386 848 1781
mobile: +1 386 848 3788



From: 
Jansson Patrik  
To: 
"equinox-dev@eclipse.org"  
Date: 
2009/05/25 08:57 
Subject: 
[equinox-dev] Framework launching and class loaders 
Sent by: 
equinox-dev-boun...@eclipse.org




I'm using the framework launching API to start an OSGi framework (which in 
this case is Equinox 3.5M6). 
I need to pass some configuration from the launcher application to one of 
the bundles running so I thought 
of using the ConfigurationAdmin service for this. 
  
The launcher gets hold of a BundleContext (from the framework handle) and 
gets a reference to the 
service; ServiceReference reference = context.getServiceReference(...) 
  
But I get into trouble on the next step 
ConfigurationAdmin cAdmin = (ConfigurationAdmin) 
context.getService(reference); 
This throws a ClassCastException. The actual object returned uses 
equinox's class loader while the class I'm 
trying to cast to, ConfigurationAdmin, is loaded through the launcher's 
standard class loader 
(sun.misc.Launcher$AppClassLoader in this case). 
  
How can I go around this? Shouldn't I be playing with OSGi services 
outside the framework like this? In 
that case how should I pass configuration from the launcher to the bundle? 

  
Thanks, 
-Patrik Jansson 
 ___
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] Framework launching and class loaders

[BJ Hargrave]

The org.osgi.service.cm package has 2 "version" in your example. One 
loaded from a bundle and used by the ConfigurationAdmin service 
implementation and the other on the application classpath. You need to 
either use reflection to use the service (then you don't need the version 
on the classpath) or you need to configure the framework to export the 
version on the package on the application classpath from the system bundle 
(org.osgi.framework.systempackages.extra) so that the ConfigurationAdmin 
bundle uses that version of the package.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Jansson Patrik 
To:
"equinox-dev@eclipse.org" 
Date:
2009/05/25 08:57
Subject:
[equinox-dev] Framework launching and class loaders
Sent by:
equinox-dev-boun...@eclipse.org



I'm using the framework launching API to start an OSGi framework (which in 
this case is Equinox 3.5M6).
I need to pass some configuration from the launcher application to one of 
the bundles running so I thought
of using the ConfigurationAdmin service for this.
 
The launcher gets hold of a BundleContext (from the framework handle) and 
gets a reference to the 
service; ServiceReference reference = context.getServiceReference(...)
 
But I get into trouble on the next step
ConfigurationAdmin cAdmin = (ConfigurationAdmin) 
context.getService(reference);
This throws a ClassCastException. The actual object returned uses 
equinox's class loader while the class I'm
trying to cast to, ConfigurationAdmin, is loaded through the launcher's 
standard class loader
(sun.misc.Launcher$AppClassLoader in this case).
 
How can I go around this? Shouldn't I be playing with OSGi services 
outside the framework like this? In
that case how should I pass configuration from the launcher to the bundle?
 
Thanks,
-Patrik Jansson
 ___
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] Conditional Permission are not being checked

[BJ Hargrave]

That is a rather old version of Equinox 3.5 (M1). Go to 
http://download.eclipse.org/equinox/ to see all the versions available and 
download 3.5 M7.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/05/07 04:32
Subject:
RE: [equinox-dev] Conditional Permission are not being checked
Sent by:
equinox-dev-boun...@eclipse.org



I am sorry, I found the new version 3.5 of Equinox in 
http://www.eclipse.org/downloads/download.php?file=/equinox/drops/S-3.5M1-200808071402/org.eclipse.osgi_3.5.0.v20080804-1730.jar
 
So I will try with this one and I will write back the results.
 
David
 
De: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] En nombre de David Conde
Enviado el: jueves, 07 de mayo de 2009 10:26
Para: 'Equinox development mailing list'
Asunto: RE: [equinox-dev] Conditional Permission are not being checked
 
Hi again, where I can get Equinox 3.5 I tried to get from 
http://download.eclipse.org/equinox/drops/R-3.4.2-200902111700/index.php, 
but there is just to version 3.4 to download.
 
I do not know really the problem and If I am missing something, I have a 
Permission Manager, who grant to itself ALLPERMISSION, and in this bundle 
we fix a BundleLocationCondition in order that my bundle
 
file:C:\\equinoxv34\\clientserviceconditional.jar is the only one who can 
Get the Service from ServiceConditional. Am I wrong? What option do I have 
to write when I launch Equinox in console way?
 
cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new

String[]{"file:C:\\equinoxv34\\clientserviceconditional.jar"})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),
"dconde.osgi.serviceconditional.ServiceConditional","GET")

});
Thank you very much in advance
 
 
 
De: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] En nombre de Thomas Watson
Enviado el: miércoles, 06 de mayo de 2009 18:52
Para: Equinox development mailing list
Asunto: Re: [equinox-dev] Conditional Permission are not being checked
 
Can you try this on 3.5? The OSGi R4.2 specification (implemented in 
Equinox 3.5) made a clarification about when the default permissions from 
PermissionAdmin are used in the presence of the ConditionalPermissionAdmin 
service.

The default default permissions for PermissionAdmin is AllPermissions. In 
Equinox 3.4 we would fall back to the PermissionAdmin default permissions 
if none of the conditions from the ConditionalPermissionAdmin table were 
satisfied for a particular bundle. The OSGi R4.2 specification has been 
clarified such that the PermissionAdmin default permissions are ONLY used 
if the condition table is COMPLETELY empty. Once you add a single 
condition to the table then bundles must not be granted the 
PermissionAdmin default permissions.

In 3.4 you should set the PermissionAdmin default permissions to a 
restricted set of permissions or you could set another condition with 
ConditionalPermissionAdmin which restricts the permissions for all bundle 
locations.

Tom



"David Conde" ---05/06/2009 11:08:03 AM---Hi,


From:

"David Conde" 

To:



Date:

05/06/2009 11:08 AM

Subject:

[equinox-dev] Conditional Permission are not being checked




Hi, 

I am trying to check Conditional Permssion Admin SErvice in Equinox. For 
this reason, I create a Bundle consumer, another one called service and 
another called PermissionManager who will implement the Conditional 
Permissions for the consumer.

The problem is that I do not get any exception when I try to get the 
service from another location different from my allowed one.

My PermissionManager implements BundleActivator and get the service 
ConditionalPermissionAdmin from the framework in the start method, finally 
is shown below:

private ConditionalPermissionAdmin cpa;

condPermRef = context.getServiceReference(ConditionalPermissionAdmin.class
.getName());

cpa =(ConditionalPermissionAdmin) context.getService(condPermRef);

AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
cpa.addConditionalPermissionInfo(new ConditionInfo[]{
new ConditionInfo(BundleLocationCondition.class.getName(),
new
String[]{context.getBundle().getLocation()})
},
new PermissionInfo[]{
new PermissionInfo(
AllPermission.class.getName(), "", "")
});

cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new

String[]{"file:C:\\equinoxv34\\clientserviceconditional.jar"})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),
"dconde.osgi.serviceconditional.ServiceConditional","GET")

});
// Add other permis

Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation

[BJ Hargrave]

Andy,

Can you file a bug on this?
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Andy Wilkinson 
To:

Date:
2009/05/06 09:22
Subject:
[equinox-dev] ClassLoader leak caused by EventManager's EventThread 
creation
Sent by:
equinox-dev-boun...@eclipse.org



Hi,

I've been looking into a PermGen leak and have identified what looks to 
be an undesirable side-effect of 
org.eclipse.osgi.framework.eventmgr.EventManager's creation of an 
EventThread instance. In my particular situation the EventManager 
instance is MRUBundleFileList's bundleFileCloserManager. I'm running on 
3.5.0.v20090311-1300.

When the EventThread is lazily created, it gets its context class loader 
from the current thread. In my situation it's a call from a non-Equinox 
owned thread that's triggered the lazy creation of the EventThread 
instance. In this case at least, it doesn't seem right for this 
Equinox-owned thread to be holding a reference to this foregin class 
loader, particularly as it's not easy to update the EventThread's 
context classloader in application code. The reference to the 
classloader leads to a PermGen leak as the classloader doesn't become 
eligible for garbage collection.

With the caveat that I don't know if there is some expectation about 
what the event thread's context class loader should be, I wonder if it 
would be better if EventManager was updated to explicitly set an 
EventThread's context class loader, possibly to Equinox's classloader, 
i.e. EventManager.class.getClassLoader()?

Regards,
Andy
___
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] policy="dynamic" in Declarative Services.

[BJ Hargrave]

This does not sound like a "flicker" problem. DS can handle that also for 
a dynamic 1..1 reference. The new service would be passed to bind before 
the old service is passed to unbind. So the component is never without a 
dependent service.

I think the issue here is that there is no replacement service available 
and, with a 1..1 cardinality, the component is deactivated.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Hal Hildebrand 
To:
Equinox development mailing list 
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy="dynamic" in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org



There's also Spring/DM, which does I think what you want - i.e. 1..1 
cardinality, but not dropping the service is its dependencies 
momentarily flicker.

On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:

> You cannot directly do this, because mandatory reference is mandatory
> at all times. However, you could make the reference optional and
> perform some kind of internal activation/deactivation in the
> bind/unbind methods.
>
> However, if that still doesn't work for you then you're trying to do
> something outside the scope of use-cases supported by DS, so you
> should drop down to the ServiceTracker API.
>
> Regards,
> Neil
>
>
> On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
>  wrote:
>> Hi  Kai,
>>
>> On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai > >
>> wrote:
>>>
>>> HI Sameera,
>>>
>>>
>>>
>>> I think Equinox’ behavior is correct here. If you have a mandatory 
>>> service
>>> reference that is not valid anymore, the referring component has 
>>> to be
>>> deactivated even if the policy is dynamic.
>>
>> I agree with your point.  Now say that the service is mandatory 
>> when the
>> component is activated. Once the component is activated, the 
>> service is a
>> optional one. That mean I don't want my component to be de- 
>> activated when
>> the service is unregistered. How can I handle this situation with
>> declarative services?
>>
>> Thanks
>> Sameera
>>>
>>>
>>>
>>>> But my requirement is that the service should be registered 
>>>> before the
>>>> component is activated.
>>>
>>>> in that case I have to put cardinality as "1..1" right?
>>>
>>> I guess your question is related to the lazy activation of 
>>> components.
>>> This is the default unless you declare the component itself 
>>> “immediate”. The
>>> meaning is: Unless no one wants to use your service, the component 
>>> (the
>>> implementing Java class) will not be instantiated.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Kai
>>>
>>>
>>>
>>> From: equinox-dev-boun...@eclipse.org
>>> [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera 
>>> Jayasoma
>>> Sent: Montag, 4. Mai 2009 04:59
>>> To: Equinox development mailing list
>>> Subject: Re: [equinox-dev] policy="dynamic" in Declarative Services.
>>>
>>>
>>>
>>> Hi,
>>>
>>> On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin  
>>> wrote:
>>>
>>> if u want to the component isn't deactivated,u should set the bound
>>> service cardinality to "0..1"
>>>
>>>
>>> Thanks for the quick reply. But my requirement is that the service 
>>> should
>>> be registered before the component is activated. in that case I 
>>> have to put
>>> cardinality as "1..1" right?
>>>
>>> Thanks
>>> Sameera
>>>
>>> 2009/5/4 Sameera Jayasoma :
>>>
>>>> Hi devs,
>>>>
>>>> Even though I have used the value "dynamic" for the "policy" 
>>>> attribute
>>>> in
>>>> the "reference" element, the component is deactivated once the 
>>>> bound
>>>> service
>>>> is unregistered. Here is the component.xml I am using.
>>>>
>>>> http://www.osgi.org/xmlns/scr/v1.0.0";>
>>>> 
>>>> >>> class="org.wso2.carbon.core.internal.CarbonCoreDSComponent"/>
>>>> >>> value="carbon.core.dscomponent"/>
>>>> &

Re: [equinox-dev] Security Doubt

[BJ Hargrave]

You can configure your system to support this. Note: since using 
permission is invasive in Java code (doPrivileged), all the bundles, in 
particular B, must be properly coded with the necessary doPrivileges to 
make it work.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"David Conde" 
To:

Date:
2009/04/28 05:18
Subject:
[equinox-dev] Security Doubt
Sent by:
equinox-dev-boun...@eclipse.org



Hi , I have a doubt about permissions in Equinox, I would like to have the 
next scenario.
 
I would like to have a set of bundles called A,A1, A2 running in Equinox, 
which are able to communicate and know about bundle B, but they do not 
know about the existence of bundle C, all of them running as well on 
Equinox. I mean, Bundle A,A1,A2 have permissions either to get service or 
import service from bundle B, bundle B have permissions either to import 
or get the service from C, and A, A1 and A2 are not able to get or import 
service from C. My question is ¿if it is possible to use bundle B from 
bundles A,A1,A2 to get acess to C service?Will either Java security or 
Equinox Security thrown an exception in this case?
 
 
Thank you in advance
 
 
 ___
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] ServiceReference.compareTo(Object)

[BJ Hargrave]

Please open a bug in the bugzilla system for this.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
岡野　真一 
To:
equinox-dev@eclipse.org
Date:
2009/04/24 05:37
Subject:
[equinox-dev] ServiceReference.compareTo(Object)
Sent by:
equinox-dev-boun...@eclipse.org



Hi all !

I am using Equinox 3.4.2, and I thik I found a bug.

The Javadoc of "org.osgi.framework.ServiceReference.compareTo(Object)"
says the following:

This ServiceReference is less than the specified ServiceReference if
it has a lower service ranking and greater if it has a higher
service ranking. Otherwise, if this ServiceReference and the
specified ServiceReference have the same service ranking, this
ServiceReference is less than the specified ServiceReference if it
has a higher service id and greater if it has a lower service id.

But,
org.eclipse.osgi.framework.internal.core.ServiceReferenceImpl.compareTo(Object)
(version=3.4.3.R34x_v20081215-1030) is implemented the following.

if (this.getRanking() != other.getRanking())
return this.getRanking() > other.getRanking() ? -1 : 1;
return this.getId() == other.getId() ? 0 : this.getId() > 
other.getId() ? 1 : -1;

I think the following is correct.

if (this.getRanking() != other.getRanking())

return this.getRanking() > other.getRanking() ? 1 : -1;  //  <--

return this.getId() == other.getId() ? 0 : this.getId() > 
other.getId() ? -1 : 1;  // <<-


I'm sorry if I have a mistake, or if it had already been discussed.

Thanks.

-- 
-
Shinichi Okano  (okano-shini...@sei.co.jp)

___
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 port on Android

[BJ Hargrave]

See http://www.eclipsecon.org/2008/index.php?page=sub/&id=380. The 
presentation attached there includes a link to a patch but that patch is 
probably against a 3.4 milestone driver.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
Mathieu Baudier 
To:
equinox-dev@eclipse.org
Date:
2009/04/20 05:28
Subject:
[equinox-dev] Equinox port on Android
Sent by:
equinox-dev-boun...@eclipse.org



Hi,

I have read in many places that Equinox has been successfully ported to 
Android (Google's mobile OS). 

(e.g. 
http://mobileosgi.blogspot.com/2008/06/public-resources-about-mobile-osgi.html 
or 
http://www.google.at/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Ffelix.apache.org%2Fsite%2Fpresentations.data%2FOSGi%2520on%2520Google%2520Android%2520using%2520Apache%2520Felix.pdf&ei=AkDsSe3fEMSF_QaanujiAw&usg=AFQjCNHf5TIqvPlTeJiRXa9LQhFmsnn8Jw&sig2=siaja0VPiHqhG0PYEVR2jw
, page 44).

Unfortunately, I could find anywhere more detailed technical information 
or code/download.

Could anyone please point me to some information?

Many thanks in advance!

Mathieu___
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] Adding Equinox Declarative Services (DS) to theEclipse SDK

[BJ Hargrave]

+1
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:
"Toedter, Kai" 
To:
"Equinox development mailing list" , "General 
development mailing list of the Eclipse project." 

Date:
2009/01/26 11:46
Subject:
RE: [equinox-dev] Adding Equinox Declarative Services (DS) to   theEclipse 
SDK
Sent by:
equinox-dev-boun...@eclipse.org



+1
 
Actually, a few month ago I have filed a bug for adding DS to the Eclipse 
SDK, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253926
 
Kai
 
From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Chris Aniszczyk
Sent: Montag, 26. Januar 2009 17:35
To: General development mailing list of the Eclipse project.
Cc: Equinox development mailing list
Subject: [equinox-dev] Adding Equinox Declarative Services (DS) to 
theEclipse SDK
 
Howdy y'all. I like to raise the question of us adding Equinox DS to the 
Eclipse SDK. DS provides a powerful way to deal with OSGi services and in 
my opinion, greatly simplifies the development of services. As we forge 
towards Eclipse 3.5, we made a lot of steps to make DS easier to use in 
the Eclipse SDK without it actually being in the SDK:

- Prosyst donated a high quality implementation of OSGi DS that made its 
way to the Equinox SDK
- PDE release DS component authoring tools as part of a GSOC project and 
3.5 work
- The DS spec was updated to work better with lazy bundles (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575)

Technically, to add DS to the Eclipse SDK all we need to do as add these 
two tiny bundles:

 org.eclipse.equinox.ds (.15MB)
 org.eclipse.equinox.util (.02MB)

So my request in sending this email out is to get the opinion of consumers 
(anyone who builds applications on top of Eclipse) and producers (the 
Eclipse platform team, especially the Equinox committers). Do consumers 
see a benefit of having DS in the SDK? Does the greater Eclipse team feel 
comfortable with having DS in the SDK and may use it in the future 
potentially?

And if we reach a consensus, it would be great to see DS included with the 
Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun 
discussion :)

Thoughts?

Cheers,

Chris Aniszczyk___
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] Support for RFC 119

[BJ Hargrave]

> Thanks to whoever did that!

You're welcome :-)

>   Should I open an enhancement request to add a REMOTE type and attach a 

> patch to contribute an addition/change? (e.g.):

I will open a bug in OSGi to fix that. In the interim just use the 
numerical value 5.

> One question:  does this framework change appear somewhere else in the 
> r4.2 spec? (i.e. other than 119)?  As it seems to imply that RFC 119 
> isn't stand-alone (that is, it requires this small addition to 
framework).

119 relies on come changes in 4.2 (e.g. ServiceHooks). ServiceException is 
one of them.

>   Are there conventions about this (placement) that dictate what 
> package(s) these interfaces should be in?  If so, where is that? 

These should already be in one of the jars from OSGi. Tom?


-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

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

Re: [equinox-dev] What bundle class loaded from

[BJ Hargrave]

Not in any standard way. A framework is free to store an installed bundle 
in any way is chooses. It could keep the original JAR file, expand it to 
the file system, put all the entries in a database, convert it to some VM 
optimized format, etc.
-- 

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:
"Fredrik Alströmer" <[EMAIL PROTECTED]>
To:
"Equinox development mailing list" 
Date:
2008/11/26 08:46
Subject:
Re: [equinox-dev] What bundle class loaded from
Sent by:
[EMAIL PROTECTED]



On a similar note, is there a way to access the actual bundle file?
Like for running an external javac-process (think tomcat jasper),
which needs a classpath.

On Mon, Nov 24, 2008 at 18:15, BJ Hargrave <[EMAIL PROTECTED]> wrote:
> PackageAdmin.getBundle(Class)
> --
>
> 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:
> Oleg Zhurakousky <[EMAIL PROTECTED]>
> To: Equinox development mailing list 
> Date: 2008/11/24 12:04
> Subject: [equinox-dev] What bundle class loaded from
> Sent by: [EMAIL PROTECTED]
> 
>
>
> I know how to do it the "hard way", but was wondering if there is and
> elegant way to determine which Bundle loaded a class?
> Thanks
> Oleg
> ___
> 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] What bundle class loaded from

[BJ Hargrave]

PackageAdmin.getBundle(Class)
-- 

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:
Oleg Zhurakousky <[EMAIL PROTECTED]>
To:
Equinox development mailing list 
Date:
2008/11/24 12:04
Subject:
[equinox-dev] What bundle class loaded from
Sent by:
[EMAIL PROTECTED]



I know how to do it the "hard way", but was wondering if there is and 
elegant way to determine which Bundle loaded a class?
Thanks
Oleg
___
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