On Jun 10, 2010, at 11:46 PM, Jerome Dochez wrote:
> 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.
This is what I'm going to do then. In essence, my question was "where
should I put my code?" I have the code working, just not in a happy
place. I'll put it in a separate module. We're still settling on the
details of how other components will access GMS (e.g., register
callback handlers), and if we want another contract that other modules
implement so they're callback handlers are picked up magically, then
this new module can provide that without a hard dependency on the GMS
API.
Note that Joe is working on splitting the shoal-gms.jar (from the
shoal workspace, not GF workspace) into an api and impl version, so
code that needs to compile with the gms api won't force the
implementation to be loaded.
>
> 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 :)
It was my fear that I'd be littering the modules dir, but it sounds
like this is how things are done. It certainly seems reasonable to
have two gms-related modules, one that relies on the gms module and
one that only relies on GF (and loads the former).
We already have v3/cluster/gms-adapter -- this is the code that relies
on the shoal-gms module and we want to load on-demand.
How about v3/cluster/gms-adapter-internal for the new one? Anyone care
about the name? v3/cluster/gms-adapter-dont-forget-to-write-your-
upgrade-code?
On Jun 10, 2010, at 9:43 PM, Marina Vatkina wrote:
>
> This is a wrong approach. You need to come up with the structure of
> your modules first. [...]
I agree. :) I just didn't have all this info when the initial cluster/
gms-adapter module was created.
Cheers,
Bobby