1 2 Previous Next 27 Replies Latest reply on Aug 18, 2007 2:25 AM by lukin

    WANTED: Input from administrators & developers

    theute

      As part of our plans to improve on JBoss Portal administration, we would like to hear about your needs.
      This is your chance to define the required features and prioritize our work at this early stage.

      There are two main fields:
      Metrics and provisioning. For infrastructure reasons, we will start by implementing the metrics part.

      Metrics can be monitored and trigger alarms while provisioning help you manage your JBoss Portal instance.

      Here is a list of things that i can think of:

      Metrics:
      - Availability: One need to know remotely if the portal is running fine. It means that all related services are up and running (CMS service if used, Database...)
      - Size of the database tables/ Maximum size allowed -> trigger alarm when the table size is reaching the max
      - Number of database hits per time unity
      - Time to render portlets (min, max, average) -> Help figure out which portlets are slowing down the page rendering
      - Time to render a page (min max, average)
      - Consumed instances (WSRP)
      - Produced instances (WSRP)
      - Number of users
      - Number of roles
      - CMS availability
      - CMS number of documents
      - Min/Max/Time to get a content from the CMS
      - Invalidate CMS cache (on a cluster)
      - CMS cache utilization (on a cluster)
      - List available portlets

      Provisioning:
      - Change datasource (copy data over)
      - Pages definition export from database to XML (-objects.xml, -instances.xml)
      - Migration from JBoss portal version to the other
      - Secure a window/a page/a portal
      - Invalidate portlet cache

      Now this is open to discussion to add/remove/modify features from this list.

      As most of you are probably developers, if you are working on a major project using portal please ping your administrators to get their input on what they will want/need to efficiently administrate and monitor JBoss Portal.

      Thanks in advance !

      Thomas.

        • 1. Re: WANTED: Input from administrators & developers

          One more point: XML Export of the portal config, and even a versionable snapshot that I can rollback if need be. Also helps enterprise customers move their staging env to production without having to synch DBs.

          Thomas, do you know how much of this will be made available through ON, exclusively?

          • 2. Re: WANTED: Input from administrators & developers
            jewhit

            this may be a bit off target, but we just bought Jboss ON. what is the timeframe for ON to fully support Portal ? from what i understand, there is some basic stuff that is there (due to the underlying AS) but there are bells and whistles that are missing.

            thanks
            JW

            • 3. Re: WANTED: Input from administrators & developers
              theute

              This is the purpose of this topic, to define "fully support Portal"

              I'd love to hear from you

              • 4. Re: WANTED: Input from administrators & developers
                jewhit

                unfortunately, we just purchased ON so i can't say that i have tinkered with it much, but these are the things i can identify as having the most value for our organization:

                1) it would be nice to be able to centralize administration of user portlets rights, etc... directly from ON, as opposed to having administrators log into each portal "instance"

                2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it.

                3) directly edit / deploy all critical XML's from ON

                4) to further extend on Roy's point... if i understood him correctly... it would be absolutely bitchin if porlet instances or CMS content could be archived remotely and restored from ON.

                5) this has nothing to do with portal directly... but when doing major portlet / portal code changes, the database purge / data directory remove / rebuild can be a real hassle... especially in heavy prototype / production enviornments. would it be possible to utilize ON to at the minimum "reinsert" users and roles upon redeployment... or at the click of a button in the console ? obviously, permission associations to portlets can't be restored, as portlets / portal deployment may change, but the ability to resync users and roles would be a big help. it sure beats having to create sql scripts manually to reinsert.

                these are the things i can think of offhand. maybe some of these things are already possible. I will throw more things at you once i get ON installed and running... or at the minimum after i go to the roadshow tomorrow. i would guess we will do our own install late this week / early next week for our test servers.

                thanks
                JW

                • 5. Re: WANTED: Input from administrators & developers

                  Hallo JBoss Team :)

                  I just started to evaluate JBoss Portal Server. You did a good job and i am looking forward to help you in improving Portal.

                  XML import

                  "thomas.heute@jboss.com" wrote:

                  - Change datasource (copy data over)
                  - Pages definition export from database to XML (-objects.xml, -instances.xml).


                  WPS (WebSphere Portal Server) has very nice XML import/export interface (XMLAccess) that allows developers and administrators to import/export entire portal configuration or desired parts of the configuration (portlet instances, pages, users and so on). Such robust xml import/export alows you to migrate to new version of the portal, switch from one DB/LDAP to another (without creating some DB-specific scripts or dumps), reproduce portal environment to local development and so on.

                  So the idea is quite simple:
                  - all the data that is stored in DB should be also configurable via xml.
                  - unique names (not DB ids) must be provided/generated for all portal objects.
                  - unique names offer common and simple lookup in xml scripts, render-url generation (can be used in Themes or CMS portlets for linking to portal pages/portlets).

                  It is possible to merge contents of the -object.xml and -instances.xml and extend it with additional data for exporting user/group information. Such "config.xml" can evolve with the new versions of the portal, but will still contain data in quite abstract format in order to provide backward compatibility between portal versions.

                  Portal Model

                  In object.xml developer may specify custom properties for dirrerent portal nodes. Is it possible to provide read access to these properties via PortalNode interface? In this case developer can access these helpfull properties in jsp (via taglib?) or portlet without using PortalObjectContainer.

                  Layout

                  Is it possible to use JSP in order to create custom RenderSet? This will keep layout element consistent as jsp's. Some jsp tags can be provided to access custom properties and other objects that are important for rendering.

                  Bogdan.

                  • 6. Re: WANTED: Input from administrators & developers
                    dhartford

                     

                    2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it.


                    Seperating out the CMS "server"/repo would definately help, not only for jboss portal but also as a seperate file-repository to develop against (aka WebDAV/JCR repo for other than just portal-CMS).

                    It would be great to deploy a 'Jboss Repo' that stores the CMS content and have the jboss-portal upgrades be seperated/less dependent of the repo. Could also setup CMS-bundles that are added to the repo and point to them from jboss-portal.

                    As another item, would be nice to have seperate administration/backup functionality that is domain-knowledge-specific to the repository versus the portal (i.e. portal admins deal with portal stuff, storage admins deal with storage stuff).

                    my two coppers,
                    -D

                    • 7. Re: WANTED: Input from administrators & developers
                      orionyiu

                      A "delegated administration" function, that is the ability to assign the right to a user to administer certain portal pages or portlets. Right now the administrator can manage the entire portal. However, in many organizations they would like to manage the portal at least at a departmental level.

                      An inheritance concept, that is if a user can administer a page he/she could administer the portlets/pages underneath it would be helpful too.

                      • 8. Re: WANTED: Input from administrators & developers
                        theute

                         

                        "roy.russo@jboss.com" wrote:
                        One more point: XML Export of the portal config


                        That's what i meant by "Pages definition export from database to XML (-objects.xml, -instances.xml)" it's good to define it better though.

                        and even a versionable snapshot that I can rollback if need be. Also helps enterprise customers move their staging env to production without having to synch DBs.


                        For versionning, shouldn't it be the administrator responsibility ? If he can get a dump of the current state of the portal at different time, he can restore the portal to whatever version he wants

                        Thomas, do you know how much of this will be made available through ON, exclusively?


                        No, we have to define what makes sense in ON and what makes sense in the portlet, those are 2 different concept. All monitoring (Statistics) will be in JON of course.

                        • 9. Re: WANTED: Input from administrators & developers
                          theute

                           

                          "jewhit" wrote:
                          unfortunately, we just purchased ON so i can't say that i have tinkered with it much, but these are the things i can identify as having the most value for our organization:


                          No worry, it's even better if you didn't look at it, you have a fresh opinion on the subject.

                          1) it would be nice to be able to centralize administration of user portlets rights, etc... directly from ON, as opposed to having administrators log into each portal "instance"


                          Ok. I also think that it makes sense.

                          2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it.


                          You mean the existing "CMS Admin portlet" but directly from ON ?

                          3) directly edit / deploy all critical XML's from ON


                          We will do that, we also need to reflect the changes without having to restart. For example adding an intereceptor means modifying a jboss-service.xml file but would only be picked up after a restart, we also need to add the interceptor dynamically.

                          4) to further extend on Roy's point... if i understood him correctly... it would be absolutely bitchin if porlet instances or CMS content could be archived remotely and restored from ON.


                          Yes, it will be priority No1 for provisioning i think.

                          5) this has nothing to do with portal directly... but when doing major portlet / portal code changes, the database purge / data directory remove / rebuild can be a real hassle... especially in heavy prototype / production enviornments. would it be possible to utilize ON to at the minimum "reinsert" users and roles upon redeployment... or at the click of a button in the console ? obviously, permission associations to portlets can't be restored, as portlets / portal deployment may change, but the ability to resync users and roles would be a big help. it sure beats having to create sql scripts manually to reinsert.


                          This is more a development related thing, so not really something for administrators. This would have to be part of some "tools" any volunteer to work on the IDE that a contributor started ? I agree that we can improve on that.

                          these are the things i can think of offhand. maybe some of these things are already possible. I will throw more things at you once i get ON installed and running... or at the minimum after i go to the roadshow tomorrow. i would guess we will do our own install late this week / early next week for our test servers.

                          thanks
                          JW


                          Thanks a lot for your valuable input !

                          • 10. Re: WANTED: Input from administrators & developers
                            theute

                             

                            "bogdan.sulima" wrote:
                            Hallo JBoss Team :)

                            I just started to evaluate JBoss Portal Server. You did a good job and i am looking forward to help you in improving Portal.

                            XML import

                            "thomas.heute@jboss.com" wrote:

                            - Change datasource (copy data over)
                            - Pages definition export from database to XML (-objects.xml, -instances.xml).


                            WPS (WebSphere Portal Server) has very nice XML import/export interface (XMLAccess) that allows developers and administrators to import/export entire portal configuration or desired parts of the configuration (portlet instances, pages, users and so on). Such robust xml import/export alows you to migrate to new version of the portal, switch from one DB/LDAP to another (without creating some DB-specific scripts or dumps), reproduce portal environment to local development and so on.


                            This is what we want to do, i don't have access to WebSphere portal though so i don't know how it works for them, but i rely on your feedback to do better ;)

                            So the idea is quite simple:
                            - all the data that is stored in DB should be also configurable via xml.
                            - unique names (not DB ids) must be provided/generated for all portal objects.


                            We have that

                            - unique names offer common and simple lookup in xml scripts, render-url generation (can be used in Themes or CMS portlets for linking to portal pages/portlets).


                            I don't get it

                            It is possible to merge contents of the -object.xml and -instances.xml and extend it with additional data for exporting user/group information. Such "config.xml" can evolve with the new versions of the portal, but will still contain data in quite abstract format in order to provide backward compatibility between portal versions.


                            We had those 2 files merged (in 2.2), Julien decided to split for WSRP. We kept backward compability though.


                            Portal Model

                            In object.xml developer may specify custom properties for dirrerent portal nodes. Is it possible to provide read access to these properties via PortalNode interface? In this case developer can access these helpfull properties in jsp (via taglib?) or portlet without using PortalObjectContainer.

                            Layout

                            Is it possible to use JSP in order to create custom RenderSet? This will keep layout element consistent as jsp's. Some jsp tags can be provided to access custom properties and other objects that are important for rendering.

                            Bogdan.


                            This is getting out of topic (I would like to stick with administration "stuff" in this topic.

                            Please open (a) new topic(s) in "JBoss Portal" forum if you have questions thanks.

                            And thanks again for your input, i appreciate it.


                            • 11. Re: WANTED: Input from administrators & developers
                              theute

                               

                              "dhartford" wrote:
                              2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it.


                              Seperating out the CMS "server"/repo would definately help, not only for jboss portal but also as a seperate file-repository to develop against (aka WebDAV/JCR repo for other than just portal-CMS).

                              It would be great to deploy a 'Jboss Repo' that stores the CMS content and have the jboss-portal upgrades be seperated/less dependent of the repo. Could also setup CMS-bundles that are added to the repo and point to them from jboss-portal.


                              I am not sure to get this right, the "CMS server" is already quite independent (it is JackRabbit) with a homebrew Hibernate storage.
                              This could be interesting to discuss over the phone during a conf call. I am not even sure you and jewhit are talking about the exact same thing. Please email me if you are interested by a call, same for jewhit.

                              As another item, would be nice to have seperate administration/backup functionality that is domain-knowledge-specific to the repository versus the portal (i.e. portal admins deal with portal stuff, storage admins deal with storage stuff).


                              Ok, the underlying thing is to add the notion of group i guess (on top of user/role), we already talked about it and it is something that we need to allow.


                              my two coppers,
                              -D


                              They worth a dime ;)
                              Thanks for your input

                              • 12. Re: WANTED: Input from administrators & developers
                                theute

                                 

                                "orionyiu" wrote:
                                A "delegated administration" function, that is the ability to assign the right to a user to administer certain portal pages or portlets. Right now the administrator can manage the entire portal. However, in many organizations they would like to manage the portal at least at a departmental level.

                                An inheritance concept, that is if a user can administer a page he/she could administer the portlets/pages underneath it would be helpful too.


                                Agreed, we need to implement that, to be honest with you, the 2.6 roadmap is already pretty charged, we always accept help from contributors if you or any reader have middleware knowledge and big motivation.

                                • 13. Re: WANTED: Input from administrators & developers
                                  dhartford

                                   

                                  I am not sure to get this right, the "CMS server" is already quite independent (it is JackRabbit) with a homebrew Hibernate storage.
                                  This could be interesting to discuss over the phone during a conf call. I am not even sure you and jewhit are talking about the exact same thing. Please email me if you are interested by a call, same for jewhit.


                                  jewhit and I may have different ideas/goals, not sure. Nonetheless, Jackrabbit was the path I was going down anyway -- and as of yesterday Jukka released a 1.1-rc1 with a compatible JCA adaptor making this a lot easier.

                                  As for independent, I guess I always see portal and the repo(jackrabbit) installed together, and it may be nice to have them seperate with a 'combo' install for those that do want them installed from one package.

                                  One 'Jboss Repo' package for Jackrabbit JCA, JCR support, WebDAV support, and the jboss hibernate wrapper (Shotoku I assume), possibly with their own admin tools (i.e. repo security/access, storage sizing, storage locations on local disk, iSCSI, SAN, etc, backup utilities, more). From the Provisioning side, I think the seperation of the portal and the repo would help out a lot, as well as add another service layer available to developers related to file-based/non-relationalDB storage.

                                  • 14. Re: WANTED: Input from administrators & developers
                                    theute

                                    I agree that it would be interesting and we already discuss that a while ago with Julien.

                                    It doesn't come to the highest priorities though.

                                    Let's bring back the discussion to the administration features required in general (without refactoring the whole codebase ;) )

                                    1 2 Previous Next