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
