myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Issue 2995 - Leo please read
Date Fri, 11 Feb 2011 18:47:39 GMT
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_jencks@yahoo.com> wrote:

> From: David Jencks <david_jencks@yahoo.com>
> Subject: Re: Issue 2995 - Leo please read
> To: "MyFaces Development" <dev@myfaces.apache.org>, "Leonardo Uribe" <lu4242@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
> 
> 


      

Mime
View raw message