Yes, there are some magic annotations to control the management view of ProfileService. We actually expose the TransactionManager as ManagedObject already, by adding:

<annotation>@org.jboss.managed.api.annotation.ManagementObject(name="TransactionManager",componentType=
@org.jboss.managed.api.annotation.ManagementComponent(type = "MCBean", subtype = "JTA"),
targetInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class)</annotation>

Although the generated default view is most probably not usable for persistence, as it would try to persist all properties.

Basically there are 2 ways of controlling this view: 1) by annotating the beans directly or 2) creatng a separate class and let profileservice create the ManagedObject based on this.
This is basically what we do for JMS destinations e.g.:
http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/main/org/jboss/jms/server/destination/QueueServiceMO.java

There is also a wiki article about the available management annotations:
http://www.jboss.org/community/wiki/ManagedObjects

We are currently also working on a xml format describing the management object instead of annotations and additional configuration capabilities for AS6.

 

"jhalliday" wrote:
Thanks for the pointers.
What's the problem with that? Type limitations?

Basically all values of ManagedProperties are exposed as a MetaType and MetaValue pair consisting only of simple types.
As this is a very generic processing it could happen that in some cases we cannot recreate the actual object, if we don't have additional information (e.g. a MetaMapper). That's why it would be good to review what's exposed and provide additional mappings if needed.
This really depends on the complexity of e.g. your TSConfigurationBean.

"jhalliday" wrote:

I definitely don't want a compile time dependency on profile service, so it looks like using annotations in the -beans.xml is the way to go.

Hmm i've never tried to put property annotations for profileservice in the -beans.xml directly, but should work. That's also why we are also working on a xml descriptor for this view.

"jhalliday" wrote:

What's the relationship between MC injection and profile service overriding the values using those from it's saved settings? I need very specific timing - the values must be set before certain events in the startup sequence if the value set is going to have an effect. When is this currently done and is there a way to control it?

The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.

 

"jhalliday" wrote:
> The persisted changes will get applied to the BeanMetaData directly before the bean is handed over to MC and installed - so before the bean is instantiated.

huh? The MC is the only thing that knows how to instantiate some beans - the wiring for the factory method is part of the -beans.xml You are saying the profile service inserts itself after the process that parses the -beans.xml but before the bit that uses the resulting data, then takes upon itself to use the factory to instantiate the bean in place of MC doing that?

We are updating the meta data only, we don't instantiate/touch the bean itself.

Given you have a bean:

public class MyBean {
 int timeout;
 @ManagementProperty
 public int getTimeout() { ... };
 public void setTimeout(int timeout) { ... };

}

With it's -beans.xml:

<bean name="TimoutBean" class="MyBean">
 <property name="timeout">12</property>
</bean>

If there are persisted changes e.g. the timout value was changed to 15 then ProfileService would update the meta data like:
BeanMetaData.setProperty("timeout", 15):

So MC would create the bean still based on the on the -beans.xml descriptor from above, but would inject a value of 15 instead of 12.