Are these documented somewhere?
On 6/10/10 2:07 PM, Snjezana Sevo-Zenzerovic wrote:
> Marina Vatkina wrote:
>> Bobby Bissett wrote:
>>> On Jun 10, 2010, at 4:03 PM, Marina Vatkina wrote:
>>>> May be you can move the code that needs gms interface out of
>>>> kernel? It's best to keep both, api and spi that your module
>>>> exposes close to your module (see e.g. transaction submodules,
>>>> though I wasn't able to move everything there).
>>>
>>> There's nothing in that class that relies on anything in the gms
>>> jars. The interface I'm talking about is simply:
>>>
>>> @Contract
>>> public interface GMSService {}
>>>
>>> So it's not the group management service, but the group management
>>> service service. IOW, it's the part of GF that starts GMS. The class
>>> I have in kernal is GmsLoaderService, and it's responsible for
>>> checking the config to see if there is >0 clusters with gms-enabled
>>> set, and, if so, load the actual GMS. So these classes are more
>>> related to GF than GMS. That sound right?
>>
>> No. It's GMS. You expose the SPI (GMSService) that other modules who
>> want to be a GMSService implement. You put the SPI into
>> gms/gms-internal-api/... and others will depend on it.
> And please note that in that case gms-internal-api needs to go into
> glassfish-common-tmp packager module...
>>
>> Each module should be as self-contained as possible.
>>
>> -marina
>>>
>>> Attached is the loader service that I thought should go in core/kernal.
>>>
>>> Cheers,
>>> Bobby
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>