Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones

[BJ Hargrave]

Given bugzilla provides a clone this bug link, I think option #2 is the 
best choice.


-- 

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




Thomas Watson/Austin/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
2007-07-11 13:42
Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
equinox-dev@eclipse.org
cc

Subject
[equinox-dev] What to do with 3.3.1 candidate bugs and milestones







Each major release the same thing happens.  We start fixing bugs in HEAD 
for the next major release but find a few fixes that we would like to also 
release into a maintenance release.  Then we have to decide what to do 
with the status of the original bug report which was used to release the 
fix into HEAD.  I have seen this handled in two ways. 

1) Leave the bug open and mark the milestone to the next maintenance 
release milestone (e.g. 3.3.1) and make a comment in the bug report 
stating the fix was released to HEAD.  If/When the fix gets approved and 
released for the maintenance release then the bug is marked as fixed; 
otherwise we make a note that the fix is not going to be included in the 
maintenance release and the milestone is updated to major milestone the 
fix was included and marked as fixed. 

2) Resolve the bug report and mark the milestone appropriate for the next 
major release (e.g. 3.4 M1) and open a separate bug with a proper 
milestone for the maintenance release (e.g. 3.3.1). 

For the past couple of releases the Equinox team has used option #1 but 
this has a few drawbacks.  First of all, it gives inaccurate search 
results when querying bugzilla for the list of bug fixes for the next 
release milestone because code was released into the milestone but the bug 
is left open and marked for a maintenance stream.  Also I find it 
generally confusing that the bug status does not reflect the fixed state 
of the bug until we can get approval and actually release the bug into the 
maintenance stream. 

The second approach has its advantages because it accurately reflects the 
state of the bug for a particular stream and makes for more accurate 
search results for fixed bugs and milestones.  But there is a risk that 
the open bug against the maintenance stream will not get approved for 
release and then we would have to resolve the bug as wontfix (or 
something).  I'm not sure that is really a problem because at least the 
reason why the fix is not in the maintenance stream is recorded.  Another 
disadvantage is that the bugs will look like duplicates which could cause 
confusion. 

What are other committers preferences?  How is this handled on other 
teams?  Is there a standard Eclipse way to handle this? 

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: AW: [equinox-dev] [sec] JAAS framework dependency on Eclipse

[BJ Hargrave]

I think the more general point here is why are extensions being used here 
instead of services (which already come built into the OSGi framework) as 
the means of connecting the various players of the JAAS framework? Is 
there something about the JAAS framework design that cannot be done, or 
done well, with services?

Sure one can install the registry (and its dependent bundles) on the OSGi 
framework and use them, but why introduce that coupling unless it truly is 
necessary? I would like to think that we may want to include the JAAS 
framework design in the OSGi spec. But I don't see that OSGi specified 
version of a JAAS framework will be based upon extensions.
-- 

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




Pascal Rapicault [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
2007-09-04 13:48
Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
Equinox development mailing list equinox-dev@eclipse.org
cc

Subject
Re: AW: [equinox-dev] [sec] JAAS framework dependency on Eclipse






The extension registry is an OSGi bundle, to that respect it runs on any
OSGi implementation.
And for curious, it even runs without OSGi.

PaScaL


  
  From:   Matt Flaherty [EMAIL PROTECTED]   
  
  To: Equinox development mailing list equinox-dev@eclipse.org   
 
  
  Date:   09/04/2007 10:58 AM  
  
  Subject:Re: AW: [equinox-dev] [sec] JAAS framework dependency on 
Eclipse 
  






In the bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=202156

Chris rightly points out that I may have been heavy-handed with 'pure' ;)

Certainly the registry can be used in other environments.. Though I've
never tried it, the framework may very well work if you simply include the
registry. Let me know if there is anything I can do to help get your
environment up and running.

-matt

---
Matt Flaherty
Security Project Lead, Lotus Notes  Eclipse Equinox
External: http://www.eclipse.org/equinox/incubator/security/
Internal: https://cs.opensource.ibm.com/projects/eclipsesec/

[EMAIL PROTECTED] wrote on 09/04/2007 10:11:25 AM:

 That answers my other question as well. Thanks.

 I'm going to file a bug right now and will contribute code if I can come
 up with something generic.

 I wonder whether the OSGi specification has already hooks available to
 put something like framework wide authentication.

 Thanks again and regards

 Arthur

 Matt Flaherty wrote:
 
  The authentication code currently relies on extension points to
  contribute the JAAS artifacts, so I don't believe it will currently
 work
  in a pure OSGi environment.
 
  Nothing is currently planned in this direction - primarily because no
  one has asked yet... Requirements (via bugzilla) and contributions are

  both welcome :)
 
  ---
  Matt Flaherty
  Security Project Lead, Lotus Notes  Eclipse Equinox
  External: http://www.eclipse.org/equinox/incubator/security/
  Internal: https://cs.opensource.ibm.com/projects/eclipsesec/
 
  [EMAIL PROTECTED] wrote on 09/04/2007 09:33:34 AM:
 
Hi all
   
I'm looking for a way to leverage the authentication functionality
provided by JAAS for an application running on Equinox (not
 depending on
the rest of Eclipse). Is it possible to leverage the Equinox
 Security
framework for this or is it necessary to use the (Eclipse specific)
extension points it provides to use it? Or are there any plans on
 making
it a pure OSGi bundle?
   
Regards
   
Arthur
   
___
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


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

Re: [equinox-dev] Equinox-Bundles component is getting crowded

[BJ Hargrave]

It would probably be best if each separately downloadable item had its own 
component against which people could file bugs.
-- 

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:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-09-12 12:34
Subject:
Re: [equinox-dev] Equinox-Bundles component is getting crowded



For the security stuff I was referring to the security-specific bundles 
like login (JAAS integration etc.)

You are right there is a lot of cross-cutting concerns with the other 
security related work that will not really fit into any one component.

Tom



John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component for p2 
definitely makes sense to me. I don't know much about the security work, 
but that may be diffi

John Arthorne [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 11:21 AM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org




To

Equinox development mailing list equinox-dev@eclipse.org

cc


Subject

Re: [equinox-dev] Equinox-Bundles component is getting crowded






Creating a new component for p2 definitely makes sense to me. I don't know 
much about the security work, but that may be difficult to partition into 
its own component because it's an inherently cross-cutting concern. If 
there end up being a number of security-specific bundles, it may make 
sense. 

Generally speaking, I think more components is a good thing. It's a great 
way to bring in new committers who may not be able to make the large 
commitment needed to contribute across a large part of Equinox. 

John 


Thomas Watson [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 11:42 AM 


Please respond to
Equinox development mailing list equinox-dev@eclipse.org



To
equinox-dev@eclipse.org 
cc

Subject
[equinox-dev] Equinox-Bundles component is getting crowded








The Equinox project continues to grow with new components and new 
contributes being added. Thanks everyone!!

As new contributions are graduated into Equinox proper we need to place 
them under one of the existing components. Currently we have the 
Framework and Bundles components for Equinox proper in bugzilla/cvs. A 
large majority of the new contributions will fall into the Bundles 
component. For example, we have a few work areas in the equinox incubator 
which are very active (e.g. p2, security etc). Once this work graduates it 
will likely to be placed into the generic Bundles component. This will 
make an already crowded component even more crowded. 

Should we consider creating a more diverse set of components for the work 
which is graduated into Equinox? I think the p2 and security work will 
deserve their own component when they graduate. Thoughts?

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

attachment: pic01850.gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Equinox-Bundles component is getting crowded

[BJ Hargrave]

[EMAIL PROTECTED] wrote on 2007-09-12 14:47:42:

 There are two extreme positions to take. Lump a large number of 
 loosely related deliverables under one component or create a 
 separate component for each and every deliverable. I'm not sure I 
 favor the latter extreme. Currently the Equinox download page allows
 you to download each bundle individually so each bundle is a 
 separate downloadable item. Creating a separate component for each 
 and every bundle in Equinox may prove to be too much overhead.

What overhead? The provisioning of a set of components for the Equinox 
product in bugzilla?

 It is
 my understanding that in Eclipse typically every bugzilla component 
 has its own set of commit rights in CVS. 

I am not sure this is true. According to portal.eclipse.org, I am a 
committer on eclipse, eclipse.equinox and eclipse.incubator. Thus it would 
seem to me we only need to elect one to eclipse.equinox to have commit 
rights to all the framework and the various potential bundle components.

 If we have a very high 
 number of components then we will be holding a very large number of 
 committer elections to get all the committers the access they need :-)
 
 I think we a balance and create components as we see fit to split up
 the different work areas in Equinox instead of creating a component 
 for every bundle.

I think the think you want to minimize is the number of committer groups. 
Assuming that bugzilla components are not tied to committer groups, then 
there is no reason not to have a 1-1 mapping of downloadable items to 
bugzilla components.

 
 Tom
 
 

-- 

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

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

Re: [equinox-dev] Equinox-Bundles component is getting crowded

[BJ Hargrave]

What is the point of the proposed change?  Tom's mail suggests we 
subdivide bundles. But in what way? To organize commit rights or bugs in 
bugzilla? Or both? I guess that is what is not clear. Clarity here will 
help us evaluate choices. It seems we can easily have M bugzilla 
components and N commit right sets with M =N. Right now (for bundles) M 
and N both equal 1. Are we looking to increase M or N or both?
-- 

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:
Jeff McAffer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-09-12 16:03
Subject:
Re: [equinox-dev] Equinox-Bundles component is getting crowded




yes but under the new plan you pointed out, the commit rights will be 
managed by groups and groups will have a 1:1 relationship to components 
and components will have associated leads, bugzilla entries, websites, ... 
 This is alot of infrastructure to put in place for each bundle. 

We did bundles originally because we could not come up with any 
reasonable partitioning of the space.  To date we have gotten away with it 
because a) the number of bundles in there was relatively low and b) many 
have very little activity.  As Tom points out, this is changing.  Our 
solution space seem to be N bundles = 1 group, N groups or M groups where 
1  M  N.  Unfortunately, it is still not clear that there is a 
reasonable grouping so while (at least to me) M groups feels like a good 
spot, it will be challenging.  Here are some thoughts 
- framework = the framework.  This stays unchanged 
- standard = bundles that implement OSGi standard services 
- p2 
- security = if needed 
- bundles = catch all for things that don't fit   

