[jira] [Created] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
Panu Hämäläinen created DOSGI-225: - Summary: Service publication with org.apache.cxf.ws.httpservice.context property does not work Key: DOSGI-225 URL: https://issues.apache.org/jira/browse/DOSGI-225 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.7.0 Reporter: Panu Hämäläinen For org.apache.cxf.ws.httpservice.context the page https://cxf.apache.org/distributed-osgi-reference.html says "When this property is specified, the OSGi HTTP Service is used to expose the service, rather than a dedicated Jetty HTTP Server. This property doesn't allow the specification of a port number, as this is provided by the HTTP Service." However, this does not work with DOSGi 1.7.0. Instead, the service gets exposed (by PojoConfigurationTypeHandler) at the default address http://localhost:9000. This used to work e.g. with 1.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOSGI-226) Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
Panu Hämäläinen created DOSGI-226: - Summary: Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall Key: DOSGI-226 URL: https://issues.apache.org/jira/browse/DOSGI-226 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.7.0 Reporter: Panu Hämäläinen I have tried to configure DSW in Karaf 4.0.3 via Felix fileinstall with a config file named "cxf-dsw.cfg". However, the framework never ends up calling the update method (ManagedService) of org.apache.cxf.dosgi.dsw.Activator. The problem probably is the syntax (against OSGi spec?) of the service PID (cxf-dsw). After updating the PID to "org.apache.cxf.dosgi.dsw" in org.apache.cxf.dosgi.dsw.Activator (and the cfg filename accordingly) things started to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6760) extract swagger2 feature in its own module
[ https://issues.apache.org/jira/browse/CXF-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121394#comment-15121394 ] Akitoshi Yoshida commented on CXF-6760: --- that sounds good. originally, i thought we can't do this during a micro-version update, but i think it should be okay with it as nothing really changes except one needs to add another dependency when they do the upgrade. so we can first do this in master and bring it down to 3.1.x at some time. > extract swagger2 feature in its own module > -- > > Key: CXF-6760 > URL: https://issues.apache.org/jira/browse/CXF-6760 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Romain Manni-Bucau > > the feature is not provided *with*dependencies so if cxf is in the container > and swagger the webapp then it leads very easily to issues. > Having an external module would make it smoother for integrations and doesnt > really hurt CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FEDIZ-150) Dynamic lookup of existing home realms
Jan Bernhardt created FEDIZ-150: --- Summary: Dynamic lookup of existing home realms Key: FEDIZ-150 URL: https://issues.apache.org/jira/browse/FEDIZ-150 Project: CXF-Fediz Issue Type: New Feature Components: IDP, OIDC Reporter: Jan Bernhardt Currently the OIDC only supports a static list of preconfigured homeRealms. Since the IDP provides a REST Interface to list all registered trusted 3rd partys, it would be beneficial to take advantage of that. The Fediz IDP should provide a default User & Role to only list trusted 3rd parties and its own realm information. The OIDC should use this user to request realm information during runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FEDIZ-151) Session Conflict with Cookies
Jan Bernhardt created FEDIZ-151: --- Summary: Session Conflict with Cookies Key: FEDIZ-151 URL: https://issues.apache.org/jira/browse/FEDIZ-151 Project: CXF-Fediz Issue Type: Bug Components: IDP Affects Versions: 1.2.1, 1.3.0 Reporter: Jan Bernhardt If I restart my tomcat with Fediz IDP installed and my browser has still a valid session cookie, I will see a Error page from the IDP. Once I delete my cookies and restart the login flow all is working fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6764) Should add RI JAXB Namespacemapper support
[
https://issues.apache.org/jira/browse/CXF-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-6764:
-
Description:
/cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
{code:java}
if (cls == null
&& (mcls.getName().contains(".internal.") ||
mcls.getName().contains("com.sun"))) {
try {
cls =
ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
JAXBUtils.class);
} catch (ClassNotFoundException ex2) {
// ignore
}
}
{code}
CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
cann't add the namespace mapping correctly.
was:
/cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
if (cls == null
&& (mcls.getName().contains(".internal.") ||
mcls.getName().contains("com.sun"))) {
try {
cls =
ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
JAXBUtils.class);
} catch (ClassNotFoundException ex2) {
// ignore
}
}
CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
cann't add the namespace mapping correctly.
> Should add RI JAXB Namespacemapper support
> --
>
> Key: CXF-6764
> URL: https://issues.apache.org/jira/browse/CXF-6764
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> /cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
> {code:java}
> if (cls == null
> && (mcls.getName().contains(".internal.") ||
> mcls.getName().contains("com.sun"))) {
> try {
> cls =
> ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
> JAXBUtils.class);
> } catch (ClassNotFoundException ex2) {
> // ignore
> }
> }
> {code}
> CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
> com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
> mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
> So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
> cann't add the namespace mapping correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6764) Should add RI JAXB Namespacemapper support
[
https://issues.apache.org/jira/browse/CXF-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121985#comment-15121985
]
Daniel Kulp commented on CXF-6764:
--
I'm a bit confused by the comment. There is a bug there as that SHOULD be:
{code:java}
if (cls == null
&& (!mcls.getName().contains(".internal.") ||
mcls.getName().contains("com.sun"))) {
{code}
as it should only go into there if its NOT the "internal" version. If it is
the internal version, the code above this:
{code}
if (cls == null) {
try {
ClassWriter cw = helper.createClassWriter();
if (cw != null) {
cls = createNamespaceWrapperInternal(helper, cw, postFix,
mcls);
}
} catch (RuntimeException ex) {
// continue
}
}
{code}
should be generating NamespaceMapper of the "internal" type.
> Should add RI JAXB Namespacemapper support
> --
>
> Key: CXF-6764
> URL: https://issues.apache.org/jira/browse/CXF-6764
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> /cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
> {code:java}
> if (cls == null
> && (mcls.getName().contains(".internal.") ||
> mcls.getName().contains("com.sun"))) {
> try {
> cls =
> ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
> JAXBUtils.class);
> } catch (ClassNotFoundException ex2) {
> // ignore
> }
> }
> {code}
> CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
> com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
> mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
> So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
> cann't add the namespace mapping correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6764) Should add RI JAXB Namespacemapper support
[
https://issues.apache.org/jira/browse/CXF-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121985#comment-15121985
]
Daniel Kulp edited comment on CXF-6764 at 1/28/16 6:21 PM:
---
I'm a bit confused by the comment. There is a bug there as that SHOULD be:
{code:java}
if (cls == null
&& (!mcls.getName().contains(".internal.") &&
mcls.getName().contains("com.sun"))) {
{code}
as it should only go into there if its NOT the "internal" version. If it is
the internal version, the code above this:
{code}
if (cls == null) {
try {
ClassWriter cw = helper.createClassWriter();
if (cw != null) {
cls = createNamespaceWrapperInternal(helper, cw, postFix,
mcls);
}
} catch (RuntimeException ex) {
// continue
}
}
{code}
should be generating NamespaceMapper of the "internal" type.
was (Author: dkulp):
I'm a bit confused by the comment. There is a bug there as that SHOULD be:
{code:java}
if (cls == null
&& (!mcls.getName().contains(".internal.") ||
mcls.getName().contains("com.sun"))) {
{code}
as it should only go into there if its NOT the "internal" version. If it is
the internal version, the code above this:
{code}
if (cls == null) {
try {
ClassWriter cw = helper.createClassWriter();
if (cw != null) {
cls = createNamespaceWrapperInternal(helper, cw, postFix,
mcls);
}
} catch (RuntimeException ex) {
// continue
}
}
{code}
should be generating NamespaceMapper of the "internal" type.
> Should add RI JAXB Namespacemapper support
> --
>
> Key: CXF-6764
> URL: https://issues.apache.org/jira/browse/CXF-6764
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> /cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
> {code:java}
> if (cls == null
> && (mcls.getName().contains(".internal.") ||
> mcls.getName().contains("com.sun"))) {
> try {
> cls =
> ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
> JAXBUtils.class);
> } catch (ClassNotFoundException ex2) {
> // ignore
> }
> }
> {code}
> CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
> com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
> mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
> So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
> cann't add the namespace mapping correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122332#comment-15122332
]
Sergey Beryozkin edited comment on CXF-6759 at 1/28/16 9:25 PM:
Please do the patch asap if you'd like to make it into 3.1.5, thanks
was (Author: sergey_beryozkin):
Please do the patch now shortly if you'd like to make it into 3.1.5, thanks
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122332#comment-15122332
]
Sergey Beryozkin commented on CXF-6759:
---
Please do the patch now shortly if you'd like to make it into 3.1.5, thanks
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neal Hu updated CXF-6759:
-
Attachment: SourceGenerator.patch
Sergey, the stylecheker reports param number and excutable statement error,
where can I modify the rule or update the code?
Thanks.
Neal
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Attachments: SourceGenerator.patch
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
