2017-02-14 3 views
2

Я разрабатываю приложение с SpringBoot 1.4.1 в качестве основной структуры. Приложение представляет собой Maven Dynamic Web Project, который предоставляет некоторые веб-службы и подключается к различным базам данных. Он поддерживает как серверы, так и клиенты для подключения к некоторым другим программам, таким как Microsoft Dynamics или AutoCad.Исключение развертывания WebLogic с использованием @WebParam в приложении SpringBoot CXF

Он работает как «дорожка» между некоторыми приложениями и некоторыми базами данных.

Веб-службы разработаны с использованием CXF 3.1.8, а доступ к базам данных осуществляется с помощью Spring JPA для методов CRUD и MyBatis для сложных запросов.

Все настроено с помощью java clases и java beans (без файлов конфигурации xml).

Приложение прекрасно работает как в загрунтованной весной загрузке Tomcat (развертывая его как приложение для загрузки весной), так и в сервере WebLogic 12c (развернутом как война на основе maven).

Но у меня странное поведение с некоторыми методами веб-сервисов. В частности, все методы работают отлично, за исключением методов удаления.

Вот небольшая часть кода.

У меня есть родительский класс java, который реализует методы, которые будут использоваться веб-службами. Затем у меня есть два или более класса Java, которые расширяют этот родительский класс и вызывают метод super.method().

Здесь родительский класс:

@Transactional(propagation = Propagation.SUPPORTS, rollbackFor = Exception.class) 
public class FooService extends ServiceConfigurator { 

    @Autowired 
    protected FooRepository fooRepository; 
    @Autowired 
    protected FooMapper fooMapper; 
    @Autowired 
    protected FooFacade fooFacade; 

    public ServiceResult persistFoo(final Foo foo) { 
     this.getServiceResult(); 
     try { 
      Foo result = this.fooFacade.persistFoo(foo, this.serviceResult); 
      if (CollectionUtils.isEmpty(this.serviceResult.getErrors())) { 
       result = this.fooMapper.findOne(result.getId()); 
       this.serviceResult.getResults().add(result); 
       this.serviceResult.setSuccess(true); 
      } 
     } catch (final Exception e) { 
      logger.error("ERROR", e); 
      this.serviceResult.getErrors().addAll(Utils.addErrors(e)); 
      e.printStackTrace(); 
     } 
     return this.serviceResult; 
    } 

    public ServiceResult deleteFoo(final Foo foo) { 
     this.getServiceResult(); 
     try { 
      final Helper helper = this.fooMapper.findById(helper.getId()); 
      final Foo existing = this.fooMapper.find(helper.getId(),  foo.getNumber(), foo.getVersion()); 
      this.fooFacade.deleteFoo(existing, this.serviceResult); 
      if (CollectionUtils.isEmpty(this.serviceResult.getErrors())) { 
       this.serviceResult.setSuccess(true); 
      } 
     } catch (final Exception e) { 
      logger.error("ERROR", e); 
      this.serviceResult.getErrors().addAll(Utils.addErrors(e)); 
      e.printStackTrace(); 
     } 
     return this.serviceResult; 
    } 
} 

И вот один из дочерних классов:

@Service("fooImpService ") 
@WebService(serviceName = "FooImpService ") 
public class FooImpService extends FooService { 

    public ServiceResult createFoo(@WebParam(name = "foo") final Foo foo) { 
     return super.persistFoo(foo); 
    } 

Этот метод выше работает нормально везде, где я раскрываю мое приложение, и так это делает другой (как пример):

@Transactional(readOnly = false) 
public ServiceResult findId(@WebParam(name = "idOne") final String idOne, @WebParam(name = "idTwo") final String idTwo, 
     @WebParam(name = "version") final String version) { 
    this.getServiceResult(); 
    try { 
     final Foo foo = this.fooMapper.findById(idOne); 
     final Fooresult = this.fooMapper.findByVersion(foo.getId(), idTwo, version); 
     if (result != null) { 
      this.serviceResult.getResults().add(result.getId()); 
      this.serviceResult.setSuccess(true); 
     } 
    } catch (final Exception e) { 
     logger.error("ERROR", e); 
     this.serviceResult.getErrors().addAll(Utils.addErrors(e)); 
     e.printStackTrace(); 
    } 
    return this.serviceResult; 
} 

Эти методы работают как в качестве приложения для загрузки весны, файла jar, так и во время развертывания военного файла в WebLogic.

Но этот метод:

public ServiceResult deleteFoo(@WebParam(name = "foo") final Foo foo) { 
    return super.deleteFoo(foo); 
} 

прекрасно во встроенном сервере Tomcat работает, если я развернуть приложение как весной загрузки приложения, но когда я пытаюсь развернуть войну WebLogic я получаю следующее исключение:

Caused by: java.lang.NullPointerException: 
    at com.sun.xml.ws.spi.db.JAXBWrapperAccessor.getPropertyAccessor(JAXBWrapperAccessor.java:261) 
    at com.sun.xml.ws.db.toplink.JAXBContextWrapper.getElementPropertyAccessor(JAXBContextWrapper.java:170) 
    at com.sun.xml.ws.server.sei.EndpointArgumentsBuilder$DocLit.<init>(EndpointArgumentsBuilder.java:598) 
    at com.sun.xml.ws.server.sei.TieHandler.createArgumentsBuilder(TieHandler.java:143) 
    at com.sun.xml.ws.server.sei.TieHandler.<init>(TieHandler.java:115) 
    at com.sun.xml.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:118) 
    at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:74) 
    at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:58) 
    at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:120) 
    at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:521) 
    at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:300) 
    at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:164) 
    at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:577) 
    at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:560) 
    at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:639) 
    at weblogic.wsee.jaxws.JAXWSDeployedServlet.getEndpoint(JAXWSDeployedServlet.java:355) 
    at weblogic.wsee.jaxws.JAXWSServlet.registerEndpoint(JAXWSServlet.java:167) 
    at weblogic.wsee.jaxws.JAXWSServlet.init(JAXWSServlet.java:79) 
    at weblogic.wsee.jaxws.JAXWSDeployedServlet.init(JAXWSDeployedServlet.java:91) 
    at javax.servlet.GenericServlet.init(GenericServlet.java:244) 
    at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:343) 
    at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:294) 
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326) 
    at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197) 
    at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203) 
    at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71) 
    at weblogic.servlet.internal.StubSecurityHelper.initServletInstance(StubSecurityHelper.java:99) 
    at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:87) 
    at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:71) 
    at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:57) 
    at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:31) 
    at weblogic.servlet.internal.ServletStubImpl.initStubLifecycleHelper(ServletStubImpl.java:673) 
    at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:612) 
    at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:2054) 
    at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:2031) 
    at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1920) 
    at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3091) 
    at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1823) 
    at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:882) 
    at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) 
    at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) 
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45) 
    at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) 

