On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: > 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).
I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). > > 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. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. > > 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. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. > > 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. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks > > regards, > > Leonardo Uribe
