i have the following node in web.config:
<configuration>
...
<scheduling>
<agent>
<param desc="database">core</param>
</agent>
<agent>
<param desc="database">master</param>
</agent>
</scheduling>
...
</configuration>
i want to remove the whole <agent> node with the child param node with master content. more or less my xdt transform node looks like:
<configuration>
...
<scheduling>
<agent
xdt:Transform="Remove"
xdt:Locator="XPath(./param[#desc='database']/??????)" />
</scheduling>
...
</configuration>
as you see, i have no idea how to match with the node content string. What do i need to add in here?
environment notes:
windows 7 - visual studio 2010 SP1
Add an extra test for text() into the locator. To match the <param> node:
xdt:Locator="XPath(./param[#desc='database' and text()='master'])">
EDIT: To match the <agent> node you need to move param into the predicate that XPath is matching:
xdt:Locator="Condition(param/#desc='database' and param/text()='master')">
Related
** Edited for clarification **
I've inherited a bunch of xml documents (configuration files) that resemble the following structure (element names changes and structured simplified for the sake of brevity.
<containers>
<container id="c1">
<ports>
<port id="p2"/>
</ports>
<rules>
<!--
Within a container, a rule must refer to a port
declared within the same container.
A rule cannot refer to a port that does not
exist in the enclosing container.
-->
<rule id="r1" portId="p1"/><!-- p1 is not in c1, but in c2, bad -->
<rule id="r2" portId="p2"/><!-- this is good -->
<rule id="r3" portId="p3"/><!-- p3 is nowhere, bad -->
</rules>
</container>
<container id="c2">
<ports>
<port id="p1"/>
<port id="p2"/>
</ports>
<rules>
<rule id="r1" portId="p1"/>
</rules>
</container>
</containers>
A container can have points and rules (point and rule ids can be duplicated among containers; they just need to be unique within a container.)
The requirement is that if a rule references a point id, that point id must be defined within the enclosing container.
I need to search for rules within containers that, by mistake reference non-existing points.
I have xpath expressions that can find a rule that points to a non-existing point (unfortunately for the entire xml document.)
//*/rule/#portId[not( . = //*/port/#id)]
The rule applies to the entire document, it is not contained within containers.
That is, this xpath expression would detect that the rule r3 in container c1 refers to a port p3 that does not exist anywhere in the document.
However, this same xpath expression would not detect that rule r1 in container c1 refers to a port p2 that is not in container c1. Why? Because this xpath expression will match it with port p2 in container c2.
My xpath expression would not detect this.
Granted, I could do this with several xpath expressions and glue code between them (say, by applying the xpath expression to each container) but I was hoping if it is possible to use one single xpath expression starting from the root element instead.
Any advice?
Another option using the ancestor:: axis...
//rule[not(#portId = ancestor::container//port/#id)]
Try this one.
//rule[#portId[not(. = ./parent::rule/parent::rules/parent::container/*/port/#id)]]
This seems to work for me. Tested on:
<containers>
<container id="c1">
<ports>
<port id="p2"/>
<port id="p4"/>
</ports>
<rules>
<!--
Within a container, a rule must refer to a port
declared within the same container.
A rule cannot refer to a port that does not
exist in the enclosing container.
-->
<rule id="r1" portId="p1"/><!-- p1 is not in c1, but in c2, bad -->
<rule id="r2" portId="p2"/><!-- this is good -->
<rule id="r3" portId="p3"/><!-- p3 is nowhere, bad -->
</rules>
</container>
<container id="c2">
<ports>
<port id="p1"/>
<port id="p2"/>
</ports>
<rules>
<rule id="r1" portId="p1"/>
<rule id="r2" portId="p4"/>
</rules>
</container>
</containers>
using this online processor.
Got the following output
Element='<rule id="r1" portId="p1"/>'
Element='<rule id="r3" portId="p3"/>'
Element='<rule id="r2" portId="p4"/>'
Our project structure regarding the logback.xmls looks like this:
src\main\resources\logback.xml
src\main\resources\config\dev\logback.xml
src\main\resources\config\sjngm\dev\logback.xml
src\main\resources\config\int\logback.xml
src\main\resources\config\local\logback.xml
src\main\resources\config\prod\logback.xml
where the first one references to the environment specific one:
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds">
<contextName>sjngm</contextName>
<jmxConfigurator />
<include resource="config/${extra}${env:-local}/logback.xml" />
</configuration>
Note that extra is not defined most of the times, which is why used this for a while:
<include resource="config/${extra:-}${env:-local}/logback.xml" />
This stopped working at one point, can't remember which version of logback. So we changed it to
<include resource="config/${extra:-./}${env:-local}/logback.xml" />
which also worked for quite a while.
Now we switched to Spring Boot 1.5.4 (contains logback-classic 1.1.11 and logback-core 1.1.11) and it stopped working again. The latest error message is:
11:08:15,020 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Could not find resource corresponding to [config/./local/logback.xml]
If I go back to
<include resource="config/${extra:-}${env:-local}/logback.xml" />
the message is
11:19:28,778 |-WARN in ch.qos.logback.core.joran.action.IncludeAction - Could not find resource corresponding to [config/extra_IS_UNDEFINEDlocal/logback.xml]
Note that logback still uses "local" as a default string for env, so not all is broken.
What do I do now? Basically I want to tell logback that I want an empty string where extra would be.
This also doesn't work:
<property name="defaultExtra" value="" />
<include resource="config/${extra:-${defaultExtra}}${env:-local}/logback.xml" />
as an empty string seems to always result in an undefined property.
The only working thing I can come up with is this:
<if condition='isDefined("extra")'>
<then>
<include resource="config/${extra}${env:-local}/logback.xml" />
</then>
<else>
<include resource="config/${env:-local}/logback.xml" />
</else>
</if>
plus this into the pom.xml:
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
</dependency>
Isn't this nice?! So why did they have to break what was working nicely???
This worked for me:
<property name="extra" value="${logback.myApp.extra:- }" />
Logback seems to trim Whitespace out of the value. So the default value of Space did the trick.
Embedded Whitespace is preserved, which may lead to a FileNotFoundException if Tabs were embedded, but embedded Spaces were ok.
Setting a Property in a Java Initialiser had the desired effect:
System.setProperty("logback.myApp.extra", "\t \tEXTRA_EXTRA_EXTRA\t \t");
The Tabs & Spaces were removed from the Property, which was assigned the value EXTRA_EXTRA_EXTRA
(the Java Initialiser must be invoked before any Logging has taken place & may contain no Logging itself)
You could of course set the Property on the Java Command line.
P.S. if the Property is undefined & you omit the Space (${logback.myApp.extra:-}), it is assigned the value:
logback.myApp.extra_IS_UNDEFINED
...so it may be wise to add a suitable comment:
<property name="extra" value="${logback.myApp.extra:- }" /><!-- N.B. Empty Default value must contain # least 1 Space!! -->
I'm new to hadoop and now I'm testing simple workflow with just single sqoop action. It works if I use plain values - not global properties.
My objective was however, to define some global properties in file referenced in job-xml tag in global section.
After long fight and reading many articles I still cannot make it work.
I suspect some simple thing is wrong, since I found articles suggesting that this feature works fine.
Hopefully, you can give me a hint.
In short:
I have properties, dbserver, dbuser and dbpassword defined in /user/dm/conf/environment.xml
These properties are referenced in my /user/dm/jobs/sqoop-test/workflow.xml
At runtime, I receive an EL_ERROR saying that dbserver variable cannot be resolved
Here are details:
I'm using Cloudera 5.7.1 distribution installed on single node.
environment.xml file was uploaded into hdfs into /user/dm/conf folder.
Here is the content:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property>
<name>dbserver</name>
<value>someserver</value>
</property>
<property>
<name>dbuser</name>
<value>someuser</value>
</property>
<property>
<name>dbpassword</name>
<value>somepassword</value>
</property>
</configuration>
workflow.xml file was uploaded into /user/dm/jobs/sqoop-test-job. Here is the content:
<?xml version="1.0" encoding="UTF-8"?>
<workflow-app xmlns="uri:oozie:workflow:0.4" name="sqoop-test">
<global>
<job-xml>/user/dm/conf/env.xml</job-xml>
</global>
<start to="get-data"/>
<action name="get-data">
<sqoop xmlns="uri:oozie:sqoop-action:0.3">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<prepare>
<delete path="${outputRootPath}"/>
</prepare>
<arg>import</arg>
<arg>--connect</arg>
<arg>jdbc:sqlserver://${dbserver};user=${dbuser};password=${dbpassword}</arg>
<arg>--query</arg>
<arg>select col1 from table where $CONDITIONS</arg>
<arg>--split-by</arg>
<arg>main_id</arg>
<arg>--target-dir</arg>
<arg>${outputRootPath}/table</arg>
<arg>-m</arg>
<arg>1</arg>
</sqoop>
<ok to="end"/>
<error to="kill"/>
</action>
<kill name="kill">
<message>Sqoop-test failed, error message[${wf:errorMessage()}]</message>
</kill>
<end name='end'/>
</workflow-app>
Now, I execute oozie workflow from command line:
sudo -u dm oozie job --oozie http://host:11000/oozie -config job-config.xml -run
Where my job-config.xml is as follows:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configuration>
<property>
<name>nameNode</name>
<value>namenode:8020</value>
</property>
<property>
<name>jobTracker</name>
<value>jobtracker:8021</value>
</property>
<property>
<name>oozie.wf.application.path</name>
<value>/user/dm/jobs/sqoop-test-job/workflow.xml</value>
</property>
<property>
<name>outputRootPath</name>
<value>/user/dm/data/sqoop-test</value>
</property>
</configuration>
OK, you are making two big mistakes.
1. Let's start with a quick exegesis of some parts of the Oozie documentation (V4.2)
Workflow Functional Specification
has a section 19 about Global Configuration
has sections 3.2.x about core Action types i.e. MapReduce, Pig, Java, etc.
the XML schema specification clearly shows the <global> element
Sqoop action Extension
does not make any mention of Global parameters
has its own XML schema specification, which evolves at its own pace, and is not up-to-date with the Workflow schema
In other words: the Sqoop action is a plug-in as far as the Oozie server is concerned. It does not support 100% of the "newer" functionalities, including the <global> thing that was introduced in Workflow schema V0.4
2. You don't understand the distinction between properties and parameters -- and I don't blame you, the Oozie docs are confused and confusing.
Parameters are used by Oozie to run text substitutions in properties, in commands, etc. You define their values as literals, either at submission time with the -config argument, or in the <parameters> element at Workflow level. And by "literal" I mean that you cannot make reference to a parameter in another parameter. The value is just immutable text, used as-is.
Properties are Java properties passed to the jobs that Oozie starts. You can set them either at submission time with the -config argument -- yes, it's a mess, the Oozie parser has to sort out which params have a well-known property name and which ones are just params -- or in the <global> Workflow element -- but they will not be propagated in all "extensions", as you have discovered the hard way -- or in the <property> Action element or inside an XML file defined with <job-xml> element, either at global Workflow level or at local Action level.
Two things to note:
when properties are defined multiple times with multiple (conflicting) values, there has to be a precedence rule but I'm not too sure
properties defined explicitly inside Oozie may have their value defined dynamically, using parameters and EL functions; but properties defined inside <job-xml> files must be literals because Oozie does not have access to them (it just passes the file content to the Hadoop Configuration constructor at run-time)
What does it mean for you? Well, your script tells Oozie to pass "hidden" properties to the JVM running the Sqoop job, at run-time, through a <job-xml>.
But you were expecting Oozie to parse a list of parameters and use them, at compile time, to define some properties. That won't happen.
Suppose I have a Web.config like such:
<configuration>
<elmah>
...
</elmah>
</configuration>
Is it possible to remove the <elmah> node with config transforms? So far I've tried something like:
<configuration>
<elmah xdt:Transfrom="RemoveAll"/>
</configuration>
Which doesn't work (according to Preview Transform). Althought this type of thing does seem to work on other nodes. Does anyone know how this can be removed?
Thanks
You need to have a xdt:Locator to get the match.
Try using the following:
Debug:
<configuration>
<elmah name="debug" />
</configuration>
Release:
<configuration>
<elmah name="debug" xdt:Locator="Match(name)" xdt:Transform="RemoveAll" />
</configuration>
Or without the need for name matching:
<configuration>
<elmah name="debug" xdt:Locator="XPath(//elmah)" xdt:Transform="RemoveAll" />
</configuration>
or
<configuration>
<elmah name="debug" xdt:Locator="XPath(configuration/elmah)" xdt:Transform="RemoveAll" />
</configuration>
As a note:
Currently the Web.config transforms are only applied during the Web Publish Pipleline (WPP) that is on Publish, not during debug, to enable them during debug check the following link: http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx .
Hope it helps.
You have a typo in your xdt syntax – it should be xdt:Transform, not xdt:Transfrom.
I've got this API using JAXB to conveniently use object models, generated from XML Schemas by the XJC (XML-to-Java) compiler, through named references. It abstracts the creation of JAXB contexts and finding ObjectFactory methods away by all sorts of background magic and reflection. The basic gist of it is that you'd always define one general schema, and then any number (may also be 0) of schemas "extending" that general one, each resulting in its own data model. The general schema carries the reusable definitions, the ones extending it use those to compose their own models.
I've now run into the situation where I'd like to reuse the general schema for more than one project. The general type definitions should remain the same across projects, and some code will be built against the abstract classes generated from those. So I'd need to first generate classes for some generic schema, then generate those extending and using them separately. I'm using Maven for my build process.
The problem I'm running into is resolving type definitions from that generic schema in the extending schemas.
Suppose my generic schema is named "general.xsd" and looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.foobar.com/general"
xmlns:gen="http://www.foobar.com/general"
elementFormDefault="qualified" attributeFormDefault="qualified">
<!-- Element (will usually be root) -->
<xs:element name="transmission" type="gen:Transmission" />
<!-- Definition -->
<xs:complexType name="Transmission" abstract="true">
<xs:sequence>
<!-- Generic parts of a transmission would be in here... -->
</xs:sequence>
</xs:complexType>
</xs:schema>
Next to that there's a bindings file to do some naming customization and set the package name for the output:
<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd"
version="2.1">
<!-- Bindings for the general schema -->
<bindings schemaLocation="general.xsd" node="/xs:schema">
<schemaBindings>
<package name="com.foobar.models.general"/>
</schemaBindings>
<bindings node="//xs:complexType[#name='Transmission']">
<!-- Some customization of property names here... -->
</bindings>
</bindings>
I'd then have the next bit in the POM of that project to generate the Java classes:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb21-plugin</artifactId>
<version>0.8.0</version>
<executions>
<execution>
<id>xjc-generate</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaDirectory>${basedir}/src/main/resources/com/foobar/schemas</schemaDirectory>
<schemaLanguage>XMLSCHEMA</schemaLanguage>
<addCompileSourceRoot>true</addCompileSourceRoot>
<episode>true</episode>
<removeOldOutput>true</removeOldOutput>
</configuration>
</execution>
</executions>
</plugin>
As you can see, I'm using the JAXB2.1 Maven plugin. I've set the option to have an episode file generated for step-wise compilation. The option to remove previous output was for a bug workaround; all it does is make sure everything's cleaned up first so recompilation is forced.
So far so good. That project compiles without a hitch. It should be noted that apart from the generated Java classes, I also package the schemas into the resulting jar file. So those are available on the classpath! The sun-jaxb.episode file is in the META-INF, as it should be.
Then I start on the project that uses schemas which will extend the above, by first importing it. One of the "subtypes" could look like this (I'll call it sub.xsd):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.foobar.com/sub"
xmlns:sub="http://www.foobar.com/sub"
xmlns:gen="http://www.foobar.com/general"
elementFormDefault="qualified" attributeFormDefault="qualified">
<xs:import namespace="http://www.foobar.com/general" />
<!-- Definition -->
<xs:complexType name="SubTransmission">
<xs:complexContent>
<xs:extension base="gen:Transmission">
<xs:sequence>
<!-- Additional elements placed here... -->
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Again, there's a bindings file:
<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd"
version="2.1">
<!-- Bindings for sub type -->
<bindings schemaLocation="sub.xsd" node="/xs:schema">
<schemaBindings>
<package name="com.foobar.models.sub"/>
</schemaBindings>
</bindings>
</bindings>
And here's the bit from the POM of this project that takes care of the XJC generation:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb21-plugin</artifactId>
<version>0.8.0</version>
<executions>
<execution>
<id>xjc-generate</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaDirectory>${basedir}/src/main/resources/com/foobar/schemas</schemaDirectory>
<schemaLanguage>XMLSCHEMA</schemaLanguage>
<addCompileSourceRoot>true</addCompileSourceRoot>
<episode>false</episode>
<catalog>${basedir}/src/main/resources/com/foobar/schemas/catalog.cat</catalog>
<episodes>
<episode>
<groupId>com.foobar</groupId>
<artifactId>foobar-general-models</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>compile</scope>
</episode>
</episodes>
<removeOldOutput>true</removeOldOutput>
</configuration>
</execution>
</executions>
</plugin>
Originally, all the schemas were in a single folder and I had the schemaLocation attribute in the import set to general.xsd, which worked fine. But now that things are separated across projects, I run into problems. The first issue was that the other schema could not be found. I've resolved this by taking the schemaLocation attribute out of the <xs:import /> element, keep only the namespace attribute and adding a catalog file (catalog.cat) which you can see referenced in the above POM extract. Its contents are:
PUBLIC "http://www.foobar.com/general" "classpath:/com/foobar/schemas/general.xsd"
This seems to work, since I no longer get an error that states the schema cannot be found. But for some reason, resolving the actual type definitions from the imported schema continues to fail. Here's the exception:
Error while parsing schema(s).Location [ file:/C:/NetBeans_groups/Test/SubModelBundle/src/main/resources/com/foobar/schemas/sub.xsd{...,...}].
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'gen:Transmission' to a(n) 'type definition' component.
Here's what I tried so far:
Use a catalog file. Partially successful, since the imported schema can now be found.
Have the compilation for the general schema generate an episode file and use this for the compilation of the sub schema. Doesn't appear to make a difference, although this should only play a role once the type was resolved, so I don't think this is important yet.
Use a different JAXP (note: not JAXB, JAXP) implementation. It did use a different one, because I could see that in the exception's stack trace, but the end result is the same.
Use the maven-jaxb22-plugin instead of 21. No difference.
Looking around online, it seems people have been running into this issue since at least 2006 and it might be related to some Xerces resolver problems. I hope that this is not some bug that's been lurking around for 6 years without anyone caring to fix it. Does someone else have some suggestions? Maybe someone ran into the same problem and found a solution? The only workaround I can think of is to use 'svn:externals' to drag the general schema into the sub project and just regenerate the classes there, but it's dirty and will only work when you can connect to our svn repo.
Much thanks in advance for reading this long post. Do keep in mind that I've taken all of the above from existing projects and replaced some namespaces and other things for anonymity, so some typos are possible.
This answer was edited. Before, I had a solution using a custom catalog resolver. However, I've found the actual problem now. The explanation follows. For the TL;DR version that provides the solution, scroll to the bottom of this answer.
The problem is with the catalog file. Note how it had this line:
PUBLIC "http://www.foobar.com/general" "classpath:/com/foobar/schemas/general.xsd"
What does that say? It says that if the public ID http://www.foobar.com/general is encountered, the system ID for the schema is classpath:/com/foobar/schemas/general.xsd. So far so good. If we take the schemaLocation attribute out of our <xs:import /> elements, the only thing that remains is the public ID (namespace URN) and the catalog file tells us where to find the schema for it.
The problem occurs when that schema then uses <xs:include /> elements. They include schema files with the same target namespace. They specify a system ID (relative location). So you'd expect that to be used for resolution. However, logging the calls to the catalog resolver reveals that requests are made for resolution with both the public ID (namespace) and system ID (relative location). And that's where it goes wrong. The public ID is given preference because of the binding in the catalog file. And that leads us straight to the general.xsd file again.
Say for example that the general schema is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.foobar.com/general"
xmlns:gen="http://www.foobar.com/general"
elementFormDefault="qualified" attributeFormDefault="qualified">
<!-- Including some definitions from another schema in the same location -->
<xs:include schemaLocation="simple-types.xsd" />
<!-- Remaining stuff... -->
</xs:schema>
And that a schema using that one is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.foobar.com/sub"
xmlns:sub="http://www.foobar.com/sub"
xmlns:gen="http://www.foobar.com/general"
elementFormDefault="qualified" attributeFormDefault="qualified">
<xs:import namespace="http://www.foobar.com/general" />
<!-- Remaining stuff... -->
</xs:schema>
When XJC is parsing that last schema, this is happening:
Parsing local definitions.
Encounters reference to definition from imported schema.
Checks import, finds no system ID, only public ID (http://www.foobar.com/general).
Checks catalog(s).
Finds binding of public ID to classpath:/com/foobar/schemas/general.xsd.
Parsing definitions in imported schema.
Encounters reference to definition from included schema (simple-types.xsd).
Checks include, finds system ID.
Checks catalog(s) for the system ID, but the public ID is implicit.
Finds binding of public ID to classpath:/com/foobar/schemas/general.xsd, which takes preference over system ID.
Resolution of included schema definitions fails.
The details for the order in which resolution is attempted are described in the OASIS spec for XML catalogs: https://www.oasis-open.org/committees/entity/spec.html#s.ext.ent. It takes a bit of interpretation, but you'll find that if the preferred method of resolution is the public IDs, those will take precedence when bound in the catalog file even if there is a system ID.
The solution, then, is to specify that system IDs are the preferred method of resolution, not provide system IDs in the imports so that the catalog's public ID binding is used and relying on the relative system IDs from the includes. In the OASIS XML catalog format, you can use attribute prefer="system". In the OASIS TR9401 catalog format, you can use OVERRIDE no. Apparently the default is public/yes.
So my catalog file then becomes:
OVERRIDE no
PUBLIC "http://www.foobar.com/general" "classpath:/com/foobar/schemas/general.xsd"
Now the regular catalog resolver works fine. I no longer need the custom one. However, I wouldn't have guessed that the public ID is still used for resolution when including schemas and takes precedence over the system ID. I'd have thought the public ID would only be used for imports, and that the system ID would still be considered if resolution failed. Only adding some logging to the custom resolver revealed this.
The short answer: add OVERRIDE no as the first directive in your TR9401 catalog file, or attribute prefer="system" to an XML catalog file. Don't specify schemaLocation in <xs:import /> directives, but bind the namespace to the proper schema location in the catalog file. Make sure <xs:include /> uses a relative path to the included schema.
Another interesting thing: the catalog resolver used by XJC can handle not just classpath: URIs, but also maven: URIs, which work relative to a Maven artefact. Pretty useful if you're using that as your build tool.
http://confluence.highsource.org/display/MJIIP/User+Guide#UserGuide-Usingcatalogs
Using Maven 2.2.1 works for me using org.jvnet.jaxb2.maven2.resolver.tools.ClasspathCatalogResolver.
Here's a sample configuration:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.0</version>
<executions>
<execution>
<id>executionId</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<schemaDirectory>src/main/resources/META-INF/schemas</schemaDirectory>
<generatePackage>com.company.project.data</generatePackage>
<bindingDirectory>src/main/jaxb</bindingDirectory>
<catalog>src/main/jaxb/catalog.cat</catalog>
<catalogResolver>org.jvnet.jaxb2.maven2.resolver.tools.ClasspathCatalogResolver</catalogResolver>
<verbose>false</verbose>
<extension>true</extension>
<episodes>
<episode>
<groupId>com.company.project</groupId>
<artifactId>xsd-common-types</artifactId>
<version>${xsd-common-types.version}</version>
</episode>
</episodes>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.company.project</groupId>
<artifactId>xsd-common-types</artifactId>
<version>${xsd-common-types.version}</version>
</dependency>
</dependencies>
</plugin>
Making this configuration work with Maven 3 results in a org.xml.sax.SAXParseException