That is the goal of the cdi module i'm working on.
What's going on:
* weld-servlet.jar will be present on the server classloader
* the optional jsp and el modules are pulled in as dependent on weld ([a different bug I need to file|http://stackoverflow.com/questions/26287696/how-to-use-cdi-weld-without-javax-el-and-javax-servlet-jsp-in-classpath])
* a custom DeploymentManager binding is attached to the "deploying" phase.
causing each deployed WebAppContext to have the following applied automatically.
+ ** a init-parameter set with ...
name = org.jboss.weld.environment.container.class
value = org.jboss.weld.environment.jetty.JettyContainer
+ ** the following server classloader classes/hierarchies are exposed to the webapp's classloader, and not allowed to be overridden by classes that might be in the WebApp itself (in WEB-INF/classes or WEB-INF/lib)
org.eclipse.jetty.servlet.ServletContextHandler.Decorator
org.jboss.weld.*
org.jboss.classfilewriter.*
org.jboss.logging.*
com.google.common.*
+ ** a jndi env reference is created
class = javax.enterprise.inject.spi.BeanManager
factory = org.jboss.weld.resources.ManagerObjectFactory
I'm thinking I need a sanity check for the missing {{beans.xml}}, maybe even use that as a checkpoint on if these actions should be performed on the deploying WebAppContext or not (in the use case where there are multiple webapps being deployed with only some using CDI)
|
