8 Replies Latest reply on Dec 1, 2010 11:15 AM by brian.stansberry

    How to model the (optional) OSGi webconsole in AS7

    bosschaert

      The current subsystem of OSGi in AS7 is nicely lean and mean. It provides the OSGi core framework only with the standard OSGi JMX API added in.

       

      While this is nice for deployments, it's not so great as a developer setup. Although you can interact with framework using the JMX API using something like JConsole as a developer you often want something more focused on the OSGi. In the OSGi installer we provide a WebConsole which is quite a nice way to interact with the OSGi framework (see here for a screenshot: http://docs.jboss.org/osgi/userguide/html/ChapGettingStarted.html#SecWebConsole ), and I would like to make this webconsole easily available to users who want it directly in the AS7 download...

       

      I can see two options here:

      1. add another profile to the domain.xml/standalone.xml files that people could pull into their default profile
      2. alternatively I could simply add commented out XML to the osgi profile that people can un-comment to pull this functionality in

       

      Thoughts anyone?

        • 1. Re: How to model the (optional) OSGi webconsole in AS7
          brian.stansberry

          This is a problem we're going to face many times.

           

          I don't see commented out config as a solution. First, at this point, when the file is re-written following an update, comments are lost. That may change, but in general using the file as documentation is fragile. Second, if we added commented out sections for all the various options different subsystems may want to expose, we'll soon have a 1,00 line file full of confusing stuff.

           

          I think we're going to need a mix of things to solve this:

           

          1) Ship a few different canned configs files for the most common profiles, with the user able to select which they want via a command line switch.

          2) An "examples" dir in the dist where some less common choices can be highlighted.

          3) Most importantly, an installer application where users can easily tell us what subsystems they want in their profile. This is the most important part; #1 is mostly to provide a very easy out-of-the-box experience.

          • 2. Re: How to model the (optional) OSGi webconsole in AS7
            bosschaert

            Yeah, the commented-XML approach surely doesn't scale.

            On the profile approach, in order to make that scale it might make sense to allow splitting it over multiple files to keep them manageable. These files could be merged at runtime into a single logical XML document possibly using something like XML xinclude. This might make the rewriting following an update 'interesting', however

             

            I like the command line switch. Maybe we can do something like what maven has and support the definition of multiple profiles combined, so if I want to add my webconsole to the default profile I could call standalone.sh -Pdefault,osgi-webconsole or something like that...

            • 3. Re: How to model the (optional) OSGi webconsole in AS7
              thomas.diesler

              I'd say an IzPack installer like we have in jbosgi is the way to go

               

              https://jira.jboss.org/browse/JBAS-8657

              • 4. Re: How to model the (optional) OSGi webconsole in AS7
                brian.stansberry

                Agreed on the IzPack approach.

                 

                In discussions last week there were a lot of calls for breaking the config into multiple files. I expect we'll keep hearing that, so it's good to think about it. There are a couple problems I see:

                 

                1) The file write problem David pointed out. The domain model would have to start carrying around info about what files various pieces came from, plus generally messier parsing and persisting.

                 

                2) The logical thing to separate out into an included file is a subsystem config. But that config isn't entirely self-contained. For example, a subsystem could reference a socket-binding config that's in the socket-binding-groups section and a thread group defined in the threads subsystem. Plus it needs to be recorded as an extension. So to be really useful bringing in that subsystem's config isn't a simple matter of an include; it would be more of a merge.

                • 5. Re: How to model the (optional) OSGi webconsole in AS7
                  jaikiran

                  Thomas Diesler wrote:

                   

                  I'd say an IzPack installer like we have in jbosgi is the way to go

                   

                  https://jira.jboss.org/browse/JBAS-8657

                  Not that I'm against an installer for AS7, but one reason why the installer was considered problematic for choosing AS profiles, was because QA testing all possible combinations of profiles wasn't really easy. AS 4.0.x had an installer (IzPack iirc) but from what I know, it was discontinued due to the above reason.

                  • 6. Re: How to model the (optional) OSGi webconsole in AS7
                    brian.stansberry

                    Good point.

                     

                    There's an easy answer to that, which is that an installer is part of community AS and not part of the product. That's not very satisfying though. And I know Rich Sharples is interested in an installer-like capability, although in a  quick scan I didn't  that in any formal requirements doc. In the June discussions we had with Rich where we brainstormed a bit in that we didn't think about the QE implications though.

                     

                    Another question is what does an installer really mean in terms of added QE and support burden.  It's basically a tool for configuring the AS. So is the shell and a text editor; i.e. users have always been able to alter the AS "profile" and make it run a configuration that's not part of our formal test plan. So an installer doesn't add anything new there. What does seem new:

                     

                    1) If we make it completely trivial to run a particular profile (e.g. we ship a domain-messaging.xml with a nothing-but-messaging profile, or include in an installer a single checkbox to create such a canned profile) then users could expect that we've quite thoroughly QE'd that particular profile.

                     

                    2) Users might expect that the installer would only allow valid, bootable combinations; i.e. if subsystem X requires subsystem Y and socket-binding A, then a profile can't be created that doesn't include X, Y and A. Confirming the installer enforces that would be a QE burden.

                    • 7. Re: How to model the (optional) OSGi webconsole in AS7
                      fnasser

                      This sounds more like a configuration utility than a installer. Perhaps some independent tool we should add to bin.

                      • 8. Re: How to model the (optional) OSGi webconsole in AS7
                        brian.stansberry

                        Yes, "configuration utility" is a better term. I'm not talking about something that does any sort of provisioning here.