11 Replies Latest reply on Apr 20, 2010 9:55 AM by starksm64

    ProfileService SPI impacts of domain.xml

    starksm64

      I want to fork off a thread to discuss the impacts of the domain.xml work on the profileservice SPI and implementation. A starting point is the IOC issue Emanuel raised. Here is a bootstrap based on a question I asked him about what his concern was:

       

      Emanuel wrote:

       

      On 04/08/2010 05:16 PM, Scott Stark wrote:
      > I want to understand that problem in detail as it does matter. In terms
      > of the domain model, even the scope of property values we support I
      > imagine will be limited unless we are going to support the full
      > BeanMetaData in the domain model.
      >
      > So, your talking about when a property has an injection value, we don't
      > know the real value because there is no runtime? It's only when the
      > final configuraiton stage of the MC is running that the true value is
      > known?
      >

       

      Yes, we need installed beans to get a hold of the target. Given aliases and all dynamic injection features MC has - also there is no guarantee that the injected value is actually a ManagedObject.

       

      On top of this you have the @XmlAnyElement callback for BeanMetaDataFactories in the KernelDeployment, which does not really simplify this

      > In terms of configuration, the configuration value is a reference to
      > something else. The actual value is not knowable until runtime, and I
      > don't see that this can be avoided as a service-configuration vs
      > runtime-service. What are you thinking?
      >

       

      Yes, the configuration should be a reference. Where the configuration is the MO, the service the consumer - where you basically change:

       

      <bean name="service>
        <property name="timout">5</property:
        <property name="injectedBean"><inject name="injectedService"/>
      </bean>

       

      into:

       

      <bean name="service">
        <property name="timeout"><inject name="configuration" property="timeout" /></property>
        <property name="injectedBean"><inject name="injectedService"/>
      </bean>

       


      So just a brief pseudo-code how persisted changes are applied:

       

      @ManagementObject(component=...)
      public class Service
      {
        @ManagedProperty
        int timeout();

       

        @ManagedProperty
        InjectedService getInjectedService()
      }

       

      <bean name="service">
        <property name="timeout">5</property>
        <property name="injectedService"><inject name="injected-service"/></..>
      </bean>

       

      by default you get:

       

      SimpleValue timeout = mc.getProperty("timeout");
      CompositeValue composite = mc.getProperty("injected-service");

       

      The persistence does:

       

      <component name="service">
      <property name="timeout>5</property>
      <property name="injectedService">
        <composite type="org.jboss.test.InjectedService">
          <item name="" ...>
        </composite>
      </property>
      </component>

       

      When we restore the information we do:

       

      BeanMetaDataBuilder.setProperty("injectedService", metaValueFactory.unwrap(compositeValue));

       

      This is what basically happens for service-binding-manager:
      http://svn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/all/bindingservice.beans/META-INF/bindings-jboss-beans.xml

       

      So in case "injectedService" is complex - e.g. no default constructor, this is going to fail.

       


      Ok, this looks a bit messy in the email - i can also write a testcase and explain more in case something is unclear.

       

      I don't see that it is practical to have the original deployment state an indirection on some configuration object, so what you mean is that when we override the property value, we are doing so with an injection to a property in the domain configuration metadata object.

       

      One of the changes we have to make to the profileservice ManagedObject implementation is to have a seperation from the runtime and configuration. The configuration is the unresolved BeanMetaData with only simple values and injection references. We cannot query the runtime state of the runtime component. Access to runtime values and operations is a seperate aspect from the configuration.

        • 1. Re: ProfileService SPI impacts of domain.xml
          emuckenhuber

          Scott Stark wrote:

           

          I don't see that it is practical to have the original deployment state an indirection on some configuration object, so what you mean is that when we override the property value, we are doing so with an injection to a property in the domain configuration metadata object.

           

          Yes, i think using the domain configuration for this would make sense. In the end that's what matters.

          Scott Stark wrote:

           

          One of the changes we have to make to the profileservice ManagedObject implementation is to have a seperation from the runtime and configuration. The configuration is the unresolved BeanMetaData with only simple values and injection references. We cannot query the runtime state of the runtime component. Access to runtime values and operations is a seperate aspect from the configuration.

          A clearer separation between configuration and runtime is something missing. In the end "configuration" is what should be exposed based on the domain model and then we can look at merging runtime MOs into a composite MO - so configuration always maps back to the domain model. For runtime objects we just provide value dispatching, no persistence.

           

          So i think that full out of the box configuration support for BeanMetaData - like we have it now. Where we overwrite the MO view with the actual pojo MO view and then update BMD, is something out of the scope. It also requires classloading so that we can actually build the pojo view.

           

          However we should be able to add better support for e.g. BeanMetaDataFactories - since we basically provide a domain specific metadata to another domain specific metadata. So the domain thread pool metadata to the actual thread pool metadata bean factory.

          • 2. Re: ProfileService SPI impacts of domain.xml
            starksm64

            Based on the thread-pool prototyping, BeanMetaDataFactories are going to have their own domain level DSL describing their configuration. What we need to provide in terms of spi/plugin support in jboss-managed is an easy way to map from the configuration metadata to the BeanMetaData the factory produces.

             

            The jboss-threads project is certainly one we should try to work with to make this connection as easy as possible.

            • 3. Re: ProfileService SPI impacts of domain.xml
              dmlloyd

              Scott Stark wrote:

               

              Based on the thread-pool prototyping, BeanMetaDataFactories are going to have their own domain level DSL describing their configuration. What we need to provide in terms of spi/plugin support in jboss-managed is an easy way to map from the configuration metadata to the BeanMetaData the factory produces.

               

              The jboss-threads project is certainly one we should try to work with to make this connection as easy as possible.

               

              The means by which the threads DSL is mapped from XML to a BMDF is purely an implementation detail.  We probably don't have a lot of alternatives, but the whole process of going from XML to object model via XB, and then to BeanMetaData via BMDF is pretty clunky.  I'd like to at least keep the door open to alternatives, so hopefully we won't be locked too tightly into this model...

              • 4. Re: ProfileService SPI impacts of domain.xml
                dmlloyd

                Also from the sound of it, it sounded to me like what goes into the domain.xml file should be a layer separate from any deployment DSLs we have (jboss-threads.xml, jboss-logging.xml, jboss-xnio.xml, jboss-remoting.xml are mine so far).  If we constrain what goes into the deployment DSLs (which are natural extensions of how the service is installed, not managed) by what goes into the management-oriented domain.xml, we're going to have a hard time carrying that off in a way that doesn't suck.  Instead it would be better to have a parallel management-oriented schema (or schemas) which act purely as an override set for what's been installed - though it's going to be really ugly trying to just slap that on top of what we have today.  I'd rather do the work of reimplementing all these deployers with a nice, well-thought-out API than be faced with the prospect of hacking anything more on top of them (I think this paradigm is already at its complexity limit before it becomes untenable).

                • 5. Re: ProfileService SPI impacts of domain.xml
                  starksm64

                  The deployment DSL should have a more admin oriented DSL. Ideally the project provides this and there is a mapping via a ManagedComponent from the admin DSL onto the deployment DSL metadata. I'm not sure how much simpler the integration of the admin configuration vs deployment features can be. Is there something you have in mind?

                  • 6. Re: ProfileService SPI impacts of domain.xml
                    jason.greene

                    One thing to consider is that maybe it doesn't make sense for things like thread pools and connections to be individually deployable, especially if the whole goal is to configure them in one place.

                    • 7. Re: ProfileService SPI impacts of domain.xml
                      jason.greene

                      So as an example, an alternative design could involve a singular thread pool management service, which simply reads the domain metadata and creates pools. It would also have some management capability to drain pools, resize them etc.

                      • 8. Re: ProfileService SPI impacts of domain.xml
                        starksm64

                        The current domain view does have these configured in one place, so even if there is a thread manager service, I'm not sure the domain model needs to change. I'll I can potentially see changing are additional settings to control how the manager reaps threads and other new features.

                         

                        I agree that we do want simple, centralized configuration with views like Brian mentioned; sockets/ports in use, interfaces in use, max threads allowed, etc.

                        • 9. Re: ProfileService SPI impacts of domain.xml
                          emuckenhuber

                          Scott Stark wrote:

                           

                          Based on the thread-pool prototyping, BeanMetaDataFactories are going to have their own domain level DSL describing their configuration. What we need to provide in terms of spi/plugin support in jboss-managed is an easy way to map from the configuration metadata to the BeanMetaData the factory produces.

                          Yes, since BeanMetaDataFactories are the contract to generate BeanMetaData - we can focus on that. Once we applied overrides to the BMDF then getBeans() should always return the upated BeanMetaData.

                          • 10. Re: ProfileService SPI impacts of domain.xml
                            dmlloyd

                            Scott Stark wrote:

                             

                            The deployment DSL should have a more admin oriented DSL. Ideally the project provides this and there is a mapping via a ManagedComponent from the admin DSL onto the deployment DSL metadata. I'm not sure how much simpler the integration of the admin configuration vs deployment features can be. Is there something you have in mind?

                             

                            Sorry for the late reply.

                             

                            I think that when you talk about mapping the admin DSL to deployment metadata, you're reaching into implementation details.  It's very conceivable than in a reasonable alternate implementation, deployments like the threads deployment wouldn't even have any metadata.  It would be much more efficient to directly read XML and spit out BeanMetaData objects, for example.  The only reason we have metadata at all for threads, logging, I/O, etc. is because we're constrained to use JBossXB for this - it would be a serious mistake to think of this as a requirement.  The whole concept of having deployment metadata of any sort might sound like a design philosophy or paradigm, but it's really just a coincidence of implementation.

                             

                            The real paradigm which is actually in use today basically amounts to a DSL which is not some kind of serialized representation of the running state of the system; it is an imperitive command language which describes a series of services which are to be started.  However everything that has been described under the heading of domain.xml is descriptive of additional configuration which is applied atop a running system.  The two models are basically orthogonal, and we should not be trying to solve both with one uniform solution - you're going to end up with either a stunted deployment DSL or an overly complex administration DSL.

                             

                            I think it's important to think about this from the perspective that the deployment and admin DSLs are two different user interfaces for two different purposes and stop thinking about implementation details until the expected semantics are clear, which, judging from this and other threads, is still a bit of a question mark.

                            • 11. Re: ProfileService SPI impacts of domain.xml
                              starksm64

                              There is some implementation specific deployment language (metadata, XML) that if its to be integrated into the domain as a feature we have identified as part of our admin domain api, we need a domain dsl that has to be handled by the implementation as configuration input. If the implementation does not have an intermediate metadata state that could be annotated (XML would be a dom element), then the implementation has to deal with applying the domain configuration. For implementations that follow the VDF notion of producing metadata during the parsing phase, I believe we should be providing a simple way to map the domain model onto the metadata. We will have to allow a more general hook to apply the domain configuration to some other metadata file, fragment, etc.