Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The following page has been changed by BrandonDuRette: http://wiki.apache.org/tomcat/HowTo The comment on the change is: Typos and Wiki formatting only ------------------------------------------------------------------------------ a different matter altogether. - == Why doesn't the netbeans example build for me? == + == Why doesn't the NetBeans example build for me? == I have found two issues with the build.xml provided here: http://jakarta.apache.org/struts/faqs/netbeans.html @@ -233, +233 @@ Threads from the [http://jakarta.apache.org/tomcat/faq/tomcatuser.html tomcat-user list] - Using Verisign: + Using Veri``Sign: * http://marc.theaimsgroup.com/?l=tomcat-user&m=106285452711698&w=2 * http://marc.theaimsgroup.com/?l=tomcat-user&m=107584265122914&w=2 @@ -297, +297 @@ - Download the source bundle or grab the source XML file from CVS. The docs are in the jakarta-tomcat-catalina CVS module, in the webapps/docs subdirectory. They are in XML format and get processed into the HTML documentation as part of the Tomcat release. - - Edit the documentation XML file(s) as you wish. The xdocs format is self-explanatory: use normal HTML markup, and add <section> or <subsection> tags as you see fit. Look at the existing docs as exampels. Make sure you use valid XML markup. + - Edit the documentation XML file(s) as you wish. The xdocs format is self-explanatory: use normal HTML markup, and add <section> or <subsection> tags as you see fit. Look at the existing docs as examples. Make sure you use valid XML markup. - Open a Bugzilla enhancement item with the explanation of your enhancements, and attach a {{{diff -u}}} format of your patch. We will evaluate and commit your patch as needed. Note that the Tomcat web site is updated with every release, so that documentation changes will not be visible as soon as you submit your Bugzilla item. @@ -408, +408 @@ } }}} - A few caveats arise, as for instance while the `System.out` and `System.err` are deirected + A few caveats arise, as for instance while the `System.out` and `System.err` are redirected as per above, no logging of these is done to files. You will need more legwork to do to make the additional logging. It is important to backup and restore the original streams as the above example does. Also, notice the use of `getOutputStream()`: @@ -724, +724 @@ == How do I authenticate Manager access via JNDI to Active Directory for multiple Tomcat instances? == - ADS insists that the CN of every group be unique, but the Manager app. always uses the group CN=manager. The default can be changed, but it's hard to find and you have to do it over every time you upgrade. Instead, pick an attribute other than the common name -- for example, "description" -- that doesn't have to be unique, name it as the RoleName attribute of the Realm (in server.xml, which you'll be editing anyway), and set that attribute to "manager" in each group you create. Create an OU for each Tomcat instance's groups and give that OU's DN as the RoleBase in that instance's server.xml. Create a uniquely-named group in each instance's OU with the chosen attribute ("description" for example) set to "manager". + ADS insists that the CN of every group be unique, but the Manager app. always uses the group CN=manager. The default can be changed, but it's hard to find and you have to do it over every time you upgrade. Instead, pick an attribute other than the common name -- for example, "description" -- that doesn't have to be unique, name it as the `RoleName` attribute of the `Realm` (in server.xml, which you'll be editing anyway), and set that attribute to "manager" in each group you create. Create an OU for each Tomcat instance's groups and give that OU's DN as the `RoleBase` in that instance's server.xml. Create a uniquely-named group in each instance's OU with the chosen attribute ("description" for example) set to "manager". == How do I check whether Tomcat is UP or DOWN? There is no status command == - Unfortunately, the org.apache.catalina.util.ServerInfo class does not determine if Tomcat is UP or DOWN. It is possible to do an HTTP GET on the root url but this is not accurate. In my case I sometimes use a regular Apache HTTPd to display a maintainence message while upgrading, etc. and using that method would give false positives. + Unfortunately, the `org.apache.catalina.util.ServerInfo` class does not determine if Tomcat is UP or DOWN. It is possible to do an HTTP GET on the root url but this is not accurate. In my case I sometimes use a regular Apache HTTPd to display a maintainence message while upgrading, etc. and using that method would give false positives. The correct way to do determine status is to parse the admin port from server.xml and see if we can connect to it. If we can then the Tomcat is UP otherwise it is DOWN. @@ -738, +738 @@ May 1, 2007 5:10:35 PM org.apache.catalina.core.StandardServer await WARNING: StandardServer.await: Invalid command '' received }}} - Ideally this should be incorporated into org.apache.catalina.util.ServerInfo by some committer. In addition to the shutdown command they should add commands like status (UP or DOWN) and uptime in the await method of org.apache.catalina.core.StandardServer + Ideally this should be incorporated into `org.apache.catalina.util.ServerInfo` by some committer. In addition to the shutdown command they should add commands like status (UP or DOWN) and uptime in the await method of `org.apache.catalina.core.StandardServer` {{{ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
