Refactoring ServerPeer

[starksm64]

In looking at where jbossas dependencies start, the org.jboss.jms.server.ServerPeer bean needs major refactoring because of jbossas specific assumptions. Some of the issues are:

- Its deployed as an mbean based on messaging-service.xml from the jbossas/messaging integration code. However, the xmdesc/ServerPeer-xmbean.xml this references is part of the jboss-messaging.jar. This is a jbossas specific descriptor that should be part of the integration project.

- It has a direct dependency on org.jboss.mx.loading.UnifiedClassLoader3. This is being used to obtain the ClassLoader ObjectName for use with the org.jboss.system.ServiceCreator. Both are jbossas specific that cannot be in jboss-messaging.jar code.

- It has destination deployment methods that expose an api which uses a stringified dom Element representation rather than a pojo object model. Not portable and not managable by the profile service.

- It uses injection of dependencies on typed objects using lookup of jmx Instance attribute based on ObjectNames. This dependency is not expressed explicitly though. So we are both imposing unnecessary implementation details on the providers of the interface as well as not properly expressing the dependency.

- Aspects are being loaded directly using the org.jboss.aop.AspectXmlLoader to load the aop-messaging-server.xml bundled in jboss-messaging.jar. These aspects configuration should be part of the integration project.

[timfox]

In looking at where jbossas dependencies start, the org.jboss.jms.server.ServerPeer bean needs major refactoring

Yes indeed. The factoring has pretty much already been done in TRUNK to move us away from the old 1.x design (which is what you're looking at). The new model is a big selling point for us - is completeley POJOised, runnable in MC, bootstrappable etc.

[starksm64]

When is that secheduled for a release?

At a minimum for the jbossas5 beta3 I think we need:
- externalize the name of the aop-messaging-server.xml so these aspects can be overriden in the server integration project.
- externalize the SecurityStore implementation so this can be overriden by the server integration project:

 <mbean code="org.jboss.jms.server.ServerPeer"
 name="jboss.messaging:service=ServerPeer"
 xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
...
 <attribute name="AopConfig">jbossas5-aop-messaging-server.xml</attribute>
 <depends optional-attribute-name="SecurityStore">jboss.messaging:service=JBossAS5SecurityStore</depends>
...

I'll take a look at making these changes.

[timfox]

When is that secheduled for a release?

It won't be ready in the timescales you need.

At a minimum for the jbossas5 beta3 I think we need:
- externalize the name of the aop-messaging-server.xml so these aspects can be overriden in the server integration project.
- externalize the SecurityStore implementation so this can be overriden by the server integration project:

Ok, that seems fair. Shouldn't be too difficult either :)

I'll take a look at making these changes.

Ok, thanks Scott. As you know we are pretty thin on the ground, so any help much appreciated.

Can you do this on Branch_Stable? (JBM TRUNK is JBM 2.0)

[starksm64]

I crated this patch http://jira.jboss.com/jira/browse/JBMESSAGING-1189 because I could not commit to the stable branch. This patch applies to https://svn.jboss.org/repos/messaging/tags/JBossMessaging_1_4_0_SP1/. I can merge it to the stable branch if you update the dev permissions for [e-mail]

[timfox]

I've added you as a committer.

Could you actually hold off committing for a little while? - we may have to do a customer patch from this branch. Will know in a few hours...

[starksm64]

What is the status of the branch?

[timfox]

Sorry about the delay.

You should be fine to commit your changes now :)

[timfox]

Sorry for the confusion - can you hold off committing actually?

It's still unsure whether I need to make some customer changes.

If you like, I can just apply the patch myself when it's clear...

[starksm64]

The issue patch has been updated to apply to the Branch_Stable code. There was an NPE in the all config that had been seen earlier when trying SP2 release. Its due to the hsqldb-persistence-service.xml/MessagingPostOfficeService/GroupMember being started before a view membership is received, and the latch being null. The patch has a check for this condition and a warning printed about being started before the view is seen.

[timfox]

The issue patch has been updated to apply to the Branch_Stable code. There was an NPE in the all config that had been seen earlier when trying SP2 release. Its due to the hsqldb-persistence-service.xml/MessagingPostOfficeService/GroupMember being started before a view membership is received, and the latch being null. The patch has a check for this condition and a warning printed about being started before the view is seen.

Scott - can you tell me how to replicate this NPE? I'd like to investigate it further.

[clebert.suconic]

Updating the JAR also require updating config files.

[starksm64]

"timfox" wrote:

Scott - can you tell me how to replicate this NPE? I'd like to investigate it further.

I was seeing it by using the patched jar in the jbossas5 all server configuration. As Clebert said there are also some messaging-service.xml and hsqldb-persistence-service.xml changes needed as well to get to the NPE.

Since were so close to the beta3 release of jbossas I'm going to change this into an integration task that needs to be done for jbossas CR1. I'll create a bug report for the NPE issue once the descriptors are in line with the stable branch snapshot after beta3.

[starksm64]

JBMESSAGING-1189 has been changed to an integration task that JBAS-5077 depends on.

[starksm64]

I have made the JBMESSAGING-1189 changes in Branch_Stable. What would a release of this be tagged as?