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/jbo....
As you can see here it
>>> * checks that the model exists:
>>>
https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jbo...
>>> * 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/jbo...
>>>
>>> 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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev