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: Wed, 23 Nov 2011 10:22:54 -0500
>
> On Wednesday, November 23, 2011 11:07:06 AM Timothy Ward wrote:
>
> ........... snip .........
>
> > > 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 would expect the container to be using the cached recipe for the BeanMetadata
version. I wasn't expecting that you could provide an arbrtrary metadata, only
ones that were already defined in the blueprint container. These could be
obtained from getComponentMetadata(id) or getMetadata(BeanMetadata.class), or
from some part of the nested hierarchy of a BeanMetadata (e.g. a nested bean in
a property). The IllegalArgumentException was to be thrown if the BeanMetadata
wasn't one recognised by the blueprint container.
>
> > 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.
Which one? I'd rather just have the second as it provides equivalent function -
I like the additional type safety (knowing that we won't get something that's
not a bean), and the fact that we can't get given invalid id strings. It
probably wouldn't be too much of an effort to get it to accept arbitrary
metadata either.
>
> 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
