Thanks much for your response and alternative productivity tip, JRebel. JRebel is a great tool , and I am already using it, but it only goes so far, and still requires redeploy for a variety of circumstances. Further, I'd like to find a solution for the team and the community at large that doesn't require a tool such JRebel, since not all folks and teams can obtain or manage use of JRebel.
Nicklas Karlsson wrote:
The CDI spec statement has an implied "according to the class accessibility requirements of the module architecture of the Java EE specification". Even if the classloading could be configured in an AS to do some special trick, CDI has the visibility rules of a standard EE app (EAR/WAR/JAR).
What you characterize as a "special trick", I might characterize as a "useful application of the wonderful JBoss module system" :)
It sounds like you are saying based on this spec that EARs, WARs, and even JARs should not have class visibility from say, another war. If that is true, then it seems like the Inter-module injection part of the spec can never be satisfied in any useful way, since that class accessibility requirement can never be satisfied.
Also, I can sort of understand this tight accessibility restriction for EARs and WARs, but surely just JAR deployables are accessible by other deployables, since jar deployable are basically the same as a module. I thought there was even a concept of a "bean archive" jar that other deployables can take advantage.
Also, I'm a bit surprised that such an action is considered violating the visibility rules, since the classes are accessible.visible via jndi lookup and via Class.forName(). Unless I'm missing something, it seems like an inconsistency then that one can then currently do an @EJB("java:/global/my-ejb-jar.jar/SomeBean") but not do a simpler @Inject instead. The classes are clearly accessible from a jndi lookup perspective and and a Class.forName() perspective, but not accessible from a CDI @Inject perspective. From inside the war, I'm even able to use the BeanManager instance from the dependent jar to do getBeans() on beans from the dependent jar to get at a jar bean, but not with @Inject.
Assuming there is no such solution, might it be possible to roll my own solution using a CDI hook/extension? If I am able to hook into the CDI bean resolution logic in the front-end war (I haven't studied if/how this can be done), then I would be able to lookup across the module using the technique that I have working described above where I have a bridge into the dependent jar exposing that deployable's BeanManager.
~Tom