14 Replies Latest reply on Jan 17, 2007 6:26 AM by Antoine Herzog

    JCR CMS Repository on distant machine

    Antoine Herzog Master

      Hello,

      I would like to have an instance of JBPortal run on Machine A (dev), working with the CMS Repository that is on Machine B (pre-prod).
      Only one repository, for both machines.
      (using the repository with the filesystem persistence, but I can use a database if it is necessary)

      How to do it : clues, idea ?

      I guess : the JCR is base on JackRabbit and JMX service, so it must be possible to do it.
      My question is : how, tricks, drawbacks etc....
      some help to do it quickly, without searching all the doc of JackRabbit, thinking of how to do it with the JMX services etc...

      shall I use the same JMX service (CMS) on Mach B, and call it from mach A ?
      (is this possible ? clues ? how to configure the descriptor)

      use two CMS JMX service on both machines, that work on the same filesystem of JCR persistence ?
      (conflicts in concurrent access to the same file?)

      well, any clue, where to look in documentation, etc... would help (and save time...)
      and may be usefull for others...

      Thank you


        • 1. Re: JCR CMS Repository on distant machine
          Olivier Newbie

          Hello,

          I have reade some wiki on the web, at JBoss maybe, that explain how to :
          - deploy a JCR repository (jackrabbit) on JBoss AS with JCA
          - make it available via RMI

          But, then you should change JBoss Portal parameter to use that JCR repository you've just defined. I haven't seen yet where changes have to be made.

          Olivier.

          • 2. Re: JCR CMS Repository on distant machine
            Antoine Herzog Master

            Thanks,
            I will look this way. I also look at Alfresco, that may provide the repository service access in several ways.

            • 3. Re: JCR CMS Repository on distant machine
              Olivier Newbie

              Hello Antoine,

              As Alfresco tools, there is another open source product that is called Magnolia. You should have a look to it too.

              If you manage to make all that work, thanks to explain a little how.

              Thanks in advance,

              Olivier.

              • 4. Re: JCR CMS Repository on distant machine
                Antoine Herzog Master

                For what we have seen (understood), magnolia is more a portal than a CMS. And we have chosen JBoss Portal yet.

                What we plan to do is to use the portal to publish documents, with all the portal features for many access and users (not always logged).
                and to use Alfresco to write and manage the content.

                we plan to do it this way :
                The portlet will access the content from the Alfresco repository, as read only (to show it to the users).
                We will use the Alfresco web app to write the content (internal team, not many users).
                We will use the WCM version of Alfresco, the one that is now in preview, to be able to do some XML Authoring (building document with the content in XML and the presentation layer aside, with some composition rules applied when building).

                lot of work to have all this work, but interesting to get these result, with each tool used for what it was made for.

                • 5. Re: JCR CMS Repository on distant machine
                  Olivier Newbie

                  Nice architecture.

                  I used to talk about such an integration you talked about, but with Magnolia.
                  Look at that post on Magnolia integration (http://jboss.org/index.html?module=bb&op=viewtopic&t=98840).

                  Magnolia has a portal part but a CMS part too.


                  Thanks for the hint, I'll test the Alfresco tools too. Maybe, it's easier to deal with for authoring content into a JCR repository than Magnolia.

                  Does someone knows if it exists Alfresco/Magnolia comparative articles on the web ?

                  Olivier.

                  • 6. Re: JCR CMS Repository on distant machine
                    Antoine Herzog Master

                    I don't know much about Magnolia.
                    here under is just my opinion.

                    what made us go to Alfresco is :
                    - a good tool for content editing, that can work with jboss portal (and a good classic repository and CMS tool).
                    - the XML Authoring : being able to compose content with several pieces and make the presentation layout at the end. That is to have a form to type the content in xml format, and then use this to build the content document, with some presentation transformation.
                    - the WCM feature, to edit the content and the source code in the same time and use some sandbox to have several person work at it independantly.

                    the first is a good thing we need.
                    the second is great : we haven't seen a open source global software offering this feature (as part of the more general and usual CMS features).
                    the third is more for the potential, for "later"... but it s a great feature.

                    the bonus with alfresco : brand new, nice and powerfull architecture.
                    if you are not looking for a mature software that as run for a few years yet, then alfresco looks good.

                    • 7. Re: JCR CMS Repository on distant machine
                      Thomas Heute Master

                      I don't think Alfresco still integrates with JBoss Portal identities. (so that you could protect resources for example)

                      Would anyone willing to contribute on this ? That would be an intersting thing to do i think.

                      • 8. Re: JCR CMS Repository on distant machine
                        Sohil Shah Master

                         


                        I guess : the JCR is base on JackRabbit and JMX service, so it must be possible to do it.
                        My question is : how, tricks, drawbacks etc....


                        This can be done by exposing the PortalCMS JMX service remotely

                        Try adding this to jboss-portal.sar/portal-cms.sar/META-INF/jboss-service.xml
                        <!-- Proxy factory for CMS -->
                         <mbean code="org.jboss.invocation.jrmp.server.JRMPProxyFactory"
                         name="jboss.jmx:type=adaptor,name=RemoteCMS,protocol=jrmp,service=proxyFactory">
                         <!-- Use the standard JRMPInvoker from conf/jboss-service.xxml -->
                         <depends optional-attribute-name="InvokerName">jboss:service=invoker,type=jrmp</depends>
                         <!-- The target MBean -->
                         <depends optional-attribute-name="TargetName">portal:service=CMS</depends>
                         <!-- Where to bind the proxy factory -->
                         <attribute name="JndiName">RemoteCMS</attribute>
                         <!-- Invoke target method instead of invoke(Invocation mi) -->
                         <attribute name="InvokeTargetMethod">true</attribute>
                         <!-- Comma-separated list of exported interfaces -->
                         <attribute name="ExportedInterfaces">org.jboss.portal.cms.CMS</attribute>
                         <!-- client-side interceptors -->
                         <attribute name="ClientInterceptors">
                         <interceptors>
                         <interceptor>org.jboss.proxy.ClientMethodInterceptor</interceptor>
                         <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
                         <interceptor>org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor</interceptor>
                         <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
                         </interceptors>
                         </attribute>
                         </mbean>
                        


                        This will provide you a remote cms proxy on which you can execute CMS Commands that you can create via the CommandFactory.

                        For examples with how to use the CMS object look at our org.jboss.portal.core.portlet.cms.CMSPortlet and org.jboss.portal.core.portlet.cms.admin.CMSAdminPortlet source code

                        one possible drawback of this way to access the CMS service is the access will be treated as "Anonymous" access which could lead possible lead to Access issues with the newly integrated fine grained security in Portal 2.6 Alpha1 release

                        The PortalCMS service sits on top of JackRabbit (JCR Impl), and to get file based storage of content, you should just be able to configure one of the FileBasedPersistence Managers packaged with JackRabbit. By default, the PortalCMS uses a Hibernate based Peristence Manager which is optimized for performance using JBossCache.

                        We are also evaluating integration with Alfresco especially their JCR Impl as an alternative to JackRabbit JCR Impl.

                        Hope this helps

                        Thanks
                        Sohil




                        • 9. Re: JCR CMS Repository on distant machine
                          Sohil Shah Master

                           


                          I don't think Alfresco still integrates with JBoss Portal identities. (so that you could protect resources for example)

                          Would anyone willing to contribute on this ? That would be an intersting thing to do i think.



                          Right on. I am going to evaluate Alfresco integration with our PortalCMS for a better out-of-the-box experience. here is the JIRA task for that

                          http://jira.jboss.com/jira/browse/JBPORTAL-1187

                          • 10. Re: JCR CMS Repository on distant machine
                            Antoine Herzog Master

                            I am starting to write a CMS portlet that go and get it's content from the JCR of Alfresco.
                            among other things... as navigation stuf etc...
                            may be we can share things and facts that show up, about this evaluation and new dev.

                            I wondered if I would build the access to the repository features through the jboss portal api (the service used under the JCR access api provided by jboss portal), or directly as an independant service.

                            I guess start as an independant service and then see how to configure things so the new repository used by my instance will be Alfresco instead of JackRabbit.

                            may be you can help on the second part of it : building the layer between jboss portal upper api, and alfresco repository service.

                            by the way : do you focus on the Alfresco 1.4 version, or the Alfresco WCM Preview version ?

                            I work more with the WCM, as I also need the XML Authoring feature. The Beta of this version is expected soon.

                            Thanks,

                            • 11. Re: JCR CMS Repository on distant machine
                              Antoine Herzog Master

                              forgot to say : the solution to access the JCR as a remote service on the previous pose : yes it helps a lot.
                              thank you for the code and example.

                              • 12. Re: JCR CMS Repository on distant machine
                                Sohil Shah Master

                                 


                                I wondered if I would build the access to the repository features through the jboss portal api (the service used under the JCR access api provided by jboss portal), or directly as an independant service.


                                JBoss Portal CMS API is an abstraction layer on top of the JCR API. Advantages of using that API would be to decouple your application code from low level details involved with the JCR access.

                                This makes your applications portable even if you decide to swap JCR impl as well as hookin some other content repository later on.

                                Other advantages of using the PortalCMS API would be out-of-the-box integration of fine grained security on the CMS resources and JBPM based workflow integration.

                                If you build out an independent service on top of JCR impl yourself, chances are you may create a parallel API similar to what we have in the org.jboss.portal.cms package.

                                But, feel free to develop with whatever API fits best your requirement, but one recommendation I would make is to not expose your application level components (portlets, JSF managed beans etc) directly to JCR API, becuase that will lock you into JCR


                                may be you can help on the second part of it : building the layer between jboss portal upper api, and alfresco repository service.


                                jboss portal upper api itself is the high level API that should directly deal with any JCR/repository related API be it Alfresco or JackRabbit.

                                Currently we provide JackRabbit integration, and we will provide the Alfresco based implementation soon.


                                by the way : do you focus on the Alfresco 1.4 version, or the Alfresco WCM Preview version ?


                                At this time the goal is to evaluate just the Alfresco JCR Impl with regards to performance, clustering, fail over etc.

                                WCM Preview is a high level end user tool that probably uses the Alfresco API.

                                You can always bundle the WCM tool and for application level access either user the JBoss Portal CMS API (once Alfresco JCR integration is done)

                                Thanks
                                Sohil




                                • 13. Re: JCR CMS Repository on distant machine
                                  Roy Russo Master

                                  Antoine,

                                  There are 2 initiatives underway wrt Alfresco:

                                  #1 As Sohil describes - investigating whether the portal cms can use the alfresco jcr impl.

                                  #2 Adding a "viewer portlet" for alfresco + portal, so users can view alfresco content.

                                  Sohil is busy with #1 for now. #2 is badly needed, actually, so if we can work together on that, then we should... so we dont duplicate effort. Feel free to email any one of us about it.

                                  • 14. Re: JCR CMS Repository on distant machine
                                    Antoine Herzog Master

                                    Ok, I'll send what I will do on a "viewer".
                                    It should be quite similar to the CMSPortlet.
                                    Just adapting a few things and the "getFile" method.
                                    It may be interesting to allow simple configuration to tell where to find the Alfresco repo.

                                    It could be interesting to be able to view the content comming from the WCM Sandboxes, that is comming throught the Alfresco VirtualHost (AVM).

                                    I am looking right now on how to reach the ServiceRepository from Alfresco, from the portlet (or JSF in the portlet) : what would be the best way. May be Sohill has some idea on that ?
                                    and the WCM VirtualHost too ?

                                    The other point is to manage the locale.

                                    On this, I'll do some more subtile strategie about "default" locale than the usual.
                                    For our project, there must not be any default locale... (et not "default is english as usual").
                                    I'll put this in a strategy pattern, so any one can use it's own strategy about locale.