On 1/25/07, lightbulb432 <[EMAIL PROTECTED]> wrote:
Thanks for your insights. Is there a name for this type of interface-style (if not SPI)? Is it correct to say that SPI-style interfaces the spec includes the spec classes and the implementers generally wouldn't package the spec classes along, in this style there are no spec classes - only specified behavior for every interface?
No, that is not a correct understanding of how the Java standardization process works. For all the gory details, go to <http://jcp.org> and read the docuemnts that describes how it really works. Below is a too-brief summary of how the JCP rules interact with your questions in this thread. The JCP rules require that anyone who implements a spec must provide an implementation of the java.* or javax.* classes that are defined by the specification (even if they are interfaces). Part of the compatibility testing is a verification that the supplied java.* and/or javax.* classes publish exactly the right set of public methods and variables (no more and no less than the spec defines). That is why MyFaces includes a set of classes and interfaces that correspond to the spec in the myfaces-api-xxx.jar file. The RI (a different implementation) ships its own version of these classes in the jsf-api-xxx.jar file. Both implementations (for 1.1) have passed the compatibility tests, so you can be assured that the public and protected methods and fields in these APIs are the same. The thing that makes JSF different from many EE specs is that there are a *lot* of concrete classes, not just interfaces. This is hardly unique -- even the Servlet Specification defines a few classes with concrete behavior (like GenericServlet and HttpServlet), and other specs like Swing are mostly concrete classes with behavior. (Indeed, so is the core JDK ... you'll notice that java.util.ArrayList is a concrete class with behavior, which must be provided by anyone who claims to implement Java SE like the Harmony project here at Apache.) In the case of JSF, this was done deliberately so that a developer just using a base JSF implementation would not have to start by creating components -- out of the box you get some basic ones that are guaranteed to be portable across implementations. I can now see how JSF's source code wouldn't be bundled in with the Java EE
5 source code (because there is no interfaces FacesServlet from that implementors implement), but are you saying that there is no Java EE 5 source code at all - only implementations? Is every Java EE 5 spec designed in this non-SPI style where there exist no actual Java EE 5 source code, only the implementations' source code? e.g. Is there no EntityManager, HttpServlet, etc source code provided by Sun - only Javadocs? (If not, where could I get it?)
Glassfish includes code for both the API and implementations of all the specs it includes (for JSF, Glassfish uses the JSF 1.2 RI sources at < https://javaserverfaces.dev.java.net>). For Geronimo's code (their EE5 stuff is under development), go to < http://geronimo.apache.org>. From what I've seen on the mailing lists, they plan on shipping the MyFaces JSF 1.2 implementation (in development here on a branch) when it's done. That certainly makes a *lot* more sense than re-inventing it. I can find the J2EE source code here but not Java EE 5:
http://www.sun.com/software/communitysource/j2ee/j2ee/download.xml
You'll do a lot better at <https://glassfish.dev.java.net> but be sure to take note when Glassfish uses other modules for some of its functionality (like the JSF RI as mentioned above). This includes both the API classes ( javaee.jar) and an implementation of all the required features of Java EE 5 (plus a bunch of other useful stuff too). As Simon mentioned, the term "official" has no meaning in the JCP process. The only implementation that is at all distinguished is the "reference implementation" that the specification lead is required to provide (along with a compatibility test kit) before a spec can be voted final. From the JCP process perspective, the reason for an RI is to prove that the specification can actually be implemented. From the end user perspective, you cannot reliably draw any quality conclusions about a reference implementation of a spec simply from the fact that it is an RI. Some were designed specifically to be just that proof of concept (look at the basic Pluto implementation of the JSR-168 portlet spec, for example), while others are designed to be product quality implementation that is useful in applications as well as serving the role of proving that the spec can be implemented. Check the documentation for the implementation you are interested in, to see what the intent was, and try it out yourself. See what other people are doing with it. Anyone who claims "because it is an RI it is therefore just a toy and should not be used in production" does not know what they are talking about. Craig Simon Kitching-3 wrote:
> > lightbulb432 wrote: >> I have another question about MyFaces source code. When looking at the >> source >> code included with MyFaces, I noticed that FacesServlet is specific to >> MyFaces, as seen in the line: >> >> SERVLET_INFO="FacesServlet of the MyFaces API implementation >> >> I thought that Sun provided the standard set of APIs and the >> implementations >> just extend/implement everything in the API package. For example, every >> implementer of JSF uses the same FacesServlet class provided by the spec >> and >> in their implementation they create a "MyFacesServlet" specific to them. >> I >> didn't realize the way things worked was that they just replace the main >> classes!? That seems pretty weird... >> >> Is this a standard kinda way of implementing specs or is this a different >> approach. Pardon my ignorance, as I'm inexperienced with all this... > > This is the way that JSF is intended to be implemented at least. Sun > provide a spec which includes a batch of javadocs, but the > implementation of those classes in javax.faces is different for each > "vendor". > > Yes, it is a little different from the "SPI" style of interfaces. > > >> >> Is there a Java EE 5 version of the JSF classes that get implemented or >> replaced by the RI and MyFaces? Or are RI, MyFaces, and any other >> implementations the only JSF source code that exist (i.e. there is no >> "official" JSF source code)? > > There is no "official" implementation. Sun's implementation has no claim > to be any more "official" than the Apache Myfaces version (or other > implementations, though I don't know of any). > > JBoss comes with the MyFaces version, Glassfish comes with the Sun > version. I bet that Geronimo (and therefore Websphere Community Edition) > comes with MyFaces. > > I haven't checked what version BEA Weblogic provides, or Oracle. > >> >> I am looking for Java EE 5 source code in general (incl. JSF) and can't >> find >> it anywhere! Where'd you get it from? > > For the "Glassfish" implementation of the jee 5 spec, search the sun site. > > For the JBoss implementation of the jee 5 spec, search the JBoss site. > > Apache Geronimo is still working on implementing this version > (http://geronimo.apache.org/), but you'll find the source they have so > far on that site. > > BEA Weblogic source code isn't available. > > Regards, > > Simon > > -- View this message in context: http://www.nabble.com/Source-code-tf2978235.html#a8645742 Sent from the MyFaces - Users mailing list archive at Nabble.com.
