Hi David There are some points to take into consideration for myfaces-api jar
1. It is preferred that myfaces-api have the less amount of "compile" or "runtime" dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with "myfaces-api" and "myfaces-impl" it is required to include "myfaces-api-spi" in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep "coherence" with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an "unofficial" extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. Now, let's review the previous response: DJ>> This is NOT for osgi. The ee classloading model does not require a separate DJ>> classloader for each war in an ear, whereas currently the myfaces api implementation DJ>> assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is "almost" every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. regards, Leonardo Uribe
