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