[jira] [Resolved] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-8974. --- Resolution: Not A Problem > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812438#comment-17812438 ] Andriy Redko commented on CXF-8974: --- No problem, please note that CXF 4.0.x officially supports Spring Boot 3.0.x, the upcoming 4.1.0 would support Spring Boot 3.2.x line > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[
https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812412#comment-17812412
]
JohnMTu commented on CXF-8974:
--
4.0.1 seems to be managed by
{code:java}
org.springframework.boot
spring-boot-dependencies
3.2.1 {code}
which is in parents hierarchy of my module.
I just checked 3.0.1 and there seems to be no conflict.
That means, i have to exclude it on my side.
Thanks for hint and sorry for false report.
> remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is
> superset
>
>
> Key: CXF-8974
> URL: https://issues.apache.org/jira/browse/CXF-8974
> Project: CXF
> Issue Type: Improvement
> Components: Build system
>Affects Versions: 4.0.3
>Reporter: JohnMTu
>Priority: Minor
>
> From cxf-rt-bindings-soap i have on classpath
> * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar
> * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar
> containing conflicting classes. Later one seems to be superset of first one.
> Hence i suggest to remove earlier one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
[ https://issues.apache.org/jira/browse/CXF-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812406#comment-17812406 ] Andriy Redko commented on CXF-8974: --- [~johnmtu] the 4.0.3 (and 4.0.x in general) does not import jakarta.xml.ws-api-4.0.1.jar (but 3.0.1 only), could you please share where the dependencies tree? Thank you. [1] https://mvnrepository.com/artifact/org.apache.cxf/cxf-rt-bindings-soap/4.0.3 > remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is > superset > > > Key: CXF-8974 > URL: https://issues.apache.org/jira/browse/CXF-8974 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.3 >Reporter: JohnMTu >Priority: Minor > > From cxf-rt-bindings-soap i have on classpath > * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar > * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar > containing conflicting classes. Later one seems to be superset of first one. > Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8974) remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset
JohnMTu created CXF-8974: Summary: remove jakarta.jws-api-3.0.0 dependency because jakarta.xml.ws-api-4.0.1 is superset Key: CXF-8974 URL: https://issues.apache.org/jira/browse/CXF-8974 Project: CXF Issue Type: Improvement Components: Build system Affects Versions: 4.0.3 Reporter: JohnMTu >From cxf-rt-bindings-soap i have on classpath * jakarta/jws/jakarta.jws-api/3.0.0/jakarta.jws-api-3.0.0.jar * jakarta/xml/ws/jakarta.xml.ws-api/4.0.1/jakarta.xml.ws-api-4.0.1.jar containing conflicting classes. Later one seems to be superset of first one. Hence i suggest to remove earlier one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
[
https://issues.apache.org/jira/browse/CXF-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812317#comment-17812317
]
Andriy Redko commented on CXF-8973:
---
[~cheesemaster] AFAIK this is the intended (and desired) behavior when Apache
CXF is used with Spring Framework: when context shuts down, the registered
beans are destroyed. In this regards, the test does not look right to me - the
JAXRSServerFactoryBean should be a part of the application context (or part of
the parent application context), or alternately use the non-Spring aware Bus
instance in order to not interfere with the test at all.
> NettyHttpServerEngineFactory shuts down all netty instances when
> SpringContext is shutdown
> --
>
> Key: CXF-8973
> URL: https://issues.apache.org/jira/browse/CXF-8973
> Project: CXF
> Issue Type: Bug
>Reporter: Eric
>Priority: Major
>
> {color:#00}NettyHttpServerEngineFactory{color} and
> {color:#00}{color:#00}JettyHttpServerEngineFactory are very similar
> in how they manage their ports and their lifecycle. There seems, however, to
> be minor difference in the Netty...Factory which seems to be the potential
> cause of bugs:
> {color}{color}
> {color:#00}{color:#00}{color:#00}
> {color}{color}{color}
> {code:java}
> class JettyHTTPServerEngineFactory {
> ...
> JettyHTTPServerEngineFactory(Bus bus) {
>setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, JettyHTTPServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(new
> JettyBusLifeCycleListener());
> }
> }
> }
> class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
> ...
> {code}
> {color:#00}{color:#00}vs{color}{color}
>
> {code:java}
> class NettyHttpServerEngineFactory implements BusLifeCycleListener {
> NettyHttpServerEngineFactory (Bus bus) {
> setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, NettyHttpServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(this);
> }
> }
> }
> ...
> {code}
> {color:#00}{color:#00}Both Variants seem to be very similar, however
> there is a subtle difference when it comes to this class:{color}{color}
>
> {code:java}
> class CXFBusLifeCycleManager implements BusLifeCycleManager {
> void initComplete() {
> if (bus != null){
> bus.getExtension(ConfiguredBeanLocator.class)
> .getBeansOfType(BusLifeCycleListener.class);
> }
> ...
> }
> ...
> }{code}
> {color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
> BusLifeCycleListener, it can be found as an Extension in the
> LifeCycleManager, which cause the Constructor with the Bus Parameter to be
> call, which in turn automatically registers the Factory for automatic
> shutdown when a spring context is closed.{color}{color}
>
> {color:#00}{color:#00}This can have unexpected side-effects, when,
> for example in tests, Spring Contexts are created and destroyed on demand and
> combined with indendenpend server instances, like this:
> {color}{color}
> {code:java}
> class TestWithNetty {
> @BeforeAll
> static void setupServer() {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(SomeWebResource.class);
> sf.setAddress("http://localhost:9000;);
> Server server = sf.create();
> }
> @RepeatedTest(2)
> void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
> runner.run(ctx -> // do something with spring context, calling
> localhost:9000);
> }
> }
> {code}
> {color:#00}{color:#00}This scenario, when called with a dependency on
> this works:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-jetty {code}
> {color:#00}{color:#00}That is, since netty is never registered as a
> outside of the beforeblock{color}{color}
>
>
> {color:#00}{color:#00}The same scenario with netty, however
> fails:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-netty-server {code}
> {color:#00}{color:#00}That is the Case because after the first test,
> the spring context is shutdown, which has the side effekt of destroying all
> netty servers, even those which where never managed by spring at all, simply
> because the constructor NettyHttpServerEngineFactory (Bus bus) was implicitly
> called by
[jira] [Commented] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812307#comment-17812307
]
Andriy Redko commented on CXF-8972:
---
[~yoshani] please consult the HTTP 415 status code [1] description, it
describes the server role. Thank you
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/415
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-8972.
---
Resolution: Information Provided
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
[
https://issues.apache.org/jira/browse/CXF-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812269#comment-17812269
]
Eric edited comment on CXF-8973 at 1/30/24 11:14 AM:
-
Shall I provide a PullRequest which changes the NettyServerEngineFactory so
that it matches the JettyServerEngineFactory in that regard?
That means that I simple remove the implements
{color:#00}BusLifeCycleListener-Clause and add an inner class.{color}
was (Author: JIRAUSER293945):
Shall I provide a PullRequest?
> NettyHttpServerEngineFactory shuts down all netty instances when
> SpringContext is shutdown
> --
>
> Key: CXF-8973
> URL: https://issues.apache.org/jira/browse/CXF-8973
> Project: CXF
> Issue Type: Bug
>Reporter: Eric
>Priority: Major
>
> {color:#00}NettyHttpServerEngineFactory{color} and
> {color:#00}{color:#00}JettyHttpServerEngineFactory are very similar
> in how they manage their ports and their lifecycle. There seems, however, to
> be minor difference in the Netty...Factory which seems to be the potential
> cause of bugs:
> {color}{color}
> {color:#00}{color:#00}{color:#00}
> {color}{color}{color}
> {code:java}
> class JettyHTTPServerEngineFactory {
> ...
> JettyHTTPServerEngineFactory(Bus bus) {
>setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, JettyHTTPServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(new
> JettyBusLifeCycleListener());
> }
> }
> }
> class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
> ...
> {code}
> {color:#00}{color:#00}vs{color}{color}
>
> {code:java}
> class NettyHttpServerEngineFactory implements BusLifeCycleListener {
> NettyHttpServerEngineFactory (Bus bus) {
> setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, NettyHttpServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(this);
> }
> }
> }
> ...
> {code}
> {color:#00}{color:#00}Both Variants seem to be very similar, however
> there is a subtle difference when it comes to this class:{color}{color}
>
> {code:java}
> class CXFBusLifeCycleManager implements BusLifeCycleManager {
> void initComplete() {
> if (bus != null){
> bus.getExtension(ConfiguredBeanLocator.class)
> .getBeansOfType(BusLifeCycleListener.class);
> }
> ...
> }
> ...
> }{code}
> {color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
> BusLifeCycleListener, it can be found as an Extension in the
> LifeCycleManager, which cause the Constructor with the Bus Parameter to be
> call, which in turn automatically registers the Factory for automatic
> shutdown when a spring context is closed.{color}{color}
>
> {color:#00}{color:#00}This can have unexpected side-effects, when,
> for example in tests, Spring Contexts are created and destroyed on demand and
> combined with indendenpend server instances, like this:
> {color}{color}
> {code:java}
> class TestWithNetty {
> @BeforeAll
> static void setupServer() {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(SomeWebResource.class);
> sf.setAddress("http://localhost:9000;);
> Server server = sf.create();
> }
> @RepeatedTest(2)
> void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
> runner.run(ctx -> // do something with spring context, calling
> localhost:9000);
> }
> }
> {code}
> {color:#00}{color:#00}This scenario, when called with a dependency on
> this works:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-jetty {code}
> {color:#00}{color:#00}That is, since netty is never registered as a
> outside of the beforeblock{color}{color}
>
>
> {color:#00}{color:#00}The same scenario with netty, however
> fails:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-netty-server {code}
> {color:#00}{color:#00}That is the Case because after the first test,
> the spring context is shutdown, which has the side effekt of destroying all
> netty servers, even those which where never managed by spring at all, simply
> because the constructor NettyHttpServerEngineFactory (Bus bus) was implicitly
> called by .getBeansOfType(BusLifeCycleListener.class), which registered the
> factory in the
[jira] [Created] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
Eric created CXF-8973:
-
Summary: NettyHttpServerEngineFactory shuts down all netty
instances when SpringContext is shutdown
Key: CXF-8973
URL: https://issues.apache.org/jira/browse/CXF-8973
Project: CXF
Issue Type: Bug
Reporter: Eric
{color:#00}NettyHttpServerEngineFactory{color} and
{color:#00}{color:#00}JettyHttpServerEngineFactory are very similar in
how they manage their ports and their lifecycle. There seems, however, to be
minor difference in the Netty...Factory which seems to be the potential cause
of bugs:
{color}{color}
{color:#00}{color:#00}{color:#00}
{color}{color}{color}
{code:java}
class JettyHTTPServerEngineFactory {
...
JettyHTTPServerEngineFactory(Bus bus) {
setBus(bus);
}
void setBus(Bus bus) {
this.bus = bus;
if (bus != null) {
bus.setExtension(this, JettyHTTPServerEngineFactory.class);
lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
if (null != lifeCycleManager) {
lifeCycleManager.registerLifeCycleListener(new
JettyBusLifeCycleListener());
}
}
}
class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
...
{code}
{color:#00}{color:#00}vs{color}{color}
{code:java}
class NettyHttpServerEngineFactory implements BusLifeCycleListener {
NettyHttpServerEngineFactory (Bus bus) {
setBus(bus);
}
void setBus(Bus bus) {
this.bus = bus;
if (bus != null) {
bus.setExtension(this, NettyHttpServerEngineFactory.class);
lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
if (null != lifeCycleManager) {
lifeCycleManager.registerLifeCycleListener(this);
}
}
}
...
{code}
{color:#00}{color:#00}Both Variants seem to be very similar, however
there is a subtle difference when it comes to this class:{color}{color}
{code:java}
class CXFBusLifeCycleManager implements BusLifeCycleManager {
void initComplete() {
if (bus != null){
bus.getExtension(ConfiguredBeanLocator.class)
.getBeansOfType(BusLifeCycleListener.class);
}
...
}
...
}{code}
{color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
BusLifeCycleListener, it can be found as an Extension in the LifeCycleManager,
which cause the Constructor with the Bus Parameter to be call, which in turn
automatically registers the Factory for automatic shutdown when a spring
context is closed.{color}{color}
{color:#00}{color:#00}This can have unexpected side-effects, when, for
example in tests, Spring Contexts are created and destroyed on demand and
combined with indendenpend server instances, like this:
{color}{color}
{code:java}
class TestWithNetty {
@BeforeAll
static void setupServer() {
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(SomeWebResource.class);
sf.setAddress("http://localhost:9000;);
Server server = sf.create();
}
@RepeatedTest(2)
void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
runner.run(ctx -> // do something with spring context, calling
localhost:9000);
}
}
{code}
{color:#00}{color:#00}This scenario, when called with a dependency on
this works:{color}{color}
{code:java}
org.apache.cxf:cxf-rt-transports-http-jetty {code}
{color:#00}{color:#00}That is, since netty is never registered as a
outside of the beforeblock{color}{color}
{color:#00}{color:#00}The same scenario with netty, however
fails:{color}{color}
{code:java}
org.apache.cxf:cxf-rt-transports-http-netty-server {code}
{color:#00}{color:#00}That is the Case because after the first test,
the spring context is shutdown, which has the side effekt of destroying all
netty servers, even those which where never managed by spring at all, simply
because the constructor NettyHttpServerEngineFactory (Bus bus) was implicitly
called by .getBeansOfType(BusLifeCycleListener.class), which registered the
factory in the LifeCycle of the SpringBus{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8973) NettyHttpServerEngineFactory shuts down all netty instances when SpringContext is shutdown
[
https://issues.apache.org/jira/browse/CXF-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812269#comment-17812269
]
Eric commented on CXF-8973:
---
Shall I provide a PullRequest?
> NettyHttpServerEngineFactory shuts down all netty instances when
> SpringContext is shutdown
> --
>
> Key: CXF-8973
> URL: https://issues.apache.org/jira/browse/CXF-8973
> Project: CXF
> Issue Type: Bug
>Reporter: Eric
>Priority: Major
>
> {color:#00}NettyHttpServerEngineFactory{color} and
> {color:#00}{color:#00}JettyHttpServerEngineFactory are very similar
> in how they manage their ports and their lifecycle. There seems, however, to
> be minor difference in the Netty...Factory which seems to be the potential
> cause of bugs:
> {color}{color}
> {color:#00}{color:#00}{color:#00}
> {color}{color}{color}
> {code:java}
> class JettyHTTPServerEngineFactory {
> ...
> JettyHTTPServerEngineFactory(Bus bus) {
>setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, JettyHTTPServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(new
> JettyBusLifeCycleListener());
> }
> }
> }
> class JettyBusLifeCycleListener implements BusLifeCycleListener { ... }
> ...
> {code}
> {color:#00}{color:#00}vs{color}{color}
>
> {code:java}
> class NettyHttpServerEngineFactory implements BusLifeCycleListener {
> NettyHttpServerEngineFactory (Bus bus) {
> setBus(bus);
> }
> void setBus(Bus bus) {
> this.bus = bus;
> if (bus != null) {
> bus.setExtension(this, NettyHttpServerEngineFactory.class);
> lifeCycleManager = bus.getExtension(BusLifeCycleManager.class);
> if (null != lifeCycleManager) {
> lifeCycleManager.registerLifeCycleListener(this);
> }
> }
> }
> ...
> {code}
> {color:#00}{color:#00}Both Variants seem to be very similar, however
> there is a subtle difference when it comes to this class:{color}{color}
>
> {code:java}
> class CXFBusLifeCycleManager implements BusLifeCycleManager {
> void initComplete() {
> if (bus != null){
> bus.getExtension(ConfiguredBeanLocator.class)
> .getBeansOfType(BusLifeCycleListener.class);
> }
> ...
> }
> ...
> }{code}
> {color:#00}{color:#00}Because NettyHttpServerEngineFactory implements
> BusLifeCycleListener, it can be found as an Extension in the
> LifeCycleManager, which cause the Constructor with the Bus Parameter to be
> call, which in turn automatically registers the Factory for automatic
> shutdown when a spring context is closed.{color}{color}
>
> {color:#00}{color:#00}This can have unexpected side-effects, when,
> for example in tests, Spring Contexts are created and destroyed on demand and
> combined with indendenpend server instances, like this:
> {color}{color}
> {code:java}
> class TestWithNetty {
> @BeforeAll
> static void setupServer() {
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(SomeWebResource.class);
> sf.setAddress("http://localhost:9000;);
> Server server = sf.create();
> }
> @RepeatedTest(2)
> void runtTestWithSpringContext(@Autowired ApplicationContextRunner runner) {
> runner.run(ctx -> // do something with spring context, calling
> localhost:9000);
> }
> }
> {code}
> {color:#00}{color:#00}This scenario, when called with a dependency on
> this works:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-jetty {code}
> {color:#00}{color:#00}That is, since netty is never registered as a
> outside of the beforeblock{color}{color}
>
>
> {color:#00}{color:#00}The same scenario with netty, however
> fails:{color}{color}
> {code:java}
> org.apache.cxf:cxf-rt-transports-http-netty-server {code}
> {color:#00}{color:#00}That is the Case because after the first test,
> the spring context is shutdown, which has the side effekt of destroying all
> netty servers, even those which where never managed by spring at all, simply
> because the constructor NettyHttpServerEngineFactory (Bus bus) was implicitly
> called by .getBeansOfType(BusLifeCycleListener.class), which registered the
> factory in the LifeCycle of the SpringBus{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
