Uploaded image for project: 'ModeShape'
  1. ModeShape
  2. MODE-1554

Improve ModeShape's AS7 subsystem to better adhere to conventions

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Blocker Blocker
    • 3.0.0.Beta3
    • 3.0.0.Alpha4
    • Server
    • None

      We got some great feedback from tomazcerar on our AS7 subsystem. We were originally patterning our subsystem after Infinispan's, but the AS7 team has made several improvements (e.g., additional classes) that we can use to simplify our codebase and make our code follow their conventions. This should also make it more likely our subsystem will work in future AS7 versions, especially 7.2.

      Tomaz was kind enough to give us a pull request with some of the suggested changes. Hopefully we can merge them (to accept his changes) and then continue with the changes.

      Here's some detail from an email discussion:

      Try not to use DescriptionProviders directly but instead use ResourceDefintion/AttributeDefinition for defining the model. If you do this maintaining of management model will be much easier that it is right now. Most of subsytems in as7 codebase have already been migrated/converted others are scheduled for 7.2. Problem with manually implementing DescriptionProvider is that it is very error prone and it does not provide unified model.

      How to write Extensions wiki was updated to include this "new" better way of defining the model.

      ...

      Example code for what wiki is talking about can be found at
      https://github.com/jbossas/archetypes/tree/master/jboss-as-subsystem-example. If you look the as7 codebase, the simples subsystems that use this are mail, web, xts, modcluster. Infinispan is one that hasn't been migrated yet.

      Another comment from Tomaz:

      So I started converting the subsystem to ResourceDefinition and created pull request for my work: https://github.com/ModeShape/modeshape/pull/377. While doing so I have found out few more problems in your code that you should address.

      index-storage & binary-storage resources don't have "ADD" and "REMOVE" operations defined which are required for any resource, instead you have 4 different add-something methods which is fine by itself but it should still have add and remove for resource itself. Given the context I thing that you are actually trying to achieve something else to have a hierarchy of index storage types which could be done different way as you have now.

      I would create hierarchy that looks something like this:

      subsystem=modeshape
        repository=* (where * is then name of repository)
          configuration= index-storage
             storage-type=ram
             storage-type=local-file
             storage-type=master-file-index
             .
             .
          configuration= binary-storage
             storage-type=file-binary
             storage-type=db-binary
             .
             .
      

      In that case you can have simple add operation for configuration=index-storage and also for all specific types for storage. Same could be applied for binary storage or even something else that you need. This would greatly simplify management trough cli and also maintaining the code.

      The path element "storage-type=ram" need to have its own ResourceDefinition, as does "storage-type=local-file" and that enables you to define different attributes for every path element you have.

              rhn-engineering-tejones Edwin Jones
              rhauch Randall Hauch (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: