Всем доброго дня)))
Возникла необходимость формировать xml-документ по xsd в Java. Все ссылки по этому поводу на xsd2inst из apach.XmlBeans. Скачал версию 2.5.0. Опробовал с командной стоки - все работает. С исходников затащил себе код из ShemaInstanceGenerator.java - получаю Exception - "The 0th supplied input is not a schema document: its type is N="(id=154)". Там код-то простой))). В отладчике XmlObject.Factory.parse(...) не дает Exception и сформированный объект содержит мой xsd, но тип объекта XmlBeans.NO_TYPE. Естественно дальше валится XmlBeans.copileXsd(...) - смотрел по кодам - просто на несоответствии типа входного документа, при попытке привести его к org.appach.xmlbens.impl.xb.xsdschema.SchemaDocument.

Братья, мож кто подтолкнет куда мне рыть)))

Заранее благодарен)))

Уточню - пишу под eclipce - plug-in - отлаживаюсь через eclipce-application. Мож настройки какие в eclipce помогут?

Еще уточнение - не работает в обработчике события от кнопки. Перенес код в конструктор диалога - там все работает. Я еще больше озадачен. В чем может быть проблема? Но уж и до-кучи - приложение JFace SWT)))

Продвигаюсь дальше - похоже дело не в обработчике. Я динамически подгружаю классы и баг начинает проявляться после таких кодов
loader=new URLClassLoader(urls);
Thread.currentThread().setContextClassLoader(loader);
- когда я устанавливаю в контекст свой класс-лоадер

Мож я чего не так делаю? Мож после нужно вычищать свой лоадер из контекста?

Посоветуйте))))

Похоже сам и отвечу)))
Запоминаю через getContextClassLoader - текущий лоадер и восстанавливаю его после завершения работы со своим. Наверное это нормальная культура программирования. Остаюсь в недоумении - почему парсер просто молчал - если внутрях не отработал егошный лоадер). Потом setContextClassLoader - логично не void-овскую иметь - ну возвращали бы туда текущий лоадер)))Это сразу наводило бы на мысль))) Удачи всем)))