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 <[email protected]> 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 <[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 > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
