this bug reporting is related to the bug
[ 1796346 ] Nonconformance to ebRS, section 6.5.1
but, instead of working on the xml message form, I suggest to modify the code of the QueryManagerImpl that, in my opinion is the bugged part of the problem. So I list both the old code (bugged) and the new code (modified and working) so the differences can be seen clearly:
old code:
String queryStr = (String)queryExp.getContent().get(0);
Unmarshaller unmarshaller = BindingUtility.getInstance().getJAXBContext().createUnmarshaller();
FilterQueryType filterQuery = (FilterQueryType)unmarshaller.unmarshal(new StreamSource( new StringReader(queryStr)));
new code:
FilterQueryType filterQuery = (FilterQueryType)queryExp.getContent().get(0);
Analizing the flow I found that 'queryExp.getContent().get(0)' returns directly a FilterQueryType, without the need of the Unmarshalling.
Logged In: YES
user_id=2022566
Originator: YES
File Added: QueryManagerImplPatch.txt
Logged In: YES
user_id=423887
Originator: NO
I thing that this bug is not only related to 1796346 but a duplicate of it. Both bug reports describe the issue that sending a request conforming to the ebRS specs causes a ClassCastException.
The proposed patch indeed corrects the problem in that it makes OMAR conform to the specifications. However, it will break existing clients that rely on the buggy behavior. For compatibility reasons it would therefore be better to check the result of queryExp.getContent().get(0) and still execute the existing code if the type is String.
Also we should check the JAXR provider to see if it generates requests conforming to the specifications or relies on the buggy behavior of OMAR.