You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Urppa <pe...@insta.fi> on 2012/11/28 08:31:07 UTC
Releasing CXF-endpoint port on context shutdown
I have a programmatic CamelContext and route configuration inside an
OSGi-bundle that I deploy on Karaf 2.3.0. There are no Blueprint/Spring
XML-files, this is all done programmatically because I need some
programmatic stuff before the route setup.
The route has a CXF-endpoint offering a SOAP-webservice on port 9000. The
configuration is activated on my Activators start-method and works just
fine, i.e. I can get the WSDL and call the WS-methods once the route is
active after I drop the bundle into the Karafs deploy-folder.
When I remove the bundle from the Karafs deploy-folder, the bundle is
stopped properly and on the activator.stop-method I have the
camelContext-shutdown-call. And looking at the log output, the camelContext
is shutdown and the route is removed gracefully. Also on port 9000 I start
getting error from Jetty and can't access the WSDL-anymore, hence my route
is gone (but note that Jetty is still running on port 9000...).
So, now port 9000 is still reserved on the Karaf-java process. And if I
restart the bundle, the same route gets added again and I get some second
port 9000 (looking at netstat -a) that has connection to my computer on some
50xxx port. And if I remove the bundle and then deploy it again, AGAIN the
port 9000 gets some connection to some 5xxxx port.
How to gracefully release port 9000 when the CamelContext and route is
shutdown? I looked at the CxfEndpoint-class, doStop method and it only has a
comment // noop... Is this the issue, or am I looking at wrong place at the
code wrt shutdown of the CXF-endpoint?
--
View this message in context: http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: Releasing CXF-endpoint port on context shutdown
Posted by Urppa <pe...@insta.fi>.
Ok, I don't think shutting down Jetty is necessary, I don't need to release the port 9000 necessarily when the route is shutdown. However, how do I get 2nd or 3rd activation of the route work properly when Jetty is up already?
Now it works so that only the first activation of the route makes my endpoint available behind port 9000 properly. All route activations after that won't bring the endpoint up on the same URI as the first time. On the log all look ok, but I can't get the WSDL from the same endpoint as I could after the first activation.
- Petri
________________________________
From: Willem.Jiang [via Camel] [mailto:ml-node+s465427n5723335h68@n5.nabble.com]
Sent: 28. marraskuuta 2012 10:24
To: Riipinen Petri
Subject: Re: Releasing CXF-endpoint port on context shutdown
We don't shutdown the Jetty engine when the bundle is stop, as we are using CXF bus to manage the life cycle of the Jetty engine.
If you are using Spring or Blueprint, they can take care of the bus shutdown issue.
But if you create the CamelContext by yourself, you need to manage the bus which camel-cxf component is used by yourself.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: willemjiang
On Wednesday, November 28, 2012 at 3:31 PM, Urppa wrote:
> I have a programmatic CamelContext and route configuration inside an
> OSGi-bundle that I deploy on Karaf 2.3.0. There are no Blueprint/Spring
> XML-files, this is all done programmatically because I need some
> programmatic stuff before the route setup.
>
> The route has a CXF-endpoint offering a SOAP-webservice on port 9000. The
> configuration is activated on my Activators start-method and works just
> fine, i.e. I can get the WSDL and call the WS-methods once the route is
> active after I drop the bundle into the Karafs deploy-folder.
>
> When I remove the bundle from the Karafs deploy-folder, the bundle is
> stopped properly and on the activator.stop-method I have the
> camelContext-shutdown-call. And looking at the log output, the camelContext
> is shutdown and the route is removed gracefully. Also on port 9000 I start
> getting error from Jetty and can't access the WSDL-anymore, hence my route
> is gone (but note that Jetty is still running on port 9000...).
>
> So, now port 9000 is still reserved on the Karaf-java process. And if I
> restart the bundle, the same route gets added again and I get some second
> port 9000 (looking at netstat -a) that has connection to my computer on some
> 50xxx port. And if I remove the bundle and then deploy it again, AGAIN the
> port 9000 gets some connection to some 5xxxx port.
>
> How to gracefully release port 9000 when the CamelContext and route is
> shutdown? I looked at the CxfEndpoint-class, doStop method and it only has a
> comment // noop... Is this the issue, or am I looking at wrong place at the
> code wrt shutdown of the CXF-endpoint?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329.html
> Sent from the Camel - Users mailing list archive at Nabble.com (http://Nabble.com).
________________________________
If you reply to this email, your message will be added to the discussion below:
http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329p5723335.html
To unsubscribe from Releasing CXF-endpoint port on context shutdown, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5723329&code=cGV0cmkucmlpcGluZW5AaW5zdGEuZml8NTcyMzMyOXw1OTU2OTkzMzg=>.
NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329p5723337.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: Releasing CXF-endpoint port on context shutdown
Posted by Urppa <pe...@insta.fi>.
Hello,
Ok, I got an error in the Karaf-log once I try to get the WSDL the second
time.
So when I deploy my bundle into deploy-folder I can get the WSDL with: http:
// localhost:9000/cisif?WSDL
But then I remove the bundle, wait a while and then deploy it again and then
try to get the WSDL with the same URL, I just get an exception from the
service and the following exception/stack trace appears into the log.
Does this give you any ideas about the possible problem? Am I missing some
dependency or something like that? (On my setup I have Karaf 2.3.0 and I’ve
installed CXF, ActiveMQ and camel-features)
2012-11-28 11:50:50,290 | WARN | 34 - /cisif?wsdl | PhaseInterceptorChain
| ache.cxf.common.logging.LogUtils 405 | 144 - org.apache.cxf.cxf-api -
2.7.0 | Interceptor for {http://www.insta.fi/cis}CISQueryServiceService has
thrown exception, unwinding now
org.apache.cxf.frontend.WSDLQueryException: Exception occurred while trying
to process http://localhost:9000/cisif
at
org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:265)[152:org.apache.cxf.cxf-rt-frontend-simple:2.7.0]
at
org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:158)[152:org.apache.cxf.cxf-rt-frontend-simple:2.7.0]
at
org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:110)[152:org.apache.cxf.cxf-rt-frontend-simple:2.7.0]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)[144:org.apache.cxf.cxf-api:2.7.0]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[144:org.apache.cxf.cxf-api:2.7.0]
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:354)[165:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.0]
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:318)[165:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.0]
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)[165:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.0]
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1040)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:976)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.Server.handle(Server.java:359)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)[60:org.eclipse.jetty.http:7.6.7.v20120910]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[60:org.eclipse.jetty.http:7.6.7.v20120910]
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[64:org.eclipse.jetty.server:7.6.7.v20120910]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)[59:org.eclipse.jetty.io:7.6.7.v20120910]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)[59:org.eclipse.jetty.io:7.6.7.v20120910]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[58:org.eclipse.jetty.util:7.6.7.v20120910]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[58:org.eclipse.jetty.util:7.6.7.v20120910]
at
java.lang.Thread.run(Thread.java:722)[:1.7.0_07]
Caused by: org.apache.cxf.bus.extension.ExtensionException: Could not create
object of extension class org.apache.cxf.catalog.OASISCatalogManager.
at
org.apache.cxf.bus.extension.Extension.load(Extension.java:222)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:199)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.bus.extension.ExtensionManagerImpl.getBeansOfType(ExtensionManagerImpl.java:303)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.bus.osgi.OSGiBeanLocator.getBeansOfType(OSGiBeanLocator.java:45)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.bus.CXFBusImpl.getExtension(CXFBusImpl.java:99)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.catalog.OASISCatalogManager.getCatalogManager(OASISCatalogManager.java:187)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.frontend.WSDLGetUtils.updateDefinition(WSDLGetUtils.java:384)[152:org.apache.cxf.cxf-rt-frontend-simple:2.7.0]
at
org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:189)[152:org.apache.cxf.cxf-rt-frontend-simple:2.7.0]
... 24 more
Caused by: java.lang.NullPointerException
at
org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:512)
at
org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1127)
at
org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1037)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1778)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:144)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:133)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
org.apache.cxf.catalog.OASISCatalogManager.<init>(OASISCatalogManager.java:73)[145:org.apache.cxf.cxf-rt-core:2.7.0]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_07]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_07]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_07]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:525)[:1.7.0_07]
at
org.apache.cxf.bus.extension.Extension.load(Extension.java:199)[145:org.apache.cxf.cxf-rt-core:2.7.0]
... 31 more
--
View this message in context: http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329p5723345.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Releasing CXF-endpoint port on context shutdown
Posted by Willem jiang <wi...@gmail.com>.
We don't shutdown the Jetty engine when the bundle is stop, as we are using CXF bus to manage the life cycle of the Jetty engine.
If you are using Spring or Blueprint, they can take care of the bus shutdown issue.
But if you create the CamelContext by yourself, you need to manage the bus which camel-cxf component is used by yourself.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: willemjiang
On Wednesday, November 28, 2012 at 3:31 PM, Urppa wrote:
> I have a programmatic CamelContext and route configuration inside an
> OSGi-bundle that I deploy on Karaf 2.3.0. There are no Blueprint/Spring
> XML-files, this is all done programmatically because I need some
> programmatic stuff before the route setup.
>
> The route has a CXF-endpoint offering a SOAP-webservice on port 9000. The
> configuration is activated on my Activators start-method and works just
> fine, i.e. I can get the WSDL and call the WS-methods once the route is
> active after I drop the bundle into the Karafs deploy-folder.
>
> When I remove the bundle from the Karafs deploy-folder, the bundle is
> stopped properly and on the activator.stop-method I have the
> camelContext-shutdown-call. And looking at the log output, the camelContext
> is shutdown and the route is removed gracefully. Also on port 9000 I start
> getting error from Jetty and can't access the WSDL-anymore, hence my route
> is gone (but note that Jetty is still running on port 9000...).
>
> So, now port 9000 is still reserved on the Karaf-java process. And if I
> restart the bundle, the same route gets added again and I get some second
> port 9000 (looking at netstat -a) that has connection to my computer on some
> 50xxx port. And if I remove the bundle and then deploy it again, AGAIN the
> port 9000 gets some connection to some 5xxxx port.
>
> How to gracefully release port 9000 when the CamelContext and route is
> shutdown? I looked at the CxfEndpoint-class, doStop method and it only has a
> comment // noop... Is this the issue, or am I looking at wrong place at the
> code wrt shutdown of the CXF-endpoint?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Releasing-CXF-endpoint-port-on-context-shutdown-tp5723329.html
> Sent from the Camel - Users mailing list archive at Nabble.com (http://Nabble.com).