[JBoss-dev] Moving to thread local enc/metadata generalization

[Scott M S. <sco...@jb...>]

So I have an update to the java:comp/env implementation that:

1. Replaces the thread context class loader based ENCFactory with the 
ThreadLocalENCFactory from ejb3 (moved to naming module).
2. Updates the ejb2.x and web containers to use this for the 
java:comp/env context.
3. Updates the ejb2.x and web containers to expose the java:comp/env 
context ad read-only using the org.jboss.util.naming.ReadOnlyContext util.
4. Updates the JndiView service to be able to list both war and ejb 
java:comp/env contexts.

Issues:

1. The read-only contexts may break existing apps/integration code 
trying to augment the component contexts.
2. ejb3 has its own implementation. Probably not a huge deal as the enc 
is a component local notion, but it needs to be accessible from 
management tools such as JndiView.
3. This is only a subset of the runtime component metadata that should 
be available to aspects. Another example is the deployment local 
property editors. We need a cohesive view in the new mc/jboss5. The 
issue is thinking about how we evolve jboss-4.0.x to allow for the newer 
stacks without breaking legacy uses.

The real question/point of this message is, what is the next step in 
runtime metadata abstraction that allows us to move both 4.0.x and 5.0.x 
forward with support for these features such that is not a support and 
maintence nightmare as the mc comes online. A solid, hierarchical 
metadata framework is needed. It needs to merge the disperate legacy 
view, aop, ejb3, mc and webservices usecases.