Re: Re[2]: [equinox-dev] Prosyst contributions

[BJ Hargrave]

I also think ip is a bit too minimalist. Certtainly as the bundle symbolic 
name. I am less concerned as the package name.
-- 

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




"Alex Blewitt" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
2007-07-07 17:26
Please respond to
Equinox development mailing list 


To
"Equinox development mailing list" 
cc

Subject
Re: Re[2]: [equinox-dev] Prosyst contributions






I'm glad I'm not alone. I've asked the question to a wider audience to
see if they'd get the reference:

http://www.eclipsezone.com/eclipse/forums/t98469.html

On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
> You're not alone, Alex. I think ip is a horrible name.
> initprovisioning or initprov or something would've been better.
> There's just no way that someone's going to know that 'ip' is 'initial
> provisioning'.
>
> Regards,
> Rem
>
> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> > Am I really the only one who thinks '.ip'  is a bad name?
> >
> > Alex.
> >
> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
> > > That's great! I've just done a quick sanity check and everything 
compiles,
> > > starts and is ready to try out.
> > >  Thanks.
> > >
> > > For anyone wanting to take a look, the following new projects were 
added to
> > > the incubator.
> > >
> > > 1) org.eclipse.equinox.ds
> > > 2) org.eclipse.equinox.io
> > > 3) org.eclipse.equinox.ip
> > > 4) org.eclipse.equinox.util
> > > 5) org.eclipse.equinox.wireadmin
> > >
> > > I had one cosmetic question for equinox.util. Currently the BSN is
> > > "org.eclipse.equinox.util.putifull" -- is there some reason it's not 
just
> > > org.eclipse.equinox.util?
> > > -Simon
> > >
> > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:
> > >
> > > > In CVS under your proposed naming.
> > > >
> > > > -Pavlin
> > > >
> > > > >
> > > >
> > > > OK, I'm not particular about the names right now.  Since we 
already
> > > > have a DS bundle lets just use org.eclipse.equinox.ds for
> > > > declarative services.
> > > >
> > > > I also like org.eclipse.equinox.ip for initial provisioning but
> > > > thought it might be to short :)  but it is snappy.
> > > >
> > > > Pavlin, if these are ok with you please release with the names 
org.
> > > > eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said before 
it
> > > > is no big deal to rename the bundles if needed in the incubator 
later.
> > > >
> > > > Tom
> > > >
> > > > Chris Aniszczyk/Austin/[EMAIL PROTECTED]
> > > > Sent by: [EMAIL PROTECTED]
> > > > 07/05/2007 09:34 PM
> > > >
> > > > Please respond to
> > > > Equinox development mailing list 
> > > >
> > > > To
> > > >
> > > > Equinox development mailing list 
> > > >
> > > > cc
> > > >
> > > > Subject
> > > >
> > > > Re: [equinox-dev] Prosyst contributions
> > > >
> > > > as an outsider, +1 for DS instead of SCR, there's like 5 people 
that
> > > > would get the SCR reference :)
> > > >
> > > > initialprovisioning is really long
> > > >
> > > > Cheers,
> > > >
> > > > ---
> > > > Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga
.
> > > > blogspot.com | +1.860.839.2465
> > > >
> > > > [image removed] Jeff McAffer ---07/05/2007 09:13:02 PM---I agree
> > > > with all/most Tom said. In the end we should look to have just one
> > > > DS implementation, Ultimately I suggest that it be
> > > >
> > > > [image removed]
> > > > From:
> > > >
> > > > [image removed]
> > > > Jeff McAffer <[EMAIL PROTECTED]>
> > > >
> > > > [image removed]
> > > > To:
> > > >
> > > > [image removed]
> > > > Equinox development mailing list 
> > > >
> > > > [image removed]
> > > > Date:
> > > >
> > > > [image removed]
> > > > 07/05/2007 09:13

Re: Re[4]: [equinox-dev] Prosyst contributions

[BJ Hargrave]

o.e.eq.ip should only be an internal (private) package name. The public 
API is defined by OSGi: org.osgi.service.provisioning.
-- 

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




"Alex Blewitt" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
2007-07-08 07:21
Please respond to
Equinox development mailing list 


To
"Pavlin Dobrev" <[EMAIL PROTECTED]>
cc
Equinox development mailing list 
Subject
Re: Re[4]: [equinox-dev] Prosyst contributions






It would be better to have a more descriptive bundle symbollic name,
that's for sure. The question then becomes whether it makes sense to
keep the bundle symbolic name and package name in sync. Given that
most package imports are handled automatically by Eclipse anyway, the
only reason I can think for having a shorter package name is that it
takes up a few less chars in the various UTF-8 constant pools in the
.class files; but if that were really an issue, we'd be calling the
packages o.e.eq.ip anyway.

The danger with using 'ip' as the package name is that it effectively
prevents anyone from having a package with the same name for unrelated
services; for example, an OSGi bundle for generating ICMP IP packets.

I'd vote for a longer name in both cases. Not that my vote counts for
anything, but as a periodic lurker on the mailing list ...

Alex.

On 08/07/07, Pavlin Dobrev <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> My personal opinion also is that IP is a horible name but maybe as BJ
> propose we can use long bundle symbolic name?
>
> -Pavlin
>
> AB> I'm glad I'm not alone. I've asked the question to a wider audience 
to
> AB> see if they'd get the reference:
>
> AB> http://www.eclipsezone.com/eclipse/forums/t98469.html
>
> AB> On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
> >> You're not alone, Alex. I think ip is a horrible name.
> >> initprovisioning or initprov or something would've been better.
> >> There's just no way that someone's going to know that 'ip' is 
'initial
> >> provisioning'.
> >>
> >> Regards,
> >> Rem
> >>
> >> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> >> > Am I really the only one who thinks '.ip'  is a bad name?
> >> >
> >> > Alex.
> >> >
> >> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
> >> > > That's great! I've just done a quick sanity check and everything 
compiles,
> >> > > starts and is ready to try out.
> >> > >  Thanks.
> >> > >
> >> > > For anyone wanting to take a look, the following new projects 
were added to
> >> > > the incubator.
> >> > >
> >> > > 1) org.eclipse.equinox.ds
> >> > > 2) org.eclipse.equinox.io
> >> > > 3) org.eclipse.equinox.ip
> >> > > 4) org.eclipse.equinox.util
> >> > > 5) org.eclipse.equinox.wireadmin
> >> > >
> >> > > I had one cosmetic question for equinox.util. Currently the BSN 
is
> >> > > "org.eclipse.equinox.util.putifull" -- is there some reason it's 
not just
> >> > > org.eclipse.equinox.util?
> >> > > -Simon
> >> > >
> >> > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 AM:
> >> > >
> >> > > > In CVS under your proposed naming.
> >> > > >
> >> > > > -Pavlin
> >> > > >
> >> > > > >
> >> > > >
> >> > > > OK, I'm not particular about the names right now.  Since we 
already
> >> > > > have a DS bundle lets just use org.eclipse.equinox.ds for
> >> > > > declarative services.
> >> > > >
> >> > > > I also like org.eclipse.equinox.ip for initial provisioning but
> >> > > > thought it might be to short :)  but it is snappy.
> >> > > >
> >> > > > Pavlin, if these are ok with you please release with the names 
org.
> >> > > > eclipse.equinox.ds and org.eclipse.equinox.ip.  As I said 
before it
> >> > > > is no big deal to rename the bundles if needed in the incubator 
later.
> >> > > >
> >> > > > Tom
> >> > > >
> >> > > > Chris Aniszczyk/Austin/[EMAIL PROTECTED]
> >> > > > Sent by: [EMAIL PROTECTED]
> >> > > >

Re: Re[4]: [equinox-dev] Prosyst contributions

[BJ Hargrave]

Well, read the spec! :-) Then you will understand the "initial" part!
-- 

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




"Alex Blewitt" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
2007-07-08 10:29
Please respond to
Equinox development mailing list 


To
"Equinox development mailing list" 
cc

Subject
Re: Re[4]: [equinox-dev] Prosyst contributions






Well, why not call it 'o.e.provisioning' then? What's so initial about it?

On 08/07/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
> o.e.eq.ip should only be an internal (private) package name. The public
> API is defined by OSGi: org.osgi.service.provisioning.
> --
>
> 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
>
>
>
>
> "Alex Blewitt" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 2007-07-08 07:21
> Please respond to
> Equinox development mailing list 
>
>
> To
> "Pavlin Dobrev" <[EMAIL PROTECTED]>
> cc
> Equinox development mailing list 
> Subject
> Re: Re[4]: [equinox-dev] Prosyst contributions
>
>
>
>
>
>
> It would be better to have a more descriptive bundle symbollic name,
> that's for sure. The question then becomes whether it makes sense to
> keep the bundle symbolic name and package name in sync. Given that
> most package imports are handled automatically by Eclipse anyway, the
> only reason I can think for having a shorter package name is that it
> takes up a few less chars in the various UTF-8 constant pools in the
> .class files; but if that were really an issue, we'd be calling the
> packages o.e.eq.ip anyway.
>
> The danger with using 'ip' as the package name is that it effectively
> prevents anyone from having a package with the same name for unrelated
> services; for example, an OSGi bundle for generating ICMP IP packets.
>
> I'd vote for a longer name in both cases. Not that my vote counts for
> anything, but as a periodic lurker on the mailing list ...
>
> Alex.
>
> On 08/07/07, Pavlin Dobrev <[EMAIL PROTECTED]> wrote:
> > Hi Alex,
> >
> > My personal opinion also is that IP is a horible name but maybe as BJ
> > propose we can use long bundle symbolic name?
> >
> > -Pavlin
> >
> > AB> I'm glad I'm not alone. I've asked the question to a wider 
audience
> to
> > AB> see if they'd get the reference:
> >
> > AB> http://www.eclipsezone.com/eclipse/forums/t98469.html
> >
> > AB> On 07/07/07, Remy Chi Jian Suen <[EMAIL PROTECTED]> wrote:
> > >> You're not alone, Alex. I think ip is a horrible name.
> > >> initprovisioning or initprov or something would've been better.
> > >> There's just no way that someone's going to know that 'ip' is
> 'initial
> > >> provisioning'.
> > >>
> > >> Regards,
> > >> Rem
> > >>
> > >> On 7/7/07, Alex Blewitt <[EMAIL PROTECTED]> wrote:
> > >> > Am I really the only one who thinks '.ip'  is a bad name?
> > >> >
> > >> > Alex.
> > >> >
> > >> > On 07/07/07, Simon Kaegi <[EMAIL PROTECTED]> wrote:
> > >> > > That's great! I've just done a quick sanity check and 
everything
> compiles,
> > >> > > starts and is ready to try out.
> > >> > >  Thanks.
> > >> > >
> > >> > > For anyone wanting to take a look, the following new projects
> were added to
> > >> > > the incubator.
> > >> > >
> > >> > > 1) org.eclipse.equinox.ds
> > >> > > 2) org.eclipse.equinox.io
> > >> > > 3) org.eclipse.equinox.ip
> > >> > > 4) org.eclipse.equinox.util
> > >> > > 5) org.eclipse.equinox.wireadmin
> > >> > >
> > >> > > I had one cosmetic question for equinox.util. Currently the BSN
> is
> > >> > > "org.eclipse.equinox.util.putifull" -- is there some reason 
it's
> not just
> > >> > > org.eclipse.equinox.util?
> > >> > > -Simon
> > >> > >
> > >> > > [EMAIL PROTECTED] wrote on 07/07/2007 06:41:23 
AM:
> > >> > >
> > >> > > > In CVS under your proposed naming.

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 


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: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones

