ProfileService SPI impacts of domain.xml
starksm64 Apr 8, 2010 2:27 PMI 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.