Any progress with spring-me?

[Paul]

Hi,

I've been having a look at spring-me for an Android project I'm
working on, and my experiences with spring-me have been promising.

I've noticed a couple of possible bugs though, while working on my
app:

+ Bean definitions that refer to a parent definition should be merged
with the parent before loading the instance,
+ Abstract bean definitions should not be generated as a bean in the
generated factory (unless we find a way to reuse that bean creation
code in the generated factory),
+ The content of the <value> tag in a <list> was always returning
null. So I changed the context.stg to use "it.type" in the
"addElement" macro. Sorry if I've got the terminology wrong, I've
never seem stringtemplate before!

Otherwise, it seems to work very well for me!

I was wondering if there has been any further progress with the
project?

Paul.

[Wilfred Springer]

Hi Paul, 

I've been having a look at spring-me for an Android project I'm
working on, and my experiences with spring-me have been promising.

That's nice to hear. It also worked quite well on our TomTom navigator project.

 

I've noticed a couple of possible bugs though, while working on my
app:

+ Bean definitions that refer to a parent definition should be merged
with the parent before loading the instance,

Now, I haven't touched Spring ME for more than a year, so I'm trying to figure out what this means. A test case would be awesome.

 

+ Abstract bean definitions should not be generated as a bean in the
generated factory (unless we find a way to reuse that bean creation
code in the generated factory),

+1. I totally agree. I guess we need a bug report for that.

 

+ The content of the <value> tag in a <list> was always returning
null. So I changed the context.stg to use "it.type" in the
"addElement" macro. Sorry if I've got the terminology wrong, I've
never seem stringtemplate before!

Whoops. Glad you caught that. If you send me the patch, then I can see if I can weave it back in. Having an associated test case would be awesome though. (See the end of the email.)

 

Otherwise, it seems to work very well for me!

That's awesome.

 

I was wondering if there has been any further progress with the
project?

Well, not really. But the good news is: I got my new Android phone today, so it's starting to make sense to consider working on it again. ;-)

The problem is, none of te original developers is currently working on a 'Java'-based device project. So I think we could really use some people joining in. If you feel like it, I'd be happy to spend some time and get you familiar with our original thoughts, and some ideas that we considered. How about it?

 

Paul.

--
You received this message because you are subscribed to the Google Groups "Spring ME" group.
To post to this group, send email to spri...@googlegroups.com.
To unsubscribe from this group, send email to spring-me+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spring-me?hl=en.

[Paul]

Hi Wilfred,

Thanks for the prompt reply!

***ISSUE #1 AND ISSUE #2***

If you look at the "inheritedTestBean" and
"inheritsWithDifferentClass" bean definitions at the following URL:

http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-child-bean-definitions

You will see that the "inheritedTestBean" is defined as abstract. Now,
in version 1.0 of the code I've been using, the static
"me.springframework.di.spring.SpringConfigurationLoader.load(BeanDefinitionRegistry)"
method would not take into account the fact that the bean definition
is abstract. So a bean would be created called "inheritedTestBean".
But the definition is defined as abstract, and so a bean should not be
directly created from this.

Now, the "inheritsWithDifferentClass" bean created by spring-me would
not recognise the fact that there is a "parent" attribute defined, and
so it would ignore the parent bean definition's configuration. What
should happen, is the bean definition for "inheritsWithDifferentClass"
should be merged with that of "inheritedTestBean". Unfortunately, the
"getMergedBeanDefinition" is only accessible to
"org.springframework.beans.factory.config.ConfigurableBeanFactory", so
we need to pass an instance of this to the load method. But
"org.springframework.beans.factory.config.ConfigurableBeanFactory"
does not have the "getBeanDefinitionNames" method! So we either need
to pass a
"org.springframework.beans.factory.support.DefaultListableBeanFactory"
class, which supports both methods, or pass in a BeanRegistry and
ConfigurableBeanFactory separately. For example:

private static Map<String, MutableInstance>
load(DefaultListableBeanFactory registry) {
Map<String, MutableInstance> instances = new HashMap<String,
MutableInstance>();
for (String name : registry.getBeanDefinitionNames()) {
// ***CHANGE*** Ignore abstract definitions and use merged
definition for ALL bean definitions
BeanDefinition definition =
registry.getBeanDefinition(name);
if (!definition.isAbstract()) {
BeanDefinition mergedDefinition =
registry.getMergedBeanDefinition(name);
MutableInstance instance = new MutableInstance(name);
load(instance, mergedDefinition);
instances.put(name, instance);
}
}
return instances;
}

The abstract definitions are ignored, as beans should not be created
from these and ALL bean definitions are merged in case they inherit
from other bean definitions.


I'm not too sure how to send you a patch, Wilfred. If you can advise I
would be more than happy to!


Great news regarding your Android phone! I'm still using my HTC Magic,
but contract is up in September so hope to upgrade to something like
the HTC Desire or Samsung Galaxy!

Am happy to talk further about the project's current status and future
goals.


Paul.