[GitHub] andymc12 opened a new pull request #380: [CXF-7639] Update dependency to servlet 4.0
andymc12 opened a new pull request #380: [CXF-7639] Update dependency to servlet 4.0 URL: https://github.com/apache/cxf/pull/380 Updating the Import-Package of javax.servlet.* packages to include 4.0. This is a small change, but is used in several modules. I'm mainly looking for an automated build to confirm that this change doesn't break anything, but review/suggestions welcome. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] andymc12 commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
andymc12 commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364227164 @sberyozkin I updated the code with your suggestions. Do you want to take another look? I also fixed the `isEnabled` behavior - we also ran into a couple of TCK/CTS failures with that method. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] andymc12 commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
andymc12 commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364164854 Hi @sberyozkin - that makes sense. I'll update with a new commit shortly. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364094956 Hmm...May be the registration of the unknown types should not be blocked as I suspect this is how many users are already registering CXF specific providers with register(...) without the base implementation having any knowledge of the scope of such providers. So IMHO it should only be limited to blocking the well-known server interfaces in the client scope and vice versa. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364092698 OK, I've debugged the test and recall a bit better now what I was trying to do with these supported types. FYI, I found implementing all of these Configuration/Configurable very challenging, I recall typing and thinking I was not really sure if I was on the wrong or right path :-) as the original docs were quite compact, and the interpretation of some signatures can vary even today. My own initial understanding was that it was primarily about supporting new filters/interceptors, given that in 2.0 (and in 2.1 for the most non-filter/non-interceptor interfaces) no priorities existed for MBR/MBW (and today for ex for ExceptionMapper or ParamConverterProvider) while many register methods accept the priorities or have the default priorities which have no any processing reqs for the last 2 interfaces and in 2.0 - for MBR/MBW as well. Hence those supported types lists (for client/server) only included the new 2.0 filter/interceptors and only later I started adding the support for the wider set of standard types. But anyway, the patch looks fine, except that the supported contracts still need to be passed in, this is to protect Server-side Configuration from accepting ClientRequest/ResponseFilter and the client side Configuration - from ContainerRequest/ResponseFilter. These supported types lists may need to be expanded for the client and server (to include all other standard types which make sense on the client and the server) such that a provider can not be registered under SomeNonJaxrsContract - which should be rejected Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364092698 OK, I've debugged the test and recall a bit better now what I was trying to do with these supported types. FYI, I found implementing all of these Configuration/Configurable very challenging, I recall typing and thinking I was not really sure if I was on the wrong or right path :-) as the original docs were quite compact, and the interpretation of some signatures can vary even today. My own initial understanding was that it was primarily about supporting new filters/interceptors, given that in 2.0 (and in 2.1 for the most non-filter/non-interceptor interfaces) no priorities existed for MBR/MBW (and today for ex for ExceptionMapper or ParamConverterProvider) while many register methods accept the priorities or have the default priorities which have no any processing reqs for the last 2 intterfaces and in 2.0 - for MBR/MBW as well. Hence those supported types lists (for client/server) only included the new 2.0 filter/interceptors and only later I started adding the support for the wider set of standard types. But anyway, the patch looks fine, except that the supported contracts still need to be passed in, this is to protect Server-side Configuration from accepting ClientRequest/ResponseFilter and the client side Configuration - from ContainerRequest/ResponseFilter. These supported types lists may need to be expanded for the client and server (to include all other standard types which make sense on the client and the server) such that a provider can not be registered under SomeNonJaxrsContract - which should be rejected Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364075241 Sorry, looking at the test in this PR which explains the issue... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364072539 Hi, I was referring to a case where a provider implementing multiple interfaces has to be registered under a specific contract(s) only... May be I'm missing what the problem is. Can you please type the code showing where the issue is for me to look at the master code with the better focus :-) ? Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts
sberyozkin commented on issue #379: [CXF-7638] Only register provider if it implements specified contracts URL: https://github.com/apache/cxf/pull/379#issuecomment-364072539 Hi, I was referring to a case where a provider implementing multiple interfaces has to be registered under a specific contract(s) only... May be I'm missing what the problem is. Can you please type the code showing where the issue for me to look at the master code with the better focus :-) ? Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: CXF with WLS 12.2.1
Hi
Not that I'm aware of; perhaps you need to configure WLS 12.2.1 somehow
to tell it not to use the default JAX-RS stack for your web app...
Sergey
On 08/02/18 09:13, Moshe Lavi (Raanana) wrote:
Hi,
I would like to know if there is any known limitation where both CXF 3.0.2 and
WLS 12.2.1 can work together, as that was not an issue with WLS 12.1.3?
Issue - Resource Interface that contain the signature of @Multipart with
Attachment type is failed in Jersey validation.
public abstract Response applyBulkDependencies(@PathParam("fwa-id") String paramString1, @Multipart("dependencies") InputStream
paramInputStream, @Multipart("dependencies") Attachment paramAttachment, @QueryParam("fwa-version") String paramString2,
@QueryParam("sitegroup-id") String paramString3, @QueryParam("sitegroup-name") String paramString4,
@QueryParam("file-name") String paramString5);
Exception
[] from public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[]) is not resolvable to a concrete
type.; source='public void org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[])', [WARNING] Parameter 1 of type java.lang.Class[] from public void
org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[]) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.AbstractJAXBProvider.setExtraClass(java.lang.Class[])', [WARNING] Parameter 1 of type java.util.Map, java.lang.String> from
public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map, java.lang.String>) is not resolvable to a concrete type.;
source='public void org.apache.cxf.jaxrs.provider.RequestDispatcherProvider.setEnumResources(java.util.Map)', [WARNING] Parameter 1 of type T from public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [WARNING] Parameter 1 of type javax.ws.rs.ext.MessageBodyWriter from public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriter(javax.ws.rs.ext.MessageBodyWriter) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriter(javax.ws.rs.ext.MessageBodyWriter)', [WARNING] Parameter 1 of type
java.util.List> from public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriters(java.util.List>) is not resolvable to a concrete type.; source='public
void org.apache.cxf.jaxrs.provider.CachingMessageBodyWriter.setDelegatingWriters(java.util.List)', [WARNING] Parameter 1 of type T from public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [WARNING] Parameter 1 of type javax.ws.rs.ext.MessageBodyReader from public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReader(javax.ws.rs.ext.MessageBodyReader) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReader(javax.ws.rs.ext.MessageBodyReader)', [WARNING] Parameter 1 of type
java.util.List> from public void
org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReaders(java.util.List>) is not resolvable to a concrete type.; source='public
void org.apache.cxf.jaxrs.provider.CachingMessageBodyReader.setDelegatingReaders(java.util.List)', [WARNING] Parameter 1 of type T from public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(T) is not resolvable to a concrete type.; source='public void
org.apache.cxf.jaxrs.provider.AbstractCachingMessageProvider.setObject(java.lang.Object)', [FATAL] No injection source found for a parameter of type public abstract javax.ws.rs.core.Response
com.amdocs.ms.frameworkagreementextractor.resources.interfaces.IExtractrequestResource.applyBulkDependencies(java.lang.String,java.io.InputStream,org.apache.cxf.jaxrs.ext.multipart.Attachment,java.lang.String,java.lang.String,java.lang.String,java.lang.String)
at index 1.; source='ResourceMethod{httpMethod=POST,
consumedTypes=[multipart/form-data], producedTypes=[application/json],
suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS,
invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=interface
com.amdocs.ms.frameworkagreementextractor.resources.interfaces.IExtractrequestResource,
handlerConstructors=[]}, definitionMethod=public abstract
javax.ws.rs.core.Response
com.amdocs.ms.frameworkagreementextractor.resources.interfaces.IExtractrequestResource.applyBulkDependencies(java.lang.String,java.io.InputStream,org.apache.cxf.jaxrs.ext.multipart.Attachment,java.lang.String,java.lang.String,j
