Point taken!
I should have been thinking more when I first did.
Cleaning it up now should not be that hard and I
will make it one of my near-future priorities.
(I knew you will spot this issue, Bill).
Kedar
Bill Shannon wrote:
> Wouter van Reeven wrote:
>> Hi Kedar,
>>
>>
>> So, I managed to modify the existing code so now I can create a
>> start/stop script
>> on Debian Linux for a domain using the command sequence in your
>> weblog. I'll be off to JavaPolis in Belgium for the next few days but
>> in the weekend I'll create an RFE for this and post a patch for the
>> code I created so far. By the way, it
>> still works on Solaris 10 as well :-)
>>
>> At the moment I have two issues. The first issue is due to apparent
>> lack of
>> javadoc. The thing is, that script that I create needs to be made
>> executable and
>> I have troubles finding out if there already is code in the glassfish
>> repository
>> that does this. I know how to make a file executable but I'd like to
>> prevent
>> coding something that already exists.
>>
>> The second issue is one of coding conventions. So far I have been
>> building upon
>> the existing SMFService.java and SMFServiceHandler.java files.
>> Strictly speaking
>> these filenames refer to a Solaris type of Service. Under Linux,
>> these services
>> generally are referred to as daemon which SMF Services are too but
>> SMF Service
>> is a specific type of daemon etc etc.
>> So, the issue is whether these specific cases should be split up. Now
>> I have put
>> lots of "if (OS.isSolaris10())" and "if (OS.isDebianLinux())"
>> statements through
>> the code but I think this is ugly. Moreover, if we centralize the
>> check for the
>> OS and we create separate files for all kinds of Services, we don't
>> have to check
>> for the OS every time we need to do something.
>> Can you please tell me whether there is a convention for this in the
>> glassfish
>> contributors community?
>
> I don't know if there's a convention, but personally I hate code that's
> full of platform-dependent "if" statements.
>
> A better way would be to have a base class that includes the
> platform-independent support, if that's possible, or throws exceptions
> or returns failure if that's not possible. The framework would then
> use the OS name to construct a class name and load a corresponding
> class, which would be a subclass of the base class. A "UNIX" subclass
> might be further subclassed by Solaris, Linux, MacOS, etc. (There
> probably ought to be a utility that does this platform-dependent-class
> loading.)
>
> Let's at least attempt to figure out what the abstractions are that
> are needed by the calling code and then write subclasses that implement
> that abstraction, rather than writing classic C "if/then/else" code.
>
> Ok, maybe that's more than anyone wants to do to solve this particular
> problem, but hopefully someone's thinking along these lines for the
> future...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>