You can deploy web applications and static content in Tomcat without dropping files into the webapps directory. This is useful if you want the content to reside outside of the Tomcat directory tree. You do this by putting a Context fragment in the host's configuration directory (e.g. ${TOMCAT_HOME}/conf/Catalina/localhost). That is, use an XML file that looks like this:
<Context path="/mycontent" docBase="c:\somewhere\mycontent"/>
The docBase can be a WAR file.
Sun "fixed" the QName bug as of JDK 1.5.0_07. That is, they changed the serialver of QName back to what it used to be back in JDK 1.4. However, this "fix" is problematic since many vendors have already issued patches to accommodate the bug. For example, BEA has an elaborate workaround to make WebLogic 9.1 interoperate with older version of QName (e.g. as you might find in ALDSP 2.1/WebLogic 8.x). That workaround is now broken with JDK 1.5.0_07.
However, Sun has thoughtfully provided the system property:
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
Sparse documentation about this magic incantation can be found in the JAXP 1.3.1 release notes. When this property is defined, QName will use the serialver ID that existed for only a few microrevs of JDK 1.5. For reference, here are the relevant serialvers:
Prior to JDK 1.5: -9120448754896609940L
JDK 1.5.0, microrevs _00 through _06: 4418622981026545151L
JDK 1.5.0_07 (and hopefully, everything greater): -9120448754896609940L (once again)
Interestingly, the JDK 1.5.0_07 release notes say that the relevant bug in the Java Bug Parade is "fixed", but the notes for that bug say that no action was taken (which is not true).
WebLogic 9.x vs. JDK 1.5.0_07
WebLogic 9.x won't start at all under JDK 1.5.0_07, even if ALDSP is not in the picture at all. There seems to be some component within the server that still wants to use the '4418' version of QName. The magic incantation above will fix the problem. Check out the thread "javax.xml.namespace.QName incompatible" in the BEA WebLogic server newsgroup.
Okay, it happened again. This time, a JIRA item (RAPT-558) did not show in the All filter for the RAPT project -- or any other filter for that matters. You could load the item directly, it just didn't appear in any lists. Rebuilding the indexes corrected the problem.
Oracle, SQL*Plus, PL/SQL
SQL*Plus will behave as you expect when executing this sequence:
variable result number;
update zot set x=x+1 returning x into :result;
print result;
but not this sequence:
variable result number;
select count(*) into :result from user_catalog;
print result;
In the latter case, the SELECT statement is accepted and executed, but the INTO clause is not respected. On the other hand, you can make it work by using a PL/SQL block:
variable result number;
begin
select count(*) into :result from user_catalog;
end;
/
print result;
While we're on the topic of SQL*Plus, here are some useful snippets that I haven't captured before...
set echo on
whenever sqlerror exit failure
define supplied_user = &&1
define supplied_tablespace = &&2
prompt Creating tables for &&supplied_user in &&supplied_tablespace
declare
table_count number;
begin
select count(*) into table_count from user_catalog where table_name='ZOT';
if 0 = table_count then
execute immediate
'create table &&supplied_user..zot (x integer) '
|| ' tablespace &&supplied_tablespace'
;
end if;
end;
/Note the two dots in "create table &&supplied_user..zot". The second dot is needed because SQL*Plus will gobble the first dot it sees after any use of the "&" operator (unless you change that behaviour using SET CONCAT).
You can add a dependency between one Windows service and another by creating a REG_MULTI_SZ key with the name:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dependent service name\DependOnService
The value is a newline-delimited list of prerequisite service names (identified by their registry key name).