geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [VOTE] Release Blueprint 1.0.0 (3thd try)
Date Fri, 11 Sep 2009 07:39:21 GMT

On Sep 11, 2009, at 12:19 AM, Guillaume Nodet wrote:

> On Thu, Sep 10, 2009 at 23:35, David Jencks <david_jencks@yahoo.com>  
> 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.

>
>> 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 foo.bar.api;
>   interface Interface {
>   }
>
>   package foo.bar.impl;
>   class Implementation implements Interface {
>   }
>
>  bundle A: exports foo.bar.api;version=1.0
>                  imports foo.bar.api;version=1.0
>                  exports foo.bar.impl;version=1.0
>                  imports foo.bar.impl;version=1.0
>
>  bundle B: exports foo.bar.api;version=1.0
>                  imports foo.bar.api;version=1.0
>                  exports foo.bar.impl;version=1.1
>                  imports foo.bar.impl;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 foo.bar.api;version=1.0
>                     exports foo.bar.impl;version=1.0
>
> Now we deploy bundle B.  The foo.bar.api is compatible, so the
> framework will import this package, but the version for foo.bar.impl
> is too low, so this package will be exported:
>    bundle B:  imports foo.bar.api;version=1.0  (from bundle A)
>                     exports foo.bar.impl;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 foo.bar.api;version=1.0
>                     exports foo.bar.impl;version=1.1
>
> The bundle A:
>     bundle A: imports foo.bar.api;version=1.0
>                     imports foo.bar.impl;version=1.1
> The framework will choose to import the foo.bar.impl 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
> foo.bar.impl, 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
> "http://geronimo.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0".
> 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 foo.bar.impl;version:=[1.0,1.1)  then it  
could not import B's 1.1 version.

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 <kevan.miller@gmail.com>
>>> wrote:
>>>>
>>>> On Sep 10, 2009, at 12:44 PM, Guillaume Nodet wrote:
>>>>
>>>>> On Thu, Sep 10, 2009 at 17:54, Kevan Miller <kevan.miller@gmail.com

>>>>> >
>>>>> 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:
>>>>>>>
>>>>>>> https://repository.apache.org/content/repositories/geronimo-staging-054/
>>>>>>>
>>>>>>> The corresponding tag is available at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://svn.apache.org/repos/asf/geronimo/components/blueprint/tags/blueprint-1.0.0/
>>>>>>>
>>>>>>> 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 sure
>>>>> 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.  
>>>>>> Also, 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  
>>>>>> OSGi
>>>>>> 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: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com


Mime
View raw message