Hi, thank you very much for the information. I did not know that this automatism works behind already. I was suspecting not because in OSGI 4.2 we define service interfaces with only strings. I was wrong than.
In this case one problem is solved already :). The other one with the osgi-enterprise and osgi-compendium makes still question marks in my head. In my opinion an implementation bundle should never contain utility classes or API that other bundles may use. Also I have this feeling that one major versioned API should be allowed only ones in one OSGI container (or subsystem or something that means an application scope). Also I still think that each logically separated API should have a dedicated bundle and implementors should not take these API packages into their bundles... Thanks for the patiente and especially for your last mail! Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Wed, May 9, 2012 at 9:42 AM, Neil Bartlett <[email protected]> wrote: > Balázs, > > This is not really the right way to version services. Service > compatibility is based on the versioning of package exports and imports. > > For example, if your provider bundle implements version 2.0.x of the API > then it should use an Import-Package range of [2.0,2.1). This is because a > bump in the minor version (second segment) is meant to indicate a new > feature, and therefore would break providers as you noted. > > If a client bundle understands version 2.0.x of the API then it should > import the package with a range of [2.0,3). This is because clients do not > care about additional features, they only care about true > backwards-incompatible breaks, which are indicated by a bump of the major > version. > > At runtime, the service registry will only permit the client bundle to see > services published by a provider that is bound to the same exported > package. Therefore it is unnecessary to layer your own arbitrary versioning > information on top of this. > > I strongly encourage you to read some documentation in this area -- either > the specification itself or "OSGi in Action" by Richard Hall et al -- > before proceeding. This will help you to avoid inadvertently reinventing > mechanisms that already exist. > > Regards, > Neil > > Balázs Zsoldos <[email protected]> > 9 May 2012 08:11 > Hi, > > I might have missed it. I am sorry but I did not have time to go through > all of the specifications till now. However I write here an example: > > There is an API interface in a package that has the version 2.1.0. Let's > call it CACHE. We have this in the OSGI container. Based on our private > rules there cannot be the same package with 2.x version 2.x as it would > cause problems (developers would not free to drop bundles again and again > during development). > > We interface is provided twice as a service in the container. The first > implementation uses InfiniSpan, the Second EhCache. The EhCache > implementation implements version 2.1.0 of the CACHE API, the Infinispan > implementation implements version 2.0.5 (some of the functions not > implemented). > > Now a new bundle comes that was compiled with 2.0.8. It will look for the > service version (and not package) [2.0.8, 3). The numbers here mean that > the service should implement the API package in this version range as at > compile time that API package version was used. > > Till now I could not find a standard way for this. I can imagine having > this method manually like this: > In the implementation bundle when I register the service I give the > version of package I used from the API as a service property. > When I use the service I give a filter like this: > (&(objectClass=APi)(&(apiversion>=2.0.8)(apiVersion<3))) > > Well, the question is a bit more complicated when a service is registered > with multiple interfaces from different packages :). > > Regards, > Balazs Zsoldos > Software Architect > Mobile: +36-70/594-92-34 > > Everit Kft. > https://www.everit.biz > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Neil Bartlett <[email protected]> > 9 May 2012 06:04 > Hello Balázs, > > With regard to service versioning, OSGi does already do this, pretty much > exactly as you have described. But you seem to be saying that this is > missing. Could you clarify please? > > Regards, > Neil > > Balázs Zsoldos <[email protected]> > 9 May 2012 00:31 > Hi, > > first of all, I am sorry I made such an argument on this mail list with my > first mail :). I feel really happy that others take serious questions that > came into my mind! > > We talked about this issue with my colleague and we made some conclusions > a couple of days ago. I may be useful for you as well what we talked about. > At our projects we would like to follow the following rules however I would > be very happy if you have any modification how to change our rules: > > - An API bundle should never expose services. That is the > implementation that register services with the interfaces of the API > - Two implementation bundles should communicate only via the API and > services > - When a project comes out from incubation the API should rarely change > - Any JAR should contain packages only that has the same releasing > lifecycle. This is true for the API packages in the same technology as > well. If there is a part that more often changes then we have to think if > they really should be in the same bundle or they have a hierarchical > connection. > - Inside one major version the API should be always backward compatible > - Inside one OSGI system there should be only one API bundle from with > the same major version > - There may be different implementation bundles that expose services > from the same API with different service properties > > What we were missing: > > - It would be useful if services had the same kind of versioning as > the API packages. The reason: > - Imagine that there is an API with version 2.2.5. This means that > implementations may come from version 2.0.0. > - If an implementation is older than an API it does not necessarily > implement all of the functions of an interface > - When someone needs a service and compilation is made with version > 2.1.2 of API bundle it can say that it needs service version [2.1.2,3). > This means that the implementation of the service has to implement this > API > version range. > > Well this may seemed to be a bit off topic but I am not sure it was. The > way how packages taken together inside one bundle is an amazingly important > thing. There should be (there might be already) how versions of API and > packages should be handled together. Well, based on our logic there should > be as many bundles as many technologies are supported in compendium and > enterprise. E.g. there should be org.osgi.services.jdbc and there should be > org.osgi.services.blueprint. The version of these parts do not have to grow > together. Well it is really sick but it came to my mind that the osgi spec > should not be one big pdf with a version but as many pdfs as many logically > different chapters are. E.g. one pdf with version for jdbc and one pdf with > version for blueprint. If all of these parts have to be released always > together it may slow down the evolution of the different parts. OSGI is > simply became too big to be handled in under one version like 4.2 or 4.3 :). > > Well I hope I could write in that way that you got my point. My problem is > that if OSGI is not separated to small bundles and specification parts in > the future with different versions and lifecycle it will lose a very > important part of modularization. It was the same with Spring. First one > big jar was made, than it was separated to many small jars when the project > got big. > > I would like to suggest also the following points: > > - There should be one OSGI certified maven repository where one java > package with one major version is allowed only in with one groupId and > artifactId. It is really annoying for example that some API-s may exist > with many different variations and everyone use them with different > groupId:artifactId pairs > - Never say that some API packages comes from one groupId:artifactId > jar at compile time and the same packages should come from different > groupId:artifactId (may be handmade jars) in the runtime environment. > > A very huge time of our work is lost as there is a big mess with API jars > and packages. The strength of Java language comes from the strict > specifications and rules. It may be time to set up some new rule (like the > ones above :) ) to keep this language and OSGI the strongest. Maven created > many very strict rules after ANT and yet made life way much easier. > > Regards, > Balazs Zsoldos > Software Architect > Mobile: +36-70/594-92-34 > > Everit Kft. > https://www.everit.biz > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Alan D. Cabrera <[email protected]> > 8 May 2012 23:22 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Holger Hoffstätte <[email protected]> > 8 May 2012 18:57 > > (one more ;) > > On 08.05.2012 17:01, BJ Hargrave wrote: > > It has always been so. See the Bundle-Description in the companion code > jars: "Interfaces and Classes for use in compiling bundles" > > Yes, fine. Does not preclude runtime use though. > > > Those packages are then supplied at runtime by the implementation > bundles (which may want to additionally decorate the exports). > > That was the actual question: where and more importantly why is this > embedding & exporting recommended, instead of simply having both consumers > and providers refer to one or more runtime-shared bundles containing only > the interfaces? I'm genuinely curious. I can see that it makes service > provider bundles self-contained (since implemented functionality is also > offered), but IMHO that seems more like an outdated concession to manual > deployment. Not sure if that's worth the additional complexity of > embedding, which seems counterintuitive for a platform that enables safe > sharing. > > I also really hope this does _not_ mean to imply that this approach should > be followed by all bundles whose implementations somehow implement > interfaces shared with other bundles, only to artificially increase their > self-containedness? Because down that path lies huge subsystem madness.. > > thanks, > Holger > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
<<compose-unknown-contact.jpg>>
<<postbox-contact.jpg>>
<<postbox-contact.jpg>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
