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.
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());
2)
for (BeanProperty p : beanData.getProperties()) {
if (name.equals(p.getName())) {
return true;
}
return false;
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)
Would that work for you? Another suggestion?
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
