myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Issue 2995 - Leo please read
Date Fri, 11 Feb 2011 18:23:48 GMT

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