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 <[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
