Need a NamedObject SimpleMetaType

[starksm64]

In working with ManagedObjects that contain properties that are references to other ManagedObjects, I need to be able to represent this type of property, so I want to introduce a SimpleMetaType NAMEDOBJECT. This is equivalent to the jmx SimpleType. The only problem with this is that unlike jmx, there is no entry point for resolving the NAMEDOBJECT. The value of a NAMEDOBJECT property is simply the referenced object name. The issue is, what is the reference resolver. The only logical place is the add support for this to the ManagedObject interface:

interface Name
{
 String getName();
}

public interface ManagedObject extends Serializable
{
...
 /**
 * Resolve a named object reference.
 *
 * @param name - the reference name to resolve
 * @return the ManagedObject the name resolves to if found,
 * null otherwise.
 */
 ManagedObject resolveName(Name name);
}

This looks like containment, but in general it will not be and the ManagedObject impl needs some registry impl. Maybe there should just be a property ManagedObjectRegistry api for this and that is where the resolution has to be done as well.

[starksm64]

I have added a org.jboss.metatype.api.types.Name and org.jboss.metatype.plugins.types.StringName default implementation. This has been added to the MetaType.ALLOWED_CLASSNAMES.

[adrian.brock]

I don't understand this. This looks like the wrong place for this?

Is this intended to be a reference?

Why it isn't it enough to just have an annotation in the managed layer?

@ManagedObjectReference
public void setOtherComponent(String name) {} // ==> matches getName() on another ManagedObject

On the registry, surely the profile service already knows all the ManagedObjects
and is acting the registrying?

I don't think we need to change the Managed project to also have a bus do we?
That would would lead to reproducing most of JMX.
The purpose of the ManagedObject interface is to avoid having to know
there is a bus somewhere (there could be different ones/types).

[starksm64]

The name of the ManagedObject is generally not useful for referencing as its a DeploymentUnit attachment name. This is not usable for a datasource referencing a security domain whose deployment type and attachment type won't be known.

You don't think the Name type belongs here, the ManagedObjectRegistry, or both?

I don't expect that there will be a bus in the managed project, just the spi to allow references to be resolved.

Its also not sufficient to just have the name in the registry. I also need to be able to validate that the source the name is bound to supports the expected property type. I guess this requires the use of the GenericMetaType on the property and source to check that the expected type exists. However, if the source supports an extension of an interface the property wants, this cannot be determined from the classname comparision GenericMetaType supports. The source would have to declare a GenericMetaType for each interface.

[starksm64]

Thinking about the type issue more, I originally was writing tests that had the security-domain property be a Name type as that is how the code is still written. Typically one would have the property be the dependent interface type that one would use, but the security domain bean is not used directly by jca. There is an indirection because jaas is used with a configuration name, and that is what really needs to be matched up between the jca security-domain property and some security domain bean implementation. In this case the Name type is correct in that its describing a dependency on another component, but is too weak in terms of validating what that component provides. What one wants to validate is that the security domain bean provides a jaas login configuration for the indicated name. Don't know how to validate that at this point.

[starksm64]

Since Name does not convey the additional requirements, maybe the property type should just be String and the fact that its a reference along with constraints provided via the ManagementObjectRef annotation.

[adrian.brock]

The name of the ManagedObject is generally not useful for referencing as its a DeploymentUnit attachment name. This is not usable for a datasource referencing a security domain whose deployment type and attachment type won't be known.

If the name is not usable then we should change it.
I remember putting a comment somewhere that I thought the current
use of the name was wrong.

IIRC, it is only currently used to know the key to which
the attachment should be put back in the attachments.

You don't think the Name type belongs here, the ManagedObjectRegistry, or both?

Both.

I don't expect that there will be a bus in the managed project, just the spi to allow references to be resolved.

Its also not sufficient to just have the name in the registry. I also need to be able to validate that the source the name is bound to supports the expected property type. I guess this requires the use of the GenericMetaType on the property and source to check that the expected type exists. However, if the source supports an extension of an interface the property wants, this cannot be determined from the classname comparision GenericMetaType supports. The source would have to declare a GenericMetaType for each interface.

Based on your "SecurityDomain" example then I don't see this as anything
more than a name with qualifier.

i.e. SecurityDomain/Default.

The trivial requirement could be served from the following
pseudo markup.