[BJ Hargrave]

So far, the respondents want #2. Tom was just observing that #1 has been 
the case in the past. 

Given that (a) bugzilla does not support multiple releases within a single 
bug (see CMVC tracks) and (b) bugzilla does have a quick and easy "Clone 
This Bug" link, #2 is the most practical and obvious 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




Jeff McAffer <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
2007-07-13 11:18
Please respond to
Equinox development mailing list 


To
Equinox development mailing list 
cc

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







ok.  in theory I support #2 but if everyone else is doing #1 then there 
may be more merit in consistency.  there is some logic that says things 
released in 3.n.x will alos be in 3.n+1.x but that is not always true. The 
issue may come down to overhead in managing the bugs/process. 

Jeff 



Thomas Watson <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 
07/13/2007 08:59 AM 

Please respond to
Equinox development mailing list 


To
Equinox development mailing list  
cc

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









No we have not done #2 in the past releases.  Searching through 3.2.x bugs 
for Platform and Equinox you will notice that most (all?) teams seem to 
have done #1 for the 3.2.x releases. 

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=Equinox&product=Platform&target_milestone=3.2.1&target_milestone=3.2.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
 


Tom


Jeff McAffer <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 
07/12/2007 09:19 PM 

Please respond to
Equinox development mailing list 



To
Equinox development mailing list  
cc

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











i thought we were all already doing #2... 

Jeff 

Thomas Watson <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED] 
07/11/2007 01:42 PM 

Please respond to
Equinox development mailing list 



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 whic

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 


To
Equinox development mailing list 
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
 
  
  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 
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 




To

Equinox development mailing list 

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 



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

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

[EMAIL PROTECTED] wrote on 2007-09-12 16:01:05:

> 
> BJ Hargrave wrote on 09/12/2007 03:33:59 PM:
> 
> > 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.
> 
> Actually the UI is misleading.  Components are treated as second-
> class by the web ui.  Actually they are hidden for scaleability 
> reasons.  If you drill into the "members" link in any given project 
> you will see that you are a committer on the framework and bundles 
> components of equinox (for example).  Note that there is currently 
> some bogus data driving these pages to don't believe all you see. 

That's rather encouraging... :-)

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


To
Equinox development mailing list  
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 



To
Equinox development mailing list  
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 



To
Equinox development mailing list  
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 comp

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


To
Equinox development mailing list  
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 
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 Arthor

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



To
Equinox development mailing list  
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 
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 
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 
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] Proposal for an OSGi spec work area in the equinox incubator

[BJ Hargrave]

+1
-- 

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-dev@eclipse.org
Date:
2007-10-16 17:23
Subject:
[equinox-dev] Proposal for an OSGi spec work area in the equinox incubator



I would like to start a new work area in the Equinox incubator to support 
prototyping and investigating future OSGi specifications. The goal behind 
this work area is to develop an implementation of the specification as the 
specification is being developed.

This work area will allow others to more easily join in on the 
investigations for future OSGi implementations. To begin with this work 
area would be used to implement the next release of the OSGi Framework, 
but other future OSGi specifications could also be contributed. This will 
also allow Equinox to provide reference implementations to OSGi without 
effecting the current Eclipse release. We would only graduate the code out 
of the incubator once the OSGi specification has gone public/final and we 
can align it with a major Eclipse release.

I would like to take a vote to approve the OSGi spec work area in the 
equinox incubator.

Tom


- Forwarded by Thomas Watson/Austin/IBM on 10/16/2007 03:45 PM -


From:

Thomas Watson/Austin/IBM

To:

equinox-dev@eclipse.org

Date:

10/12/2007 01:34 PM

Subject:

OSGi R4.2 Stream


The OSGi Alliance is busy working on the next release of the 
specification. The release of the next OSGi specification will be long 
after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede 
release we will not release new OSGi R4.2 API or implement new R4.2 
functions in the Ganymede stream (HEAD).

We need a place where we can continue to implement and prototype the next 
OSGi specification release as it is being developed. I see two options.

1) Create an area in the Equinox incubator to develop the OSGi R4.2 
implementation
2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 
implementation

I prefer using a branch instead of a separate repository project in the 
incubator because it will make life easier when developing streams in 
parallel, which we will likely need to do until the Ganymede release in 
June 2008. I plan to create a branch based of next weeks I-Build for the 
OSGi R4.2 work. Please let me know if you have any issues with 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: [equinox-dev] Differences in classloading between standard activators and Declarative Services

[BJ Hargrave]

SCR does not alter the class loading setup of a bundle. That is, 
DynamicImport-Package will work either way. You can even use a normal 
BundleActivator with SCR assuming you use lazy activation. When SCR goes 
to load the first class from a bundle, the lazy activation will trigger 
the execution of the BundleActivator.

The only thing that may be different is timing in bundle startup. You may 
need to do some class loader diagnostics to see what is actually 
happening.
-- 

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:
"Michael Furtak" <[EMAIL PROTECTED]>
To:

Date:
2007-11-05 11:22
Subject:
[equinox-dev] Differences in classloading between standard  activators 
and Declarative Services



Hi all,
 
I have a quick question about a possible difference I am noticing between 
the way classes are loaded in standard Equinox activators and the DS SCR 
in equinox 3.4.I20071023-0800.
 
Specifically, when transitioning to DS, I have started running into 
exceptions that I see commonly when Swing cannot acquire the L&F classes 
it needs.  I have solved these problems in the standard activator scenario 
by:
1)   Making sure that bundles that introduce new L&F classes export 
those classes
2)   Having the bundles that wind up triggering these Swing look-ups 
include DynamicImport-Package: * in their manifest.
 
What seems to be the case is that the SCR is not honoring that 
DynamicImport-Package statement, because when I switch to those services 
being started via DS, I run into the errors again. Those errors look like 
this:
 
UIDefaults.getUI() failed: no ComponentUI class for: 
javax.swing.JMenuItem…
java.lang.Error
at javax.swing.UIDefaults.getUIError(UIDefaults.java:691)
at 
javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:117)
at javax.swing.UIDefaults.getUI(UIDefaults.java:721)
at javax.swing.UIManager.getUI(UIManager.java:860)
at javax.swing.JMenuItem.updateUI(JMenuItem.java:208)
at javax.swing.JMenuItem.init(JMenuItem.java:170)
at javax.swing.JMenuItem.(JMenuItem.java:119)
…
 
To restate the difference clearly, the same services started via OSGi 
activator do not produce the errors, where the DS start-up does.
 
Any insight or suggestions for a better solution to the Swing L&F issues 
would be appreciated.
 
Thanks,
-Mike Furtak
 
 
 
 
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS 
ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended 
recipient, your use of this message for any purpose is strictly 
prohibited. If you have received this communication in error, please 
delete the message and notify the sender so that we may correct our 
records. 
 
 
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] 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 
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
<><>___
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] OBR

[BJ Hargrave]

This may be a problem in the tool (from OSGi) which generates the xml. OSGi 
recently decide to add < and > to the set of filter operators. But this is not 
in the 4.1 spec. It will be in a future spec. So the tool which generates the 
xml should not use the new operators.


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: ChangWoo Jung [EMAIL PROTECTED]
Sent: 01/20/2008 07:43 AM
To: Equinox development mailing list 
Cc: Peter Kriens <[EMAIL PROTECTED]>
Subject: Re: [equinox-dev] OBR



I guess I found little bug in the generated OBR repo (
http://download.eclipse.org/releases/europa/repository.zip)
The generated filter seems to be incorrect which throws exception in the
runtime.

For example, Jetty Http Service (org.eclipse.equinox.http.jetty), has
dependency on "javax.servlet" which is shown as
Import-Package: javax.servlet;version="[2.4.0,2.5.0)" in the manifest.

It turns out be generated like below, (which seems to be incorrect), so it
throws "InvalidSyntaxException" when equinox tries to create the filter
upon that.


  Import package javax.servlet ;version=2.4.0


I guess there is minor bug on creating filter and after applying my
private fix it seems to be working.
wrong:
filter='(&(package=javax.servlet)(version>=2.4.0)(version<2.5.0))'

correct:
filter='(&(package=javax.servlet)(&(version>=2.4.0)(&(version!=2.5.0)(version<=2.5.0'

Which component will be the right place to report a bug against that i can
attach my fix there as well? Any pointers?
Thanks.


Sincerely,
ChangWoo Jung





From:
Jeff McAffer <[EMAIL PROTECTED]>
To:
Equinox development mailing list 
Date:
01/12/2008 12:43 AM
Subject:
Re: [equinox-dev] OBR




We currently do host an OBR repo with the major releases.   Don't remember
the URL but the required repository.xml/zip file is there for Callisto and
Europa.  The OBR client code may be interesting but our strategic
direction is p2.  For the most part p2 has (or can be made to have) the
same functionality as the OBR client but goes further towards solving the
wider range of problems we see in the Eclipse provisioning space.

I am all for supporting the use of OBR repositories in the sense that some
people will make their function available that way.  Given the p2 work
however, it would be more interesting (to me at least) to write an OBR
repository adaptor for p2 than to use the OBR api.  Further, I hope that
eclipse projects will feel comfortable making their content available as
p2 repositories so that the Eclipse user community is not put in a
position of having to get many different provisioning clients.

In short, we in p2 would very much like to have your interaction and
participation in making a provisioning solution that solves your needs.

Jeff



Thomas Hallgren <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/11/2008 10:19 AM

Please respond to
Equinox development mailing list 


To
Equinox development mailing list 
cc

Subject
[equinox-dev] OBR








Hi,
I'm wonder if any work has been done within Eclipse to deal with OBR
repositories, and if so, how can I get access to that. If not, and if no
one has a better idea, I'm planning to start an IP-zilla to get the
Apache Felix OBR approved since we will want to map that kind of
repositories in Buckminster and also provide OBR's as an alternative to
update sites in the spaces project.

Regards,
Thomas Hallgren

___
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] 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" 
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.c

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

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] DS invocation order of bind and activate (timing issue???)

