0 Replies Latest reply on Jan 16, 2003 3:30 PM by Viet

    first analysis repost from jboss-dev

    Viet Master

      hi folks,

      JNuke adventure has started.
      After analysis of PostNuke I've began the development, still early though.

      I keep everything that's good in PostNuke and throw all the shit away :

      modules, blocks, permissions system, url system and themes.

      JMX is used for PostNuke components : themes,
      modules and blocks are all JMX mbeans. Here are my reasons :

      A : general

      1.we need a component structure, why not JMX ? after all
      another forum say that's lightweight.

      2.theses components do not have to scale, i.e the number of modules,
      blocks and themes is very small.

      B : for modules

      1.Ability to deploy/undeploy when application is running.

      2.It's easy to deploy additional modules as a separate deployment and
      have them register in the same registry.

      3.PostNuke is all about invoking module functions.
      Url like index.php?module=User&op=register means
      that the PN must call the method register on module User.
      For me that means that the servlet retrieves the mbean
      under the name jnuke:publicmodules:name=User
      and invokes the operation register().

      4.When a module is installed and configured it plug
      block mbeans in the JMX.

      C : for blocks, same reasons as above except 3 and 4
      as invocation is typed for 3.

      D : for themes, same reasons as above except 3 and 4
      as invocation is typed for 3.

      EJB are used for the model :

      UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will
      be CMP 2.0 beans. We'll use local invocations and same trick
      as in forum to make them faster. Plus more beans.

      Each module is made of :

      1.ModuleMBean : is the module itself, does not provide fucntionnalities,
      it's used to manager the PublicModule. Main operations are lifecycle
      (initialize, activate, unactivate, uninitialize)

      2.PublicModuleMBean : is created when ModuleMBean activates and is
      responsible for serving requests. The MBean is dynamic and operations
      with no arguments and no returns are served.

      It's up to the module to do as he wants : if he wants MVC it can, it
      it wants to mix HTML and code, it can. First modules won't be MVC
      as they simply don't need.

      It's up to the model to have the persistence mecanisms it wants. First
      modules will use EJB. With lifecycle operations, each module can install
      itself, for instance :

      a ModuleMBean is plugged :
      1.module configuration, setup of variables
      2.initialize : module can creates table, deploy EJB, plugs block.
      3.activate : module
      then go to block admin and creates instances of blocks (if module
      use blocks), display them on the page.

      Each block is made of :

      1.BlockMBean : manages BlockInstanceMBean.
      2.BlockInstanceMBean : is a block instance, it contains a title and a position
      on web page + 3 operations : display(), edit(), update().
      display() : displays the block instance
      edit() : used to edit the block in block administration
      update() : used to upate the block in block admin

      Each them is made of various callbacks that displays HTML on the page.
      It has to provide location of files like css, gifs, etc...
      THe first them I did is made of a servlet that register to JMX
      and the doGet operation serves the files. It's default theme.
      To make the thing simpler, it will be possible to make theme with JSP
      because I want to keep post nuke spirit.

      Ideally, even Module and Blocks could be made as JSP of things like that, that keeps
      PHP easy to do spirit.

      I did not thought a lot about permissions. In PostNuke, each module is responsible
      for checking security. I know that could be done with AOP but I don't know if it's
      gonna now, later or never :-)

      One problem is the configuration persistence. I don't know how our JMX implementation
      is far there. But if there is a restart, all config must be re-done. JMX persistence
      will save us there. Even though it's plain file and not JDBC.

      I will check out later (now it's a true mess), but I can say what works :
      Themes + default theme is done
      modules and module invocation.
      That means that yes, it displays me something that's nice to watch
      and I can invoke some operations although it's very early.