geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Date Fri, 11 Sep 2009 08:02:01 GMT
On Fri, Sep 11, 2009 at 09:39, David Jencks <> wrote:
> On Sep 11, 2009, at 12:19 AM, Guillaume Nodet wrote:
>> On Thu, Sep 10, 2009 at 23:35, David Jencks <>
>> wrote:
>>> I updated the NOTICE file generation to use the recommended
>>> remote-resources
>>> plugin techniques.
>>> I would still like to see something change on:
>>> 1. I still think that the spec xsds need to be in the spec jar and
>>> nowhere
>>> else and available from the spec jar.  I haven't understood any arguments
>>> about why this requires more than one copy or why its a bad idea.  Why
>>> should an alternative blueprint implementation that wants to use our api
>>> jar
>>> need to include its own copy of the schema?
>> First, remember that we are in a pure OSGi environment.
>> Second, the small jars (i.e. not the blueprint-bundle one) are mostly
>> here for separating concerns, but the real artifact to be deployed is
>> the blueprint-bundle.   If you deploy the other ones, you won't be
>> fully compliant with the spec.  The reason is that the spec clearly
>> specifies that the org.osgi.service.blueprint package should have a
>> "uses" clause that lists the implementation specific packages that can
>> be used by clients.   In our case, there are some interfaces defined
>> in the blueprint-core bundle that are exported.   The reason for all
>> that is to make sure that you end up in a consistent state if you have
>> multiple blueprint extenders in your framework.
>> Third, the spec does not say that this schema should be made available
>> at that location, so this is implementation specific.  I've included
>> it there only because i think it will be easier for users to find it.
>> Last, let's assume you deploy another blueprint implementation.  You
>> have no way to know exactly which api package you will be wired to.
>> So if you're no wired to your own version of the jar, but to the other
>> implementation jar, maybe this other implementation will not have the
>> schema available at the same location, so you can't really rely on
>> that.   So you *need* the other copy internally.   If you don't want
>> multiple copies, we'd have to remove the one from the api jar as it
>> was previously.
>> Any other implementation would have to do the same because the spec
>> does not specify that the schema should be included in the api
>> package.
> Does osgi work better if you package interfaces and implementation together
> in the same bundle? IIUC you are saying here that the blueprint service is
> really designed to only work this way.

So the schema is a side issue I think.  But in OSGi, everything is
about modularity and if you want to really leverage OSGi, you need to
carefully design your bundles.   If don't have an extensive experience
in this area, and other felix guys might be better able to answer, but
usually, the best way to achieve that is to package the interface
packages with the service implementation in a single bundle (for
bundles that mostly expose a standalone OSGi service).  If you have a
whiteboard pattern, you don't really want to include the api in each
service.  But services like the OSGi preference services,
configuration admin, HTTP service, etc... are best done this way
I think having too fined grained bundles is not ideal, but having too
coarsed grained bundles either ...

For blueprint, the spec says the following:
"A Blueprint extender must not manage a Blueprint bundle if there is a class
space incompatibility for the org.osgi.service.blueprint packages. For
example, if the Blueprint bundle uses the BlueprintContainer class, then it
must import the org.osgi.service.blueprint.container package. The Blue-
print extender and the Blueprint bundle must then share the same class
space for this package. Type compatibility can be verified by loading a class
from the blueprint packages via the Blueprint extender bundle and the Blue-
print bundle’s loadClass methods. If the Blueprint bundle cannot load the
class or the class is identical to the class loaded from the extender, then the
two bundles are compatible for the given package. If the Blueprint extender
is not class space compatible with the Blueprint bundle, then Blueprint
extender must not start to manage the Blueprint bundle."

and also:
"To mitigate type incompatibility problems, a Blueprint extender must
export the org.osgi.service.blueprint package. In the uses: directive, it
should list any packages of classes that can be shared between the Blueprint
extender and the Blueprint bundle. Blueprint bundles should import this

Those problems comes from the fact that Blueprint is an extender and
is not a plain OSGi service, so things have to be carefully done to
avoid class space inconsistencies.

