On Wednesday, November 23, 2011 11:07:06 AM Timothy Ward wrote:
........... snip .........
> > 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());
> }
OK. Thanks!
> > 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 guess it would be good to have both options. The one reason I liked the
idea of passing an id (and then throw an exception if invalid) was that it
allows re-using the Recipe's a lot easier. The Recipe's can cache things
like methods and such so reusing them if possible can be a bit of a
performance advantage. If you pass in the BeanMetadata, you would really
need to build a new Recipe from scratch which may take a little longer. That
said, I can see the advantages of doing that as well. :-)
> 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.
I'll work on getting that added.
THAT said, it doesn't change the fact that 0.4 is no where near backwords
compatible and there wasn't any "migration path" or notice or anything
provided. For 0.4.1, I'd like to re-export the stuff that would be needed to
get CXF 2.4.4 and 2.5.0 working with it with plans to remove those exports in
0.5 so that we have some time to get projects updated. We're kind of in a
catch 22 right now. Karaf cannot really update to 0.4 if it breaks the
projects that generally deploy into Karaf like Camel and CXF, but CXF won't go
up to 0.4 if it cannot deploy into Karaf.
Dan
> > 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
