[jira] [Commented] (CXF-6742) Weblogic Integration for secured JMS Modules
[ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101553#comment-15101553 ] Christian Schneider commented on CXF-6742: -- Do you think we really need the exposeJndiEnvironment attribute. Would it hurt to always expose the JNDI environment in worker threads? Edit: I thought about this .. As for example in JMSConduit the JNDI context is established per message this can have a serious performance impact. So I think we need this config. On the other hand the performance impact may also be a problem for you. Did you do any performance tests of secured vs unsecured? > Weblogic Integration for secured JMS Modules > > > Key: CXF-6742 > URL: https://issues.apache.org/jira/browse/CXF-6742 > Project: CXF > Issue Type: Improvement > Components: JMS >Affects Versions: 3.1.4 > Environment: SOAP/JMS services (client or server) accessing a > Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy >Reporter: Guillaume >Assignee: Christian Schneider > Attachments: soapJMSWeblo.diff > > > This is a follow up of the user list thread : > http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E > When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic > security model enforces the presence of a valid user (i.e. matching the > security constraint) on the thread interacting with the ressource (i.e. > creating a MessageConsumer or MessageProducer on a JMS session). > This is documented here : > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > This user can be logged in either by having either an open InitialContext, or > a JAAS LoginContext, active at the time of the security-check. > In the CXF 2.x and 3.x implementations, such a condition is met when > accessing the JNDI (to retreive the ConnectionFactory or Destination queue > objects), but the JNDI context is closed almost immediately after this step, > meaning : > 1) When sending SOAP/JMS calls, the calling thread does not have an open > InitialContext anymore > 2) When exposing a SOAP/JMS service, the poller threads that start never even > had a logged in user at any point in time > This leads to a JMS Security exception. For the server side : > Caused by: weblogic.jms.common.JMSSecurityException: Access denied to > resource: type=, application=... > at > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) >... >at > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > In CXF 2.X, the SpringJMS based implementation would allow any user to > override the polling threads to actually perform InitialContext injection, as > suggested here : > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where > we can override the thread pool to perform such an injection too (although > this suffers from several concerns, such as the difficulty to inject > different credentials for different endpoints). > An ideal solution would be to match SpringJMS behaviour of the > "exposeAccessContext" function : > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html > . That is, CXF would provide an option (say, on JMSConfig), to expose an > InitialContext in the threads performing JMS API calls through JNDI. > I will shortly provide a draft patch for this behavior, as a base for > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6721) NullPointerException for some responses containing SoapFault.
[ https://issues.apache.org/jira/browse/CXF-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6721. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.2.0 3.1.5 > NullPointerException for some responses containing SoapFault. > -- > > Key: CXF-6721 > URL: https://issues.apache.org/jira/browse/CXF-6721 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Sergey Maslov >Assignee: Sergey Beryozkin > Fix For: 3.1.5, 3.2.0 > > Attachments: errorresponse.txt, exception.txt > > > NullPointerException for some responses containing SoapFault. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6742) Weblogic Integration for secured JMS Modules
[ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101613#comment-15101613 ] Guillaume commented on CXF-6742: The exposeJndiContext is not mandatory in my view, but offered mostly two things to me : 1) a non regression option if the behaviour had any unintended effect (making it opt in would prevent that) and 2) make it obvious that there was something special going on. I did not perf test this for the outgoing case, because we were in a "functionnality trumps performance" context : slow is better than KO. And I guess, if you're really serious about performance anyway, you'll build a pool of client objects (just as you build a pool of HTTP clients) and hide it behind some kind of service facade. Currently, in production, we are creating the initial context just before instantiating the javax.ws.Service instance, and destroying it after each call, so, we have no re-use pattern at all. And that's why our main need is mostly server-side, by the way, because you always have control of which thread sends a client request, so you can get yourself out of this kind of issue (as long as CXF does not spawn its own thread to listen for a reply - then it gets trickier). We could also have a two step resolution of this issue. Server side first, and then, have a broader discussion about client side. > Weblogic Integration for secured JMS Modules > > > Key: CXF-6742 > URL: https://issues.apache.org/jira/browse/CXF-6742 > Project: CXF > Issue Type: Improvement > Components: JMS >Affects Versions: 3.1.4 > Environment: SOAP/JMS services (client or server) accessing a > Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy >Reporter: Guillaume >Assignee: Christian Schneider > Attachments: soapJMSWeblo.diff > > > This is a follow up of the user list thread : > http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E > When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic > security model enforces the presence of a valid user (i.e. matching the > security constraint) on the thread interacting with the ressource (i.e. > creating a MessageConsumer or MessageProducer on a JMS session). > This is documented here : > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > This user can be logged in either by having either an open InitialContext, or > a JAAS LoginContext, active at the time of the security-check. > In the CXF 2.x and 3.x implementations, such a condition is met when > accessing the JNDI (to retreive the ConnectionFactory or Destination queue > objects), but the JNDI context is closed almost immediately after this step, > meaning : > 1) When sending SOAP/JMS calls, the calling thread does not have an open > InitialContext anymore > 2) When exposing a SOAP/JMS service, the poller threads that start never even > had a logged in user at any point in time > This leads to a JMS Security exception. For the server side : > Caused by: weblogic.jms.common.JMSSecurityException: Access denied to > resource: type=, application=... > at > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) >... >at > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > In CXF 2.X, the SpringJMS based implementation would allow any user to > override the polling threads to actually perform InitialContext injection, as > suggested here : > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where > we can override the thread pool to perform such an injection too (although > this suffers from several concerns, such as the difficulty to inject > different credentials for different endpoints). > An ideal solution would be to match SpringJMS behaviour of the > "exposeAccessContext" function : > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html > . That is, CXF would provide an option (say, on JMSConfig), to expose an > InitialContext in the threads performing JMS API calls through JNDI. > I will shortly provide a draft patch for this behavior, as a base for > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko reassigned CXF-6740:
-
Assignee: Andriy Redko
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101755#comment-15101755
]
Andriy Redko edited comment on CXF-6740 at 1/15/16 1:22 PM:
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code}
Apparently, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
was (Author: reta):
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code:json}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code:json}
Apparently, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101755#comment-15101755
]
Andriy Redko edited comment on CXF-6740 at 1/15/16 1:22 PM:
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code}
Very luckily, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
was (Author: reta):
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code}
Apparently, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101755#comment-15101755
]
Andriy Redko commented on CXF-6740:
---
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code:json}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code:json}
Apparently, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101755#comment-15101755
]
Andriy Redko edited comment on CXF-6740 at 1/15/16 1:23 PM:
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code}
So basically you always have all your APIs in same specification. Very luckily,
the heavy use of statics in Swagger may cause this weird behaviour. I will try
to investigate if something could be done in CXF to workaround that.
Thank you.
was (Author: reta):
This is very interesting issue, apparently related to changes in Swagger 2.
So what is happing, and you see that as well, /cxf/bpc-core/swagger.json and
/cxf/bpc-monitor/swagger.json return the same results.
However, you should see 2 tags in the resulting json, something like:
{code}
"tags": [
{ "name": "bpc-core" },
{ "name": "bpc-monitor" }
]
{code}
Very luckily, the heavy use of statics in Swagger may cause this weird
behaviour. I will try to investigate if something could be done in CXF to
workaround that.
Thank you.
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6742) Weblogic Integration for secured JMS Modules
[ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101826#comment-15101826 ] Christian Schneider commented on CXF-6742: -- I started with a commit for the server side now. This allows to defer the creation of a new option. Can you check if that helps with your problem? I will also start a discussion on the list to see if other also have this problem and what experiences they made. I would also like to get some feedback from other on a possible impact on the performance. If I am correct then instantiating a InitialContext can involve one or more remote requests so this could really impact the perfomance in a big way. > Weblogic Integration for secured JMS Modules > > > Key: CXF-6742 > URL: https://issues.apache.org/jira/browse/CXF-6742 > Project: CXF > Issue Type: Improvement > Components: JMS >Affects Versions: 3.1.4 > Environment: SOAP/JMS services (client or server) accessing a > Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy >Reporter: Guillaume >Assignee: Christian Schneider > Attachments: soapJMSWeblo.diff > > > This is a follow up of the user list thread : > http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E > When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic > security model enforces the presence of a valid user (i.e. matching the > security constraint) on the thread interacting with the ressource (i.e. > creating a MessageConsumer or MessageProducer on a JMS session). > This is documented here : > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > This user can be logged in either by having either an open InitialContext, or > a JAAS LoginContext, active at the time of the security-check. > In the CXF 2.x and 3.x implementations, such a condition is met when > accessing the JNDI (to retreive the ConnectionFactory or Destination queue > objects), but the JNDI context is closed almost immediately after this step, > meaning : > 1) When sending SOAP/JMS calls, the calling thread does not have an open > InitialContext anymore > 2) When exposing a SOAP/JMS service, the poller threads that start never even > had a logged in user at any point in time > This leads to a JMS Security exception. For the server side : > Caused by: weblogic.jms.common.JMSSecurityException: Access denied to > resource: type=, application=... > at > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) >... >at > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > In CXF 2.X, the SpringJMS based implementation would allow any user to > override the polling threads to actually perform InitialContext injection, as > suggested here : > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where > we can override the thread pool to perform such an injection too (although > this suffers from several concerns, such as the difficulty to inject > different credentials for different endpoints). > An ideal solution would be to match SpringJMS behaviour of the > "exposeAccessContext" function : > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html > . That is, CXF would provide an option (say, on JMSConfig), to expose an > InitialContext in the threads performing JMS API calls through JNDI. > I will shortly provide a draft patch for this behavior, as a base for > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6749) Classloader leak on FileUtils.createTmpDir()
Diogo Sant'Ana created CXF-6749: --- Summary: Classloader leak on FileUtils.createTmpDir() Key: CXF-6749 URL: https://issues.apache.org/jira/browse/CXF-6749 Project: CXF Issue Type: Bug Affects Versions: 2.7.14 Environment: Slackware Linux 14.1 (kernel 3.10.17), Java 1.7.0_75, Tomcat 7.0.39 (this is my production environment) Reporter: Diogo Sant'Ana FileUtils.createTmpDir() adds a ApplicationShutdownHook to remove the recently created temp folder, creating a indirect reference to the Tomcat WebappClassloader from the hook static attribute at ApplicationShutdownHooks class, preventing the classloader to be collected. Actually, it will be collected when the JVM is turned off. But this is a web application container, it won't be turn off for a while. I only checked this with the version I´m currently using (2.7.14), but I checked the code at 3.1.x and master branches and it still the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6749) Classloader leak on FileUtils.createTmpDir()
[ https://issues.apache.org/jira/browse/CXF-6749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102011#comment-15102011 ] Diogo Sant'Ana commented on CXF-6749: - Screenshot of Eclipse Memory Analyser: https://goo.gl/rofvi9 > Classloader leak on FileUtils.createTmpDir() > > > Key: CXF-6749 > URL: https://issues.apache.org/jira/browse/CXF-6749 > Project: CXF > Issue Type: Bug >Affects Versions: 2.7.14 > Environment: Slackware Linux 14.1 (kernel 3.10.17), Java 1.7.0_75, > Tomcat 7.0.39 (this is my production environment) >Reporter: Diogo Sant'Ana > Labels: classloader-leak > > FileUtils.createTmpDir() adds a ApplicationShutdownHook to remove the > recently created temp folder, creating a indirect reference to the Tomcat > WebappClassloader from the hook static attribute at ApplicationShutdownHooks > class, preventing the classloader to be collected. > Actually, it will be collected when the JVM is turned off. But this is a web > application container, it won't be turn off for a while. > I only checked this with the version I´m currently using (2.7.14), but I > checked the code at 3.1.x and master branches and it still the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
