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