Jetspeed 2
  1. Jetspeed 2
  2. JS2-1120

Portlet icon to be shown on toolbox should be loaded from application context

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.1
    • Fix Version/s: 2.2.1
    • Component/s: None
    • Labels:
      None

      Description

      Portlet icons are currently loaded from Portal context.

      It makes difficult to update individual Portlet icons because they must be deployed to the Portal Application.

      Proposed change is to make Portal to lookup the resource on Portlet context if the icon is not found in the main Portal location.

      This will help developers update Portlet icons with application.

        Activity

        Hide
        Gonzalo Aguilar added a comment -

        Include needed options to support context driven features.

        Support also full path icon source based on context

        Show
        Gonzalo Aguilar added a comment - Include needed options to support context driven features. Support also full path icon source based on context
        Hide
        Gonzalo Aguilar added a comment -

        Make j2-admin exclusively check for icon into application context instead of portal context.

        Show
        Gonzalo Aguilar added a comment - Make j2-admin exclusively check for icon into application context instead of portal context.
        Hide
        Gonzalo Aguilar added a comment -

        It's necessary to force everyone to include icons to the application context or create a server or client side routine to find where's the icon.

        Show
        Gonzalo Aguilar added a comment - It's necessary to force everyone to include icons to the application context or create a server or client side routine to find where's the icon.
        Hide
        Woonsan Ko added a comment - - edited

        I'm seeing the following lines in your patch:

        + iconFile = new File(applicationContextPath + "/images/portlets/" + portletIcon);
        + // How to check if file exists? Need application context absolute path
        +// if(iconFile.exists())
        +//

        { +// portletIconPath = iconFile.getPath(); +// }

        +// else
        +// portletIconPath = new String();
        + portletIconPath = iconFile.getPath();

        I prefer supporting the existing feature (icons in portal app) as well as new proposed feature (icons in portlet app). In this sense, the above code seems to support the new feature only.
        How about simply adding a metadata field in jetspeed-portlet.xml like this? That could be a global metadata for the portlet app like this:

        <portlet-app id="demo">
        <js:metadata name="portlet.icon.holder" xml:lang="en">portlet</js:metadata>
        <js:metadata name="portlet.icon.base.path" xml:lang="en">/images/portlets</js:metadata>
        </portlet-app id="demo">

        This metadata could be checked in the portlet registry service and passed to toolbox view page. If it exists with 'portlet' value for 'portlet.icon.holder', then the portlet context path will be used; otherwise the default portal path will be used.
        Also, the second metadata could be used to override the default icon path.

        What do you think?

        Woonsan

        Show
        Woonsan Ko added a comment - - edited I'm seeing the following lines in your patch: + iconFile = new File(applicationContextPath + "/images/portlets/" + portletIcon); + // How to check if file exists? Need application context absolute path +// if(iconFile.exists()) +// { +// portletIconPath = iconFile.getPath(); +// } +// else +// portletIconPath = new String(); + portletIconPath = iconFile.getPath(); I prefer supporting the existing feature (icons in portal app) as well as new proposed feature (icons in portlet app). In this sense, the above code seems to support the new feature only. How about simply adding a metadata field in jetspeed-portlet.xml like this? That could be a global metadata for the portlet app like this: <portlet-app id="demo"> <js:metadata name="portlet.icon.holder" xml:lang="en">portlet</js:metadata> <js:metadata name="portlet.icon.base.path" xml:lang="en">/images/portlets</js:metadata> </portlet-app id="demo"> This metadata could be checked in the portlet registry service and passed to toolbox view page. If it exists with 'portlet' value for 'portlet.icon.holder', then the portlet context path will be used; otherwise the default portal path will be used. Also, the second metadata could be used to override the default icon path. What do you think? Woonsan
        Hide
        Gonzalo Aguilar added a comment -

        Hi Woonsan,

        While this is a good solution. It would be better to autodetect the portlet icon location. So user has not to put any "extra" configuration.

        But I found that it's not trivial to check for a file. Maybe because I'm not an expert.

        The question is...

        Is there any way to get absolute path to both contexts (portal and app)?

        This way I can check File(path).exists() before setting the path in the service bean...

        Show
        Gonzalo Aguilar added a comment - Hi Woonsan, While this is a good solution. It would be better to autodetect the portlet icon location. So user has not to put any "extra" configuration. But I found that it's not trivial to check for a file. Maybe because I'm not an expert. The question is... Is there any way to get absolute path to both contexts (portal and app)? This way I can check File(path).exists() before setting the path in the service bean...
        Hide
        Woonsan Ko added a comment -

        Hi Gonzalo,

        Actually, I have thought of auto-detecting if the icon resource exists or not.
        Technically, I think we can check it by using javax.servlet.ServletContext#getResource() or javax.portlet.PortletContext#getResource() because it reads the method returns null if the resource is not available.
        However, I have the followings in mind:
        (1) If we invoke getResource() method in the PortletRegistryService, then I think it would cost much with regard to performance.
        (2) Or, we could think of another approach to make invocations during the initialization time of portlet application or portlet instance.
        However, when a user browses portlet definitions in the toolbox, a portlet application for the portlet definition or a portlet instance for the portlet are not guaranteed to be initialized at that moment.

        Therefore, I think those additional metadata fields would be better.
        By the way, the metadata fields are defined at the application level in jetspeed-portlet.xml, not at the portlet level. So, I think it minimizes the burden.

        Kind regards,

        Woonsan

        Show
        Woonsan Ko added a comment - Hi Gonzalo, Actually, I have thought of auto-detecting if the icon resource exists or not. Technically, I think we can check it by using javax.servlet.ServletContext#getResource() or javax.portlet.PortletContext#getResource() because it reads the method returns null if the resource is not available. However, I have the followings in mind: (1) If we invoke getResource() method in the PortletRegistryService, then I think it would cost much with regard to performance. (2) Or, we could think of another approach to make invocations during the initialization time of portlet application or portlet instance. However, when a user browses portlet definitions in the toolbox, a portlet application for the portlet definition or a portlet instance for the portlet are not guaranteed to be initialized at that moment. Therefore, I think those additional metadata fields would be better. By the way, the metadata fields are defined at the application level in jetspeed-portlet.xml, not at the portlet level. So, I think it minimizes the burden. Kind regards, Woonsan
        Hide
        Woonsan Ko added a comment -

        I think it's been fixed with two optional metadata.

        If a portlet application contains the following optional metadata in jetspeed-portlet.xml as application-level metadata, then portlet icon resource paths can be overriden.

        <js:metadata name="portlet.icon.holder" xml:lang="en">portlet</js:metadata>
        <js:metadata name="portlet.icon.base.path" xml:lang="en">/images/portlet-icons</js:metadata>

        If the first metadata, portlet.icon.holder, exists and it has "portlet" value, then the portlet application's context would be used to load the portlet icon resource.
        If it is not set or if it has a different value from "portlet", then the portal web app's context would be used to load the porlet icon resource as it has done so far.

        If the second metadata, portlet.icon.base.path, is set, then the value would be used as a context relative portlet icon base path.
        If it is not set, then the default context relative base path, "/images/portlets", would be used.

        Regards,

        Woonsan

        Show
        Woonsan Ko added a comment - I think it's been fixed with two optional metadata. If a portlet application contains the following optional metadata in jetspeed-portlet.xml as application-level metadata, then portlet icon resource paths can be overriden. <js:metadata name="portlet.icon.holder" xml:lang="en">portlet</js:metadata> <js:metadata name="portlet.icon.base.path" xml:lang="en">/images/portlet-icons</js:metadata> If the first metadata, portlet.icon.holder , exists and it has "portlet" value, then the portlet application's context would be used to load the portlet icon resource. If it is not set or if it has a different value from "portlet", then the portal web app's context would be used to load the porlet icon resource as it has done so far. If the second metadata, portlet.icon.base.path , is set, then the value would be used as a context relative portlet icon base path. If it is not set, then the default context relative base path, "/images/portlets", would be used. Regards, Woonsan

          People

          • Assignee:
            Woonsan Ko
            Reporter:
            Gonzalo Aguilar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development