[adrian.brock]

Yes. I have already made a few changes. We need to agree on how we test this as currently the server is not booting. Are there local unit tests for this?

I don't know what you mean?

The tests I have use a mock SARDeployer,
org.jboss.test.system.controller.SimpleSARDeployer
the rest of the code is just a simplified version of the old ServerLoader,
see: org.jboss.test.system.controller.ControllerTestDelegate

 public void setUp() throws Exception
 {
 super.setUp();

 //System.setProperty(ServerConstants.MBEAN_SERVER_BUILDER_CLASS_PROPERTY, ServerConstants.DEFAULT_MBEAN_SERVER_BUILDER_CLASS);
 server = MBeanServerFactory.createMBeanServer("jboss");
 serviceController = createServiceController();
 server.registerMBean(serviceController, ServiceControllerMBean.OBJECT_NAME);

 deployer = new SimpleSARDeployer(server, serviceController);

[starksm64]

I don't know what you mean?

The tests I have use a mock SARDeployer,
org.jboss.test.system.controller.SimpleSARDeployer
the rest of the code is just a simplified version of the old ServerLoader,
see: org.jboss.test.system.controller.ControllerTestDelegate

Ok, just was not sure if you were trying to test by running the full server.

[starksm64]

The system/system-jmx split is underway and the branch is broken. Once I have the eclipse workspace building I'll let you know.

[starksm64]

The eclipse workspace is now building. You need to checkout the https://svn.jboss.org/repos/jbossas/branches/MC_VDF_WORK/system-jmx project and update your entire workspace to pickup all of the updated .classpath files that reference this.

The ant scripts are broken and need to be updated after defining the system-jmx artifacts.

Note that there is one potential problem in that there are two DeploymentException (org.jboss.deployers.spi, org.jboss.deployment) and there should really only be one (org.jboss.deployers.spi). I guess the correct thing to do is make org.jboss.deployment.DeploymentException a trivial subclass of org.jboss.deployers.spi.DeploymentException, but all uses should be updated as part of the deployer update and the org.jboss.deployment should just go away.

[adrian.brock]

I've fixed the ant scripts so that you can build and run the tests.

It looks like there is some stuff that should be moved
src/resources, src/etc, src/bin as well
but these are probably going to become redundant anyway?

[adrian.brock]

I've made org.jboss.deployment.DeploymentException
extends org.jboss.deployment.spi.DeploymentException.

I've also deprecated it.

However, I'm still using it in the ServiceController, etc.
since this signature leaks out through that interface.

[starksm64]

hmm, I had the ant build working last night and I thought I had this checked in, but apparently I did not check it in. I had stripped down the system-jmx/build.xml to a minimal jboss-system-jmx.jar artifact. The run.jar should still be coming from the system module as there is where org.jboss.Main is. Currently the system-jmx module is producing the same jboss-sytem.jar and run.jar artifacts as the system module so that won't work. I would like to update the system-jmx module build.xml to just a jboss-system-jmx.jar artifact to match the jboss.sytemjmx.classpath defintion.

[adrian.brock]

Ok, I was just concentrating on getting it to build
so I could do some work. :-)

[starksm64]

Ok, see if the latest system-jmx/build.xml is working for you. Both the eclipse and ant builds are working for me.

[adrian.brock]

Works for me as well.

[adrian.brock]

I've nearly finished this, so I can soon start working on the
new deployers. :-)

* Things that need doing immediately:

1) Make the synchronization inside AbstractController only for state,
like the old ServiceController.

Currently when you do install() or change() it synchronizes to
avoid concurrent access. This means that shutdown will hang
if one of these operations hangs. e.g. an MBean is broken
The shutdown thread can't enter the synchronized method.

2) There are a couple of things I found that need fixing
in the old ServiceController during testing. These need
to be backported to JBoss4. Most are just NPEs where
errors/invalid configuration are not handled correctly.

One however causes a broken state machine when the parsing
of an invalid object name in a dependency leaves the MBean
registered but not under the control of the ServiceController.

The fix is trivial, it needs to catch Throwable instead of Exception
to do the tidyup.

Also, the use of ObjectNameFactory.create() is spurious in this code
(that method factory is a helper for known valid ObjectNames),
since this will throw java.lang.Error instead of the real
MalformedObjectNameException

* Things that need doing for the new deployers:

1) Rewrite the IncompleteDeploymentException to include pojo
contexts.

* Things that need doing longer term:

1) Test the trim/replace attributes in the ServiceController
I think this will probably open a can of worms. :-)

2) Test XMBean

3) Add extra metadata options to -service.xml
like constructor dependencies/injection

<server>
 <constructor>
 <arg type="SomeClass"><inject bean="Blah"/>
...

4) Make MBeanProxy injection be a CONFIGURED dependency
as well as a CREATE/START injection.

This is trivial and just needs testing.

e.g.

<server>
 <mbean>
 <depends optional-attribute-name="Attribute"
 proxy-type="SomeInterface">test:type=Depends</depends>

Currently if test:type=Depends is not installed it will fail
when trying to use the proxy.
The MBean should not reach the CONFIGURED stage
until test:type=Depends is installed.

[adrian.brock]

I forget to mention that the POJO/JMX sides can now do dependencies
on each other (which was the whole point of writing this thing in
the first place :-)

JMX injected into POJO

<bean>
 <property name="Blah"><inject bean="test:type=MBean"/></property>

POJO injected into JMX

<mbean>
 <attribute name="Blah"><inject bean="POJO"/></attribute>