You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christopher Richmond <cr...@referentia.com> on 2010/08/24 02:30:27 UTC
fully controllable server instance
Hello,
I have built a simple working endpoint sample based on the HelloWorld
service that starts up fine with the following code in simple Main method.:
System.*out*.println("Starting Server");
HelloWorldImpl implementor = *new* HelloWorldImpl();
String address = "http://localhost:9000/helloWorld";
Endpoint ep = Endpoint.*publish*(address, implementor);
* *
This works just fine and I can access the
http://localhost:9000/helloWorld?wsdl fine from the browser as expected.
Also, when I call:
ep.stop();
That works as expected, with the endpoint no longer being avialable.
However, the jetty server still serves up 404 pages accordingly, when what
I really want is to be able to explicitly control when the underlying server
starts and stops and not merely when enpoints are stopped/published. I am
able to explicitly start and stop the server with the port/address being
completely reachable or unreachable as expected with code like below
Server jetty = *new* *Server*(9000)*;*
*try* {
jetty.start();
System.*err*.println("Jetty running: " + jetty.*isRunning*());
jetty.stop();
System.err.println("*Jetty* stopped: " + jetty.isStopped());
} *catch* (Exception e) {
…
*}*
What I cannot seem to figure out is how to meld the two together. Either
explicitly starting the server as in the jetty snippet and configuring my
endpoints there so that I can explicitly start and stop the entire
server(not just enpoints) or using the first type of example, how to get a
handle on the underlying server to completely stop it and not just the
endpoint(which ep.stop() does).
What am I missing?
Re: fully controllable server instance
Posted by Daniel Kulp <dk...@apache.org>.
You should be able to call:
BusFactory.getDefaultBus().getExtension(JettyHTTPServerEngineFactory.class)
to get the JettyHTTPServerEngineFactory that is in use. There is a
destroyForPort(int) method on there that would shutdown a particular port.
If you want to shutdown EVERYTHING cxf uses, you can do:
BusFactory.getDefaultBus().shutdown()
but that may be complete overkill.
Dan
On Monday 23 August 2010 8:30:27 pm Christopher Richmond wrote:
> Hello,
>
>
>
> I have built a simple working endpoint sample based on the HelloWorld
> service that starts up fine with the following code in simple Main method.:
>
>
>
> System.*out*.println("Starting Server");
>
> HelloWorldImpl implementor = *new* HelloWorldImpl();
>
> String address = "http://localhost:9000/helloWorld";
>
> Endpoint ep = Endpoint.*publish*(address, implementor);
>
>
>
> * *
>
> This works just fine and I can access the
> http://localhost:9000/helloWorld?wsdl fine from the browser as expected.
>
>
>
> Also, when I call:
>
>
>
>
>
> ep.stop();
>
>
>
>
>
> That works as expected, with the endpoint no longer being avialable.
> However, the jetty server still serves up 404 pages accordingly, when what
> I really want is to be able to explicitly control when the underlying
> server starts and stops and not merely when enpoints are
> stopped/published. I am able to explicitly start and stop the server with
> the port/address being completely reachable or unreachable as expected
> with code like below
>
>
>
>
>
> Server jetty = *new* *Server*(9000)*;*
>
> *try* {
>
>
>
> jetty.start();
>
> System.*err*.println("Jetty running: " + jetty.*isRunning*());
>
> jetty.stop();
>
> System.err.println("*Jetty* stopped: " + jetty.isStopped());
>
> } *catch* (Exception e) {
>
> …
>
> *}*
>
>
>
>
>
> What I cannot seem to figure out is how to meld the two together. Either
> explicitly starting the server as in the jetty snippet and configuring my
> endpoints there so that I can explicitly start and stop the entire
> server(not just enpoints) or using the first type of example, how to get a
> handle on the underlying server to completely stop it and not just the
> endpoint(which ep.stop() does).
>
>
>
> What am I missing?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog