geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: svn commit: r774319 - in /geronimo/sandbox/blueprint: ./ blueprint-bundle/ blueprint-core/ blueprint-core/src/main/java/org/apache/xbean/ blueprint-core/src/main/java/org/apache/xbean/recipe/
Date Wed, 13 May 2009 21:08:19 GMT
Currently, the whole conversion strategy is broken in blueprint
because we do not use the conversion service as it is supposed too.
Furthermore, the constructor matching and factory method matching
completely fails in some cases because xbean recipes are not 'typed'.
This means that for a given recipe, you don't really know what kind of
object will be created.  This leads to disambiguation not working for
constructors and factory methods.

Let's take a simple example:

class A {
   public A(Map map) {
   }
   public A(Properties props) {
   }
}

with the following definition:

<bean id="a" class="A">
   <argument>
     <props></props>
   </argument>
</bean>

XBean is not able to hande that because a MapRecipe will be created,
but more than one method can be used and the whole disambiguation in
xbean is based on whether a given recipe can create that kind of
objects or not.   You don't have any way to have the best match in
those cases.

So what i did is add a getTypes() method that usually return a single
class (I think multiple values will be needed for references which can
be injected as ServiceReference or proxies).

Anyway, I have no problem discussing the path we want to go, but I
really don't like the current state we're in: the code becomes too
complicated because the roughty had to rewrite the whole factory stuff
in blueprint instead of xbean and it is broken due to not using the
conversion service correctly for disambiguation.
We need to choose one way, as I explained in another thread some time ago:
  * either put what we need in xbean-reflect (factories, better
disambiguation, etc...)
  * or 'fork' it and tweak it to be able to natively handle all the
blueprint requirements
I think the risk of destabilizing openEjb and gbeans are too high to
go for the first solution, so i was heading to the second one.

On Wed, May 13, 2009 at 22:46, Jarek Gawor <jgawor@gmail.com> wrote:
> Guillaume,
>
> Can you explain why this is necessary? I really don't want to 'fork'
> xbean-reflect.
>
> Jarek
>
> On Wed, May 13, 2009 at 9:09 AM,  <gnodet@apache.org> wrote:
>> Author: gnodet
>> Date: Wed May 13 13:09:33 2009
>> New Revision: 774319
>>
>> URL: http://svn.apache.org/viewvc?rev=774319&view=rev
>> Log:
>> Inline xbean to be able to refactor the conversion mechanism and allow better matching
of arguments against constructors / factory methods
>>
>> Added:
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/
>>      - copied from r774242, geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/recipe/
>> Removed:
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/AsmParameterNameLoader.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/RecipeVisitor.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/StaticRecipe.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/UnsetPropertiesRecipe.java
>> Modified:
>>    geronimo/sandbox/blueprint/blueprint-bundle/pom.xml
>>    geronimo/sandbox/blueprint/blueprint-core/pom.xml
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/AbstractRecipe.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/ObjectRecipe.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/Recipe.java
>>    geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/xbean/recipe/RecipeHelper.java
>>    geronimo/sandbox/blueprint/pom.xml
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message