7 Replies Latest reply on Sep 9, 2010 4:51 AM by Joerg Harm

    Portal configuration

    Nic Essling Newbie



      I have several questions regarding the right setup of GateIn after having read all guides and most of the posts in this forum.


      First of all, it's nice to create portal instances, pages, navigation and the like via the UI. However, in a real world environment I would expect you want to do so via configuration for several reasons:

      - you want to set up your portals with all pages etc. first in a test environment and when everything works as expected you want to deploy it as a whole package to production and not manually start on production to create everything via the UI.

      - depending on your use case you will have a lot of portals and pages and it would be donkey work to maintain this manually all the time.


      Having said that, I wonder what is the best approach for it. I know the various xml files like navigation.xml and pages.xml, but my understanding is that this is more or less limited to the very first launch of the portal. The content is written to the DB and unless I use a totally in-memory DB - which I definitely wouldn't do in a productive environment - I cannot update these xml files for subsequent launches. On the other side there is this concept of extensions which could be used to add pages to an already deployed portal or even to add a separate portal (see the samples in the installation package), but as far as Matt Wringe explained several times in some posts (e.g. http://community.jboss.org/click.jspa?searchID=700465&objectType=2&objectID=531434) this can only be used before the first launch either. So I really wonder, what is it goof for, if I cannot extend my portal after it already ran some time.


      So do I have to have everything laid out and defined in xml files at the very beginning and from then onwards only can maintain my portal via the UI? Or would I have to drop my JCR DB that it would be built from scratch on the next startup after I adjusted my xml files?


      Next question: given that I used the xml files to prepare my pages and navigation for the default portal "portal" and the default site "classic" (http:localhost:8080/portal/public/classic), how would I configure a separate site that runs in the same portal container (e.g. http:localhost:8080/portal/public/modern)? In the UI it is easy to create a new site, but how would I do it beforehand in xml?

        • 1. Re: Portal configuration
          Julien Viet Apprentice



          what you are saying makes a lot of sense and we are willing to address this in the future in a proper manner. What I mean by future is not yet determined.


          At the moment the whole configuration is stored in a Java Content Repository server that is available inside GateIn.


          The data is stored in a special model that is called MOP (Model Object for Portal), although we don't really support this data model externally: What I mean by that, is that we don't want to make the model change in later version of GateIn 3.2+ (community) but we cannot offer strong guarantees.



          So now if you decide to understand the model, you can do practically anything you want. One way to introspect GateIn data is to use the CRaSH shell (crsh.googlecode.com).


          You can use CRaSH to understand the model, you can even write your own commands to do cool stuff in gatein, like adding a new user (I've a command for that somewhere on my hard drive), create a page or whatever.

          • 2. Re: Portal configuration
            Nic Essling Newbie

            Thanks for your reply. I will definitely have a look at CRaSH.


            So can I deduct from your answer that successively maintaining a portal via xml configurations is not yet possible? So I either have to plan everything upfront via xml, or maintain it via the UI on the fly, or last but not least can try to manipulate it with CRaSH? What would be the behavior if I manipulate the repository with CRaSH while users are logged into the portal and using it?


            Any plans so far for enabling a real round-trip, meaning that from the JCR you could generate or export again xml files? With this feature I could first manually prepare my portal via the UI on one (test) server and afterwards generate xml configurations for my other (productive) server and start there with a full blown configuration of pages etc.



            • 3. Re: Portal configuration
              Thomas Heute Master

              We're actually still looking for a Senior developer to take on that task:



              But furthermore we are looking to gather requirements from users and customers. We have some ideas and some feedback but would be happy to have more requirements before we dig a lot into it.


              So the question is how would you see that functionality for your goals ? If you want to start a Wiki so people can contribute to the specification that would be just great. If you want to start prototyping, that's equally great

              • 4. Re: Portal configuration
                Nic Essling Newbie

                Thanks for the job offer, will think about it :-)


                I can definitely share my ideas with you about this. Do you have your ideas and feedback in a written manner so I could take it as a basis and go from there?

                • 5. Re: Portal configuration
                  Thomas Heute Master

                  For now I'd rather not influence anybody by directions.

                  There are many different situations, we need to find one that suits most.


                  One big differentiator for instance is when Dev/Staging/Prod/Test machines are on the same network and when they are not. Also if when running on a single node, a downtime is acceptable or not for an upgrade.


                  Be imaginative

                  • 6. Re: Portal configuration
                    Julien Viet Apprentice

                    Actually we do have some thought about an intermediary XML that would be different from the deployment descriptors but that could be used as deployment descriptor.


                    The main reason is that anything that is in the JCR after UI changes could not be exported as initial descriptors, so there would need for another XML descriptor set that would be designed for import/export


                    For instance if a page is pointing to a shared portlet instance, then it would not work with the current XML because it does not have this concept.

                    • 7. Re: Portal configuration
                      Joerg Harm Newbie

                      I tried to export the repository content using CRaSH, deleting the content, and to import it again. Unfortunately, the portal does not work after that.

                      Is there a way to export the configuration via CRaSH and later on import it to the portal on the same or another server (e.g. from development server to production server)? Which repositories need to exported?


                      Is there any documentation of MOP and examples of groovy commands for CRaSH?