You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ji...@apache.org on 2007/02/28 18:06:40 UTC
svn commit: r512845 - in /tomcat/connectors/trunk/jk/native: BUILDING
netscape/README
Author: jim
Date: Wed Feb 28 09:06:37 2007
New Revision: 512845
URL: http://svn.apache.org/viewvc?view=rev&rev=512845
Log:
More nsapi plugin build help
Modified:
tomcat/connectors/trunk/jk/native/BUILDING
tomcat/connectors/trunk/jk/native/netscape/README
Modified: tomcat/connectors/trunk/jk/native/BUILDING
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/BUILDING?view=diff&rev=512845&r1=512844&r2=512845
==============================================================================
--- tomcat/connectors/trunk/jk/native/BUILDING (original)
+++ tomcat/connectors/trunk/jk/native/BUILDING Wed Feb 28 09:06:37 2007
@@ -115,11 +115,15 @@
----------------------------------------------
make clean (to remove all previously compiled modules)
use configure and indicate that you will be building the
- netscape nsapi redirector, then make the redirector plugin
+ netscape nsapi redirector, then make the redirector plugin:
./configure --enable-netscape
cd netscape
make -f Makefile.solaris
+
+ This assumes that SUITSPOT_HOME is defined and points to
+ your SunONE install path (eg: /opt/SUNWwbsvr/plugins)
+ and that JAVA_HOME is defined (eg: /opt/SUNWwbsvr/bin/https/jdk).
Misc notes
----------
Modified: tomcat/connectors/trunk/jk/native/netscape/README
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/netscape/README?view=diff&rev=512845&r1=512844&r2=512845
==============================================================================
--- tomcat/connectors/trunk/jk/native/netscape/README (original)
+++ tomcat/connectors/trunk/jk/native/netscape/README Wed Feb 28 09:06:37 2007
@@ -6,7 +6,8 @@
a custom build on Windows systems
On Unix system, a Makefile.solaris is provided and should be
-adapted to tailor to your own configuration.
+adapted to tailor to your own configuration. Be sure to read
+the BUILDING file, one directory up.
REQUIREMENT for Windows build
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Accepted meaning of 'should' in spec documents
Posted by "C. Halstead" <ch...@sourcelabs.com>.
Awesome. That's exactly what I was looking for. Thanks Tim.
---
C. Halstead <ch...@sourcelabs.com>
SourceLabs - http://www.sourcelabs.com
Dependable Open Source Systems
----- "Tim Funk" <fu...@joedog.org> wrote:
> Typically its:
>
> http://www.faqs.org/rfcs/rfc2119.html
>
> -Tim
>
> C. Halstead wrote:
> > Hi,
> >
> > Just a quick clarification question, and sorry if it's a basic one.
> When interpreting various spec documents is the qualifier 'should'
> always taken to indicate that something is optional?
> >
> > Two cases in point:
> >
> > Bug 41718 was marked as an enhancement request with the explanation
> of "should == optional"
> >
> > Bug 41722 pertains to a web.xml element that is referred to in the
> spec once with (emphasis mine) "A security-role-ref element *should*
> contain a role-link sub-element..." and then later with "...an
> optional link to a security role(role-link)."
> >
> > I'm just trying to understand the standards applied when
> interpreting the spec.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Accepted meaning of 'should' in spec documents
Posted by Tim Funk <fu...@joedog.org>.
Typically its:
http://www.faqs.org/rfcs/rfc2119.html
-Tim
C. Halstead wrote:
> Hi,
>
> Just a quick clarification question, and sorry if it's a basic one. When interpreting various spec documents is the qualifier 'should' always taken to indicate that something is optional?
>
> Two cases in point:
>
> Bug 41718 was marked as an enhancement request with the explanation of "should == optional"
>
> Bug 41722 pertains to a web.xml element that is referred to in the spec once with (emphasis mine) "A security-role-ref element *should* contain a role-link sub-element..." and then later with "...an optional link to a security role(role-link)."
>
> I'm just trying to understand the standards applied when interpreting the spec.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Accepted meaning of 'should' in spec documents
Posted by "C. Halstead" <ch...@sourcelabs.com>.
Hi,
Just a quick clarification question, and sorry if it's a basic one. When interpreting various spec documents is the qualifier 'should' always taken to indicate that something is optional?
Two cases in point:
Bug 41718 was marked as an enhancement request with the explanation of "should == optional"
Bug 41722 pertains to a web.xml element that is referred to in the spec once with (emphasis mine) "A security-role-ref element *should* contain a role-link sub-element..." and then later with "...an optional link to a security role(role-link)."
I'm just trying to understand the standards applied when interpreting the spec.
Thanks,
-chris
---
C. Halstead <ch...@sourcelabs.com>
SourceLabs - http://www.sourcelabs.com
Dependable Open Source Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org