ah, the lovely battle of schema and catalogs in JDBC land.

Short version: it can't really be handled well - I think if system has multiple ambigious references we are better of failing stating the setup needs to be made more specific, rather than "take first that match"

Longer version:
Hibernate Tools reverse engineering handles mulitiple schemas for two reasons a) to be able to handle the default case users will run into out of the box if running on multi-user db's b) that some databases (i.e. often in IBM land) actually encourages usage of multiple schemas as a way to separate systems but still allow cross-joins/queries.

But I never found a good way to ever figure out (efficiently) which is the current catalog/schema (especially considering that databases and drivers in different combinations would return different results - i.e. mysql swaps meaning of catalog/schema in some versions) thus anytime anyone bumped into needing only specific subset I simply expected them do have set hibernate.default_schema|catalog and used that as the search of tables and as the default schema if schema was not known.

BUT even if you set the hibernate.default* properties you can still via reveng.xml and the tools specify you would want to search wider than that.

In this case the hibernate.default* was used to make sure that the generated code and the model would not set schema/catalog specifically. This allowed you to reverse engineer a specific schema, but still let the code be possible to reuse for other schemas and here the user would set hibernate.default* to something else.

Thus I would say better to do:

if ( object-we-are-looking-for-explicitly-names-a-namespace ) {
    // only *ever* look in this explicit namespace
}
else {
    // look in current namespace, if known

    // look in default namespace, if defined

    // look in all namespaces, if one hit - use that; if multiple - error and inform user to define hibernate.default* or specifically set it on the relevant entities.
}