[jboss-as7-dev] Subsystem testing harness

[Kabir Khan]

You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
On 20 Jul 2011, at 12:23, David Bosschaert wrote:

> Hi Kabir,
> 
> Was wondering, is there a way to test the subsystem write operation without actually starting the whole thing up?
> I see that the JMXSubsystemTestCase.testParseAndMarshalModel() does a read-write test, but it also starts up the system which is a bit more heavyweight than I really want.
> 
> I guess what I'm looking for would allow me to do something like this:
>  String subsystemXml = ...
>  List<ModelNode> operations = parse(subsystemXml);
>  String writtenXml = write(operations);
>  assertEquivalent(subsystemXML, writtenXml)
>  // btw the XML doesn't have to be exactly the same, but logically equivalent, assertEquivalent() should take this into account
> 
> Cheers,
> 
> David
> 
> On 19/07/2011 10:10, Kabir Khan wrote:
>> Let me know how you get along. The test harness uses a flat classpath, with no modules. I think this is fine for most subsystems but I'm not sure how that will play out in OSGi land.
>> On 19 Jul 2011, at 09:31, David Bosschaert wrote:
>> 
>>> Awesome! I'm going to have a play with that today. Was looking for
>>> something like this for a while.
>>> 
>>> Cheers,
>>> 
>>> David
>>> 
>>> On 18/07/2011 18:05, Kabir Khan wrote:
>>>> There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
>>>> 
>>>> If your subsystem is not totally self contained, the harness provided makes it easy to
>>>> * Install services your subsystem depends on manually
>>>> * Add socket bindings, paths and system properties used by your subsystem
>>>> * Add parsers and other subsystem extensions required by your subsystem
>>>> 
>>>> It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
>>>> 
>>>> To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
>>>> * checks that the model exists:
>>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
>>>> * actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
>>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186
>>>> 
>>>> The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
>>>> 
>>>> This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>