You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org> on 2010/02/17 01:56:27 UTC

[jira] Created: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

provide a hook for for an external decorator of Skin InputStreamProvider
------------------------------------------------------------------------

                 Key: TRINIDAD-1729
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
             Project: MyFaces Trinidad
          Issue Type: Improvement
          Components: Skinning
            Reporter: Jeanne Waldman
            Assignee: Jeanne Waldman


A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
1. We first discussed decorating ExternalContext.getResource(), since in
Trinidad we create the URL by calling FacesContext's ExternalContext's
getResource(style-sheet-name). For an example, see
http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
2. This won't work for them because it returns an URL object
3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
5. To allow them to plugin their InputStreamProvider we
can do this with a service provider interface where we open up
META-INF/services/<fully qualified classname of service> and load all of the
services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840725#action_12840725 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

I created this JIRA issue TRINIDAD-1746 move InputStreamProvider to be a public API
I will implement 1746 before I implement this JIRA.

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>         Attachments: 1729InputStreamProviderHookWithTodos.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854063#action_12854063 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

This is also related to TRINIDAD-1746 move InputStreamProvider to be a public API

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>             Fix For: 1.2.14-core 
>
>         Attachments: MDSNameResolver.jar, NameResolverPatch1212.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Resolved: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeanne Waldman resolved TRINIDAD-1729.
--------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.14-core 

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>             Fix For: 1.2.14-core 
>
>         Attachments: MDSNameResolver.jar, NameResolverPatch1212.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843659#action_12843659 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

todo wait until Matthias has finished merging and creating a new trunk to apply to trunk

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>         Attachments: MDSNameResolver.jar, NameResolverPatch1212.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843645#action_12843645 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

NameResolverPatch1212.patch has the fix.
To customize the NameResolver, you will need a jar with a file in META-INF/services called org.apache.myfaces.trinidad.share.io.NameResolver.
In this file, there should be a line that says where your NameResolver implementation is.
e.g., 
org.mycompany.MyCustomNameResolver

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>         Attachments: NameResolverPatch1212.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840923#action_12840923 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

Having a META-INF\services for InputStreamProvider is not enough. I need a way to pass in the 'name'  (css filename) to their provider.
So I need an InputStreamProviderFactory that has getProvider(name). This is the class that the services class will need to implement.

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>         Attachments: 1729InputStreamProviderHookWithTodos.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Reopened: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeanne Waldman reopened TRINIDAD-1729:
--------------------------------------


There is a bug in this.

java.lang.ClassCastException: oracle.webcenter.skin.model.MDSInputStreamProvider cannot be cast to org.apache.myfaces.trinidad.share.io.NameResolver
        at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._loadNameResolverFromServices(StyleSheetEntry.java:621)
        at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._getNameResolverForStyleSheetFile(StyleSheetEntry.java:428)
        at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._getNameResolver(StyleSheetEntry.java:347)
        at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry.createEntry(StyleSheetEntry.java:78)
        at org.apache.myfaces.trinidadinternal.skin.SkinImpl._createStyleSheetDocument(SkinImpl.java:563)
        at org.apache.myfaces.trinidadinternal.skin.SkinImpl.getStyleSheetDocument(SkinImpl.java:346)
        at org.apache.myfaces.trinidadinternal.skin.SkinExtension.getStyleSheetDocument(SkinExtension.java:527)
        at org.apache.myfaces.trinidadinternal.skin.SkinStyleProvider.createStyleSheetDocument(SkinStyleProvider.java:158)

because we are putting an InputStreamProvider in the map, but retrieving a NameResolver.

> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>             Fix For: 1.2.14-core 
>
>         Attachments: MDSNameResolver.jar, NameResolverPatch1212.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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


[jira] Commented: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider

Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842899#action_12842899 ] 

Jeanne Waldman commented on TRINIDAD-1729:
------------------------------------------

The InputStreamProviderFactory is also not enough. 
InputStreamProvider provides an inputStream for a file.
NameResolver provides an InputStreamProvider and another NameResolver that can be used to find files that are imported into the base file. The skinning .xss files support imports. The skinning .css files do not yet, but someday they should.
So to think about the future, we should have the customizer implement NameResolver, not InputStreamProvider.

Therefore, we need to:
1. Make NameResolver public (part of TRINIDAD-1746 )
2. Make InputStreamProvider public (part of TRINIDAD-1746 )
3. The customizer will customize NameResolver.
4. StyleSheetEntry will see if it can find the file the way it does now. If so, it creates a StyleSheetNameResolver. If not, it loads the customized NameResolver from META-INF/services if it is there. Otherwise, it throws a FileNotFoundException.


> provide a hook for for an external decorator of Skin InputStreamProvider
> ------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1729
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>            Reporter: Jeanne Waldman
>            Assignee: Jeanne Waldman
>         Attachments: 1729InputStreamProviderHookWithTodos.patch
>
>
> A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them.
> 1. We first discussed decorating ExternalContext.getResource(), since in
> Trinidad we create the URL by calling FacesContext's ExternalContext's
> getResource(style-sheet-name). For an example, see
> http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/
> 2. This won't work for them because it returns an URL object
> 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified.
> 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java
> 5. To allow them to plugin their InputStreamProvider we
> can do this with a service provider interface where we open up
> META-INF/services/<fully qualified classname of service> and load all of the
> services that way.

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