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

Reply via email to