Done with the build, needed additional util libraries... There is a jira for this SSL issue ?
On Fri, 2007-25-05 at 15:10 -0400, Dragos Pavel wrote: > Hello again, > > 1) Creating my own binding (using the code snippet mentioned in my > previous email) does help by having a generated wsdl which points to the > correct https location. However after creating and running the related > client it complains about: > "Exception from ServiceClient: Could not invoke service.. Nested > exception is org.codehaus.xfire.fault.XFireFault: Invalid endpoint for > service." > So by creating my own binding (in services.xml) to point to https > doesn't makes xfire to use the https to resolve the correct endpoint. > My only solution therefore is to modify that > org.codehaus.xfire.transport.http.XFireServletTransport to return https. > > Now I'm comming to point 2 (the build): > > 2) the xfire 1.2.6 build points to org.mortbay.jetty-5.1.3.jar > The problem is that in the build there are references to > org.mortbay.component.AbstractLifeCycle and to > org.mortbay.component.LifeCycle > but the source org.mortbay.jetty-5.1.3.jar doesn't contain a "component" > package ! > Beside there are other 4 discrepancies in classes related to the same > source for jetty = org.mortbay.jetty-5.1.3.jar > > It's a library problem. > So I ran into this 6 errors: > compile: > [javac] Compiling 137 source files to /home/dragos/httpslib/xfire- > core/target/classes > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:66: > cannot access org.mortbay.component.AbstractLifeCycle > [javac] file org/mortbay/component/AbstractLifeCycle.class not found > [javac] SslSocketConnector sslConector = new > SslSocketConnector(); > [javac] ^ > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:71: > cannot find symbol > [javac] symbol : method addConnector > (org.mortbay.jetty.security.SslSocketConnector) > [javac] location: class org.mortbay.jetty.Server > [javac] httpServer.addConnector(sslConector); > [javac] ^ > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:77: > cannot access org.mortbay.component.LifeCycle > [javac] file org/mortbay/component/LifeCycle.class not found > [javac] connector.setPort(port); > [javac] ^ > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:78: > cannot find symbol > [javac] symbol : method addConnector(org.mortbay.jetty.Connector) > [javac] location: class org.mortbay.jetty.Server > [javac] httpServer.addConnector(connector); > [javac] ^ > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:84: > cannot find symbol > [javac] symbol : constructor Context > (org.mortbay.jetty.Server,java.lang.String,int) > [javac] location: class org.mortbay.jetty.servlet.Context > [javac] Context context = new Context > (httpServer,"/",Context.SESSIONS); > [javac] ^ > [javac] /home/dragos/httpslib/xfire- > core/src/main/org/codehaus/xfire/server/http/XFireHttpServer.java:88: > cannot find symbol > [javac] symbol : constructor ServletHolder > (org.codehaus.xfire.transport.http.XFireServlet) > [javac] location: class org.mortbay.jetty.servlet.ServletHolder > [javac] ServletHolder servlet = new ServletHolder(new > XFireServlet()); > [javac] ^ > [javac] 6 errors > > Anybody any idea ? Over HTTP my service is working fine; I have this > HTTPS problem to solve. > > > > > > On Thu, 2007-24-05 at 17:58 -0400, Dragos Pavel wrote: > > By trying to do this in the services.xml config: > > > > <createDefaultBindings>false</createDefaultBindings> > > <bindings xmlns:e="https://acompany.com/";> > > <soap11Binding name="e:serviceSoap11Binding" > > transport="http://schemas.xmlsoap.org/soap/http"; > > allowUndefinedEndpoints="true"> > > <endpoints> > > <endpoint name="e:serviceHttpPort" > > url="https://test.dynadocs.com/ws/energy/lixarinterface/service"; /> > > </endpoints> > > </soap11Binding> > > </bindings> > > > > One can create his own bindings pointing to https for endpoint > > location ??? I have the https for location in wsdl after this change in > > services.xml config but I still can't validate the generated wsdl. > > > > The 'serviceHttpPort' has an invalid binding - 'serviceSoap11Binding'. > > Check that the 'serviceSoap11Binding' binding is defined. > > > > What's the correct way to this binding configuration ? Sorry but the man > > pages are not very helpful. Any hint will be welcomed. > > > > Thanks in advance. > > > > > > > > On Thu, 2007-24-05 at 17:51 -0400, Dragos Pavel wrote: > > > OK I modified the class and I'm using the build "all" target provided in > > > the build.xml How can one build the XFire source code successfully? > > > I run into this dependency and I get errors getting the related jar libs > > > from Error getting http://www.ibiblio.org/maven/..... > > > > > > Buildfile: build.xml > > > > > > build-all: > > > > > > init: > > > > > > setproxy: > > > > > > xfire.get-deps: > > > [mkdir] Created dir: /home/dragos/httpslib/target/lib > > > [mkdir] Created dir: /home/dragos/httpslib/xfire-core/target/lib > > > > > > -download-dep: > > > [get] Getting: http://www.ibiblio.org/maven/geronimo- > > > spec/jars/geronimo-spec-activation-1.0.2-rc4.jar > > > [get] To: /home/dragos/httpslib/target/lib/geronimo-spec- > > > activation-1.0.2-rc4.jar > > > [get] Error getting http://www.ibiblio.org/maven/geronimo- > > > spec/jars/geronimo-spec-activation-1.0.2-rc4.jar > > > to /home/dragos/httpslib/target/lib/geronimo-spec-activation-1.0.2- > > > rc4.jar > > > > > > -download-dep: > > > [get] Getting: http://www.ibiblio.org/maven/woodstox/jars/wstx- > > > asl-3.0.1.jar > > > [get] To: /home/dragos/httpslib/target/lib/wstx-asl-3.0.1.jar > > > [get] Error getting > > > http://www.ibiblio.org/maven/woodstox/jars/wstx-asl-3.0.1.jar > > > to /home/dragos/httpslib/target/lib/wstx-asl-3.0.1.jar > > > > > > -download-dep: > > > [get] Getting: > > > http://www.ibiblio.org/maven/stax/jars/stax-1.2.0.jar > > > [get] To: /home/dragos/httpslib/target/lib/stax-1.2.0.jar > > > [get] Error getting > > > http://www.ibiblio.org/maven/stax/jars/stax-1.2.0.jar > > > to /home/dragos/httpslib/target/lib/stax-1.2.0.jar > > > > > > -download-dep: > > > [get] Getting: http://www.ibiblio.org/maven/stax/jars/stax- > > > api-1.0.1.jar > > > [get] To: /home/dragos/httpslib/target/lib/stax-api-1.0.1.jar > > > [get] Error getting http://www.ibiblio.org/maven/stax/jars/stax- > > > api-1.0.1.jar to /home/dragos/httpslib/target/lib/stax-api-1.0.1.jar > > > > > > -download-dep: > > > [get] Getting: http://www.ibiblio.org/maven/jdom/jars/jdom-1.0.jar > > > [get] To: /home/dragos/httpslib/target/lib/jdom-1.0.jar > > > [get] Error getting > > > http://www.ibiblio.org/maven/jdom/jars/jdom-1.0.jar > > > to /home/dragos/httpslib/target/lib/jdom-1.0.jar > > > > > > ......... > > > > > > > > > My proxy is configured right. > > > > > > > > > Yes, I observed the retrieve work you do in the handler Yeogesh, > > > I understand better now. Thanks. > > > > > > Suggestions for the HTTPS issue much appreciated, or for the build. > > > > > > > > > On Thu, 2007-24-05 at 10:58 -0700, Yogesh Chawla - PD wrote: > > > > Hi Dragos, > > > > We have the users generate their clients from the WSDL > > > > and when they hit the service they require a client > > > > certficate. > > > > > > > > During run time, the clients don't actually need the > > > > WSDL and the service doesn't need it either. All of > > > > the HTTPS mutual authentication is handled by the > > > > application server. > > > > > > > > I did write an input handler to my service which > > > > retrieves the certificate out of the HTTP Header and > > > > double checks it. I also match the common name in the > > > > certificate with different access levels in the app. > > > > > > > > Let me know if you are interested in any of this. > > > > > > > > Thanks, > > > > Yogesh > > > > > > > > --- Dragos Pavel <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Yogesh, > > > > > > > > > > Thank you very much for your answer. > > > > > I like your solution but unfortunately is not > > > > > applicable in my case. > > > > > In my environment the client has a certificate, the > > > > > handshake is done on > > > > > the server etc; in your case probably you need human > > > > > interaction from > > > > > your clients in order to accept the certificate when > > > > > they are prompted > > > > > for that. > > > > > > > > > > Does somebody successfully created his own bindings > > > > > in the wsdl ( by > > > > > using > > > > > <createDefaultBindings>false</createDefaultBindings> > > > > > ...) ? > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > On Wed, 2007-23-05 at 20:16 -0700, Yogesh Chawla - > > > > > PD wrote: > > > > > > Hi Dragos, > > > > > > The specific situation I had was this. My service > > > > > was > > > > > > secured using HTTPS and Client Certificates. I > > > > > didn't > > > > > > want my service consumers to need a certificate > > > > > just > > > > > > to see the WSDL. > > > > > > > > > > > > We took the WSDL generated by xfire and did a view > > > > > > source on it. I copied what was there and > > > > > modified > > > > > > the WSDL and exposed in an unsecured part of the > > > > > web > > > > > > site (a page that did not require a client > > > > > > certificate). > > > > > > > > > > > > In our example, the application server tomcat was > > > > > > handling the HTTPS connection so the endpoint in > > > > > the > > > > > > WSDL could be modified without affecting any of > > > > > the > > > > > > actual data types in the schema. > > > > > > > > > > > > As a general observation, the WSDLs generated > > > > > doing > > > > > > code first development are not the nicest looking. > > > > > We > > > > > > do code first development using XMLBeans but write > > > > > the > > > > > > WSDLs by hand for ease of human readability. Once > > > > > > such WSDL can be found here: > > > > > > > > > > > > > > > > > > > > > http://wijis.wisconsin.gov/wsdl/PointerCountService.wsdl > > > > > > > > > > > > We can easily change this part of the WSDL if the > > > > > port > > > > > > or server name changes with minimal impact: > > > > > > > > > > > > <wsdl:service name="PointerCountService"> > > > > > > <wsdl:port binding="tns:PointerCountServiceSOAP" > > > > > > name="PointerCountServiceSOAP"> > > > > > > <soap:address > > > > > > > > > > > > > > > location="https://wijis.wisconsin.gov:17444/xfire/PointerCount"; > > > > > > /> > > > > > > </wsdl:port> > > > > > > </wsdl:service> > > > > > > > > > > > > Dragos, I am not sure how much help this because > > > > > we > > > > > > might have slightly different situations but > > > > > hopefully > > > > > > this example will help you find your solution. > > > > > > > > > > > > Cheers, > > > > > > Yogesh > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe from this list please visit: > > > > > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe from this list please visit: > > > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe from this list please visit: > > > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this list please visit: > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
