Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: Proposals
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      5

      Description

      Igor Shabalov wrote:

      Some component libraries may require some external resources to be used, like
      additional servlets, special servlet mappings, images, styles etc.

        Activity

        Hide
        jrstephe added a comment -

        Gavin wrote:

        I definitely agree with this too.

        We have a custom component that requires an external XML configuration
        file, so having standard support in tools for linking and packaging the
        file would be extremely useful for component authors.

        Gavin

        Show
        jrstephe added a comment - Gavin wrote: I definitely agree with this too. We have a custom component that requires an external XML configuration file, so having standard support in tools for linking and packaging the file would be extremely useful for component authors. Gavin
        Hide
        jrstephe added a comment -

        Sergey wrote:

        +1 also. It is probably aside from the mainstream, but is might be extremely
        helpful if components writers provide information that helps tool to add
        support of those component libraries to the project automatically.
        For example, MyFaces requires just put the jar file in the WEB-INF/lib, but
        webgalileo requires to put faces-config.xml files into the WEB-INF and have
        several records in the web.xml. I suggest, such requirement might be defined
        using meta-data.
        I hope, experts who present the components writers lobby in our JSR can
        provide us with some typical usecases and we can start to form the proposal
        after that.

        Show
        jrstephe added a comment - Sergey wrote: +1 also. It is probably aside from the mainstream, but is might be extremely helpful if components writers provide information that helps tool to add support of those component libraries to the project automatically. For example, MyFaces requires just put the jar file in the WEB-INF/lib, but webgalileo requires to put faces-config.xml files into the WEB-INF and have several records in the web.xml. I suggest, such requirement might be defined using meta-data. I hope, experts who present the components writers lobby in our JSR can provide us with some typical usecases and we can start to form the proposal after that.
        Hide
        jrstephe added a comment -

        Martin wrote:

        Let me talk about what Apache MyFaces would need to get its custom
        components up and running:

        Apache MyFaces needs a custom filter (called the Extension-filter) for
        the custom components to work properly. This extension-filter needs to
        be configured in your web.xml file.

        This extension filter loads all resources from subdirectory of the
        component directory - and optionally you can overwrite the location of
        these resources to a user-defined directory by setting a parameter on
        the component.

        Even though this might not the best approach, we had to go for it as
        otherwise resource management is very tedious for the users.

        Show
        jrstephe added a comment - Martin wrote: Let me talk about what Apache MyFaces would need to get its custom components up and running: Apache MyFaces needs a custom filter (called the Extension-filter) for the custom components to work properly. This extension-filter needs to be configured in your web.xml file. This extension filter loads all resources from subdirectory of the component directory - and optionally you can overwrite the location of these resources to a user-defined directory by setting a parameter on the component. Even though this might not the best approach, we had to go for it as otherwise resource management is very tedious for the users.
        Hide
        jrstephe added a comment -

        Damien wrote:

        Let me talk about what Apache MyFaces would need to get its custom
        components up and running:

        Apache MyFaces needs a custom filter (called the Extension-filter) for
        the custom components to work properly. This extension-filter needs to
        be configured in your web.xml file.

        This extension filter loads all resources from subdirectory of the
        component directory - and optionally you can overwrite the location of
        these resources to a user-defined directory by setting a parameter on
        the component.

        Even though this might not the best approach, we had to go for it as
        otherwise resource management is very tedious for the users.

        Sergey wrote:

        So, by the end of the day, we can specify the following activities required
        to be done in order to add component library support in the new project:

        1. Adding record to the web descriptor file
        2. Adding record to the faces configuration file
        3. Copying folder context from component library jar into the folder under
        the web project root
        4. Copying file (like faces-config.xml) from component library jar under the
        web project root

        Does anybody have other required activities that are not covered by the
        scenarios above?

        Jacob wrote:

        I thought the best solution would be to go back to the Servlet spec and
        load 'xml data' from the META-INF-- just like JSP and JSF, so then those
        components/frameworks with additional resources could be mounted via
        /META-INF/web.xml. It seemed like something they wanted to include, so
        I don't know if it's worth spending a lot of time solving this issue in
        a 'standard' way yet when the ideal solution is to get resource mapping
        capabilities within the servlet spec itself.

        – Jacob

        Jeff wrote:

        Based on all the comments on this thread, we know that some component
        libraries require files copied into the web application for various
        reasons, and some component libraries require additional servlets/filters
        to be set up in web.xml. I don't think it is within JSR 276's scope to say
        which approach is "better". I don't think we can envision all of the possible
        ways in which a future component library might interact with
        files in the web application or additional servlets/filters/etc.

        What we can do is think about how we can improve the design-time experience
        for component libraries that have these kinds of requirements. If we come
        up with a way for the component author to communicate these requirements to
        a tool, then the tool could theoretically copy files or set up additional
        servlets/filters etc. when the component library is first used.

        As Martin said in his post, I think there is a certain class of user that
        just wants to use the component, and would be greatly aided if the tool
        did all of this on their behalf.

        Show
        jrstephe added a comment - Damien wrote: Let me talk about what Apache MyFaces would need to get its custom components up and running: Apache MyFaces needs a custom filter (called the Extension-filter) for the custom components to work properly. This extension-filter needs to be configured in your web.xml file. This extension filter loads all resources from subdirectory of the component directory - and optionally you can overwrite the location of these resources to a user-defined directory by setting a parameter on the component. Even though this might not the best approach, we had to go for it as otherwise resource management is very tedious for the users. Sergey wrote: So, by the end of the day, we can specify the following activities required to be done in order to add component library support in the new project: 1. Adding record to the web descriptor file 2. Adding record to the faces configuration file 3. Copying folder context from component library jar into the folder under the web project root 4. Copying file (like faces-config.xml) from component library jar under the web project root Does anybody have other required activities that are not covered by the scenarios above? Jacob wrote: I thought the best solution would be to go back to the Servlet spec and load 'xml data' from the META-INF-- just like JSP and JSF, so then those components/frameworks with additional resources could be mounted via /META-INF/web.xml. It seemed like something they wanted to include, so I don't know if it's worth spending a lot of time solving this issue in a 'standard' way yet when the ideal solution is to get resource mapping capabilities within the servlet spec itself. – Jacob Jeff wrote: Based on all the comments on this thread, we know that some component libraries require files copied into the web application for various reasons, and some component libraries require additional servlets/filters to be set up in web.xml. I don't think it is within JSR 276's scope to say which approach is "better". I don't think we can envision all of the possible ways in which a future component library might interact with files in the web application or additional servlets/filters/etc. What we can do is think about how we can improve the design-time experience for component libraries that have these kinds of requirements. If we come up with a way for the component author to communicate these requirements to a tool, then the tool could theoretically copy files or set up additional servlets/filters etc. when the component library is first used. As Martin said in his post, I think there is a certain class of user that just wants to use the component, and would be greatly aided if the tool did all of this on their behalf.
        Hide
        jrstephe added a comment -

        Current status of this issue is:

        • A requirement has been added into the requirements document with use cases
          pulled from the above comments.
        • No metadata items have been proposed yet
        Show
        jrstephe added a comment - Current status of this issue is: A requirement has been added into the requirements document with use cases pulled from the above comments. No metadata items have been proposed yet
        Hide
        jrstephe added a comment -

        Sergey wrote:

        Some of the configuration paramers might be required, someones not.
        For example,
        Faceslets requires to put View Handler into faces-config.xml
        Optionally, I can add some configuration params into web.xml such as:

        <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
        </context-param>

        <context-param>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>true</param-value>
        </context-param>

        It would be nice if Facelets provides some meta-data about those parameters'
        types, so tool can ask user: "What the Default Suffix you Want to Have
        (.jsp/.xhtml)?" and "Is it Development Environment - [yes/no]"

        Show
        jrstephe added a comment - Sergey wrote: Some of the configuration paramers might be required, someones not. For example, Faceslets requires to put View Handler into faces-config.xml Optionally, I can add some configuration params into web.xml such as: <context-param> <param-name>javax.faces.DEFAULT_SUFFIX</param-name> <param-value>.xhtml</param-value> </context-param> <context-param> <param-name>facelets.DEVELOPMENT</param-name> <param-value>true</param-value> </context-param> It would be nice if Facelets provides some meta-data about those parameters' types, so tool can ask user: "What the Default Suffix you Want to Have (.jsp/.xhtml)?" and "Is it Development Environment - [yes/no] "
        Hide
        jrstephe added a comment -

        Jeff wrote:

        We've had a fair amount of discussion about webapp configuration,
        but we haven't yet discussed the syntax that a component author
        would use to convey information about the changes that are needed
        to the webapp in order for their component library to work properly.

        If you need a refresher on this issue, the meat of the discussion is
        captured in the issue here:

        https://jsf-metadata-spec-public.dev.java.net/issues/show_bug.cgi?id=5

        In addition, the requirements and use cases are written up in our
        requirements-elicitation.html document (see requirements #16 and #17).

        I've given the problem some thought, and I keep coming back to the
        idea that Sergey raised that a tool might want to prompt users about
        the configuration changes (particularly if some of them are considered
        optional). I agree, I've always been of the opinion that it is nice to
        let the users know what you are doing to their web app. Thus, I think
        that we should at least design the metadata such that there is enough
        information to prompt the user and explain what the tool is about to
        do. This means that in addition to specifying the actual configuration
        changes (like the class name of an additional servlet), that we'd need
        a display name for the configuration operation, a human readable description
        of what it is for/why it is important, and some indication if it is
        required in order for the component library to work.

        For specifying the actual configuration changes, I think we've got
        two possible routes. The first option is to pick specific configuration
        changes that we support (like adding a new servlet) and then define our own
        XML language for gathering all the information the tool would need
        to update web.xml. Something approximately like:

        <configuration-tasks>

        <add-servlet id="trinidad-resource-servlet">
        <display-name>Add Trinidad Resource Servlet</display-name>
        <description>This servlet is required for ...</description>
        <required>true</required>
        <servlet-name>resources</servlet-name>
        <servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-
        class>
        <servlet-mapping>/afr/*</servlet-mapping>
        <servlet-mapping>/adf/*</servlet-mapping>
        </add-servlet>

        <copy-file id="copy-sample-adf-config-file">
        <display-name>Add Sample ADF Configuration File</display-name>
        <description>Copies a sample ADF Configuration File into WEB-
        INF</description>
        <source>resources/samples/adf-config.xml</source>
        <destination>/WEB-INF</destination>
        </copy-file>

        </configuration-task>
        </configuration-tasks>

        The problem with the above is that we have to define an element in our language
        for each potential change someone wants to make to web.xml (init-params,
        context-params, etc). There's a lot of web.xml syntax, how far do we go...

        A second option is to do something less precise but more flexible like allowing
        the component author to specify an arbitrary chunk of XML syntax and the file
        name that they want it to go in:

        <configuration-tasks>

        <configuration-task id="add-adf-faces-resource-servlet">
        <display-name>Add Trinidad Resource Servlet</display-name>
        <description>This servlet is required for ...</description>
        <modify-file location="WEB-INF/web.xml">
        <servlet>
        <servlet-name>resources</servlet-name>
        <servlet-
        class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>
        </servlet>

        <servlet-mapping>
        <servlet-name>resources</servlet-name>
        <url-pattern>/adf/*</url-pattern>
        </servlet-mapping>

        <servlet-mapping>
        <servlet-name>resources</servlet-name>
        <url-pattern>/afr/*</url-pattern>
        </servlet-mapping>

        </modify-file>
        </configuration-task>
        </configuration-task>

        The pros of this approach are that arbitrary xml would be accepted inside
        modify-file
        so that we don't have to redefine the web app language (we'd just put a
        wildcard in our
        XML schema). It could also be used to modify files other than web.xml. The
        cons are that
        it places a burden on the tool to make sense of that content and appropriately
        merge it
        into the file.

        I'm not wedded to either approach or to the example syntax I used above.
        I do hope that the examples demonstrate the two possible approaches I've
        been considering. Does anyone have any preferences or any better ideas
        for syntax?

        Show
        jrstephe added a comment - Jeff wrote: We've had a fair amount of discussion about webapp configuration, but we haven't yet discussed the syntax that a component author would use to convey information about the changes that are needed to the webapp in order for their component library to work properly. If you need a refresher on this issue, the meat of the discussion is captured in the issue here: https://jsf-metadata-spec-public.dev.java.net/issues/show_bug.cgi?id=5 In addition, the requirements and use cases are written up in our requirements-elicitation.html document (see requirements #16 and #17). I've given the problem some thought, and I keep coming back to the idea that Sergey raised that a tool might want to prompt users about the configuration changes (particularly if some of them are considered optional). I agree, I've always been of the opinion that it is nice to let the users know what you are doing to their web app. Thus, I think that we should at least design the metadata such that there is enough information to prompt the user and explain what the tool is about to do. This means that in addition to specifying the actual configuration changes (like the class name of an additional servlet), that we'd need a display name for the configuration operation, a human readable description of what it is for/why it is important, and some indication if it is required in order for the component library to work. For specifying the actual configuration changes, I think we've got two possible routes. The first option is to pick specific configuration changes that we support (like adding a new servlet) and then define our own XML language for gathering all the information the tool would need to update web.xml. Something approximately like: <configuration-tasks> <add-servlet id="trinidad-resource-servlet"> <display-name>Add Trinidad Resource Servlet</display-name> <description>This servlet is required for ...</description> <required>true</required> <servlet-name>resources</servlet-name> <servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet- class> <servlet-mapping>/afr/*</servlet-mapping> <servlet-mapping>/adf/*</servlet-mapping> </add-servlet> <copy-file id="copy-sample-adf-config-file"> <display-name>Add Sample ADF Configuration File</display-name> <description>Copies a sample ADF Configuration File into WEB- INF</description> <source>resources/samples/adf-config.xml</source> <destination>/WEB-INF</destination> </copy-file> </configuration-task> </configuration-tasks> The problem with the above is that we have to define an element in our language for each potential change someone wants to make to web.xml (init-params, context-params, etc). There's a lot of web.xml syntax, how far do we go... A second option is to do something less precise but more flexible like allowing the component author to specify an arbitrary chunk of XML syntax and the file name that they want it to go in: <configuration-tasks> <configuration-task id="add-adf-faces-resource-servlet"> <display-name>Add Trinidad Resource Servlet</display-name> <description>This servlet is required for ...</description> <modify-file location="WEB-INF/web.xml"> <servlet> <servlet-name>resources</servlet-name> <servlet- class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>resources</servlet-name> <url-pattern>/adf/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>resources</servlet-name> <url-pattern>/afr/*</url-pattern> </servlet-mapping> </modify-file> </configuration-task> </configuration-task> The pros of this approach are that arbitrary xml would be accepted inside modify-file so that we don't have to redefine the web app language (we'd just put a wildcard in our XML schema). It could also be used to modify files other than web.xml. The cons are that it places a burden on the tool to make sense of that content and appropriately merge it into the file. I'm not wedded to either approach or to the example syntax I used above. I do hope that the examples demonstrate the two possible approaches I've been considering. Does anyone have any preferences or any better ideas for syntax?
        Hide
        jrstephe added a comment -

        Update: Martin and Damien voted for Option 1.

        Thanks for the feedback. So, that's two votes for the first option
        and no votes yet for the second. That at least gives me a direction
        to go in. I'll try to flesh out the first option some more tomorrow
        and send another mail when I have a more complete syntax.

        > what would we need to add?
        >
        > - init-params
        > - context-params
        > - filter
        > - filter-mapping
        > - servlet
        > - servlet-mapping

        Yeah, and the child elements that go inside those. In the end, it is
        still about 50% of the web.xml language. It is possible we could blow
        off some of the stuff inside <servlet> like <security-role-ref> and
        possibly <load-on-startup>.

        > How about positioning in the web.xml - like what filter would need to
        > be going before what other filter? Or do we leave that to the user?

        Good point. Obviously if there were two filters in the same design time
        metadata or faces-config.xml file, then they could be added to web.xml
        in that order, but I don't know what to do about filters contributed from
        other component libraries that match the same url-pattern or servlet name.
        We could potentially add a priority or something, but that seems like
        overkill. Maybe leaving this to the user to order is okay (unless you
        guys think it is going to be a big problem).

        Show
        jrstephe added a comment - Update: Martin and Damien voted for Option 1. Thanks for the feedback. So, that's two votes for the first option and no votes yet for the second. That at least gives me a direction to go in. I'll try to flesh out the first option some more tomorrow and send another mail when I have a more complete syntax. > what would we need to add? > > - init-params > - context-params > - filter > - filter-mapping > - servlet > - servlet-mapping Yeah, and the child elements that go inside those. In the end, it is still about 50% of the web.xml language. It is possible we could blow off some of the stuff inside <servlet> like <security-role-ref> and possibly <load-on-startup>. > How about positioning in the web.xml - like what filter would need to > be going before what other filter? Or do we leave that to the user? Good point. Obviously if there were two filters in the same design time metadata or faces-config.xml file, then they could be added to web.xml in that order, but I don't know what to do about filters contributed from other component libraries that match the same url-pattern or servlet name. We could potentially add a priority or something, but that seems like overkill. Maybe leaving this to the user to order is okay (unless you guys think it is going to be a big problem).
        Hide
        jrstephe added a comment -

        Martin wrote:

        Well, there's stuff that the user has configured that might need to be
        before our filters - e.g. SecurityFilters. Would we expect JSF
        libraries to define security relevant filters as well?

        In any case, positioning is dangerous, maybe we should introduce an id
        to our elements, and then have a before or after element where we can
        refer to this id.

        e.g.:

        <after>com.ajax4jsf.ResourceFilter</after>
        <after>org.weblets.ResourceFilter</after>
        <before>org.apache.myfaces.ExtensionFilter</before>

        this would need to be added for the mapping-elements. In the
        faces-config.xml, a syntax like this was forgotten about, and this
        hits us hard now with the amount of component libraries around.

        Show
        jrstephe added a comment - Martin wrote: Well, there's stuff that the user has configured that might need to be before our filters - e.g. SecurityFilters. Would we expect JSF libraries to define security relevant filters as well? In any case, positioning is dangerous, maybe we should introduce an id to our elements, and then have a before or after element where we can refer to this id. e.g.: <after>com.ajax4jsf.ResourceFilter</after> <after>org.weblets.ResourceFilter</after> <before>org.apache.myfaces.ExtensionFilter</before> this would need to be added for the mapping-elements. In the faces-config.xml, a syntax like this was forgotten about, and this hits us hard now with the amount of component libraries around.

          People

          • Assignee:
            jrstephe
            Reporter:
            jrstephe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: