[jira] [Created] (CXF-8958) A migration Guide for CXF-DOSGI Users
Mehmet Can Cömert created CXF-8958:
--
Summary: A migration Guide for CXF-DOSGI Users
Key: CXF-8958
URL: https://issues.apache.org/jira/browse/CXF-8958
Project: CXF
Issue Type: Wish
Reporter: Mehmet Can Cömert
As I noticed, CXF-DOSGI project is retired in the middle of 2022.
We have a big REST API implementation relying on this framework.
Now we want to update other components such as Jetty and they need newer
version of Javax.Servlet-API (4.0.0 or above) however DOSGI components seems to
request older Javax.Servlet-API (from 2.0.0 until 4.0.0)
We do not need to provide REST API resources as OSGI services, but they still
need to consume OSGI Services from the Business Logic layer.
A resource definition is done in an interface and implementation done in
another class with the help of DOSGI Intents and calling OSGI Services.
Here is the API for Resource definition in an API Bundle:
{code:java}
@Path("")
public interface IJobStatusResource {
@GET
@Produces({MediaType.APPLICATION_JSON})
Response getJobStatusEntries(@Context UriInfo uriInfo,
@QueryParam(IFieldKeys.IDENTIFIER) String
identifier)
throws RestApiException;
}
{code}
Here is the implementation exposing the Resource over OSGI and supplying the
DOSGI Intents provider for HTML/JSON serialization.
{code:java}
import org.apache.cxf.dosgi.common.api.IntentsProvider;
@Component(name = "JobStatusConfigurationResource", immediate = true, //
service = {
IJobStatusResource.class, IntentsProvider.class
}, property = {
"service.exported.configs=org.apache.cxf.rs", //
"service.exported.interfaces=*", //
"org.apache.cxf.rs.address=" +
IRestResourcePaths.JOB_STATUS_ENTRIES_PATH, //
"org.apache.cxf.rs.provider.expected=true", //
})
@ServiceDescription("JobStatus Configuration Resouce DOSGI implementation.")
public class JobStatusResource implements IJobStatusResource, IntentsProvider {
@Reference(name = "jobstatus.service.ref", //
policy = ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.MANDATORY, //
bind = "registerConnector", unbind = "unregisterConnector")
public void registerConnector(IJobStatusService jobStatusService) {
service = jobStatusService;
} public void unregisterConnector(IJobStatusService jobStatusService) {
service = null;
} @Reference(name = "jobstatus.intent.service.ref", //
policy = ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.MANDATORY, //
bind = "registerIntentFactory", unbind = "unregisterIntentFactory")
public void registerIntentFactory(IIntentFactory intentFactory) {
intentFactoryService = intentFactory;
} public void unregisterIntentFactory(IIntentFactory intentFactory) {
intentFactoryService = null;
} @Override
public Response getJobStatusEntries(UriInfo uriInfo, String id) throws
RestApiException {
// use Service from osgi to call business logic. } @Override
public List< ? > getIntents() {
return intentFactoryService.createDefaultIntents();
}} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8958) A migration Guide for CXF-DOSGI Users
[
https://issues.apache.org/jira/browse/CXF-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mehmet Can Cömert updated CXF-8958:
---
Description:
As I noticed, CXF-DOSGI project is retired in the middle of 2022.
We have a big REST API implementation relying on this framework.
Now we want to update other components such as Jetty and they need newer
version of Javax.Servlet-API (4.0.0 or above) however DOSGI components seems to
request older Javax.Servlet-API (from 2.0.0 until 4.0.0)
We do not need to provide REST API resources as OSGI services, but they still
need to consume OSGI Services from the Business Logic layer.
A resource definition is done in an interface and implementation done in
another class with the help of DOSGI Intents and calling OSGI Services.
Here is the API for Resource definition in an API Bundle:
{code:java}
@Path("")
public interface IJobStatusResource {
@GET
@Produces({MediaType.APPLICATION_JSON})
Response getJobStatusEntries(@Context UriInfo uriInfo,
@QueryParam(IFieldKeys.IDENTIFIER) String
identifier)
throws RestApiException;
}
{code}
Here is the implementation exposing the Resource over OSGI and supplying the
DOSGI Intents provider for HTML/JSON serialization.
{code:java}
import org.apache.cxf.dosgi.common.api.IntentsProvider;
@Component(name = "JobStatusConfigurationResource", immediate = true, //
service = {
IJobStatusResource.class, IntentsProvider.class
}, property = {
"service.exported.configs=org.apache.cxf.rs", //
"service.exported.interfaces=*", //
"org.apache.cxf.rs.address=" +
IRestResourcePaths.JOB_STATUS_ENTRIES_PATH, //
"org.apache.cxf.rs.provider.expected=true", //
})
public class JobStatusResource implements IJobStatusResource, IntentsProvider {
@Reference(name = "jobstatus.service.ref", //
policy = ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.MANDATORY, //
bind = "registerConnector", unbind = "unregisterConnector")
public void registerConnector(IJobStatusService jobStatusService) {
service = jobStatusService;
}
public void unregisterConnector(IJobStatusService jobStatusService) {
service = null;
}
@Reference(name = "jobstatus.intent.service.ref", //
policy = ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.MANDATORY, //
bind = "registerIntentFactory", unbind = "unregisterIntentFactory")
public void registerIntentFactory(IIntentFactory intentFactory) {
intentFactoryService = intentFactory;
}
public void unregisterIntentFactory(IIntentFactory intentFactory) {
intentFactoryService = null;
}
@Override
public Response getJobStatusEntries(UriInfo uriInfo, String id) throws
RestApiException {
// use Service from OSGI to call business logic.
}
@Override
public List< ? > getIntents() {
return intentFactoryService.createDefaultIntents();
}
}{code}
Any help or documentation would be very nice to switch resources without DOSGI
dependencies.
was:
As I noticed, CXF-DOSGI project is retired in the middle of 2022.
We have a big REST API implementation relying on this framework.
Now we want to update other components such as Jetty and they need newer
version of Javax.Servlet-API (4.0.0 or above) however DOSGI components seems to
request older Javax.Servlet-API (from 2.0.0 until 4.0.0)
We do not need to provide REST API resources as OSGI services, but they still
need to consume OSGI Services from the Business Logic layer.
A resource definition is done in an interface and implementation done in
another class with the help of DOSGI Intents and calling OSGI Services.
Here is the API for Resource definition in an API Bundle:
{code:java}
@Path("")
public interface IJobStatusResource {
@GET
@Produces({MediaType.APPLICATION_JSON})
Response getJobStatusEntries(@Context UriInfo uriInfo,
@QueryParam(IFieldKeys.IDENTIFIER) String
identifier)
throws RestApiException;
}
{code}
Here is the implementation exposing the Resource over OSGI and supplying the
DOSGI Intents provider for HTML/JSON serialization.
{code:java}
import org.apache.cxf.dosgi.common.api.IntentsProvider;
@Component(name = "JobStatusConfigurationResource", immediate = true, //
service = {
IJobStatusResource.class, IntentsProvider.class
}, property = {
"service.exported.configs=org.apache.cxf.rs", //
"service.exported.interfaces=*", //
"org.apache.cxf.rs.address=" +
IRestResourcePaths.JOB_STATUS_ENTRIES_PATH, //
"org.apache.cxf.rs.provider.expected=true", //
})
@ServiceDescription("JobStatus Configuration Resouce DOSGI implementation.")
public class JobStatusResource implements IJobStatusResource, IntentsProvider {
@
[jira] [Created] (CXF-8959) Detect order dependent flakiness in AttachmentUtilTest.java in core module
Ruby created CXF-8959: - Summary: Detect order dependent flakiness in AttachmentUtilTest.java in core module Key: CXF-8959 URL: https://issues.apache.org/jira/browse/CXF-8959 Project: CXF Issue Type: Bug Reporter: Ruby The order dependent flakiness was detected when running multiple test classes. The polluter that caused the flakiness in AttachmentUtilTest.java was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there were multiple tests that used Mockito.spy() to verify the behavior of CachedOutputStream object. In those tests, the spy CachedOutputStream object "cos" was generate (CachedOutputStream cos = spy(CachedOutputStream.class)). Then after this, there was a line verify(cos).setThreshold(102400L). Therefore, after the cos being initialized, we need to make sure the setThreshold has been called once. However, it doens't execute as expected, and the root cause is that the threshold is not provided when calleing testSetStreamedAttachmentProperties() method and the thresholdSysPropSet, the boolean that indicated whether the default threshold has been set or not, has been set to true when we run the CachedOutputStreamTest.java. Inside the CachedOutputStreamTest.java, the unit test testUseSysPropsWithAttachmentDeserializer() called the AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the thresholdSysPropSet has been set to true. Therefore, if we run CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the verify(cos).setThreshold(102400L) statement will lead to the error message Wanted but not invoked: cachedOutputStream.setThreshold(102400L); -> at org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8959) Detect order dependent flakiness in AttachmentUtilTest.java in core module
[ https://issues.apache.org/jira/browse/CXF-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruby updated CXF-8959: -- Description: The order dependent flakiness was detected when running multiple test classes. The polluter that caused the flakiness in AttachmentUtilTest.java was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there were multiple tests that used Mockito.spy() to verify the behavior of CachedOutputStream object. In those tests, the spy CachedOutputStream object "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). Then after this, there was a line verify(cos).setThreshold(102400L). Therefore, after the cos being initialized, we need to make sure the setThreshold has been called once. However, it doens't execute as expected, and the root cause is that the threshold is not provided when calling testSetStreamedAttachmentProperties() method and the thresholdSysPropSet, the boolean that indicated whether the default threshold has been set or not, has been set to true when we run the CachedOutputStreamTest.java. Inside the CachedOutputStreamTest.java, the unit test testUseSysPropsWithAttachmentDeserializer() called the AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the thresholdSysPropSet has been set to true. Therefore, if we run CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the verify(cos).setThreshold(102400L) statement will lead to the error message Wanted but not invoked: cachedOutputStream.setThreshold(102400L); -> at org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) was: The order dependent flakiness was detected when running multiple test classes. The polluter that caused the flakiness in AttachmentUtilTest.java was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there were multiple tests that used Mockito.spy() to verify the behavior of CachedOutputStream object. In those tests, the spy CachedOutputStream object "cos" was generate (CachedOutputStream cos = spy(CachedOutputStream.class)). Then after this, there was a line verify(cos).setThreshold(102400L). Therefore, after the cos being initialized, we need to make sure the setThreshold has been called once. However, it doens't execute as expected, and the root cause is that the threshold is not provided when calleing testSetStreamedAttachmentProperties() method and the thresholdSysPropSet, the boolean that indicated whether the default threshold has been set or not, has been set to true when we run the CachedOutputStreamTest.java. Inside the CachedOutputStreamTest.java, the unit test testUseSysPropsWithAttachmentDeserializer() called the AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the thresholdSysPropSet has been set to true. Therefore, if we run CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the verify(cos).setThreshold(102400L) statement will lead to the error message Wanted but not invoked: cachedOutputStream.setThreshold(102400L); -> at org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) > Detect order dependent flakiness in AttachmentUtilTest.java in core module > -- > > Key: CXF-8959 > URL: https://issues.apache.org/jira/browse/CXF-8959 > Project: CXF > Issue Type: Bug >Reporter: Ruby >Priority: Minor > > The order dependent flakiness was detected when running multiple test > classes. The polluter that caused the flakiness in AttachmentUtilTest.java > was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there > were multiple tests that used Mockito.spy() to verify the behavior of > CachedOutputStream object. In those tests, the spy CachedOutputStream object > "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). > Then after this, there was a line verify(cos).setThreshold(102400L). > Therefore, after the cos being initialized, we need to make sure the > setThreshold has been called once. However, it doens't execute as expected, > and the root cause is that the threshold is not provided when calling > testSetStreamedAttachmentProperties() method and the thresholdSysPropSet, the > boolean that indicated whether the default threshold has been set or not, has > been set to true when we run the CachedOutputStreamTest.java. Inside the > CachedOutputStreamTest.java, the unit test > testUseSysPropsWithAttachmentDeserializer() called the > AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the > thresholdSysPropSet has been set to true. Therefore, if we run > CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the > verify(cos).setThreshold(102400L)
[jira] [Updated] (CXF-8959) Detect order dependent flakiness in AttachmentUtilTest.java in core module
[ https://issues.apache.org/jira/browse/CXF-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruby updated CXF-8959: -- Description: The order dependent flakiness was detected when running multiple test classes. The polluter that caused the flakiness in AttachmentUtilTest.java was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there were multiple tests that used Mockito.spy() to verify the behavior of CachedOutputStream object. In those tests, the spy CachedOutputStream object "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). Then after this, there was a line verify(cos).setThreshold(102400L). Therefore, after the cos being initialized, we need to make sure the setThreshold has been called once. However, it doens't execute as expected, and the root cause is that the threshold is not provided when calling testSetStreamedAttachmentProperties() method and the thresholdSysPropSet (the boolean that indicated whether the default threshold has been set or not) has been set to true when we run the CachedOutputStreamTest.java. Inside the CachedOutputStreamTest.java, the unit test testUseSysPropsWithAttachmentDeserializer() called the AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the thresholdSysPropSet has been set to true then. Therefore, if we run CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the verify(cos).setThreshold(102400L) statement will lead to the error message Wanted but not invoked: cachedOutputStream.setThreshold(102400L); -> at org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) was: The order dependent flakiness was detected when running multiple test classes. The polluter that caused the flakiness in AttachmentUtilTest.java was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there were multiple tests that used Mockito.spy() to verify the behavior of CachedOutputStream object. In those tests, the spy CachedOutputStream object "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). Then after this, there was a line verify(cos).setThreshold(102400L). Therefore, after the cos being initialized, we need to make sure the setThreshold has been called once. However, it doens't execute as expected, and the root cause is that the threshold is not provided when calling testSetStreamedAttachmentProperties() method and the thresholdSysPropSet, the boolean that indicated whether the default threshold has been set or not, has been set to true when we run the CachedOutputStreamTest.java. Inside the CachedOutputStreamTest.java, the unit test testUseSysPropsWithAttachmentDeserializer() called the AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the thresholdSysPropSet has been set to true. Therefore, if we run CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the verify(cos).setThreshold(102400L) statement will lead to the error message Wanted but not invoked: cachedOutputStream.setThreshold(102400L); -> at org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) > Detect order dependent flakiness in AttachmentUtilTest.java in core module > -- > > Key: CXF-8959 > URL: https://issues.apache.org/jira/browse/CXF-8959 > Project: CXF > Issue Type: Bug >Reporter: Ruby >Priority: Minor > > The order dependent flakiness was detected when running multiple test > classes. The polluter that caused the flakiness in AttachmentUtilTest.java > was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there > were multiple tests that used Mockito.spy() to verify the behavior of > CachedOutputStream object. In those tests, the spy CachedOutputStream object > "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). > Then after this, there was a line verify(cos).setThreshold(102400L). > Therefore, after the cos being initialized, we need to make sure the > setThreshold has been called once. However, it doens't execute as expected, > and the root cause is that the threshold is not provided when calling > testSetStreamedAttachmentProperties() method and the thresholdSysPropSet (the > boolean that indicated whether the default threshold has been set or not) has > been set to true when we run the CachedOutputStreamTest.java. Inside the > CachedOutputStreamTest.java, the unit test > testUseSysPropsWithAttachmentDeserializer() called the > AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the > thresholdSysPropSet has been set to true then. Therefore, if we run > CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the > verify(cos).setThreshol
[jira] [Updated] (CXF-8959) Detect order dependent flakiness in AttachmentUtilTest.java in core module
[ https://issues.apache.org/jira/browse/CXF-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruby updated CXF-8959: -- Attachment: failure.png > Detect order dependent flakiness in AttachmentUtilTest.java in core module > -- > > Key: CXF-8959 > URL: https://issues.apache.org/jira/browse/CXF-8959 > Project: CXF > Issue Type: Bug >Reporter: Ruby >Priority: Minor > Attachments: failure.png > > > The order dependent flakiness was detected when running multiple test > classes. The polluter that caused the flakiness in AttachmentUtilTest.java > was the test class CachedOutputStreamTest.java. In AttachmentUtilTest, there > were multiple tests that used Mockito.spy() to verify the behavior of > CachedOutputStream object. In those tests, the spy CachedOutputStream object > "cos" was generated (CachedOutputStream cos = spy(CachedOutputStream.class)). > Then after this, there was a line verify(cos).setThreshold(102400L). > Therefore, after the cos being initialized, we need to make sure the > setThreshold has been called once. However, it doens't execute as expected, > and the root cause is that the threshold is not provided when calling > testSetStreamedAttachmentProperties() method and the thresholdSysPropSet (the > boolean that indicated whether the default threshold has been set or not) has > been set to true when we run the CachedOutputStreamTest.java. Inside the > CachedOutputStreamTest.java, the unit test > testUseSysPropsWithAttachmentDeserializer() called the > AttachmentUtil.setStreamedAttachmentProperties(message, cache), so the > thresholdSysPropSet has been set to true then. Therefore, if we run > CachedOutputStreamTest.java before running the AttachmentUtilTest.java, the > verify(cos).setThreshold(102400L) statement will lead to the error message > Wanted but not invoked: > cachedOutputStream.setThreshold(102400L); > -> at > org.apache.cxf.attachment.AttachmentUtilTest.bigIntAsAttachmentMaxSize(AttachmentUtilTest.java:279) -- This message was sent by Atlassian Jira (v8.20.10#820010)
