13 Replies Latest reply on Nov 25, 2008 12:23 PM by starksm64

    Profile Service api

      CORE PROFILE SERVICE

      As far as the core profile api goes this doesn't look too bad.

      It still has the VFSDeployment and DeploymentPhase stuff in there,
      I think we can live with that (its a bit too close to the implementation details for my
      liking).

      The part that I think is missing is the ability to add/remove profiles.

      My original idea for profiles was that the profile could be implemented how you like
      (picking from existing implementations or writing your own).

      The current api only allows you to create/remove implementations dictated by the
      profile service itself.
      You can see this problem in the way the farming stuff done by Brian is using
      the DeploymentManager of the profile service rather than adding his own sub-profile.
      But you can also see it in that there is no current support for sub-profiles at all really
      or activation/deactivation of these (the deployment phase was originally
      done as a hack until sub-profiles were implemented).

      The one part that really does look broken to me is the following method
      on the Profile interface.
      VirtualFile getRootFile(DeploymentPhase phase) throws Exception;

      This has no meaning when there are multiple roots.

      Since its use seems to be a location where template
      deployments get constructed this also looks broken if the profile is "read-only"
      by which I mean only admin overrides in the local repository are allowed
      not modification of the original source location.

        • 1. Re: Profile Service api
          starksm64

          Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?

          The getRootFile(DeploymentPhase) is only used to define a location that a DeploymentTemplate can use for generating a deployment. I didn't see a point to exposing multiple roots when the admin client has no knowledge of the root at all.

          • 2. Re: Profile Service api

            REPOSITORY API

            This is a lot worse.

            It's actually ok as it currently stands in princple since all of this
            is actually hidden as implementation details within the
            org.jboss.system.server.profileservice.repository.ProfileServiceImpl

            But where this doesn't work is that some of those implementation details
            have been promoted to spi when they clearly are nothing of the sort.

            e.g. org.jboss.profileservice.spi.DeploymentRepository
            This looks far too close to the implementation details to be done in any
            other way. Even to the extent of exposing locking methods.

            The AbstractAttachmentStore is probably closer to what people would
            really want to use in terms of changing behaviour. But this is not spi.

            But both contain incorrect assumptions like the repository and source of the
            profile come from the same integration point.
            These two things are seperate concerns. That should not be mixed.
            My guess is that a proper seperation would make the spi(s) for these a lot simpler.

            Just trying to read the source code for this is very hard.
            I found it difficult to understand which parts were referring to
            server/default/deploy or data/attachments/...
            The assumption that server/default/deploy is a file/directory is just broken
            and so are the names given to files in data/attachments (not unique enough).

            I'll conclude as I started. If it were possible to implement the (sub-)profile
            how you like, the current state of Repository API would not be an issue.

            • 3. Re: Profile Service api

               

              "scott.stark@jboss.org" wrote:
              Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?


              When I initially suggested the profile-service I imagined it as something like
              (assuming a more modern maven repository)

              Pseudo xml as usual :-)
              <profiles>
               <profile name="default">
               <source type="Maven">http://repository.jboss.com/maven2</source>
               <source type="Maven">http:/repository.acme.com/maven2</source>
               <sub-profile>naming</sub-profile>
               <sub-profile>transaction</sub-profile>
               <sub-profile>jms</sub-profile>
               <sub-profile>ejb3</sub-profile>
               <deployment>MyApp1</deployment>
               </profile>
              </profiles>
              


              The "deployment phase" if it is really a useful concept at all
              would be included within the profile definition, e.g.

              <profiles name="ejb3">
               <profile name="ejb3-deployer" phase="deployers">
               <source type="Maven">http://repository.jboss.com/maven2</source>
               <deployment>jboss-jpa-deployer</deployment>
               <deployment>jboss-ejb-deployer</deployment>
               </profile>
               <profile name="ejb3-runtime" phase="deploy">
               <source type="Maven">http://repository.jboss.com/maven2</source>
               <deployment>jboss-ejb3.beans</deployment>
               </profile>
              </profiles>
              


              I say it is probably not really useful because one could assume
              that the ejb3-deployer sub-profile must be fully deployed before
              ejb3-runtime is deployed.

              Basically, this is back to the original intention of the profile service
              which is to just provide a list of deployments you want deployed
              no matter where they come from.

              The handling of overrides from the management console
              to these original deployments is a different concern
              (although you could imagine the above pseudo xml containing
              xml elements that also include overrides from your own repository).

              I understand there are complications if you want the original deployments
              to be hot deployable (or don't if you set some lockdown flag after you've
              used the management console to edit them).
              The most complicated of these being patching where you try to merge
              the diff of the original into the config managed by the console.

              In terms of the farming (or the hot deployment prototype),
              this is just another way of producing a list of original deployments.


              • 4. Re: Profile Service api

                 

                "scott.stark@jboss.org" wrote:

                The getRootFile(DeploymentPhase) is only used to define a location that a DeploymentTemplate can use for generating a deployment. I didn't see a point to exposing multiple roots when the admin client has no knowledge of the root at all.


                But shouldn't this be creating the new template deployment in the data/attachments?

                • 5. Re: Profile Service api

                   

                  "adrian@jboss.org" wrote:

                  The handling of overrides from the management console
                  to these original deployments is a different concern.


                  This wasn't something I had in the original profile design.
                  In fact for a long time I assumed that JON was going to implement this
                  via some plugin to the profile service .
                  i.e. it would set the pre-determined managed objects of the deployment
                  (based on what has been overridden in the console and in its own repository)
                  before it got deployed.

                  The requirements then moved to be based on ManagedObjects.
                  After I did the initial work this, I posted that I thought the console operations should
                  be intercepted by the profile service using a mechanism similar to
                  what JBossCache does using AOP (including "transactional" change sets).
                  i.e. the ManagedObject/Fields would be enhanced with interceptors to trap
                  changes which would be persisted and progogated to the server(s).

                  But this was then rewritten to use ManagedDeployments and the AOP approach
                  got dropped. Which is where I've kind of lost sight of where this was going. :-)

                  I didn't expect it would end up with both the profile source(s) and console
                  edits in the same repository spi. :-)

                  • 6. Re: Profile Service api
                    starksm64

                     

                    "adrian@jboss.org" wrote:

                    But shouldn't this be creating the new template deployment in the data/attachments?

                    The issue is how different are additions going to be from the traditional deployment mechanism of placing the deployment into a deploy folder. If I add a datasource I'm expecting to see a deploy addition. Its just a question of transparency of the admin tool behaviors.


                    • 7. Re: Profile Service api
                      brian.stansberry

                      You guys write way faster than I do. :)

                      "scott.stark@jboss.org" wrote:
                      Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?


                      I don't see the contents of deploy-hasingleton as being a separate deployment phase; they are just APPLICATION, like everything in deploy.

                      What's special about them is their location in deploy-hasingleton marks them as belonging to a "hasingleton" subprofile. Registering them with the profile service as belonging to that subprofile could be a function of the scanner that's responsible for scanning that location. Or a function of the profile service impl; i.e. it has a configuration that understands that certain deployment URLs are associated with a particular subprofile. The latter has the advantage of allowing the regular repository HD scanner to scan both deploy and deploy-hasingleton.

                      Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.

                      The HASingletonDeploymentScanner's functionality them gets broken into 2 pieces:

                      1) The scanning/registration as part of subprofile function.

                      2) The activation function Adrian described at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136492&postdays=0&postorder=asc&start=10 . HASingletonDeploymentActivator calls profileService.deployProfile("hasingleton") when it determines it is the master node.


                      • 8. Re: Profile Service api

                         

                        "scott.stark@jboss.org" wrote:
                        "adrian@jboss.org" wrote:

                        But shouldn't this be creating the new template deployment in the data/attachments?

                        The issue is how different are additions going to be from the traditional deployment mechanism of placing the deployment into a deploy folder. If I add a datasource I'm expecting to see a deploy addition. Its just a question of transparency of the admin tool behaviors.


                        But then shouldn't the admin console edits modify the existing files?
                        How do they do if the dds are inside jars?

                        Ok this is simpler because it is a new file, but if the deploy/ folder is read-only
                        it ain't going to work.


                        • 9. Re: Profile Service api

                           

                          "bstansberry@jboss.com" wrote:

                          Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.


                          Ok but as it stands, the profile service doesn't know about these deployments
                          unless the server is the singleton. Which means the console can't modify them either.

                          In the alternate approach the profile service/console always knows about these
                          deployments, its just that they may not be currently deployed if the server is not the
                          singleton.

                          • 10. Re: Profile Service api
                            starksm64

                             

                            "adrian@jboss.org" wrote:

                            But then shouldn't the admin console edits modify the existing files?
                            How do they do if the dds are inside jars?

                            Ok this is simpler because it is a new file, but if the deploy/ folder is read-only
                            it ain't going to work.

                            Right, its simple because its a new deployment, and its a simple component type that has a single xml fragment describing it. Generally the managed object view is a composite of multiple descriptors and its not practical to track this back to the original descriptor, if it even exists.


                            • 11. Re: Profile Service api
                              brian.stansberry

                               

                              "adrian@jboss.org" wrote:
                              "bstansberry@jboss.com" wrote:

                              Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.


                              Ok but as it stands, the profile service doesn't know about these deployments
                              unless the server is the singleton. Which means the console can't modify them either.


                              Yes, that's the fundamental wrong thing about the current HASingletonDeploymentScanner. With the division of function into 2 parts that I described, the registration as part of subprofile function needs to happen regardless of whether the node is master.

                              • 12. Re: Profile Service api
                                starksm64

                                 

                                "adrian@jboss.org" wrote:

                                This wasn't something I had in the original profile design.
                                In fact for a long time I assumed that JON was going to implement this
                                via some plugin to the profile service .
                                i.e. it would set the pre-determined managed objects of the deployment
                                (based on what has been overridden in the console and in its own repository)
                                before it got deployed.

                                That approach just was not working as the jon team could not keep up with the evolution of the server changes. We are still working through whether we have fully predetermined attachments or a delta, and both have issues.

                                So the repository needs another major refactoring for input into the eap. The DeploymentRepository spi was an attempt at defining the admin plugin api, but it is mixing a few things since its bootstraping from the old filesystem layout, supporting hot deployment, and admin edits.


                                • 13. Re: Profile Service api
                                  starksm64

                                   

                                  "bstansberry@jboss.com" wrote:
                                  "adrian@jboss.org" wrote:

                                  Ok but as it stands, the profile service doesn't know about these deployments
                                  unless the server is the singleton. Which means the console can't modify them either.


                                  Yes, that's the fundamental wrong thing about the current HASingletonDeploymentScanner. With the division of function into 2 parts that I described, the registration as part of subprofile function needs to happen regardless of whether the node is master.

                                  Which was also the problem with the refactoring of the bootstrap; these deployments were not visible to the profile service until I updated the ProfileServiceBootstrap to expose them.

                                  That all components are know to the profile service and can be exposed to jon needs to be a goal.