On 6/10/10 6:43 PM, Marina Vatkina wrote:
> Bobby Bissett wrote:
>> On Jun 10, 2010, at 5:01 PM, Marina Vatkina wrote:
>>> 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.
>>
>> I'm not even at the point yet of how other modules will access it. I
>> need code *somewhere* that checks domain.xml. Then I need a contract
>> interface *somewhere* that I can use to start up the GMSService that
>> other modules will then use.
>
> This is a wrong approach. You need to come up with the structure of
> your modules first. So if you have at least one interface that you
> expose, you create a module, e.g. 'gms' with 2 submodules
> 'gms-internal-api' and 'gms-impl' (or whatever names seem right). It
> is much easier to do it that way instead of adding dependencies and/or
> moving things around later on. Unfortunately temporary solutions stay
> that way forever :(
yes, this is basically what I was suggesting earlier...
He needs to have a small piece of code that checks the domain.xml and
trigger some module instantiation when certain configuration settings
are enabled. The piece that does the checkin should not trigger the gms
modules resolution.
One way to achieve that is to have a gms-bootstrap module that contains
only the startup service that does the check and the @contract
definition. The gms-bootstrap module should not depend on anything
except probably glassfish-api.
The @contract implementation (the @Service) will ship in the gms-impl
module.
>
> The whole idea of modularization is to have modules :).
yes but not too many :)
>> The domain-checking code and the contract interface can't go in my
>> gms-dependent module because that defeats the whole purpose of not
>> loading the module unless it's needed.
>
> That's why the contract goes into its own module.
>
> Best,
> -marina
>
>> So where should these two classes go?
>>
>> Thanks,
>> 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
>