[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286397#comment-13286397
]
Sergey Beryozkin commented on CXF-4351:
---
Yes, we have a couple of demos actually producing JSON in OSGI but JSONProvider
is explicitly registered there.
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285795#comment-13285795
]
Sergey Beryozkin edited comment on CXF-4348 at 5/31/12 9:55 AM:
Ivan,
2) AttachmentOutputInterceptor is created with some default Content-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
note that the method in your code @Produces(multipart/*). I can reproduce
that the response message's Content-Type is set to application/octet-stream,
but only if no Accept: multipart-related exists. If I update the client to
set Accept: multipart-related, then the message Content-Type is set correctly
to multipart-related, with other parameters like start-info, etc, included.
Can you confirm that you have a specific multipart media type listed in Accept ?
I can confirm that the Content-Type of the root part only is broken for
outbound attachments. Will be fixing it
was (Author: sergey_beryozkin):
Ivan,
2) AttachmentOutputInterceptor is created with some default Content-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
note that the method in your code @Produces(multipart/*). I can reproduce
that the response message's Content-Type is set to application/octet-stream,
but only if no Accept: multipart-related exists. If I update the client to
set Accept: multipart-related, then the message Content-Type is set correctly
to multipart-related, with other parameters like start-info, etc, included.
Can you confirm that you have a specific multipart media type listed in Accept ?
I can confirm that when we have more than one part returned, the Content-Type
of the root part is broken. Will be fixing it
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286486#comment-13286486
]
Ivan Bondarenko commented on CXF-4348:
--
I cannot check application/octet-stream right now, will do it a bit later.
But what spec reflects this in global Content-Type?: type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
As I know the first part should have no impact on the whole content.
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286490#comment-13286490
]
Sergey Beryozkin commented on CXF-4348:
---
just add LogginFeature or LoggingInInterceptor to see the actual Accept.
re: type=application/msword; boundary=uuid:{UUID};
start=Attachment_id1; start-info=application/msword
this is a bit broken, it should only occur for XOP payloads - will be fixing
that. However it should not affect the consumers expecting no XOP, those are
just media type parameters and thus can be safely ignored
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286543#comment-13286543
]
Sergey Beryozkin commented on CXF-4348:
---
The fix for the root part's Content-Type is on the trunk, 2.5.x
Content-Type is broken in multipart serialization
-
Key: CXF-4348
URL: https://issues.apache.org/jira/browse/CXF-4348
Project: CXF
Issue Type: Bug
Components: JAX-RS
Environment: Any
Reporter: Ivan Bondarenko
Priority: Blocker
Labels: bug, multipart, serialization
Multiparts are serialized incorrectly.
Imagine the response with two attachments:
a) filename1.doc with attachment-id Attachment_id1 and Content-Type
application/msword
b) filename2.xls with attachment-id Attachment_id2 and Content-Type
application/vnd.ms-excel
Serialization of this Multipart is ({} are used for text reduction):
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: application/octet-stream; type=application/msword;
boundary=uuid:{UUID}; start=Attachment_id1;
start-info=application/msword
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: text/xml; charset=UTF-8; type=application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
While we are expecting kind of this:
HTTP/1.1 200 OK
Server: ...
Date: ...
Content-Type: multipart/related
Transfer-Encoding: chunked
--uuid:{UUID}
Content-Type: application/msword;
Content-Transfer-Encoding: binary
Content-ID: Attachment_id1
Content-Disposition: attachment; filename=filename1.doc
{CONTENT1}
--uuid:{UUID}
Content-Type: application/vnd.ms-excel
Content-Transfer-Encoding: binary
Content-ID: Attachment_id2
Content-Disposition: attachment; filename=filename2.xls
{CONTENT2}
--uuid:{UUID}--
So the Content-Type of the whole response and of the first part are incorrect.
The starting point of the bug searching is
org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object)
method, which has at least these sub-bugs:
1) First attachment is handled other way than all subsequent ones - All
attachments must be handled in the same way.
2) AttachmentOutputInterceptor is created with some default Contetnt-Type,
which is application/octet-stream - The type must be multipart/related
(or other multipart).
3) Content-Type of outMessage is changed to the first attachment's
Content-Type and then new type is used at least in
org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method - The
same type must be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4352) SAML Web SSO processing error when receiving a signed Assertion
Colm O hEigeartaigh created CXF-4352: Summary: SAML Web SSO processing error when receiving a signed Assertion Key: CXF-4352 URL: https://issues.apache.org/jira/browse/CXF-4352 Project: CXF Issue Type: Bug Components: JAX-RS Security Affects Versions: 2.6.1 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.6.2 When the RequestAssertionConsumerService (for SAML Web SSO) receives a signed SAML Assertion embedded in a SAMLP Response, there is a bug when it marshalls it to DOM, in that it tries to re-sign the Assertion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286564#comment-13286564
]
Daniel Kulp commented on CXF-4351:
--
This may actually be fixed with 2.6.1. Any chance you could test it?
All the Class.forName things take place from cxf-api and I added a dynamic
import org.apache.cxf.* there to resolve some issues with the JAXB databinding
and stuff. It may actually fix this issue as well.
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4352) SAML Web SSO processing error when receiving a signed Assertion
[ https://issues.apache.org/jira/browse/CXF-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4352. -- Resolution: Fixed SAML Web SSO processing error when receiving a signed Assertion --- Key: CXF-4352 URL: https://issues.apache.org/jira/browse/CXF-4352 Project: CXF Issue Type: Bug Components: JAX-RS Security Affects Versions: 2.6.1 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.6.2 When the RequestAssertionConsumerService (for SAML Web SSO) receives a signed SAML Assertion embedded in a SAMLP Response, there is a bug when it marshalls it to DOM, in that it tries to re-sign the Assertion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3883) Support for identity mapping as part of issue token process
[ https://issues.apache.org/jira/browse/CXF-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286621#comment-13286621 ] Colm O hEigeartaigh commented on CXF-3883: -- Sounds fine to me. Colm. Support for identity mapping as part of issue token process --- Key: CXF-3883 URL: https://issues.apache.org/jira/browse/CXF-3883 Project: CXF Issue Type: New Feature Components: Services Affects Versions: 2.5 Reporter: Oliver Wulff The JIRA https://issues.apache.org/jira/browse/CXF-3520 describes the case where a CXF consumer has configured a different STS than the issuer configured in the IssuedToken assertion of the service provider: In this case, the service consumer and provider don't understand the identity/subject/principal of the counterpart. First, the consumer gets a token from its STS (IDP-STS) which could be a SAML token. Then he requests another token from the STS and sends the one issued before as part of the WS-Security header. The STS must figure out that the sent and requested tokens are from different realms (security domains) and must therefore call the configured identity mapper which takes as parameters source realm, target realm and source principal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-115) Use Spring DM and Eclipse Gemini Blueprint with DOSGi
[
https://issues.apache.org/jira/browse/DOSGI-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286634#comment-13286634
]
Sergey Beryozkin commented on DOSGI-115:
Yes indeed.
I wonder how the following can be rewritten with Aries:
{code:java}
public BlueprintContext publish(ListString springIntentLocations,
BundleContext bundleContext) {
OsgiBundleXmlApplicationContext ctx = new OsgiBundleXmlApplicationContext(
springIntentLocations.toArray(new String[] {}));
ctx.setPublishContextAsService(false);
ctx.setBundleContext(bundleContext);
ctx.refresh();
return new AriesBlueprintContext(ctx);
}
{code}
where BlueprintContext and AriesBlueprintContext are DOSGi-specific.
Use Spring DM and Eclipse Gemini Blueprint with DOSGi
-
Key: DOSGI-115
URL: https://issues.apache.org/jira/browse/DOSGI-115
Project: CXF Distributed OSGi
Issue Type: New Feature
Components: DSW
Affects Versions: 1.4
Environment: Developped in Windows OS
Reporter: Angelo
Labels: patch
Fix For: 1.4
Attachments: cxf-dosgi-ri-dsw-Eclipse Projects cxf with Spring
DM+Eclipse Gemini Blueprint.zip
Today cxf-dosgi-ri-dsw-cxf supports only Spring DM. This goal of this issue
is to modify cxf-dosgi-ri-dsw-cxf to support both Spring DM and Eclipse
Gemini Blueprint.
The idea is :
* 1) cxf-dosgi-ri-dsw-cxf :remove Spring DM dependencies (don't use directly
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext and
org.springframework.osgi.context.BundleContextAware) in this project but use
a commons interface :
package org.apache.cxf.dosgi.dsw.container;
import java.util.List;
import org.osgi.framework.BundleContext;
import org.springframework.context.ApplicationContext;
/**
* OSGi Spring container API.
*
* @author Angelo Zerr angelo.z...@gmail.com
*
*/
public interface OsgiSpringContainer {
/**
* Publish the given springs files and returns the Spring
* {@link ApplicationContext}.
*
* @param springIntentLocations
* @param bundleContext
* @return
*/
ApplicationContext publish(ListString springIntentLocations,
BundleContext bundleContext);
/**
* Returns the {@link BundleContext} from the given Spring application
* context.
*
* @param context
* @return
*/
BundleContext getBundleContext(ApplicationContext context);
}
1.1) In the class OsgiUtils:
do like this:
ApplicationContext ctx =
OsgiSpringContainerProvider.getContainer().publish(springIntentLocations,
bundleContext);
Instead of doing that:
//
//
//OsgiBundleXmlApplicationContext ctx = new
OsgiBundleXmlApplicationContext(springIntentLocations
//.toArray(new String[] {}));
//ctx.setPublishContextAsService(false);
//ctx.setBundleContext(bundleContext);
//ctx.refresh();
1.2) In the Activator class:
Implements ApplicationContextAware (instead of BundleContextAware) :
public class Activator implements ManagedService,
ApplicationContextAware/*,BundleContextAware*/ {
and implements setApplicationContext liek this
public void setApplicationContext(ApplicationContext context)
throws BeansException {
bc = OsgiUtils.getBundleContext(context);
}
where OsgiUtils.getBundleContext use the interface
public static BundleContext getBundleContext(ApplicationContext context) {
return OsgiSpringContainerProvider.getContainer().getBundleContext(context);
}:
1.1) OsgiSpringContainerProvider:
The OsgiSpringContainerProvider use SPI ServiceRegistry to retrieves the
implemententation of OsgiSpringContainer :
package org.apache.cxf.dosgi.dsw.container;
import java.util.Iterator;
import javax.imageio.spi.ServiceRegistry;
public class OsgiSpringContainerProvider {
private static
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286663#comment-13286663
]
Sergey Beryozkin commented on CXF-4351:
---
I deployed a bundle into Karaf with all the individual cxf 2.6.0 modules and
ProviderFactory is capable of loading the default provider.
I think Chris may be using an all-bundle, and looks like it may need an
optional import
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286703#comment-13286703
]
Sergey Beryozkin commented on CXF-4351:
---
Hi Chris, can you provide more details please, when does this exception occur,
when the client bundle making an invocation, or when the server one processes
the request/response ?
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286715#comment-13286715
]
Sergey Beryozkin commented on CXF-4351:
---
Also, do you use Require-Bundle ? If yes, which modules does it list
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4353) DigestAuth sends Proxy-Auth headers even when not requested
Daniel Kulp created CXF-4353: Summary: DigestAuth sends Proxy-Auth headers even when not requested Key: CXF-4353 URL: https://issues.apache.org/jira/browse/CXF-4353 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 2.5.4, 2.6.1 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 2.5.5, 2.6.2 When using DigestAuth, after the initial challenge/response, any additional requests start computing and sending Proxy-Authorization headers even when no proxy policies are set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286903#comment-13286903
]
Chris Dolan commented on CXF-4351:
--
Sergey: no, I don't use Require-Bundle anywhere. I have a few
DynamicImport-Package statements, but none related to CXF. I load CXF via the
karaf features.xml. My custom features.xml loads the following via Karaf's
featuresBoot:
{code}
feature name=my-project version=${project.version} resolver=(obr)
feature version=${cxf.version}cxf/feature
feature version=${activemq.version}activemq/feature
...
/feature
{code}
The CXF part of my Import-Package looks like this (generated by
maven-bundle-plugin; most of this is due to custom auth interceptors and my
jax-rs client):
{code}
org.apache.cxf.binding.soap;version=[2.6,3),
org.apache.cxf.binding.soap.interceptor;version=[2.6,3),
org.apache.cxf.binding.soap.saaj;version=[2.6,3),
org.apache.cxf.configuration.jsse;version=[2.6,3),
org.apache.cxf.endpoint;version=[2.6,3),
org.apache.cxf.headers;version=[2.6,3),
org.apache.cxf.interceptor;version=[2.6,3),
org.apache.cxf.interceptor.security;version=[2.6,3),
org.apache.cxf.jaxrs;version=[2.6,3),
org.apache.cxf.jaxrs.client;version=[2.6,3),
org.apache.cxf.jaxrs.ext;version=[2.6,3),
org.apache.cxf.jaxrs.impl;version=[2.6,3),
org.apache.cxf.jaxrs.model;version=[2.6,3),
org.apache.cxf.jaxrs.utils;version=[2.6,3),
org.apache.cxf.message;version=[2.6,3),
org.apache.cxf.phase;version=[2.6,3),
org.apache.cxf.security;version=[2.6,3),
org.apache.cxf.service;version=[2.6,3),
org.apache.cxf.service.invoker;version=[2.6,3),
org.apache.cxf.service.model;version=[2.6,3),
org.apache.cxf.transport;version=[2.6,3),
org.apache.cxf.transport.http;version=[2.6,3)
{code}
And my bundles via the Karaf shell:
{noformat}
list -s -t 0 | grep cxf
[ 149] [Active ] [Created ] [ ] [ 40] org.apache.cxf.cxf-api
(2.6.0)
[ 150] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-core (2.6.0)
[ 151] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-management (2.6.0)
[ 152] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.karaf.cxf-karaf-commands (2.6.0)
[ 153] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-databinding-jaxb (2.6.0)
[ 154] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-bindings-xml (2.6.0)
[ 155] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-bindings-soap (2.6.0)
[ 156] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-transports-http (2.6.0)
[ 157] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-frontend-simple (2.6.0)
[ 158] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-frontend-jaxws (2.6.0)
[ 160] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-rs-extension-providers (2.6.0)
[ 161] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-rs-extension-search (2.6.0)
[ 162] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-frontend-jaxrs (2.6.0)
[ 163] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-databinding-aegis (2.6.0)
[ 165] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-databinding-xmlbeans (2.6.0)
[ 166] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-bindings-corba (2.6.0)
[ 167] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-bindings-coloc (2.6.0)
[ 168] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-bindings-object (2.6.0)
[ 169] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-transports-http-jetty (2.6.0)
[ 170] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-transports-local (2.6.0)
[ 171] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-transports-jms (2.6.0)
[ 173] [Active ] [] [ ] [ 40]
org.apache.cxf.xjc-utils.cxf-xjc-runtime (2.6.0)
[ 175] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-ws-policy (2.6.0)
[ 184] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-ws-addr (2.6.0)
[ 186] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-ws-security (2.6.0)
[ 187] [Active ] [Created ] [ ] [ 40]
org.apache.cxf.cxf-rt-ws-rm (2.6.0)
[ 188] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-ws-mex (2.6.0)
[ 189] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-javascript (2.6.0)
[ 191] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-frontend-js (2.6.0)
[ 192] [Active ] [] [ ] [ 40]
org.apache.cxf.cxf-rt-features-clustering (2.6.0)
[ 193] [Active ] [] [ ] [ 50] org.apache.cxf.bundle
(2.6.0)
{noformat}
No
[jira] [Updated] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Dolan updated CXF-4351:
-
Attachment: CXF-4351.patch
*untested* one-line patch to add json import to jaxrs manifest
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
Attachments: CXF-4351.patch
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286912#comment-13286912
]
Chris Dolan commented on CXF-4351:
--
Daniel: yes, today's 2.6.1-SNAPSHOT works. I tried it back-to-back with 2.6.0
to ensure that I had turned off my workaround. I still think this is worth
patching because the patch is so simple and it saves one ClassNotFoundException
in the provider factory.
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
Attachments: CXF-4351.patch
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286920#comment-13286920
]
Daniel Kulp commented on CXF-4351:
--
The problem is that it won't work. You end up with circular imports where the
cxf-rt-frontend-jaxrs imports stuff from cxf-rt-rs-extension-providers, but
cxf-rt-rs-extension-providers imports stuff from cxf-rt-frontend-jaxrs. I'm
pretty sure OSGi doesn't allow that.
In anycase, with 2.6.1 working, I'm happy with that.
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
Attachments: CXF-4351.patch
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4351) No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing Import-Package for org.apache.cxf.jaxrs.provider.json
[
https://issues.apache.org/jira/browse/CXF-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286978#comment-13286978
]
Chris Dolan commented on CXF-4351:
--
I'm willing to let this go with your Dynamic-Import solution. Thanks.
But I feel the need to say: my solution should work because of the
;resolution:=optional as long as cxf-rt-rs-extension-providers.jar is loaded
before the ProviderFactory is invoked, which should be always unless a bundle
watcher gets in between them...
Yet another solution would be to make cxf-rt-rs-extension-providers a Fragment
of cxf-rt-frontend-jaxrs. I'm not sure that would be a good idea, but it would
solve the problem too.
No JSON output under OSGi because cxf-rt-frontend-jaxrs is missing
Import-Package for org.apache.cxf.jaxrs.provider.json
Key: CXF-4351
URL: https://issues.apache.org/jira/browse/CXF-4351
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6
Environment: OSGi 4.2, Apache Karaf 2.2.7, Equinox
Reporter: Chris Dolan
Attachments: CXF-4351.patch
I use CXF via the features.xml inside of Apache Karaf. I use the umbrella
feature cxf to pull in most of the CXF bundles.
When upgrading from CXF 2.5.0 to 2.6.0, I started getting errors like the
following when my Accepts header is application/json:
{noformat}
2012-05-30 16:43:55,979 WARN [JAXRSOutInterceptor.java:401] No message body
writer has been found for response class HealthItemCollection. -
o.a.c.j.i.JAXRSOutInterceptor
{noformat}
I put a breakpoint in org.apache.cxf.jaxrs.provider.ProviderFactory and found
this:
{noformat}
java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.json.JSONProvider
{noformat}
Then I looked at the manifest for cxf-rt-frontend-jaxrs and noticed that the
Import-Packages line lacks a reference to org.apache.cxf.jaxrs.provider.json
and other providers that were moved to the new cxf-rt-rs-extension-providers
bundle for 2.6.0.
I think the solution is to simply add an import for
org.apache.cxf.jaxrs.provider.json to the manifest of cxf-rt-frontend-jaxrs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4058) If CXF is last in Karaf feature list, endpoints aren't bound
[ https://issues.apache.org/jira/browse/CXF-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Dolan resolved CXF-4058. -- Resolution: Cannot Reproduce My code has changed enough that I no longer have a way to reproduce it (I don't use Spring anymore). So, I'm resolving as Cannot Reproduce. If CXF is last in Karaf feature list, endpoints aren't bound Key: CXF-4058 URL: https://issues.apache.org/jira/browse/CXF-4058 Project: CXF Issue Type: Bug Components: OSGi Affects Versions: 2.5 Environment: Talend Service Factory 2.5.0.0 (Karaf 2.2.4, CXF 2.5.0) Reporter: Chris Dolan Priority: Minor Fix For: NeedMoreInfo [I apologize in advance that this bug report has a lot of guesswork in it. I've found a workaround so I've marked this as Minor, but it took me a week to find my workaround and I can't figure where the root cause is.] If I write my featuresBoot property in org.apache.karaf.features.cfg like this, everything works: featuresBoot=config,ssh,management,activemq-spring,cxf,webconsole,my-custom-feature But if I (accidentally) move my feature to the front of the list like so: featuresBoot=my-custom-feature,config,ssh,management,activemq-spring,cxf,webconsole then I get 404's for the resources and No services have been found. on the CXF services list. My custom feature contains a JAX-RS application which is bootstrapped with a META-INF/spring/beans.xml file containing beans roughly like this: jaxrs:server id=admin address=/path/to/my/application jaxrs:inInterceptors ref bean=traceInboundStart/ /jaxrs:inInterceptors jaxrs:outInterceptors ref bean=traceOutboundDone/ /jaxrs:outInterceptors jaxrs:serviceBeans ref bean=mySvc/ /jaxrs:serviceBeans jaxrs:providers ref bean=jaxRsAuthFilter/ /jaxrs:providers /jaxrs:server Reloading the bundles in my-custom-feature fixes the problem (the WADL links appear on the services list and the endpoint URLs respond correctly). In both scenarios (my-custom-feature at the front or back of the featuresBoot list), the log messages seem to be nearly identical. A really confusing part is that in *both* cases, I see this log message which seems to suggest success: [INFO] Setting the server's publish address to be /path/to/my/application logger = org.apache.cxf.endpoint.ServerImpl thread = SpringOsgiExtenderThread-2 So, clearly CXF is getting the JAX-RS application successfully, but somehow that's not being mapped all the way through to the OSGi HTTP service. The only other logs that appear relevant appear to be these: [INFO] SPI-Provider Manifest header found in bundle: org.apache.cxf.bundle [INFO] Binding bundle: [org.apache.cxf.bundle_2.5.0 [191]] to http service Those happen just before the Setting the server's publish address... message but after the Spring Found mandatory OSGi service for bean... resolution messages in the failing scenario. I request either 1) a fix so the CXF feature is order independent or 2) a troubleshooting log message to indicate that the resources are bound too late to help others diagnose this problem more quickly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
