Spring-int schema support

[alesj]

I'm just going through Spring xml schema and there are a couple of features that need to be discussed if we really want to support them.

First here are some that I think are useful to be added to existing bean metadata support:
- parent (http://www.springframework.org/docs/reference/beans.html#beans-child-bean-definitions)
- abstract (same link as parent)

After you have these previous two, there is a 'merge' option on collections:
- http://www.springframework.org/docs/reference/beans.html#beans-collection-elements
Which is probably trivial to implement.

There are two that fit in the ConfigureAction:
- autowire (http://www.springframework.org/docs/reference/beans.html#beans-factory-autowire)
- dependency-check (http://www.springframework.org/docs/reference/beans.html#beans-factory-dependencies)
I already added support for optional 'autowire-candidate' aka 'contextual-injection-candidate'.

'scope' element will probably be handled by our kernel scoping impl - additional API on top of deployers?

And two more which can probably be handled by our aspectized MC configuration:
- lookup-method (http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection)
- replaced-method (http://www.springframework.org/docs/reference/beans.html#beans-factory-arbitrary-method-replacement)
Kabir?
How to integrate this with Joinpoint instantiation?

Some of them have a 'global' deployment default value.

What's the deal with all those lifecycle, aware, post-callback interfaces:
- http://www.springframework.org/docs/reference/beans.html#beans-factory-nature
- http://www.springframework.org/docs/reference/beans.html#beans-factory-extension
We can probably wrap most of them into MC features.
How to get classes into classpath? Meaning, can we ship our own small artifact/jar with just those interfaces?
So that the notion of not needing full blown Spring IoC is still there. ;-)

[alesj]

Is this feature meaningful (to be imported into MC features):
- http://www.springframework.org/docs/reference/beans.html#beans-factory-xml-import
Since in our case those files will be scanned and deployed in the same controller anyway.
Probably this should be just a Spring-int addon.

[adrian.brock]

You can do this with XInclude and JBossXB.

<?xml version="1.0" encoding="UTF-8"?>



<deployment xmlns="urn:jboss-bean-deployer:2.0"
 xmlns:xi="http://www.w3.org/2001/XInclude">

 <xi:include href="someurl"/>

 <bean .../>
</deployment>

Why reinvent when there is already a standard?

[alesj]

You can do this with XInclude and JBossXB.

<?xml version="1.0" encoding="UTF-8"?>



<deployment xmlns="urn:jboss-bean-deployer:2.0"
 xmlns:xi="http://www.w3.org/2001/XInclude">

 <xi:include href="someurl"/>

 <bean .../>
</deployment>

Why reinvent when there is already a standard?

Hehe.
We should ask this the Spring guys. :-)

What about other stuff - 1st post?

[adrian.brock]

The only difference I can see between XInclude and the Spring include
is that with XInclude it is a fragment, i.e.

<bean/>
<bean/>

whereas the Spring include is a full document, i.e. in the Microcontainer
it would be

<deployment>
 <bean/>
 <bean/>
</deployment>

[kabirkhan]

"alesj" wrote:

And two more which can probably be handled by our aspectized MC configuration:
- lookup-method (http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection)
- replaced-method

Adding this should be pretty trivial and can be done from the AOPConstructorJoinPoint. How will I know that this is the thing to do though? i.e. where will I find whatever the following becomes:

 <lookup-method name="createCommand" bean="command"/>

This needs to be something that is visible from aop-mc-int, which we probably do not want to make dependent on spring-int.

"alesj" wrote:

(http://www.springframework.org/docs/reference/beans.html#beans-factory-arbitrary-method-replacement)

This can be implemented as an aspect for the affected methods. How will I get hold of

 <replaced-method name="computeValue" replacer="replacementComputeValue">
 <arg-type>String</arg-type>
 </replaced-method>

[alesj]

This needs to be something that is visible from aop-mc-int, which we probably do not want to make dependent on spring-int.

Sure, absolutely no aop-mc-int --> spring-int dependency.

But we are thinking of enabling such features from other IoC frameworks on top of existing core MC code, since as you can see MC already provides such architecture that implementing this is trivial. :-)

If you could provide me with some pseudo code or point me to some hooks (into aop-mc-int) on where I can plugin this features from the kernel module.

[kabirkhan]

Maybe another subclass of AOPContructorJoinPoint that is used for spring-int? I don't know if having spring-int depending on aop-mc-int is viable?

One issue with http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection is that we need to replace the original abstract class with the generated concrete class.

[alesj]

Maybe another subclass of AOPContructorJoinPoint that is used for spring-int? I don't know if having spring-int depending on aop-mc-int is viable?

Like I said, I think we can push this into main kernel module, but as an optional feature depending on aop-mc-int.

One issue with http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection is that we need to replace the original abstract class with the generated concrete class.

What's the issue?

[adrian.brock]

These look like AOP features to me and would be better implemented
with something more flexible than specific config options.

I'd do it in a spring-aop-int project and translate the spring xml into aop/bean xml, e.g.

<aop:generated-lookup-factory name="commandManager" class="fiona.apple.CommandManager" method="createCommand" bean="command"/>

when you are asked for getBeans();

Fundamentally, you can write any BeanMetaFactory you like
whether it a GenericBeanFactory, an AOP generated class or a CGLIB/javassist
generated class doesn't really matter.

You can always hide the implementation details in your getBeans() :-)

[kabirkhan]

"alesj" wrote:

One issue with http://www.springframework.org/docs/reference/beans.html#beans-factory-lookup-method-injection is that we need to replace the original abstract class with the generated concrete class.

What's the issue?

Simply that from the "beans-factory-lookup-method-injection" example, we cannot instantiate/install CommandManager itself since it is abstract. Instead we would need to install the generated sub-class

[alesj]

Simply that from the "beans-factory-lookup-method-injection" example, we cannot instantiate/install CommandManager itself since it is abstract. Instead we would need to install the generated sub-class

Sure.
But isn't this just a matter of providing right 'bean factory' (as Adrian suggested)?

[kabirkhan]

Yes, something along those lines

[kabirkhan]

I was just reiterating the "issue". The issue is definitely solveable :-)