유효성 검사 도중 다른 위치 (Jar)에서 XSD 스키마를 읽는 방법

Question

xsd를 마샬링 및 언 마샬링하려고합니다. 항아리에는 A.xar에 1.xsd라는 하나의 xsd 파일이 들어 있습니다. JAXB를 사용하여 유효성을 검사하려고하지만 실패합니다. 1.xsd가 다른 jar (B. jar)에있는 스키마를 3 개 더 가져옵니다. 1.xsd의 유효성을 검사하는 동안 다른 jar (B.jar)에 속한 가져온 파일을 읽을 수 있는지 확인하려면 어떻게해야합니까?

Answer 1

두 개의 jar를 클래스 경로에서 사용할 수 있다고 가정하면 스키마 파일이 다른 jar에 있는지 여부는별로 중요하지 않습니다. 한 스키마가 다른 스키마를 가져 오거나 포함하는 경우 중요한 것은 경로를 확인할 수 있다는 것입니다.

A.jar 및 B.jar에있는 my.project.schemas 패키지가 있다고 가정합니다. A.jar에는 해당 패키지에 1.xsd이 들어 있으며 에 같은 패키지에 2.xsd을 가져옵니다. 1.xsd에서 가져 오기 요소가 ...이처럼 보이는 경우

<xs:import namespace="https://www.example.com" schemaLocation="2.xsd" /> 

는 그것을 작동합니다. 리졸버 (resolver)는 다른 스키마의 위치를 ​​알아서 처리하며, 주어진 schemaLocation은 상대 경로이므로 리졸버는 동일한 패키지가 다른 위치의 동일한 jar 파일을 고려하기 때문에 그것을 찾는다.

패키지가 다른 경우 상황이 더 복잡해질 수 있습니다. 이 경우 올바른 파일을 참조하기 위해 패키지 계층을 위 또는 아래로 이동해야하는 상대 경로를 사용해야합니다 (예 : 이 my.project.schemas 패키지의 구성원 인 경우 additional/2.xsd). 또 다른 옵션은 use a custom resolver입니다. 이를 통해 외부 리소스에 대한 호출을 가로 채서 프로그래밍 방식으로 해결할 수 있습니다.

마지막으로 Schema 개체를 만드는 데 사용되는 SchemaFactory이 has a method that accepts an array of sources입니다. 각 스키마 파일에 Source을 생성하고 모두 Schema 객체를 만들기 위해이 파일들을 모두 공장에 공급하면 위치 문제가 발생하지 않습니다. 사실 schemaLocation 속성은 생략 할 수 있습니다. 왜냐하면 필요한 모든 참조가 제공된 스키마에서 찾을 수 있기 때문입니다.

과거에는 다른 패키지간에 스키마를 사용해야하는 마샬 러/언 마샬 러와 함께 JAXB를 사용했습니다. 서로 다른 jar에 걸쳐있을 수도 있습니다. 팩터 리 메서드에 대한 스키마 당 Source을 제공하는 마지막 솔루션이 제가 선호하는 방법이었습니다.