8 Replies Latest reply on Nov 24, 2008 4:20 PM by Ales Justin

    Configuration deployments

    David Lloyd Master

      How can I make the MC support configuration file deployments?

      A configuration file deployment would differ from a bean deployment in a couple ways. First, there is no undeploy - a configuration is read upon deployment, and that's the end of it. Either the configuration is accepted and applied, or rejected and ignored. Second, a configuration deployer would not yield BeanMetaData; rather the custom MetaData type would be installed directly into the application where it could be accepted or rejected.

      Is this possible to do? Maybe even using SchemaResolverDeployer to produce the custom metadata type, which is then handed to the program (perhaps with an install callback)?

        • 1. Re: Configuration deployments
          Charles Crouch Expert

          Hi David
          I'm afraid I can't help answer your question directly, but I'd be interested to know more about your use case here. This smells like something which the profile service could/should be helping with. Could you expand on what it is you would like to achieve from the end user perspective?

          Thanks

          • 2. Re: Configuration deployments
            David Lloyd Master

            From the end-user perspective, I'd like them to be able to put a foo-config.xml file in the deploy/ directory and have the container map it to a custom MetaData type for me, and then pass the resultant object into my running service.

            This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.

            • 3. Re: Configuration deployments
              Charles Crouch Expert

               

              "david.lloyd@jboss.com" wrote:
              This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.


              Bingo. This looks like a usecase for the profileservice. So if the profileservice doesn't do what you need it to today, I think we should at least investigate what changes would be required.

              - Presumably you want those runtime changes to also persist across app restarts?
              - What sort of "reconfiguration" are you looking to do? Change property values?
              - Would it be acceptable to annotate properties you wanted to be able to change, so the profile service knows they needed managing? Or does that count as a "hard API dependency"?

              Thanks

              • 4. Re: Configuration deployments
                David Lloyd Master

                 

                "charles.crouch@jboss.com" wrote:
                Bingo. This looks like a usecase for the profileservice.


                Excellent! Where can I find more information about profileservice?

                "charles.crouch@jboss.com" wrote:
                So if the profileservice doesn't do what you need it to today, I think we should at least investigate what changes would be required.

                - Presumably you want those runtime changes to also persist across app restarts?


                Yes, that would seem to make sense.

                "charles.crouch@jboss.com" wrote:
                - What sort of "reconfiguration" are you looking to do? Change property values?


                Perhaps a little more in depth than that - the configuration data might be somewhat complex (plain objects but also e.g. lists/sets/maps etc. as well). I'm thinking more of an object model that is mappable to an XML configuration format. I'm inclined to believe that the service itself would be in the best position to ascertain how the configuration should be merged into the running state of the service.

                "charles.crouch@jboss.com" wrote:
                - Would it be acceptable to annotate properties you wanted to be able to change, so the profile service knows they needed managing? Or does that count as a "hard API dependency"?


                Annotations should be fine as long as the annotation classes are not a runtime dependency... Though I have a hard time envisioning an annotation-backed system that would be as flexible as simply plugging a metadata object into a service method when the config changes.

                • 5. Re: Configuration deployments
                  Charles Crouch Expert

                   

                  "david.lloyd@jboss.com" wrote:

                  Excellent! Where can I find more information about profileservice?


                  Here is I think the latest doco, it will give you a rough idea about what the profile service is about, but it definitely needs some updating to match the current impl.
                  http://www.jboss.org/community/docs/DOC-11694

                  "david.lloyd@jboss.com" wrote:
                  Perhaps a little more in depth than that - the configuration data might be somewhat complex (plain objects but also e.g. lists/sets/maps etc. as well).

                  From that doco:

                  The general notion is that a deployment has a collection of ManagedObjects which are collections of detyped, self-defining properties ala the JDK6 Open MBeans notion.


                  "david.lloyd@jboss.com" wrote:
                  Annotations should be fine as long as the annotation classes are not a runtime dependency...

                  The annotations have Runtime retention but that shouldn't prevent you loading your classes in another environment that doesn't have the annotation jar file in the classpath. You're just going to need them when you compile.

                  • 6. Re: Configuration deployments
                    Ales Justin Master

                     

                    "david.lloyd@jboss.com" wrote:

                    Is this possible to do? Maybe even using SchemaResolverDeployer to produce the custom metadata type, which is then handed to the program (perhaps with an install callback)?

                    Sure, this is nothing abnormal.
                    We do this all the time.
                    e.g. EJB metadata --> JBossMetaData
                    It eventually gets used by EJB container, helping create proper services/beans,
                    but never gets undeployed, since there is nothing to undeploy.

                    How you create your metadata is up to you.
                    For parsing I would definitely use SRD, as it's probably the easiest+cleanest way.


                    • 7. Re: Configuration deployments
                      Charles Crouch Expert

                       

                      "alesj" wrote:
                      Sure, this is nothing abnormal.
                      We do this all the time.
                      e.g. EJB metadata --> JBossMetaData
                      It eventually gets used by EJB container, helping create proper services/beans,
                      but never gets undeployed, since there is nothing to undeploy.


                      But we don't use this technique to configure/reconfigure the EJB Container itself do we? I thought that would be analogous to what David is trying to do?

                      "david.lloyd@jboss.com" wrote:
                      This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.

                      This sounds more like a configuration (i.e. metadata overrides, i.e. profile service issue) than a deployment shaped one.

                      David, if you've got the time, have you got an example of the original service deployment descriptor and an example change you would expect to see. This might help clarify if the profile service would help here or not.

                      Thanks

                      • 8. Re: Configuration deployments
                        Ales Justin Master

                         

                        "charles.crouch@jboss.com" wrote:

                        But we don't use this technique to configure/reconfigure the EJB Container itself do we?

                        No, I would expect EJB Container to be a bunch of MC beans,
                        hence configurable via MC based ManagedObject.

                        "charles.crouch@jboss.com" wrote:

                        I thought that would be analogous to what David is trying to do?

                        Perhaps I didn't give the best example + missing some details. :-)
                        It was more about just using metadata and not making it into beans + not undeploying it.

                        But there is nothing preventing you to annotate your custom metadata
                        with ManagedObject annotations and then exposing them.
                        I guess some more MO impl details are needed,
                        e.g. InstanceClassFactory or ManagedObjectBuilder