This is just a stake in the ground. 

Jeff 



John Arthorne/Ottawa/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 03:42 PM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
Equinox development mailing list equinox-dev@eclipse.org 
cc

Subject
Re: [equinox-dev] Equinox-Bundles component is getting crowded









Since component is a confusing term, I should clarify my comments on 
this.  I like the idea of being more fine-grained with Unix groups (CVS 
commit rights), because I think it encourages new committers. If someone 
joins the community with a strong interest in a narrow area (such as 
security or provisioning), but isn't interested in the rest of the 
framework, they could quickly earn commit rights in that area, without 
having to give them write access to other code they aren't qualified to 
maintain (or aren't interested in maintaining).  On the question of 
bugzilla components, I don't particularly care whether we have one or ten 
- these are fairly easy to change over time as the need arises. 

John 


John Arthorne/Ottawa/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 03:24 PM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org



To
Equinox development mailing list equinox-dev@eclipse.org 
cc

Subject
Re: [equinox-dev] Equinox-Bundles component is getting crowded











I agree one component per bundle is probably overkill.  However, it's not 
necessarily true that the CVS commit groups match 1-1 with Bugzilla 
groups. While it's often convenient to do it this way, it's not a 
constraint that we need to conform to.  I should also add that the EMO has 
a plan under consideration for standardizing the group structure for Unix 
groups, and part of this work is to facilitate election across multiple 
groups (see item 6 in 
https://bugs.eclipse.org/bugs/attachment.cgi?id=77092).  Essentially, 
simultaneously nominating an individual for N groups would only require a 
single election, and a single vote per committer. Just some things to 
consider... 


Thomas Watson [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 02:47 PM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org



To
Equinox development mailing list equinox-dev@eclipse.org 
cc

Subject
Re: [equinox-dev] Equinox-Bundles component is getting crowded












There are two extreme positions to take. Lump a large number of loosely 
related deliverables under one component or create a separate component 
for each and every deliverable. I'm not sure I favor the latter extreme. 
Currently the Equinox download page allows you to download each bundle 
individually so each bundle is a separate downloadable item. Creating a 
separate component for each and every bundle in Equinox may prove to be 
too much overhead. It is my understanding that in Eclipse typically every 
bugzilla component has its own set of commit rights in CVS. If we have a 
very high number of components then we will be holding a very large number 
of committer elections to get all the committers the access they need :-)

I think we a balance and create components as we see fit

Re: [equinox-dev] Equinox-Bundles component is getting crowded

[BJ Hargrave]

 It is about community and clarity for our consumers.

I don't see how arbitrary groupings help here. The whole point of the 
component model is people pick the components they need which is why it is 
good that people can download bundles individually. Arbitrary groupings 
would be more interesting perhaps if you actually delivered against the 
groupings.

 Why not reify the structure we think we have?

I think part of the issue is that there is no common view of the structure 
we think we have to reify it.

  would the http service be part of standard services or server side?

You totally avoid this question by avoiding arbitrary groupings like 
standard services and server side. 

Perhaps this whole topic deserves a small slot on the Equinox Summit 
agenda?
-- 

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:
Jeff McAffer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-09-13 09:04
Subject:
Re: [equinox-dev] Equinox-Bundles component is getting crowded




to me it is neither of these options.  It is about community and clarity 
for our consumers.  Walking up to Equinox you just have a sea of bundles. 
Add in the p2 and security stuff and the sea turns into an ocean.  Say you 
hear that Equinox has implementations of some OSGi service specs.  If you 
go to the download page today you have to grovel through spec impls, 
launchers, random other stuff and cannot tell one from the other.  Since 
there is no particular web/wiki page for people interested in spec 
implementations, it is hard to build a community around that topic. People 
interested in contributing to standard spec impls cannot easily find 
related bugs etc.  There is also no clear lead of that community who is 
plotting the course/planning, coordinating execution, building the 
community, ...  You can replace OSGi service spec with p2, security, ...   


A number of these issues can be addressed simply by structuring the 
download site or wiki or...  If you address most of them then in effect 
you have just created a component without actually creating a component. 
So what are we afraid of?  Why not reify the structure we think we have? 

That begs the question, what is the structure? The challenge is that all 
partitionings will have problems as different people have different views 
on the world.  would the http service be part of standard services or 
server side?  However the existance of issues need not stop progress or 
movement.  So this discussion is really about defining that structure.  At 
least thats my view... 

Jeff 



BJ Hargrave [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 05:13 PM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
Equinox development mailing list equinox-dev@eclipse.org 
cc

Subject
Re: [equinox-dev] Equinox-Bundles component is getting crowded








What is the point of the proposed change?  Tom's mail suggests we 
subdivide bundles. But in what way? To organize commit rights or bugs in 
bugzilla? Or both? I guess that is what is not clear. Clarity here will 
help us evaluate choices. It seems we can easily have M bugzilla 
components and N commit right sets with M =N. Right now (for bundles) M 
and N both equal 1. Are we looking to increase M or N or both?
-- 

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:
Jeff McAffer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-09-12 16:03
Subject:
Re: [equinox-dev] Equinox-Bundles component is getting crowded




yes but under the new plan you pointed out, the commit rights will be 
managed by groups and groups will have a 1:1 relationship to components 
and components will have associated leads, bugzilla entries, websites, ... 

This is alot of infrastructure to put in place for each bundle. 

We did bundles originally because we could not come up with any 
reasonable partitioning of the space.  To date we have gotten away with it 

because a) the number of bundles in there was relatively low and b) many 
have very little activity.  As Tom points out, this is changing.  Our 
solution space seem to be N bundles = 1 group, N groups or M groups where 

1  M  N.  Unfortunately, it is still not clear that there is a 
reasonable grouping so while (at least to me) M groups feels like a good 
spot, it will be challenging.  Here are some thoughts 
- framework = the framework.  This stays unchanged 
- standard = bundles that implement OSGi standard services 
- p2 
- security = if needed 
- bundles = catch all for things that don't fit 

This is just a stake in the ground. 

Jeff 



John Arthorne/Ottawa/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/12/2007 03:42 PM 

Please respond to
Equinox development

Re: [equinox-dev] Moving Service Activator Toolkit (SAT) from the Open Healthcare Framework (OHF) to Equinox

[BJ Hargrave]

There was a bug in KF which prevented using SAT on KF. But I understand KF 
has recently fixed that bug[1]. So SAT should work on any correct OSGi 
framework.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg00490.html
-- 

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:
Peter Neubauer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-09-26 16:03
Subject:
Re: [equinox-dev] Moving Service Activator Toolkit (SAT) from the Open 
Healthcare Framework (OHF) to Equinox



Hi there,
is there anything special to Equinox in SAT or can the SAT bundles be used 
with any OSGi compliant framework?

/peter

On 9/26/07, Simon J Archer [EMAIL PROTECTED] wrote:

+1 for Patrick's proposal. 



Patrick Dempsey [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED] 
09/26/2007 03:44 PM 

Please respond to
Equinox development mailing list equinox-dev@eclipse.org



To
Equinox development mailing list equinox-dev@eclipse.org 
cc

Subject
[equinox-dev] Moving Service Activator Toolkit (SAT) from the Open 
Healthcare Framework (OHF) to Equinox








Currently the Service Activator Toolkit (SAT) in the Open Healthcare 
Framework (OHF) technology project that is of great value to people 
programming OSGi Applications.  SAT is a Java component that simplifies 
the building of OSGi service-oriented bundles. It is approximately 8,000 
lines of Java code. By decreasing the complexity of OSGi bundle 
development, this toolkit provides increased acceptance of OSGi in the 
device community. In addition to making the use of OSGi services easier, 
it supports the creation of well behaved bundles, reducing development 
time, reducing training costs, and promotes consistent bundle behavior. It 
seems that this technology is somewhat misplaced and it would better serve 
the community if it was part of the Equinox project. 

I propose moving SAT from OHF to Equinox.  As this code is very stable, 
robust and has been previously used in commercial products, I would ask 
that it be reviewed for eligibility for moving in the graduated Equinox 
bundles area, rather than the Equinox Incubator. 

For reference SAT is in cvs at 
:pserver:dev.eclipse.org:/cvsroot/technology 
org.eclipse.ohf/plugins/org.eclipse.soda.sat 

There is also lots of good information (documentations, bug reporting, 
downloads) at  
http://eclipse-sat.blogspot.com/ 

Patrick 

___
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




-- 
GTalk:neubauer.peter
Skype:   peter.neubauer
ICQ:   18762544
Phone:   +46704 106975
Mail:   [EMAIL PROTECTED] 
___
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] [prov] p2 calls and Thanksgiving