>>> 2. I see that the core and cm bundles don't import what they export.  Not
>>> importing what you export still makes be extremely uneasy.  Maybe one can
>>> argue that the cm bundle is a library since it doesn't appear to export
>>> any
>>> services or have a bundle activator, but the core bundle is surely not a
>>> library since it registers a bundle listener.  Unless there is clear harm
>>> in
>>> importing what we export I would really prefer to follow this principle
>>> everywhere and couple it with careful version specification in imports
>>> and
>>> exports.
>> Again, those bundles are not really supposed to be deployed.  If it
>> makes you uncomfortable, I'd rather make them plain jars and not
>> bundles.  But I suppose the same apply to blueprint-bundle too, which
>> only imports/exports the blueprint api packages.
>> That said, I've been hit by this problem before and I can try to
>> re-explain a bit.   It's about backward compatibility and consistency
>> of your class path.
>> First, make sure we understand what the framework does.   When a
>> bundle export and import the same package, it won't actually do both
>> at the same time.
>> When the bundle is resolved, the framework will choose to have the
>> bundle *either* export the package *or* import it, and the spec does
>> not mandate any particular option if both can be done.  Not that
>> importing the package necesseraly implies that all constraints are
>> satisfied (such as uses clauses, version ranges, etc...) along with
>> consistency in the classloader.  Both equinox and felix frameworks
>> will choose to import the pacakge rather than export it if the
>> constraints can be satisfied afaik.
>> Now, let's take an example:
>> We have two classes:
>>  package;
>>  interface Interface {
>>  }
>>  package;
>>  class Implementation implements Interface {
>>  }
>>  bundle A: exports;version=1.0
>>                 imports;version=1.0
>>                 exports;version=1.0
>>                 imports;version=1.0
>>  bundle B: exports;version=1.0
>>                 imports;version=1.0
>>                 exports;version=1.1
>>                 imports;version=1.1
>> Also, let's say both those bundles have an OSGi BundleActivator that
>> will register a service implementing Interface (from the class
>> Implementation).
>> We first deploy bundle A, so the framework will make this bundle
>> export both packages:
>>    bundle A: exports;version=1.0
>>                    exports;version=1.0
>> Now we deploy bundle B.  The is compatible, so the
>> framework will import this package, but the version for
>> is too low, so this package will be exported:
>>   bundle B:  imports;version=1.0  (from bundle A)
>>                    exports;version=1.1
>> In this case, everything is fine. bundle A and B will use their own
>> implementation classes.
>> Now, let's say the bundles are deployed in the opposite order.
>> We first deploy bundle B:
>>    bundle B: exports;version=1.0
>>                    exports;version=1.1
>> The bundle A:
>>    bundle A: imports;version=1.0
>>                    imports;version=1.1
>> The framework will choose to import the package, because
>> this version is compatible with the constraints from bundle A:
>> version >= 1.0.
>> What happens now ?  Bundle A will not see it's own classes in package
>>, but the classes from bundle B.
>> This means that the service exported by bundle A will be the same than
>> the service exported by bundle B.   I think this is really unexpected,
>> but let's go further.   The Implementation class is not part of the
>> API, so it may change between different versions.   Let's say that
>> between version 1.0 and 1.1, the class has been renamed to
>> MyImplementation.  Bundle A will try to load the Implementation class
>> and this will result in a NoClassDefFoundError.  Really unexpected.
>> So as I said, this is really about backward compatibility.  In the
>> java world, we tend to define interfaces to hide implementation
>> details behing a known contract.  You don't want people to use
>> implementation classes directly because any incompatible change would
>> break the whole thing.  That's really the same here.   I certainly
>> don't want to have to maintain full backward compatibility on all
>> implementation details, and neither have people depending on those
>> classes.
>> In our case, the blueprint-cm bundle defines an OSGi service, which is
>> a geronimo custom namespace handler for the namespace
>> "".
>> This service implements org.apache.geronimo.blueprint.NamespaceHandler
>> interface.  This is an imported package and actually, I think
>> blueprint-cm should not export any package.
>> I think it would be easier to turn them into plain jars to avoid
>> confusion.
> I need some time to digest this.  Meanwhile.... it seems to me that two
> other solutions to this problem are:
> 1. don't export the implementation classes

> 2. use restrictive version ranges on the implementation packages.  (Of
> course this implies that you can predict the future of your classes)  For
> instance, if A imported;version:=[1.0,1.1)  then it could not
> import B's 1.1 version.

Right, those are the two solutions.  In this very case, given the
blueprint-api, -core and -cm are not really supposed to be used
directly, but they are all embedded in blueprint-bundle, I think we
should just make them plain jars.  It just removes the problem.

We had this very discussion on the camel dev list a few days ago, and
the constraints have to be thought carefully.
What we decided is:
  * for third party dependencies: use a range up to the next major
version, i.e. [2.1,3)
  * for inter camel dependencies, use a range up to the next minor
version, i.e. [2.1,2.2)
  * for a few jars that are tightly tied together at implementation
level, use a closed range: i.e. [2.1,2.1]

