You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Daniel Kulp <dk...@apache.org> on 2011/11/22 19:24:22 UTC
More issues with blueprint.....
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: More issues with blueprint.....
Posted by Guillaume Nodet <gn...@gmail.com>.
Ouch, this means that the ActiveMQ support which totally rely on blueprint
is compltetly broken too.
I'm thinking about backporting fixes into a 0.3.x blueprint branch and
release it (which will be much easier) and forget about 0.4 for now for
karaf, cxf, activemq, camel, xbean and geronimo.
Though given some bundles have already been released in 0.3.2, not sure how
i can handle that ...
On Tue, Nov 22, 2011 at 22:18, David Jencks <da...@yahoo.com> 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: dkulp@apache.org
> >> To: dev@aries.apache.org
> >> 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
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: More issues with blueprint.....
Posted by Guillaume Nodet <gn...@gmail.com>.
I've re-exported the cm package and everything seems to work now (Dan
re-exported other packages earlier today).
I've been able to deploy an activemq broker so looks good.
On Wed, Nov 23, 2011 at 18:53, David Jencks <da...@yahoo.com> wrote:
> 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.cmagain
> > afaik.
> >
> > On Tue, Nov 22, 2011 at 22:18, David Jencks <da...@yahoo.com>
> 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: dkulp@apache.org
> >>>> To: dev@aries.apache.org
> >>>> 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
> >>>> dkulp@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>
> >>
> >>
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: More issues with blueprint.....
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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: dkulp@apache.org
>>>> To: dev@aries.apache.org
>>>> 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
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: More issues with blueprint.....
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <da...@yahoo.com> 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: dkulp@apache.org
> >> To: dev@aries.apache.org
> >> 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
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: More issues with blueprint.....
Posted by David Jencks <da...@yahoo.com>.
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: dkulp@apache.org
>> To: dev@aries.apache.org
>> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>
RE: More issues with blueprint.....
Posted by Timothy Ward <ti...@apache.org>.
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: dkulp@apache.org
> To: dev@aries.apache.org
> CC: timothyjward@apache.org
> Subject: Re: More issues with blueprint.....
> Date: Wed, 23 Nov 2011 10:22:54 -0500
>
> On Wednesday, November 23, 2011 11:07:06 AM Timothy Ward wrote:
>
> ........... snip .........
>
> > > The third one is the trickier one as that really needs to call into the
> > > runtime. We could add a method on ExtendedBlueprintContainer like:
> > >
> > > void configureObject(String id, Object obj)
> >
> > This is certainly a possibility - Would it make more sense to pass a
> > BeanMetadata than an id? This prevents you from erroneously using the id of
> > a reference, reference list or service. It also allows you to configure
> > anonymous beans without relying on a particular name. We would need to
> > think about the exception behaviour if the BeanMetadata wasn't a recognized
> > bean from this blueprint container - perhaps something like:
> >
> > /**
> > * Inject (or reinject) an Object instance with the blueprint properties
> > defined by a BeanMetadata *
> > * Throws IllegalArgumentException if the bean metadata does not exist in
> > this blueprint container * Throws ComponentDefinitionException if the
> > injection process fails - this may have rendered the supplied Object
> > unusable by partially completing the injection process */
> > void injectBeanInstance(BeanMetadata bmd, Object o) throws
> > IllegalArgumentException, ComponentDefinitionException
>
> I guess it would be good to have both options. The one reason I liked the
> idea of passing an id (and then throw an exception if invalid) was that it
> allows re-using the Recipe's a lot easier. The Recipe's can cache things
> like methods and such so reusing them if possible can be a bit of a
> performance advantage. If you pass in the BeanMetadata, you would really
> need to build a new Recipe from scratch which may take a little longer. That
> said, I can see the advantages of doing that as well. :-)
>
I would expect the container to be using the cached recipe for the BeanMetadata version. I wasn't expecting that you could provide an arbrtrary metadata, only ones that were already defined in the blueprint container. These could be obtained from getComponentMetadata(id) or getMetadata(BeanMetadata.class), or from some part of the nested hierarchy of a BeanMetadata (e.g. a nested bean in a property). The IllegalArgumentException was to be thrown if the BeanMetadata wasn't one recognised by the blueprint container.
>
> > I'll have a bit more of a think about whether there's a way to do this
> > within the existing API exposed by 0.4, but I'm not sure that it is. In any
> > event do you (or anyone else) have any thoughts about the relative merits
> > of these two proposed methods? Both are implementable, it's more of a
> > usage/readability concern for me.
> > > Would that work for you? Another suggestion?
> >
> > One other (above) but I'm definitely not against adding a method with this
> > sort of function to the ExtendedBlueprintContainer.
>
> I'll work on getting that added.
Which one? I'd rather just have the second as it provides equivalent function - I like the additional type safety (knowing that we won't get something that's not a bean), and the fact that we can't get given invalid id strings. It probably wouldn't be too much of an effort to get it to accept arbitrary metadata either.
>
> THAT said, it doesn't change the fact that 0.4 is no where near backwords
> compatible and there wasn't any "migration path" or notice or anything
> provided. For 0.4.1, I'd like to re-export the stuff that would be needed to
> get CXF 2.4.4 and 2.5.0 working with it with plans to remove those exports in
> 0.5 so that we have some time to get projects updated. We're kind of in a
> catch 22 right now. Karaf cannot really update to 0.4 if it breaks the
> projects that generally deploy into Karaf like Camel and CXF, but CXF won't go
> up to 0.4 if it cannot deploy into Karaf.
>
>
> Dan
>
>
>
>
> > > Dan
> > >
> > > > Regards
> > > >
> > > > Tim Ward
> > > > -------------------
> > > > Apache Aries PMC member & Enterprise OSGi advocate
> > > > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > > > -------------------
> > > >
> > > > > From: dkulp@apache.org
> > > > > To: dev@aries.apache.org
> > > > > 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: More issues with blueprint.....
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, November 23, 2011 11:07:06 AM Timothy Ward wrote:
........... snip .........
> > Note that di is referenced as a return from ExtendedBlueprintContainer.
> > We could remove the method, but again, that causes other backwords
> > compatibility issues.
>
> That is a problem - most probably because we don't have an
> "InternalBlueprintContainer" interface, and we wanted to use it elsewhere
> in blueprint core.
> > The first two above can likely be done just from the BeanMetadata.
> >
> > 1)
> > Class cls = container.loadClass(beanData.getClassName());
> > or:
> > cls = AriesFrameworkUtil.getClassLoader(bundle)
> >
> > .getClass(beanData.getClassName());
>
> Safety would suggest that you need to do the following (and probably that we
> need an API method because it's non obvious) - this should work in 0.3 and
> 0.4:
>
> Class cls = null;
>
> if(beanData instanceof ExtendedBeanMetadata) {
> cls = ((ExtendedBeanMetadata)beanData).getRuntimeClass();
> }
>
> if(cls == null) {
> cls = container.loadClass(beanData.getClassName());
> }
OK. Thanks!
> > The third one is the trickier one as that really needs to call into the
> > runtime. We could add a method on ExtendedBlueprintContainer like:
> >
> > void configureObject(String id, Object obj)
>
> This is certainly a possibility - Would it make more sense to pass a
> BeanMetadata than an id? This prevents you from erroneously using the id of
> a reference, reference list or service. It also allows you to configure
> anonymous beans without relying on a particular name. We would need to
> think about the exception behaviour if the BeanMetadata wasn't a recognized
> bean from this blueprint container - perhaps something like:
>
> /**
> * Inject (or reinject) an Object instance with the blueprint properties
> defined by a BeanMetadata *
> * Throws IllegalArgumentException if the bean metadata does not exist in
> this blueprint container * Throws ComponentDefinitionException if the
> injection process fails - this may have rendered the supplied Object
> unusable by partially completing the injection process */
> void injectBeanInstance(BeanMetadata bmd, Object o) throws
> IllegalArgumentException, ComponentDefinitionException
I guess it would be good to have both options. The one reason I liked the
idea of passing an id (and then throw an exception if invalid) was that it
allows re-using the Recipe's a lot easier. The Recipe's can cache things
like methods and such so reusing them if possible can be a bit of a
performance advantage. If you pass in the BeanMetadata, you would really
need to build a new Recipe from scratch which may take a little longer. That
said, I can see the advantages of doing that as well. :-)
> I'll have a bit more of a think about whether there's a way to do this
> within the existing API exposed by 0.4, but I'm not sure that it is. In any
> event do you (or anyone else) have any thoughts about the relative merits
> of these two proposed methods? Both are implementable, it's more of a
> usage/readability concern for me.
> > Would that work for you? Another suggestion?
>
> One other (above) but I'm definitely not against adding a method with this
> sort of function to the ExtendedBlueprintContainer.
I'll work on getting that added.
THAT said, it doesn't change the fact that 0.4 is no where near backwords
compatible and there wasn't any "migration path" or notice or anything
provided. For 0.4.1, I'd like to re-export the stuff that would be needed to
get CXF 2.4.4 and 2.5.0 working with it with plans to remove those exports in
0.5 so that we have some time to get projects updated. We're kind of in a
catch 22 right now. Karaf cannot really update to 0.4 if it breaks the
projects that generally deploy into Karaf like Camel and CXF, but CXF won't go
up to 0.4 if it cannot deploy into Karaf.
Dan
> > Dan
> >
> > > Regards
> > >
> > > Tim Ward
> > > -------------------
> > > Apache Aries PMC member & Enterprise OSGi advocate
> > > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > > -------------------
> > >
> > > > From: dkulp@apache.org
> > > > To: dev@aries.apache.org
> > > > 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: More issues with blueprint.....
Posted by Timothy Ward <ti...@apache.org>.
A couple of comments in line
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: dkulp@apache.org
> To: dev@aries.apache.org
> CC: timothyjward@apache.org
> Subject: Re: More issues with blueprint.....
> Date: Tue, 22 Nov 2011 15:04:17 -0500
>
> On Tuesday, November 22, 2011 7:34:50 PM 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.
>
> Thanks for that info. I'll add that to the @deprecated javadoc for the
> restored class.
>
> However, they behave differently. The BundleDelegatingClassLoader does take
> an extra classloader that is used to find resources. In my case, I do need
> that behavior. Like I said, I can easily work around this by create a
> classloader that mimics that in CXF.
>
>
> > Clearly the CXF integration is quite involved - what exactly is it that CXF
> > needs the Recipes for?
>
> CXF has several use cases where the bean OBJECTS themselves are created from
> within CXF, but the configuration for those objects is done via blueprint (or
> spring) via abstract bean definitions. We basically need three methods from
> BeanRecipe exposed in some form or another:
>
> 1) Class getType()
> Basically so we can verify that the type of the bean definition is assignable
> to the bean.
>
> 2) Object getProperty(String name)
> (Actually just need to know if the definition HAS the property configured,
> don't really need the value itself)
>
> 3) void setProperties(Object o)
> Actually applies the properties from the configuration to the given object.
>
>
> > 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.
>
> Note that di is referenced as a return from ExtendedBlueprintContainer. We
> could remove the method, but again, that causes other backwords compatibility
> issues.
That is a problem - most probably because we don't have an "InternalBlueprintContainer" interface, and we wanted to use it elsewhere in blueprint core.
>
> The first two above can likely be done just from the BeanMetadata.
>
> 1)
> Class cls = container.loadClass(beanData.getClassName());
> or:
> cls = AriesFrameworkUtil.getClassLoader(bundle)
> .getClass(beanData.getClassName());
>
Safety would suggest that you need to do the following (and probably that we need an API method because it's non obvious) - this should work in 0.3 and 0.4:
Class cls = null;
if(beanData instanceof ExtendedBeanMetadata) {
cls = ((ExtendedBeanMetadata)beanData).getRuntimeClass();
}
if(cls == null) {
cls = container.loadClass(beanData.getClassName());
}
> 2)
> for (BeanProperty p : beanData.getProperties()) {
> if (name.equals(p.getName())) {
> return true;
> }
> return false;
>
This looks like a good solution for 2)
> The third one is the trickier one as that really needs to call into the
> runtime. We could add a method on ExtendedBlueprintContainer like:
>
> void configureObject(String id, Object obj)
>
This is certainly a possibility - Would it make more sense to pass a BeanMetadata than an id? This prevents you from erroneously using the id of a reference, reference list or service. It also allows you to configure anonymous beans without relying on a particular name. We would need to think about the exception behaviour if the BeanMetadata wasn't a recognized bean from this blueprint container - perhaps something like:
/**
* Inject (or reinject) an Object instance with the blueprint properties defined by a BeanMetadata
*
* Throws IllegalArgumentException if the bean metadata does not exist in this blueprint container
* Throws ComponentDefinitionException if the injection process fails - this may have rendered the supplied Object unusable by partially completing the injection process
*/
void injectBeanInstance(BeanMetadata bmd, Object o) throws IllegalArgumentException, ComponentDefinitionException
I'll have a bit more of a think about whether there's a way to do this within the existing API exposed by 0.4, but I'm not sure that it is. In any event do you (or anyone else) have any thoughts about the relative merits of these two proposed methods? Both are implementable, it's more of a usage/readability concern for me.
>
> Would that work for you? Another suggestion?
>
One other (above) but I'm definitely not against adding a method with this sort of function to the ExtendedBlueprintContainer.
>
> Dan
>
>
>
> >
> > Regards
> >
> > Tim Ward
> > -------------------
> > Apache Aries PMC member & Enterprise OSGi advocate
> > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > -------------------
> >
> > > From: dkulp@apache.org
> > > To: dev@aries.apache.org
> > > 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: More issues with blueprint.....
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, November 22, 2011 7:34:50 PM 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.
Thanks for that info. I'll add that to the @deprecated javadoc for the
restored class.
However, they behave differently. The BundleDelegatingClassLoader does take
an extra classloader that is used to find resources. In my case, I do need
that behavior. Like I said, I can easily work around this by create a
classloader that mimics that in CXF.
> Clearly the CXF integration is quite involved - what exactly is it that CXF
> needs the Recipes for?
CXF has several use cases where the bean OBJECTS themselves are created from
within CXF, but the configuration for those objects is done via blueprint (or
spring) via abstract bean definitions. We basically need three methods from
BeanRecipe exposed in some form or another:
1) Class getType()
Basically so we can verify that the type of the bean definition is assignable
to the bean.
2) Object getProperty(String name)
(Actually just need to know if the definition HAS the property configured,
don't really need the value itself)
3) void setProperties(Object o)
Actually applies the properties from the configuration to the given object.
> 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.
Note that di is referenced as a return from ExtendedBlueprintContainer. We
could remove the method, but again, that causes other backwords compatibility
issues.
The first two above can likely be done just from the BeanMetadata.
1)
Class cls = container.loadClass(beanData.getClassName());
or:
cls = AriesFrameworkUtil.getClassLoader(bundle)
.getClass(beanData.getClassName());
2)
for (BeanProperty p : beanData.getProperties()) {
if (name.equals(p.getName())) {
return true;
}
return false;
The third one is the trickier one as that really needs to call into the
runtime. We could add a method on ExtendedBlueprintContainer like:
void configureObject(String id, Object obj)
Would that work for you? Another suggestion?
Dan
>
> Regards
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
> > From: dkulp@apache.org
> > To: dev@aries.apache.org
> > 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: More issues with blueprint.....
Posted by Timothy Ward <ti...@apache.org>.
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: dkulp@apache.org
> To: dev@aries.apache.org
> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com