[BJ Hargrave]

Uh, Thanksgiving is Thursday the 27th of *November* in the US :-) Nice try 
though!
-- 

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:
Pascal Rapicault [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-10-05 14:08
Subject:
[equinox-dev] [prov] p2 calls and Thanksgiving




Regardless of Thanksgiving (Monday the 8th in Canada and Monday the 15th 
in
USA) the p2 calls will take place for those that are not forced to eat
turkey :-)
Happy thanksgiving in advance, and happy Mondays !

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] [prov] p2 calls and Thanksgiving

[BJ Hargrave]

I meant 22nd, but my point is it is in November.
-- 

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:
BJ Hargrave/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-10-05 14:34
Subject:
Re: [equinox-dev] [prov] p2 calls and Thanksgiving



Uh, Thanksgiving is Thursday the 27th of *November* in the US :-) Nice try 

though!
-- 

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:
Pascal Rapicault [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2007-10-05 14:08
Subject:
[equinox-dev] [prov] p2 calls and Thanksgiving




Regardless of Thanksgiving (Monday the 8th in Canada and Monday the 15th 
in
USA) the p2 calls will take place for those that are not forced to eat
turkey :-)
Happy thanksgiving in advance, and happy Mondays !

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

Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

[BJ Hargrave]

You need to, as part of the release process, use tooling, like japitools, to 
examine each package for changes, including non-backwards compatible changes. 
Then, at the end of the release, the package and bundle version numbers can be 
properly increased. We do this in the OSGi release process.


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


- Original Message -
From: Thomas Watson
Sent: 01/11/2008 01:45 PM
To: Equinox development mailing list equinox-dev@eclipse.org
Subject: Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider
Export-Package  as API




Without tooling this will be difficult.  If we wanted to use the big hammer
approach the we would have the API tooling (or plain old PDE) mark exports
without versions as a warning/error by default or update each project
settings in eclipse to make it an error.  Now the question is what version
would all the well established packages use?  Most eclipse packages do not
specify a version which means they have been using the default version of
0.0.0.  If a package is being versioned for the first time what should its
version be?

- Start off using 1.0.0
- Use the Bundle-Version

I favor using the Bundle-Version for well established packages because if
we decide to add versions to the maintenance streams then we have room to
downgrade the versions as appropriate.  Completely new packages in a
release should start off with version 1.0.

I have been trying to version the exports of org.eclipse.osgi for the past
few releases.  It is hard to keep track of without tooling.  Just look at
how many times we forget to increment the bundle versions in Eclipse and
that is just one version number per bundle to maintain.  Now we will have
to maintain each package version individually which is a much bigger task.
Hopefully more advanced API tooling could detect that the API package has
changed since last release and needs to be incremented.  Does the new API
tooling currently do something like this for Bundle-Version?

Tom




 
  From:   Jeff McAffer [EMAIL PROTECTED] 
 
  To: equinox-dev@eclipse.org
 
  Date:   01/11/2008 02:17 PM
 
  Subject:[equinox-dev] Fw: [Bug 214801] [api tools] consider 
Export-Package  as API
 






Tom raises a good point that we keep letting slide.  Are we going to ensure
that all export package statements have version numbers for 3.4?  If we
have API tooling for this then it would likely be reasonable to start
doing.  Even without tooling today, we could introduce version numbers
based on the bundle version number for this release and then evolve from
there (with tooling that will come in the future).

Jeff

- Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM -

 [EMAIL PROTECTED]
 rg

To
 01/11/2008 10:50 AM Jeff McAffer/Ottawa/[EMAIL PROTECTED]
cc

   Subject
 [Bug 214801] [api tools] consider
 Export-Package as API











https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801
Product/Component: PDE / Incubators




--- Comment #2 from Thomas Watson [EMAIL PROTECTED]  2008-01-11
10:50:13 -0400 ---
I agree with the concept.  All exported packages which are not marked
x-internal:=true should be versioned.  Without this it makes using
Import-Package very limiting because you cannot specify what version of the
package you require.  Packages marked as x-friends are questionable, but I
can
see friend bundles depending on a particular friend package version.


--
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the
bug.___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
inline: graycol.gifinline: ecblank.gif___
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] is this a service tracker bug?

[BJ Hargrave]

But you should not have to refresh. That is the whole point of importing 
the package which is exported. So that A' can import it from A which is 
where B imports it from.

I think the IllegalStateException is is a bug in Equinox.
-- 

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:
Mark [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008-01-25 13:06
Subject:
Re: [equinox-dev] is this a service tracker bug?



I see - It's in an IllegalState until you refresh

On 25/01/2008, Mark  [EMAIL PROTECTED] wrote:
Try adding: 

Import-Package: bundlea.service 

to the Bundle A manifest. 

=
I just tried the suggestion above - but it blows up?

Framework is launched.

idState   Bundle
0ACTIVE  org.eclipse.osgi_3.3.1.R33x_v20070828
1ACTIVE  bundleA_1.0.0
2ACTIVE  bundleB_1.0.0

osgi stop 1
removedService

osgi update 1

osgi ss

Framework is launched.

idState   Bundle
0ACTIVE  org.eclipse.osgi_3.3.1.R33x_v20070828
1INSTALLED   bundleA_1.0.0
2ACTIVE  bundleB_1.0.0

osgi start 1
org.osgi.framework.BundleException: Exception in bundlea.Activator.start() 
of bundle bundleA.
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: The state indicates the bundle 
is resolved
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at 
org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
at 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417)
at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
at 
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at bundlea.Activator.start(Activator.java:12)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
... 14 more
Nested Exception:
java.lang.IllegalStateException: The state indicates the bundle is 
resolved
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start

Re: [equinox-dev] is this a service tracker bug?

[BJ Hargrave]

That seems to be a bug in Equinox. You may wish to file a bug report.

For giggles, try update 1 without stopping it first. The update operation 
will automatically stop and restart the updated bundle.

Note: in order for import and exporting the package to work here, the 
exported package in A' must be backwards compatible with the exported 
package in A. This is because the remaining code in A' will be 
implementing/using the interface from A.
-- 

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:
Mark [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008-01-25 12:59
Subject:
Re: [equinox-dev] is this a service tracker bug?



Try adding: 

Import-Package: bundlea.service 

to the Bundle A manifest. 

=
I just tried the suggestion above - but it blows up?

Framework is launched.

idState   Bundle
0ACTIVE  org.eclipse.osgi_3.3.1.R33x_v20070828
1ACTIVE  bundleA_1.0.0
2ACTIVE  bundleB_1.0.0

osgi stop 1
removedService

osgi update 1

osgi ss

Framework is launched.

idState   Bundle
0ACTIVE  org.eclipse.osgi_3.3.1.R33x_v20070828
1INSTALLED   bundleA_1.0.0
2ACTIVE  bundleB_1.0.0

osgi start 1
org.osgi.framework.BundleException: Exception in bundlea.Activator.start() 
of bundle bundleA.
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276)
at 
org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalStateException: The state indicates the bundle 
is resolved
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at 
org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
at 
org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at 
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417)
at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
at 
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
at 
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
at 
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at bundlea.Activator.start(Activator.java:12)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
... 14 more
Nested Exception:
java.lang.IllegalStateException: The state indicates the bundle is 
resolved
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376

Re: [equinox-dev] is this a service tracker bug?

[BJ Hargrave]

Try adding:

Import-Package: bundlea.service

to the Bundle A manifest. 

