Version 3

    Nukes on JBoss runs on top of the PortalContainer. The value added are :


    • Advanced user management :

      Convert the user module


    • Security management :



    • Advanced modules :

      Later, that means Wiki etc...


    • Search engine :

      Each module can use that service to index the content it manages.


      • Benefits :

        • One single repository to manage

        • Unified search engine

      • We have : on disk index management and asynchronous index update.

      • Needs :

        • Define a metadata structure that modules can share for instance

        • Think about index replication, if a module updates the index, all the index should be updated as well,

        there are several ways to do that : JMS is one possibility, each index service subscribe to a clustered

        topic, but I don't think that the current JMS implementation can do that yet. Otherwise it could be possible

        to use the clustering framework.


    • Command framework:

      The current command framework defined in Nukes 1.x must be reused. Today is it leveraged by the

      forum and the HTML module. The benefits are :


      • Each command is encapsulated in one single class, can leverage OO inheritence.

      • Independant from the invocation layer : HTTP/HTML, SMTP

      • An individual command is easier to test

      • Command interception to add portal system aspects : search engine/notification/monitoring/flood control/security/etc...

      • History is easy to implement

      • Easier integration for 3rd party :

        • Create and invoke commands from outside of the module

        • Add custom interception to implement event driven behaviour


    • Page :

      There is a need for a page repository, each page contains a set of window.

      Today the page concept does not exist in Nukes 1.x so this is rather new.


    • Rendering :

      The portal framework defines the abstract notion of Component/Instance/Window.

      Since the notion of window is really generic it cannot handle specificity for a given

      one. For instance, a PortletWindow add the notion of WindowState and PortletMode and

      when it is being rendered the theme can use these specific informations to display

      control link that can affect this PortletWindow.

      Therefore there is a need to have a generic renderer for windows as well as specialized

      renderer for a window specialization.