Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to the el-impl most of the times. (sadly)
LieGrue, strub --- On Fri, 2/11/11, David Jencks <david_jen...@yahoo.com> wrote: > From: David Jencks <david_jen...@yahoo.com> > Subject: Re: Issue 2995 - Leo please read > To: "MyFaces Development" <dev@myfaces.apache.org>, "Leonardo Uribe" > <lu4...@gmail.com> > Date: Friday, February 11, 2011, 6:23 PM > > 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 > >