Then when bundle A is updated to A',
A' will import the package from A which is where bundle B is importing
it. So bundle B can see the service from A' since it implements
the interface from A. (This follows from Tom Watson's explanation.)

See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
-- 



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




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

Re: [equinox-dev] Classpath from another project

[BJ Hargrave]

Try bnd[1] !

[1] http://www.aqute.biz/Code/Bnd
-- 

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:
Emmanuel Potvin [EMAIL PROTECTED]
To:
'Equinox development mailing list' equinox-dev@eclipse.org
Date:
2008-03-28 09:52
Subject:
[equinox-dev] Classpath from another project



I have a plugin project, with the META-INF/MANIFEST.MF, plus another java
project with only classes. I want this second project included in the 
bundle
of the first. Can I? And how?

___
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 regarding class loader and getPackages()

[BJ Hargrave]

[EMAIL PROTECTED] wrote on 2008/06/02 08:58:36 AM:

 [image removed] 
 
 [equinox-dev] Question regarding class loader and getPackages()
 
 Jan Stette 
 
 to:
 
 Equinox development mailing list
 
 2008/06/02 08:59 AM
 
 Sent by:
 
 [EMAIL PROTECTED]
 
 Please respond to Equinox development mailing list 
equinox-dev@eclipse.org
 
 I'm trying to call Package.getPackages() in some code in an OSGi 
 bundle.  This calls into getPackages on the classloader, where I'm 
 observing that:
 
 1.  The call is not overridden in the Equinox classloader, so the 
 default implementation in java.lang.ClassLoader is used.  Hence, 
 only the bundle's own packages, and the system packages are returned.

I don't think imported packages should be listed since they are imported 
from other bundles.

 2.  Only packages from which at least one class has been loaded are 
 returned.  So, if a class hasn't been loaded from a given package, 
 it won't be included in the returned list.
 
 I haven't found anything in the OSGi or Java language specs that 
 specify this, but I expected all packages that the bundle 
 classloader can see to be returned, something aking to the java doc 
 description of Package.getPackages(): Get all the packages 
 currently known for the caller's ClassLoader instance. Those 

The packages currently known are those for which at least one successful 
class load has occurred. There is no reliable or specified way for a class 
loader to know all the classes which it can successfully load.

 packages correspond to classes loaded via or accessible by name to that 
 ClassLoader instance.  Which seems to suggest that both packages of
 classes that haven't been loaded yet, and packages imported by the 
 bundle class loader should be listed.
 
 I realise that the Package Admin service is an alternative for this,
 but I'm surprised if these details can't be accessed through the 
 class loader... 
 
 Could anyone shed some light on this, please?
 
 Regards,
 Jan
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

-- 

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


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

Re: [equinox-dev] Equinox and UTF-8

[BJ Hargrave]

Well you should not be getting bytes from a String. A String is a set of 
Characters. Some characters may fit into bytes, but some are wider.

Also, remember that the length of  a String is the number of characters 
not the number of bytes into which those characters may be encoded.
-- 

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:
Holger Mense [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/07/10 02:37 AM
Subject:
Re: [equinox-dev] Equinox and UTF-8



Hi,

On Wed, 9 Jul 2008 15:45:03 -0400, Oleg Besedin [EMAIL PROTECTED]
wrote:

 To get more consistent results, use String.getBytes(UTF8). The 
 getBytes() method uses default encoding. 

using String.getBytes(UTF-8) does not change the behaviour.

Running the code as a bundle inside Eclipse leads to

=== cut ===
§ length() = 1
§ cast to byte = -89 
§ getBytes() = -62 -89
=== cut ===

while starting it as a bundle in a running Equinox framework outside
Eclipse leads to

=== cut ===
+é-º length() = 2
+é-º cast to byte = -62 -89
+é-º getBytes() = -61 -126 -62 -89
=== cut ===


 I've read that Windows has 
 different default encodings for GUI and console applications. If that is 

 true, it might explain why you see different outputs.

I don't think that this is the reason of the watched behaviour. Executing
the same
code without a running Equinox framework leads to the correct identical
result in- and outside
Eclipse. When running it in an Equinox instance, both results differ. So 
it
looks for me like an
Equinox issue.

Currently I am migrating a bigger application on top of Equinox. The last
days I was working to get
it to start again outside my development environment. That was the time
where a detected the watched
behaviour.

-- 
Holger Mense

___
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 references without an interface

[BJ Hargrave]

That will only work for services registered under the name 
java.lang.Object. I imagine the size of that set is zero.
-- 

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:
Stefan Liebig [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/07/22 12:57 AM
Subject:
Re: [equinox-dev] DS and references without an interface



Have you tried java.lang.Object as type?

Alin Dreghiciu wrote:
 Hi guys,

 Is there any way to specify in Declarative Services a reference
 without a type, just with a filter (target)?
 My use case is that I want all services that have certain service
 properties regardless the type of the service.

 Thanx,
 

___
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] .qualifier for export package?

[BJ Hargrave]

I would be extremely cautious about using qualifier on package versions. I 
must say that I have never seen it done.

It seems an over specification. I think that having build tools to advise 
you to increment the micro is more than sufficient.
-- 

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:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/02 10:45 AM
Subject:
Re: [equinox-dev] .qualifier for export package?



Before recommending every package uses a qualifier I have the following 
concerns:

1) In Eclipse we have loads of packages. We better make sure all identical 
qualifier Strings are shared (interned etc.) for performance reasons. 
Today when loading from a cached state we share identical Version objects. 
Because package versions are managed independently we will end up with 
lots of different versions that have the same qualifier exported by a 
bundle. We also will limit the ability to share Version objects across 
bundles because each will use a different qualifier (unless we happen to 
use the same CVS tag).

2) The qualifier will change even in cases where no code was touched in 
the package. I'm not sure this is a valid concern. The code got recompiled 
so perhaps changing the version qualifier is warranted. But we need to 
think about the consequences. For example, I can see API tooling start to 
complain that the micro version of a package should be increased to 
indicate a bug fix when comparing the package versions with a base line. 
It will notice that the qualifier changed from a previous release but the 
micro version was not increased.

3) What about versions of packages which we do not maintain the API for at 
Eclipse. Things like org.osgi.* and orbit bundles. Shouldn't we use the 
version the producers of the API have defined? Adding a qualifier here 
does not seem right, especially if a qualifier is already defined by the 
producers.

On the surface this sounds like a fine idea, and I am not completely 
against it. But I would like to take the first step of versioning the 
Eclipse API packages first to see what all the issues are with independent 
package versioning. I'm sure we will run into other hurdles along the way. 
For example, how does a developer maintain the version of a split package 
across all the bundles the package is split?

Tom



Chris Aniszczyk ---08/31/2008 02:46:34 PM---On Sun, Aug 31, 2008 at 5:53 
AM, Jeff McAffer  [EMAIL PROTECTED]


From:

Chris Aniszczyk [EMAIL PROTECTED]

To:

Equinox development mailing list equinox-dev@eclipse.org

Date:

08/31/2008 02:46 PM

Subject:

Re: [equinox-dev] .qualifier for export package?



On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] wrote: 
As version numbers on packages become more prevalent does it start making 
sense to use .qualifier on them in addition to bundle version numbers? The 
logic here is the same as for bundles. we rev the version number of the 
bundle to match the most extreme change for that release. in between if 
hte provisioning system is going to do its job, it needs to have different 
version numbers. Teh .qualifier allows for the auto-qualification of 
bundle version numbers. The same is true for folks using import/export 
package.

+1

In PDE, I plan on releasing some builder logic to flag exported packages 
without versions with a warning in M2. API Tooling also has items in plan 
that deal with package versioning, but that will be post M2

Thoughts for how/if this should be introduced?

I say before M2, we formulate a plan across the Eclipse proper projects to 
deal with versions on package exports. We can than look at pushing that 
plan to other Eclipse.org projects as a best practice once we get the hang 
of it.

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

image/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] .qualifier for export package?

[BJ Hargrave]

 Right, but since package versions will now evolve independently of 
bundle 
 versions, should the package name also appear in the @since tag - like 
 @since org.eclipse.jdt.debug.model 3.4. Else, when just looking at the 

 Javadoc, consumers of an API will not know if they need a required 
bundle 
 or a package import.

Wouldn't the package name already be stated by the package statement at 
the head of the source code? It seem redundant and repetitive to put it in 
the @since tag.

I think @since obviously applies to the package. When you javadoc the 
code, bundle membership is absent. Only the package organization remains.
-- 

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


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

Re: [equinox-dev] When is DS done loading services?

[BJ Hargrave]

The whole point of services is that the are dynamic. The fact the DS is 
processing them on behalf of some bundle does not mean that another 
bundle should know or observe that. 

Bundles which depend upon a service need to deal with that service's 
dynamism. You can't assume a bundle's activator or starting a bundle will 
synchronously register some services. I would not support an option for DS 
to synchronously register services during bundle start as this means 
people will improperly use that.

You may also be seeing an impedance mismatch between the lifecycle of 
extensions and services. Extensions become active when the bundle is 
resolved while services become active only when the bundle is started. 
Switching to use extensions will not allow for dynamism (unless you want 
to write all the code to use the extension registry API to do so.)

You may be able to use startlevels to mitigate the issue (make sure all 
bundles providing service B are started before bundles using B), but this 
is also a hack. It would be better if service A dealt with the dynamics of 
service B such that service A has a dynamic dependency on service B and is 
able to accept B's being registered and unregistered at any time.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

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





From:
Stoyan Boshev [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/03 07:51 AM
Subject:
Re: [equinox-dev] When is DS done loading services?



Hi Otto,
I guess your problem is connected to the asynchronous processing of the 
DS services.
As far as I understand the situation is: your application bundles are 
started, then your application is started but at this moment not all of 
the DS services are inited yet because they are being asynchronously 
processed.

Unfortunately currently there is no way to find out when DS completes 
the DS services processing.
I think if there was an option that DS bundle process the DS services in 
the started bundles synchronously, it would solve your problem. So I 
will open bug(enhancement) about that and hopefully this will be 
implemented soon.
As a possible workaround you could observe the running threads and when 
the thread with name Component Resolve Thread disappears this would 
mean that DS bundle has no more work to do and eventually all of your DS 
services are processed. I realize this is not a clean solution (that's 
why I call it workaround) but at this moment I cannot find out a more 
appropriate working solution without modifications in the DS bundle.

Stoyan


Cortez, Otto wrote:
 I made a post to the Eclipse newcomers group a few weeks ago, but did 
 not get a response.  I don’t know if this is the appropriate place for 
 this question, but hopefully someone can point me in the right 
direction.
 
 
 
 We are building a headless RCP application and we would like to use DS 
 to make functionality available.  The problem we are running into is 
 that not all of the services we declared through DS get loaded and are 
 visible before our application executes.
 
 
 
 For example, I have a service A which needs 0..n instances of another 
 service B. The issue I'm running into is that if the implementations of 
 service B are spread across several bundles, then the service A will not 

 have seen all instances of service B when it is called since the 
 application starts (and sometimes ends) running before DS is done 
 looking through all the bundles and registering all the services in the 
 active bundles.
 
 Is there a way to know when declarative services is done looking through 

 the active bundles and loading the services found in them?  Am I missing 

 something?
 
 
 
 It seems that using the plug-in registry may solve this issue.  Is that 
 perhaps a better way to go?
 
 
 
 Thanks,
 Otto
 
 This email and any files transmitted with it are confidential, 
proprietary
 and intended solely for the individual or entity to whom they are 
addressed.
 If you have received this email in error please delete it immediately.
 
 
 
 
 
 
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev

-- 
-
dipl. eng. Stoyan Boshev . Department manager
ProSyst Labs EOOD
1606 Sofia, Bulgaria . 48 Vladajska Str.
Tel. +359 2 953 05 88; Fax +359 2 953 26 17
Mobile: +359 88 898 29 17
http://www.prosyst.com . [EMAIL PROTECTED]
-
stay in touch with your product
-
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] .qualifier for export package?