> many thanks for the detailed example!
> david jencks
>>> 3. I'm pretty unhappy with the maven project names at the moment.  I'd
>>> prefer to see them go back to simple names and use the bundle plugin
>>> default
>>> behavior to generate the bundle symbolic names to include the
>>> org.apache.geronimo fluff.
>> I'm not strong on that.  All the artifacts from felix uses this naming
>> scheme.  I think when you end up with a list of jars in a flat
>> directory, it's easier to deal with, but i agree it's kinda redundant
>> in a maven repo.  If you really want to change, I'm suggesting to use:
>>  geronimo-blueprint-core
>>  geronimo-blueprint-api
>>  geronimo-blueprint-cm
>>  geronimo-blueprint  (instead of blueprint-bundle)
>>> I also got an itest failure trying to build but haven't investigated yet.
>>> thanks
>>> david jencks
>>> On Sep 10, 2009, at 12:11 PM, Guillaume Nodet wrote:
>>>> Just committed some changes.
>>>> Please review and I'll upload a new release asap.
>>>> On Thu, Sep 10, 2009 at 21:05, Kevan Miller <>
>>>> wrote:
>>>>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>>>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <>
>>>>>> wrote:
>>>>>>> On Sep 10, 2009, at 4:29 AM, Guillaume Nodet wrote:
>>>>>>>> I've uploaded a new 1.0.0 release of the blueprint project.
>>>>>>>> I think I've addressed all the issues raised in the discussion
>>>>>>>> thread.
>>>>>>>> The staging repository is available at:
>>>>>>>> The corresponding tag is available at
>>>>>>>> Please review and vote:
>>>>>>>> [  ] +1 Release
>>>>>>>> [  ] -1 Do not release
>>>>>>>> The vote will remain open for 72 hours.
>>>>>>> The following files do not contain apache source license headers.
>>>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/package.html
>>>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/container/packageinfo
>>>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/package.html
>>>>>>> ./blueprint-api/src/main/java/org/osgi/service/blueprint/reflect/packageinfo
>>>>>> Those come straight from the blueprint OSGi from the osgi alliance
>>>>>> afaik.
>>>>>> I can add them with the OSGi alliance copyright, but I'm not even
>>>>>> what's the comments syntax for the packageinfo file
>>>>> OK. I should have noticed that these were in blueprint-api. I would not
>>>>> add
>>>>> anything to them.
>>>>>>> ./blueprint-core/src/main/resources/OSGI-INF/permissions.perm
>>>>>>> ./blueprint-core/src/test/resources/cache.xsd
>>>>>>> ./blueprint-core/src/test/resources/test-bad-id-ref.xml
>>>>>>> ./blueprint-core/src/test/resources/test-constructor.xml
>>>>>>> ./blueprint-core/src/test/resources/test-depends-on.xml
>>>>>>> ./blueprint-core/src/test/resources/test-generics.xml
>>>>>>> ./blueprint-core/src/test/resources/test-simple-component.xml
>>>>>>> ./blueprint-core/src/test/resources/test-wiring.xml
>>>>>>> ./blueprint-core/src/test/resources/test.xml
>>>>>>> ./blueprint-sample/src/main/resources/OSGI-INF/blueprint/config.xml
>>>>>> Those need to be fixed, right.
>>>>>>> Unless convinced otherwise, I think those must be fixed.
>>>>>>> The README should be updated to not reference 1.0.0-SNAPSHOT.
>>>>>>> the
>>>>>>> README instructions do not reference the correct maven
>>>>>>> groupid/artifactid
>>>>>>> for blueprint bundles:
>>>>>>> Current:
>>>>>>> file:///<m2_repo>/org/apache/geronimo/blueprint-bundle/1.0.0-SNAPSHOT/blueprint-bundle-1.0.0-SNAPSHOT.jar
>>>>>>> Should be:
>>>>>>> file:///<m2_repo/org/apache/geronimo/blueprint/org.apache.geronimo.blueprint.bundle/1.0.0/org.apache.geronimo.blueprint.bundle-1.0.0.jar
>>>>>> Yeah, the REAME is outdated.  I'll have a look.
>>>>> Let me know, and I can update, if you want. Strings are still in my
>>>>> emacs
>>>>> buffer... ;-)
>>>>>>> Was there any NOTICE information associated with the original
>>>>>>> Alliance
>>>>>>> source? If so, it might need to be moved over...
>>>>>> I haven't seen any NOTICE files from the OSGi Alliance, but will
>>>>>> double check to make sure.
>>>>> Thanks.
>>>>> --kevan
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog:
>>>> ------------------------
>>>> Open Source SOA
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message