Reflection and MetaDataRepository refactoring

[adrian.brock]

The devil is always in the detail ;-)

I've found a couple of other wrong dependencies while splitting out this code.

The first is the ArrayInfo using the Signature class from the metadata repository
to determine primitive array class information.
This should clearly be delegating to PrimitiveInfo in both cases.

The second is this horrible method in BeanInfo

 /**
 * Bean may have additional dependencies
 * that the kernel cannot initially resolve. (currently defined by ClassAdapter)
 *
 * @param metaData the metadata
 * @return the list of dependencies
 */
 List<DependencyBuilderListItem<?>> getDependencies(MetaData metaData);

This has always bothered me since we first started the aop integration.
It doesn't really belong there. It's really part of the Kernel api.

The original intention isn't even used (instance ClassAdapters for AOP
instance containers).

And the latest rev has some horrible opaque type which is seen here in
the

<?>

which is actually the KernelControllerContext.

The issue came up again since it causes jboss-reflection to be based
on the metadata repository for no logical reason.

I'm finally going to bite the bullet and move this api to the kernel project
and remove all reference to the DependencyBuilder from the reflection project.

Like I said only aop-mc-int implements it and then only from the MC Pojo lifecycle.

[adrian.brock]

Additionally, the DependencyBuilderListItem also needs a removeDependency()
method, but I'll take that up with Kabir seperately.

He needs to write a proper test for redeploying changing aop dependencies
without undeploying the bean which will show why this a problem.

[adrian.brock]

Since this has been more work than I thought, I'm going to do
beta10 releases of these projects and validate it integrates back into the
microcontainer, aop and jbossxb projects before doing the CR1s.

[adrian.brock]

I'm well behind schedule on this :-(

I thought it would take me a couple of hours on Monday and most of that
would maven problems ;-)

Anyway its been a good excercise none the less,
because I've found and fixed a lot of problems that I wouldn't otherwise have known existed.

[adrian.brock]

Tomorrow I'm going to upgrade the MC project to
the new jboss-reflection and jboss-mdr projects.

Unfortunately, I didn't catch Alex before he left the office to get approval
for a jboss-xb release, so I'll do a snapshot until I can speak to him next week.

I also want to put some JBossXB testsuite support in JBossXB
so each project doesn't have to write their own jbossxb test harness
like we do now, so that's probably not a bad thing anyway since it isn't done yet.

Once I've completed this, the other projects will (hoperfully :-) be lot a easier
since they are already in a sane state unlike the tangled web that the container
project had become. ;-)

We can also remove the schema initialization hacks from our test code
since that will be provided by JBossXB factory settings.