commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Conrad" <andrewcon...@attbi.com>
Subject RE: [lang] System properties
Date Sat, 24 Aug 2002 05:20:49 GMT
Thanks, I was just thrown off by the extra verbage.  I think defining an
interface a good idea, allowing the utility to be extended as needed.

What does everyone else think?


An OSClassifier interface, A GenericOSClassifier class, load
GenericOSClassifier by default in SystemUitls, and adding appropriate
set and get methods to change the OSClassifier ?


Also, what about defining a property hierarchy base upon the code base,
then the operating system family, kind of like:

OS_BASE_UNIX
OS_BASE_MAC
OS_BASE_WINDOWS


OS_FAMILY_LINUX
OS_FAMILY_AIX
OS_FAMILY_WINDOWS_NT
OS_FAMILY_WINDOWS_9X

Each family is also a part of the base....


- Andrew

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Friday, August 23, 2002 2:04 PM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] System properties
> 
> 
> 
> 
> On Fri, 23 Aug 2002, Andrew Conrad wrote:
> 
> > Date: Fri, 23 Aug 2002 13:14:50 -0400
> > From: Andrew Conrad <andrewconrad@attbi.com>
> > Reply-To: Jakarta Commons Developers List 
> > <commons-dev@jakarta.apache.org>
> > To: 'Jakarta Commons Developers List'
> <commons-dev@jakarta.apache.org>
> > Subject: RE: [lang] System properties
> >
> > What do you mean by pluggable interface and a processor class 
> > identifier?  Can you point me to a class that does this, so
> I can try
> > and get up to speed?
> >
> 
> I don't know of any specific code that does this for OS clases, but 
> consider something along the following lines:
> 
>   public interface OSClassifier {
>     public String getOSClass();
>   }
> 
> that would have the responsibility to grab the appropriate operating 
> system property and "classify" it -- in the current discusson we've 
> talked about classes like "SunOS" versus "Linux" versus "Windows" 
> being returned.
> 
> Now, it would be possible to hard code a mapping algorithm into a 
> static
> getOSClass() method inside SystemUtils, but that's not very
> extendable. It would be better to allow apps to plug in their 
> own classifier algorithm
> -- just as a simple example, some apps will care about the 
> distinction between SunOS and Solaris, and others won't.
> 
> The standard SystemUtils class would support something like:
> 
>   public class SystemUtils {
>     ...
>     public static OSClassifier getOSClassifier();
>     public static void setOSClassifier(OSClassifier classifier);
>     ...
>   }
> 
> and provide a default implementation of OSClassifier that is generally

> useful -- but applications needing more specialized analysis of the 
> system property string can do so.
> >
> > - Andrew
> >
> 
> Craig
> 
> 
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > Sent: Friday, August 23, 2002 12:59 PM
> > > To: Jakarta Commons Developers List
> > > Subject: RE: [lang] System properties
> > >
> > >
> > >
> > >
> > > On Fri, 23 Aug 2002, Steve Downey wrote:
> > >
> > > > Date: Fri, 23 Aug 2002 12:42:14 -0400
> > > > From: Steve Downey <steve.downey@netfolio.com>
> > > > Reply-To: Jakarta Commons Developers List 
> > > > <commons-dev@jakarta.apache.org>
> > > > To: Jakarta Commons Developers List
> > > > <commons-dev@jakarta.apache.org>
> > > > Subject: RE: [lang] System properties
> > > >
> > > > I think trying to make these distinctions will end up in a
> > > morass of
> > > > fine differences without utility. SunOS is how Solaris
> identifies
> > > > itself, although the version numbers aren't the same.
> > > Solaris 7, for
> > > > example, is SunOS 5.7.
> > > >
> > > > Even with what's there now, what does IS_LINUX say that IS_UNIX 
> > > > doesn't? That is, what action could you take on the basis
> > > of IS_LINUX
> > > > being true, that you couldn't with just IS_UNIX being true.
> > > >
> > >
> > > To make something like this more generally useful and
> scalable, it
> > > might be better to abstract the notion of OS identification by 
> > > providing a pluggable interface that returns a "processor class 
> > > identifier" or something.  The default implementation could be 
> > > what's originally proposed, but people wouldn't be stuck with it.
> > >
> > > The same sort of thing happens in the web app world when
> it comes to
> > > the "User-Agent" header.  There are lots of libraries around that 
> > > attempt to classify these strings into general categories, but no 
> > > such scheme is going to be universally applicable.
> > >
> > > Craig
> > >
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: scolebourne@btopenworld.com 
> > > > > [mailto:scolebourne@btopenworld.com]
> > > > > Sent: Friday, August 23, 2002 5:18 AM
> > > > > To: commons-dev@jakarta.apache.org
> > > > > Subject: RE: [lang] System properties
> > > > >
> > > > >
> > > > > >  from:    Andrew Conrad <andrewconrad@attbi.com>
> > > > > > So your saying that potentially there could be a Solaris 
> > > > > > family encompassing all Solaris versions, Windows NT family
> > > encompassing
> > > > > > NT, 2000, XP?
> > > > >
> > > > > I think that demand will come. Is Mac OSX a Mac or a UNIX?
> > > > >
> > > > >
> > > > > > Without thinking too hard about it, the only thing I
> > > can think of
> > > > > > is to use a byte as the enumeration type then AND them 
> > > > > > together and compare. That will allow a boolean method
> > > isOSFamilyLinux and
> > > > > > isOSFamilyUnix to both return true  (and other possible
> > > options:
> > > > > > I think I heard OSX ).
> > > > >
> > > > > One thing I hate is manipulating bytes with AND and OR
> > > operations.
> > > > > It requires me to think too much.
> > > > >
> > > > > > What's the reasoning behind wanting to differentiate
> > > between Linux
> > > > > > and Unix, but not SunOS and AIX?
> > > > >
> > > > > I would have added a Solaris option, but didn't know if
> > > Solaris ==
> > > > > SunOS or not.
> > > > >
> > > > > Stephen
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail: 
> > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > additional commands,
> > > e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message