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 >
