When I try to compile this, the first problem is the argument I use in the "new StreamRecorderParameters()" function (connectsName).
The compiler complains with an "error: cannot find symbol" with a carat under the "e" in "connectsName".
Another cannot find symbol error puts the carat under the "S" in the second "StreamRecorderParamaters" of that same command.
Finally, there are 3 cannot find symbol errors concerning the "IStreamRecorderConstants" lines.
My first problem (and perhaps solution to the others) is: what argument do I supply for the "new StreamRecorderParameters()" function; since I am not actually
in any appInstance yet, I cannot use "this.appInstance"; I need to supply a name.
If the LiveStreamRecordManager module is ultimately not accessible from the JMX utility, I guess I will have to use telnet to send http commands, which is not nearly as elegant as using the JMXCommandLine, but would work.
The way JMX works, you can only send and receive simple values or Objects that are marked as Serializable. ApplicationInstance is not Serializable so you cannot send and receive it using JMX.
For what you are wanting to do, I would suggest creating a simple module that wraps the methods you want to use and make those wrappers available to the JMX interface. Any public methods that only receive or return simple values or do not need or return a value are automatically added to the mbeans for the module instance and will be available via JMX. AppInstances do need to be running for the module instance mbeans to be visible. You can call one of the VHost. touchApplicationInstance methods via JMX to load the appInstance prior to calling your methods
You will then be able to add methods to your JMX class that will work with your wrapper methods.
The reason you are probably getting the compile errors is because you don't have the Wowza classes available in your class path when compiling. Because you are building something to communicate remotely with wowza then you shouldn't be compiling against the Wowza classes anyway as these will most likely not be available at runtime anyway.