Version 3

    This roadmap is divided in two parts, JBoss Portal Developer Release (23 September of 2004) and JBoss Portal Alpha (December of 2004).




    JBoss Portal Developer Release


    • PortalContainer :

      • Property management :

        • DONE - Define a set of interface that can have several implementations

        • DONE - Basic implementation, in memory


    • JSR-168 implementation

      • DONE - TCK compliance (for TC4, some test are not passing on TC5)

        • DONE 2 days - Look at the security stuff

        • DONE 3 days - Implement preferences on top component properties

        • DONE 3 days - Custom client properties per component. I don't know if that should be part

        of the portal container or Nukes yet. This part is rather complicated because

        several sources for properties needs to be aggregated (portal,component,user,group)

        and need some kind of layered approach with some rules to compute the returned value.

        At least the API to retrieve these properties needs to be defined by the PortalContainer.

    • DONE  2 days - Improve web application interception : works for TC4 and TC5


    • DONE Put basic portlet examples

    • Document the release : usage and architecture

    • DONE 2 days - Basic theme

    • DONE 2 days - Convert to JBoss-4.x : there are minor problem with

    • DONE 9 days - Decide which component are displayed ? do we need to introduce a page concept ?

      For now in Nukes 1.x the algorithm is : in the center render the target module

      then take all the blocks, remove the block the user cannot see and display everything.

      This has is sufficient for Nukes 1.x but is too simplistic for advanced scenarios.




    JBoss Portal AlphaBeta


    • 2 days - Fetch config from tomcat connectors, the portal needs to know what are the ports (HTTP and HTTPS).


    • 4 days - User/Group :

      • Reimplement persistence with hibernate

      • User defined properties

      • Group defined properties


    • 2 day - Security :

      • Move the security from the module object to the request object.


      8 days

    • Existing modules : Either convert the modules to the portlet format or modify the current and improve

      the current Nukes 1.x custom API

      • Reimplement Nukes interface (Page object) based on the component framework or define a new set

       of intefaces similar to portlet.


    • Improve the security management. I believe that the current Nukes authorization

      mechanism is ok though it needs some fixes but the authentication needs to be

      switched on JAAS. See how this would be possible with servlets and single sign on.


    • Define a theme API : The Portal Container will procude during an invocation a result

      which is a set of page fragment. These page fragment will all inherit the same class

      but will have various custom properties (for instance a Portlet window has a PortletMode).

      We need to find the right architecture for theming here. A fragment should be rendered

      on screen by a general mechanism and let room for customized renderers.

      Assignee : Roy


    • Define a mechanism to allow component to specify a custom stylesheet during a request.


    • JSR-168 implementation

      • Finish JSR-168 implementations :

        • PLT. Exceptions During Request Handling : temporary unavailability

        • PLT.8.4 Custom Portlet Modes : map these to something

        • PLT.9.4 Custom Window States : map these to something

        • PLT.11.2.1 : Retrieving Uploaded Data : look at it

        • PLT.12.3.4 : Namespace encoding : all

        • PLT.14.3.1 : Localizing Preferences Attributes : look at it

        • PLT.17.1 : Defining User Attributes : look at it

        • DONE PLT.18 Caching

        • PLT.20.4 Specifying Security Constraints : all




    Sometime later


    • Instance distribution


    • Extract the text rendering framework from Nukes 1.x, make it an independant module (maybe project).

      Consider to release it as standalone.


    • Define an invocation pipeline at the application level. Ideally Nukes components

      should use that pipeline.


    • The pipeline has interceptors applied locally and globally

      and handle orthognal aspects of the application. In the pipeline we push application

      commands (see the gof Command pattern). This is how it works today for the forum and the HTML

      module. For instance for the forums the applied concerns are the mail notifications, the search

      engine index modifications etc... The goal here would be to have global interceptors configured to

      react on application events.


    • Allow command invocation by other mechanism than HTTP request. For instance the Nukes 1.x

      integration with JBossMailServer will use the ReplyCommand to create a reply to a post.


    • Finish JBossMail/BB integration