Hi It is a good idea, but I additionally need the startup ExternalContext to call the SPI methods from that location. To do that we can put the startup ExternalContext on shared and move the SPI interfaces. But note this is a temporal hack. I would like to keep myfaces core jdk 1.5 compatible as long as possible, but JSF 2.1 set jdk 1.6 as minimal requeriment.
See http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-August/002795.html For now we can maintain the compatibility with jdk 1.5, but in the future we'll have to remove the current hack (maybe on JSF 2.2). Anyway, I think it is reasonable to do what you are proposing in the medium/long term. There is no objections about do it now, but my interest is get a release of 2.1 out ASAP. regards, Leonardo Uribe 2011/5/2 Jakob Korherr (JIRA) <[email protected]>: > > [ > https://issues.apache.org/jira/browse/MYFACES-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027741#comment-13027741 > ] > > Jakob Korherr commented on MYFACES-3093: > ---------------------------------------- > > I think a better idea than the myfaces-shaded-impl "hack" would be to create > a myfaces-spi module, which contains MyFaces' SPI classes (of course, only > the abstract ones, not the implementation classes) and which will be shaded > into myfaces-impl at build time. In this way myfaces-implee6 could use the > myfaces-spi module and the myfaces-shaded-impl module could be removed. > > What do you think of that solution, Leo? > >> Check FacesServlet description for support servlet 3.0 spec >> ------------------------------------------------------------ >> >> Key: MYFACES-3093 >> URL: https://issues.apache.org/jira/browse/MYFACES-3093 >> Project: MyFaces Core >> Issue Type: Task >> Components: JSR-314 >> Affects Versions: 2.1.0-SNAPSHOT >> Reporter: Leonardo Uribe >> Assignee: Leonardo Uribe >> Fix For: 2.1.0 >> >> >> The description says this: >> ".. If the application is running in a Servlet 3.0 (and beyond) container, >> the runtime must provide an implementation of the >> ServletContainerInitializer interface that declares the following classes in >> its javax.servlet.annotation.HandlesTypes annotation. >> * ResourceDependencies >> * ResourceDependency >> * javax.faces.bean.ManagedBean >> * FacesComponent >> * UIComponent >> * Converter >> * FacesConverter >> * ListenerFor >> * ListenersFor >> * FacesBehaviorRenderer >> * Renderer >> * FacesValidator >> * Validator >> This servlet must automatically be mapped if it is not explicitly mapped in >> web.xml or web-fragment.xml and one or more of the following conditions are >> true. >> * >> A faces-config.xml file is found in WEB-INF >> * >> A faces-config.xml file is found in the META-INF directory of a jar in >> the application's classpath. >> * >> A filename ending in .faces-config.xml is found in the META-INF >> directory of a jar in the application's classpath. >> * >> The javax.faces.CONFIG_FILES context param is declared in web.xml or >> web-fragment.xml. >> * >> The Set of classes passed to the onStartup() method of the >> ServletContainerInitializer implementation is not empty. >> If the runtime determines that the servlet must be automatically mapped, it >> must be mapped to the following <url-pattern> entries. >> * /faces >> * *.jsf >> * *.faces >> ..." >> In theory, MyFaces has already that class (MyFacesContainerInitializer on >> implee6), but we need to check if it complies with the spec. Note the part >> that says UIComponent and Renderer classes should be added as HandlesTypes. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira >
