Version 17

    JBoss Portal CMS Response Logic


    This article addresses some of the finer points of how JBoss Portal serves content from the JCR repository, and other CMS-related architecture issues.



    Scroll to the bottom of the page, to view diagrams on the CMS Object Model and CMS Service.


    • The Request:

      • Formatting: At the root of the logic when serving content, the portal must detect whether it is indeed a request for content from the repository, pertaining to the CMSPortlet. This is achieved by prepending the url for content with a predefined parameter. The MBean that manages this, can be seen in portal-cms.sar/META-INF/jboss-service.xml.

          <attribute name="Prefix">content</attribute>
          <attribute name="TargetWindowRef">default.default.CMSPortletWindow</attribute>
          <depends optional-attribute-name="Factory" proxy-type="attribute">portal:commandFactory=Delegating</depends>
          <depends optional-attribute-name="CMSService" proxy-type="attribute">portal:service=CMS</depends>
          <attribute name="Prefix">content</attribute>
          <depends optional-attribute-name="Factory" proxy-type="attribute">portal:urlFactory=Delegating</depends>


    We will be using these MBeans in the decision phase, so use them as a reference on this page.


    • Decision Phase:

      • Request for Content? As you can see, the default prefix is 'content'. Which means, any time a request is made to the portal in the pattern /content/path/to/file.gif, the portal will retrieve the file using path following the /content prefix.

      • Is it Streamable? The CMSObjectCommandFactory is reponsible for then obtaining the actual content and determining whether it is a request for a binary or a text document.

    For example: When requesting the default portal page http://localhost:8080/portal/content/default/index.html, the CMSObjectCommandFactory will handle the request and do the following:

    1. Retrieve content from repository using the path provided in the request, default/index.html.

    2. Determine whether it is a binary or text item.

      1. If binary, return a StreamContentCommand to the invoker.

      2. If text, invoke the CMSPortlet for rendering.

    • Render Phase: During the Render Phase in our CMS Logic, we determine how the content will be rendered.

      • StreamContent: If the CMSObjectCommandFactory determines the request to be for a binary item, it will return a StreamContentCommand, that once invoked by the portal, will set the appropriate content type for this item and stream it to the browser.

      • CMSPortlet: If the CMSObjectCommandFactory determines the request to be for a text/plan or text/html item, it will call the CMSPortletWindow to render the content, in its doView(). The doView() in this class also prepends urls found in html pages, so subsequent requests for inline gifs/jpgs/resources are handled properly.

    • Response: As was mentioned above, the CMSPortlet will rewrite (prefix /content) to existing inline resource links. This rewriting has the effect of triggering additional calls to the portal and beginning the cycle of logic again.


    JBoss Portal CMS JCR Structure