Это исключение может быть вызвано чем-то, связанным с аннотацией @WebParam, потому что когда я удаляю аннотацию из метода удаления, приложение развертывается правильно, и метод отлично работает в WebLogic.

+1

У меня аналогичная проблема, когда весна загрузки моей баночки и войны работала отлично и WLS это не работать там, где я использую JAXB, и я узнал, WLS использует свой собственный JAXBMarshaller и я добавил пакет в META-INF и сопоставлен с weblogic.xml с использованием ресурсов -приложений-приложений. Я не думаю, что это так же касается вашей проблемы, но и проверить эту строку. – user3428736

+0

выглядит как конфликт классов, упомянутый выше. – ulab

+0

@ user3428736 Какие пакеты вы добавили в weblogic.xml? В моем приложении у меня есть jaxb-core и jaxb-impl jars, но я не уверен, какие пакеты добавить ... Может быть, com.sun.xml? –

ответ

0

Следующая ссылка https://axis.apache.org/axis2/java/core/docs/app_server.html для Axis, но в целом применима к пользовательским войнам на веб-сайте. Он утверждает,

если вы хотите развернуть пользовательские Войн, скажем, в кластерной среде, необходимо добавить два дополнительных файла в WEB-INF под названием «services.list» и «modules.list» под модули и каталог услуг соответственно.

WEB-INF/services/services.list: должен отображать все службы (файлы aar), которые вы хотите просмотреть. WEB-INF/модули/модули.list: должен отображать все модули (файлы mar), которые вы хотите использовать.

ПРИМЕЧАНИЕ: В обоих случаях, пожалуйста, перечислите одну запись в строке.

WebLogic поставляется с JAR, которые конфликтуют с JAR, присутствующими в Axis2. Поэтому используйте для обеспечения того, чтобы JAR, упакованные в Axis2 WAR, были взяты из WEB-INF/lib. Вы можете сделать это, установив для элемента в WEB-INF/weblogic.xml значение true. Пример weblogic.xml приведен ниже:

<weblogic-web-app> 
    <container-descriptor> 
     <prefer-web-inf-classes>true</prefer-web-inf-classes> 
    </container-descriptor> 
</weblogic-web-app> 

Если установлено значение истинно, то элемент заставит загрузчик классов WebLogic для загрузки классов, расположенных в каталоге WEB-INF веб-приложения в предпочтении к применению или системных классов. Это рекомендуемый подход, поскольку он влияет только на один веб-модуль.

Для CXF, аналогичный документ на http://cxf.apache.org/docs/application-server-specific-configuration-guide.html#ApplicationServerSpecificConfigurationGuide-WebLogic:

Создать WebLogic-application.xml (Weblogic специфические) в папке META-INF.

<?xml version="1.0" encoding="UTF-8"?> 
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"> 
    <application-param> 
     <param-name>webapp.encoding.default</param-name> 
     <param-value>UTF-8</param-value> 
    </application-param> 
    <prefer-application-packages> 
     <package-name>javax.jws.*</package-name> 
    </prefer-application-packages> 
</weblogic-application> 
+0

Я уже определил нечто похожее для log4j. У меня была проблема с банками WLS, поэтому я добавил в weblogic.xml код: org.slf4j Я проверю этот параметр и расскажу вам, что произойдет. Спасибо. –

+0

Ваши услуги в services.list? – mikep

+0

Нет. Я использую apache CXF, и вся конфигурация выполняется через классы конфигурации java, где я определяю конечные точки служб. Список служб создается при развертывании. Я могу видеть и использовать все службы и все методы обслуживания, и все они отлично работают с аннотацией @WebParam, за исключением методов удаления. Странное поведение. Я думаю, что эта проблема имеет больше общего с банками, используемыми WLS, чем любая другая вещь, как вы упомянули ранее. –

Смежные вопросы