new kernel profileservice test

[ccrouch]

Building off Scott's tests of the profileservice I've added another test (DataSourceTestCase) and supporting classes under org.jboss.test.profileservice.* in the kernel module. Basically the tests just try to create some slightly more releastic object graphs trying to represent LocalTx and NoTx datasources. I'd appreciate any comments on the test themselves, e.g. is the usage of classes/annotations as expected? Coding them up generated the following questions:

1) Given a ManagedObject there needs to be someway to tell what "type" it is, i.e. differentiate between a ManagedObject for a LocalTx datasource and a NoTx one.

2) The one-to-one mapping from Deployment's to ManagedObject's seems like a bit of a restriction? It would be nice to be able to have a ManagedObject for the ConnectionManager and ConnectionFactory parts of the dataSource and another one of the ConnectionPool part. But it doesn't look like we could do this currently without splitting the Deployment into two separate instances as well. One reason for the split is to eventually scope runtime actions, e.g. a flush action makes more sense on just the ConnectionPool ManagedObject, rather than on a monolithic DataSource ManagedObject.

2a) Assuming you've got two ManagedObjects which are related to each other, e.g. DataSource -> ConnectionPool, it would be good to be able add some form of relation between the two ManagedObjects. This would also be useful if we're trying to model our management view on the hierarchical JSR77 model.

3) Given a property on a ManagedObject you should be able to tell if that property is read-only or not. You can sort of specify this on the bean itself with @ManagedProperty (use = ViewUse.???) but I couldn't see how that mapped to a R/RW attribute on the PropertyInfo class which is available through a ManagedObject.

4) Given a property on a ManagedObject you should be able to tell if that property is required or not.

Thanks

[starksm64]

1) Given a ManagedObject there needs to be someway to tell what "type" it is, i.e. differentiate between a ManagedObject for a LocalTx datasource and a NoTx one.

I think this relates to the question I had about exactly what the ManagedObject should contain. Right now its simply a mapping from the raw deployment bean properties. An alternate form was using org.jboss.profileservice.spi.management.ManagedPropertyRef was shown in the other design forum (this class was not checked in so I just did that). Type could be a specific addition to a ManagedPropertyRef or a usage pattern for the context string (/DataSource/LocalTx/...). Certainly this could be added to the ManagedObject as well. Until we get to some better round trip usecases that touch on the deployment (jsr88) and runtime (jsr77) management I don't have an opinion on what should be showing up where. Just add it if its needed and we can iterate on whether its in the correct place as the tests expand.

[starksm64]

2) The one-to-one mapping from Deployment's to ManagedObject's seems like a bit of a restriction? It would be nice to be able to have a ManagedObject for the ConnectionManager and ConnectionFactory parts of the dataSource and another one of the ConnectionPool part. But it doesn't look like we could do this currently without splitting the Deployment into two separate instances as well. One reason for the split is to eventually scope runtime actions, e.g. a flush action makes more sense on just the ConnectionPool ManagedObject, rather than on a monolithic DataSource ManagedObject.

2a) Assuming you've got two ManagedObjects which are related to each other, e.g. DataSource -> ConnectionPool, it would be good to be able add some form of relation between the two ManagedObjects. This would also be useful if we're trying to model our management view on the hierarchical JSR77 model.

This also gets back to the ManagedPropertyRef.context notion. Originally we discussed having a ManagedObject being an annotation with nested annotations representing reusable views of other managed objects. This was too cumbersome to manage using the annotation reflection capabilities so I backed away from it to a simple property collection. There needs to be a single ManagedObject that represents the deployment in terms of its configurable settings for creation. Runtime operations are another view of the deployment bean managed properties. The bean properties still can express one or more types of management views via the ViewUse{CONFIGURATION, RUNTIME, STATISTIC} enumeration. This got dropped in the move away from the annotation representation, but it could be added to the ManagedPropertyRef.

[starksm64]

3) Given a property on a ManagedObject you should be able to tell if that property is read-only or not. You can sort of specify this on the bean itself with @ManagedProperty (use = ViewUse.???) but I couldn't see how that mapped to a R/RW attribute on the PropertyInfo class which is available through a ManagedObject.


4) Given a property on a ManagedObject you should be able to tell if that property is required or not.

These should be showing up on the bean PropertyInfo. I'm going through another iteration on the deployment bean to kernel metadata as they are too far apart so I'll add these. In terms of being required for creation, I would view this as simply whether or not a property has a default value.

[starksm64]

This also gets back to the ManagedPropertyRef.context notion. Originally we discussed having a ManagedObject being an annotation with nested annotations representing reusable views of other managed objects. This was too cumbersome to manage using the annotation reflection capabilities so I backed away from it to a simple property collection. There needs to be a single ManagedObject that represents the deployment in terms of its configurable settings for creation. Runtime operations are another view of the deployment bean managed properties. The bean properties still can express one or more types of management views via the ViewUse{CONFIGURATION, RUNTIME, STATISTIC} enumeration. This got dropped in the move away from the annotation representation, but it could be added to the ManagedPropertyRef.

And properties are not operations so there is still the issue of identifying jsr77 like runtime ops such as start/stop as well as arbitrary management operations available via jmx today.