[BJ Hargrave]

If you change API during dev cycle, that is the proper time to also change 
the major or minor version.  That is the whole point. I would assume that 
API tooling will complain until you do so. Just changing the qualifier is 
insufficient to capture an API change. Also, I think that last thing we 
want to see are bundles using qualifiers in import package statements! So 
if you use qualifier to denote API change during dev, then other bundles 
will need to import using qualifiers to ensure they wire to the desire API 
if they use it. UGLY!

Qualifiers are useful to capture implementation changes. But API is a 
specified thing that changes deliberately and (hopefully) slowly and its 
version is not subject to implementation. 
-- 

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:
Jeff McAffer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/03 06:16 AM
Subject:
Re: [equinox-dev] .qualifier for export package?



I understand your hestiation and actually agree with you from the 
released code point of view.  However, we spend a lot of time dealing 
with code and API that is in development.  If we are to have any hope of 
provisioning and managing that, we need to know the difference between the 
various iterations of the packages.  For example, when someone adds an API 
during the dev cycle and you want use it, you need to import the right 
version of the package to ensure you get it.  Changing the first three 
segments version number of the package for every change done in the dev 
cycle feels too disruptive.

To a certain extent this could be handled in the provisioning system but 
that would force the situation of bundles in a particular context (e.g., a 
build lineup).  That is, bundles would no longer be 
completely/accurately self-describing.

Jeff

BJ Hargrave wrote: 

I would be extremely cautious about using qualifier on package versions. I 
must say that I have never seen it done. 

It seems an over specification. I think that having build tools to advise 
you to increment the micro is more than sufficient. 
-- 

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: 
Thomas Watson/Austin/[EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
2008/09/02 10:45 AM 
Subject: 
Re: [equinox-dev] .qualifier for export package?




Before recommending every package uses a qualifier I have the following 
concerns:

1) In Eclipse we have loads of packages. We better make sure all identical 
qualifier Strings are shared (interned etc.) for performance reasons. 
Today when loading from a cached state we share identical Version objects. 
Because package versions are managed independently we will end up with 
lots of different versions that have the same qualifier exported by a 
bundle. We also will limit the ability to share Version objects across 
bundles because each will use a different qualifier (unless we happen to 
use the same CVS tag).

2) The qualifier will change even in cases where no code was touched in 
the package. I'm not sure this is a valid concern. The code got recompiled 
so perhaps changing the version qualifier is warranted. But we need to 
think about the consequences. For example, I can see API tooling start to 
complain that the micro version of a package should be increased to 
indicate a bug fix when comparing the package versions with a base line. 
It will notice that the qualifier changed from a previous release but the 
micro version was not increased.

3) What about versions of packages which we do not maintain the API for at 
Eclipse. Things like org.osgi.* and orbit bundles. Shouldn't we use the 
version the producers of the API have defined? Adding a qualifier here 
does not seem right, especially if a qualifier is already defined by the 
producers.

On the surface this sounds like a fine idea, and I am not completely 
against it. But I would like to take the first step of versioning the 
Eclipse API packages first to see what all the issues are with independent 
package versioning. I'm sure we will run into other hurdles along the way. 
For example, how does a developer maintain the version of a split package 
across all the bundles the package is split?

Tom



Chris Aniszczyk ---08/31/2008 02:46:34 PM---On Sun, Aug 31, 2008 at 5:53 
AM, Jeff McAffer  [EMAIL PROTECTED]

From: 

Chris Aniszczyk [EMAIL PROTECTED] 

To: 

Equinox development mailing list equinox-dev@eclipse.org 

Date: 

08/31/2008 02:46 PM 

Subject: 

Re: [equinox-dev] .qualifier for export package?




On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] wrote: 
As version numbers on packages become more prevalent does it start making 
sense to use .qualifier on them in addition to bundle version

RE: [equinox-dev] When is DS done loading services?

[BJ Hargrave]

But even DS only knows about started bundles. If a bundle is started after 
DS has processed some bundle, then new services can be registered. There 
is no way for DS to know about all possible services being ready since 
some may come from bundles yet to be started. The best DS could tell you 
is that it is done processing services from bundles that are currently 
started.

It is far better in the long run for the application to handle dynamism. 
Anything you do today to try and enforce some ordering will likely fail in 
the future when some thing changes about the set of installed bundles.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

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





From:
Cortez, Otto [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/03 02:48 PM
Subject:
RE: [equinox-dev] When is DS done loading services?



It is more important for us to know what functionality is installed and 
available before parts of the application execute then it is for us to 
support dynamism.  I would like to keep the dynamism if we can, but to do 
that and provide reliable execution I think the application would need to 
guarantee that all services known through the bundle manifests will be 
initialized before we start processing.  I guess using extensions might be 
a better fit.
 
I’m not sure if we need DS to synchronously register services as much as 
some way to listen to DS events or know its state, like is it just sitting 
around waiting for more bundles to be activated or deactivated.  I was 
focused on services being managed by DS since I thought DS would know 
weather it was done initializing all services listed in the active 
bundles’ manifest files and then we would be able to say to users which 
may supply functionality, well if you use DS then we could guarantee that 
we wouldn’t start until DS had initialized your services.
 
Thanks,
Otto
 

From: [EMAIL PROTECTED] [
mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave
Sent: Wednesday, September 03, 2008 7:22 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] When is DS done loading services?
 

The whole point of services is that the are dynamic. The fact the DS is 
processing them on behalf of some bundle does not mean that another 
bundle should know or observe that. 

Bundles which depend upon a service need to deal with that service's 
dynamism. You can't assume a bundle's activator or starting a bundle will 
synchronously register some services. I would not support an option for DS 
to synchronously register services during bundle start as this means 
people will improperly use that. 

You may also be seeing an impedance mismatch between the lifecycle of 
extensions and services. Extensions become active when the bundle is 
resolved while services become active only when the bundle is started. 
Switching to use extensions will not allow for dynamism (unless you want 
to write all the code to use the extension registry API to do so.) 

You may be able to use startlevels to mitigate the issue (make sure all 
bundles providing service B are started before bundles using B), but this 
is also a hack. It would be better if service A dealt with the dynamics of 
service B such that service A has a dynamic dependency on service B and is 
able to accept B's being registered and unregistered at any time. 
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED] 

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





From: 
Stoyan Boshev [EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
2008/09/03 07:51 AM 
Subject: 
Re: [equinox-dev] When is DS done loading services?
 




Hi Otto,
I guess your problem is connected to the asynchronous processing of the 
DS services.
As far as I understand the situation is: your application bundles are 
started, then your application is started but at this moment not all of 
the DS services are inited yet because they are being asynchronously 
processed.

Unfortunately currently there is no way to find out when DS completes 
the DS services processing.
I think if there was an option that DS bundle process the DS services in 
the started bundles synchronously, it would solve your problem. So I 
will open bug(enhancement) about that and hopefully this will be 
implemented soon.
As a possible workaround you could observe the running threads and when 
the thread with name Component Resolve Thread disappears this would 
mean that DS bundle has no more work to do and eventually all of your DS 
services are processed. I realize this is not a clean solution (that's 
why I call it workaround) but at this moment I cannot find out a more 
appropriate working solution without modifications in the DS bundle.

Stoyan


Cortez, Otto wrote:
 I made a post to the Eclipse newcomers group a few weeks ago, but did 
 not get

Re: [equinox-dev] When is DS done loading services?

[BJ Hargrave]

 As to the question of DS, let's not forget that it is just an 
 instrument. From what I understand, its goal is to help developers 
 work around OSGi complexities. If it does not help, it needs to be 
fixed. 

I am all for fixing DS if it is flawed. But your argument against using 
startlevel can be applied to anything which attempts to fix some ordering. 
The difficult point is that bundles can be interdependent. They and 
services are dynamic. You can attempt to hide the dynamism through the use 
of static policies in DS but that only goes so far. Using DS, one can 
fairly easily deal with service dynamism. There are bind/unbind methods 
which are called when services come and go so the bundle can be notified 
of changes to the set of services.

I feel that changing DS to perform service registration synchronous with 
bundle activation will likely result in deadlocks when there are complex 
service dependency graphs. 

One possible way to deal with this is through the use of component 
enablement. Using the original example of service A depending upon some 
number of service B, if you can know when all the service Bs are 
available, one can write a component with a dynamic dependency on B. When 
all the Bs are available then enable the component providing service A 
(which are declared disabled in its description). The trick is of course 
to be able to know when all the service Bs are available such that we are 
ready to enable serviceA.


-- 

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] When is DS done loading services?

