[alesj]

We can't use this approach in this case:

 <bean name="parameterObject1" class="org.jboss.test.kernel.inject.support.ParameterTestObject">
 <constructor>
 <parameter><inject/></parameter>
 </constructor>
 </bean>

Fail if up to this point no matching bean has been instantiated?

[adrian.brock]

I don't understand?

It should fail if the inject cannot find a target.

When it works, it should look like this:
(C1) Context1: Your bean above
(C2) Context2: Implements the class

C1: preprocess/Describe - we need somebody to implement the parameter class
C2: .../Instantiate/etc. - I implement it
C1: Can now proceed to instantiation using C2 as the iDependOn

If there is no C2, then it is an error.

[alesj]

I don't understand?

It should fail if the inject cannot find a target.

When it works, it should look like this:
(C1) Context1: Your bean above
(C2) Context2: Implements the class

C1: preprocess/Describe - we need somebody to implement the parameter class
C2: .../Instantiate/etc. - I implement it
C1: Can now proceed to instantiation using C2 as the iDependOn

If there is no C2, then it is an error.

Ok, this is written for property case - and is already commited.

In property case I can later (still in describe state) get the actual property class type.

How to get to class in different parameter injection cases:

 <bean name="parameterObject1" class="org.jboss.test.kernel.inject.support.ParameterTestObject">
 <constructor>
 <parameter><array><inject/></array></parameter>
 </constructor>
 </bean>

Crawl back all to the constructorMD / parameterMD for some info which will help me in 'placeholder' dependency item?

[adrian.brock]

Nope. It is still broken.

You should not modify the BeanMetaData inside the Kernel.
This is a representation of what the user wants.

What you have done is added a reference to the class in the SuppliesMetaData
which once the bean gets uninstalled will cause a memory leak.

UninstalledBeanMetaData (waiting to get reinstalled) ->
SuppliesMetaData -> Class -> ClassLoader (that is supposed to be
garbage collected).

I don't even see why you are doing this?
All you need to do is to modify the kernel registry plugin entry point
getEntry() to use your contextsByClass.
http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/registry.html#registryfactory-overview

Did you try running the full testsuite? org.jboss.test.KernelAllTestSuite.
or from the command line
./build.sh -f build-test.xml tests

There are currently 38 failures and 1 error.

[adrian.brock]

"alesj" wrote:

How to get to class in different parameter injection cases:

 <bean name="parameterObject1" class="org.jboss.test.kernel.inject.support.ParameterTestObject">
 <constructor>
 <parameter><array><inject/></array></parameter>
 </constructor>
 </bean>

Crawl back all to the constructorMD / parameterMD for some info which will help me in 'placeholder' dependency item?

That is more difficult. The current way it works is based on the
injected type deciding which method/constructor gets used
(by matching the passed types to the parameter types).

What you are trying to do is the reverse which currently has
no infrastructure to support it.

It is also an unsolvable problem in general:

e.g.

public class MyClass
{
 public MyClass(Type1 type1) {}
 public MyClass(Type2 type2) {}
}

Which type should I use Type1 or Type2?
The only way to resolve it would be:

 <parameter class="Type1"><inject/></parameter>

[adrian.brock]

"alesj" wrote:

Crawl back all to the constructorMD / parameterMD for some info which will help me in 'placeholder' dependency item?

These should be available in the MetaDataVisitor.
i.e. create a "stack" of previously visited objects in the branch,
so in the case above you would have:

BeanMetaData
ConstructorMetaData
ParameterMetaData
ArrayMetaData

in the "stack".

[alesj]

Is there a view of all possible usage?

So that I know where and how to look for useful injection information in this MetaData stack.

[alesj]

"alesj" wrote:
Is there a view of all possible <injection /> usage?

So that I know where and how to look for useful injection information in this MetaData stack.

Ups, forum ate xml.

Is there a view of all possible

<injection />

usage?

So that I know where and how to look for useful injection information in this MetaData stack.

[adrian.brock]

"alesj" wrote:
Is there a view of all possible <injection /> usage?

You mean besides the xsd? :-)

So that I know where and how to look for useful injection information in this MetaData stack.

I don't know how you would define something abstract.
The information you want comes from the BeanInfo
not the MetaData. The MetaData is just the key.

e.g. className + property name -> getBeanInfo(className).getProperty(name).getType();

