1

I have 3 modules:

  • The api jar contains the xsd + wsdl files and generates the java objects during compile using cxf-codegen-plugin from apache.

  • The service jar implements the interface generated by the the api, which is imported as dependency.

  • And the ear builds the ear package from the service.

This is how the service is defined:

@Stateless
@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
@WebService(portName = "blabla",
        serviceName = "blabla",
        targetNamespace = "http://blabla",
        wsdlLocation = "META-INF/resources/wsdl/.../mywebservice.wsdl", // this should be relative to the api jar
        endpointInterface = "blabla")
@SchemaValidation
public class MyWebServiceImpl implements MyWebService {}

The thing is that we noticed the schema validation does not work if we don't specify the wsdlLocation, so we need to add it. But we don't know how to reference it without needing to add the wsdl files directly into the root of the service jar. We do the following assembly (located in the service module):

<assembly
    xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 http://maven.apache.org/xsd/assembly-1.1.3.xsd">
    <id>resources</id>
    <formats>
        <format>jar</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <dependencySets>
        <dependencySet>
            <includes>
                <include>service-artifact</include>
            </includes>
            <outputDirectory>/</outputDirectory>
            <useProjectArtifact>true</useProjectArtifact>
            <scope>runtime</scope>
            <unpack>true</unpack>
        </dependencySet>
        <dependencySet>
            <includes>
                <include>api-artifact</include>
            </includes>
            <outputDirectory>/</outputDirectory>
            <useProjectArtifact>true</useProjectArtifact>
            <scope>runtime</scope>
            <unpack>true</unpack>
            <unpackOptions>
                <includes>
                    <include>META-INF/resources/wsdl/**</include>
                </includes>
            </unpackOptions>
        </dependencySet>
    </dependencySets>
</assembly>

Which I want to get rid off since I think it should not be necessary to do it because the dependency is already there.

I've tried setting the wsdl location like this

wsdlLocation = "classpath:META-INF/resources/wsdl/.../mywebservice.wsdl"

But it throws an error during deployment:

####<May 4, 2021 10:33:05,436 AM EEST> <Warning> <Deployer> <devrecapp122> <AdminServer> <[ACTIVE] ExecuteThread: '113' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <8160e7ac-f241-4145-bdc1-9aaf0c1cbb76-0000c727> <1620113585436> <[severity-value: 16] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: weblogic.wsee.ws.WsException: wsdl "classpath:META-INF/resources/wsdl/.../mywebservice.wsdl" is not found in the deployment weblogic.utils.jars.JarFileDelegate@250f95f5 - /data/weblogic/Oracle/products/Oracle_Home/fusion/user_projects/domains/myapp/servers/svc_srv1/tmp/_WL_user/myapp-ear/skp9bk/myapp-2.2.0.1.jar
    at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:114)
    at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:192)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:187)
    at weblogic.application.utils.StateMachineDriver$ParallelChange.run(StateMachineDriver.java:83)
    at weblogic.application.utils.StateMachineDriver.nextStateInParallel(StateMachineDriver.java:144)
    at weblogic.application.internal.flow.ModuleStateDriver.parallelPrepare(ModuleStateDriver.java:46)
    at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:75)
    at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:55)
    at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:729)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
    at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:241)
    at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:66)
    at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
    at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:65)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:229)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:103)
    at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:242)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:800)
    at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1352)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:270)
    at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:186)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:14)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:47)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:670)
    at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:352)
    at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:337)
    at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:57)
    at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
    at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:644)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:415)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:355)
Caused By: weblogic.wsee.ws.WsException: wsdl "classpath:META-INF/resources/wsdl/.../mywebservice.wsdl" is not found in the deployment weblogic.utils.jars.JarFileDelegate@250f95f5 - /data/weblogic/Oracle/products/Oracle_Home/fusion/user_projects/domains/myapp/servers/svc_srv1/tmp/_WL_user/myapp-ear/skp9bk/myapp-2.2.0.1.jar
    at weblogic.wsee.deploy.WSEEEjbModule.loadWsdlDefinitions(WSEEEjbModule.java:176)
    at weblogic.wsee.deploy.WSEEModule.loadWsdl(WSEEModule.java:436)
    at weblogic.wsee.deploy.WSEEAnnotationProcessor.isWsdlHasPolicy(WSEEAnnotationProcessor.java:390)
    at weblogic.wsee.deploy.WSEEAnnotationProcessor.process(WSEEAnnotationProcessor.java:104)
    at weblogic.wsee.deploy.WSEEModule.prepare(WSEEModule.java:124)
    at weblogic.wsee.deploy.WseeEjbModuleExtension.postPrepare(WseeEjbModuleExtension.java:47)
    at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:297)
    at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:285)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
    at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:109)
    at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:192)
    at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:187)
    at weblogic.application.utils.StateMachineDriver$ParallelChange.run(StateMachineDriver.java:83)
    at weblogic.application.utils.StateMachineDriver.nextStateInParallel(StateMachineDriver.java:144)
    at weblogic.application.internal.flow.ModuleStateDriver.parallelPrepare(ModuleStateDriver.java:46)
    at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:75)
    at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:55)
    at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:729)
    at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
    at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:241)
    at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:66)
    at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
    at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:65)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:229)
    at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:103)
    at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:242)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:800)
    at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1352)
    at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:270)
    at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:186)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:14)
    at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:47)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:670)
    at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:352)
    at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:337)
    at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:57)
    at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
    at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:644)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:415)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:355)
> 

It does not find it because is not looking in the right jar. The wsdl file is inside another jar from the lib folder.

myapp.ear
├── lib
├── META-INF
└── myapp-2.2.0.1.jar
anat0lius
  • 2,145
  • 6
  • 33
  • 60
  • Probably it will make no difference, but did you try to prefix your `@WebService` `wsdlLocation` with `classpath:`? I mean, something like: `wsdlLocation = "classpath:META-INF/wsdl/mywebservice.wsdl"`. This prefix is commonly used in the stubs generated by CXF, although usually in `@WebServiceClient`, but it may be of help. – jccampanero May 02 '21 at 18:42
  • @jccampanero I've tried that yes, it throws an error because it doesn't find it. – anat0lius May 03 '21 at 08:13
  • I see. I am sorry to hear that you already tested it and it didn't work. Please, can you include the error stack trace in your question? – jccampanero May 03 '21 at 13:24
  • @jccampanero I 've updated – anat0lius May 04 '21 at 08:09
  • Thank you very much for the feedback @anat0lius. If I understand it correctly, you are using Weblogic, and the problem is that you need to include a value for `wsdlLocation` for your web service in order to schema validation be performed but by doing so WL is unable to deploy your application because it does not find the WSDL resource, isn't it? – jccampanero May 04 '21 at 17:38
  • @jccampanero yes. I want to refactor the way we specify the wsdl. Currently we use an assembly which adds the wsdl files in the root of the main jar. – anat0lius May 04 '21 at 17:44
  • Thank you @anat0lius. Well, sometimes WL... I think you are in a deadlock, because probably the module/feature cannot be disabled and digging into the WL code it seems you are in fact providing a very good solution. How are you configuring your CXF service? I mean, although I understand that mixing different types of configuration is not the best way to proceed, but do you have the ability to [configure CXF](http://cxf.apache.org/faq.html#FAQ-HowcanIturnonschemavalidationforjaxwsendpoint?) using the configuration property `schema-validation-enabled`? – jccampanero May 04 '21 at 17:59
  • In addition, I do not know if it is possible, but probably deploying the application as a war instead of an ear will allow you combine both requirements. – jccampanero May 04 '21 at 18:51
  • The configuration is very simple, like the example https://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html In the `` I also add the `` with the same value as in the service impl. The schema validation is enabled with the `@SchemaValidation` annotation already specified in the service impl. Just to clarify, our application is already in production, the schema validation works as expected. I only want to `refactor` the way the wsdl is referenced. – anat0lius May 04 '21 at 18:52
  • Sorry for the late reply. I understand @anat0lius. Then, in my opinion, your actual solution looks quite good due to the restrictions imposed by the ear loading mechanism of WL. Please, in any way, try the suggested approach of deploying the application as a war file instead of an enterprise application: if you do not have especial requirements related with prefer packages, etcetera, maybe it could be a viable solution. – jccampanero May 05 '21 at 17:52
  • Have you tried moving the wsdl to the more common ```META-INF/wsdl/``` folder without the ```resources```? – Derek S. May 08 '21 at 15:14

0 Answers0