[BJ Hargrave]

  I feel that changing DS to perform service registration synchronous 
with
  bundle activation will likely result in deadlocks when there are 
complex
  service dependency graphs.
 
 This won't be any different from what is done now manually. The
 potential for deadlocks are there regardless of DS.
 

Perhaps, but at least we are not building it into the DS spec or the DS 
impl!

  
  One possible way to deal with this is through the use of component
  enablement. Using the original example of service A depending upon 
some
  number of service B, if you can know when all the service Bs are
  available, one can write a component with a dynamic dependency on B.
  When all the Bs are available then enable the component providing
  service A (which are declared disabled in its description). The trick 
is
  of course to be able to know when all the service Bs are available 
such
  that we are ready to enable serviceA.
 
 And we are back to the core problem: we cannot be sure when all service
 Bs are available.

How can you ever be sure? :-) Unless there is some definition of the 
expected set of Bs, it is just random.

 In code which doesn't use DS, start() method will
 serve as a boundary for the service changes - satisfied services will be
 registered while the bundle is starting and any services which becomes
 satisfied will be registered synchronously (the latter is the current
 behavior of DS).

This makes the assumption that bundle will always register their B during 
BundleActivator execution. I think this is a fairly tall assumption. What 
if a bundle's B depends upon something which is not yet available? It is 
very bad form to block the BundleActivator. So such a bundle, if well 
behaved, would have to return from the BundleActivator w/o having 
registered B and delay registering B until the dependency is met some time 
later.

  After all the bundles are activated, we can be sure
 that all services which doesn't depend on external factors will be
 available and the system can be considered ready.
 

You assume (all services which doesn't depend on external factors) that 
all B's have no dependencies and can be registered at will. That is a 
pretty big assumption.

Perhaps one thing a DS impl could do, is to register all services for 
which all dependencies are currently met synchronously during bundle 
activation. All other services would have to handled asynchronously. This 
splits the DS work between work that can be quickly done during bundle 
activation and work that will take time which is done after bundle 
activation. I don't think any change to the DS spec is needed to allow 
this behavior.

-- 

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] When is DS done loading services?

[BJ Hargrave]

 I totally agree. This is what I actually wanted in the very beginning of 

 this thread.

OK, but I certainly did not understand that at the beginning :-)

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] .qualifier for export package?

[BJ Hargrave]

Mix-and-matching bundles from different builds during a dev cycle seems a 
recipe for problems. If p2 will pick the bundle with the highest bundle 
version (including the qualifier with the builddate) and the p2 repo is 
always properly provisioned with the latest build output, then there 
should be no problem as every will use the latest build for all bundles.
-- 

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:
David M Williams/Raleigh/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/05 10:18 AM
Subject:
Re: [equinox-dev] .qualifier for export package?




 Without some sort of increasing version number on the packages, p2 
 for example, will have a hard time figuring out what to give you 
 cause everything will look the same to it.
 Can anyone think of another way of enabling #2? 

Wouldn't p2 _have_ to always pick a bundle with the highest qualifier 
(thereby getting the highest level of any packages in that bundle)? 
If not, then this API use case would only be a special case of a general 
problem of using old implementations. 
Perhaps I'm missing the point? 