It is even more complicated for parameters since then you
have to iterate to constructors and do a "fuzzy match"
to try to guess which constructor they mean.

The current logic is in the Configurator for matching joinpoints.

My guess would be that you would need to:
1) Implement the revisit() of the meta data such that
you have the metadata context after the BeanInfo has been
determined. a simple way to be to add a visitDescribed() path.

2) The ADVMD then asks its parent on the stack getClass();

which will for a property
3a) Do context.getBeanInfo().getProperty(myName) and return the type

for a parameter
4a) Ask the constructor/beanMetaData to guess which constructor
will be used from the BeanInfo.getConstructors() and then
determine the class from this.

The factory and create/.../destroy/install will be the same as the
constructor except at least for the factory/install they will have
to retrieve the bean info for a different type.

Again all this code is in the Configurator in terms of resolving/guessing
the specific info.

[adrian.brock]

Of course, every metadata class that takes part in this would need
to implement an interface that defines the getType(),

e.g. based on what was retrieved from the stack
advmd -> (NewInterface) propertyMetaData.getType()
advmd -> (NewInterface) parameterMetaData.getType() -> (NewInterface) constructor.getType()

Also, for the parameters, there would need to be some notion
of "index" so you know which parameter you are working with.

[adrian.brock]

The alternative which is to fix it up by hand in the DescribeAction
(like you are doing now with the placeholder) is not very extensible
going forwards. It really needs a visitor pattern.

[alesj]

The alternative which is to fix it up by hand in the DescribeAction
(like you are doing now with the placeholder) is not very extensible
going forwards. It really needs a visitor pattern.

Ok, forget then about 'placeholder' approach?

Rewrite it to revisit pattern +

Of course, every metadata class that takes part in this would need
to implement an interface that defines the getType(),

e.g. based on what was retrieved from the stack
advmd -> (NewInterface) propertyMetaData.getType()
advmd -> (NewInterface) parameterMetaData.getType() -> (NewInterface) constructor.getType()

Also, for the parameters, there would need to be some notion
of "index" so you know which parameter you are working with.

?

Calling revisit from where - ConfiguredAction - though AbstractKernelCOntrollerContext?

public void setController(Controller controller)
 {
 super.setController(controller);
 preprocessMetaData();
 }

[adrian.brock]

"alesj" wrote:

Ok, forget then about 'placeholder' approach?

Yes. It was only a temporary solution so you wouldn't have
to mess around with the visitor.

Calling revisit from where - ConfiguredAction - though AbstractKernelCOntrollerContext?

From the DescribeAction.

 BeanMetaData metaData = context.getBeanMetaData();
 if (metaData.getBean() != null)
 {
 BeanInfo info = configurator.getBeanInfo(metaData);
 context.setBeanInfo(info);

 <snipped/>

 describeMetaData(); // similar to preprocessMetaData();
 }

The first visit is to read the metadata that can be determined
without the classloader/class (which up until now has been
all of it except the AOP stuff).

The second visit is once the class is resolved and the BeanInfo
is available.

public interface MetaDataVisitor[Node]
{
 void initialVisit(...); // the original visit(...)
 void describeVisit(...);
}

You can then do all your processing in the describe visit
knowing that context.getBeanInfo() will be available.

[alesj]

I don't even see why you are doing this?
All you need to do is to modify the kernel registry plugin entry point
getEntry() to use your contextsByClass.
http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/registry.html#registryfactory-overview

Ok, I added this code to AbstractKernelController.getEntry

 else if (name instanceof Class)
 return getContextByClass((Class)name);

But this should probably be in a seperate KernelRegistryPlugin impl (requires KernelController).

Where to register/unregister such plugin into KernelRegistry?
Or where to install/uninstall instance - so that it gets automatically picked up by KernelRegistry?

[alesj]

What you have done is added a reference to the class in the SuppliesMetaData
which once the bean gets uninstalled will cause a memory leak.

UninstalledBeanMetaData (waiting to get reinstalled) ->
SuppliesMetaData -> Class -> ClassLoader (that is supposed to be
garbage collected).

Ok, this is then the same as If I would set a value (the demaning class) in the AbstractDependencyMD?

So class should only be set in the 'placeholder' DependencyItem? No memory leak problem there?

As for MDV[]Node.describeVisit() - it should not add any class refs to MetaData then?