Anissa,
Yes, not the same, but very similar API. I've chosen a method
convenient for use in a programmatic client or a command line CLI or
JConsole.
There is support for add/remove/replace via
com.sun.appserv.management.config.CollectionOp, and this will work
with *any* anonymous non-singleton elements like JVMOptions (jvm-
options) and any future ones of that kind.
(anonymous non-singleton elements look like this: <option-name>blah
blah blah</option-name>)
You can (optionally) make the first element of the array be the command.
NOTE: ConfigBean layer is broken right now for removing items, but
it's coded at the AMX level. I think Jerome will fix this soon.
EXAMPLES
(these apply to any anonymous non-singleton elements that are
List<String> at the ConfigBeanProxy layer, not just JVMOptions (jvm-
options))
import static com.sun.appserv.managment.CollectionOp.*;
...
// To REMOVE the two options "-Dfoo-bar" and "-client":
setJVMOptions( new String[] { COLLECTION_OP_REMOVE, "-Dfoo=bar",
"-client"} );
// To ADD option "-Dfoo-bar" (without affecting any others):
setJVMOptions( new String[] { COLLECTION_OP_ADD, "-
Dfoo=bar" } ); // explicit add via command
setJVMOptions( new String[] { C"-Dfoo=bar" } ); // implicit "add
if not already present", nothing removed
// To REPLACE all existing options with these new ones:
setJVMOptions( new String[] { COLLECTION_OP_REPLACE, "-Dfoo=bar",
"-client"} );
To replicate the existing V2 behavior exactly you must insert
'COLLECTION_OP_REPLACE' as the first element of the array:
final String[] allTheOptionsIWant = new String[]
{ COLLECTION_OP_REPLACE, ... };
config.setJVMOptions( allTheOptionsIWant );
Lloyd
On Apr 21, 2008, at 5:22 PM, Anissa Lam wrote:
> Lloyd L Chambers wrote:
>>
>> Anissa,
>>
>> Regarding bugs #4492 and #4819—
>>
>> The problem is not easy; it requires special handling, and it's
>> very awkward to deal with in light of being both generic and
>> transactional. It's going to take several days to work out the
>> right way to handle it, even for the specific case of JVMOptions.
>>
>> Anissa are you open to converting to this API instead?
> This is fine with me. I assume that the same API will be used to
> get the JVM Options of the profiler.
>
> thanks
> Anissa.
>>
>> Ex:
>> javaConfig.createSingleValueElement( "jvm-options", "-Dfoo.bar" );
>> javaConfig.createSingleValueElement( "jvm-options", "-Dbar.foo" );
>>
>> final String[] allJVMOptions =
>> javaConfig.getSingleValueElements( "jvm-options" );
>>
>>
>> public interface SingleValueElementSupport {
>> /** Create a single-value element (eg <jvm-options>) of the
>> specified element type with the specified value. */
>> void createSingleValueElement( final String elementType, final
>> String value );
>>
>> /** Remove a single-value element (eg <jvm-options>) of the
>> specified element type with the specified value.*/
>> String removeSingleValueElement( final String elementType,
>> final String value);
>>
>> /** Get the values of all single-valued elements of the specified
>> element type.*/
>> String[] getSingleValueElements( final String elementType );
>>
>> /** Return the element types for all single-valued elements */
>> String[] getSingleValueElementTypes();
>> }
>>
>> Lloyd
>>
>> On Apr 21, 2008, at 11:37 AM, Lloyd L Chambers wrote:
>>> I am working on them today.
>>>
>>> I am hoping for TP2, but the two bugs involve design issues, not
>>> just simple bug fixes.
>>>
>>> Lloyd
>>>
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc