Thanks Kumar and Jerome for the details.
Anissa—
First, you could start by finding the AMX MBeans for config, realizing
that as Kumar points out, config elements do not exist for all of
them. I see these MBeans in V3:
amx:j2eeType=X-AuthRealmConfig,name=admin-realm,X-ConfigConfig=server-
config,X-SecurityServiceConfig=na
amx:j2eeType=X-AuthRealmConfig,name=certificate,X-ConfigConfig=server-
config,X-SecurityServiceConfig=na
amx:j2eeType=X-AuthRealmConfig,name=file,X-ConfigConfig=server-
config,X-SecurityServiceConfig=na
For fullf functionality there are two issues:
- writing the method(s) to obtain the correct info in V3
- where to put the methods
AMX has no obvious place to put this method; it's a config-related
thing, but not config itself--awkward. For now, AMX has the
KitchenSink interface, which is a place to put such oddball items. It
currently has only getConnectionDefinitionPropertiesAndDefaults(). So
you could add methods to the interface (and the implementation to
KitchenSinkImpl).
Lloyd
On Jul 25, 2008, at 12:40 AM, V B Kumar Jayanti wrote:
> Hi Jerome,
>
> Jerome Dochez wrote:
>
>> +1
>>
>> in fact, +10.
>>
>> You can find the names of each service without instantiating them
>> if you need that. You can also get their classes without
>> instantiating them and finally you can use injection of lookup to
>> get instances, but you already know that. Look at the Habitat API,
>> it's all there.
>>
> The Realm is declared as a contract. And i can ensure all Realm
> Impl classes are marked as Service's. And then i can use Habitat
> API to discover them.
>
> However there are two issues
>
> 1. the mapping is really 1->Many. A single Realm Impl class can
> be used for Multiple Realm-Type definitions (by varying the
> properties supplied to the realm). We have 2 such cases in the set
> of PreDefinedRealms, wherein the JDBC Realm and JDBCDigest Realm
> essentially use the same Realm Impl class, but use a different
> JAAS Context which is supplied as a property when configured in
> domain.xml. The same kind of polymorphism exists for admin-realm
> and file-realm, both use the same FileRealm impl class but they use
> a different keyfile (supplied as a property)
>
>> <auth-realm
>> classname="com.sun.enterprise.security.auth.realm.file.FileRealm"
>> name="admin-realm">
>> <property name="file" value="${com.sun.aas.instanceRoot}/
>> config/admin-keyfile"/>
>> <property name="jaas-context" value="fileRealm"/>
>> </auth-realm>
>> <auth-realm
>> classname="com.sun.enterprise.security.auth.realm.file.FileRealm"
>> name="file">
>> <property name="file" value="${com.sun.aas.instanceRoot}/
>> config/keyfile"/>
>> <property name="jaas-context" value="fileRealm"/>
>> </auth-realm>
>
>
>
> 2. If i want to discover the predefined realms by their listings
> in domain.xml, then the issue is that we do not by default want to
> register all the predefined realms in domain.xml because it is an
> unnecessary overhead on the startup. So by default in GlassFish only
> the admin-realm and file-realm and the certificate realm are
> registered the other 3 predefined realms are not registered by
> default.
>
> Let me know if you have some suggestion.
>
> regards,
> kumar
>
>> jerome
>>
>> On Jul 24, 2008, at 11:09 PM, Sahoo wrote:
>>
>>> Instead of hardcoding the names, why don't we discover them using
>>> Habitat API? Are these not implemented as Service?
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Anissa Lam wrote:
>>>
>>>> Hi,
>>>> I am working on the GUI for creating security realm. In V2, i
>>>> called the following method getPredefinedAuthRealmClassNames()
>>>> on SecurityServiceMBean to get the list of predefined security
>>>> auth realm.
>>>> Question 1: Is this list the same as in V3 Prelude ? If not,
>>>> can someone give me that list ?
>>>> Question 2: Should GUI just hard code the list or has 'ss
>>>> implement backend support' already ?
>>>>
>>>> thanks
>>>> Anissa
>>>>
>>>> public class SecurityServiceMBean extends BaseConfigMBean
>>>> {
>>>> /**
>>>> * Returns names of predefined AuthRealms' classes supported by
>>>> security service.
>>>> * @returns array of predefind AuthRealms' classes
>>>> *
>>>> */
>>>> public String[] getPredefinedAuthRealmClassNames()
>>>> {
>>>> //!!!!!!!!!!!! (hardcoded for now until ss will implement
>>>> backemnd support)
>>>> return new String[]{
>>>>
>>>> "com.sun.enterprise.security.auth.realm.file.FileRealm",
>>>>
>>>> "com
>>>> .sun.enterprise.security.auth.realm.certificate.CertificateRealm",
>>>>
>>>> "com.sun.enterprise.security.auth.realm.ldap.LDAPRealm",
>>>>
>>>> "com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm",
>>>>
>>>> "com.sun.enterprise.security.auth.realm.solaris.SolarisRealm"};
>>>> }
>>>> }
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>