We Keep Coding

Java XML validation without knowing the schema in advance

I can receive one of 82 XML structures, each of which contains a root which is not in a name space, and also contains several xmlns attributes the first of which defines a urn for the schema for the object, and the rest (which define namespaces) also contain the urns for the common objects.
The Schema Aware Parsing in Java assumes you know the schema before you start the parsing, but I do not know it until either I have loaded the XML without validation and extracted the root, at point I can load it again with the right schema, or I can find some way to get to the xmlns elements in the root and select the right schema (I know how to map the urn to the correct schema, and all the schemas are held as resources in my classpath.
It seems a shame to load the XML twice, is there a way to do this in a single pass?
As an example I have a possible document which looks like:-
<?xml version="1.0" encoding="UTF-8"?>
<BusinessCard xmlns="urn:oasis:names:specification:ubl:schema:xsd:BusinessCard-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
</BusinessCard>
(there is obviously content inside the BusinessCard object, but I left it out as it is no relevance here)
and I the schema for this is in resource "xsd/main/UBL-BusinessCard-2.2.xsd".
I have tried using an EntityResolver, but it does not get called before the parser complains that it can not find the declaration of BusinessCard.

I'm not sure why you say the root isn't in a namespace, when the xmlns="urn:oasis:names:... declaration makes it clear that it is.
One way to do this is to load a single composite schema that contains all the different component schemas, and validate against that. If the union of the schemas is a valid schema (i.e. no conflicting type definitions) then this might be the best approach, especially if you are validating thousands of document and most of the component schemas are going to be used in each run.
On the other hand, if you're only using a small number of the component schemas in a given run, then this would be expensive.
One approach would be to detect the namespace using an abortive parse of the document. Write a SAX filter that captures the first namespace declaration and then aborts the parse by throwing an exception. Or you could also do this with a streaming XSLT 3.0 transformation.
Even smarter would be to write a little SAX pipeline that does some buffering. Capture the first startElement event, extract the namespace, load the schema, create a validator, feed it the SAX events that you've already consumed (the first startElement), then feed the rest of the SAX events from your preprocessor straight through to the validator.

Xjc generating 1000+ classes for fpml schema

I have xml based on fpml schema.
Used xjc command line tool to generate corresponding pojo classes.
Then I am using JAXB to unmarshal xml into java objects.
I converted this to objects as an intermediate step because then it is easy to read values of some fields.
But problem is fpml schema generated ~1200 classes.
so I am not sure if this is correct approach as jar size will also increase.
My problem statement : convert one xml based on one schema to another xml based on another schema. Both involves fpml. While populating another xml I need to validate few fields from database.
please give me suggestions

Data binding technologies such as JAXB work fine for simple cases, but when the schema is large, complex, or frequently changing, they become quite unwieldy, as you have discovered.
This is a task for XSLT. Use schema-aware XSLT if possible, because it makes your stylesheet easier to debug.

Should Java classes created by JAXB have logic code

I use JAXB to load an XML configuration file to a Java object (ConfigurationDTO). Is it good practice to add some logic code on the this Java object (ConfigurationDTO) or I should create a different java object with this logic code (ie Configuration). When I say logic code I mean some checks/constraints that the configuration file should have. Should the java class 'ConfigurationDTO' contain only getters?

The question is why do you need that constraints? Are you going to use your object not only for marshalling/unmarshalling? If so it is bad idea. The rule of thumb is not to spread DTO objects among all levels of an application. If you follow this rule you'll not need to have additional constraints in your DTO.
The JAXB standard provides you with ability to validate an object during marshal and unmarshal time. It means that if your XML schema requires nonempty field but the corresponding java object has null value then marshal will fail. And vise versa.
Here is quote from the JAXB documentation
Validation is the process of verifying that an XML document meets all the constraints expressed in the schema. JAXB 1.0 provided validation at unmarshal time and also enabled on-demand validation on a JAXB content tree. JAXB 2.0 only allows validation at unmarshal and marshal time. A web service processing model is to be lax in reading in data and strict on writing it out. To meet that model, validation was added to marshal time so users could confirm that they did not invalidate an XML document when modifying the document in JAXB form.
Such approach has its own drawbacks (if you spread the DTO among the application you'll lost control on it) but the advantages are more valuable.

Java Bean Validation: Posible to specify runtime validations?

I am maintaining a web app that is using Java bean validations (as part of JSR303 I believe).
Members are mapped with annotations like #Pattern and then we have a LocalValidatorFactoryBean that performs the validation. The Validator that this factory bean bootstraps is actually the Hibernate validation instance.
My problem is that my #Pattern regex needs to be loaded at runtime when my application starts up, so I cannot use the annotation.
Therefore, I'm wondering if there is an alternative way such as XML to plug in such validation?
If not, I may just have to use a separate Spring validator to do this work

I recommend creating custom validator as described in http://docs.spring.io/spring/docs/3.0.0.RC3/reference/html/ch05s07.html#validation.beanvalidation.spring.constraints. Thus you will need to check the value agains the pattern in the code of constraint validator class.

You can configure bean validation using XML for such a thing. The syntax is a lot like the JavaBean XML format and maps rather well to the hierarchical structure of the equivalent Java syntax.

JAXB: How to exclude specific field from marshaling in runtime?

I'm using JAXB+Jettison to serve multiformat RESTful (schema-less) service.
#XmlTransient annotation served good for those properties that I don't want to serialize at all. But that's not enough.
How can I exclude specific field from marshaling in runtime?
Can I somehow preinitialize Marshaling context and define what fields to exclude?
I need that to selectively serialize object fields based on current user's role.

I've done similar before by having a number of DTOs in a hierarchy, from lean to full fat, each with differing JAXB mappings. However this is only practical for a small number of roles.
MOXy does allow runtime binding alterations, seems to fit the bill for your use-case.
However, beware with tampering with your service contracts, it can lead to weird live bugs that are a PAIN to track down.