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.
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