Hi Glynn
On 10/04/12 11:55, Glyn Normington wrote:
Hi Sergey
On 5 Apr 2012, at 16:51, Sergey Beryozkin wrote:
Hi Glyn
On 05/04/12 18:39, Glyn Normington wrote:
I thought I'd try running CXF distributed OSGi on Eclipse Virgo and got it
working painlessly, so thanks for some nice documentation!
However, I did notice an issue with the greeter demo. If I stop (or even
uninstall) the greeter impl, the remote service is still remotely invokable. I
guess the service object is cached inside CXF, but can someone confirm this is
working as designed?
Indirectly yes, when the endpoint is created,
But when I stopped the CXF bundle, the remote service was again still
invokable, so it seems that the CXF stop doesn't cleanly terminate the
underlying Jetty instance. Perhaps this is due to a NPE I observed:
This should've caused a CXF server stopping AFAIK
Daemon Thread [Thread-34] (Suspended (exception NullPointerException))
ConfigurationManager.stop(BundleContext) line: 267
AggregatedActivator.stopEmbeddedActivators(BundleContext) line: 137
AggregatedActivator.stop(BundleContext) line: 51
BundleContextImpl$2.run() line: 771
AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not
available [native method]
BundleContextImpl.stop() line: 764
BundleHost.stopWorker(int) line: 510
BundleHost(AbstractBundle).stop(int) line: 464
Basic.stop(boolean, Bundle[]) line: 817
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
Reflective.method(CommandSession, Object, String, List<Object>) line:
136
CommandProxy.execute(CommandSession, List<Object>) line: 82
Closure.executeCmd(String, List<Object>) line: 469
Closure.executeStatement(List<Token>) line: 395
Pipe.run() line: 108
Closure.execute(List<Object>) line: 183
Closure.execute(CommandSession, List<Object>) line: 120
CommandSessionImpl.execute(CharSequence) line: 89
Console.run() line: 62
Shell.console(CommandSession) line: 203
Shell.gosh(CommandSession, String[]) line: 128
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
Reflective.method(CommandSession, Object, String, List<Object>) line:
136
CommandProxy.execute(CommandSession, List<Object>) line: 82
Closure.executeCmd(String, List<Object>) line: 469
Closure.executeStatement(List<Token>) line: 395
Pipe.run() line: 108
Closure.execute(List<Object>) line: 183
Closure.execute(CommandSession, List<Object>) line: 120
CommandSessionImpl.execute(CharSequence) line: 89
TelnetConnection.run() line: 94
Should I raise a bug on this NPE?
Please do
After more digging, it looks like the NPE is probably fixed by
https://issues.apache.org/jira/browse/FELIX-2813 in Felix config admin 1.4.0.
So I raised the this bug to cover the upgrade:
https://issues.apache.org/jira/browse/DOSGI-117
I can not see 1.4.0 in Central
Any ideas whether this really is the cause of the remote service continuing to
run after CXF is stopped?
Not really :-)
The AggregatedActivator.stopEmbeddedActivators method (below) doesn't have any
exception handling, so the above NPE will abort the loop. Since this is stop
processing, would it make sense to catch/log exceptions and continue the loop?
void stopEmbeddedActivators(BundleContext ctx) throws Exception {
for (BundleActivator ba : activators) {
ba.stop(ctx);
}
}
Sure, fixed on the trunk
Thanks, Sergey
Environment:
CXF single bundle distribution 1.3.0
ZooKeeper 3.4.3
java version "1.6.0_29"
Mac OS X 10.7.3
Regards,
Glyn
PS. I am about to go off for Easter, so I apologise in advance for not being
able to handle any response before Tuesday.
Enjoy :-)
FYI, ideally a patch would be provided to get a speedy resolution to this
issue, the reported issues will be reviewed and as many as realistically
possible will be resolved in time for the next release, but having a patch
submitted is definitely the fastest way to get it resolved :-)
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Regards,
Glyn
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com