From: 
Jeff McAffer [EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
09/05/2008 04:32 AM 
Subject: 
Re: [equinox-dev] .qualifier for export package?




I'm certainly sympathetic to you thinking here.  Having qualifiers in 
import statements is ugly at best.  The challenge is that in the dev cycle 
the API of something may change many many times.  This would lead to quite 
visible changes in unreasonable ways.  For example, say we introduce some 
API and then break it several times as we refine in the dev cycle.  Then 
the first release of the API might have version 42.23.27 or some such. 
Trying to manage API semantics during the dev/release cycle seems like 
overkill.  Clearly that is an over done example but you get the point I 
hope.

Lets step back for a second.  Some goals in decreasing order of 
priority/importance.

Goal #1: ensure that at least all API packages have version numbers on the 
exports.
Goal #2: be able to eat our own dog food wrt provisioning and version 
management during the dev cycle.

Good news is that #1 is likely agreed to and *all* we have to do is put 
the initial version numbers on the current packages and then have the 
tooling help people manage them according to the current versioning model.

The proposal for using .qualifier was actually one possible implementation 
of goal #2.  #2 is interesting because eating our own dog food seems to 
greatly increase the likelihood of our technology being good/useful. 
Without some sort of increasing version number on the packages, p2 for 
example, will have a hard time figuring out what to give you cause 
everything will look the same to it.
Can anyone think of another way of enabling #2?  Of the top of my head I'm 
thinking that something like the odd/even version pattern might help...

Jeff
BJ Hargrave wrote: 

If you change API during dev cycle, that is the proper time to also change 
the major or minor version.  That is the whole point. I would assume that 
API tooling will complain until you do so. Just changing the qualifier is 
insufficient to capture an API change. Also, I think that last thing we 
want to see are bundles using qualifiers in import package statements! So 
if you use qualifier to denote API change during dev, then other bundles 
will need to import using qualifiers to ensure they wire to the desire API 
if they use it. UGLY! 

Qualifiers are useful to capture implementation changes. But API is a 
specified thing that changes deliberately and (hopefully) slowly and its 
version is not subject to implementation. 
-- 

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: 
Jeff McAffer [EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
2008/09/03 06:16 AM 
Subject: 
Re: [equinox-dev] .qualifier for export package?




I understand your hestiation and actually agree with you from the 
released code point of view.  However, we spend a lot of time dealing 
with code and API that is in development.  If we are to have any hope of 
provisioning and managing that, we need to know the difference between the 
various iterations of the packages.  For example, when someone adds an API 
during the dev cycle and you want use it, you need to import the right 
version of the package to ensure you get it.  Changing the first three 
segments version number of the package for every change done in the dev 
cycle feels too disruptive.

To a certain extent this could be handled in the provisioning system but 
that would force the situation of bundles in a particular context (e.g., a 
build lineup).  That is, bundles would

Re: [equinox-dev] .qualifier for export package?

[BJ Hargrave]

But the qualifier is just another component of the version to allow 
ordering among versions. Why is change it any different than changing any 
other component of the version? (Other than semantic we place on the 
version components.)

Changing any part of the version during development is only interesting if 
someone will change their import to depend upon that higher version. And 
if someone becomes dependent upon that new version, then making backwards 
incompatible API changes during development is in trouble. Backing out API 
changes made during dev does not mean you can simply revert the version 
number since there may have been changes in other areas of the package 
which are not affected by the back out. 

Original: 1.2
Make change A: 1.2.0.qual1
Make change B: 1.2.0.qual2
Backout change A: 1.2.0.qual1 is not right since change B is still there.

-- 

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:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/05 10:11 AM
Subject:
Re: [equinox-dev] .qualifier for export package?



If we decided to back out an API then we revert the version back and have 
to make the necessary announcements to the community to prepare them for 
the version decrease in mid development cycle. From release to release our 
version have to follow our version rules at 
http://wiki.eclipse.org/index.php/Version_Numbering

I do not think we should change the minor number each time API is added 
for each I-Build or milestone. That should only be done once each release. 
What Jeff would like is the ability to pick a particular build of a 
package from a development. If this is important then the qualifier 
approach is likely the most simple approach. Another approach could be to 
have exporters add a matching attribute that indicates new API. But this 
does not scale well. For example:

Export-Package: foo; version=2.1; bar=true

This would be used when some new bar feature was added to the foo package, 
then

Export-Package: foo; version=2.1; bar=true; baz=true

This would be used when both the bar and baz features are added to the foo 
package. This is possible but is hard to manage and is just ugly. Is this 
a serious enough issue that we must address it? It seems like it is just a 
temporary issue that goes away once the final release is done.

Tom



BJ Hargrave---09/05/2008 07:50:25 AM---If I understand #2 correctly, then 
you want a controlled version practice during the development cycle. This 
is challenging sin


From:

BJ Hargrave/Austin/[EMAIL PROTECTED]

To:

Equinox development mailing list equinox-dev@eclipse.org

Date:

09/05/2008 07:50 AM

Subject:

Re: [equinox-dev] .qualifier for export package?




If I understand #2 correctly, then you want a controlled version practice 
during the development cycle. This is challenging since you may want to 
change your mind and break from a previous API change made during the same 
dev cycle. 

For example: 

1.2 is the last shipped version of a package (let's say thats in 
Ganymede). 

So during the dev cycle you change to 1.3 because you add new API. Soon 
you add more API. 1.3.1 or 1.4? Then you decide to pull some of those API 
changes because we learned they did not work as expected. What version 
then? 2.0? Because of the breaking change? I think this is a fairly 
impossible situation during the dev cycle because we are free to change 
our mind about new API until API freeze. 

I think the odd/even versioning could be useful. But it still does not 
easily handle the removal of new API previously added during the dev 
cycle. It only seems to work well if the API only grows but does not 
shrink. 

-- 

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: 
Jeff McAffer [EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
2008/09/05 04:32 AM 
Subject: 
Re: [equinox-dev] .qualifier for export package?




I'm certainly sympathetic to you thinking here. Having qualifiers in 
import statements is ugly at best. The challenge is that in the dev cycle 
the API of something may change many many times. This would lead to quite 
visible changes in unreasonable ways. For example, say we introduce some 
API and then break it several times as we refine in the dev cycle. Then 
the first release of the API might have version 42.23.27 or some such. 
Trying to manage API semantics during the dev/release cycle seems like 
overkill. Clearly that is an over done example but you get the point I 
hope.

Lets step back for a second. Some goals in decreasing order of 
priority/importance.

Goal #1: ensure that at least all API packages have version numbers on the 
exports.
Goal #2: be able to eat our own dog food wrt

Re: [equinox-dev] .qualifier for export package?

[BJ Hargrave]

If the new API is completely pull such that the API is again the same as 
the last released version then yes, revert to 1.0. But as long as the API 
is different than the last released version, it should remain 1.1. Putting 
a qualifier of a build date or tag on the package export is wrong. It will 
lead one to believe that importing that package with a qualifier is ok and 
meaningful. But a qualifier of a build date or tag says nothing about API 
backwards compatibility. It is just a form of identity with no meaningful 
ordering.
-- 

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:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/05 12:03 PM
Subject:
Re: [equinox-dev] .qualifier for export package?



Anyone adopting early API (before API freeze) has to be prepared for 
breaking changes. We must have the flexibility to develop our new API and 
increment our versions properly from one final release to the next. 
Imagine the following scenario

foo; version=1.0

The M1 build adds new backwards compatibility API to foo and the version 
becomes:

foo; version=1.1

In the M2 build it is decided that the new API is bad and is pulled out, 
now what do you think foo version should be? back to 1.0 or 1.2 or 2.0? 
removing the API technically is a backwards compatibility change so 
technically the version should become 2.0 when compared to the version of 
foo from the M1 build. I think we must evolve our API versions from the 
last release, not from build to build. In this case the foo package 
contains the exact API as the 1.0 version, making it anything other than 
1.0 is wrong and confusing.

Adding a qualifier will allow clients to depend on a particular version of 
the package from a particular build (or CVS tag) if they really need to. 
But I do not think this is the common case and we should not recommend as 
a best practice to include qualifiers in version ranges used in 
Import-Package or Require-Bundle.

Tom



BJ Hargrave---09/05/2008 09:40:56 AM---But the qualifier is just another 
component of the version to allow ordering among versions. Why is change 
it any different tha


From:

BJ Hargrave/Austin/[EMAIL PROTECTED]

To:

Equinox development mailing list equinox-dev@eclipse.org

Date:

09/05/2008 09:40 AM

Subject:

Re: [equinox-dev] .qualifier for export package?




But the qualifier is just another component of the version to allow 
ordering among versions. Why is change it any different than changing any 
other component of the version? (Other than semantic we place on the 
version components.) 

Changing any part of the version during development is only interesting if 
someone will change their import to depend upon that higher version. And 
if someone becomes dependent upon that new version, then making backwards 
incompatible API changes during development is in trouble. Backing out API 
changes made during dev does not mean you can simply revert the version 
number since there may have been changes in other areas of the package 
which are not affected by the back out. 

Original: 1.2 
Make change A: 1.2.0.qual1 
Make change B: 1.2.0.qual2 
Backout change A: 1.2.0.qual1 is not right since change B is still there. 

-- 

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: 
Thomas Watson/Austin/[EMAIL PROTECTED] 
To: 
Equinox development mailing list equinox-dev@eclipse.org 
Date: 
2008/09/05 10:11 AM 
Subject: 
Re: [equinox-dev] .qualifier for export package?




If we decided to back out an API then we revert the version back and have 
to make the necessary announcements to the community to prepare them for 
the version decrease in mid development cycle. From release to release our 
version have to follow our version rules at 
http://wiki.eclipse.org/index.php/Version_Numbering

I do not think we should change the minor number each time API is added 
for each I-Build or milestone. That should only be done once each release. 
What Jeff would like is the ability to pick a particular build of a 
package from a development. If this is important then the qualifier 
approach is likely the most simple approach. Another approach could be to 
have exporters add a matching attribute that indicates new API. But this 
does not scale well. For example:

Export-Package: foo; version=2.1; bar=true

This would be used when some new bar feature was added to the foo package, 
then

Export-Package: foo; version=2.1; bar=true; baz=true

This would be used when both the bar and baz features are added to the foo 
package. This is possible but is hard to manage and is just ugly. Is this 
a serious enough issue that we must address it? It seems like it is just a 
temporary issue that goes away once the final release

Re: [equinox-dev] service elements in Declaratice Services

[BJ Hargrave]

Looks like a bug to me. Open a bug here: 
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox

Select the Compendium component and start the summary with [ds].

The schema for the XML only permits a single service element. DS should 
reject the XML as invalid thus ignoring the component description. 
-- 

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:
Toedter, Kai [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/10/28 09:14 AM
Subject:
[equinox-dev] service elements in Declaratice Services



Hi All,

I currently prototype a little Equinox app that uses Declarative Services 
(DS). The DS spec 4.1 says The service element is optional. ... The 
service element must have one or more provide elements that define the 
service interfaces. So, the following XML is syntactically correct and 
handled well by Equinox DS:

component name=com.siemens.ct.pm.ui.views.treeView
implementation
class=com.siemens.ct.pm.ui.views.treeview.TreeView/
service
provide
 interface=com.siemens.ct.pm.application.service.IViewContribution/
provide
interface=com.siemens.ct.pm.model.IPersonListener/
/service
/component

However, the following XML is incorrect with regards to the DS spec...

component name=com.siemens.ct.pm.ui.views.treeView
implementation
class=com.siemens.ct.pm.ui.views.treeview.TreeView/
service
provide
 interface=com.siemens.ct.pm.application.service.IViewContribution/
/service
service
provide
interface=com.siemens.ct.pm.model.IPersonListener/
/service
/component

... but Equinox handles it exactly like the above correct XML :)

Now the question is, is this a bug or a feature?
If it is a bug, I can file it...
...but how should Equinox DS react then?

Best regards,

Kai
---


Kai Tödter

Siemens AG
Corporate Technology
Architecture
CT SE 2
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 89 636-41064
Fax: +49 89 636-45450
mailto: [EMAIL PROTECTED]
Internet: www.siemens.com/corporate-technology

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard 
Cromme; Managing Board: Peter Loescher, Chairman, President and Chief 
Executive Officer; Heinrich Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo 
Montes, Juergen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. 
Sharef, Peter Y. Solmssen, Klaus Wucherer; Registered offices: Berlin and 
Munich; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, 
HRB 6684; WEEE-Reg.-No. DE 23691322



___
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] Conceptual problem with OSGi

[BJ Hargrave]

It would be better to ask this question on the [EMAIL PROTECTED] list 
since it is a general OSGi question and not tied to Equinox's 
implementation.
-- 

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:
Alexander Shutyaev [EMAIL PROTECTED]
To:
equinox-dev@eclipse.org
Date:
2008/10/30 07:46 AM
Subject:
[equinox-dev] Conceptual problem with OSGi



I have come upon a conceptual problem with OSGi.

First, I'll tell what I need. I need a factory that will create some 
instances. Each instance has it's own configuration and all instances 
provide a service.

I've read about the EMailFetcher example in the Configuration Admin 
Specification and it turned out to be just my case. So I was happy and 
thought that I should use ManagedServiceFactory and all the things 
associated with it.

Later, however I've read the Declarative Services Specification. And that 
is where it began. I can't feel the difference between the 
ManagedServiceFactory (from Configuration Admin) and ComponentFactory 
(from Declarative Services).

If anyone could tell me the difference between them (for example why can't 
I use ComponentFactory in the EMailFetcher example, or can I?), I would be 
very-very thankful.

Thanks 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] 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 equinox-dev@eclipse.org
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

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 equinox-dev@eclipse.org
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 equinox-dev@eclipse.org
 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] 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 kai.toed...@siemens.com
To:
Equinox development mailing list equinox-dev@eclipse.org, General 
development mailing list of the Eclipse project. 
eclipse-...@eclipse.org
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] 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:
岡野　真一 okano-shini...@sei.co.jp
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] 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 dco...@citic.es
To:
equinox-dev@eclipse.org
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] 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 hal.hildebr...@oracle.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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
 sameera.madus...@gmail.com wrote:
 Hi  Kai,

 On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com 
 
 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 blued...@gmail.com 
 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 sameera.madus...@gmail.com:

 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.

 components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
 scr:component enabled=true name=carbon.core.dscomponent
 implementation
 class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
 property name=service.pid 
 value=carbon.core.dscomponent/
 reference name=registry.service
 interface=org.wso2.carbon.registry.core.service.RegistryService
 cardinality=1..1 policy=dynamic bind=setRegistryService
 unbind=unsetRegistryService/
 /scr:component
 /components

 Here is the component implementation class.

 public class CarbonCoreDSComponent{

 private static Log log =
 LogFactory.getLog(CarbonCoreDSComponent.class);
 private BundleContext bundleContext;

 protected void activate(ComponentContext ctxt) {
 log.info(*** Carbon Core bundle is activated *** 
 );
 }

 protected void deactivate(ComponentContext ctxt) {
 log.info(*** Carbon Core bundle is deactivated 
 *** );
 }

 protected void setRegistryService(RegistryService 
 registryService) {
 System.out.println(Set Registry 
 Service);
 }

 protected void unsetRegistryService(RegistryService 
 registryService)
 {
 System.out.println(Unset Registry
 Service);
 }
 }

 When I stop the bundle which registers the
 org.wso2.carbon.registry.core.service.RegistryService, 
 following out
 put
 is generated.

 *** Carbon Core bundle

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 andy.wilkin...@springsource.com
To:
equinox-dev@eclipse.org
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] 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 dco...@citic.es
To:
'Equinox development mailing list' equinox-dev@eclipse.org
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 dco...@citic.es

