Breaking up CoreDeploymentInfo

[David Blevins <da...@visi.com>]

One thing that's become clear in digging around in @Inject (330) and CDI(299) lands is that it that our CoreDeploymentInfo object is just too large and unwieldy.

This is not really a surprise, but looking at it with fresh eyes I can see how refactoring it a bit is going to make a few things much easier.  Currently working on splitting it up as follows:


  CoreDeploymentInfo
    has a BeanContext
            has a ModuleContext
                    has a AppContext

And AppContext has a non static reference to SystemInstance -- hopefully we can get rid of a few statics while where at it.  Might end up changing the logical parent of AppContext, but the idea is obvious -- to be able to walk your way back to the top (or bottom depending on perspective :).

Next step is to maybe consider a finer scoped MethodContext object where we can finally store per-method metadata like TransactionPolicy and whatnot, rolling over to BeanContext if we don't find an explicit value.  When we add new method-level features, it will be a lot easier than putting yet another map in the CoreDeploymentInfo object that links a method to an arbitrary piece of data.

This also aligns a little better with the new java:global, java:app and java:module scopes.  We'll likely need to be pushing some new metadata through the AppInfo and EjbJarInfo to hold new JNDI and other data.  As well the extra scopes will make it slightly easier to slot in the BeanManager and start sharing data and the appropriate level.

That's the working theory.  Thoughts welcome!


-David