public class ConnectionManagerMetaData
{
 @ManagedObjectRef(type="SecurityDomain');
 public void setSecurityDomain(String securityDomain);
}

@MangedObject
public class SecurityDeployment
{
 @ManagedProperty
 Collection<SecurityPolicy> getPolicies();
}

public SecurityPolicyMetaData
{
 @ManagedObjectID(type="SecurityDomain")
 public String getName();
}

I'd actually turn the "policies" managed property into a map by id.
i.e. the property that gets constructed is not a collection it is effectively.

Map<String, ManagedObject<SecurityPolicy>>

There is a similar trick going on the 'unified metadata" for

object (id)
-------------
ejbs (ejb-name)
ejb-refs (ejb-ref-name)
etc.

[starksm64]

Based on your "SecurityDomain" example then I don't see this as anything
more than a name with qualifier.

i.e. SecurityDomain/Default.

The trivial requirement could be served from the following
pseudo markup.

public class ConnectionManagerMetaData
{
 @ManagedObjectRef(type="SecurityDomain');
 public void setSecurityDomain(String securityDomain);
}

@MangedObject
public class SecurityDeployment
{
 @ManagedProperty
 Collection<SecurityPolicy> getPolicies();
}

public SecurityPolicyMetaData
{
 @ManagedObjectID(type="SecurityDomain")
 public String getName();
}

I'd actually turn the "policies" managed property into a map by id.
i.e. the property that gets constructed is not a collection it is effectively.

Map<String, ManagedObject<SecurityPolicy>>

There is a similar trick going on the 'unified metadata" for

object (id)
-------------
ejbs (ejb-name)
ejb-refs (ejb-ref-name)
etc.

Ok, something needs to identify that the SecurityDeployment is of type "SecurityDomain", and identify what the key under the "SecurityDomain" type is. Presumably something like?

@ManagementObject(type="SecurityDomain").
public class SecurityDeployment
{
 @ManagedProperty
 @ManagedObjectKey
 Collection<SecurityPolicy> getPolicies();
}

[adrian.brock]

The deployment isn't a "SecurityDomain" it is the submanaged objects,
the policies in the deployment that are security domains.

I don't see why you need anymore markup than I've shown?

[starksm64]

I'm not following the example then as it does not match the existing jca metadata/managed object view. What exists logically is:

@ManagementObject
class DSDeployments
{
 @ManagementObject
 List<ConnMetaData> deployments();
}

@ManagementObject
class ConnMetaData
{
 @ManagementProperty(name="jndi-name")
 String getJndiName();

 @ManagementProperty(name="security-domain", managed=true)
 SecMetaData getSecMetaData();
}

@ManagementObject
class SecMetaData
{
 @ManagementProperty
 @ManagedObjectRef(type="SecurityDomain');
 String getDomain();
}

Somewhere else there needs to be a type="SecurityDomain' managed object with a name that matches the SecMetaData.domain value. If the @ManagedObjectID(type="SecurityDomain") annotation is identifying the key space of the managed objects of type="SecurityDomain' then I follow. Otherwise I don't.

[adrian.brock]

Somewhere else there needs to be a type="SecurityDomain' managed object with a name that matches the SecMetaData.domain value. If the @ManagedObjectID(type="SecurityDomain") annotation is identifying the key space of the managed objects of type="SecurityDomain' then I follow. Otherwise I don't.

It is, but I put it on the policy not the deployment. The login-config.xml
can have multiple policies. It is the policy that represents the security domain.

All I'm saying is that where-ever it is, you just need to identify what the id
of the ManagedObject is and its type/qualifier.

From above (but more explicit):

@MangementObject
public class SecurityDeployment
{
 // login-config.xml has many policies
 @ManagedProperty(managed=true)
 Collection<SecurityPolicy> getPolicies();
}

@ManagedObject
public SecurityPolicyMetaData
{
 // This is its id which has qualifier/type/discriminator "SecurityDomain"
 @ManagedObjectID(type="SecurityDomain")
 public String getName();
}

So the profile service can look at the SecurityPolicyMetaData managed objects
and see they are keyed by "SecurityDomain"/name
and match that with what is on the connection manager metadata.

[adrian.brock]

The point I was trying to make before was that it probably be easier
for the mangement layer to deal with a map, so an alternative markup
might be to define on the collection:

@MangementObject
public class SecurityDeployment
{
 // login-config.xml has many policies
 @ManagedProperty(managed=true map-id="name" id-qualifier="SecurityDomain")
 Collection<SecurityPolicy> getPolicies();
}

Then the profile service when it does getProperty("policies")
would get a TableMetaValue of String(id/name)->ManagedObject
instead of having to iterate over an array of managed objects.

It's still a Collection underneath, we've just exposed it as a map
(since we know it has a unique id) for ease of use.

[starksm64]

The point I was trying to make before was that it probably be easier
for the mangement layer to deal with a map, so an alternative markup
might be to define on the collection:

@MangementObject
public class SecurityDeployment
{
 // login-config.xml has many policies
 @ManagedProperty(managed=true map-id="name" id-qualifier="SecurityDomain")
 Collection<SecurityPolicy> getPolicies();
}

Then the profile service when it does getProperty("policies")
would get a TableMetaValue of String(id/name)->ManagedObject
instead of having to iterate over an array of managed objects.

Ok, the reference to the login-config.xml is interesting now in that its not exposed as metadata available to the deployment layer. Its really handled outside of the associated security mbean as internal state of a custom jaas login configuration object in the jdk. It does in fact need to be associated with the jaas security domain mbean as sub-managed objects, and the id-qualifier needs to differentiate the SecurityDomain type further as there will be alternate SecurityDomain types (jaas, jaspi, ...). A little off topic, but that is why I was not following what the SecurityPolicy annotation was achieving.

I'll try to have a revision of the management annotations by Monday to review.