[jira] [Created] (CXF-4378) Refactor HttpURLConnection out of JAX-RS AbstractClient.setResponseBuilder()
Chris Dolan created CXF-4378:
Summary: Refactor HttpURLConnection out of JAX-RS
AbstractClient.setResponseBuilder()
Key: CXF-4378
URL: https://issues.apache.org/jira/browse/CXF-4378
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.6.1
Reporter: Chris Dolan
Priority: Minor
First off, I realized this is a bit of a wacky request. My use case may be an
abomination, but my specific request is modest. :-)
My current project experimentally bridges JAX-RS request/response over a JMS
bus. Services are declared with JAX-RS annotations on Java interfaces. Clients
are created with JAXRSClientFactory, but with a proprietary URL schema instead
of http://; and I have registered a proprietary Conduit implementation instead
of the usual HTTPConduit.
So far, so good. The request side of the JAX-RS client code is actually very
nicely abstracted from the conduit, so there's no assumption about HTTP. On the
response side, however, the AbstractClient.setResponseBuilder() method assumes
that there must be an HttpURLConnection attached to the message. If the message
already has its own InputStream (mine does) then this URLConnection is used
just to get the header values back out.
To work around this, I had to make a hack like this in my Conduit
implementation:
{code}
MockHttpURLConnection conn = new MockHttpURLConnection(url);
conn.putHeader(Yada, yada-yada-yada);
message.put(HTTPConduit.KEY_HTTP_CONNECTION, conn);
{code}
where MockHttpURLConnection basically just wraps a Map for header values.
I request that AbstractClient be altered so it expects either a
KEY_HTTP_CONNECTION or a new type of KEY_HTTP_HEADERS, which is perhaps a
simple MultiMap or an actual Headers instance.
--
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-4378) Refactor HttpURLConnection out of JAX-RS AbstractClient.setResponseBuilder()
[
https://issues.apache.org/jira/browse/CXF-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294791#comment-13294791
]
Chris Dolan commented on CXF-4378:
--
Daniel, perhaps but the setResponseBuilder method looks like this:
{code}
HttpURLConnection conn =
(HttpURLConnection)outMessage.get(HTTPConduit.KEY_HTTP_CONNECTION);
if (conn == null) {
throw new ClientWebApplicationException(HTTP Connection is null);
}
...
for (Map.EntryString, ListString entry : conn.getHeaderFields().entrySet())
{
...
}
{code}
So, the HttpURLConnection is currently unavoidable.
Refactor HttpURLConnection out of JAX-RS AbstractClient.setResponseBuilder()
Key: CXF-4378
URL: https://issues.apache.org/jira/browse/CXF-4378
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.6.1
Reporter: Chris Dolan
Priority: Minor
First off, I realized this is a bit of a wacky request. My use case may be an
abomination, but my specific request is modest. :-)
My current project experimentally bridges JAX-RS request/response over a JMS
bus. Services are declared with JAX-RS annotations on Java interfaces.
Clients are created with JAXRSClientFactory, but with a proprietary URL
schema instead of http://; and I have registered a proprietary Conduit
implementation instead of the usual HTTPConduit.
So far, so good. The request side of the JAX-RS client code is actually very
nicely abstracted from the conduit, so there's no assumption about HTTP. On
the response side, however, the AbstractClient.setResponseBuilder() method
assumes that there must be an HttpURLConnection attached to the message. If
the message already has its own InputStream (mine does) then this
URLConnection is used just to get the header values back out.
To work around this, I had to make a hack like this in my Conduit
implementation:
{code}
MockHttpURLConnection conn = new MockHttpURLConnection(url);
conn.putHeader(Yada, yada-yada-yada);
message.put(HTTPConduit.KEY_HTTP_CONNECTION, conn);
{code}
where MockHttpURLConnection basically just wraps a Map for header values.
I request that AbstractClient be altered so it expects either a
KEY_HTTP_CONNECTION or a new type of KEY_HTTP_HEADERS, which is perhaps a
simple MultiMap or an actual Headers instance.
--
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=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
[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=13286131#comment-13286131
]
Chris Dolan commented on CXF-4351:
--
Workaround: simply add new JSONProvider() to my application via
JAXRSServerFactoryBean.setProviders()
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-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280268#comment-13280268
]
Chris Dolan commented on CXF-4290:
--
OK, yes, now I've properly verified that 2.5.4-SNAPSHOT solves the problem
using the provided ProxyClassLoader.
Allow user-specified classloader for JAXRSClientFactory
---
Key: CXF-4290
URL: https://issues.apache.org/jira/browse/CXF-4290
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.5
Environment: Apache Karaf 2.2.4, CXF 2.5.0
Reporter: Chris Dolan
I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
helper exposes this interface as a OSGi service:
{code}
public interface JaxRsClientBuilder {
T T createClient(@Nonnull String baseUrl, @Nonnull ClassT
resourceApiClass);
}
{code}
However, I discovered a blocking problem. If the user of my helper doesn't
import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
exceptions from java.lang.reflect.Proxy because there's no classloader
anywhere that can see both resourceApiClass and
org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
dynamically make an aggregate classloader that can see both resourceApiClass
and Client. I think I can trick JAXRSClientFactory into using this new
classloader for the main resource (by passing in a new Proxy instance as the
resource class), but I can't wedge my custom classloader in for subresources
because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
I request the following as a possible solution. Certainly, I'd accept a
better solution. For example, it looks like JAX-RS 2.0 should eliminate this
problem by making Client into a public interface instead of an implementation
detail.
1) add a new method variant to JAXRSClientFactory that takes a classloader
2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
cri.getServiceClass().getClassLoader() or the thread context classloader
3) change ClientProxyImpl to save this classloader and use it for
subresources
See also the following which describes my failed attempt to work around this
issue:
http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
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-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13278914#comment-13278914
]
Chris Dolan commented on CXF-4290:
--
I think it worked. I need to do a more detailed test, but for right now, I just
renamed it to cxf-bundle-2.5.0.jar and dropped it into my Maven repo, and
commented out my temporary Import-Package: org.apache.cxf.jaxrs.client and
everything works.
Nothing breaks, anyway, so I say ship it! :-) Thanks so much, Sergey.
Allow user-specified classloader for JAXRSClientFactory
---
Key: CXF-4290
URL: https://issues.apache.org/jira/browse/CXF-4290
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.5
Environment: Apache Karaf 2.2.4, CXF 2.5.0
Reporter: Chris Dolan
I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
helper exposes this interface as a OSGi service:
{code}
public interface JaxRsClientBuilder {
T T createClient(@Nonnull String baseUrl, @Nonnull ClassT
resourceApiClass);
}
{code}
However, I discovered a blocking problem. If the user of my helper doesn't
import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
exceptions from java.lang.reflect.Proxy because there's no classloader
anywhere that can see both resourceApiClass and
org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
dynamically make an aggregate classloader that can see both resourceApiClass
and Client. I think I can trick JAXRSClientFactory into using this new
classloader for the main resource (by passing in a new Proxy instance as the
resource class), but I can't wedge my custom classloader in for subresources
because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
I request the following as a possible solution. Certainly, I'd accept a
better solution. For example, it looks like JAX-RS 2.0 should eliminate this
problem by making Client into a public interface instead of an implementation
detail.
1) add a new method variant to JAXRSClientFactory that takes a classloader
2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
cri.getServiceClass().getClassLoader() or the thread context classloader
3) change ClientProxyImpl to save this classloader and use it for
subresources
See also the following which describes my failed attempt to work around this
issue:
http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
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-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13278920#comment-13278920
]
Chris Dolan commented on CXF-4290:
--
Oops, no, I need more testing. My previous test was flawed - I used the wrong
client jar...
Allow user-specified classloader for JAXRSClientFactory
---
Key: CXF-4290
URL: https://issues.apache.org/jira/browse/CXF-4290
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.5
Environment: Apache Karaf 2.2.4, CXF 2.5.0
Reporter: Chris Dolan
I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
helper exposes this interface as a OSGi service:
{code}
public interface JaxRsClientBuilder {
T T createClient(@Nonnull String baseUrl, @Nonnull ClassT
resourceApiClass);
}
{code}
However, I discovered a blocking problem. If the user of my helper doesn't
import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
exceptions from java.lang.reflect.Proxy because there's no classloader
anywhere that can see both resourceApiClass and
org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
dynamically make an aggregate classloader that can see both resourceApiClass
and Client. I think I can trick JAXRSClientFactory into using this new
classloader for the main resource (by passing in a new Proxy instance as the
resource class), but I can't wedge my custom classloader in for subresources
because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
I request the following as a possible solution. Certainly, I'd accept a
better solution. For example, it looks like JAX-RS 2.0 should eliminate this
problem by making Client into a public interface instead of an implementation
detail.
1) add a new method variant to JAXRSClientFactory that takes a classloader
2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
cri.getServiceClass().getClassLoader() or the thread context classloader
3) change ClientProxyImpl to save this classloader and use it for
subresources
See also the following which describes my failed attempt to work around this
issue:
http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
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-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270983#comment-13270983
]
Chris Dolan commented on CXF-4290:
--
Sergey: I started prototyping the classloader, but stopped when I realized that
it wouldn't work for sub resources. I think that shipping CXF with a dynamic
loader would be great. It would need to be careful to 1) cache the CL to avoid
making hundreds of copies and 2) carefully use weak references for the cache to
avoid pinning the OSGi bundle. It would certainly be easier and more flexible
to accept a classloader argument, but an automatic implementation would be much
more user-friendly.
Allow user-specified classloader for JAXRSClientFactory
---
Key: CXF-4290
URL: https://issues.apache.org/jira/browse/CXF-4290
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.5
Environment: Apache Karaf 2.2.4, CXF 2.5.0
Reporter: Chris Dolan
I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
helper exposes this interface as a OSGi service:
{code}
public interface JaxRsClientBuilder {
T T createClient(@Nonnull String baseUrl, @Nonnull ClassT
resourceApiClass);
}
{code}
However, I discovered a blocking problem. If the user of my helper doesn't
import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
exceptions from java.lang.reflect.Proxy because there's no classloader
anywhere that can see both resourceApiClass and
org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
dynamically make an aggregate classloader that can see both resourceApiClass
and Client. I think I can trick JAXRSClientFactory into using this new
classloader for the main resource (by passing in a new Proxy instance as the
resource class), but I can't wedge my custom classloader in for subresources
because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
I request the following as a possible solution. Certainly, I'd accept a
better solution. For example, it looks like JAX-RS 2.0 should eliminate this
problem by making Client into a public interface instead of an implementation
detail.
1) add a new method variant to JAXRSClientFactory that takes a classloader
2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
cri.getServiceClass().getClassLoader() or the thread context classloader
3) change ClientProxyImpl to save this classloader and use it for
subresources
See also the following which describes my failed attempt to work around this
issue:
http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
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-4290) Allow user-specified classloader for JAXRSClientFactory
Chris Dolan created CXF-4290:
Summary: Allow user-specified classloader for JAXRSClientFactory
Key: CXF-4290
URL: https://issues.apache.org/jira/browse/CXF-4290
Project: CXF
Issue Type: Improvement
Components: JAX-RS
Affects Versions: 2.5
Environment: Apache Karaf 2.2.4, CXF 2.5.0
Reporter: Chris Dolan
I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
helper exposes this interface as a OSGi service:
{code}
public interface JaxRsClientBuilder {
T T createClient(@Nonnull String baseUrl, @Nonnull ClassT
resourceApiClass);
}
{code}
However, I discovered a blocking problem. If the user of my helper doesn't
import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
exceptions from java.lang.reflect.Proxy because there's no classloader anywhere
that can see both resourceApiClass and org.apache.cxf.jaxrs.client.Client. I
tried a solution (based on
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
dynamically make an aggregate classloader that can see both resourceApiClass
and Client. I think I can trick JAXRSClientFactory into using this new
classloader for the main resource (by passing in a new Proxy instance as the
resource class), but I can't wedge my custom classloader in for subresources
because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
I request the following as a possible solution. Certainly, I'd accept a better
solution. For example, it looks like JAX-RS 2.0 should eliminate this problem
by making Client into a public interface instead of an implementation detail.
1) add a new method variant to JAXRSClientFactory that takes a classloader
2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
cri.getServiceClass().getClassLoader() or the thread context classloader
3) change ClientProxyImpl to save this classloader and use it for subresources
See also the following which describes my failed attempt to work around this
issue:
http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
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-2640) WSDLToJavaContainer ignores CFG_SUPPRESS_GEN for outputdir creation
WSDLToJavaContainer ignores CFG_SUPPRESS_GEN for outputdir creation
---
Key: CXF-2640
URL: https://issues.apache.org/jira/browse/CXF-2640
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.2.6
Reporter: Chris Dolan
Priority: Trivial
First, let me say that I realize that WSDLToJava doesn't support -suppress as
a command-line option. So this defect is quite obscure.
Consider this code:
WSDLToJava w2j = new WSDLToJava(new String[] {
-d, generatedcode,
http://localhost:9090/CustomerServicePort?wsdl;,
});
ToolContext context = new ToolContext();
context.put(ToolConstants.CFG_SUPPRESS_GEN, true);
w2j.run(context);
This code works in the sense that it does not build any .java files, however it
still creates the generatedcode directory. An easy and low-risk fix would be
to change WSDLToJavaContainer.validate() to wrap an if (isSuppressCodeGen())
{...} around the if(!dir.exists()) {dir.mkdirs()} block.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
