(Aimed mainly at the GUI team)
This discussion applies to anything in an @Configured ConfigBeanProxy
object that declares an @Element List<String>, which I'll term
"anonymous non-singleton elements" (they are not named and there can
be any number of them present).
AMX SUPPORT IN V3 for anonymous non-singleton elements
(see BACKGROUND info below)
In the V2 AMX API, there was no generic access to such elements; the
only access was via get/set, with set being a "complete replace" eg:
String[] getJVMOptions()
void setJVMOptions( String[] replaceWithThis )
V3 now supports a more flexible API for such elements:
public interface AnonymousElementList //
com.sun.appserv.management.config
{
public static final String OP_ADD = "add";
public static final String OP_REMOVE = "remove";
public static final String OP_REPLACE = "replace";
public String[] getAnonymousElementList( final String
elementName );
public void modifyAnonymousElementList( final String elementName,
final String op, final String[] args);
}
An AMXConfig interface like
com.sun.apperv.management.config.JavaConfig extends this interface and
support is automatic for any number of such elements. It is
recommended to have a getter (and optional setter) so that the values
are accessible as JMX Attributes.
Usage is now much more flexible:
String[] values = ...;
// complete replace with specified options; these 3 are all equivalent
javaConfig.setJVMOptions( values );
javaConfig.modifyAnonymousElementList( "JVMOptions", OP_REPLACE,
values ); // or "jvm-options"
// add new options without duplication, retaining existing ones
javaConfig.modifyAnonymousElementList( "jvm-options", OP_ADD, values);
// remove only the specified options
javaConfig.modifyAnonymousElementList( "jvm-options", OP_REMOVE,
values);
// remove all options
javaConfig.modifyAnonymousElementList( "jvm-options", OP_REMOVE, new
String[] {} );
BACKGROUND
The existing serverbeans @Configured JavaConfig contains this
declaration:
@Element
public List<String> getJvmOptions();
public void setJvmOptions(List<String> options) throws
PropertyVetoException;
In the AMX com.sun.appserv.management.config.JavaConfig interface,
this looks like:
public String[] getJVMOptions();
public void setJVMOptions( String[] options );
(String[] is used for historical reasons, convenience in generic
tools, as well as issues with serialization of List)
The declarations ultimately result in XML entries like this:
<java-config>
<jvm-options>-client</jvm-options>
<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/lib/
endorsed</jvm-options>
<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/
config/server.policy</jvm-options>
<jvm-options>-Djava.security.auth.login.config=$
{com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
...
</java-config
As another example, an @Configured might declare the following
(omitting the setter methods for brevity):
public interface FooBarConfig extends ConfigBeanProxy, Injectable {
@Element public List<String> getFoos();
@Element public List<String> getBars();
@Element public List<String> getCars();
@Element public List<String> getJvmOptions();
}
which would result in XML like this:
<foo-bar-config>
<foo>oh happy day</foo>
<foo>hello world</foo>
<bar>bite me</bar>
<bar>bah, humbug</bar>
<car>Ford</car >
<car>Chevy</car >
<jvm-options>--client</jvm-options>
<jvm-options>--server</jvm-options>
</foo-bar-config>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc