I think, too, that these sorts of administrative issues need to be more
related to how administration takes place in a production arena (which I
freely admit I have little to no experience in) rather than a developers'
private playplace. Remember, folks, we're typically not the ones having to
administer the webserver once the servlet's been deployed; as convenient as
it may be to us to have it one way or the other, let's have a small bit of
pity on the poor folks that have to support the mess we create. :-)
Any experienced web/servlet-admins out there willing to comment? Easier with
a new extension or reuse the old one?
Ted Neward
Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
http://www.javageeks.com/~tneward
"I don't even speak for myself; my wife won't let me." --Me
-----Original Message-----
From: Frank Carver <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, July 06, 1999 8:26 AM
Subject: Re: Comments on 2.2 Public Review Draft
>On Tuesday, July 06, 1999 2:01 PM, [EMAIL PROTECTED]
>[SMTP:[EMAIL PROTECTED]] wrote:
>> I strongly disagree. To argue the flip side of your point.......If we go
>with
>> the .jar extension, then it makes it difficult to associate webapps with
>> specialized tools (and there *will* be several of them) for
>manipulating/viewing
>> them. Once a decent tool comes about to manipulate webapps, how will the
>OS be
>> able to determine that the webapp tool is needed to manipulate the file?
>Now
>> that I have JDK 1.2 on my machine, my assocations for JAR files have have
>stolen
>> by the JDK to support the new executable jar mechanisms. I prefer to
have
>the a
>> special extension so that I can kick off the specized tool. To go a step
>> further, I would prefer to have ejb jar files get their own extension as
>well so
>> that I can kick off specialized tools for them as well. You can always
>> associate multiple types with the same tool (Winzip=*.jar,*.zip,*.war for
>> example), but it's much more difficult to associate the same extension
>with
>> multiple tools.
>
>I suppose I look at this differently. All these are "just" different
>operations on jar files. As an analogy, consider Java source files.
>The default operation might be to open the file in an editor but I
>also typically have other, operations bound to it as well: Compile,
>Print etc. In Windows these appear on a right-click menu, on other
>systems there may be a similar approach.
>
>For jar files the same could apply. A default operation such as
>pass it to the Java interpreter, and several other applications
>also bound to it: a Web Application Tool, a generic Jar tool, an
>EJB tool and so on.
>
>perhaps I use these systems in a different way, but when I develop
>Java, the jar file is usually an output (like a .class file), generated
>by my build process when I recompile the source code, rather than
>a manually edited input file (such as a .java file), When it comes
>to deployment, the jar file is identified by its context; jar files in
>the class path are extensions to the Java class library, jar files
>in a web server config file are web applications and so on.
>
>Frank.
>
>--
>Frank Carver
>[ Personal: [EMAIL PROTECTED] http://www.efsol.com/ ]
>[ At Work: [EMAIL PROTECTED] tel +44 (0)1473 227371 ]
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
