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: [email protected] > To: [email protected] > CC: [email protected] > 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: [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
