Applying persisted changes.

[emuckenhuber]

One of the failures i mentioned was about restoring JMS destinations. The updates does not work
when the ManagedObjectClass(..) is not present in the deployment descriptor.
So the tests with this annotation element are passing, the one without is failing.

One other problem i think we could have is that ManagedObjectFactory.initMO does not create the same output, as ManagementView (as this would require e.g. KernelDeploymentManagedObjectCreator)

Additionally the failures which can be seen during the bootstrap (https://jira.jboss.org/jira/browse/JBAS-6524)
seem also somehow related to this - as when processing the collection in the ManagedObjectFactory,
does not have access to the ComponentDeploymentContext.getMetaData() for each bean.
Not really sure about this, as it's been a while since i last looked into this.

So the main issue with that is when restoring the persisted information it is (of course) relying on the same ManagedObject structure as it was persisted before. Only the values are getting persisted and restored (which makes sense, as the metaType should not change)

Therefore i think that this kind of 'override' done by the InstanceClassFactories (getManagedObjectClass),
should be done outside the deployers - e.g. in ManagementView when creating the ManagedComponents.
So that it always creates the same MO for the attachment persistence.
Maybe a related topic Scott created: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222668

This does not not cover partial persistence and removing components, but i think we can discuss that later.

[ccrouch]

From today's call can I assume this thread is going to tackle the issues raised in the following jiras?

http://jira.jboss.com/jira/browse/JBAS-6689 add support for activation policy metadata on ManagedProperties
http://jira.jboss.com/jira/browse/JBAS-6742 Updates to managed properties no longer persisting when changes made through embedded console
http://jira.jboss.com/jira/browse/JBAS-6227 Only way to remove a managedcomponent is to remove its deployment
http://jira.jboss.com/jira/browse/JBAS-6716 add back securityConfig config property to JMS destination resources

Please indicate if there are going to be issues you think will not be covered.

Thanks

[starksm64]

"emuckenhuber" wrote:
One of the failures i mentioned was about restoring JMS destinations. The updates does not work
when the <annotation>ManagedObjectClass(..)</annotation> is not present in the deployment descriptor.
So the tests with this annotation element are passing, the one without is failing.

I don't understand why the ManagedObjectBuilder for the destination class is not seen. I'll try to look into why that is.

"emuckenhuber" wrote:

One other problem i think we could have is that ManagedObjectFactory.initMO does not create the same output, as ManagementView (as this would require e.g. KernelDeploymentManagedObjectCreator)

Additionally the failures which can be seen during the bootstrap (https://jira.jboss.org/jira/browse/JBAS-6524)
seem also somehow related to this - as when processing the collection in the ManagedObjectFactory,
does not have access to the ComponentDeploymentContext.getMetaData() for each bean.
Not really sure about this, as it's been a while since i last looked into this.

So the main issue with that is when restoring the persisted information it is (of course) relying on the same ManagedObject structure as it was persisted before. Only the values are getting persisted and restored (which makes sense, as the metaType should not change)

Therefore i think that this kind of 'override' done by the InstanceClassFactories (getManagedObjectClass),
should be done outside the deployers - e.g. in ManagementView when creating the ManagedComponents.
So that it always creates the same MO for the attachment persistence.
Maybe a related topic Scott created: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222668

This does not not cover partial persistence and removing components, but i think we can discuss that later.

Ok, I see. We need to move the managed object factory extension behavior out of the deployers. I'll start looking at that.

[emuckenhuber]

I don't understand why the ManagedObjectBuilder for the destination class is not seen. I'll try to look into why that is.

Looks like the MODefinitions are getting installed too late (as they are in deploy/messaging).
Moving those definitions to deployers/ seems to work, although in the end this should not be needed?

Ok, I see. We need to move the managed object factory extension behavior out of the deployers. I'll start looking at that.

I think that will simplify things for the attachment persistence.
Last week i was briefly looking into something similar. It's basically not that obvious, as IMHO parts of what ServiceMetaDataICF and BeanMetaDataICF are doing should be moved out.
On the other hand looking at the connection factory ICFs - those actually only do operations on the ConnectionFactoryMetaData itself, which should be fine.

So i think that one of the goals should be to have a clearer separation between the metaData operations and the extension behavior.
Although refactoring ICFs totally out of this process could be quite hard. Maybe creating something new but similar for the extension behavior could be easier?

Leaving the meta data operations in the responsablitly of the ICFs (setValue, getValue). On top of that the extension behavior like overriding the moClass, getting the values from the MBeanServer or the MCBean... Also adding and creating a new attribute to the meta data e.g. ServiceAttributeMD could be done by the extensions.
Is similar to what you have in mind?

[starksm64]

"emuckenhuber" wrote:

I think that will simplify things for the attachment persistence.
Last week i was briefly looking into something similar. It's basically not that obvious, as IMHO parts of what ServiceMetaDataICF and BeanMetaDataICF are doing should be moved out.
On the other hand looking at the connection factory ICFs - those actually only do operations on the ConnectionFactoryMetaData itself, which should be fine.

So i think that one of the goals should be to have a clearer separation between the metaData operations and the extension behavior.
Although refactoring ICFs totally out of this process could be quite hard. Maybe creating something new but similar for the extension behavior could be easier?

Leaving the meta data operations in the responsablitly of the ICFs (setValue, getValue). On top of that the extension behavior like overriding the moClass, getting the values from the MBeanServer or the MCBean... Also adding and creating a new attribute to the meta data e.g. ServiceAttributeMD could be done by the extensions.
Is similar to what you have in mind?

The ICF behavior needs to be separated out into the type/metadata driven aspect of creating the MO skeleton and subsequent population. The value read access of the ICF is an extension of the current ManagedObjectPopulator default implementation.

There is a disconnect between the ManagedDeployment/ManagedComponent and the DeploymentUnit/component DeploymentUnit that is what the KernelDeploymentManagedObjectCreator is essentially working around. In general we need to be doing something like:
1. Create the ManagedObject metadata from attachments and extensions based on metadata
2. Create the ManagedDeployment/ManagedComponent/ManagedObject skeletons. This view should work even without a sever with default values coming from the ManagedProperty metadata
3. Provide a full runtime view with stats, operations via a population step.

Getting to this abstraction for 5.1 is not possible. What we can do in the next week is what I'm trying to figure out today.

[starksm64]

"emuckenhuber" wrote:

Looks like the MODefinitions are getting installed too late (as they are in deploy/messaging).
Moving those definitions to deployers/ seems to work, although in the end this should not be needed?

I don't see this if I run the JmsDestinationRestartUnitTestCase after the JmsDestinationOverrideTestCase when the server is running. The JmsDestinationRestartUnitTestCase.testQueueTemplate fails if I run the JmsDestinationOverrideTestCase and then restart the server, so we are loading something too early it seems.

In general both the mbean and MODefinitions would only be visible to the class loader of the deployment, so needing these classes visible when the deployers first load is not correct. We don't processes any persisted attachments unless we see a deployment with a matching attachments, so it could just be that this is an implicit dependency issue where the destinations-service.xml is getting processed before the messaging-jboss-beans.xml during startup.

[emuckenhuber]

I don't see this if I run the JmsDestinationRestartUnitTestCase after the JmsDestinationOverrideTestCase when the server is running. The JmsDestinationRestartUnitTestCase.testQueueTemplate fails if I run the JmsDestinationOverrideTestCase and then restart the server, so we are loading something too early it seems.

Yes the RestartUnitTestCases need a server restart. That's basically where this problem occurs.

In general both the mbean and MODefinitions would only be visible to the class loader of the deployment, so needing these classes visible when the deployers first load is not correct. We don't processes any persisted attachments unless we see a deployment with a matching attachments, so it could just be that this is an implicit dependency issue where the destinations-service.xml is getting processed before the messaging-jboss-beans.xml during startup.

Hmm well we are applying the information in PRE_REAL. As the messaging-beans are also in deploy/ they are most probably in the same state - so not installed.

[starksm64]

"emuckenhuber" wrote:

Hmm well we are applying the information in PRE_REAL. As the messaging-beans are also in deploy/ they are most probably in the same state - so not installed.

This will be a general problem with extensions that are added via injection, install callbacks, etc. The fully populated managed objects can only be done on a fully initialized kernel. If extensions are beans themselves, the managed object creation cannot even be done correctly as part of the deployment processing. This does require that extensions be installed as part of the deployers bootstrap phase.