To:

equinox-dev@eclipse.org

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 permissions
return null; // nothing to return
}
});

If I try to get the Service from another

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 patrik.jans...@saabgroup.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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 patrik.jans...@saabgroup.com 
To: 
equinox-dev@eclipse.org 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] 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 and...@teirney.net
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_Projectview=diffr1=1.8r2=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] 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 and...@teirney.net
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] 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' equinox-dev@eclipse.org
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] 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: equinox-dev@eclipse.org
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] 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 john_artho...@ca.ibm.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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 equinox-dev@eclipse.org


To
Equinox development mailing list equinox-dev@eclipse.org 
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

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 a...@naddaf.org
To:
Equinox development mailing list equinox-dev@eclipse.org
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 anyAttribute/ 
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] 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 john_artho...@ca.ibm.com
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] 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 s.bos...@prosyst.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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 john_artho...@ca.ibm.com
 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

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 ian.skerr...@eclipse.org
To:
equinox-dev@eclipse.org, 'Runtime Project PMC mailing list' 
rt-...@eclipse.org
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] 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 prof.tar...@gmail.com
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] 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 tdiek...@tibco.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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.
 -- Fortune Cookie

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 njbartl...@gmail.com
To:
Equinox development mailing list equinox-dev@eclipse.org
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,  daniel.stu...@empolis.com 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: 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:
daniel.stu...@empolis.com
To:
equinox-dev@eclipse.org
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 tdiek...@tibco.com 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,  daniel.stu...@empolis.com 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

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 l...@toolazydogs.com
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] 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 j...@eclipsesource.com
To: Equinox development mailing list equinox-dev@eclipse.org
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



graycol.gifKirchev, 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

ecblank.gif
From:
ecblank.gif
Kirchev, Lazar l.kirc...@sap.com
ecblank.gif
To:
ecblank.gif
Equinox development mailing list equinox-dev@eclipse.org
ecblank.gif
Date:
ecblank.gif
12/02/2010 10:52 AM
ecblank.gif
Subject:
ecblank.gif
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



graycol.gifJeff 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 j...@eclipsesource.com
34743407.jpg
To:
34519726.jpg
Equinox development mailing list equinox-dev@eclipse.org
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

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 gun...@wagenknecht.org
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] 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 equinox-dev@eclipse.org
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 equinox-dev@eclipse.org
From: Neil Bartlett njbartl...@gmail.com
Sent by: equinox-dev-boun...@eclipse.org
Date: 02/22/2011 10:46AM
Cc: Equinox development mailing list equinox-dev@eclipse.org
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 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
hargr...@us.ibm.com 

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






From:Gunnar Wagenknecht gun...@wagenknecht.org
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]

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 njbartl...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
Cc: Richard S. Hall he...@ungoverned.org
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 he...@ungoverned.org 
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 equinox-dev@eclipse.org
 From: Neil Bartlett njbartl...@gmail.com
 Sent by: equinox-dev-boun...@eclipse.org
 Date: 02/22/2011 10:46AM
 Cc: Equinox development mailing list equinox-dev@eclipse.org
 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 hargr...@us.ibm.com
 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 gun...@wagenknecht.org
 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,

 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 mailto:gun...@wagenknecht.org
 http://wagenknecht.org/

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

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

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



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

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 katya.todor...@sap.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 katya.todor...@sap.com 
Sent by: equinox-dev-boun...@eclipse.org
06/24/2011 08:27 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org


To
Equinox development mailing list equinox-dev@eclipse.org
cc

Subject
[equinox-dev] 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

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 b.kapukara...@gmail.com
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] 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:   stanley_p...@dell.com
To: equinox-dev@eclipse.org, 
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

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 he...@ungoverned.org
To: Equinox development mailing list equinox-dev@eclipse.org, 
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 equinox-dev@eclipse.org, 

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:stanley_p...@dell.com 
To:equinox-dev@eclipse.org, 
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


image/gifimage/pngimage/pngimage/pngimage/pngimage/pngimage/pngimage/pngimage/png___
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 pas...@rapicault.net
To: Equinox development mailing list equinox-dev@eclipse.org, 
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] 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 sle...@composent.com
To: Equinox development mailing list equinox-dev@eclipse.org, 
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 pas...@rapicault.net 
To:Equinox development mailing list equinox-dev@eclipse.org, 
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org, 
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=1file=/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] 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 ljeli...@virtage.com
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] 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] 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 mike.milinkov...@eclipse.org
To: equinox-dev@eclipse.org, 'Runtime Project PMC mailing list' 
rt-...@eclipse.org, 
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] 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 matteo.ru...@abodata.com
To: equinox-dev@eclipse.org, 
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 AtomicReferenceMyService _serv = new 
AtomicReferenceMyService();
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org 
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]

 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]

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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 raymond.a...@liferay.com 
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 hargr...@us.ibm.com 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] Class visibility without declared dependency

[BJ Hargrave]

 From: Stephan Herrmann stephan.herrm...@berlin.de
 
  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] 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 cvgav...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 cvgav...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 hargr...@us.ibm.com
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 cvgav...@gmail.com 
To:Equinox development mailing list equinox-dev@eclipse.org 
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] [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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 tom.schi...@bestsolution.at
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 tjwat...@us.ibm.com 
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 equinox-dev@eclipse.org, 
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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org 
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

image/gif___
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 cvgav...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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, ServiceRegistrationHttpService 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] 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 andreas.s...@codetrails.com
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 govel...@gmail.com 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] 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();
...
EnumerationURL 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 govel...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
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();
...
EnumerationURL 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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org 
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 govel...@gmail.com 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] 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 cvgav...@gmail.com
To: Equinox development mailing list equinox-dev@eclipse.org
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org, Apache 
Felix Developers d...@felix.apache.org
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] 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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org, Apache 
Felix Developers d...@felix.apache.org
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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org, 
Apache Felix Developers d...@felix.apache.org 
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]

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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org, 
Apache Felix Developers d...@felix.apache.org 
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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org, 
Apache Felix Developers d...@felix.apache.org 
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]

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 raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
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 hargr...@us.ibm.com 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 raymond.a...@liferay.com 
To:Equinox development mailing list equinox-dev@eclipse.org, 
Apache Felix Developers d...@felix.apache.org 
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 hargr...@us.ibm.com 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

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 equinox-dev@eclipse.org
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.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303

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 raymond.a...@liferay.com
To: Apache Felix Developers d...@felix.apache.org
Cc: Equinox development mailing list equinox-dev@eclipse.org
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 latest-equinox 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 raymond.a...@liferay.com 
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. jamie.goody...@gmail.com 
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 raymond.a...@liferay.com 
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 raymond.a...@liferay.com
 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 raymond.a...@liferay.com

 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 hargr...@us.ibm.com
 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* hargr...@us.ibm.com

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





 From:Raymond Auge raymond.a...@liferay.com
 To:Equinox development mailing list equinox-dev@eclipse.org
,
 Apache Felix Developers d...@felix.apache.org
 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
 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é* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com (@Liferay)




 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com (@Liferay)




 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http

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 equinox-dev@eclipse.org
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 cvgav...@gmail.com 
To:Equinox equinox-dev@eclipse.org 
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 cvgav...@gmail.com: 
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] Exporting packages without a version

[BJ Hargrave]

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

 From: Dennis Hübner dennis.hueb...@itemis.de
 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 
 com.google.guava_15.0.0.v201403281430 [4]
 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.google.guava_15.0.0.v201403281430 [4]
 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 
 com.google.guava_15.0.0.v201403281430 [4]
 ...
 org.eclipse.xtext.xbase.lib; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.8.0.v20141037 [626]
 org.eclipse.xtext.xbase.lib; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]
 org.eclipse.xtext.xbase.lib.internal; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.8.0.v20141037 [626]
 org.eclipse.xtext.xbase.lib.internal; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]
 org.eclipse.xtext.xbase.lib.util; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.8.0.v20141037 [626]
 org.eclipse.xtext.xbase.lib.util; version=0.0.0 
 org.eclipse.xtext.xbase.lib_2.7.3.v201411190455 [584]
   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

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

[BJ Hargrave]

 From: Stephan Herrmann stephan.herrm...@berlin.de

 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] dependency on org.osgi.annotation?

[BJ Hargrave]

 From: Stephan Herrmann stephan.herrm...@berlin.de

 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 markus_kel...@ch.ibm.com

 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 stephan.herrm...@berlin.de

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