[jira] [Created] (CXF-7062) wsdl2java generates incorrect @XmlElement(namespace=“…”)
Randy Leonard created CXF-7062: -- Summary: wsdl2java generates incorrect @XmlElement(namespace=“…”) Key: CXF-7062 URL: https://issues.apache.org/jira/browse/CXF-7062 Project: CXF Issue Type: Bug Components: Soap Binding Affects Versions: 3.1.7 Environment: MacOSX 10.11, Java v1.8 Reporter: Randy Leonard Priority: Blocker I am using Apache CXF 3.1.7, and the wsdl2java command is generating code with missing/incorrect namespace attributes on the @XMLEment annotation. Note I generally use four distinct namespaces within each WSDL document, which are as follows: • Shared data types across many WSDL documents (http://v1_0_0.datatypes.provider.soap.foundation.rps.com) • Domain-specific data types (http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com) • Parameter types (http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com) • Service types (http://v1_0_0.provider.soap.common.masterdata.rps.com) This gives a nice separation of data types, and has worked quite well for me with Axis2. I am having issues, however, when applying this approach to CXF. Below is an example WSDL document with the namespaces defined above: ——— http://v1_0_0.provider.soap.common.masterdata.rps.com; xmlns:foundationTypes="http://v1_0_0.datatypes.provider.soap.foundation.rps.com; xmlns:masterdataCommonTypes="http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com; xmlns:parameter="http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/; xmlns:tns="http://v1_0_0.provider.soap.common.masterdata.rps.com; xmlns:http="http://schemas.xmlsoap.org/wsdl/http/; xmlns:xs="http://www.w3.org/2001/XMLSchema; xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/;> http://v1_0_0.parameters.provider.soap.common.masterdata.rps.com; > http://v1_0_0.datatypes.provider.soap.foundation.rps.com; schemaLocation="schemas/FoundationTypes.xsd" /> http://v1_0_0.datatypes.provider.soap.common.masterdata.rps.com; schemaLocation="schemas/MasterDataCommonTypes.xsd" /> http://schemas.xmlsoap.org/soap/http; />
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505191#comment-15505191
]
Andriy Redko commented on CXF-7045:
---
Done, [~sergey_beryozkin] [~ay]:
master @
https://github.com/apache/cxf/commit/507ad4be6ee6056bb75e8decef9ee8e1ef13c334
3.1.fixes @
https://github.com/apache/cxf/commit/9d7c9508ba36161e795390985f384169c4f0d086
Works perfectly on Karaf 4.0.6 :)
Thanks!
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6263) Caused by: java.lang.VerifyError: org.apache.cxf.jaxrs.provider.ProviderFactory
[ https://issues.apache.org/jira/browse/CXF-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504114#comment-15504114 ] Daryl Banttari commented on CXF-6263: - I know this is a year late, but it's the first Google hit for this so: My problem that generated this error was that Ivy was including both the org="asm" and org="org.ow2.asm". Added this to solve: > Caused by: java.lang.VerifyError: > org.apache.cxf.jaxrs.provider.ProviderFactory > --- > > Key: CXF-6263 > URL: https://issues.apache.org/jira/browse/CXF-6263 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.7.13 > Environment: Windows 7, JRE 1.6, WAS 8.5, spring 3.2.5 >Reporter: Raj Rao >Assignee: Sergey Beryozkin > Labels: compatibility > Fix For: NeedMoreInfo > > > I am getting the following exception: > [2/19/15 22:28:24:125 CST] 0120 ContextLoader E > org.springframework.web.context.ContextLoader initWebApplicationContext > Context initialization failed > java.lang.VerifyError: > org.apache.cxf.jaxrs.provider.ProviderFactory > at java.lang.ClassLoader.defineClassImpl(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:264) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:74) > at > com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:853) > at > com.ibm.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:763) > at > com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:604) > at java.lang.ClassLoader.loadClass(ClassLoader.java:650) > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:93) > at java.lang.J9VMInternals.verify(J9VMInternals.java:91) > at java.lang.J9VMInternals.prepare(J9VMInternals.java:490) > at java.lang.Class.getDeclaredMethods(Class.java:746) > at > org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:467) > at > org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:451) > at > org.springframework.util.ReflectionUtils.getUniqueDeclaredMethods(ReflectionUtils.java:511) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod(AbstractAutowireCapableBeanFactory.java:638) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBeanFactory.java:575) > at > org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:1350) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:355) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:326) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:434) > at > org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:624) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:461) > at > org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389) > at > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294) > at > org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112) > at > sf.jra.framework.web.servlet.ApplicationInitializer.initializeListeners(ApplicationInitializer.java:239) > at > sf.jra.framework.web.servlet.ApplicationInitializer.contextInitialized(ApplicationInitializer.java:119) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1678) > at > com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:414) > at > com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88) > at > com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169) > at > com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:746) > at > com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:634) > at > com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:426) > at >
[jira] [Commented] (CXF-7058) Extra CDATA elements added on long CDATA payload
[
https://issues.apache.org/jira/browse/CXF-7058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503802#comment-15503802
]
Rodrigo Merino commented on CXF-7058:
-
Is there any chance this change can be backported to 2.7.x and released?
Thanks in advance.
> Extra CDATA elements added on long CDATA payload
>
>
> Key: CXF-7058
> URL: https://issues.apache.org/jira/browse/CXF-7058
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7.18, 3.1.7
> Environment: All
>Reporter: Rodrigo Merino
> Attachments: headerSoapReqLongCdata.xml
>
>
> When calling StaxUtils.copy() with a source xml that contains a long CDATA
> section, that long CDATA is sent in chunks to the writer, with each chunk
> being wrapped in a CDATA independently.
> For instance, {code}{code} in the source ends in the
> destination as {code}{code}
> This can be verified by running the test
> org.apache.cxf.staxutils.StaxUtilsTest.testCopy() with the attached xml file
> (headerSoapReqLongCdata.xml).
> I reported this initially to woodstox
> (https://github.com/FasterXML/woodstox/issues/21 and
> https://github.com/FasterXML/woodstox/issues/22),, but from Tatu's last
> answer
> (https://github.com/FasterXML/woodstox/issues/22#issuecomment-246254486) is
> is something that should be handled in CXF's StaxUtils.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7058) Extra CDATA elements added on long CDATA payload
[
https://issues.apache.org/jira/browse/CXF-7058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503713#comment-15503713
]
ASF GitHub Bot commented on CXF-7058:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/169
> Extra CDATA elements added on long CDATA payload
>
>
> Key: CXF-7058
> URL: https://issues.apache.org/jira/browse/CXF-7058
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7.18, 3.1.7
> Environment: All
>Reporter: Rodrigo Merino
> Attachments: headerSoapReqLongCdata.xml
>
>
> When calling StaxUtils.copy() with a source xml that contains a long CDATA
> section, that long CDATA is sent in chunks to the writer, with each chunk
> being wrapped in a CDATA independently.
> For instance, {code}{code} in the source ends in the
> destination as {code}{code}
> This can be verified by running the test
> org.apache.cxf.staxutils.StaxUtilsTest.testCopy() with the attached xml file
> (headerSoapReqLongCdata.xml).
> I reported this initially to woodstox
> (https://github.com/FasterXML/woodstox/issues/21 and
> https://github.com/FasterXML/woodstox/issues/22),, but from Tatu's last
> answer
> (https://github.com/FasterXML/woodstox/issues/22#issuecomment-246254486) is
> is something that should be handled in CXF's StaxUtils.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7061) Avoid asm library conflicts - please follow ow2 repackage recommendation
Carsten Heyl created CXF-7061: - Summary: Avoid asm library conflicts - please follow ow2 repackage recommendation Key: CXF-7061 URL: https://issues.apache.org/jira/browse/CXF-7061 Project: CXF Issue Type: Bug Components: Core Affects Versions: 3.1.7 Reporter: Carsten Heyl Priority: Minor Repeatingly people get conflicts because of different asm library versions and because ow2 didn't change package names between incompatible versions of the asm library. Ow2 recommends that libraries/components using asm byte processing bundle their own repackages version of asm. I suggest that CXF does the same and avoid conflicts for the future. http://asm.ow2.org/doc/faq.html#Q15 It's the third time I got bitten by this and it's a waste of time and blaming other libraries and trying to run other libraries without correct asm version does not help. Updating legacy applications is a pain without those issues. I know that a similiar issue has been rejected in the past (adding a dependency to a repackaged asm) but in my opinion CXF is a major component and should play nicely with others and should repacke on it's own. Thank you for providing such a great product. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503492#comment-15503492
]
Akitoshi Yoshida commented on CXF-7045:
---
sounds good.
thanks.
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503165#comment-15503165
]
Andriy Redko commented on CXF-7045:
---
Hi Aki, Sergey,
Awesome, will do the change today.
Thanks!
Best Regards,
Andriy Redko
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502928#comment-15502928
]
Sergey Beryozkin commented on CXF-7045:
---
Hi Aki,
Besides that here is what I said in some of my comments, there were few of them.
Right now Swagger 2 feature already includes Jackson deps - but the feature
does not work and the user have to install Jackson deps manually. Removing
these deps out of the feature will not make a feature complete - if a user has
to pre-install Jackson manually for the feature to work then there's little
point in having the feature in the 1st place.
So we can keep these deps inside the feature by tweaking some of the attributes
for the Jackson deps to resolve properly. But Jackson being Jackson, it is used
a lot by CXF users who may not care about Swagger at all - all they need is
JSON returned from their services. So if we do a simple refactoring and keep
Jackson deps with the Swagger feature by having it depend on a dedicated
Jackson feature instead of inlining these deps then:
- Swagger feature works and users do not install Jackson manually as in this
demo
- Extra benefit for free - CXF Jackson users can stop typing 5 install commands
for all of the libs Jackson needs
- Will let us deal later on with the case where users have Jackson installed,
and now need Swagger2, but do not want it installing its own Jackson deps.
I reckon it will make things simpler, with Jackson, Swagger or Jackson/Swagger
users all winning.
Cheers, Sergey
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502694#comment-15502694
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy, Sergey,
on second thought, maybe it's practical to introduce a jackson feature and we
can deal with the version upgrading issue when we actually encounter one.
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7045) Update sample description_swagger2_osgi README.txt
[
https://issues.apache.org/jira/browse/CXF-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502676#comment-15502676
]
Akitoshi Yoshida commented on CXF-7045:
---
Hi Andriy, Sergey,
Umm. I am missing to see the benefit of having a cxf-jackson feature. If this
feature is only used by the swagger2 feature and no other cxf component is
using it, there is no benefit of it at this moment. And if other cxf
components start using it for their jackson scenarios, we will need to
synchronized its versions across all those jackson consuming components (so we
can go less frequent upgrade or must introduce multiple versioned jackson
features (e.g., jackson-nn) used by specific components. In short, I think
introducing a jackson feature now seems to make our life more complicated, no?
regards, aki
> Update sample description_swagger2_osgi README.txt
> --
>
> Key: CXF-7045
> URL: https://issues.apache.org/jira/browse/CXF-7045
> Project: CXF
> Issue Type: Bug
> Components: Samples
>Reporter: John Poth
>Assignee: Freeman Fang
>Priority: Minor
> Fix For: 3.2.0, 3.1.8
>
>
> Update jackson version. Currently getting the error:
> {code}
> Caused by: org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0):
> missing requirement [org.apache.cxf.samples.jax_rs_description_swagger2_osgi
> [146](R 146.0)] osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))
> Unresolved requirements:
> [[org.apache.cxf.samples.jax_rs_description_swagger2_osgi [146](R 146.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=com.fasterxml.jackson.jaxrs.json)(version>=2.6.0)(!(version>=3.0.0)))]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-226) Cannot configure org.apache.cxf.dosgi.dsw.Activator via Felix fileinstall
[ https://issues.apache.org/jira/browse/DOSGI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502416#comment-15502416 ] Panu Hämäläinen commented on DOSGI-226: --- Sounds good, thanks. > 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 >Assignee: Christian Schneider > Fix For: 2.0.0 > > > 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] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502394#comment-15502394 ] Panu Hämäläinen edited comment on DOSGI-225 at 9/19/16 6:02 AM: Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) - specify empty cxfServletAlias property in HttpServiceManager config? Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? was (Author: hamapa): Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? > 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 >Assignee: Christian Schneider > Fix For: 2.0.0 > > > 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] [Comment Edited] (DOSGI-225) Service publication with org.apache.cxf.ws.httpservice.context property does not work
[ https://issues.apache.org/jira/browse/DOSGI-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502394#comment-15502394 ] Panu Hämäläinen edited comment on DOSGI-225 at 9/19/16 6:00 AM: Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property (does it still exist)? was (Author: hamapa): Ok, need to try. Probably the referred documentation should be updated then. The bug seems to be related to DOSGI-159. If I want to expose my service at address "http://:/myservice", I need to specify - org.apache.cxf.ws.address = /myaddress (in my service properties) - httpBase = http://: (in HttpServiceManager config with PID org.apache.cxf.dosgi.http) Correct? What's the purpose of org.apache.cxf.ws.httpservice.context service property? > 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 >Assignee: Christian Schneider > Fix For: 2.0.0 > > > 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)
