Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: portlet container
    • Labels:
      None

      Description

      A cleaning up of the current Pluto packages was proposed initially by Casten on the dev list, see:
      http://www.nabble.com/-RT--Cleaning-up-our-packages-p22288945.html

      A follow up proposal was accepted on the dev list, see:
      http://www.nabble.com/Re%3A--RT--Cleaning-up-our-packages-p22414927.html

      defining the following changes which will be done:

      container-api:

      • o.a.p
        leave as is
      • o.a.p.core
        rename to o.a.p.driver
        move NullPortlet as inner class to PortletServlet
      • o.a.p.services
        move PortletAppDescriptorServices to o.a.p.spi
        move ContainerServices to o.a.p
        move PlutoServices to o.a.p.driver (side-by-side PortletServlet)
      • o.a.p.om.portlet
        leave as is
      • o.a.p.internal
        rename Internal* to Container* (I really don't like the "Internal" prefix)
        move * to o.a.p
      • o.a.p.spi.optional
        move * to o.a.p.spi
        the distinction between spi and spi.optional (while somewhat useful configuration wise) really is too artificial technical wise imo.

      container (impl):

      • o.a.p
        move PortletContainerFactory to o.a.p.driver.impl
      • o.a.p.core
        move the following to new package o.a.p.impl
        ContainerInvocation* (note: I've some ideas to completely get rid of these all together)
        PlutoContainerServices
        PortletContainerImpl
        move all the others to either
      • o.a.p.driver.impl (those which really are used only by/for a standalone/pure embedded driver)
      • o.a.p.spi.impl (those which are of more generic usage and/or embedding in a larger portal)
        drop package o.a.p.core
      • o.a.p.descriptors.portlet, o.a.p.descriptors.portlet10
        rename these to o.a.p.om.portlet.impl and o.a.p.om.portlet10.impl
      • o.a.p.descriptors.services.jaxb
        move PortletAppDescriptorServiceImpl to o.a.p.spi.impl
      • o.a.p.internal.impl
        move * to o.a.p.impl
      • o.a.p.util
        move to o.a.p.impl.util

        Activity

        Hide
        Ate Douma added a comment -

        Changes committed.

        Show
        Ate Douma added a comment - Changes committed.
        Hide
        Ate Douma added a comment -

        Reopening this issue for a small adjustment to move base implementations of the PortletContext and PortletConfig interfaces back from the o.a.p.c.driver.impl back to o.a.p.c.impl
        These implementations can be made almost 100% generic, except for the PortletConfig.getResourceBundle(Locale) method which is tricky and really depends on how the portal needs to handle that.

        The few Pluto Portal Driver specifics I'll derive from the current implementations and move them to extended DriverPortletContextImpl and DriverPortletConfigImpl classes in o.a.p.c.driver.impl.

        I'm already running the TCK again against these changes and expect no surprises so will commit these as soon as the test passes.

        Show
        Ate Douma added a comment - Reopening this issue for a small adjustment to move base implementations of the PortletContext and PortletConfig interfaces back from the o.a.p.c.driver.impl back to o.a.p.c.impl These implementations can be made almost 100% generic, except for the PortletConfig.getResourceBundle(Locale) method which is tricky and really depends on how the portal needs to handle that. The few Pluto Portal Driver specifics I'll derive from the current implementations and move them to extended DriverPortletContextImpl and DriverPortletConfigImpl classes in o.a.p.c.driver.impl. I'm already running the TCK again against these changes and expect no surprises so will commit these as soon as the test passes.
        Hide
        Ate Douma added a comment -

        All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

        Show
        Ate Douma added a comment - All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593
        Hide
        Ate Douma added a comment -

        Finally, I've started removing the PortalCallbackService by moving its containing methods to other more direct and appropriate "service" access interfaces.
        The PortalCallbackService as a separate service interface really wasn't adding any technical or functional benefit anyway, as it was provided by the RequiredContainerServices, so needed to be implemented by the embedding Portal just as well.

        I've added a FilterManagerService (also allows to better maintain a cached FilterChain state instead of creating a new on each request) to access a FilterManager.
        The getFilterManager method is moved from the PortalCallbackService to this new FilterManagerService, which itself is added (up) to the RequiredContainerServices directly.
        The getPortletURLListener() is also moved up to the RequiredContainerServices, and all the other methods in PortalCallBackService are moved to the response specific -Context interface where they are (only) used:

        • getResourceURLProvider -> PortalResponseContext
        • getPortletURLProvider -> PortletMimeResponseContext
        • getEventProvider -> PortletStateAwareResponseContext

        This leaves an empty PortalCallbackService and thus can be removed.

        Show
        Ate Douma added a comment - Finally, I've started removing the PortalCallbackService by moving its containing methods to other more direct and appropriate "service" access interfaces. The PortalCallbackService as a separate service interface really wasn't adding any technical or functional benefit anyway, as it was provided by the RequiredContainerServices, so needed to be implemented by the embedding Portal just as well. I've added a FilterManagerService (also allows to better maintain a cached FilterChain state instead of creating a new on each request) to access a FilterManager. The getFilterManager method is moved from the PortalCallbackService to this new FilterManagerService, which itself is added (up) to the RequiredContainerServices directly. The getPortletURLListener() is also moved up to the RequiredContainerServices, and all the other methods in PortalCallBackService are moved to the response specific -Context interface where they are (only) used: getResourceURLProvider -> PortalResponseContext getPortletURLProvider -> PortletMimeResponseContext getEventProvider -> PortletStateAwareResponseContext This leaves an empty PortalCallbackService and thus can be removed.
        Hide
        Ate Douma added a comment - - edited

        I also removed the (single) usage of the PortletInfoService from ResourceBundleFactory which only uses it to initially retrieve potentially window specific PortletInfo.
        As accessing the PortletInfoService was the only real left usage of the PortletContainerInvocationService, replacing the PortletInfoService by having this "initial" PortletInfo provided by the PortletConfigImpl itself, also allowed the ThreadLocal based PortletContainerInvocationService!

        Show
        Ate Douma added a comment - - edited I also removed the (single) usage of the PortletInfoService from ResourceBundleFactory which only uses it to initially retrieve potentially window specific PortletInfo. As accessing the PortletInfoService was the only real left usage of the PortletContainerInvocationService, replacing the PortletInfoService by having this "initial" PortletInfo provided by the PortletConfigImpl itself, also allowed the ThreadLocal based PortletContainerInvocationService!
        Hide
        Ate Douma added a comment -

        Further adjustments to the above:

        The Request/Response*Context interfaces of course really are portal (driver) implementation specific and as such belong to the "required" category and must be provided by the Pluto Portal driver
        (these most importantly replace many of the old PortletURLProvider, some of the PortalCallbackService functionalities)

        Furthermore, PortletContextManager, PortletRegistryService and PortalAdministrationService are also primarily PortalDriver services and/or only used from the (driver) PortletServlet.
        I'll move the access to these in a new PortalDriverservices interfaces, besides the RequiredContainerServices and OptionalContainerServices as for the container they are not needed services.

        Show
        Ate Douma added a comment - Further adjustments to the above: The Request/Response*Context interfaces of course really are portal (driver) implementation specific and as such belong to the "required" category and must be provided by the Pluto Portal driver (these most importantly replace many of the old PortletURLProvider, some of the PortalCallbackService functionalities) Furthermore, PortletContextManager, PortletRegistryService and PortalAdministrationService are also primarily PortalDriver services and/or only used from the (driver) PortletServlet. I'll move the access to these in a new PortalDriverservices interfaces, besides the RequiredContainerServices and OptionalContainerServices as for the container they are not needed services.
        Hide
        Ate Douma added a comment -

        From: http://www.nabble.com/Re%3A--VOTE--Cleaning-up-our-packages-p22426226.html

        As indicated, I've started the package cleanup (PLUTO-537).

        But... while doing this, the more it becomes clear this whole SPI package naming really isn't that appropriate.

        While the SPI packaging indicates "pluggable" interfaces to be provided/implemented by the portal,
        in practice a large part of the Pluto provided SPI implementation classes really are very core/generic/standard and are unlikely to be (completely) replaced by an embedding portal.
        And then, some other interfaces are expected to be provided, extended or replaced by the embedding portal.
        Furthermore, some interfaces are more Object model like, while others clearly are services like.

        I'm now planning to follow the suggestion Carsten already somewhat made in his initial proposal, and use a much more descriptive packaging structure (based on the previously targeted packaging) which also better "aligns" with the jar "container" naming:

        container-api:

        • move o.a.p.* to o.a.p.container
        • move o.a.p.driver.* to o.a.p.container.driver
        • move.o.a.p.spi.* to o.a.p.container
        • move.o.a.p.om.portlet.* to o.a.p.container.om.portlet
          and:
        • move all o.a.p.container services to o.a.p.container.services

        container (impl):

        • move o.a.p.impl.* to o.a.p.container.impl
        • move o.a.p.driver.impl.* to o.a.p.container.driver.impl
        • move o.a.p.om.portlet|portlet10.impl to o.a.p.container.om.portlet|portlet10.impl
        • move o.a.p.spi.impl to o.a.p.container.impl
        • move.o.a.p.impl.util to o.a.p.container.util
          and:
        • move all o.a.p.container.impl Default*Services (or similar like PortletContextManager) to o.a.p.container.driver.impl
        • move all o.a.p.container.impl Request/Response*ContextImpl to o.a.p.container.driver.impl.DefaultRequest/Response*Context
          (these really will be only light weight implementations and primarily for usage by Pluto Portal Driver)
        Show
        Ate Douma added a comment - From: http://www.nabble.com/Re%3A--VOTE--Cleaning-up-our-packages-p22426226.html As indicated, I've started the package cleanup ( PLUTO-537 ). But... while doing this, the more it becomes clear this whole SPI package naming really isn't that appropriate. While the SPI packaging indicates "pluggable" interfaces to be provided/implemented by the portal, in practice a large part of the Pluto provided SPI implementation classes really are very core/generic/standard and are unlikely to be (completely) replaced by an embedding portal. And then, some other interfaces are expected to be provided, extended or replaced by the embedding portal. Furthermore, some interfaces are more Object model like, while others clearly are services like. I'm now planning to follow the suggestion Carsten already somewhat made in his initial proposal, and use a much more descriptive packaging structure (based on the previously targeted packaging) which also better "aligns" with the jar "container" naming: container-api: move o.a.p.* to o.a.p.container move o.a.p.driver.* to o.a.p.container.driver move.o.a.p.spi.* to o.a.p.container move.o.a.p.om.portlet.* to o.a.p.container.om.portlet and: move all o.a.p.container services to o.a.p.container.services container (impl): move o.a.p.impl.* to o.a.p.container.impl move o.a.p.driver.impl.* to o.a.p.container.driver.impl move o.a.p.om.portlet|portlet10.impl to o.a.p.container.om.portlet|portlet10.impl move o.a.p.spi.impl to o.a.p.container.impl move.o.a.p.impl.util to o.a.p.container.util and: move all o.a.p.container.impl Default*Services (or similar like PortletContextManager) to o.a.p.container.driver.impl move all o.a.p.container.impl Request/Response*ContextImpl to o.a.p.container.driver.impl.DefaultRequest/Response*Context (these really will be only light weight implementations and primarily for usage by Pluto Portal Driver)

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development