Re: [osgi-dev] manifest localization (BJ Hargrave)
[EMAIL PROTECTED] wrote on 11/13/2006 12:51:48 PM: > BJ, > > I chuckled at your reply. The technical details are pretty much what > I thought. However, given the real subtleties of, say, bundle class > loading, I was surprised at the reluctance to enumerate headers with > framework semantics. > > I have no such fears because I have a healthy experience of being > wrong. So here is my list: > > 3.2.1.1 Bundle-Activator: framework semantics > 3.2.1.2 Bundle-Category: localized > 3.2.1.3 Bundle-Classpath: framework semantics > 3.2.1.4 Bundle-ContactAddress: localized > 3.2.1.5 Bundle-Copyright: localized > 3.2.1.6 Bundle-Description: localized > 3.2.1.7 Bundle-DocURL: localized > 3.2.1.8 Bundle-Localization: framework semantics > 3.2.1.9 Bundle-ManifestVersion: framework semantics > 3.2.1.10 Bundle-Name: localized This could be localized since the framework is not specified to use it at runtime. But I would not. Some framework impls will try to use this header as a substitute for Bundle-SymbolicName when old (pre-R4) bundles are installed. > 3.2.1.11 Bundle-NativeCode: framework semantics > 3.2.1.12 Bundle-RequiredExecutionEnvironment: framework semantics > 3.2.1.13 Bundle-SymbolicName: framework semantics > 3.2.1.14 Bundle-UpdateLocation: localized This has framework semantics since the framework should consult the value of the header during Bundle.update(). > 3.2.1.15 Bundle-Vendor: localized > 3.2.1.16 Bundle-Version: framework semantics > 3.2.1.17 DynamicImport-Package: framework semantics > 3.2.1.18 Export-Package: framework semantics > 3.2.1.19 Export-Service: framework semantics This header is deprecated and has no runtime semantics. > 3.2.1.20 Fragment-Host: framework semantics > 3.2.1.21 Import-Package: framework semantics > 3.2.1.22 Import-Service: framework semantics This header is deprecated and has no runtime semantics. > 3.2.1.23 Require-Bundle: framework semantics > > I assume in addition that those headers marked as having framework > semantics should be parsed as headers with clauses, and clauses with > values, directives, and attributes (some with additional constraints > as per the spec), while localized headers can be treated as mere > (localized) text strings, although in some cases it may be convenient > to present them in a more useful form (e.g. the bundle categories as > a list of strings). > > Feel free to comment or not ;-) > > Ciao! > > /djk > > > Date: Mon, 13 Nov 2006 11:56:51 -0500 > > From: BJ Hargrave <[EMAIL PROTECTED]> > > Subject: Re: [osgi-dev] manifest localization > > To: OSGi Developer Mail List > > Message-ID: > > > [EMAIL PROTECTED]> > > Content-Type: text/plain; charset="US-ASCII" > > > > The list will change over time (as we make new spec releases) and, > > invariably, the spec team will screw up and and the list will be > > incorrect. :-) So we chose to not put such a list in the spec. > > > > For each header defined by the spec, if the framework will use the > > header > > value in some way (e.g. Import-Package) then that header has framework > > semantics and the framework must not use any localization of the > > header. > > Others, like Bundle-Description, are never used by the framework. > > So, if > > you are implementing the framework, any header whose value you > > would need > > to use should be the original, unlocalized value. > > > > BJ Hargrave > > Senior Technical Staff Member, IBM > > OSGi Fellow and CTO of the OSGi Alliance > > [EMAIL PROTECTED] > > > > office: +1 407 849 9117 > > mobile: +1 386 848 3788 > > > > > > > > > > David Kemper <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 11/13/2006 11:44 AM > > Please respond to > > OSGi Developer Mail List > > > > > > To > > osgi-dev@bundles.osgi.org > > cc > > > > Subject > > [osgi-dev] manifest localization > > > > > > > > > > > > > > Section 3.10.2 (Manifest Localization) of the R4 specification states > > that > > > > "All headers in a bundle's manifest can be localized. However, the > > Framework must always use the non-localized versions of headers that > > have Framework semantics." > > > > I can make a guess as to which of the 23 manifest headers (see > > 3.2.1.1 through 3.2.1.23) have "Framework semantics" but would > > appreciate the list from a more official source. > > > > Also, I suggest that the list be made more explicit in the next > > revision o
Re: [osgi-dev] manifest localization
The list will change over time (as we make new spec releases) and, invariably, the spec team will screw up and and the list will be incorrect. :-) So we chose to not put such a list in the spec. For each header defined by the spec, if the framework will use the header value in some way (e.g. Import-Package) then that header has framework semantics and the framework must not use any localization of the header. Others, like Bundle-Description, are never used by the framework. So, if you are implementing the framework, any header whose value you would need to use should be the original, unlocalized value. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 407 849 9117 mobile: +1 386 848 3788 David Kemper <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/13/2006 11:44 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] manifest localization Section 3.10.2 (Manifest Localization) of the R4 specification states that "All headers in a bundle's manifest can be localized. However, the Framework must always use the non-localized versions of headers that have Framework semantics." I can make a guess as to which of the 23 manifest headers (see 3.2.1.1 through 3.2.1.23) have "Framework semantics" but would appreciate the list from a more official source. Also, I suggest that the list be made more explicit in the next revision of the specification. If the list is made clear in the specification, maybe someone could point it out and accept my apologies? Thanks in advance. /djk ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Where to download execution environments?
I don't know that anyone has created EEs beyond the 2 (ee.minimum and ee.foundation) that were created by OSGi. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 407 849 9117 mobile: +1 386 848 3788 "Kevin Riff" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/27/2006 10:30 AM Please respond to OSGi Developer Mail List To "OSGi Developer Mail List" cc Subject [osgi-dev] Where to download execution environments? Is there a repository somewhere for execution environment jars? I'm trying to locate EEs for PBP and Personal Profile but so far all I can find are the ee jars on the OSGi site. ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] About SCA and OSGi
> Is there where can I know what EEG recently will do? Check out http://bundles.osgi.org/EnterpriseWorkshop/HomePage BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 407 849 9117 mobile: +1 386 848 3788 "jerry lin" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/10/2006 10:51 PM Please respond to OSGi Developer Mail List To "OSGi Developer Mail List" cc Subject Re: [osgi-dev] About SCA and OSGi Yeah,David's work seems to great. I'm very expected SCA and EEG can match together to improve both,SCA have very excited features to apply in the enterprise application,and OSGi have very complete implemention that guide how to implement the Service-Oriented Component Model. Is there where can I know what EEG recently will do? 2006/10/11, David Savage <[EMAIL PROTECTED]>: > By way of a short advertisement for an open source implementation that > uses OSGi and SCA... > > Newton (http://newton.codecauldron.org) is an OSGi based framework > (which I'm involved in developing) that uses SCA as it's declaration > model. The SCA and OSGi models compliment each other well in this > environment IMHO. > > I'm certainly very interested in where the EEG and SCA will go in the > future. It is my understanding is that part of the EEG remit is to start > to look at how to expose OSGi services across remote interfaces. > > To throw another technology into the mix, we're using Jini for remote > communications (though we hide the complexity of Jini behind SCA > bindings to make developers lives as simple/POJO like as possible). > > In this respect I would also like to see convergence in EEG with the > high level patterns from the Jini world namely leasing and dynamic > discovery. > > We think that there are a lot of similarities between these high level > patterns and the SCA/EEG design. Though there are also some clashes at > the implementation level (LDAP attributes vs Entries, Jini preferred > class loading vs OSGi peer class loading). > > Hopefully as the Jini, SCA and EEG technologies evolve there will be > convergence between these patterns in the future... > > Advertisement over :) > > Regards, > > Dave. > > Peter Kriens wrote: > > What the EEG will do depends on its members ... > > > > I think there is a lot of excitement about SCA and OSGi. I also just > > read it and agree that it seems very complementary. But we need people > > that can drive the work. > > > > Kind regards, > > > > Peter Kriens > > > > jl> hi,everyone! > > > > jl> I have skimed SCA V 0.9 recently.On my point,I think SCA is > > jl> similar to the extend of OSGi in Enterprise Application,if really like > > jl> this,then what do EEG will do? > > > > > > > > > > The information transmitted is intended only for the person(s) or entity > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer. > > Paremus Limited. > 107-111 Fleet Street, London EC4A 2AB. Phone number +44 20 7936 9098 > > ___ > OSGi Developer Mail List > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev > -- = | BlueDavy | | MSN: [EMAIL PROTECTED]| = ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Case sensitivity of bundle symbolic names
They are case sensitive (like package names in Java). I will raise a bug on section 3.5.2 to be more clear on this. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Jeremy Volkman" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/28/2006 11:08 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] Case sensitivity of bundle symbolic names Are bundle symbolic names compared case-sensitive or case-insensitive? Section 3.5.2 (Bundle-SymbolicName) of the core specification does not appear to detail this, and I couldn't find it anywhere else. Thanks, Jeremy Volkman ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Some questions on OSGi and embedded devices
[EMAIL PROTECTED] wrote on 09/22/2006 01:46:17 PM: > Hi there, > I got some questions from a big customer and would like to ask them > here, since I don't really know the answers: > > - in order to implement MIDP3, is it a prerequisite to have OSGi, CDC > and JSR232 supported? No. MIDP3 is orthoginal to OSGi and JSR 232. It should be possible to implement MIDP3 with OSGi/JSR 232. > > - Is it possible to support OSGi on top of KVM, which is, does OSGi > demand the Java reflection system? By KVM, I assume you mean a CLDC VM? OSGi requires classloader support and some reflection. OSGi could be implemented on CLDC *IF* there was someone for the implementation to define and use class loaders and reflection. This does not need to be through the java.* API but could be some VM specific API. So the VM would have to provide that API and the framework impl would need to use that API. > > - Is there a way to support CLDC on top of CLC in order to support > both profiles with the same JMV/Code? Well CDC is a superset of CLDC. So you are already done. > > - Is there something like OSGi for C in order to handle dynamic dll > loading (in case the dynamics themselves are already solved, it's more > about dependency resolution and meta data between dlls/bundles) > A lot of the features of OSGi are based upon Java capabilities like dynamic class loading and unloading. None of the this exists in any standard way in native code. It would all have to be invented for each native platform assuming the native linker/loader even supported it. > > Cheers > > /peter > > > P.S. Thanks for a very nice OSGi Enterprise Workshop! > ___ > osgi-dev mailing list > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Strange question...
Besides how much legacy code is there really in the default package? I cannot imagine that there is much at all since it is an open ended package without any name. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Richard S. Hall" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/14/2006 05:33 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To OSGi Developer Mail List <[EMAIL PROTECTED]> cc Subject Re: [osgi-dev] Strange question... John Wells wrote: > But being able to handle legacy code *does* seem like a good enough > reason to "bloat" the framework a little. This can't possibly be much > "bloat" and the use case of legacy code is compelling IMO. > Not that I don't understand, because I do. But making the OSGi framework support every ugly thing that every legacy application has ever done is not good in my book. We have used this reason to introduce some of the many things already in OSGi, some of which I think are quite ugly...there is no end to this path, we can always find another legacy issue that cannot be done. Where do we draw the line? Everyone feels that their legacy ugliness isn't so ugly. :-) -> richard > > John Wells (Aziz) > [EMAIL PROTECTED] > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard S. > Hall > Sent: Thursday, September 14, 2006 12:18 PM > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] Strange question... > > Thomas Watson wrote: > >> As far as being able to distiguish between the different default >> packages ... is this not the same issue as having muliple versions of >> a normal package? You need to use matching attributes to distinguish >> the different packages >> > > No, this is not the same at all. Different versions have some > chronological relationship and are potentially substitutable for each > other. This is not the case at all for the default package. > > However, I agree that you could concoct a scheme that forced people to > use BSN and version with "." and that would probably work, but would be > totally brittle and doesn't seem like a good reason to further bloat the > framework. > > -> richard > >> For example: >> >> Export-Package: .;legacy-lib-name="abc";version="1.0" >> >> Export-Package: .;legacy-lib-name="xyz";version="1.0" >> >> Import-Package: .;legacy-lib-name="abc";version="1.0" >> >> Import-Package: .;legacy-lib-name="xyz";version="1.0" >> >> This allows you to pick the default package from either the abc or xyz >> > > >> legacy library. >> >> Tom >> >> >>> Can't do it. >>> >>> There is no way to express the default package in OSGi...the main >>> >> reason >> >>> is there would be no way to distinguish one bundle's default package >>> > > >>> with another's. And you couldn't just combine them all, since this >>> >> would >> >>> lead to naming conflicts. >>> >>> -> richard >>> >>> John Wells wrote: >>> >>>> How do I export the "root" package? In otherwords, a package with >>>> > > >>>> no name. I know, I know, it isn't too smart... but I'm dealing >>>> with >>>> >> legacy >> >>>> code here... >>>> >>>> Any idea? >>>> >>>> John Wells (Aziz) >>>> [EMAIL PROTECTED] >>>> >>>> >>>>>> Register now for BEA World 2006 --- See >>>>>> >> http://www.bea.com/beaworld<< >> >>>>>> >>>>>> >> __ >> _ >> >>>> Notice: This email message, together with any attachments, may >>>> >> contain >> >>>> information of BEA Systems, Inc., its subsidiaries and >>>> >> affiliated >> >>>> entities, that may be confidential, proprietary, copyrighted >>>> >> and/or >> >>>> legally privileged, and is intended solely for the use of the >>>> >> individual >> >>>>
[osgi-dev] Re; OSGi and Security
[Moved from equinox-dev] What you seem to be asking for is a negative permission: a bundle can't register a Foo service (but can register other services). The java permission model does not support negative permissions. While you could use conditions to guard a set of ServicePermissions to give SerivcePermission[Foo,REGISTER] permission to the special bundles, you can't "take it away" from the other bundles. You would have to give the other bundles the complement of SerivcePermission[Foo,REGISTER] which is a really an unbounded set of ServicePermissions. We had a lot of discussions about negative permissions in OSGi during R4 development. At the time, it was decided that it was a difficult subject and very different that the java permission model and we chose to avoid it. This is not to say it could not be looked at for R5. It would require a nomenclature to specify the negative permissions and special permission collections to negate the implies result of the union of the implies of the collected permissions. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ----- Forwarded by BJ Hargrave/Austin/IBM on 09/13/2006 10:21 AM - "John Wells" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/29/2006 01:22 PM Please respond to Equinox development mailing list <[EMAIL PROTECTED]> To "Equinox development mailing list" <[EMAIL PROTECTED]> cc Subject [equinox-dev] OSGi and Security I want to allow only specific bundles to offer particular services. For example, suppose I have a service "com.acme.Foo" that I want to be sure is only available from one of three particular signed bundles. How can I do this with the OSGi Security (either Conditional (chapter 9) or not (chapter 10))? The trouble with this, of course, is that I want all other bundles to be allowed to REGISTER any other services without having any knowledge of what those services might be beforehand (and without having to force them to explicitly allow for any service they might want to offer in their security files). So, the question is whether or not I can somehow set up a condition that allows me to specify that particular services can only come from particular bundles without having to then explicitly allow specific services from all other bundles. Thanks in advance for your help! John Wells (Aziz) [EMAIL PROTECTED] ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ equinox-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Inserting Properties at runtime
Ask Richard Hall :-) I am sure he can provide some use cases. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Kevin Riff" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/05/2006 04:14 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To "OSGi Developer Mail List" <[EMAIL PROTECTED]> cc Subject Re: [osgi-dev] Inserting Properties at runtime I’m curious, Tom. What is the use case for running multiple frameworks in the same VM? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Watson Sent: September 5, 2006 3:59 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Inserting Properties at runtime This will lead to issues when you run in an environment where there is more than one OSGi framework running in the VM at the same time. In this environment some framework implementations will have instance specific properties for BundleContext properties. I know Equinox does this when running multiple frameworks in the same VM and I think Felix does the same thing. In this case you may not see the system property changes in the BundleContext properties because they only represent the properties for the specific instance of the framework while the System properties represent global properties for the whole VM environment. If you can live with the property being global to the whole VM then you should get the property using the System.getProperty instead of BundleContext.getProperty. Another option would be to request OSGi add a BundleContext.setProperty method. This way we can set the instance specific framework properties in the case where multiple Frameworks are running in the same VM. Tom Andrew Eberbach/Durham/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/05/2006 02:17 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To OSGi Developer Mail List <[EMAIL PROTECTED]> cc Subject Re: [osgi-dev] Inserting Properties at runtime Well, I managed to find the answer myself. I didn't realize that even after startup you can do a System.setProperty() and the Context will pick it up. I'm not sure if this is 100% pure, but it works in my environment (equinox) so that's all I need. Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] Andrew Eberbach/Durham/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/05/2006 02:21 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject [osgi-dev] Inserting Properties at runtime Hi, Is it possible to set a property without using ConfigurationAdmin? What I'm trying to do is insert one property during my bundle's startup so that other bundles can see it. Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ]
One _expression_ but it can be a compound _expression_. For example:(&(foo=bar)(xyz>=10)(|(vendor=osgi)(vendor=acme)))BJ HargraveSenior Technical Staff Member, IBMOSGi Fellow and CTO of the OSGi Alliance[EMAIL PROTECTED]Office: +1 407 849 9117 Mobile: +1 386 848 3788 - Original Message - From: osgi-dev-bounces Sent: 08/20/2006 02:15 PM To: OSGi Developer Mail List" <[EMAIL PROTECTED]> Subject: Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ] Just a confirmation, please.In Bundle-NativeCode, the 'selection-filter' can contain one and only one _expression_ to validate, right ?-- ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ]
It is quite possible we forgot to add it to the Contants class. Why don't you open a bug on the bundles.osgi.org bugzilla system so we can add it in the next release?BJ HargraveSenior Technical Staff Member, IBMOSGi Fellow and CTO of the OSGi Alliance[EMAIL PROTECTED]Office: +1 407 849 9117 Mobile: +1 386 848 3788 - Original Message - From: osgi-dev-bounces Sent: 08/20/2006 01:26 PM To: OSGi Developer Mail List" <[EMAIL PROTECTED]> Subject: Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ] Another one, regarding framework constants for bundle header parsing.The Bundle-NativeCode is composed of native clauses.Each native clause indicates osname(s), processor(s), etc. and selection-filter(s). But R4 Spec org.osgi.framework.Constants does not have a constant named like BUNDLE_NATIVECODE_XXX corresponding to this 'selection-filter' section.Is this a error or is my reflexion wrong ?-- ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ]
Each word is an alias. So powerpc has power and ppc as aliases. Same for x86. Each is an alias. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Arnaud Quiblier" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/20/2006 01:52 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To "OSGi Developer Mail List" <[EMAIL PROTECTED]> cc Subject Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ] Another litle related question, concerning alias provided for org.osgi.framework.processor (R4, pp.90-91) Does PowerPC has one alias as 'power ppc' or two as 'power' & 'ppc' Idem for x86 : 'pentium', 'i386', 'i486', 'i586' & 'i686' are all aliases, I suppose ... -- ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ]
Bundle-NativeCode manifest header 1) They are necessary in so far as clauses without them can not be selected. However from a grammar point of view they are not mandatory. 2) Since they are not mandatory in the grammar, we do not need to make the grammar more complicated :-) Algorithm OK. Lets break down the paragraph: > If a selection filter is evaluated and its syntax is invalid, then the bundle > installation must fail with a Bundle Exception. The framework evaluates the selection filters only if the other values match. That is the osname, processor, etc. When the framework evaluates the selection filter and an invalid syntax error occurs, then the installation of the bundle fails. > If a selection filter is not >evaluated (it may be in a native code clause where the osname or processor >does not match), then the invalid filter must not cause the bundle installation >to fail. If some other value failed to match and the clause will not be selected anyway, the framework does not need to evaluate the selection filter and is therefore not obligated to validate the syntax of the selection filter. This is just trying to avoid work. > This is also true even if the optional clause is specified. The optional clause means that it is OK for no native code clause to be selected by the algorithm. So this sentence means this paragraph applies regardless of the presence of the optional clause. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Arnaud Quiblier" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/11/2006 08:51 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject [osgi-dev] R4 Core Spec : Loading Native Code Libraries [ 3.9 ] Dear all, Here are my comments and questions concerning the chapter 3.9 (pp. 59-63) of the OSGi Core Specification Release 4. *) Bundle-NativeCode manifest header syntax (p. 60) I would like to be totally sure to correctly understand the syntax of the 'nativecode' element of this header. This element is composed of one or more 'path' element and one or more 'parameter' element. One ore more 'parameter' implies that one at least of the architected attributes is mandatory. Reading further the section 3.9.1 (p. 62) describing the native code algorithm, the first step of the process seems to imply that 'osname' and 'processor' are both required in a native clause. Indeed, the other parameters can be not specified, but those can't. Question(s) 1/ The two parameters 'osname' and 'processor' are mandatory. Does anybody can tell me whether it's right ? 2/ If so, perhaps the mandatory aspect of those two parameters could be explicitly written p.60 and the order of the parameter's presentation be changed to reflect this importance. *) Native Code Algorithm (p. 62) Perhaps I'm stupid. But I do NOT understand the last but one paragraph. It begins with "If a selection filter .." and ends with "... optional clause is specified.". The paragraph before is absolutly clear, but this one exceeds my capacities. Plz help ! Regards, -- ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Service Registration
>From your example, it seems that 2 bundles have a copy of the same
classfile. However each bundle's classloader will load its copy of the
classfile resulting in 2 distinct classes in the VM. They both have the
same name but they are different Class objects because the tuple (class
name, class loader) is different.
So when each bundle registers an object of its class as a service, you end
up with 2 service registrations. Each service will be registered under the
same class name but the service objects are not class compatible (see
paragraph above).
Now let assume each bundle exported the package containing MyClass (the
class of the service). Then if a 3rd bundle imported that package, it
would be wired to only one of the orginal 2 bundles. So when the 3rd
bundle does a service lookup (BundleContext.getServiceReference), it will
find the service registered by the bundle to which its import is wired. If
the 3rd bundle calls BundleContext.getAllServiceReferences it will see
both services, since that method does include package wiring in its
constraints.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"joe antony lawrence david" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/08/2006 03:46 AM
Please respond to
OSGi Developer Mail List <[EMAIL PROTECTED]>
To
[EMAIL PROTECTED]
cc
Subject
[osgi-dev] Service Registration
Hi everybody!
Greetings!
I have a doubt with service registration in OSGi R4. Can two diff
bundles register two similar services, meaning with the same classname and
properties, but with a different service impl object.
For e.g.,
Class MyClass implements BundleActivator
{
pulic void start()
{
// construct a map with a property holding this classname.
sReg = bundlecontext.registerService(this.getClass ().getName(),
this, map);
}
public void stop()
{
sReg.unregister();
}
}
Now, can I have the same class as part of two of my bundles, install
and start them sucessfully. Will two services be registered in the
framework under the same classname?
Please note that the package in which this class resides is the same in
both the bundles.
--
Cheers
Joe
Visit my blog at http://djlolly.blogspot.com
* Believing in yourself is an endless destination;
But, believing your have failed is the end of the journey.
* A pound a fret cant pay an ounce a debt.
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] how to add package
Do you have that package exported by some project in your workspace that your project is connected to? Since this is an Eclipse question and not an OSGi question, you may want to ask in one of the Eclipse newsgroups. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "karthik ananth" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/31/2006 07:43 PM Please respond to OSGi Developer Mail List <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject [osgi-dev] how to add package My eclipse is giving error if i import org.osgi.framework, plz anyone help out to resolve this... i am ew to this and don have time to explore. thanks in advance -- akarthik ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Tracking count of ServiceTracker
701.8.2.14 is out of date. The tracking count is modified when a tracked service is modified. This is necessary because the service ranking could change which results in a different service being returned by getService. I will clarify the javadoc which will be published in a future update. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Ikuo Yamasaki <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/20/2006 11:46 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] Tracking count of ServiceTracker Hi, I have questions on ServiceTracker: Q. Should "tracking count" of ServiceTracker be incremented when a service to be tracked is MODIFIED ? While the section 701.3 of spec R4 seems to tell that it should be, the section 701.8.2.14 says it should be only for ADDED and REMOVED. - NTT Cyber Solutions Laboratories Ikuo YAMASAKI E-mail: [EMAIL PROTECTED] TEL +81-46-859-8537 FAX +81-46-855-1282 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] using ecore in an equinox runtime
I think you want the equinox-dev list. This is the osgi-dev list which a general OSGi technical discussion list. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 David Kemper <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/17/2006 07:47 PM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] using ecore in an equinox runtime I'm trying to use ecore in an Equinox OSGi environment. I'll try first to state the problem and the symptoms without going deep into details, and provide any additional info in any follow-ups. I am installing a fairly large set of required bundles...about a hundred. This is the result of analyzing all the bundle dependencies of my client bundle. My client bundle has a dependency on the org.eclipse.emf.ecore, and all of the hundred bundles that I install get resolved, including my client bundle. I explicitly start my client bundle. When I try to use ecore as a result of my client bundle activator, I get a class not found error on org.eclipse.em.ecore.EObject, which is in the ecore bundle. Now here's the rub: If I explicitly start the org.eclipse.equinox.common bundle before I start my client bundle, my code works. My underlying question is: How do I know what bundles need to be explicitly started in any given configuration? In other words, what makes org.eclipse.equinox.common special in that I need to explicitly start it? In my mental OSGi model, a bundle that has an activator will be started by the framework when its code gets referenced for the first time (barring explicit calls using the bundle context). Is this in error? Are there other bundles that I need to start explicitly, even though their code gets referenced? If so, how do I know? I'm wondering if there is a set of equinox bundles that I really should start in my runtime to get a properly functional OSGi runtime (Current the only such bundle is the org.eclipse.osgi framework bundle, which gets started implicitly, as it is the framework bundle). As always, thanks for any pointers, or for sending me to a more appropriate list... /djk ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] osgi-dev Digest, Vol 7, Issue 4
Thanks. However too late for the spec refresh since it went final on
Friday :-( But when the refresh is published, we will list it as an
erratum.
Also, you can file bug reports such as these using the OSGi external
bugzilla system: http://bundles.osgi.org/bugzilla/
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Michaël OULLION <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/17/2006 08:51 AM
Please respond to
[EMAIL PROTECTED]; Please respond to
OSGi Developer Mail List
To
osgi-dev@bundles.osgi.org
cc
Subject
Re: [osgi-dev] osgi-dev Digest, Vol 7, Issue 4
Hi,
just an another little error in the OSGi R4 compendium.
In Event Handler 113.4, the definition is :
topic-scope ::= '*' | ( topic [ '/*'] ) so that is to say the last token
of the topic name must be a '\*' because [...] define a set ( one of ...)
the right definition should be :
topic-scope ::= '*' | ( topic [ '/*']? )
Regards,
Oullion michael
> Message du 14/07/06 à 18h00
> De : [EMAIL PROTECTED]
> A : osgi-dev@bundles.osgi.org
> Copie à :
> Objet : osgi-dev Digest, Vol 7, Issue 4
>
> Send osgi-dev mailing list submissions to
> osgi-dev@bundles.osgi.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://bundles.osgi.org/mailman/listinfo/osgi-dev
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of osgi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Questions about Event and topics (BJ Hargrave)
>
>
> --
>
> Message: 1
> Date: Fri, 14 Jul 2006 11:39:03 -0400
> From: BJ Hargrave
> Subject: Re: [osgi-dev] Questions about Event and topics
> To: OSGi Developer Mail List
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
>
> 1) Good catch and just in time!
>
> We are just finalizing a refresh of the R4 specs to collect up the
errata
> and have added this to the list of fixes.
>
> The token production will be changed to:
>
> token ::= ( alphanum | ?_? | ?-? )+
>
> The Event.validateToken method will be fixed to accept this grammar. The
> method was originally written to the R3 token grammar. Late in the R4
> cycle we updated the token grammar in the spec but missed the + and also
> the code in Event.
>
> 2) foo/bar/* will match foo/bar/xyz but will not match foo/bar or
> foo/barbar. It will match any topic that startsWith("foo/bar/").
>
> If you want your handler to match foo/bar and foo/bar/*, then set both
> topics in the event.topics property: new String[] {"foo/bar",
"foo/bar/*"}
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> [EMAIL PROTECTED]
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> Micha?l OULLION
> Sent by: [EMAIL PROTECTED]
> 07/11/2006 04:11 AM
> Please respond to
> [EMAIL PROTECTED]; Please respond to
> OSGi Developer Mail List
>
>
> To
> osgi-dev@bundles.osgi.org
> cc
>
> Subject
> [osgi-dev] Questions about Event and topics
>
>
>
>
>
>
> Hi,
> I already try to send the first question but my subscribtion on the
> mailling list failed so i can't if they are somes responses. Sorry for
the
> spam.
> First Question : I'm working on Event in OSGi and i found some
differences
> between OSGi R4 specification and org.osgi.compendium.
> In OSGI R4 , a topic is defined by : topic ::= token ( ' / ' token ) *
> (see Topics 113.3.1 OSGi Compendium)
> and a token is : token ::= ( alphanum | ?_? | ?-? )* and alphanum ::=
> alpha | digit and digit ::= [0..9] and alpha ::= [a..zA..Z]
> (see General Syntax Definitions 1.4.2 OSGi Core)
> So, we can have a topic with an empty name (due to the * operator in
> token's definition ) or a topic begins with '-' or '_' or a digit.
> But, in the org.osgi.event.Event code, the validateToken() method is
used
> to validate a topic. This method invalidate all topics beginning with
'_'
> or '-' or a digit and also invalidate topics with empty name.
> Is it an error ? What "definition" must i respect??? OSGi R4 spec or
> org.osgi.event.Event ???
> Second question : in Topics handler, when you configure your handler
with
> "foo/bar/* ", will you r
Re: [osgi-dev] Questions about Event and topics
1) Good catch and just in time!
We are just finalizing a refresh of the R4 specs to collect up the errata
and have added this to the list of fixes.
The token production will be changed to:
token ::= ( alphanum | ’_’ | ’-’ )+
The Event.validateToken method will be fixed to accept this grammar. The
method was originally written to the R3 token grammar. Late in the R4
cycle we updated the token grammar in the spec but missed the + and also
the code in Event.
2) foo/bar/* will match foo/bar/xyz but will not match foo/bar or
foo/barbar. It will match any topic that startsWith("foo/bar/").
If you want your handler to match foo/bar and foo/bar/*, then set both
topics in the event.topics property: new String[] {"foo/bar", "foo/bar/*"}
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Michaël OULLION <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/11/2006 04:11 AM
Please respond to
[EMAIL PROTECTED]; Please respond to
OSGi Developer Mail List
To
osgi-dev@bundles.osgi.org
cc
Subject
[osgi-dev] Questions about Event and topics
Hi,
I already try to send the first question but my subscribtion on the
mailling list failed so i can't if they are somes responses. Sorry for the
spam.
First Question : I'm working on Event in OSGi and i found some differences
between OSGi R4 specification and org.osgi.compendium.
In OSGI R4 , a topic is defined by : topic ::= token ( ' / ' token ) *
(see Topics 113.3.1 OSGi Compendium)
and a token is : token ::= ( alphanum | ’_’ | ’-’ )* and alphanum ::=
alpha | digit and digit ::= [0..9] and alpha ::= [a..zA..Z]
(see General Syntax Definitions 1.4.2 OSGi Core)
So, we can have a topic with an empty name (due to the * operator in
token's definition ) or a topic begins with '-' or '_' or a digit.
But, in the org.osgi.event.Event code, the validateToken() method is used
to validate a topic. This method invalidate all topics beginning with '_'
or '-' or a digit and also invalidate topics with empty name.
Is it an error ? What "definition" must i respect??? OSGi R4 spec or
org.osgi.event.Event ???
Second question : in Topics handler, when you configure your handler with
"foo/bar/* ", will you receive the event propagate on foo/bar???
Regards,
Oullion Michael,
Student in Adele Team, LSR laboratory, France
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Can classpath have parameters
There are no parameters defined by the OSGi R4 spec. We merely left "space" for defining parameters in the future. In early spec drafts, there was a proposal to allow a selection filter to include/exclude bundle classpath entries (like selection-filter in Bundle-NativeCode) but that was dropped since the same goal could be achieved via fragments. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 kiran bharadwaj <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/29/2006 04:34 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] Can classpath have parameters Hello All, OSGi bundleclasspath manifest header according to syntax is having parameters. What parameters are allowed here? Also what is the use of the parameters. Can the parameters include version also? Cheers, Kiran Bharadwaj Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Conditional Permissions
[EMAIL PROTECTED] wrote on 06/25/2006 12:37:41 AM:
> Hi all,
>
>I am having a doubt regarding the Conditional Permissions!
>
> 1. What is the set of Basic permissions assigned to a bundle at the
> time of its installation?
It is the union of all permission guarded by Conditions which evaluate to
true for the subject bundle. Note, a permission set can be added to
conditional permission admin which are not guarded. Thus, these
permissions apply to all bundles.
>
> 2. Is there any way to find the set of actual permissions assigned
> to the bundle or to be assigned to the bundle from the
> ConditionalPermissionAdmin? getConditionalPermissionInfos()
> enumerates the complete list. is there any way to retrieve the
> permissions related to a specific bundle?
>
You can call getProtectionDomain on the Class object of a class loaded
from the subject bundle. Then enumerate the permission in the protection
domain. However, the enumeration may not include permissions guarded by
mutable or postponed evalutation conditions since those conditions must be
evaluated at the time of a permission check.
> 3. What happens when a permission is set in one tuple and revoked
> in another tuple?
Permissions cannot be revoked. The Java 2 permission model really only
supports additive permissions.
> Say for example, there is a tuple { [BundleLocationCondition
> "*mylocation*"] (ServicePermission "MyClass" "*") }
> and there is also another tuple { [BundleLocationCondition
> "*mylocation*"] (ServicePermission "MyClass" "GET") }
>
> According to the first tuple, the bundles satisfying the
> locationcondition should be allowed to get and register services of
> type MyClass. But according to the second tuple, bundles satisfyingt
> he condition shouldnot be allowed to register a service of type
> MyClass. What is the actual permissions for the bundle that
> satisfies the given locationcondition in this case?
In this example, it is the union of the permissions. So it is the union of
the actions "*" and "GET" which I would assume is "*".
>
> Cheers
> Joe
>
>
> --
>
>
> * Believing in yourself is an endless destination;
> But, believing your have failed is the end of the journey.
> * A pound a fret cant pay an ounce a debt.
> ___
> osgi-dev mailing list
> osgi-dev@bundles.osgi.org
> http://bundles.osgi.org/mailman/listinfo/osgi-dev
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Query on resolving
But a bundle does not need to be resolved at installation and probably shouldn't be. For example if you are installing an application consisting of several bundles, you will need to get all the bundles installed before you try to resolve any of them since they may have package dependencies amongst themselves. A framework implementation is free to resolve a bundle at any time after installation and before starting. The resolveBundles methods can be used to force a bundle or bundles to be resolved upon request. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 kiran bharadwaj <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/21/2006 12:30 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject Re: [osgi-dev] Query on resolving If a bundle is automatically getting resolved when it is installed, then no need arises for this method. I am not saying resolving while starting, but resolving while installing. If resolution happens at the time of installation itself then there is no need for explicit methods like resolveBundles(). I still didnt understand who is going to use this method. Regards, Kiran Bharadwaj Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] case of ServicePropety keys
[EMAIL PROTECTED] wrote on 06/20/2006 03:12:18 PM: > I would like to clarify one more point. > How about other keys assigned by the specification, which is determined > by not the framework but a bundle developer? (e.g. service.ranking, > service.vendor, ...) > > In other words, if a bundle registers with "Service.Ranking" as a key, > what should ServiceReference.getPropertyKeys() return? > "service.ranking" or "Service.Ranking". In this case it would be "Service.Ranking" since the framework did not set this key and the user was the performed the last set of the key. > > - > NTT Cyber Solutions Laboratories > > Ikuo YAMASAKI > E-mail: [EMAIL PROTECTED] > > > ___ > osgi-dev mailing list > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] case of ServicePropety keys
[EMAIL PROTECTED] wrote on 06/20/2006 02:29:12 PM:
> Hi,
>
> # I'm not sure if my questions should be posted on dev ml.
This is a fine question for this list. :-)
>
> The spec (r4.core.pdf) says "A Framework must return the key
> in ServiceReference.getPropertyKeys in exactly the same case as it was
last
> set."
>
> I have questions on it.
>
> In advance, imagin that a Dictionary object with a key of "Service.Id"
> and a value for it is specified at its service registration. According
> the spec, framework must keep not the value specified but one that
> framework sets for this key.
Right. So the framework will do:
properties.setProperty("service.id", newServiceId);
thus overwritting the user specified "Service.Id" key during
registerService.
>
> As far as I understand, ServiceReference.getPropertyKeys must return not
> Constants.SERVICE_ID="service.id" but "Service.Id".
No. You have it reversed. The last key set was done by the framework
during the processing of registerService and it used the value of
Constants.SERVICE_ID. The last set was done by the framework and not by
the user. The spec states that these keys will be overwritten by the
framework when registering a service.
>
> # The same thing can be said about OBJECTCLASS.
Yes. Since the framework sets the Constants.OBJECTCLASS key last, the case
of that key will be the case in Constants.
>
> Q1. Is my understanding correct ?
No. See above.
>
> Q2. Why did OSGi Alliance decide the spec as "A Framework must return
> the key in ServiceReference.getPropertyKeys in exactly the same case as
> it was last set." ? (why not decided as "return keys in lower case", at
> least for Constants.*** keys)
The service properties are case-preserving with case-insensitive lookup.
In hindsight, the expert group regrets that decision. We should have gone
case-sensitive. But it is too late to change now without risking breaking
backwards compatibility.
As we have created and will create new specification we have chosen and
will choose case-sensitive where possible.
>
> -
> NTT Cyber Solutions Laboratories
>
> Ikuo YAMASAKI
> E-mail: [EMAIL PROTECTED]
>
>
> ___
> osgi-dev mailing list
> osgi-dev@bundles.osgi.org
> http://bundles.osgi.org/mailman/listinfo/osgi-dev
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] General design of resource handling
bugzilla/ ? > > Don't get me wrong, I think the spec is great, I am just trying to > understand the reasons why it is the way it is. No problem. Appreciate the feedback. > > Mirko > > ___ > osgi-dev mailing list > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Declarative Services implementation guidelines?
Yes. Probably true.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Roy Paterson/Austin/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-05-11 03:24 PM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
I understand that we would use Proxy. My point (which you touch on) is
that it is not always valid to return an object who's behavior is to do
nothing when it's methods are called.
I would be worried that providing such a null object would lull the user
in
to thinking they have a valid object that will do what they expect, which
is false. Better to allow an exception to be thrown so they realize that
their code has to deal with this case.
Regards,
Roy
-
Roy Paterson
IBM Pervasive Computing
Austin, TX
Phone: (512) 838-8898
BJ
Hargrave/Austin/I
[EMAIL PROTECTED]
To
Sent by: OSGi Developer Mail List
osgi-dev-bounces@
bundles.osgi.org cc
Subject
05/11/2006 02:18 Re: [osgi-dev] Declarative Services
PMimplementation guidelines?
Please respond to
OSGi Developer
Mail List
<[EMAIL PROTECTED]
.osgi.org>
Well SCR could synthesize such an object using java.lang.reflect.Proxy.
But the user of such an object may themselve fail if they call a method on
it which does not return some expected object. So null object is not a
universal solution. It just avoid the need for the null check in your
code.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Roy Paterson/Austin/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-05-11 02:25 PM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
How could SCR generically implement a null object? In the case of
logservice it makes sense to have the methods not do anything and return
null, but I don't think that is universally valid for all interfaces.
-
Roy Paterson
IBM Pervasive Computing
Austin, TX
Phone: (512) 838-8898
BJ
Hargrave/Austin/I
[EMAIL PROTECTED]
To
Sent by: OSGi Developer Mail List
osgi-dev-bounces@
bundles.osgi.org cc
Subject
05/11/2006 12:25 Re: [osgi-dev] Declarative Services
PMimplementation guidelines?
Please respond to
OSGi Developer
Mail List
<[EMAIL PROTECTED]
.osgi.org>
Yes. I dont think SCR could bind these null objects by default. The
component itself would have to chose to do this in its unbind method.
However, an option could be added to SCR, where the programmer, could
request null objects when otherwise unbound. Assuming the service is
referenced via an interface, then a null object can be synthesized via a
dynamic proxy.
If some feels this is interesting, please open a bug on the
bundles.osgi.org bugzilla system to request this feature.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Kevin Riff" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 12:56 PM
Please respond to
OSGi Developer Mail List
To
"OSGi Developer Mail List"
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Would that be legal? If no service is available the SCR should be
binding that reference to null so that the component knows that it's
unbound. It might be able to make alternate arrangements, like sending
log messages to System.out instead. But if you give it a "null" object,
then it won't know that its logging messages are being discarded.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave
Sent: Thursday, May 11, 2006 10:35 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Declarative Services implementation guidelines?
So by null object, you mean an object wh
Re: [osgi-dev] Declarative Services implementation guidelines?
Well SCR could synthesize such an object using java.lang.reflect.Proxy.
But the user of such an object may themselve fail if they call a method on
it which does not return some expected object. So null object is not a
universal solution. It just avoid the need for the null check in your
code.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Roy Paterson/Austin/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-05-11 02:25 PM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
How could SCR generically implement a null object? In the case of
logservice it makes sense to have the methods not do anything and return
null, but I don't think that is universally valid for all interfaces.
-
Roy Paterson
IBM Pervasive Computing
Austin, TX
Phone: (512) 838-8898
BJ
Hargrave/Austin/I
[EMAIL PROTECTED]
To
Sent by: OSGi Developer Mail List
osgi-dev-bounces@
bundles.osgi.org cc
Subject
05/11/2006 12:25 Re: [osgi-dev] Declarative Services
PMimplementation guidelines?
Please respond to
OSGi Developer
Mail List
<[EMAIL PROTECTED]
.osgi.org>
Yes. I dont think SCR could bind these null objects by default. The
component itself would have to chose to do this in its unbind method.
However, an option could be added to SCR, where the programmer, could
request null objects when otherwise unbound. Assuming the service is
referenced via an interface, then a null object can be synthesized via a
dynamic proxy.
If some feels this is interesting, please open a bug on the
bundles.osgi.org bugzilla system to request this feature.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Kevin Riff" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 12:56 PM
Please respond to
OSGi Developer Mail List
To
"OSGi Developer Mail List"
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Would that be legal? If no service is available the SCR should be
binding that reference to null so that the component knows that it's
unbound. It might be able to make alternate arrangements, like sending
log messages to System.out instead. But if you give it a "null" object,
then it won't know that its logging messages are being discarded.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave
Sent: Thursday, May 11, 2006 10:35 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Declarative Services implementation guidelines?
So by null object, you mean an object which implements the LogService
interface but whose methods are no-ops?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Marcel Offermans <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 10:16 AM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Kevin Riff wrote:
>Copying to a local variable first would also work, but only if the log
>field is volatile. Otherwise you risk having your threads see a stale
>copy of that field.
>
>
>-Original Message-
>// ...
>if(log != null) {
>log.log(LogService.INFO, "Did something");
>}
>// ...
>
>
In the dependency manager I've used the null object pattern to make this
a bit easier for the user. Instead of "nulling" the field when the
service is not available, I create a null object so you don't have to
check for null everywhere. Of course you should use this combined with
the volatile keyword, like Kevin suggested.
The null object implementation I've used should be pretty easy to re-use
(even if you don't use the dependency manager).
Greetings, Marcel
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
Re: [osgi-dev] Declarative Services implementation guidelines?
Yes. I dont think SCR could bind these null objects by default. The
component itself would have to chose to do this in its unbind method.
However, an option could be added to SCR, where the programmer, could
request null objects when otherwise unbound. Assuming the service is
referenced via an interface, then a null object can be synthesized via a
dynamic proxy.
If some feels this is interesting, please open a bug on the
bundles.osgi.org bugzilla system to request this feature.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Kevin Riff" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 12:56 PM
Please respond to
OSGi Developer Mail List
To
"OSGi Developer Mail List"
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Would that be legal? If no service is available the SCR should be
binding that reference to null so that the component knows that it's
unbound. It might be able to make alternate arrangements, like sending
log messages to System.out instead. But if you give it a "null" object,
then it won't know that its logging messages are being discarded.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave
Sent: Thursday, May 11, 2006 10:35 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Declarative Services implementation guidelines?
So by null object, you mean an object which implements the LogService
interface but whose methods are no-ops?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Marcel Offermans <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 10:16 AM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Kevin Riff wrote:
>Copying to a local variable first would also work, but only if the log
>field is volatile. Otherwise you risk having your threads see a stale
>copy of that field.
>
>
>-Original Message-
>// ...
>if(log != null) {
>log.log(LogService.INFO, "Did something");
>}
>// ...
>
>
In the dependency manager I've used the null object pattern to make this
a bit easier for the user. Instead of "nulling" the field when the
service is not available, I create a null object so you don't have to
check for null everywhere. Of course you should use this combined with
the volatile keyword, like Kevin suggested.
The null object implementation I've used should be pretty easy to re-use
(even if you don't use the dependency manager).
Greetings, Marcel
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Declarative Services implementation guidelines?
So by null object, you mean an object which implements the LogService
interface but whose methods are no-ops?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Marcel Offermans <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
2006-05-11 10:16 AM
Please respond to
OSGi Developer Mail List
To
OSGi Developer Mail List
cc
Subject
Re: [osgi-dev] Declarative Services implementation guidelines?
Kevin Riff wrote:
>Copying to a local variable first would also work, but only if the log
>field is volatile. Otherwise you risk having your threads see a stale
>copy of that field.
>
>
>-Original Message-
>// ...
>if(log != null) {
>log.log(LogService.INFO, "Did something");
>}
>// ...
>
>
In the dependency manager I've used the null object pattern to make this
a bit easier for the user. Instead of "nulling" the field when the
service is not available, I create a null object so you don't have to
check for null everywhere. Of course you should use this combined with
the volatile keyword, like Kevin suggested.
The null object implementation I've used should be pretty easy to re-use
(even if you don't use the dependency manager).
Greetings, Marcel
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Declarative Services implementation guidelines?
[EMAIL PROTECTED] wrote on 2006-05-11 04:31:41 AM:
> Hi,
>
> I'm looking for some guidelines on the correct way to implement
> thread-safe Declarative Services components. In particular I'm unclear
> regarding which methods I need to make synchronized. Suppose I have a
> component with an optional dependency on the LogService. The component
> code looks something like this:
>
> public class LoggingComponent {
> private LogService log;
>
> protected void bindLog(LogService log) { this.log = log; }
> protected void unbindLog(LogService log) { this.log = null; }
>
> public void doSomething() {
> // ...
> if(log != null) {
> log.log(LogService.INFO, "Did something");
> }
> // ...
> }
> }
Is the reference to the log service static or dynamic? If static, then you
do not have to really worry since the bindLog and unbindLog methods will
be called before activate and after deactivate. If dynamic, then the
bindLog/unbindLog methods can be called from any thread while you are
running. So you will need to properly protect access the log field.
Probably the simplest thing to do is make log volatile and copy to a local
variable before using.
>
> I assume that it is possible for unbindLog() to be called between the
> null check and the usage of log, so does this mean that I need to make
> all of these methods synchronized? Alternatively, can I copy the log
> field to a local variable, ie:
>
> LogService localLog = log;
> if(localLog != null) {
> localLog.log(LogService.INFO, "Did something");
> }
>
> Would that always work, or is it possible that the localLog reference
> would become stale before I use it?
In a fully dynamic system like OSGi, there is a chance that the log
service reference by localLog could be unregistered before using it.
Thread 1Thread 2
localLog = log;
//thread switch
// log service unregistration
begins
// SCR receives unregistration
event
// unbindLog is called
this.log = null;
// log service unregistation
complete
// At this point localLog refers to a
// log service object which has been unregistered
// Its behavior is undefined
localLog.log(...)
// result could be a noop or an exception
If you make bindLog, unbindLog and doSomething all synchronized, then
thread 2 will block trying to call unbindLog since thread 1 is executing
in doSomething which holds the monitor. Assuming the log(...) method
doesn't need thread 2 or any monitor currently held by thread 2, the
synchronized added to your methods will stall the unregistration of the
log service while you are using it. The risk is a deadlock if the service
methods you call need something which is owned by thread 2.
>
> Many thanks,
> Neil
> _______
> osgi-dev mailing list
> osgi-dev@bundles.osgi.org
> http://bundles.osgi.org/mailman/listinfo/osgi-dev
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
___
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Export-Service deprecated?
In general, bundles shouldn't be starting or stopping other bundles. That is the job of the management agent. With regard to the Export-Service/Import-Service manifest headers, these header were never meaningful at runtime since a bundle does not have to register any service during the execution of its BundleActivator. A bundle cen register and unregister a service at any time and for any reason (as long as it is started). So these header were of dubious value. Some people used them as hint to the management system to say if bundle A says Import-Service: FooService then I better install a bundle which says Export-Service: FooService. This is only generally interesting for the reasons described above. I guess the prefered thing now is Declarative Services (DS). The metadata for DS is more meaningful than the Export-Service/Import-Service manifest headers. And SCR (the DS runtime) will process that and connect services together. DS does require the bundles to be started, but since DS does not require the bundles to have a BundleActivator, then cost of starting a bundle with no BundleActivator is the same as resolving it: that is no class loader needs to be created until SCR needs to load a class from the bundle. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Andrew Eberbach/Durham/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2006-05-01 03:07 PM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] Export-Service deprecated? Hi, I'm trying to figure out why the Export-Service field is deprecated in R4. The reason I'm using it is because I want to be able to find a specific service in the current list of available bundles and start it. The catch is that the bundle that exports the service (or claims to export the service) might not be started yet. From what I understand the service registry only gets update when someone calls registerService as part of their bundle.. which implies the bundle has been started. Am I missing something? Should I be approaching this another way? Or is the "preferred" approach giving the user a list of bundles and telling them to pick the one they want to start? Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Question about Event Admin specification
I don't think event handlers are expected to be reentrant. So if event handler H subscribes to topic T and the event source fires event A on topic T and then event B on topic T: 1) H should called with A before it is called with B 2) (I think) H should return from the call with A before it is called with B. Otherwise H must be reentrant and may "see" B before A based upon thread scheduling. I don't think (2) is not spelled out in the spec but I believe this was the intent. Hopefully some of the others will chime in with an opionion here (Peter, Kevin? :-) BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Jeremy Volkman" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-04-25 02:53 PM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] Question about Event Admin specification I'm developing an Event Admin implementation that uses multiple threads to dispatch events. I have a question regarding the order if delivered events. An excerpt related to the question (from the compendium, section 113.7.2): "The Event Admin service can use more than one thread to deliver events. If it does then it must guarantee that each handler receives the events in the same order as the events were posted. This ensures that handlers see events in the expected order. For example, it would be an error to see a destroyed event before the corresponding created event." Say I have two events, A and B, both of which a particular EventHandler receives. If the EventHandler takes 5 seconds to handle event A (which it will receive before event B), can event B be delivered immediately after the EventHandler starts to handle event A, or should the delivery of event B be delayed for 5 seconds? Thanks, Jeremy ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] OSGi webinar
I just wanted to let folks know about an OSGi webinar to be held Thursday, April 27, 2006 9:30 AM-11:00 AM (GMT-05:00) Eastern Time (US & Canada). The details can be found at http://www.osgi.org/webinar.asp BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] split package version numbers
I guess this is a sad consequence of poor cohesion in the original package design. As Richard said, one choice would be to properly refactor into new package names and have the orginal package delegate to the new packages for existing code that does not/cannot be itself refactored to use the new package names. Given that will likely not happen, I think you will need to keep the version numbers of the package in sync so that any change to any portion of the split will uplevel the package version in every bundle. The reasoning is that logically there is only a single package that is physically split across multiple bundles. A bundle that gets the package from the aggregator bundle will see the complete package and any change in any split will be visible. A bundle that gets only a split of the package from one of the other bundles may see a version change even though nothing actually changed in the split, but that should be OK assuming the bundle does not use an overly restrictive version range on the import. Also, I think you should consider a different attribute design for the split org.eclipse.core.runtime (original bundle) Export-Package: org.eclipse.core.runtime; version=3.2; common=split; registry=split Require-Bundle: org.eclipse.equinox.common, org.eclipse.equinox.registry org.eclipse.equinox.common Export-Package: org.eclipse.core.runtime; version=3.2; common=split, mandatory:=common org.eclipse.equinox.registry Export-Package: org.eclipse.core.runtime; version=3.2; registry=split, mandatory:=registry This will allow the consuming bundle to be wired to either the aggregator or the split bundle and even provides the flexibilty to combine the splits in any way in the future should your needs change. (note the attribute value does not have to be "split", I just chose it for the example). BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-03-31 08:58 AM Please respond to OSGi Developer Mail List To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] split package version numbers In a thread on equinox-dev the following was said. Peter Kriens wrote on 03/31/2006 03:17:07 AM: > 2. If you have sloppy exported packages, you probably also have sloppy >virtual bundles. All bets are off. A package with the same version, >and same name MUST contain substitutable content. If you do not >accept this condition, then please skip :-) the remainder of this message; >package atomicity is one of the premises of OSGi modularity. This makes total sense. Tom and I were just the other day going over a case where we have a three-way split in a package because of some refactoring. We used to have org.eclipse.core.runtime 3.2.0 in one bundle but parts of that package got moved out into two other bundles (i.e., three-way split). For backwards compatibility we are using mandatory attributes as follows org.eclipse.core.runtime (original bundle) Export-Package: org.eclipse.core.runtime Require-Bundle: org.eclipse.equinox.common, org.eclipse.equinox.registry org.eclipse.equinox.common Export-Package: org.eclipse.core.runtime; split=common, mandatory:=split org.eclipse.equinox.registry Export-Package: org.eclipse.core.runtime; split=registry, mandatory:=split So the core.runtime bundle acts as an aggregator for the split package. Anyone who simply imports org.eclipse.core.runtime will get it from the core.runtime bundle. People wanting a specific package split can spec the "split" attribute. Ok, so now comes the question: how do we evolve the version numbers of the different splits. In effect what we have done is broken the org.eclipse.core.runtime package up into two sub packages (common and registry) which can be evolved and consumed independently. The one in the core.runtime bundle is then an aggregation of the others. It seems like the subpackages can evolve their version numbers at a rate appropriate to their change and the aggregator should then evolve its version number based on the change in the subpackages and changes to itself. So you could end up with different version numbers on all three package exports. On the surface this seems confusing but it actualy correctly captures what is happening and allows people to spec their dependencies accordingly. Thoughts? Jeff ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] OSGI for residential gateway
I did not tell anyone to shut up. Perhaps you should read more carefully. I said this list is a suitable place for such general OSGi discussions (to counter Richard who was under the impression this list was for OSGi spec issues only). But I also suggested that discussions which are specific to implementations are better asked in the implementation lists since that is where the implementors hang out. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Peter Kriens <[EMAIL PROTECTED]> 2006-03-25 01:12 AM To BJ Hargrave/Austin/[EMAIL PROTECTED] cc OSGi Developer Mail List Subject Re[2]: [osgi-dev] OSGI for residential gateway Finally some traffic and then you tell them to shut up? I think this is a general developers list and it is foolish to restrict access. The question is clearly not specific OSCAR but more general. If traffic becomes too heavy then we can split the list. Kind regards, Peter Kriens BH> This list is for discussing any OSGi technical topic including spec issues BH> and general programming for OSGi (i.e. bundle development). BH> Questions about specific OSGi implementations would be better asked in the BH> implementations' mail lists. BH> BJ Hargrave BH> Senior Technical Staff Member, IBM BH> OSGi Fellow and CTO of the OSGi Alliance BH> [EMAIL PROTECTED] BH> Office: +1 407 849 9117 Mobile: +1 386 848 3788 BH> "Richard S. Hall" <[EMAIL PROTECTED]> BH> Sent by: [EMAIL PROTECTED] BH> 2006-03-24 08:18 AM BH> Please respond to BH> OSGi Developer Mail List BH> To BH> Yann Dolbeau <[EMAIL PROTECTED]> BH> cc BH> OSGi Developer Mail List , cavel alexis BH> <[EMAIL PROTECTED]> BH> Subject BH> Re: [osgi-dev] OSGI for residential gateway BH> Well, I won't claim to be the content police for this list, so others BH> are free to correct me. It was my understanding that this list was for BH> higher-level issues than bundle development. Personally, I don't mind BH> talking about bundle development, since I do it all the time anyway. :-) ->> richard BH> Yann Dolbeau wrote: >> Hello Mr Hall, >> >> Actually, I put this request here on demand of Mr Peter Kriens so he >> could answer/give me some information about the OSGi but I didn't know >> it was reserved for the spec details. >> I just wanted to know for example how to develop a bundle or how to >> make the platform work without having it on my laptop... >> >> I'm going to see what's happening on the Oscar mailing list... >> >> See you >> >> 2006/3/24, Richard S. Hall <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>>: >> >> I am not sure this is the best mailing list for your request...the >> osgi-dev mailing list is intended to be about spec issues. >> >> If you want to discuss Oscar, you should probably use the Oscar >> mailing >> list... >> >> -> richard >> >> Yann Dolbeau wrote: >> > >> > I would like to work with another student on our final project >> of our >> > engineering school based on OSGI technology. It will be done in >> China >> > from February to June 2006 at Beijing University of Technology ( >> > http://www.bjpu.edu.cn < http://www.bjpu.edu.cn/> ). >> > >> > Students at Ecole Centrale d'Electronique of Paris, we would like BH> to >> > associate this project with one of your research on services >> based on >> > the OSGI technology if this is possible or just have useful >> > information (how to start developping services with Oscar for >> example) >> > >> > >> > >> > We are fully willing to answer your questions. >> > >> > >> > PS: We suceeded in lauching Oscar and to run some services as >> the GUI >> > interface or the HTTP web access but One of our big question is : BH> In >> > what kind of box (Home Box or (I don't know)) do you put the >> > plateform, how you do it? Where can we find those type of boxes? >> > >> > >> > Thanx >> > >> > -- >> > Yann Dolbeau >> > >> >> >> > >> > ___ >> > osgi-dev mailing list >> > osgi-dev@bundles.osgi.org <
Re: [osgi-dev] OSGI for residential gateway
This list is for discussing any OSGi technical topic including spec issues and general programming for OSGi (i.e. bundle development). Questions about specific OSGi implementations would be better asked in the implementations' mail lists. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "Richard S. Hall" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-03-24 08:18 AM Please respond to OSGi Developer Mail List To Yann Dolbeau <[EMAIL PROTECTED]> cc OSGi Developer Mail List , cavel alexis <[EMAIL PROTECTED]> Subject Re: [osgi-dev] OSGI for residential gateway Well, I won't claim to be the content police for this list, so others are free to correct me. It was my understanding that this list was for higher-level issues than bundle development. Personally, I don't mind talking about bundle development, since I do it all the time anyway. :-) -> richard Yann Dolbeau wrote: > Hello Mr Hall, > > Actually, I put this request here on demand of Mr Peter Kriens so he > could answer/give me some information about the OSGi but I didn't know > it was reserved for the spec details. > I just wanted to know for example how to develop a bundle or how to > make the platform work without having it on my laptop... > > I'm going to see what's happening on the Oscar mailing list... > > See you > > 2006/3/24, Richard S. Hall <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > I am not sure this is the best mailing list for your request...the > osgi-dev mailing list is intended to be about spec issues. > > If you want to discuss Oscar, you should probably use the Oscar > mailing > list... > > -> richard > > Yann Dolbeau wrote: > > > > I would like to work with another student on our final project > of our > > engineering school based on OSGI technology. It will be done in > China > > from February to June 2006 at Beijing University of Technology ( > > http://www.bjpu.edu.cn < http://www.bjpu.edu.cn/> ). > > > > Students at Ecole Centrale d'Electronique of Paris, we would like to > > associate this project with one of your research on services > based on > > the OSGI technology if this is possible or just have useful > > information (how to start developping services with Oscar for > example) > > > > > > > > We are fully willing to answer your questions. > > > > > > PS: We suceeded in lauching Oscar and to run some services as > the GUI > > interface or the HTTP web access but One of our big question is : In > > what kind of box (Home Box or (I don't know)) do you put the > > plateform, how you do it? Where can we find those type of boxes? > > > > > > Thanx > > > > -- > > Yann Dolbeau > > > > > > > > ___ > > osgi-dev mailing list > > osgi-dev@bundles.osgi.org <mailto:osgi-dev@bundles.osgi.org> > > http://bundles.osgi.org/mailman/listinfo/osgi-dev > > > > > > > -- > Yann Dolbeau ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Updating and mixing R3 and R4 bundles and Bundle-SymbolicName
They are all possible. Whether is makes sense is in the eye of the beholder :-) Scenarios 1 and 3 are both changing the BSN (bundle symbolic name) of an installed bundle. Scenario 2 is about adding a BSN. This is probably more common as people start to take advantage of R4 function. Scenario 1 is possible of a bundle is refactored into a set of bundles, but in that case it is more likely the original BSN will still be needs as a facade bundle to combine the refactored bundles. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Marcel Offermans <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-03-21 08:42 AM Please respond to OSGi Developer Mail List To OSGi Developer Mail List , felix-dev@incubator.apache.org cc Subject [osgi-dev] Updating and mixing R3 and R4 bundles and Bundle-SymbolicName There are a couple of scenarios that I'd like to discuss that have to do with updating bundles and mixing R3 and R4. Whilst I agree some of them are a bit theoretical, I'd like to get your opinions on how to deal with them (best practices if you wish). These issues are related to the Bundle-SymbolicName. When talking about Bundle-SymbolicName, the spec (3.5.2) says: The installation of a bundle with a Bundle-SymbolicName and Bundle-Version identical to an existing bundle must fail. Furthermore, on bundle validity the spec (3.11) says (amongst other things): Updating a bundle to a bundle that has the same symbolic name and version as another installed bundle [causes a bundle to fail]. Scenario 1: Updating an R4 bundle with symbolic name A to one with symbolic name B. Provided B (with the same version) does not exist yet, this should not fail, although for me it is strange to change the symbolic name in an update. Scenario 2: Updating an R3 bundle to an R4 bundle. Provided the symbolic name and version of the R4 bundle does not fail, this should be possible. Scenario 3: Updating an R4 bundle to an R3 bundle. This should be possible, but might break dependencies that are using the symbolic name. Any comments on this? Greetings, Marcel ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] JSR 291 has been approved
Just wanted to let folks know that JSR 291 has been approved by the JCP. If any of you are intested in following the discussion, you can join the eg mail list (it is open for all to subscribe, but only accepted JSR 291 EG member can post to the list): http://bundles.osgi.org/mailman/listinfo/jsr-291-eg BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bundle overhead
It is a tradeoff (like all things). If you collapse all the javacode into a single JAR then you only need one classloader (bootstrap class loader). But if you want modularity between code sets and you want the ability to independently life cycle manage code sets, then a single JAR is not a good choice. Therefore you want to use the smallest number of bundles consistent with proper modularity and life cycle management needs. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 한 찬규 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-03-14 03:00 AM Please respond to OSGi Developer Mail List To cc Subject [osgi-dev] Bundle overhead Hi, I'm a immature student. - Is it good to reduce the number of OSGi bundle (I think it's same concept as bundle overhead)? Is it absolutely efficient? why? i wonder.. Thank you for your interest. ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Non-local classpath entries...
As currently designed and specified, the purpose of Bundle-Classpath is to state the internal classpath of the bundle. That is directories and JAR files contained within the bundle. So Bundle-Classpath must not refer to things out side of the bundle. If you need to refer to things outside of the bundle use Import-Package, Require-Bundle or even fragments. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Niclas Hedhman <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-02-23 07:17 AM Please respond to OSGi Developer Mail List To OSGi Developer Mail List cc Subject [osgi-dev] Non-local classpath entries... Am I allowed to specify http:// URLs in the classpath for a bundle, instead of packaging them within the bundle itself?? How about custom URLs, that may (or not) be resolved either through URLStreamhandlerFactory or the java.protocol.handler.pkgs ?? Cheers Niclas ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Service Platform Identifier
Service Platform Identifier is defined in 2.2.13 of the R3 spec. During the rewrite of the spec for R4 we seem to have lost this definition. Sorry :-( I will open a bug to have this added to the IP spec for the next release. The following is from section 2, Reference Architecture, of the R3 spec. This text also references some other entities defined in section 2. So you probably need to consult the R3 spec for the full information. 2.2.13 Service Platform Identifier The Service Platform Identifier (SPI) is a character string that is assigned at some point in time before the Service Platform is running, also known as staging. This identifier must be stored in the Service Platform Server so that it is available to the Service Platform software when it starts. The identifier must also be made available to the Owner. The identifier can be printed on the exterior of the Service Platform Server either on its box or the accompanying literature. If the manufacturer uses a smart card to hold the Service Platform Identifier, it could, for example, be printed on the smart card. The identifier must be unique across all service platforms, and it should be formatted according to the following scheme: SPI := domain ’:’ tail domain := alpha ( alpha | digit | ’_’ ) * tail := alpha ( alpha | digit | [-+/._] ) * The first part of the string is a domain identifier, which defines the structure and format of the rest of the identifier. The domain identifier and the tail are delimited by a colon (“:”). The domain identifier can indicate anything, such as manufacturer, phone number, or some other existing name-space. For example: MSISDN:+46706066934 VIN:123456789-345678 ACME:SerNo987654321-0 The Service Platform Identifier can be permanent or changeable. An example of a permanent identifier is a serial number built into the Service Platform Server and used under the assumption that only one Service Platform executes on that server. A changeable identifier might be one that can be created during the initial provisioning of the SPS, either by the Service Platform itself or by an external entity. A changeable identifier might be based on a permanent one, such as a serial number built into the Service Platform Server. For example, a server serial number appended with the ordering number of the service platform can be a suitable identifier. It is important for the Service Platform Identifier to be unique and for the Operator to understand the nature (permanent or otherwise) of the Service Platform Identifier. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 "John E. Conlon" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-01-27 10:12 AM Please respond to [EMAIL PROTECTED]; Please respond to OSGi Developer Mail List To OSGi Developer Mail List cc Subject [osgi-dev] Service Platform Identifier The Service Compendium R4 on page 231-432 (Initial Provisioning Service) is the first place that mentions the term of a Service Platform Identifier. Before the request URL is executed, the Service Platform information is appended to the URL. This information includes at least the Service Platform Identifier, but may also contain proprietary information, as long as the keys for this information do not conflict. Different URL schemes may use different methods of appending parameters; these details are specified in the mappings of this specification to concrete protocols. The term 'Service Platform Identifier' is mentioned throughout the I.Provisioning Service section but the spec does not specify format nor how the 'spid' is obtained. (110.7.3. does however give a couple of examples of adding it to a http(s) request.) Is the use of a SPID a MUST requirement? How is it created and what is the format? thanks, John Conlon Verticon, Inc. ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] org.osgi.service.prefs bundle versions?
New prefs. Don't think about the symbolic name when dealing with Prefs. Prefs predates symbolic name. All Prefs can know is bundle id and bundle location. The Prefs spec is mute on which is the primary key for the prefs data. However the ref impl uses bundle id. I have opened an issue for CPEG to decide which it should be and will we then update the spec text and perhaps issue an erratum. I expect bundle id will be the choice since that is the behavior of the ref impl. So in your scenario A and B and C all have different bundle ids. Therefore none of them can see any of the others preferences. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Roy Paterson/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2006-01-31 03:57 PM Please respond to OSGi Developer Mail List To OSGi Developer Mail List cc Subject Re: [osgi-dev] org.osgi.service.prefs bundle versions? Ok, so what should happen in the following scenario: Bundles A and B are installed at the same time. They have the same symbolic-name but different versions. They both use prefs, so they have their own preferences. The Preferences Impl bundle is shutdown... ... sometime later the Preferences Impl bundle starts up again. Bundles A and B are no longer installed. However there is a new Bundle C that has the same symbolic-name as A & B. When Bundle C asks for it's prefs, what should it get? A's prefs, B's prefs, or new prefs? Thanks, Roy - Roy Paterson IBM Pervasive Computing Austin, TX Phone: (512) 838-8898 BJ Hargrave/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/26/2006 08:19 PM Please respond to OSGi Developer Mail List To OSGi Developer Mail List cc Subject Re: [osgi-dev] org.osgi.service.prefs bundle versions? [EMAIL PROTECTED] wrote on 2006-01-26 04:57:59 PM: > > How should an implementation of the OSGi preferences service handle > bundles with the same symbolic name but different versions both > running on the same system? Should the bundles share the same > preferences or should they each have their own? Technically, these are 2 distinct bundles. Each has a distinct bundle id and bundle location. Therefore, Prefs must treat each as a seperate bundle and give them each their own preferences. If the there was only one bundles installed and it was updated to a new bundle version, then the updated bundle would then use the prefs from the original bundle. This is because they are the "same" bundle to Prefs: they have the same bundle id and bundle location. > > This question came up in Eclipse bug https://bugs.eclipse. > org/bugs/show_bug.cgi?id=124176#c5 > > Regards, > Roy Paterson > > - > Roy Paterson > IBM Pervasive Computing > Austin, TX > Phone: (512) 838-8898___ > osgi-dev mailing list > osgi-dev@bundles.osgi.org > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Where should API go?
I think it really depends. Using the org.osgi.service.log package as an example, this package is small, contains mostly interfaces and a few small classes (exceptions, events, ...). These classes have very little implementation and change very slowly. This package is suitable for all three choices but (3) is probably overkill. For servlet API, I would go with (3) for several reasons. (a) The code contains non-trivial implementation in places that may need fixing. Its own bundle allows it to be independently updated. (b) The code is from a 3rd party. The servlet code comes from a different source than the http service implementation (most likely the case). Therefore clean seperation makes sense. I have contributed code to make a servlet 2.1 bundle for Felix. So this will one day be available as a bundle direct from Apache. (c)The code is not just a small package. There is quite a but of code so (2) will consume resources unnecesarily if there are several bundles all providing the package. (d) Since the code is 3rd party, it is probably on different release schedules that the code which is using it. So (1) is a poor choice here. In summary, I generally prefer (2) or (3). (2) is great for small service packages. (3) is better for package with some implementation complexity or size. (1) is really just a packaging optimization that may be done too early :-) BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-01-29 03:58 PM Please respond to OSGi Developer Mail List To OSGi Developer Mail List cc Subject [osgi-dev] Where should API go? At the risk of exposing some religion... There seems to be quite a bit of debate on where to put API packages relative to their implementation(s). The current one on hand for us is the javax.servlet API and the HTTP service implemenation. (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=121585 if you want the gory details). Here is the scenario org.eclipse.osgi.services -- All the OSGi produced API packages. This includes the HTTP service API org.eclipse.equinox.http -- implements the HTTP service but needs javax.servlet The question for this example is, "where should the javax.servlet packages be put?" Three options 1) in the services bundle + convenient and efficient (no extra classloaders assuming you have to have services anyway) - bloats the services bundle - does not scale on disk. Everyone else will want to put their stuff in there too. - drags in other interfaces 2) in the http service impl bundle + convenient and efficient (no extra classloaders) - brittle as it ties the implementation to the packages. If you update the HTTP bundle the old one cannot be tossed until a restart. This keeps around all the impl classes - causes problems for folks that want to use the service if it is available but are ok if it isn't. That is, they have to spec an import to get the service interface but if the interface is only available via implementations, they have to have an implementation to resolve. 3) in a third bundle just for the servlet API (e.g., javax.servlet) + clear - adds another classloader. i.e., does not scale well at runtime if everyone takes this approach - how big should these bundles be? The Services bundle only makes sense because its contents are all from the same source and the interfaces are very small. Otherwise many of the contents are completely unrelated. - harder to manage as you have more bundles (this may be a nit but depending on how much you put in each, there could be alot of API bundles) I have seen Peter state that #2 is a VERY [his empahsis] common approach and was somewhat surprised by that. The Knopflerfish folks seem to have all three approaches (in some cases for the same function). We just need to pick a path and do it. Any advice would be most appreciated. Jeff ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev ___ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] org.osgi.service.prefs bundle versions?
[EMAIL PROTECTED] wrote on 2006-01-26 04:57:59 PM: > > How should an implementation of the OSGi preferences service handle > bundles with the same symbolic name but different versions both > running on the same system? Should the bundles share the same > preferences or should they each have their own? Technically, these are 2 distinct bundles. Each has a distinct bundle id and bundle location. Therefore, Prefs must treat each as a seperate bundle and give them each their own preferences. If the there was only one bundles installed and it was updated to a new bundle version, then the updated bundle would then use the prefs from the original bundle. This is because they are the "same" bundle to Prefs: they have the same bundle id and bundle location. > > This question came up in Eclipse bug https://bugs.eclipse. > org/bugs/show_bug.cgi?id=124176#c5 > > Regards, > Roy Paterson > > - > Roy Paterson > IBM Pervasive Computing > Austin, TX > Phone: (512) 838-8898___ > osgi-dev mailing list > [EMAIL PROTECTED] > http://bundles.osgi.org/mailman/listinfo/osgi-dev BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list [EMAIL PROTECTED] http://bundles.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] bundles.osgi.org content
We are building the bundles.osgi.org website with technical information for OSGi developers. We currently have HTML javadoc for the R4 API (Core and Compendium) [http://bundles.osgi.org/javadoc/r4/index.html], XML schemas [http://bundles.osgi.org/xmlns/] and various constants [http://bundles.osgi.org/reference.php]. And of course the big new thing is getting the OBR bundle repo going. Peter has put information on the website for people who want to federate into the repo [http://bundles.osgi.org/vendors.php] as well as a browser for the repo contents [http://bundles.osgi.org/browse.php] If there is any other information you would like to see on the website, send a mail to this list to let us know. For example, would it be useful to also have the Javadoc for past releases of the OSGi spec? BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 ___ osgi-dev mailing list [EMAIL PROTECTED] http://bundles.osgi.org/mailman/listinfo/osgi-dev
