|
This page acts as an unfiltered list of miscellaneous "gotchas" that we have fallen foul of. Since we didn't manage to find an easy answer on Google for these, we figured we'd blog our work-arounds here for the benefit of others: Using private comments/attachments with Bugzilla version 2.22 We recently upgraded from Bugzilla 2.16 to 2.22 which introduces a significant change in database structure. We were previously using a feature that allowed comments to be marked as private, but found that this facility was no longer enabled after upgrade. Searching on Google, we found references to creating an "insidergroup" user group. This appears to do something but not what we needed, in the end we found that we instead needed to set the "insidergroup" parameter (on the Group Security page) to the name of a user group containing the set of users we wanted to be able to see the private entries. This could do with being documented a little more explicitly. Failure to parse JAXWS deployment descriptor The Sun reference implementation of the JAXWS 2.0 spec includes a WSServlet that can be deployed to a servlet container (e.g. Tomcat) to allow it to host web-services. This servlet is configured by a deployment file sun-jaxws.xml which resides in WEB-INF alongside the server deployment descriptor. This desriptor file allows the WSDL for a web-service endpoint to optionally be referenced from a local file (otherwise it is derived from the endpoint classes). We were deploying a number of web-services and had the WSDL files for these services in a sub-directory of WEB-INF. However one day the servlet stopped working and reported the following exception: WSSERVLET11: failed to parse runtime descriptor: XML reader error: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog. at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:128) After much investigation we discovered that the problem was actually not to do with the runtime descriptor, but was instead to do with parsing the referenced WSDL files, or more particularly erroneously parsing other files in the same directory as the referenced WSDL files. Yes it appears that if you have any non WSDL files in the same directory as your referenced WSDL files, the servlet attempts to parse these as WSDL (even though they are not referenced from the deployment descriptor) and if this fails the servlet does not initialise and a very misleading error is reported. Configuring Tomcat for remote debugging Java includes some really useful support for debugging of another virtual machine (e.g. of a browser plug-in, or servlet container). The principle is that the target VM is configured via VM arguments to listen for connection to a specific debug port, you then simply point your IDE at that port when you want to connect and debug. For Tomcat this is covered in this page - http://tomcat.apache.org/faq/development.html. However one thing that they omit to mention is that if you enter the VM options in the (Windows) Tomcat Properties dialog each option needs to go on a separate line (it seems that this dialog treats each line as a separete option to negate the need to quote paths with spaces). Hence if the options -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n are entered on the same line, the remote port is not actually opened and there is no indication of why. To avoid this infuriating problem, the options should simply be entered as: -Xdebug Overriding default SSL behaviour in Tomcat The default SSL behaviour of the JSSE within Java is to only allow communication with hosts that have trusted certificates. To get around this you need to supply your own SSLSocketFactory implementation and set the ssl.SocketFactory.provider property to point to it. This worked fine from a stand-alone J2SE application, but as soon as we used the code from a servlet running in Tomcat we got ClassNotFoundException for our SSLSocketFactory. It seems that in this case (for reasons unknown), the class referenced by ssl.SocketFactory.provider needs to be on the bootstrap class-path (e.g. in <jre>/lib/ext). Gotcha 5. [Domain Apache/Linux] Bizarre SSL problems / problems serving page Case 1: Having generated/imported a valid key/certificate pair and referenced them from conf.d/ssl.conf, httpd fails to start (not even any error log entries written!) Case 2: Some pages are served but others are not despite the same apparent privileges Gotcha: This is SELinux (used in Red Hat / Fedora / Debian) at work. Try ls -Z to see if the files/certificates have the same SELinux security category as others. Copying files, say from a Samba connection, almost certainly won't set the correct category. This can be changed (by root) using chcat -- +<category> <filename> Directory and Location are not the same Be careful when editing the httpd.conf Apache configuration file, not to paste in example text from the web that uses <Location> elements thinking that they are equivalent to the existing <Directory> elements. Directory elements refer to directories on your file system, whereas Location elements refer to relative URL locations. This can cause rather unexpected behaviour. |