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
