[JBossWS] - Re: Use my own WSDL -> Cannot publish WSDL
by jimpo991
The WSDL and the xsd definitions are in structure:
schema/Employee2.xsd - common definitions
schema/TypeDefinitions.xsd - common definitions
wsdl/schema/EmployeeServer.xsd - definitions for employee service types
wsdl/EmployeeService.wsdl - employee service WSDL
I have tried to put these to, and referer to the place in end point interface's wsdlLocation:
1) local file system
2) META-INF/
3) regular web application root
Each time I get the error when jbossws tries to publish the WSDL:
| 14:40:18,709 INFO [JmxKernelAbstraction] persistence.units:ear=soapoc-employeeservice-1.0.ear,jar=employee-ejbs-1.0.jar,unitName=soa_poc_user
| 14:40:18,740 INFO [EJBContainer] STARTED EJB: com.foobar.soapoc.ejb.manager.impl.EmployeeManagerImpl ejbName: EmployeeManagerImpl
| 14:40:18,771 INFO [EJBContainer] STARTED EJB: com.foobar.soapoc.ejb.facade.impl.EmployeeFacadeImpl ejbName: EmployeeFacade
| 14:40:18,787 INFO [EJB3Deployer] Deployed: file:/D:/bz-soa-poc/sandbox/3/jboss-4.2.1.GA/jboss-4.2.1.GA/server/default/tmp/deploy/tmp33208soapoc-employees
| ervice-1.0.ear-contents/employee-ejbs-1.0.jar
| 14:40:18,803 INFO [TomcatDeployer] deploy, ctxPath=/employee-service, warUrl=.../tmp/deploy/tmp33208soapoc-employeeservice-1.0.ear-contents/employee-servi
| ce-1.0-exp.war/
| 14:40:19,209 WARN [PolicyMetaDataBuilder] Cannot get service '{http://www.city.fi/soa-poc/EmployeeServiceWSDL}EmployeeServiceImplService' from the give
| n wsdl definitions! Eventual policies attached to this service won't be considered.
| 14:40:19,490 INFO [WSDLFilePublisher] WSDL published to: file:/D:/bz-soa-poc/sandbox/3/jboss-4.2.1.GA/jboss-4.2.1.GA/server/default/data/wsdl/soapoc-empl
| oyeeservice-1.0.ear/employee-service-1.0.war/EmployeeService.wsdl
| 14:40:19,490 ERROR [MainDeployer] Could not start deployment: file:/D:/bz-soa-poc/sandbox/3/jboss-4.2.1.GA/jboss-4.2.1.GA/server/default/tmp/deploy/tmp332
| 08soapoc-employeeservice-1.0.ear-contents/employee-service-1.0.war
| org.jboss.ws.WSException: Cannot publish wsdl to: D:\bz-soa-poc\sandbox\3\jboss-4.2.1.GA\jboss-4.2.1.GA\server\default\data\wsdl\soapoc-employeeservice-1.
| 0.ear\employee-service-1.0.war\EmployeeService.wsdl
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:143)
| at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52)
| at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:118)
| at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
| at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90)
| at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
| at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy45.start(Unknown Source)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
| at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:258)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:287)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:102)
| at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:77)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.io.IOException: Cannot get URL for: WEB-INF/wsdl/schema/EmployeeService.xsd
| at org.jboss.wsf.common.URLLoaderAdapter.findChild(URLLoaderAdapter.java:106)
| at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:99)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:242)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:130)
| ... 50 more
| 14:40:19,537 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
| java.io.IOException: Cannot get URL for: WEB-INF/wsdl/schema/EmployeeService.xsd
| at org.jboss.wsf.common.URLLoaderAdapter.findChild(URLLoaderAdapter.java:106)
| at org.jboss.wsf.framework.deployment.ArchiveDeploymentImpl.getMetaDataFileURL(ArchiveDeploymentImpl.java:99)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:242)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262)
| at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishSchemaImports(WSDLFilePublisher.java:262)
|
For some reason unknown to me, jbossws seems to think the type definitions should exist under WEB-INF
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163272#4163272
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163272
16 years, 5 months
[JBossWS] - X509 Certificate issuer comparison
by alessio.soldano＠jboss.com
Grant Sheppar says:
anonymous wrote : Hi Alessio,
|
| I'm relatively new to JBoss so I'm not sure whether what I've found is a bug however it seems to be. In the org.jboss.ws.extensions.security.SecurityStore class there is a method getCertificateByIssuerSerial(String issuer, String serial) that attempts to find a X509Certificate based on the given issuer and serial. The method iterates over the stored certificates and compare the issuer and serial given with the issuer and serial from each certificate. The comparison of the issuer (based on the DN of the cert) is a simple string comparison which does not take into account the various formats that a DN can take (see RFC 2253). So if a client sends an issuer DN that is not identical to one stored in a cert then the match fails.
|
| The solution I think would be to take the component parts of the DN and do the comparison based on these individual parts, ignoring any separator characters or extra whitespace.
|
| Hope this makes sense and helps,
|
| Regards,
|
| Grant Sheppard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163199#4163199
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163199
16 years, 5 months
[JBossWS] - SOLUTION! (yeah, for reals)
by tomstrummer
Ok! I was actually able to convert the rpc/encoded WSDL to rpc/literal. So I use my modified WSDL against the service rather than their rpc/encoded one. I realized the response is valid rpc/literal, just with some added xsi:type attributes.
First step: convert the WSDL:
Convert the <soap:body attribute to use="literal" and remove the encodingStyle attribute.
Second step: convert any complexTypes to not extend soapenc:Array:
Any types that use <xs:restriction base="soapenc:Array"> can be changed to this:
For a loosely-typed array (JAXB will map it to a List):
| <xs:complexType name="VariantArray">
| <xs:complexContent>
| <xs:extension base="ns1:GlxNode">
| <xs:sequence>
| <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" />
| </xs:sequence>
| </xs:extension>
| </xs:complexContent>
| </xs:complexType>
|
or for a typed List:
| <xs:complexType name="StringArray">
| <xs:complexContent>
| <xs:extension base="ns1:GlxNode">
| <xs:sequence>
| <xs:element name="String" type="xs:string" minOccurs="0" maxOccurs="unbounded" />
| </xs:sequence>
| </xs:extension>
| </xs:complexContent>
| </xs:complexType>
|
Just chose your own "base" type to extend or just create a new ComplexType.
Note also that I ended up switching to Metro (JAX-WS) 1.2 rather than JBossWS. But using JBossWS as a client seemed to work as well.
This is a bit of a pain but still a hell of a lot better than not being able to consume an RPC/encoded service or being stuck using Axis 1. Hope this helps someone as I couldn't find any other solution in all my searching.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163152#4163152
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163152
16 years, 5 months