myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-2860) Provide AnnotationScanner interface
Date Tue, 10 Aug 2010 17:45:17 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896978#action_12896978
] 

Leonardo Uribe commented on MYFACES-2860:
-----------------------------------------

Hi Stan

There are two reasons why make difference about where the classes came from:

1. Handling of metadata-complete: The spec says the following:

"... If the <faces-config> element in the WEB-INF/faces-config.xml file contains metadata-complete
attribute whose value is "true", the implementation must not perform annotation scanning on
any classes except for those classes provided by the implementation itself ..."

   The interface provided by mojarra does not take into account that it could be annotations
inside its own jar files, instead it assume no annotations will be included on jsf-impl.jar.
From the point of view of the spec, provide a separate method to deal with myfaces-impl annotations
is ok, but note myfaces-impl does not have annotations to be scanned at the moment. Maybe
instead make AnnotationProvider an interface we should make it an abstract class, to add that
method if required in the future.

2. How to handle class files according to the location where they come from: It is not the
same to scan annotations if the connection url is a file type or if it is a jar file. The
algorithm required to scan is different. With a file protocol it is possible to scan between
directories, but with a jar protocol, it is better to get the JarFile and scan all entries
ending with .class.

The spec is not clear about the ordering, but myfaces tries to follow the spec literally.
In this case it is not a concern after all.

I was thinking on provide an interface to allow customize the way how classes are selected
to be scanned for annotations.

The consideration about why use ExternalContext instead ServletContext is how to handle portlet
case. But maybe it is invalid after all, because it is expected jsf implementation be outside
portlet assembly. Anyway, it is not very clear at initialization and destroy which instance
could be received: PortletContext or ServletContext, so I think it is preferred use ExternalContext.

I'll do another proposal closer to your needs.


> Provide AnnotationScanner interface
> -----------------------------------
>
>                 Key: MYFACES-2860
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2860
>             Project: MyFaces Core
>          Issue Type: Improvement
>          Components: JSR-314
>    Affects Versions: 2.0.1
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>         Attachments: jboss-myfaces.zip, Myfaces-2.0-jsf.deployer.zip, MYFACES-2860-1.patch
>
>
> Looking integration of myfaces with JBoss AS6, it was notice myfaces does not have a
way to override the annotation configurator.
> Ri has a class called AnnotationProvider with this methods:
> public AnnotationProvider(ServletContext sc) 
> abstract public Map<?> getAnnotatedClasses(Set<URL> urls)
> the documentation says it is possible to override using this type of constructor.
> public AnnotationProvider(ServletContext sc, AnnotationProvider parent)
> We should provide something similar (let's call it AnnotationScanner because its objective
is scan for annotations).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message