[BJ Hargrave]

I think you should put this in a bug report against DS.
-- 

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

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




From:
"Foerster, Stefan" <[EMAIL PROTECTED]>
To:
equinox-dev@eclipse.org
Date:
2008-02-22 11:52
Subject:
[equinox-dev] DS invocation order of bind and activate (timing  issue???)



Hello,

I'm having three bundles providing three services using the declarative 
service (version 1.0.0.v20080218):

bundle A:

  
  

  
  
  
  
  
  
  


bundle B:

  
  

  
  
  
  
  


bundle D:

  
  

  
  
  
  


Reading the OSGi DS spec I assume the only valid method invocation order 
(if the methods exists and are accessible) is:
1) D1.activate()   -> some instanceD
2) A1.setD(instanceD)
3) A1.activate()   -> some instanceA
4) B1.setA(instanceA) and B1.setD(instanceD) in any order
5) B1.activate()   -> some instanceB
6) A1.setB(instanceB)

Sometimes, it happens that B1 is activated before!!! A1. and I get the 
following 
order of calls from the OSGi log (calls to setD() are not logged!):

==
1: >Debug [51] D1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
2: >Info [51] ServiceEvent REGISTERED {service.id=29}
3: >Info [54] ServiceEvent REGISTERED {service.id=30}
4: >Info [37] ServiceEvent REGISTERED {service.id=31}
5: >Info [52] ServiceEvent REGISTERED {service.id=32}
6: >Info [53] ServiceEvent REGISTERED {service.id=33}
7: >Warn [4] ComponentReference.bind(): bind method setE is not 
accessible! [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
8: >Warn [4] ComponentReference.bind(): bind method setB is not 
accessible! [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
9: >Debug [51] B1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
10:>Debug [51] A1: setB() [EMAIL PROTECTED]:file:../../build/d1.jar/
11:>Debug [51] A1: setB() A1 not yet activated!!! [EMAIL PROTECTED]:
file:../../build/d1.jar/
12:>Debug [51] A1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
13:>Debug [51] E1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
14:>Debug [51] A1: setE() [EMAIL PROTECTED]:file:../../build/d1.jar/
15:>Debug [51] B2: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
16:>Debug [51] A1: setB() [EMAIL PROTECTED]:file:../../build/d1.jar/
17:>Warn [4] ComponentReference.bind(): service reference already bound: 
{IB}={service.ranking=1000, service.pid=B1, component.name=B1, 
component.id=4, service.id=33} [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
==

Please observe line 11! I inserted the check for activation since else 
some internal data structures of A1 were not 
initialised and I had NullPointerExceptions.
Since I check for activation, all services are at least started.


I also have a run the whole thing with DS debugging enabled, interestingly 
no service is started at all:

==
>Info [6] Log created; Log Size=100; Log Threshold=4 [EMAIL PROTECTED]:
file:org.eclipse.equinox.log_1.1.0.v20071203.jar/
>Info [6] ServiceEvent REGISTERED {service.id=23}
>Info [6] ServiceEvent REGISTERED {service.id=24}
>Info [6] ServiceEvent REGISTERED {service.id=25}
>Info [6] BundleEvent STARTED [EMAIL PROTECTED]:
file:org.eclipse.equinox.log_1.1.0.v20071203.jar/
>Debug [5] bundleentry://7/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Debug [5] [QueuedJob] WorkPerformer: 
[EMAIL PROTECTED]; actionType 1 
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on 
processing [QueuedJob] WorkPerformer: 
[EMAIL PROTECTED]; actionType 1 
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Info [7] BundleEvent STARTED [EMAIL PROTECTED]:file:../../build/b1.jar/
>Info [8] BundleEvent STARTED [EMAIL PROTECTED]:
file:org.apache.commons.logging_1.0.4.v200711021015.jar/
>Info [11] BundleEvent STARTED [EMAIL PROTECTED]:
file:org.eclipse.osgi.services_3.1.200.v20071203.jar/
>Debug [5] bundleentry://12/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Debug [5] [QueuedJob] WorkPerformer: 
[EMAIL PROTECTED]; actionType 1 
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on 
processing [QueuedJob] WorkPerformer: 
[EMAIL PROTECTED]; actionType 1 
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Info [12] BundleEvent STARTED [EMAIL PROTECTED]:file:../../build/a1.jar/
>Debug [5] bundleentry://14/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
>Debug [5] [QueuedJob] WorkPerformer: 
[EMAIL PROTECTED]; actionType 1 
[EMAIL PROTECTED]:file:or

Re: [equinox-dev] Cannot bind services to multiply DS factory components

[BJ Hargrave]

> Hello.
> 
> I have such component descriptions:
> 
> 
>   
>   
> 
>   
> 
> 
> 
>   
>   
> 
>   
>interface="testservice.TestService"
> cardinality="0..n"
> policy="dynamic"
> bind="addTestService"
> unbind="removeTestService"/>
> 
> 
> At first I instantiate let's say five TestService components with 
> it's factory. 

So at this point there should be 5 TestService services registered with 
the framework.

> Then I try to instantiate two TestServiceNew 
> components with it's factory. Everything seems OK except of one 
> thing: all five TestService are bound to first TestServiceNew, but 
> none of them is bound to second TestServiceNew! In log I have this 
warning:
> 

Yes this seems wrong. Each TestServiceNew component instance should have 
all five TestServices bound to it.

> WARNING 21 ComponentReference.bind(): service reference already 
> bound: {testservicenew.TestServiceNew}=
> {component.name=TestServiceNew, component.id=10, id=0, service.id=37}
> 
> I thinks this is happens because of DS thinks that all factory 
> components share same reference pool or something, so there is no 
> need to bind TestService to second instance of TestServiceNew, 
> because they are already bound to first instance. Is this true? If 
> it is, is there a way to override this behaviour or someway to 
> implement such behaviour that I need?

I think this is a bug in the DS impl. Please open a bug against 
Equinox->Bundles with this information and a test case to help reproduce 
the problem.

Thanks,

-- 

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] Using log4j with LogService

[BJ Hargrave]

You can write code which uses to LogReaderService to receive log entries as 
they are written to the LogService and the writes them to log4j.

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: "Srijith Kochunni" [EMAIL PROTECTED]
Sent: 03/17/2008 09:21 PM
To: 
Subject: [equinox-dev] Using log4j with LogService



Hi All,

   I am working on the logging module of a project which uses log4j.  I 
am writing it as a bundle which will expose it`s own service for logging in the 
OSGi runtime. I would like to know whether it is possible for me to integrate 
this with the Equinox Log Service? For example is it possible for me to 
configure the OSGi Log Service as an appender for my log4j module. My intention 
is that consumer bundles should be able to use either OSGi Log Service/ My 
Logging service and logs should happen in both.

Thanks in advance for your help.

-
Srijith.
___
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] 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'" 
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] my confusion for unregistering services in bundle.stop

[BJ Hargrave]

It is up to you. If the framework removes them, they will be removed in a 
random order. If you have several listeners and registered services which 
should be shutdown in some orderly manner, you will need to shut them down 
yourself.

-- 

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:
Meng Xin Zhu <[EMAIL PROTECTED]>
To:
equinox-dev@eclipse.org
Cc:
Xiang Yu Hao <[EMAIL PROTECTED]>
Date:
2008/03/31 06:17 AM
Subject:
[equinox-dev] my confusion for unregistering services in bundle.stop



I find below description in the OSGi R4 specification section '4.3.6 
Activation':

stop(BundleContext) – This method must undo all the actions of the 
BundleActivator.start(BundleContext) method. However, it is unnecessary to 
unregister services or Framework listeners, because they must be cleaned 
up by the Framework anyway.

Recently I read a post introducing development best practices(it's ibm 
internal site), it says: 
While the OSGi Framework will clean up services and service references, it 
is still good programming practice to clean up what you allocate. 
If you register services in the start() method, unregister the services in 
the stop() method. 
If you create (and open) a ServiceTracker in the start() method, close it 
in the stop() method. 
If you start threads or jobs in your start() method, make sure that the 
threads or jobs are terminated by your stop method.

Which practice I would choice when programming OSGi service under Equinox? 
Thanks

Best Regards
Zhu Meng Xin
IBM Workplace Client Technology
Tel: 86-10-82452244-52342 Fax: 86-10-82452887
NOTES: Meng Xin Zhu/China/IBM E-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] Granting permissions for usage of Bundle

[BJ Hargrave]

In general, the management of permission is best done by a management 
agent: a bundle (or set of bundles) tasked with managing the set of 
installed bundles including the security policy. Enforcing permissions of 
course means that a SecurityManager is installed.

In order to modify the permissions on CPA, the caller must have 
AllPermission. So, in your example, bundle A would need AllPermission to 
modify the permissions so that only bundle B can import a specific 
package. Bundle A is then a "super user" which seems wrong.
-- 

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:
"Srijith Kochunni" <[EMAIL PROTECTED]>
To:

Date:
2008/04/15 07:03 AM
Subject:
[equinox-dev] Granting permissions for usage of Bundle



Hi All, 

 I have a bundle(A) from which I am exporting a package. I want to 
ensure that this package can be imported only by another particular 
bundle(B) in the OSGi runtime. Have been reading the spec about 
Conditional Permission Admin Service and Permission Admin Service, but am 
finding it difficult to understand whether they do provide such a facility 
and if so how it can be achieved using these core services. 

 Again I do not want to use a separate Management Agent bundle to 
enforce this scenario, unless there is no other option. It would be better 
if I could achieve this by writing code in my consumed bundle alone. Any 
links to examples for using Permission Admin Service / Conditional 
Permission Service would also be helpful. 

Thanks, 
Srijith. ___
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 

> 
> 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: AW: [equinox-dev] regarding OSGI Device Access (Problem with Drivers)

[BJ Hargrave]

Can you please open a bug and attach a test case which demonstrates the 
problem?
-- 

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:
"Daniel Felsing" <[EMAIL PROTECTED]>
To:
"'Equinox development mailing list'" 
Date:
2008/06/27 06:30 AM
Subject:
AW: [equinox-dev] regarding OSGI Device Access (Problem with Drivers)



Hmmm this behavior described below is only true if i start/stop the bridge 
driver (which exports the devices)
and the base driver already has some devices exported to the registry.
 
 
If the bridge driver is running and i start/stop the basedriver (which 
removes/registers the devices which should get exported)
everything works fine.
 
Kind regards,
Daniel
 
 
Von: [EMAIL PROTECTED] [
mailto:[EMAIL PROTECTED] Im Auftrag von Daniel Felsing
Gesendet: Freitag, 27. Juni 2008 11:59
An: equinox-dev@eclipse.org
Betreff: [equinox-dev] regarding OSGI Device Access (Problem with Drivers)
 
Dear All,
 
I really need help :-(

Let us say, I have a Base Driver, which creates Motion Sensor and Simple 
Light Devices (OSGI Devices).. and I have another bundle
which acts as a motion sensor/ simple light bridging driver. The driver 
will create new UPnP devices which use my motion sensor / simple light 
devices as model (e.g. creates a new upnplightdevice for each simple light 
found).
 

When the bridge driver bundle is installed/started in the framework, it 
registers itsself (OSGI Driver service).

The basedriver registering the motion sensor / simple light devices gets 
started and registers the found devices in the registry

Now the OSGI DeviceManager look for all "Drivers" and calls the  match 
method of my upnpbridge driver…
In best case my bundle is successful and registers the upnp device 
implementations to the registry which lets the upnp base driver (from 
niche) export them successfully.


Now my question….
 
I tried to test the behavior of my base and bridge driver by starting and 
stopping them in random order while the framework is running.
Most of the time all runs fine…and attach and match methods get called on 
my driver
 
so my bridge driver says:
-   Motionsensor1 successfully exported
-   Light1 successfully exported
 
BUT SOMETIMES SOMEHOW…(i cannot explain why…)
 
The bridgedrivers (which should export the devices) match method is only 
called for one of the devices (this behavior is random) and the other 
device’s „noDriverFound()“ method gets called immediately…?
Thats a strange behavior…since the match method of the driver should be 
called…..and sometimes it doesnt!
 
I use eclipse equinox version 3.2 and already tried the device bundle from 
3.4 – but no success either.
 
 
Kind regards,
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

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

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

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

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

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 

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

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]

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

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

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

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

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

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

Re: [equinox-dev] Is this a bug?

[BJ Hargrave]

FYI. OSGi discussed and declined to specify a reference URL form. So it is 
not part of the spec and we have no plans to add it to the spec.
-- 

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



[EMAIL PROTECTED] wrote on 2008/09/24 09:02:52 AM:

> [image removed] 
> 
> Re: [equinox-dev] Is this a bug?
> 
> Stuart McCulloch 
> 
> to:
> 
> Equinox development mailing list
> 
> 2008/09/24 09:04 AM
> 
> Sent by:
> 
> [EMAIL PROTECTED]
> 
> Please respond to Equinox development mailing list 

> 
> 2008/9/24 Niclas Hedhman <[EMAIL PROTECTED]>
> On Wed, Sep 24, 2008 at 5:12 PM, Danail Nachev <[EMAIL PROTECTED]> 
wrote:
> If bundles are installed by reference (via reference: URL) Equinox
> doesn't guarantee anything to bundles which you replace, while they are
> still running. Although OSGi is considered dynamic, such scenarios are
> not supported. AFAIK, p2 and old Eclipse Update installs all bundles by
> reference.
> 
> Such scenarios can be supported if the bundle was copied to the Equinox
> storage and not referenced. Bundles which are installed through
> Bundle.installBundle(String, InputStream) and
> Bundle.installBundle(String) are copied (unless the URL passed to the
> installBundle(String) is reference: URL) are copied to the storage.
> 
> I find this behavior interesting... Is this behavior supported by 
> the specification explicitly, or does it just not cover it??
> 
> I couldn't find any explicit mention in the spec, but FWIW we also 
> support the reference: scheme in Felix

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

> -- 
> Cheers, Stuart___
> 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 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  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" 
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:









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











... 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 
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" 
Date:
2008/11/26 08:46
Subject:
Re: [equinox-dev] What bundle class loaded from
Sent by:
[EMAIL PROTECTED]



On a similar note, is there a way to access the actual bundle file?
Like for running an external javac-process (think tomcat jasper),
which needs a classpath.

On Mon, Nov 24, 2008 at 18:15, BJ Hargrave <[EMAIL PROTECTED]> wrote:
> PackageAdmin.getBundle(Class)
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
> From:
> Oleg Zhurakousky <[EMAIL PROTECTED]>
> To: Equinox development mailing list 
> Date: 2008/11/24 12:04
> Subject: [equinox-dev] What bundle class loaded from
> Sent by: [EMAIL PROTECTED]
> 
>
>
> I know how to do it the "hard way", but was wondering if there is and
> elegant way to determine which Bundle loaded a class?
> Thanks
> Oleg
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] Support for RFC 119

[BJ Hargrave]

> Thanks to whoever did that!

You're welcome :-)

>   Should I open an enhancement request to add a REMOTE type and attach a 

> patch to contribute an addition/change? (e.g.):

I will open a bug in OSGi to fix that. In the interim just use the 
numerical value 5.

> One question:  does this framework change appear somewhere else in the 
> r4.2 spec? (i.e. other than 119)?  As it seems to imply that RFC 119 
> isn't stand-alone (that is, it requires this small addition to 
framework).

119 relies on come changes in 4.2 (e.g. ServiceHooks). ServiceException is 
one of them.

>   Are there conventions about this (placement) that dictate what 
> package(s) these interfaces should be in?  If so, where is that? 

These should already be in one of the jars from OSGi. Tom?


-- 

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

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

RE: [equinox-dev] Adding Equinox Declarative Services (DS) to theEclipse SDK

[BJ Hargrave]

+1
-- 

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

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




From:
"Toedter, Kai" 
To:
"Equinox development mailing list" , "General 
development mailing list of the Eclipse project." 

Date:
2009/01/26 11:46
Subject:
RE: [equinox-dev] Adding Equinox Declarative Services (DS) to   theEclipse 
SDK
Sent by:
equinox-dev-boun...@eclipse.org



+1
 
Actually, a few month ago I have filed a bug for adding DS to the Eclipse 
SDK, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253926
 
Kai
 
From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Chris Aniszczyk
Sent: Montag, 26. Januar 2009 17:35
To: General development mailing list of the Eclipse project.
Cc: Equinox development mailing list
Subject: [equinox-dev] Adding Equinox Declarative Services (DS) to 
theEclipse SDK
 
Howdy y'all. I like to raise the question of us adding Equinox DS to the 
Eclipse SDK. DS provides a powerful way to deal with OSGi services and in 
my opinion, greatly simplifies the development of services. As we forge 
towards Eclipse 3.5, we made a lot of steps to make DS easier to use in 
the Eclipse SDK without it actually being in the SDK:

- Prosyst donated a high quality implementation of OSGi DS that made its 
way to the Equinox SDK
- PDE release DS component authoring tools as part of a GSOC project and 
3.5 work
- The DS spec was updated to work better with lazy bundles (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226575)

Technically, to add DS to the Eclipse SDK all we need to do as add these 
two tiny bundles:

 org.eclipse.equinox.ds (.15MB)
 org.eclipse.equinox.util (.02MB)

So my request in sending this email out is to get the opinion of consumers 
(anyone who builds applications on top of Eclipse) and producers (the 
Eclipse platform team, especially the Equinox committers). Do consumers 
see a benefit of having DS in the SDK? Does the greater Eclipse team feel 
comfortable with having DS in the SDK and may use it in the future 
potentially?

And if we reach a consensus, it would be great to see DS included with the 
Eclipse SDK in the 3.5M6 timeframe. If not, at least we had a fun 
discussion :)

Thoughts?

Cheers,

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

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

Re: [equinox-dev] Equinox port on Android

[BJ Hargrave]

See http://www.eclipsecon.org/2008/index.php?page=sub/&id=380. The 
presentation attached there includes a link to a patch but that patch is 
probably against a 3.4 milestone driver.
-- 

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

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




From:
Mathieu Baudier 
To:
equinox-dev@eclipse.org
Date:
2009/04/20 05:28
Subject:
[equinox-dev] Equinox port on Android
Sent by:
equinox-dev-boun...@eclipse.org



Hi,

I have read in many places that Equinox has been successfully ported to 
Android (Google's mobile OS). 

(e.g. 
http://mobileosgi.blogspot.com/2008/06/public-resources-about-mobile-osgi.html 
or 
http://www.google.at/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Ffelix.apache.org%2Fsite%2Fpresentations.data%2FOSGi%2520on%2520Google%2520Android%2520using%2520Apache%2520Felix.pdf&ei=AkDsSe3fEMSF_QaanujiAw&usg=AFQjCNHf5TIqvPlTeJiRXa9LQhFmsnn8Jw&sig2=siaja0VPiHqhG0PYEVR2jw
, page 44).

Unfortunately, I could find anywhere more detailed technical information 
or code/download.

Could anyone please point me to some information?

Many thanks in advance!

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

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

Re: [equinox-dev] ServiceReference.compareTo(Object)

[BJ Hargrave]

Please open a bug in the bugzilla system for this.
-- 

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

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




From:
岡野　真一 
To:
equinox-dev@eclipse.org
Date:
2009/04/24 05:37
Subject:
[equinox-dev] ServiceReference.compareTo(Object)
Sent by:
equinox-dev-boun...@eclipse.org



Hi all !

I am using Equinox 3.4.2, and I thik I found a bug.

The Javadoc of "org.osgi.framework.ServiceReference.compareTo(Object)"
says the following:

This ServiceReference is less than the specified ServiceReference if
it has a lower service ranking and greater if it has a higher
service ranking. Otherwise, if this ServiceReference and the
specified ServiceReference have the same service ranking, this
ServiceReference is less than the specified ServiceReference if it
has a higher service id and greater if it has a lower service id.

But,
org.eclipse.osgi.framework.internal.core.ServiceReferenceImpl.compareTo(Object)
(version=3.4.3.R34x_v20081215-1030) is implemented the following.

if (this.getRanking() != other.getRanking())
return this.getRanking() > other.getRanking() ? -1 : 1;
return this.getId() == other.getId() ? 0 : this.getId() > 
other.getId() ? 1 : -1;

I think the following is correct.

if (this.getRanking() != other.getRanking())

return this.getRanking() > other.getRanking() ? 1 : -1;  //  <--

return this.getId() == other.getId() ? 0 : this.getId() > 
other.getId() ? -1 : 1;  // <<-


I'm sorry if I have a mistake, or if it had already been discussed.

Thanks.

-- 
-
Shinichi Okano  (okano-shini...@sei.co.jp)

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

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

Re: [equinox-dev] Security Doubt

[BJ Hargrave]

You can configure your system to support this. Note: since using 
permission is invasive in Java code (doPrivileged), all the bundles, in 
particular B, must be properly coded with the necessary doPrivileges to 
make it work.
-- 

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

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




From:
"David Conde" 
To:

Date:
2009/04/28 05:18
Subject:
[equinox-dev] Security Doubt
Sent by:
equinox-dev-boun...@eclipse.org



Hi , I have a doubt about permissions in Equinox, I would like to have the 
next scenario.
 
I would like to have a set of bundles called A,A1, A2 running in Equinox, 
which are able to communicate and know about bundle B, but they do not 
know about the existence of bundle C, all of them running as well on 
Equinox. I mean, Bundle A,A1,A2 have permissions either to get service or 
import service from bundle B, bundle B have permissions either to import 
or get the service from C, and A, A1 and A2 are not able to get or import 
service from C. My question is ¿if it is possible to use bundle B from 
bundles A,A1,A2 to get acess to C service?Will either Java security or 
Equinox Security thrown an exception in this case?
 
 
Thank you in advance
 
 
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] policy="dynamic" in Declarative Services.

[BJ Hargrave]

This does not sound like a "flicker" problem. DS can handle that also for 
a dynamic 1..1 reference. The new service would be passed to bind before 
the old service is passed to unbind. So the component is never without a 
dependent service.

I think the issue here is that there is no replacement service available 
and, with a 1..1 cardinality, the component is deactivated.
-- 

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

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




From:
Hal Hildebrand 
To:
Equinox development mailing list 
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy="dynamic" in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org



There's also Spring/DM, which does I think what you want - i.e. 1..1 
cardinality, but not dropping the service is its dependencies 
momentarily flicker.

On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:

> You cannot directly do this, because mandatory reference is mandatory
> at all times. However, you could make the reference optional and
> perform some kind of internal activation/deactivation in the
> bind/unbind methods.
>
> However, if that still doesn't work for you then you're trying to do
> something outside the scope of use-cases supported by DS, so you
> should drop down to the ServiceTracker API.
>
> Regards,
> Neil
>
>
> On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
>  wrote:
>> Hi  Kai,
>>
>> On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai > >
>> wrote:
>>>
>>> HI Sameera,
>>>
>>>
>>>
>>> I think Equinox’ behavior is correct here. If you have a mandatory 
>>> service
>>> reference that is not valid anymore, the referring component has 
>>> to be
>>> deactivated even if the policy is dynamic.
>>
>> I agree with your point.  Now say that the service is mandatory 
>> when the
>> component is activated. Once the component is activated, the 
>> service is a
>> optional one. That mean I don't want my component to be de- 
>> activated when
>> the service is unregistered. How can I handle this situation with
>> declarative services?
>>
>> Thanks
>> Sameera
>>>
>>>
>>>
>>>> But my requirement is that the service should be registered 
>>>> before the
>>>> component is activated.
>>>
>>>> in that case I have to put cardinality as "1..1" right?
>>>
>>> I guess your question is related to the lazy activation of 
>>> components.
>>> This is the default unless you declare the component itself 
>>> “immediate”. The
>>> meaning is: Unless no one wants to use your service, the component 
>>> (the
>>> implementing Java class) will not be instantiated.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Kai
>>>
>>>
>>>
>>> From: equinox-dev-boun...@eclipse.org
>>> [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera 
>>> Jayasoma
>>> Sent: Montag, 4. Mai 2009 04:59
>>> To: Equinox development mailing list
>>> Subject: Re: [equinox-dev] policy="dynamic" in Declarative Services.
>>>
>>>
>>>
>>> Hi,
>>>
>>> On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin  
>>> wrote:
>>>
>>> if u want to the component isn't deactivated,u should set the bound
>>> service cardinality to "0..1"
>>>
>>>
>>> Thanks for the quick reply. But my requirement is that the service 
>>> should
>>> be registered before the component is activated. in that case I 
>>> have to put
>>> cardinality as "1..1" right?
>>>
>>> Thanks
>>> Sameera
>>>
>>> 2009/5/4 Sameera Jayasoma :
>>>
>>>> Hi devs,
>>>>
>>>> Even though I have used the value "dynamic" for the "policy" 
>>>> attribute
>>>> in
>>>> the "reference" element, the component is deactivated once the 
>>>> bound
>>>> service
>>>> is unregistered. Here is the component.xml I am using.
>>>>
>>>> http://www.osgi.org/xmlns/scr/v1.0.0";>
>>>> 
>>>> >>> class="org.wso2.carbon.core.internal.CarbonCoreDSComponent"/>
>>>> >>> value="carbon.core.dscomponent"/>
>>>> &

Re: [equinox-dev] ClassLoader leak caused by EventManager's EventThread creation

[BJ Hargrave]

Andy,

Can you file a bug on this?
-- 

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

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




From:
Andy Wilkinson 
To:

Date:
2009/05/06 09:22
Subject:
[equinox-dev] ClassLoader leak caused by EventManager's EventThread 
creation
Sent by:
equinox-dev-boun...@eclipse.org



Hi,

I've been looking into a PermGen leak and have identified what looks to 
be an undesirable side-effect of 
org.eclipse.osgi.framework.eventmgr.EventManager's creation of an 
EventThread instance. In my particular situation the EventManager 
instance is MRUBundleFileList's bundleFileCloserManager. I'm running on 
3.5.0.v20090311-1300.

When the EventThread is lazily created, it gets its context class loader 
from the current thread. In my situation it's a call from a non-Equinox 
owned thread that's triggered the lazy creation of the EventThread 
instance. In this case at least, it doesn't seem right for this 
Equinox-owned thread to be holding a reference to this foregin class 
loader, particularly as it's not easy to update the EventThread's 
context classloader in application code. The reference to the 
classloader leads to a PermGen leak as the classloader doesn't become 
eligible for garbage collection.

With the caveat that I don't know if there is some expectation about 
what the event thread's context class loader should be, I wonder if it 
would be better if EventManager was updated to explicitly set an 
EventThread's context class loader, possibly to Equinox's classloader, 
i.e. EventManager.class.getClassLoader()?

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

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

RE: [equinox-dev] Conditional Permission are not being checked

[BJ Hargrave]

That is a rather old version of Equinox 3.5 (M1). Go to 
http://download.eclipse.org/equinox/ to see all the versions available and 
download 3.5 M7.
-- 

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

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




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/05/07 04:32
Subject:
RE: [equinox-dev] Conditional Permission are not being checked
Sent by:
equinox-dev-boun...@eclipse.org



I am sorry, I found the new version 3.5 of Equinox in 
http://www.eclipse.org/downloads/download.php?file=/equinox/drops/S-3.5M1-200808071402/org.eclipse.osgi_3.5.0.v20080804-1730.jar
 
So I will try with this one and I will write back the results.
 
David
 
De: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] En nombre de David Conde
Enviado el: jueves, 07 de mayo de 2009 10:26
Para: 'Equinox development mailing list'
Asunto: RE: [equinox-dev] Conditional Permission are not being checked
 
Hi again, where I can get Equinox 3.5 I tried to get from 
http://download.eclipse.org/equinox/drops/R-3.4.2-200902111700/index.php, 
but there is just to version 3.4 to download.
 
I do not know really the problem and If I am missing something, I have a 
Permission Manager, who grant to itself ALLPERMISSION, and in this bundle 
we fix a BundleLocationCondition in order that my bundle
 
file:C:\\equinoxv34\\clientserviceconditional.jar is the only one who can 
Get the Service from ServiceConditional. Am I wrong? What option do I have 
to write when I launch Equinox in console way?
 
cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new

String[]{"file:C:\\equinoxv34\\clientserviceconditional.jar"})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),
"dconde.osgi.serviceconditional.ServiceConditional","GET")

});
Thank you very much in advance
 
 
 
De: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] En nombre de Thomas Watson
Enviado el: miércoles, 06 de mayo de 2009 18:52
Para: Equinox development mailing list
Asunto: Re: [equinox-dev] Conditional Permission are not being checked
 
Can you try this on 3.5? The OSGi R4.2 specification (implemented in 
Equinox 3.5) made a clarification about when the default permissions from 
PermissionAdmin are used in the presence of the ConditionalPermissionAdmin 
service.

The default default permissions for PermissionAdmin is AllPermissions. In 
Equinox 3.4 we would fall back to the PermissionAdmin default permissions 
if none of the conditions from the ConditionalPermissionAdmin table were 
satisfied for a particular bundle. The OSGi R4.2 specification has been 
clarified such that the PermissionAdmin default permissions are ONLY used 
if the condition table is COMPLETELY empty. Once you add a single 
condition to the table then bundles must not be granted the 
PermissionAdmin default permissions.

In 3.4 you should set the PermissionAdmin default permissions to a 
restricted set of permissions or you could set another condition with 
ConditionalPermissionAdmin which restricts the permissions for all bundle 
locations.

Tom



"David Conde" ---05/06/2009 11:08:03 AM---Hi,


From:

"David Conde" 

To:



Date:

05/06/2009 11:08 AM

Subject:

[equinox-dev] Conditional Permission are not being checked




Hi, 

I am trying to check Conditional Permssion Admin SErvice in Equinox. For 
this reason, I create a Bundle consumer, another one called service and 
another called PermissionManager who will implement the Conditional 
Permissions for the consumer.

The problem is that I do not get any exception when I try to get the 
service from another location different from my allowed one.

My PermissionManager implements BundleActivator and get the service 
ConditionalPermissionAdmin from the framework in the start method, finally 
is shown below:

private ConditionalPermissionAdmin cpa;

condPermRef = context.getServiceReference(ConditionalPermissionAdmin.class
.getName());

cpa =(ConditionalPermissionAdmin) context.getService(condPermRef);

AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
cpa.addConditionalPermissionInfo(new ConditionInfo[]{
new ConditionInfo(BundleLocationCondition.class.getName(),
new
String[]{context.getBundle().getLocation()})
},
new PermissionInfo[]{
new PermissionInfo(
AllPermission.class.getName(), "", "")
});

cpa.addConditionalPermissionInfo(
new ConditionInfo[]{
new ConditionInfo(
BundleLocationCondition.class.getName(),
new

String[]{"file:C:\\equinoxv34\\clientserviceconditional.jar"})
},
new PermissionInfo[]{
new PermissionInfo
(ServicePermission.class.getName(),
"dconde.osgi.serviceconditional.ServiceConditional","GET")

});
// Add other permis

Re: [equinox-dev] Framework launching and class loaders

[BJ Hargrave]

The org.osgi.service.cm package has 2 "version" in your example. One 
loaded from a bundle and used by the ConfigurationAdmin service 
implementation and the other on the application classpath. You need to 
either use reflection to use the service (then you don't need the version 
on the classpath) or you need to configure the framework to export the 
version on the package on the application classpath from the system bundle 
(org.osgi.framework.systempackages.extra) so that the ConfigurationAdmin 
bundle uses that version of the package.
-- 

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

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




From:
Jansson Patrik 
To:
"equinox-dev@eclipse.org" 
Date:
2009/05/25 08:57
Subject:
[equinox-dev] Framework launching and class loaders
Sent by:
equinox-dev-boun...@eclipse.org



I'm using the framework launching API to start an OSGi framework (which in 
this case is Equinox 3.5M6).
I need to pass some configuration from the launcher application to one of 
the bundles running so I thought
of using the ConfigurationAdmin service for this.
 
The launcher gets hold of a BundleContext (from the framework handle) and 
gets a reference to the 
service; ServiceReference reference = context.getServiceReference(...)
 
But I get into trouble on the next step
ConfigurationAdmin cAdmin = (ConfigurationAdmin) 
context.getService(reference);
This throws a ClassCastException. The actual object returned uses 
equinox's class loader while the class I'm
trying to cast to, ConfigurationAdmin, is loaded through the launcher's 
standard class loader
(sun.misc.Launcher$AppClassLoader in this case).
 
How can I go around this? Shouldn't I be playing with OSGi services 
outside the framework like this? In
that case how should I pass configuration from the launcher to the bundle?
 
Thanks,
-Patrik Jansson
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

RE: [equinox-dev] Framework launching and class loaders

[BJ Hargrave]

You can't "override" exported packages. But, if you use the same package 
version number as exported by a bundle, the framework will prefer an 
already exported package when resolving. Since the framework exports the 
system packages first, then they are preferred.
-- 

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

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




From:
Jansson Patrik 
To:
Equinox development mailing list 
Date:
2009/05/26 04:43
Subject:
RE: [equinox-dev] Framework launching and class loaders
Sent by:
equinox-dev-boun...@eclipse.org



What will happen if I let the org.eclipse.osgi.services bundle remain 
resolved in my OSGi framework and the system bundle export the same 
version of org.osgi.service.cm? Which package will be imported by other 
bundles (eclipse implementation of ConfigurationAdmin being one of them)?
 
That way, I don't have to care about exporting packages inside 
org.eclipse.osgi.services that is not mutually shared by the launcher and 
bundles inside the framework. So, what I'm asking for is a way to override 
a specific package exported by a bundle (but not all of them), is that 
possible?
 
Thanks,
-Patrik

From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of BJ Hargrave
Sent: den 25 maj 2009 15:12
To: Equinox development mailing list
Subject: Re: [equinox-dev] Framework launching and class loaders

The org.osgi.service.cm package has 2 "version" in your example. One 
loaded from a bundle and used by the ConfigurationAdmin service 
implementation and the other on the application classpath. You need to 
either use reflection to use the service (then you don't need the version 
on the classpath) or you need to configure the framework to export the 
version on the package on the application classpath from the system bundle 
(org.osgi.framework.systempackages.extra) so that the ConfigurationAdmin 
bundle uses that version of the package. 
-- 

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

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



From: 
Jansson Patrik  
To: 
"equinox-dev@eclipse.org"  
Date: 
2009/05/25 08:57 
Subject: 
[equinox-dev] Framework launching and class loaders 
Sent by: 
equinox-dev-boun...@eclipse.org




I'm using the framework launching API to start an OSGi framework (which in 
this case is Equinox 3.5M6). 
I need to pass some configuration from the launcher application to one of 
the bundles running so I thought 
of using the ConfigurationAdmin service for this. 
  
The launcher gets hold of a BundleContext (from the framework handle) and 
gets a reference to the 
service; ServiceReference reference = context.getServiceReference(...) 
  
But I get into trouble on the next step 
ConfigurationAdmin cAdmin = (ConfigurationAdmin) 
context.getService(reference); 
This throws a ClassCastException. The actual object returned uses 
equinox's class loader while the class I'm 
trying to cast to, ConfigurationAdmin, is loaded through the launcher's 
standard class loader 
(sun.misc.Launcher$AppClassLoader in this case). 
  
How can I go around this? Shouldn't I be playing with OSGi services 
outside the framework like this? In 
that case how should I pass configuration from the launcher to the bundle? 

  
Thanks, 
-Patrik Jansson 
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] Declarative Services Bind/Unbind Method Signatures

[BJ Hargrave]

The DS 1.1 spec does NOT require bind and unbind methods for a reference 
to have the same signatures. If the Equinox DS impl requires them to, 
please open a bug.
-- 

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

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




From:
Andrew Teirney 
To:
equinox-dev@eclipse.org
Date:
2009/05/28 20:18
Subject:
[equinox-dev] Declarative Services Bind/Unbind Method Signatures
Sent by:
equinox-dev-boun...@eclipse.org



Does a declarative services components unbind method have to have the
same signature as its corresponding bind method?

I have noticed in the commit...

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/model/ComponentReference.java?root=RT_Project&view=diff&r1=1.8&r2=1.9


In that change this results in at lines 462,463 for the unbind
invocation using the method parameters as obtained from the bind
method, this results in an IllegalArgumentException if the unbind
method does not have the same signature as the bind method.

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

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

Re: [equinox-dev] Creating heavy weight DS Components

[BJ Hargrave]

One idea is to use a separate component factory for the service(s) 
provided by the BIG component. Reference the component factory from the 
"main" component. When the main component is activated and has completed 
the long running task on the thread, a single instance of the factory 
component is created which then provides the service.
-- 

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

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




From:
Andrew Teirney 
To:
equinox-dev@eclipse.org
Date:
2009/05/29 17:48
Subject:
[equinox-dev] Creating heavy weight DS Components
Sent by:
equinox-dev-boun...@eclipse.org



I currently have several use cases whereby I am using declarative
services to inject dependent services into a component instance, lets
call this component BIG.

The component BIG is intended to provide several services, however
before it can provide the services it needs to be able to utilize
those dependent service for a setup operation that can take some
lengthy amount of time (needs to access several databases/files).

At present I have been trying to do this in the activate method,
however this does have a time limit and if I understand things
correctly if this time is exceeded then the component will be disposed
of if its takes too long to construct.

So, to get around this in the activate method I spawn a thread that
does the processing in the background, and when it completes I
register the services programatically. This thread obviously has to
take into account any of its services being ripped out from underneath
whilst its using it, and the component itself being deactivated.

What I am wondering is whether this is the best possible solution to a
component being a heavyweight service (in that it takes some time to
properly construct). Other than the complexity of the solution another
aspect I don't like is that the services a component provides are not
part of the declarative services xml (a mild annoyance).

If anyone has any tips/pointers on perhaps how to handle this
heavyweight component creation problem I am encountering that would be
appreciated.

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

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

Re: [equinox-dev] Permission Admin Service Problem

[BJ Hargrave]

Did you start Equinox with security on? Those services are not registered 
unless you start the framework with security on.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "David Conde" [dco...@citic.es]
Sent: 06/26/2009 12:21 PM ZE2
To: "'Equinox development mailing list'" 
Subject: [equinox-dev] Permission Admin Service Problem



Hi everyone,



I would like to use the method getPermissions from Permission Admin Service
in order to get Local permissions information from a bundle location. I have
read that this bundle is already integrated in the framework, and looking
for it in the Equinox bundles I did not found it, but when I tried to get
the service I got NULL, as this service was not installed in the framework.
So, my question is, do I have to download this bundle from anywhere?Is this
bundle still used in OSGI? I read that ConditionalPermissionAdmin service
appeared in newer version of OSGI in order to provide more security
capabilities to OSGI than Permission Admin.



Thank you in advance



David

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

Re: [equinox-dev] org.osgi.framework.system.packages.extra system variable

[BJ Hargrave]

That property is new for OSGi 4.2 which Equinox 3.5 implements.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "Chris Hopkins" [chopk...@cra.com]
Sent: 06/30/2009 10:45 AM AST
To: "Equinox development mailing list" 
Subject: [equinox-dev] org.osgi.framework.system.packages.extra system  variable



Hi all -



I'm trying to get access to the
com.sun.java.swing.plaf.windows.WindowsComboBoxUI class within my
Equinox plug-in. I noticed back in April that Tom had referenced a
org.osgi.framework.system.packages.extra system variable that can be set
to add packages to the list of available packages that the framework
recognizes. However, I can't seem to get it to work. I set the
following:



org.osgi.framework.system.packages.extra=com.sun.java.swing.plaf.windows



but when I start Eclipse I still cannot import the WindowsComboBoxUI
class.



Am I setting the property incorrectly?



I am still using Eclipse 3.4 but I have defined a Target Platform for
this workspace that includes the jars below. I pulled them from a RC
version of Equinox just prior to the official Galileo release.



org.eclipse.equinox.ds_1.1.0.v20090513.jar

org.eclipse.equinox.event_1.1.100.v20090513.jar

org.eclipse.equinox.log_1.2.0.v20090513.jar

org.eclipse.equinox.util_1.0.100.v20090429-1630.jar

org.eclipse.osgi.services_3.2.0.v20090513.jar

org.eclipse.osgi.util_3.2.0.v20090429-1630.jar

org.eclipse.osgi_3.5.0.v20090513.jar



Thanks,

Chris




THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Unclear warning in DS when a service component provides inexisting/unimplemented interface

[BJ Hargrave]

You should probably open a bug for this.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
Office: +1 386 848 1781 Mobile: +1 386 848 3788


- Original Message -
From: "Kirchev, Lazar" [l.kirc...@sap.com]
Sent: 06/30/2009 02:11 PM ZE2
To: 
Subject: [equinox-dev] Unclear warning in DS when a service component   
provides inexisting/unimplemented interface



Hello,

We are using declarative services and we came across the following
situation. There are two components, A and B. A provides an interface
and B references this interface. If the interface which A provides does
not exist, or is not implemented, when the framework tries to create an
instance of component B, a warning that there is probably a circular
dependancy is logged. This does not help to find the real problem - that
the interface does not exist and there is no such service.

In ComponentReference.getMethod(...), if the result of the call
InstanceProcess.staticRef.getService(...) is null, then it is assumed
that serviceObject cannot be created because of circularity. But
InstanceProcess.staticRef.getService(...) returns null both when there
is circularity and when the service object cannot be retrieved from the
bundle context.

Also, if the component state is checked with the component command, it
is Satisfied, saying in the dynamic information part that all references
of the component are satisfied.

Is this the intended behavior of DS?

Kind regards,
Lazar Kirchev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Problem with custom local permissions

[BJ Hargrave]

Have you written (or installed) a bundle which reads the permissions.perm 
file, parses the text into PermissionInfos and calls either 
PermissionAdmin or ConditionalPermissionAdmin to set the permissions of 
the bundle?

permissions.perm files are not read by the framework. You need s security 
policy bundle installed (for example, as I describe above) to set bundle 
permissions. The framework is policy free.
-- 

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

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




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/09/04 07:59
Subject:
[equinox-dev] Problem with custom local permissions
Sent by:
equinox-dev-boun...@eclipse.org



Hi,
 
I have the next scenario: 
Bundle Service which has a method called addVALUE as  shown:
 
public boolean addValue(String key, Object value) {
 
SecurityManager security = System.getSecurityManager();
  if (security != null) {
security.checkPermission(new PlatformConfigurationPermission(
PlatformConfigurationPermission.WRITE_VALUE)); 
  }
 
}
 
The problem is that other  bundle  called consumer which has the next 
permissions.perm file, tries to call this method getting the Security 
Exception shown below:
 
#TestPlatformConfiguration Permissions File
(java.io.FilePermission "C:\TestingLog3.log" "write")
(es.citic.osgi.system.platformConfiguration.PlatformConfigurationPermission 
"PlatformConfigurationPermission" "writeValue")
 
 
The Exception which was got is:
Java.security.AccessControlException: Access denied 
(es.citic.osgi.system.platformConfiguration.PlatoformConfigurationPermission 
PlatformConfigurationPermission writeValue)
 
 
My PlatformConfigurationPermission class extends from Permission.
 
What am I missing in this implementation?
 
It looks like as does not recognice what I am writing in the 
permission.perm file.
 
Any idea
 
Thank you in advance
 
David___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] Problem when BundleContext.getAllServiceReferences(null, null);

[BJ Hargrave]

You can only get services for which the caller has 
ServicePermission(serviceName, "get"). If your bundle has no service 
permissions, you will get no services.
-- 

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

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




From:
"David Conde" 
To:
"'Equinox development mailing list'" 
Date:
2009/09/14 06:24
Subject:
[equinox-dev] Problem when BundleContext.getAllServiceReferences(null, 
null);
Sent by:
equinox-dev-boun...@eclipse.org



Hi, I am getting null object when I try to get AllServices references in 
Equinox framework using :
 
 Result = bundleContext.getAllServiceReferences(null, null);
 
This problem only happens when I use Equinox with security, getting all 
services references if I do not active the security in Equinox.
 
Do I need any special permission? I do not get any AccessControlException 
at all, so I suppoused that I did not need any permission.
 
Do I need to have “GET” permission for any Service?if this is, the problem 
is that I don’t know what Services I have in the framework.
 
Any idea?
 
Thank you in advance
 
David
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

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

[BJ Hargrave]

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

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

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




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




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

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

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

John 



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

Please respond to
Equinox development mailing list 


To
Equinox development mailing list  
cc

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








Today I have done some more DI exploration using DS to see how it fits 
with the constructs we have in eclipse and I'm struggling to integrate in 
a nice way with the application model (I mean without using static) and 
I'm looking to know how others are doing this?
The one line summary of my experiment is: I have a class that does some 
work (named RepositoryDumper), it needs a service (RepoMgr). I want now to 
create an eclipse application that invokes the RepositoryDumper and I 
would like to not have to acquire the RepoMgr service manually.

Here is what I have been exploring with:
Solution 1:
I have an application declared in the plugin.xml. I have created a DS 
component that instantiates RepositoryDumper. However the question now is 
how does the application (remember that an eclipse application extension 
needs to provides n class) can get a hold of the RepositoryDumper instance 
that got created by DS:
- 1.1: Ugly -> Store the instance RepositoryDumper in the Activator of the 
plug-in
- 1.2: Get the RepositoryDumper be registered as a Service and have the 
application get this service. I don't like this because now 
RepositoryDumper is visible to everybody just so I can get access to it

Solution 2:
This solution assumes that the declarative approach to the eclipse 
application model is the hindrance and works around it by registering an 
ApplicationDescriptor (org.osgi.service.application). To do so I create a 
DS component that instantiates the RepositoryDumper and also register an 
ApplicationDescriptor as a service. This has the nice attribute that 
everything gets injected and that the application is only available to run 
if all the necessary pieces are available. However it requires a lot of 
code since one has to implement ApplicationDescriptor and 
ApplicationHandle, and I don't think this application would even be 
launchable using the -application argument.

Solution 3:
This solution is an hybrid between 1 and 2 using the 
IExecutableExtensionFactory. 
There is a DS component that creates the RepositoryDumper and register a 
service, let's call it X. Then let's make the class specified in 
application extension (in the plugin.xml) implements 
IExecutableExtensionFactory and have it get the service X. This solution 
allows to have the application construction be completely done by 
injection however given that the application is contributed through 
extension registry it still is visible even though not ready to run.

How are others doing this? Is this a real problem or is it just me? Should 
I just not worry about that and use static fields?
Btw, the code is available /cvsroot/rt 
org.eclipse.equinox/incubator/p2/bundles/org.eclipse.equinox.p2.diagnostic 
Only solution 1 and 2 are available.

Thx for your attention and feedback

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

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

[BJ Hargrave]

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

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

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

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

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

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




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




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

John 



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

Please respond to
Equinox development mailing list 


To
Equinox development mailing list  
cc

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








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

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

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


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






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

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

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

John 

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

Please respond to
Equinox development mailing list 



To
Equinox development mailing list  
cc

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












Today I have done some more DI exploration using DS to see how it fits 
with the constructs we have in eclipse and I'm struggling to integrate in 
a nice way with the application model (I mean without using static) and 
I'm looking to know how others are doing this?
The one line summary of my experiment is: I have a class that does some 
work (named RepositoryDumper), it needs a service (RepoMgr). I want now to 
create an eclipse application that invokes the RepositoryDumper and I 
would like to not have to acquire the RepoMgr service manually.

Here is what I have been exploring with:
Solution 1:
I have an application declared in the plugin.xml. I have created a DS 
component that instantiates RepositoryDumper. However the question now is 
how does the application (remember that an eclipse application extension 
needs to provides n class) can get a hold of the RepositoryDumper instance 
that got created by DS:
- 1.1: Ugly -> Store the instance RepositoryDumper in the Activator of the 
plug-in
- 1.2: Get the RepositoryDumper be registered as a Se

Re: [equinox-dev] MetaType Service

[BJ Hargrave]

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

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

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




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



Hello everyone.

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

Many thanks,
Ali.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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

[BJ Hargrave]

Why doesn't DS just asynchronously process bundles which are lazy 
activated (not lazy started which is an incorrect term)? Then you have the 
same behavior (async processing) regardless of whether the bundle is 
lazily or eagerly activated.
-- 

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

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




From:
John Arthorne 
To:
equinox-dev@eclipse.org
Date:
2009/10/26 14:32
Subject:
[equinox-dev] DS and bundle stop/start
Sent by:
equinox-dev-boun...@eclipse.org




I came across an interesting problem today involving DS and expicitly 
starting/stopping bundles. After chatting with Tom he suggested I raise it 
here for general awareness and to discuss whether the behaviour makes 
sense. 

In various places in p2 today we explicitly start bundles for various 
reasons. We typically use Bundle.start(Bundle.START_TRANSIENT) for this 
purpose. We are starting to use DS in p2 today, and we have a few places 
where a bundle acquires a service that it registered via DS in its own 
BundleActivator.start method. It turns out that DS only processes/starts 
service components synchronously for bundles that are lazy started. If you 
start a bundle explicitly the DS processing occurs asynchronously, and as 
a result the services provided via DS are not available at the time the 
bundle starts. The result is subtlely different bundle behaviour (or 
outright failures), if a bundle is started explicitly via Bundle#start 
versus implicitly via lazy activation: 

1) Lazy start case: 
 a) bundle's service component is processed and services provided by the 
component are registered by DS 
 b) bundle activator starts, and can use services registered in 1a) 

2) Activation via Bundle.start(Bundle.START_TRANSIENT): 
  a) bundle's activator starts, and services are not yet available 
  b) bundle's service component is processed and services provided by the 
component are registered by DS 

It turns out there is a coding pattern that can be used to make the 
explicit start case match the lazy start case: 

final Bundle bundle = ...;//get some bundle 
bundle.start(Bundle.START_ACTIVATION_POLICY); 
bundle.start(Bundle.START_TRANSIENT); 

The call to start(Bundle.START_ACTIVATION_POLICY) causes DS to process the 
bundle and register its component services, but does not start the bundle. 
The second call to start with Bundle.START_TRANSIENT actually starts the 
bundle. 

The moral of the story seems to be that we need to use this "double start" 
coding pattern anywhere we are starting bundles, because those bundles 
might be using DS and relying on the activation order. Or, perhaps someone 
has a suggestion for changes that can be made to the framework or DS so 
that these cases behave consistently... 

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

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

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

[BJ Hargrave]

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

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

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




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



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

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

Tom



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


From:

BJ Hargrave/Austin/i...@ibmus

To:

Equinox development mailing list 

Date:

10/26/2009 03:27 PM

Subject:

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



Why doesn't DS just asynchronously process bundles which are lazy 
activated (not lazy started which is an incorrect term)? Then you have the 
same behavior (async processing) regardless of whether the bundle is 
lazily or eagerly activated. 
-- 

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

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


From: 
John Arthorne  
To: 
equinox-dev@eclipse.org 
Date: 
2009/10/26 14:32 
Subject: 
[equinox-dev] DS and bundle stop/start 
Sent by: 
equinox-dev-boun...@eclipse.org





I came across an interesting problem today involving DS and expicitly 
starting/stopping bundles. After chatting with Tom he suggested I raise it 
here for general awareness and to discuss whether the behaviour makes 
sense. 

In various places in p2 today we explicitly start bundles for various 
reasons. We typically use Bundle.start(Bundle.START_TRANSIENT) for this 
purpose. We are starting to use DS in p2 today, and we have a few places 
where a bundle acquires a service that it registered via DS in its own 
BundleActivator.start method. It turns out that DS only processes/starts 
service components synchronously for bundles that are lazy started. If you 
start a bundle explicitly the DS processing occurs asynchronously, and as 
a result the services provided via DS are not available at the time the 
bundle starts. The result is subtlely different bundle behaviour (or 
outright failures), if a bundle is started explicitly via Bundle#start 
versus implicitly via lazy activation: 

1) Lazy start case: 
a) bundle's service component is processed and services provided by the 
component are registered by DS 
b) bundle activator starts, and can use services registered in 1a) 

2) Activation via Bundle.start(Bundle.START_TRANSIENT): 
a) bundle's activator starts, and services are not yet available 
b) bundle's service component is processed and services provided by the 
component are registered by DS 

It turns out there is a coding pattern that can be used to make the 
explicit start case match the lazy start case: 

final Bundle bundle = ...;//get some bundle 
bundle.start(Bundle.START_ACTIVATION_POLICY); 
bundle.start(Bundle.START_TRANSIENT); 

The call to start(Bundle.START_ACTIVATION_POLICY) causes DS to process the 
bundle and register its component services, but does not start the bundle. 
The second call to start with Bundle.START_TRANSIENT actually starts the 
bundle. 

The moral of the story seems to be that we need to use this "double start" 
coding pattern anywhere we are starting bundles, because those bundles 
might be using DS and relying on the activation order. Or, perhaps someone 
has a suggestion for changes that can be made to the framework or DS so 
that these cases behave consistently... 

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

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

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

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

[BJ Hargrave]

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

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

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

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

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

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




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





BJ Hargrave wrote:
> Why doesn't DS just asynchronously process bundles which are lazy 
> activated (not lazy started which is an incorrect term)? Then you have 
> the same behavior (async processing) regardless of whether the bundle is 

> lazily or eagerly activated.

The DS components of activated bundles are processed by DS when it 
receives BundleEvent.STARTED (for normal activated bundles) or 
BundleEvent.LAZY_ACTIVATION (for lazy activated bundles). These events 
are processed in DS by a SynchronousBundleListener.
Actually DS processes synchronously the components in both cases. The 
difference comes with the fact that BundleEvent.STARTED is sent by the 
framework after the bundle's activator is started.
We cannot modify DS to process only BundleEvent.STARTED because in this 
case lazy activated bundles will not be processed at all.

What we can do in DS is to process the DS components of a bundle when DS 
receives BundleEvent.STARTING event instead of BundleEvent.STARTED. This 
way DS will process the components before the framework calls the bundle 
activator's start method and the behavior would be similar to the one 
when processing lazy activated bundles. However, the DS specification 
always speaks of DS processing started bundles. So, I am not sure 
whether it is appropriate to process the DS components of a bundle 
before it is fully started.

Stoyan


> -- 
> 
> *BJ Hargrave*
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
> __hargr...@us.ibm.com_ <mailto:hargr...@us.ibm.com> 
> 
> office: +1 386 848 1781
> mobile: +1 386 848 3788
> 
> 
> 
> 
> From:  John Arthorne 
> To:equinox-dev@eclipse.org
> Date:  2009/10/26 14:32
> Subject:   [equinox-dev] DS and bundle stop/start
> Sent by:   equinox-dev-boun...@eclipse.org
> 
> 
> 
> 
> 
> 
> 
> I came across an interesting problem today involving DS and expicitly 
> starting/stopping bundles. After chatting with Tom he suggested I raise 
> it here for general awareness and to discuss whether the behaviour makes 

> sense.
> 
> In various places in p2 today we explicitly start bundles for various 
> reasons. We typically use Bundle.start(Bundle.START_TRANSIENT) for this 
> purpose. We are starting to use DS in p2 today, and we have a few places 

> where a bundle acquires a service that it registered via DS in its own 
> BundleActivator.start method. It turns out that DS only processes/starts 

> service components synchronously for bundles that are lazy started. If 
> you start a bundle explicitly the DS processing occurs asynchronously, 
> and as a result the services provided via DS are not available at the 
> time the bundle starts. The result is subtlely different bundle 
> behaviour (or outright failures), if a bundle is started explicitly via 
> Bundle#start versus implicitly via lazy activation:
> 
> 1) Lazy start case:
> a) bundle's service component is processed and services provided by the 
> component are registered by DS
> b) bundle activator starts, and can use services registered in 1a)
> 
> 2) Activation via Bundle.start(Bundle.START_TRANSIENT):
>  a) bundle's activator starts, and services are not yet available
>  b) bundle's service component is processed and services provided by the 

> component are registered by DS
> 
> It turns out there is a coding patter

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

[BJ Hargrave]

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

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

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

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




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

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



OSGi Alliance is have a DevCon at the JAX conference in London.  The Call 
for Papers is out now; deadline is Nov 27.
 
https://www.osgi.org/DevConLondon2010/HomePage
 
Ian
 
 
Ian Skerrett
Director of Marketing
Eclipse Foundation
613-224-9461 ext. 227
blog: ianskerrett.wordpress.com
twitter: https://twitter.com/ianskerrett
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] some issues in creatingfilters

[BJ Hargrave]

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

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

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

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

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

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

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




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




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

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

Sent from the Equinox - Dev mailing list archive at Nabble.com.

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

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

Re: [equinox-dev] problem with ServiceTracker.open() and refreshThread in Equinox

[BJ Hargrave]

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

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

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




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



I ran into a problem with Equinox 3.5.1.R35x_v20090806:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Thanks,

   Tim.

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

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

[BJ Hargrave]

Do I smell DOS attack? :-)
-- 

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

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




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



Daniel,

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

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

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

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

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

Regards,
Neil

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

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

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

[BJ Hargrave]

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

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

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




From:

To:

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



Hi all,

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

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

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

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

Bye,
Daniel


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

Tim,

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

Neil

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

Re: [equinox-dev] Starting the system bundle

[BJ Hargrave]

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

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

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

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




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



Hello,
 
We are implementing logic which depends on the system bundle being put in 
ACTIVE state after all bundles, which should be running, are started. 
However, it turned out that actually the system bundle is put in ACTIVE 
state just before the bundles are started. This is evident from the method 
StartLevelManager.doSetStartLevel(…), which is called from the 
EquinoxLauncher. There is a comment in the code, that putting the bundle 
in ACTIVE state “should be done just before firing the STARTED event for 
the system bundle” but is done earlier, because “some depend on the system 
bundle being in the ACTIVE state when they are starting”. Do you think it 
is possible to change the current behavior and put the system bundle in 
ACTIVE state after the other bundles are started, as it is in the OSGi 
spec?
 
Kind regards,
Lazar Kirchev___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Bug in event admin

[BJ Hargrave]

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

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

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





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



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


Regards,
Alan

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

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

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

[BJ Hargrave]

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

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

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





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



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

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

So, what do we actually have to do here?

Jeff


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

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

Tom



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


From:

"Kirchev, Lazar" 

To:

Equinox development mailing list 

Date:

12/02/2010 10:52 AM

Subject:

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



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

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

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

Lazar



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

Tom



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

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




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

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

[BJ Hargrave]

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

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

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

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





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



Hi,

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

-Gunnar



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

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

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

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

[BJ Hargrave]

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

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

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

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





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



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

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

Tom

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

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

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

Sent from my BlackBerry

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

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

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

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

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






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



Hi,

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

-Gunnar



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

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

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

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

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

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

[BJ Hargrave]

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

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

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





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



Hi Richard and BJ,

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

Cheers
Neil

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

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

Re: [equinox-dev] Multiple bsnversion in equinox

[BJ Hargrave]

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

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

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





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



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

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

Thanks for your help,
Katya


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

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

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

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

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

~ John





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


To
Equinox development mailing list 
cc

Subject
[equinox-dev] Multiple bsnversion in equinox






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

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

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

resolve to the same file.
Is that expected? 
 
Thanks, 
Katya___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

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

Re: [equinox-dev] same bundle in multiple regions

[BJ Hargrave]

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

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

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





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



Hey folks,

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

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

Thanks,
Bobby___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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

[BJ Hargrave]

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

-- 

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

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





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



In an experiment to have 200K of services registered, the service lookup 
by GUID is exceedingly slow – more the 4 seconds per lookup.
 
There are enough RAM (8G) and heap (2G) allocated.
 
What would be the reason of the slowness of the lookup? Any settings to 
start the framework to improve this?
 
 
Thanks,
Stanley___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

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

[BJ Hargrave]

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

-- 

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

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





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



Just a side comment...

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

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

-> richard

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

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

Tom



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


From:

BJ Hargrave/Austin/IBM@IBMUS

To:

Equinox development mailing list , 

Date:

05/03/2012 10:04 PM

Subject:

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




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

-- 

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

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






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




In an experiment to have 200K of services registered, the service lookup 
by GUID is exceedingly slow – more the 4 seconds per lookup. 
 
There are enough RAM (8G) and heap (2G) allocated. 
 
What would be the reason of the slowness of the lookup? Any settings to 
start the framework to improve this? 
 
 
Thanks, 
Stanley___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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


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

Re: [equinox-dev] looking up binaries

[BJ Hargrave]

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

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

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

-- 

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

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





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



Hey, 

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

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

Thx

Pascal

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


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

Re: [equinox-dev] looking up binaries

[BJ Hargrave]

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

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

-- 

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

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





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



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

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

What do you think?

Pascal

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


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

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

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

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

-- 

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

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






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



Hey, 

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

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

Thx

Pascal

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


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

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

Re: [equinox-dev] looking up binaries

[BJ Hargrave]

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

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

-- 

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

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





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



Could capabilities be used to represent dependencies between native 
libraries? 

Scott

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

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

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

-- 

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

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






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



Hey, 

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

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

Thx

Pascal

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




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

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

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

Re: [equinox-dev] Some Packages must be imported outside of Eclipse

[BJ Hargrave]

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

-- 

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

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





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



Hello Richard,

thanks for your answer.

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

Regards,
Rene

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


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


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

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

[BJ Hargrave]

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

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

-- 

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

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





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



Hey All,

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

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

or can we use the newly released 4.3 compendium jar?

Thanks,

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
8-9 October 2012 | Liferay North America Symposium | 
liferay.com/northamerica2012
16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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

[BJ Hargrave]

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

-- 

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

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





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



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

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

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

Methods are summarized by me at at [2].

My questions:

1) Is Eclipse-BuddyPolicy deprecated or not recommended?

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

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

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

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

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

Visit our developer adventures at http://devblog.virtage.com!
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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



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

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

Re: [equinox-dev] bundles wiring and redeployment issues - hotswap

[BJ Hargrave]

To discuss, lets define some package names:

package mybean contains MyBean
package myservice contains MyService

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

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

-- 

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

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





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



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

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

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

[BJ Hargrave]

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

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

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




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



Hello All,

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

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

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

Thoughts?

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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

[BJ Hargrave]

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

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

and by the OSGi spec:

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

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

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

What do the constructors look like on your permissions?

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

-- 

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

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




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



Hey guys, thanks for responding.

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

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

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

The only requirements are:

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

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

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

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

Sincerely,
- Ray


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

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

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




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



Hello All, 

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

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

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

Thoughts? 

-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc.  
--- 
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012 
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

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

[BJ Hargrave]

> 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 
To: Equinox development mailing list 
Date:   2013/04/18 12:29
Subject:Re: [equinox-dev] PermissionInfoCollection issues with 
perms cloning
Sent by:equinox-dev-boun...@eclipse.org



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


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

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

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

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

Sorry about my confusion.

- Ray

Thx


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

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

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

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

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




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




-- 
Raymond Augé  | Senior Software Architect | Liferay, Inc. 
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

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

[BJ Hargrave]

> From: Scott Lewis 

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

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

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

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

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


-- 

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

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