That was the first problem i ran into, and I think it's easy to solve with
these bnd instructions;
<Private-Package>
org.apache.aries.blueprint.compendium.cm
</Private-Package>
Then I ran into problems with either bean metadata or recipes that I don't
have time to investigate right now.
david jencks
On Nov 23, 2011, at 7:32 AM, Guillaume Nodet wrote:
> So xbean is extending the cm namespace from blueprint-cm, so there's no
> other way that exporting the org.apache.aries.blueprint.compendium.cm again
> afaik.
>
> On Tue, Nov 22, 2011 at 22:18, David Jencks <[email protected]> wrote:
>
>> Since you seem to be trawling for namespace handlers with problems.... I
>> think that xbean-blueprint is going to be pretty much impossible to run
>> with the latest aries blueprint. I think that the xbean-blueprint
>> functionality should be available through a standards based namespace
>> handler.
>>
>> xbean-blueprint code is here:
>>
>> svn:https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-blueprint
>>
>> Roughly speaking xbean-blueprint works like this:
>>
>> 1. you javadoc-annotate your bean classes to indicate they are interesting
>> 2. You run a maven plugin that generates a schema where the bean classes
>> correspond to elements/types and the bean attribute correspond to the xml
>> structure (generally simple attributes map to xml attributes, more
>> complicated attributes such as beans map to elements). The plugin also
>> generates a property file that maps the xml to bean recipes.
>>
>> 3. Your blueprint plan includes elements in the generated schema
>> namespace; as noted above element names correspond to bean class names.
>>
>> 4. you register an xbean-blueprint namespace handler configured with the
>> schema namespace. This mostly finds the property file so it can do the
>> mapping.
>>
>> 5. the xbean-blueprint namespace handler takes over xml processing of each
>> element in the namespace, creating and configuring the bean recipes. If
>> you switch back to blueprint (or other namespace) control goes back to the
>> main blueprint parser.
>>
>> At this point I think I'm going to have to switch geronimo's use of
>> xbean-blueprint back to plain blueprint. Perhaps I'll be able to find
>> time soon to help resolve these problems.
>>
>> thanks
>> david jencks
>>
>> On Nov 22, 2011, at 11:34 AM, Timothy Ward wrote:
>>
>>>
>>> Hi,
>>>
>>> BundleDelegatingClassLoader was dropped a while back in favour of using
>> AriesFrameworkUtil#getClassLoader(Bundle) and
>> AriesFrameworkUtil#getClassLoaderForced(Bundle). These get the actual
>> bundle classloader which makes them faster and less error prone.
>>>
>>> Clearly the CXF integration is quite involved - what exactly is it that
>> CXF needs the Recipes for? This is exactly the sort of stuff that would be
>> useful to us in properly defining the Aries Blueprint API. It may be that
>> there are ways of implementing the function without using blueprint's
>> internals, and in a way that works across 0.3 and 0.4. Another possibility
>> is that your use-case indicates a missing piece of API for blueprint that
>> we should be adding. I'm really not keen to start exporting the internal
>> recipe and di packages again, in my view they are implementation details
>> that should never have been exported in the first place.
>>>
>>> Regards
>>>
>>> Tim Ward
>>> -------------------
>>> Apache Aries PMC member & Enterprise OSGi advocate
>>> Enterprise OSGi in Action (http://www.manning.com/cummins)
>>> -------------------
>>>
>>>
>>>> From: [email protected]
>>>> To: [email protected]
>>>> Subject: More issues with blueprint.....
>>>> Date: Tue, 22 Nov 2011 13:24:22 -0500
>>>>
>>>>
>>>> As you know, I'm trying to get CXF to work with the latest blueprint
>> stuff.
>>>> This is not going easily.... More issues:
>>>>
>>>> 1) BundleDelegatingClassloader removed - not a huge issue. I can copy
>> it into
>>>> CXF from the old tag. However, this is a backwords incompatible
>> issue. I
>>>> would recommend putting it back in and marking it @deprecated.
>>>>
>>>> 2) blueprint.di, blueprint.container, blueprint.reflect not exported.
>>>> reflect isn't a big deal. CXF is just calling a single method on
>>>> MetatdataUtil for which I can easily copy the code over. The other
>> two are
>>>> much bigger issues. CXF needs access to the BeanRecipe from container
>> and
>>>> Recipe and ExecutionContext from di.
>>>>
>>>>
>>>> I can likely work around some of it if we export DI and then add a
>> BeanRecipe
>>>> interface into DI that the BeanRecipe in container would implement.
>> I'd
>>>> still need to do some reflection or something to allow support of both
>> 0.3 and
>>>> 0.4.1 to deal with it. However, for 0.4.1, I'd LIKE to do the above
>> but
>>>> export container for now with the plan to not export it later. Allow
>> some
>>>> time for migration.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> [email protected] - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
