[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&focusedCommentId=15491378#comment-15491378
]
Andriy Redko commented on CXF-7045:
---
I think the problem is understood: our Swagger 2 implementation does not
directly depend on *com.fasterxml.jackson.jaxrs* so that is why those are not
being installed during *feature:install*. Now, there are couple of options
here:
- remove *com.fasterxml.jackson.jaxrs* from the *feature.xml* so it becomes
the responsibility of the user to install it
- add *com.fasterxml.jackson.jaxrs.json;resolution:=optional* to
*cxf.osgi.import* section (*cxf-rt-rs-service-description-swagger* module)
- remove *dependency="true"* or use *install="auto"* (waiting for advise here
from Christian)
It seems like the first option is the easier one to take, but second one could
be more beneficial to the users, what do you [~sergey_beryozkin], [~ay]?
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-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&focusedCommentId=15490858#comment-15490858
]
ASF GitHub Bot commented on CXF-7058:
-
GitHub user elrodro83 opened a pull request:
https://github.com/apache/cxf/pull/169
[CXF-7058] Extra CDATA elements added on long CDATA payload
* Allow passing woodstox config to bypass the issue
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/elrodro83/cxf CXF-7058
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/169.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #169
commit 0588dcfa3c8f744c921b4e55feea10810fa1dca0
Author: Rodrigo Merino
Date: 2016-09-14T16:22:27Z
[CXF-7058] Extra CDATA elements added on long CDATA payload
* Allow passing woodstox config to bypass the issue
> 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&focusedCommentId=15490860#comment-15490860
]
Rodrigo Merino commented on CXF-7058:
-
Created a PR (https://github.com/apache/cxf/pull/169) to allow passing a
parameter to bypass the issue.
> 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] [Updated] (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:all-tabpanel
]
Rodrigo Merino updated CXF-7058:
Attachment: headerSoapReqLongCdata.xml
Attached file to use for manifesting the bug.
> 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-7058) Extra CDATA elements added on long CDATA payload
Rodrigo Merino created CXF-7058:
---
Summary: 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: 3.1.7, 2.7.18
Environment: All
Reporter: Rodrigo Merino
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-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&focusedCommentId=15490634#comment-15490634
]
Andriy Redko commented on CXF-7045:
---
Hey guys,
Here is what I have found. The dependencies for Jackson are indeed in the
feature.xml file but those two:
{noformat}
mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.6
mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.6
{noformat}
Are not being installed as part of feature:install. Apparently, due to
*dependency="true"*, there is another bundle which satisfy those dependencies
and they are skipped. For a sake of experiment, I removed *dependency="true"*,
deployed feature, deployed sample and everything resolves perfectly. So I think
this is the issue, looking right now where the conflict comes from.
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] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490466#comment-15490466
]
Christian Schneider commented on DOSGI-209:
---
Fixed in
https://github.com/apache/cxf-dosgi/commit/a109b28facacc3f61ec37a84fd1b3a449e20deb6
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.get(ArrayList.java:382
[jira] [Resolved] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-209.
---
Resolution: Fixed
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.get(ArrayList.java:382)
> at
> org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage(WrapperClassInInterceptor.java:110)
>
[jira] [Updated] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated DOSGI-209:
--
Fix Version/s: (was: 2.1.0)
2.0.0
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
> Fix For: 2.0.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.get(ArrayList.java:382)
> at
> org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage(WrapperClassInInterceptor.java:110)
>
[jira] [Assigned] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned DOSGI-209:
-
Assignee: Christian Schneider
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.get(ArrayList.java:382)
> at
> org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage(WrapperClassInInterce
[jira] [Updated] (DOSGI-238) ClassCastException: com.sun.xml.internal.stream.XMLOutputFactoryImpl cannot be cast to javax.xml.stream.XMLOutputFactory
[ https://issues.apache.org/jira/browse/DOSGI-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-238: -- Fix Version/s: (was: 2.0.0) 2.1.0 > ClassCastException: com.sun.xml.internal.stream.XMLOutputFactoryImpl cannot > be cast to javax.xml.stream.XMLOutputFactory > > > Key: DOSGI-238 > URL: https://issues.apache.org/jira/browse/DOSGI-238 > Project: CXF Distributed OSGi > Issue Type: Task >Affects Versions: 1.7.0 >Reporter: Chenguang Zhang > Fix For: 2.1.0 > > > Hello Guys, > Recently, i am trying to build the OSGi environment for CXF using > DOSGi(version 1.7.0).I can see that CXF has cancelled to release singlebundle > for quite a long time.So i have to use the multibundle version. > To verify the environment, i just wrote two very simple bundles based on > JAX-WS rules to test it. > The problem is that when i make all the bundles run well,the the webservice > can not be published which means not signs to show the cxf has been running > successfully. > I can make sure that the bundle has started, it seems that the service is not > bound to CXF container.Some traces here: > Could you please help to find where is wrong? > (Please ignore the Chinese word below :-)) > osgi> org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/transports/http/configuration > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/bindings/soap > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/jaxws > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/simple > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [bundleresource://201.fwk4961455:2/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [bundleresource://201.fwk4961455:3/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.JCLLoggerFactory] > 五月 24, 2016 9:41:02 下午 org.slf4j.impl.JCLLoggerAdapter info > 信息: No quiesce support is available, so blueprint components will not > participate in quiesce operations > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-wsdl (169) > [org.apache.cxf.wsdl.WSDLManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-xml > (176) [org.apache.cxf.binding.xml.XMLBindingFactory, > org.apache.cxf.binding.xml.wsdl11.XMLWSDLExtensionLoader] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http > (177) [org.apache.cxf.transport.http.HTTPTransportFactory, > org.apache.cxf.transport.http.HTTPWSDLExtensionLoader, > org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder, > org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder, > org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-soap > (184) [org.apache.cxf.binding.soap.SoapBindingFactory, > org.apache.cxf.binding.soap.SoapTransportFactory] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-management (189) > [org.apache.cxf.management.InstrumentationManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-frontend-jaxws > (193) [org.apache.cxf.jaxws.context.WebServiceContextResourceResolver] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle > org.apache.cxf.cxf-rt-transports-http-jetty (204) > [org.apache.cxf.transport.http_jetty.JettyDestinationFactory, > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory, > org.apache.cxf.transport.http.ContinuationProviderFactory] > 五月 24, 2016 9:41:02 下午 > org.apac
[jira] [Resolved] (DOSGI-185) Restarting of Jetty/PaxWeb makes exported services unavailable
[ https://issues.apache.org/jira/browse/DOSGI-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-185. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 This should work now. The new code use DS to publish the HttpServiceManager and WsProvider, RsProvider. So if the HttpService goes away all services should be unpublished and republished once it comes back. > Restarting of Jetty/PaxWeb makes exported services unavailable > -- > > Key: DOSGI-185 > URL: https://issues.apache.org/jira/browse/DOSGI-185 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.4.0 > Environment: CXF 2.7.3, Jetty 8.x, PaxWeb 3.0.1, Felix 4.2.1 >Reporter: Dmytro Pishchukhin >Assignee: Christian Schneider >Priority: Critical > Fix For: 2.0.0 > > > How to reproduce: > - export REST/WS service > - update PaxWeb configuration (e.g. change port) > - exported REST/WS services are not available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-238) ClassCastException: com.sun.xml.internal.stream.XMLOutputFactoryImpl cannot be cast to javax.xml.stream.XMLOutputFactory
[ https://issues.apache.org/jira/browse/DOSGI-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-238: -- Summary: ClassCastException: com.sun.xml.internal.stream.XMLOutputFactoryImpl cannot be cast to javax.xml.stream.XMLOutputFactory (was: Problem found when using the latest CXF DOSGi) > ClassCastException: com.sun.xml.internal.stream.XMLOutputFactoryImpl cannot > be cast to javax.xml.stream.XMLOutputFactory > > > Key: DOSGI-238 > URL: https://issues.apache.org/jira/browse/DOSGI-238 > Project: CXF Distributed OSGi > Issue Type: Task >Affects Versions: 1.7.0 >Reporter: Chenguang Zhang > Fix For: 2.0.0 > > > Hello Guys, > Recently, i am trying to build the OSGi environment for CXF using > DOSGi(version 1.7.0).I can see that CXF has cancelled to release singlebundle > for quite a long time.So i have to use the multibundle version. > To verify the environment, i just wrote two very simple bundles based on > JAX-WS rules to test it. > The problem is that when i make all the bundles run well,the the webservice > can not be published which means not signs to show the cxf has been running > successfully. > I can make sure that the bundle has started, it seems that the service is not > bound to CXF container.Some traces here: > Could you please help to find where is wrong? > (Please ignore the Chinese word below :-)) > osgi> org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/transports/http/configuration > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/bindings/soap > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/jaxws > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/simple > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [bundleresource://201.fwk4961455:2/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [bundleresource://201.fwk4961455:3/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.JCLLoggerFactory] > 五月 24, 2016 9:41:02 下午 org.slf4j.impl.JCLLoggerAdapter info > 信息: No quiesce support is available, so blueprint components will not > participate in quiesce operations > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-wsdl (169) > [org.apache.cxf.wsdl.WSDLManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-xml > (176) [org.apache.cxf.binding.xml.XMLBindingFactory, > org.apache.cxf.binding.xml.wsdl11.XMLWSDLExtensionLoader] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http > (177) [org.apache.cxf.transport.http.HTTPTransportFactory, > org.apache.cxf.transport.http.HTTPWSDLExtensionLoader, > org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder, > org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder, > org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-soap > (184) [org.apache.cxf.binding.soap.SoapBindingFactory, > org.apache.cxf.binding.soap.SoapTransportFactory] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-management (189) > [org.apache.cxf.management.InstrumentationManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-frontend-jaxws > (193) [org.apache.cxf.jaxws.context.WebServiceContextResourceResolver] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle > org.apache.cxf.cxf-rt-transports-http-jetty (204) > [org.apache.cxf.transport.http_jetty.JettyDestinationFactory, > org.apache.cxf.transport.http_jett
[jira] [Resolved] (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:all-tabpanel ] Christian Schneider resolved DOSGI-225. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 If you just want to use the existing HTTPService then simply set the address to "/myservice". The current examples use this too. > 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] [Resolved] (DOSGI-217) Security filters don't work in Karaf 3.0.x
[ https://issues.apache.org/jira/browse/DOSGI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-217. --- Resolution: Fixed Assignee: Christian Schneider This should work with current karaf versions. > Security filters don't work in Karaf 3.0.x > -- > > Key: DOSGI-217 > URL: https://issues.apache.org/jira/browse/DOSGI-217 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.6.0 > Environment: Karaf 3.0.0/3.0.1 >Reporter: Amichai Rothman >Assignee: Christian Schneider > > Registering a servlet filter as a security filter (via > org.apache.cxf.httpservice.filter service property) doesn't work under Karaf > 3 - see PAXWEB-668. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490348#comment-15490348
]
Christian Schneider commented on DOSGI-209:
---
I just checked the current code. This issue is still valid. We are too short
before the 2.0.0 release to fix this. I will look into it for the next release.
Btw. the issues here are not actively tracked. If you have problems please also
report them on the mailing list to get some attention.
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
> Fix For: 2.1.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.Ind
[jira] [Updated] (DOSGI-209) when bundles registers two WS with different SoapBinding Style Document/RPC then one of the STYLE is not as expected
[
https://issues.apache.org/jira/browse/DOSGI-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated DOSGI-209:
--
Fix Version/s: 2.1.0
> when bundles registers two WS with different SoapBinding Style Document/RPC
> then one of the STYLE is not as expected
>
>
> Key: DOSGI-209
> URL: https://issues.apache.org/jira/browse/DOSGI-209
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0, 1.5.0
> Environment: Java 1.7, DOSGI-1.5.0, Jetty 8.1.13, win32
>Reporter: Ranjeeth
> Fix For: 2.1.0
>
> Attachments: IntentManagerImpl.java.patch
>
>
> After migrating from 1.3.1 to 1.5.0, i see strange behavior with the
> SOAPBINDING Style [DOCUMENT/RPC],
> Sample Interface:
> {code:title=Interface |borderStyle=solid}
> @WebService(name="iDocumentStyleBindingServiceType",
> portName="iDocumentStyleBindingServicePort",
> serviceName="IDocumentStyleBindingServiceService",
> targetNamespace=IDocumentStyleBindingService.TNS)
> @SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL)
> public interface IDocumentStyleBindingService {
>public static final String TNS =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService";;
>
> @WebResult(name = "IDocumentStyleBindingServiceResult",
> targetNamespace = IDocumentStyleBindingService.TNS, partName =
> "IDocumentStyleBindingServiceResult")
> @Action(input =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";,
> output =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";)
> @WebMethod(operationName = "GetLetterFormURIs", action =
> "http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";)
> public String IDocumentStyleBindingService();
> }
> {code}
> {code:xml}
> http://www.osgi.org/xmlns/scr/v1.1.0";
> enabled="true" immediate="true"
> name="com.temp.uri.documentstylebindingservice">
>
>
>
>
> value="com.temp.uri.IDocumentStyleBindingService"/>
> value="org.apache.cxf.ws"/>
>
> />
> value="/iDocumentStyleBindingService"/>
>
>
> {code}
> Generated WSDL with SOAP Binding style - RPC, should have been document.
> {code:xml}
> http://www.w3.org/2001/XMLSchema";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:ns1="http://schemas.xmlsoap.org/soap/http";
> name="IDocumentStyleBindingServiceService"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";>
>
> http://www.w3.org/2001/XMLSchema";
> xmlns:tns="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> elementFormDefault="unqualified"
> targetNamespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> version="1.0">
>
> type="tns:GetLetterFormURIsResponse"/>
>
>
>
>
>
> name="IDocumentStyleBindingServiceResult" type="xs:string"/>
>
>
>
>
>
> name="parameters">
>
>
>
>
>
>
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";>
> name="GetLetterFormURIsResponse"
> wsam:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";
>
> wsaw:Action="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingServiceResponse";>
>
>
> type="tns:iDocumentStyleBindingServiceType">
> http://schemas.xmlsoap.org/soap/http"/>
>
> soapAction="http://www.temp.uri/temp/iDocumentStyleBindingServiceService/IDocumentStyleBindingService";
> style="rpc"/>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
> namespace="http://www.temp.uri/temp/iDocumentStyleBindingServiceService";
> use="literal"/>
>
>
>
>
> name="iDocumentStyleBindingServicePort">
> http://localhost:15220/iDocumentStyleBindingService"/>
>
>
>
> {code}
> Accessing the service results in following exception
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.get(ArrayList.java:382)
> at
> org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage(WrapperClassInInterceptor.java:110)
> at
> org.apache.cxf.phase.PhaseInte
[jira] [Resolved] (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:all-tabpanel ] Christian Schneider resolved DOSGI-226. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 The config pid is now org.apache.cxf.dosgi.http > 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] [Resolved] (DOSGI-223) Problem Instantiating CXF API
[ https://issues.apache.org/jira/browse/DOSGI-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-223. --- Resolution: Cannot Reproduce Assignee: Christian Schneider The current CXF code does not depend on blueprint anymore. So this should work now. > Problem Instantiating CXF API > - > > Key: DOSGI-223 > URL: https://issues.apache.org/jira/browse/DOSGI-223 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Affects Versions: 1.6.0 >Reporter: Setya >Assignee: Christian Schneider > > Hi all, > When starting CXF DOSGI bundles in Virgo I notice the following exception in > the logs that: > [2015-12-29 13:31:09.326] ERROR Blueprint Extender: 3 > org.apache.aries.blueprint.container.BlueprintContainerImpl Unable to > start blueprint container for bundle org.apa > che.cxf.cxf-api > org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to > instantiate components > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:672) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: > org.eclipse.virgo.kernel.osgi.framework.ExtendedNoClassDefFoundError: > org/apache/aries/blueprint/NamespaceHandler in KernelBundleClassLoader: > [bundle=org.apache.cxf.cxf-a > pi_2.7.8] in KernelBundleClassLoader: [bundle=org.apache.cxf.cxf-api_2.7.8] > at > org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:152) > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > at > org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:340) > at > org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.loadClass(BlueprintContainerImpl.java:419) > at > org.apache.aries.blueprint.container.BlueprintRepository.loadClass(BlueprintRepository.java:410) > at > org.apache.aries.blueprint.container.GenericType.parse(GenericType.java:113) > at > org.apache.aries.blueprint.di.AbstractRecipe.doLoadType(AbstractRecipe.java:168) > at > org.apache.aries.blueprint.di.AbstractRecipe.loadType(AbstractRecipe.java:161) > at > org.apache.aries.blueprint.container.BeanRecipe.loadClass(BeanRecipe.java:249) > at > org.apache.aries.blueprint.container.BeanRecipe.getType(BeanRecipe.java:895) > at > org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:323) > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806) > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787) > at > org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) > at > org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106) > at > org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:282) > at > org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:249
[jira] [Resolved] (DOSGI-187) service configuration for service-namespace, service-name and service-port only take affect if wsdl-location is also configured
[
https://issues.apache.org/jira/browse/DOSGI-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-187.
---
Resolution: Won't Fix
Assignee: Christian Schneider
Fix Version/s: 2.0.0
This is only needed when using a WSDL. When you use the @WebService annotation
you can set these properties in the annotation.
> service configuration for service-namespace, service-name and service-port
> only take affect if wsdl-location is also configured
> ---
>
> Key: DOSGI-187
> URL: https://issues.apache.org/jira/browse/DOSGI-187
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0
>Reporter: Ronald Müller
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
> Attachments: patch.diff
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Changes to the service-configuration for service-namespace, service-name and
> service-port will only take affect, if wsdl-location is also configured. But
> this should be decoupled. See method {{protected void
> setCommonWsdlProperties(..)}} of class
> {{org.apache.cxf.dosgi.dsw.handler.AbstractPojoConfigurationTypeHandler}}
> Workaround: configure wsdl-location as well (e.g. to same url like before)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-186) documentation incorrect
[
https://issues.apache.org/jira/browse/DOSGI-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-186.
---
Resolution: Fixed
Assignee: Christian Schneider
Fix Version/s: 2.0.0
Fixed the error in the wiki.
> documentation incorrect
> ---
>
> Key: DOSGI-186
> URL: https://issues.apache.org/jira/browse/DOSGI-186
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.4.0
>Reporter: Ronald Müller
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The documentation on service configuration
> (http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ContributingDistributionpropertiestoExistingServices%28withoutchangingthem%29)
> for properties service-name, service-namespace, port-name is incorrect
> (compared to the sources in 'org.apache.cxf.dosgi.dsw.Constants.java') and
> will *not* work if applied so.
> Please change:
> * {{org.apache.cxf.ws.wsdl.service.ns -> org.apache.cxf.ws.service.ns}}
> * {{org.apache.cxf.ws.wsdl.service.name -> org.apache.cxf.ws.service.name}}
>
> * {{org.apache.cxf.ws.wsdl.port.name -> org.apache.cxf.ws.port.name}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-199) NoSuchMethodError in tests (Jetty version mismatch)
[ https://issues.apache.org/jira/browse/DOSGI-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-199. --- Resolution: Cannot Reproduce Assignee: Christian Schneider Fix Version/s: 2.0.0 This does not seem to happen anymore with the current code. > NoSuchMethodError in tests (Jetty version mismatch) > --- > > Key: DOSGI-199 > URL: https://issues.apache.org/jira/browse/DOSGI-199 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.5.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider >Priority: Minor > Fix For: 2.0.0 > > > When running the tests, I sometimes see the exception below. Seems to be a > mismatch of eclipse/pax-web Jetty dependency versions. While this usually > goes along with build failure, I've seen one instance where this exception > was thrown but the build was still successful. > ERROR: Bundle cxf-dosgi-ri-dsw-cxf [67] EventDispatcher: Error during > dispatch. (java.lang.NoSuchMethodError: > org.eclipse.jetty.util.LazyList.removeFromArray([Ljava/lang/Object;Ljava/lang/Object;)[Ljava/lang/Object;)java.lang.NoSuchMethodError: > > org.eclipse.jetty.util.LazyList.removeFromArray([Ljava/lang/Object;Ljava/lang/Object;)[Ljava/lang/Object; > at > org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.removeServlet(JettyServerImpl.java:189) > at > org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Started.removeServlet(ServerControllerImpl.java:271) > at > org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.removeServlet(ServerControllerImpl.java:112) > at > org.ops4j.pax.web.service.internal.HttpServiceStarted.unregister(HttpServiceStarted.java:205) > at > org.ops4j.pax.web.service.internal.HttpServiceProxy.unregister(HttpServiceProxy.java:72) > at > org.apache.cxf.dosgi.dsw.handlers.HttpServiceManager$UnregisterListener.serviceChanged(HttpServiceManager.java:177) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3890) > at org.apache.felix.framework.Felix.access$000(Felix.java:79) > at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:728) > at > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:135) > at > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:129) > at > org.apache.cxf.dosgi.samples.greeter.impl.rest.Activator.stop(Activator.java:56) > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2278) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266) > at java.lang.Thread.run(Thread.java:724) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-196) Greeter demo does not work in standalone Felix
[ https://issues.apache.org/jira/browse/DOSGI-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-196. --- Resolution: Won't Fix Assignee: Christian Schneider The samples are completely different now. > Greeter demo does not work in standalone Felix > -- > > Key: DOSGI-196 > URL: https://issues.apache.org/jira/browse/DOSGI-196 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 1.9.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-200) ServiceConstructionException in tests
[ https://issues.apache.org/jira/browse/DOSGI-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-200. --- Resolution: Cannot Reproduce Assignee: Christian Schneider I can not reproduce this in the current code anymore. > ServiceConstructionException in tests > - > > Key: DOSGI-200 > URL: https://issues.apache.org/jira/browse/DOSGI-200 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.5.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > > Systests often fail due to the exception below. This happens inconsistently > but often enough. > SEVERE: Cannot find any registered HttpDestinationFactory from the > Bus.cxf-dosgi-ri-dsw-cxf[org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore] > : failed to create server for interface > org.apache.cxf.dosgi.samples.greeter.GreeterServiceorg.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:178) > at > org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:197) > at > org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:165) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:121) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:56) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:54) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:54) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:39) > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(TopologyManagerExport.java:177) > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.doExportService(TopologyManagerExport.java:168) > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport$3.run(TopologyManagerExport.java:143) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Caused by: java.io.IOException: Cannot find any registered > HttpDestinationFactory from the Bus. > at > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(HTTPTransportFactory.java:295) > at > org.apache.cxf.binding.soap.SoapTransportFactory.getDestination(SoapTransportFactory.java:142) > at > org.apache.cxf.endpoint.ServerImpl.initDestination(ServerImpl.java:93) > at org.apache.cxf.endpoint.ServerImpl.(ServerImpl.java:72) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:160) > ... 15 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-218) ZooKeeperDiscovery should allow multiple client-server connections
[ https://issues.apache.org/jira/browse/DOSGI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-218. --- Resolution: Won't Fix Assignee: Christian Schneider This is currently not possible and at least I do not plan to support multiple connections. I recommend to use a zookeeper cluster for this. The problem with feeding the same data to independent zookeepers is how would you handle the receiving side when the report diverging data. What you can do is create your own discovery based on the zookeeper discovery code where you handle this differently. > ZooKeeperDiscovery should allow multiple client-server connections > -- > > Key: DOSGI-218 > URL: https://issues.apache.org/jira/browse/DOSGI-218 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Discovery >Affects Versions: 1.6.0 >Reporter: Timo Heinonen >Assignee: Christian Schneider > > I would like to use DOSGi+ZooKeeper in a situation where there exists > multiple ZooKeeper servers that are not connected to each other. Currently I > don't know if I can do this because ZooKeeperDiscovery starts only 1 instance > of ZooKeeper client which does not support connections to multiple servers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-189) Endpoint.publish(...) emits FactoryFinder$ConfigurationError with cxf-dosgi-ri-singlebundle-distribution-1.4.0.jar
[ https://issues.apache.org/jira/browse/DOSGI-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-189. --- Resolution: Won't Fix Assignee: Christian Schneider The single bundle distro is not supported anymore .. as it created to many class loading problems. > Endpoint.publish(...) emits FactoryFinder$ConfigurationError with > cxf-dosgi-ri-singlebundle-distribution-1.4.0.jar > -- > > Key: DOSGI-189 > URL: https://issues.apache.org/jira/browse/DOSGI-189 > Project: CXF Distributed OSGi > Issue Type: Bug > Environment: Apache Felix on Windows 7 >Reporter: Andrew Lamb >Assignee: Christian Schneider > Attachments: hello_world.zip > > > A bundled version of the CXF java_first_jaxws sample fails on > Endpoint.publish(...) when the > cxf-dosgi-ri-singlebundle-distribution-1.4.0.jar is used. > Exception in thread "SpringOsgiExtenderThread-2" > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.apache.cxf.dosgi.samples.springdm.impl.HelloWorldImpl#0' > defined in URL [bundle://5.0:0/META-INF/spring/spring.xml]: Invocation of > init method failed; nested exception is > javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider > org.apache.axis2.jaxws.spi.Provider not found > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355) > at > org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) > at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320) > at > org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider > org.apache.axis2.jaxws.spi.Provider not found > at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:138) > at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:282) > at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:125) > at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:42) > at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:273) > at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:282) > at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:168) > at javax.xml.ws.spi.Provider.provider(Provider.java:39) > at javax.xml.ws.Endpoint.publish(Endpoint.java:47) > at > org.apache.cxf.dosgi.samples.springdm.impl.HelloWorldImpl.start(HelloWorldImpl.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomI
[jira] [Commented] (DOSGI-182) SecurityContext populated by spring security made available to CXF
[ https://issues.apache.org/jira/browse/DOSGI-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490277#comment-15490277 ] Christian Schneider commented on DOSGI-182: --- I do not fully understand how this could work. The filter chain is built from OSGi services. So you can not guarantee any order. The only way I could imagine is to execute the CXF service as a filter and have a filter before to set the context and another one after to delete it. This would require a completely different mechanics though. What do you use spring security for? Maybe CXF provides something for your case already. > SecurityContext populated by spring security made available to CXF > -- > > Key: DOSGI-182 > URL: https://issues.apache.org/jira/browse/DOSGI-182 > Project: CXF Distributed OSGi > Issue Type: Wish >Affects Versions: 1.4.0 >Reporter: Isart > Fix For: 1.9.0 > > > I'd like SecurityContext populated by SpringSecurity filter chain to be > available in CXF, and also being available to registered services. > I've been able to apply a SpringSecurity filter chain to JAX-RS services > published with DOSGi by instantiating my filter chain bean and registering it > as an > osgi service with "org.apache.cxf.httpservice.filter" property. > This filter chain populates SecurityContext but also removes it when the > filter chain finishes. > org.apache.cxf.dosgi.dsw.handlers.SecurityDelegatingHttpContext is > responsible of handling the filter for DOSGi registered web services. > When a request comes, the filter chain finishes before normal request > processing in CXF takes place, resulting in SecurityContext not being > available in CXF nor in registered web services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-155) Felix Multi-Bundle distro should not set org.osgi.framework.system.packages property
[
https://issues.apache.org/jira/browse/DOSGI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-155.
---
Resolution: Won't Fix
Currently we need this property for CXF DOSGi to work. I plan to revisit the
problem once I switch to a new way of creating the distro.
> Felix Multi-Bundle distro should not set org.osgi.framework.system.packages
> property
>
>
> Key: DOSGI-155
> URL: https://issues.apache.org/jira/browse/DOSGI-155
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Product
>Affects Versions: 1.4.0
>Reporter: David Bosschaert
>Assignee: Christian Schneider
>Priority: Minor
>
> The multi-bundle distribution contains 2 felix configuration files:
> * conf/felix.config.properties.append
> * conf/felix.discovery.config.properties.append
> Both these files specify the *org.osgi.framework.system.packages* framework
> property:
> {noformat}org.osgi.framework.system.packages=org.osgi.framework;
> version=1.5.0, \
> org.osgi.framework.launch; version=1.0.0, \
> org.osgi.framework.hooks.service; version=1.0.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.4.0, \
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9, \
> javax.crypto, \
> javax.crypto.spec, \
> {noformat}
> and so on...
> This property should really be left specified by the framework itself as its
> value will depend on the version of the OSGi framework and the Java runtime
> used. The values specified are very likely incorrect in a number of cases
> (for example if you use the latest version of Felix, the org.osgi.* values
> are incomplete and the versions incorrect).
> It looks like the main thing here is to add the *org.apache.karaf* packages
> to the framework packages. This should really be done via the
> *org.osgi.framework.system.packages.extra* property, without specifying any
> of the packages provided by the framework or the JRE. E.g.
> {noformat}org.osgi.framework.system.packages.extra=\
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9{noformat}
> I briefly tried this but it seems there is an issue with resolving the
> javax.xml.stream package, and I noticed that in the current configuration it
> was actually removed from the list.
> So in order to fix this situation some work will need to be done make sure
> that the default value of the *org.osgi.framework.system.packages* property
> will work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-224) DiscoveryPlugin interface not exported
[ https://issues.apache.org/jira/browse/DOSGI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490255#comment-15490255 ] Christian Schneider commented on DOSGI-224: --- The zookeeper discovery is not part of CXF DOSGi anymore. It is now located at Aries RSA. I just checked there and the problem is still present there. > DiscoveryPlugin interface not exported > -- > > Key: DOSGI-224 > URL: https://issues.apache.org/jira/browse/DOSGI-224 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.7.0 >Reporter: Panu Hämäläinen > > The package containing the interface > org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not > exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) > which makes it impossible to implement 3rd party discovery plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOSGI-178) NullPointerException when interface method declares throwing custom exception
[ https://issues.apache.org/jira/browse/DOSGI-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490227#comment-15490227 ] Christian Schneider commented on DOSGI-178: --- Can you recheck with current CXF DOSGi? The code has changed quite a bit. > NullPointerException when interface method declares throwing custom exception > - > > Key: DOSGI-178 > URL: https://issues.apache.org/jira/browse/DOSGI-178 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 > Environment: Oracle JDK 1.7.0_17, DOSGi 1.4.0/1.5.0, Karaf 2.3.1 > (Aegis Databinding 2.7.2) >Reporter: Amichai Rothman > > I'm getting an Aegis exception (stacktrace below) when trying to export a > service. It looks similar to CXF-3613, but that is closed as fixed in 2.7.1. > I also found mention of it in > http://mail-archives.apache.org/mod_mbox/cxf-dev/201301.mbox/%3c399bf167-4cdd-4e5c-b9ce-7dbdfc012...@apache.org%3E > from a few months ago but nothing further. > I tried debugging a bit, and it seems to fail when the service interface has > a method declaring a throws clause with a custom exception which is a trivial > Exception subclass (with no fields, just standard constructors). Somewhere > down the line of dependencies it reaches a java.lang.Class, which has a field > of type T[] named enumConstants, it tries to get the base type for component > type "T", which returns null, which causes the exception. > Update: I think I found a temporary workaround: I changed the custom > exception to extend RuntimeException instead of Exception, and changed the > interface to declare throwing RuntimeException instead of the custom > exception, and now I no longer see this exception occurring. The reason for > using RuntimeException (rather than Exception) is so that the rest of the > code does not require any modification - only the exception class and the > interface are changed, and only those will need to be reverted when a proper > fix is released. > However, it's still bad that code needs to be changed in order for DOSGi to > work (one of its main selling points is transparency to OSGi services), plus > the code loses compile-time exception checking for users of the > interface/service. > java.lang.NullPointerException > at java.lang.reflect.Array.newArray(Native Method)[:1.7.0_17] > at java.lang.reflect.Array.newInstance(Array.java:70)[:1.7.0_17] > at > org.apache.cxf.aegis.type.TypeUtil.getTypeRelatedClass(TypeUtil.java:261)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:108)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.type.AbstractTypeCreator.createType(AbstractTypeCreator.java:402)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:192)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.type.basic.BeanType.getDependencies(BeanType.java:534)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:394)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:371)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:283)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:242)[178:org.apache.cxf.cxf-rt-databinding-aegis:2.7.2] > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)[165:org.apache.cxf.cxf-rt-core:2.7.2] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:475)[165:org.apache.cxf.cxf-rt-core:2.7.2] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:537)[165:org.apache.cxf.cxf-rt-core:2.7.2] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:249)[
[jira] [Resolved] (DOSGI-171) service objects are never released (using ungetService)
[ https://issues.apache.org/jira/browse/DOSGI-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-171. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 I just checked the current code and did not find any missing ungetService anymore. I did not check all of Aries RSA though so. If you find any occurence there please open a ticket at Aries. > service objects are never released (using ungetService) > --- > > Key: DOSGI-171 > URL: https://issues.apache.org/jira/browse/DOSGI-171 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > Fix For: 2.0.0 > > > The BundleContext.getService() spec/API states that for every time this > method returns a service object, it must later be released using > BundleContext.ungetService(). Further, after ungetService is called, all > references to the service object should be removed (set to null) so that it > can be properly released. > Currently, there are many usages of getService in the code, but none of them > release the reference as required. > The recommendation seems to be to use service trackers where possible instead > of directly accessing the getService/ungetService APIs, since the > ServiceTracker was created for this exact purpose - to properly handle all > the bookkeeping for service references. Alternatively, in places in which a > ServiceTracker is not appropriate and the services are used locally, the > getService call should be followed by a try-finally block which always ungets > the service when done as is standard practice with resource management. > Finally, in places in which the service access is not contained in a local > method, and is stored in a field or passed around, proper resource release > should be performed (ungetService called and references nulled afterwards) in > an appropriate way for those cases (when closing or releasing the containing > class instance, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-3781) Problems occuring when dynamic creation of client with wsdl in https
[ https://issues.apache.org/jira/browse/CXF-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490205#comment-15490205 ] Andreas Vallen commented on CXF-3781: - For anyone else fighting with this issue, one possible albeit unpretty workaround is described here: http://stackoverflow.com/questions/15755293/apache-cxf-wsdl-download-via-ssl-tls > Problems occuring when dynamic creation of client with wsdl in https > > > Key: CXF-3781 > URL: https://issues.apache.org/jira/browse/CXF-3781 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.4.2 > Environment: Spring, JBoss, Apache CXF 2.4.2, Windows XP >Reporter: Guillaume JOUANJAN > > Hello , > First of all , sorry for my english , i'm a french developer. > My goal is to call dynamically web services method using a WSDL (the only > information i have + name of methods) > I've got a problem with the following code : > String urlWsdl = > "https://10.33.30.138:8443/eLBG-Server/WS/LogbookWS.LogbookWSHttpSoap12Endpoint?wsdl";; > JaxWsDynamicClientFactory factory = JaxWsDynamicClientFactory. > newInstance(); > Client clientWS = factory.createClient(urlWsdl); > I've got the following error : > 10:04:22,562 ERROR [[rmm-ata]] "Servlet.service()" pour la servlet rmm-ata a > g´┐¢n´┐¢r´┐¢ une exception > java.security.cert.CertificateException: No subject alternative names present > at sun.security.util.HostnameChecker.matchIP(Unknown Source) > at sun.security.util.HostnameChecker.match(Unknown Source) > at > com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(Unknown > Source) > at > com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown > Source) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown > Source) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) > at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) > at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown > Source) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown > Source) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown > Source) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown > Source) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown > Source) > at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown > Source) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown > Source) > at > org.apache.cxf.resource.URIResolver.tryFileSystem(URIResolver.java:167) > at org.apache.cxf.resource.URIResolver.(URIResolver.java:90) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.composeUrl(DynamicClientFactory.java:561) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:259) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:204) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:197) > at > org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:152) > at > com.airbus.rmm.controller.ManualController.send(ManualController.java:174) > I have specified a http conduit in spring configuration file but it seems > that information inside is not managed and the disableCNCheck=false is still > active > my http-conduit conf : > > disableCNCheck="true"> > > file="../classes/server.jks"/> > > > file="../classes/server.jks"/> > > > > .*_EXPORT_.* > .*_EXPORT1024_.* > .*_WITH_DES_.* > .*_WITH_NULL_.* > .*_DH_anon_.* > > > > nandana > password > > > > > I've tried also a http-conduit name ="https://10.33.30.138:8443/*"; but i've > got the same error. > org.springframework.web.util.NestedServletException: Request processing > failed; nested exception is > org.apache.cxf.service.factory.ServiceConstructionException: Could not > resolve URL > "https://10.33.30.138:8443/eLBG-Server/WS/LogbookWS.LogbookWSHttpSoap12Endpoint?wsdl";. > > org.springframework.web.servlet.Framewor
[jira] [Assigned] (DOSGI-155) Felix Multi-Bundle distro should not set org.osgi.framework.system.packages property
[
https://issues.apache.org/jira/browse/DOSGI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned DOSGI-155:
-
Assignee: Christian Schneider
> Felix Multi-Bundle distro should not set org.osgi.framework.system.packages
> property
>
>
> Key: DOSGI-155
> URL: https://issues.apache.org/jira/browse/DOSGI-155
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Product
>Affects Versions: 1.4.0
>Reporter: David Bosschaert
>Assignee: Christian Schneider
>Priority: Minor
>
> The multi-bundle distribution contains 2 felix configuration files:
> * conf/felix.config.properties.append
> * conf/felix.discovery.config.properties.append
> Both these files specify the *org.osgi.framework.system.packages* framework
> property:
> {noformat}org.osgi.framework.system.packages=org.osgi.framework;
> version=1.5.0, \
> org.osgi.framework.launch; version=1.0.0, \
> org.osgi.framework.hooks.service; version=1.0.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.4.0, \
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9, \
> javax.crypto, \
> javax.crypto.spec, \
> {noformat}
> and so on...
> This property should really be left specified by the framework itself as its
> value will depend on the version of the OSGi framework and the Java runtime
> used. The values specified are very likely incorrect in a number of cases
> (for example if you use the latest version of Felix, the org.osgi.* values
> are incomplete and the versions incorrect).
> It looks like the main thing here is to add the *org.apache.karaf* packages
> to the framework packages. This should really be done via the
> *org.osgi.framework.system.packages.extra* property, without specifying any
> of the packages provided by the framework or the JRE. E.g.
> {noformat}org.osgi.framework.system.packages.extra=\
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9{noformat}
> I briefly tried this but it seems there is an issue with resolving the
> javax.xml.stream package, and I noticed that in the current configuration it
> was actually removed from the list.
> So in order to fix this situation some work will need to be done make sure
> that the default value of the *org.osgi.framework.system.packages* property
> will work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-155) Felix Multi-Bundle distro should not set org.osgi.framework.system.packages property
[
https://issues.apache.org/jira/browse/DOSGI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490202#comment-15490202
]
Christian Schneider commented on DOSGI-155:
---
I think the reason why equinox works without the config is that they delegate
all class loading to the boot classloader as a fallback.
Btw. I was able to run the SOAP and RS examples using bndrun and only needed
these configs:
org.osgi.framework.bootdelegation=com.sun.*,\
org.osgi.framework.system.packages.extra='sun.misc,javax.xml.bind.annotation;version=2.2.1,javax.xml.bind;version=2.2.1'
This is not directly applicable to the multi bundle distro though as bndtools
resolves different bundles.
In mid term I plan to deprecate the mutli bundle distro and instead recommend
to use bndtools for non karaf purposes.
This does not help for eclipse RCP though. So I hope we can provide a distro
for RCP too - maybe in the form of a p2 repo and feature. I am not sure how
important this is though as I only know one of our customers who uses CXF in
Eclipse RCP.
> Felix Multi-Bundle distro should not set org.osgi.framework.system.packages
> property
>
>
> Key: DOSGI-155
> URL: https://issues.apache.org/jira/browse/DOSGI-155
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Product
>Affects Versions: 1.4.0
>Reporter: David Bosschaert
>Priority: Minor
>
> The multi-bundle distribution contains 2 felix configuration files:
> * conf/felix.config.properties.append
> * conf/felix.discovery.config.properties.append
> Both these files specify the *org.osgi.framework.system.packages* framework
> property:
> {noformat}org.osgi.framework.system.packages=org.osgi.framework;
> version=1.5.0, \
> org.osgi.framework.launch; version=1.0.0, \
> org.osgi.framework.hooks.service; version=1.0.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.4.0, \
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9, \
> javax.crypto, \
> javax.crypto.spec, \
> {noformat}
> and so on...
> This property should really be left specified by the framework itself as its
> value will depend on the version of the OSGi framework and the Java runtime
> used. The values specified are very likely incorrect in a number of cases
> (for example if you use the latest version of Felix, the org.osgi.* values
> are incomplete and the versions incorrect).
> It looks like the main thing here is to add the *org.apache.karaf* packages
> to the framework packages. This should really be done via the
> *org.osgi.framework.system.packages.extra* property, without specifying any
> of the packages provided by the framework or the JRE. E.g.
> {noformat}org.osgi.framework.system.packages.extra=\
> org.apache.karaf.jaas.boot; version=2.2.9, \
> org.apache.karaf.version; version=2.2.9{noformat}
> I briefly tried this but it seems there is an issue with resolving the
> javax.xml.stream package, and I noticed that in the current configuration it
> was actually removed from the list.
> So in order to fix this situation some work will need to be done make sure
> that the default value of the *org.osgi.framework.system.packages* property
> will work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-237) Upgrade Distributed OSGI to OSGI 5.0
[
https://issues.apache.org/jira/browse/DOSGI-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-237.
---
Resolution: Fixed
Assignee: Christian Schneider
Fix Version/s: 2.0.0
> Upgrade Distributed OSGI to OSGI 5.0
>
>
> Key: DOSGI-237
> URL: https://issues.apache.org/jira/browse/DOSGI-237
> Project: CXF Distributed OSGi
> Issue Type: Improvement
> Components: Product
>Affects Versions: 1.9.0
>Reporter: UniKnow
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
>
> Upgrade dOSGI to OSGI verion 5.0 by changing value of properties
> {{osgi.version}} and {{osgi.compendium.version}} from {{4.3.1}} into
> {{5.0.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-236) IllegalArgumentException: No SchemaFactory exception during build
[
https://issues.apache.org/jira/browse/DOSGI-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-236.
---
Resolution: Fixed
Assignee: Christian Schneider
Fix Version/s: 2.0.0
This is a bug in CXF Aegis. I found a workaround. The current 2.0-SNAPSHOT uses
the new CXF and works.
> IllegalArgumentException: No SchemaFactory exception during build
> -
>
> Key: DOSGI-236
> URL: https://issues.apache.org/jira/browse/DOSGI-236
> Project: CXF Distributed OSGi
> Issue Type: Bug
>Affects Versions: 1.9.0
> Environment: Windows, JDK 1.8 Maven 3.2.1
>Reporter: UniKnow
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
>
> When I execute the build by invoking {{mvn clean install}} some of the the
> 'Distributed OSGi System Tests Multi-Bundle' tests are failing due to the
> following exception:
> {code}
> [pool-7-thread-4] INFO
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean - Creating
> Service {http://greeter.samples.dosgi.cxf.apache.org/}GreeterService from
> class org.apache.cxf.dosgi.samples.greeter.GreeterService
> Exception in thread "pool-7-thread-4" java.lang.ExceptionInInitializerError
> at
> org.apache.cxf.aegis.AegisContext.createRootTypeCreator(AegisContext.java:119)
> at
> org.apache.cxf.aegis.AegisContext.createTypeCreator(AegisContext.java:108)
> at org.apache.cxf.aegis.AegisContext.initialize(AegisContext.java:150)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:233)
> at
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:467)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:179)
> at
> org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.exportService(PojoConfigurationTypeHandler.java:120)
> at
> org.apache.cxf.dosgi.dsw.handlers.CXFDistributionProvider.exportService(CXFDistributionProvider.java:80)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:184)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:117)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:55)
> at
> org.apache.aries.rsa.core.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:39)
> at
> org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(TopologyManagerExport.java:154)
> at
> org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport.doExport(TopologyManagerExport.java:125)
> at
> org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport.access$000(TopologyManagerExport.java:54)
> at
> org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport$1.run(TopologyManagerExport.java:98)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: No SchemaFactory that
> implements the schema language specified by: http://www.w3.org/2001/XMLSchema
> could be loaded
> at
> javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:215)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.(XMLTypeCreator.java:122)
> ... 27 more
> {code}
> (Example of failure in {{TestImportService}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-238) Problem found when using the latest CXF DOSGi
[ https://issues.apache.org/jira/browse/DOSGI-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490175#comment-15490175 ] Christian Schneider commented on DOSGI-238: --- I think this means that you have two bundles exporting the package javax.xml.stream. Can you check if this still occurs with the current 2.0-SNAPSHOT? > Problem found when using the latest CXF DOSGi > - > > Key: DOSGI-238 > URL: https://issues.apache.org/jira/browse/DOSGI-238 > Project: CXF Distributed OSGi > Issue Type: Task >Affects Versions: 1.7.0 >Reporter: Chenguang Zhang > Fix For: 2.0.0 > > > Hello Guys, > Recently, i am trying to build the OSGi environment for CXF using > DOSGi(version 1.7.0).I can see that CXF has cancelled to release singlebundle > for quite a long time.So i have to use the multibundle version. > To verify the environment, i just wrote two very simple bundles based on > JAX-WS rules to test it. > The problem is that when i make all the bundles run well,the the webservice > can not be published which means not signs to show the cxf has been running > successfully. > I can make sure that the bundle has started, it seems that the service is not > bound to CXF container.Some traces here: > Could you please help to find where is wrong? > (Please ignore the Chinese word below :-)) > osgi> org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/transports/http/configuration > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/bindings/soap > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/jaxws > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/simple > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [bundleresource://201.fwk4961455:2/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [bundleresource://201.fwk4961455:3/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.JCLLoggerFactory] > 五月 24, 2016 9:41:02 下午 org.slf4j.impl.JCLLoggerAdapter info > 信息: No quiesce support is available, so blueprint components will not > participate in quiesce operations > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-wsdl (169) > [org.apache.cxf.wsdl.WSDLManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-xml > (176) [org.apache.cxf.binding.xml.XMLBindingFactory, > org.apache.cxf.binding.xml.wsdl11.XMLWSDLExtensionLoader] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http > (177) [org.apache.cxf.transport.http.HTTPTransportFactory, > org.apache.cxf.transport.http.HTTPWSDLExtensionLoader, > org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder, > org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder, > org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-soap > (184) [org.apache.cxf.binding.soap.SoapBindingFactory, > org.apache.cxf.binding.soap.SoapTransportFactory] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-management (189) > [org.apache.cxf.management.InstrumentationManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-frontend-jaxws > (193) [org.apache.cxf.jaxws.context.WebServiceContextResourceResolver] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle > org.apache.cxf.cxf-rt-transports-http-jetty (204) > [org.apache.cxf.transport.http_jetty.JettyDestinationFactory, > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory, > org.apache.cxf.transport.http.ContinuationProviderFactory] > 五月 24, 2016 9:41:02 下午 > org.apache
[jira] [Updated] (DOSGI-238) Problem found when using the latest CXF DOSGi
[ https://issues.apache.org/jira/browse/DOSGI-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-238: -- Fix Version/s: 2.0.0 > Problem found when using the latest CXF DOSGi > - > > Key: DOSGI-238 > URL: https://issues.apache.org/jira/browse/DOSGI-238 > Project: CXF Distributed OSGi > Issue Type: Task >Affects Versions: 1.7.0 >Reporter: Chenguang Zhang > Fix For: 2.0.0 > > > Hello Guys, > Recently, i am trying to build the OSGi environment for CXF using > DOSGi(version 1.7.0).I can see that CXF has cancelled to release singlebundle > for quite a long time.So i have to use the multibundle version. > To verify the environment, i just wrote two very simple bundles based on > JAX-WS rules to test it. > The problem is that when i make all the bundles run well,the the webservice > can not be published which means not signs to show the cxf has been running > successfully. > I can make sure that the bundle has started, it seems that the service is not > bound to CXF container.Some traces here: > Could you please help to find where is wrong? > (Please ignore the Chinese word below :-)) > osgi> org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/transports/http/configuration > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/bindings/soap > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/jaxws > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/simple > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [bundleresource://201.fwk4961455:2/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [bundleresource://201.fwk4961455:3/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > SLF4J: Actual binding is of type [org.slf4j.impl.JCLLoggerFactory] > 五月 24, 2016 9:41:02 下午 org.slf4j.impl.JCLLoggerAdapter info > 信息: No quiesce support is available, so blueprint components will not > participate in quiesce operations > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-wsdl (169) > [org.apache.cxf.wsdl.WSDLManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-xml > (176) [org.apache.cxf.binding.xml.XMLBindingFactory, > org.apache.cxf.binding.xml.wsdl11.XMLWSDLExtensionLoader] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http > (177) [org.apache.cxf.transport.http.HTTPTransportFactory, > org.apache.cxf.transport.http.HTTPWSDLExtensionLoader, > org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder, > org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder, > org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-bindings-soap > (184) [org.apache.cxf.binding.soap.SoapBindingFactory, > org.apache.cxf.binding.soap.SoapTransportFactory] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-management (189) > [org.apache.cxf.management.InstrumentationManager] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle org.apache.cxf.cxf-rt-frontend-jaxws > (193) [org.apache.cxf.jaxws.context.WebServiceContextResourceResolver] > 五月 24, 2016 9:41:02 下午 org.apache.cxf.bus.osgi.CXFExtensionBundleListener > addExtensions > 信息: Adding the extensions from bundle > org.apache.cxf.cxf-rt-transports-http-jetty (204) > [org.apache.cxf.transport.http_jetty.JettyDestinationFactory, > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory, > org.apache.cxf.transport.http.ContinuationProviderFactory] > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer register > 信息: Registered blueprint namespace handler for > http://cxf.apache.org/blueprint/core > 五月 24, 2016 9:41:02 下午 > org.apache.cxf.
[jira] [Resolved] (FEDIZ-173) Cors support for js OIDC Implicit Flow
[ https://issues.apache.org/jira/browse/FEDIZ-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved FEDIZ-173. Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 1.3.2 > Cors support for js OIDC Implicit Flow > -- > > Key: FEDIZ-173 > URL: https://issues.apache.org/jira/browse/FEDIZ-173 > Project: CXF-Fediz > Issue Type: Improvement > Components: OIDC >Reporter: gonzalad >Assignee: Sergey Beryozkin > Fix For: 1.3.2 > > > Provide OOB support for Cors request on all endpoints used by javascript > clients (jwk and userInfo). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-173) Cors support for js OIDC Implicit Flow
[ https://issues.apache.org/jira/browse/FEDIZ-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490152#comment-15490152 ] Sergey Beryozkin commented on FEDIZ-173: Adrian, thanks for the patch, I did a tiny update - application context already uses util:list. thanks > Cors support for js OIDC Implicit Flow > -- > > Key: FEDIZ-173 > URL: https://issues.apache.org/jira/browse/FEDIZ-173 > Project: CXF-Fediz > Issue Type: Improvement > Components: OIDC >Reporter: gonzalad > > Provide OOB support for Cors request on all endpoints used by javascript > clients (jwk and userInfo). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-173) Cors support for js OIDC Implicit Flow
[ https://issues.apache.org/jira/browse/FEDIZ-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490148#comment-15490148 ] ASF GitHub Bot commented on FEDIZ-173: -- Github user asfgit closed the pull request at: https://github.com/apache/cxf-fediz/pull/9 > Cors support for js OIDC Implicit Flow > -- > > Key: FEDIZ-173 > URL: https://issues.apache.org/jira/browse/FEDIZ-173 > Project: CXF-Fediz > Issue Type: Improvement > Components: OIDC >Reporter: gonzalad > > Provide OOB support for Cors request on all endpoints used by javascript > clients (jwk and userInfo). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7054) CORBADocLitClientTypeTest failed with java9
[
https://issues.apache.org/jira/browse/CXF-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490140#comment-15490140
]
Grzegorz Grzybek commented on CXF-7054:
---
I know what's happening (sort of). With {{\--patch-module java.corba=xxx}}, we
actually use jacorb's ORB class. which uses jacorb's class for default ORB
class name.
after this diff:
{noformat}
diff --git a/systests/uncategorized/pom.xml b/systests/uncategorized/pom.xml
index e5a8380..fdff3de 100644
--- a/systests/uncategorized/pom.xml
+++ b/systests/uncategorized/pom.xml
@@ -457,6 +457,9 @@
org.apache.maven.plugins
maven-surefire-plugin
+
+
com.sun.corba.se.impl.orb.ORBImpl
+
${cxf.surefire.fork.vmargs}
--patch-module java.corba=target/java9-jacorb
{noformat}
I brought back SUN's ORB implementation and got back to these failures:
{noformat}
Results :
Failed tests:
CORBADocLitClientTypeTest>AbstractTypeTestClient.testUnsignedShort:244->Assert.assertEquals:118->Assert.failNotEquals:834->Assert.fail:88
testUnsignedShort(): Incorrect value for out param expected:<65535> but
was:<-1>
Tests in error:
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testAnonymousStruct:260 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testBase64Binary:1349 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testBoundedArray:397 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient3.testChoiceWithBinary:1444 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testColourEnum:1429 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testCompoundArray:490 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testDecimal:1139 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testDecimalEnum:1524 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient3.testDerivedEmptyBaseEmptyAll:538
» CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient3.testDerivedEmptyBaseEmptyChoice:567
» CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testEmptyAll:792 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testEmptyChoice:722 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testFixedArray:364 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testHexBinary:1324 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient5.testMixedArray:453 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient3.testMultipleOccursSequenceInSequence:1361
» CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testNMTokenEnum:1557 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testNestedArray:533 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient.testNumberEnum:1461 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testSimpleChoice:765 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient3.testStructWithBinary:1401 »
CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testStructWithNillables:219
» CorbaBinding
CORBADocLitClientTypeTest>AbstractTypeTestClient2.testUnboundedArray:452 »
CorbaBinding
{noformat}
I wonder if jacorb revealed some problems with SUN's implementation?
Looks like failures like "Caused by: org.omg.CORBA.BAD_PARAM: Illegal enum
member name: a b c" with Jacorb are _better_ than:
{noformat}
Caused by: java.lang.ClassCastException:
org.apache.cxf.binding.corba.runtime.CorbaStreamableImpl (in module: Unnamed
Module) cannot be cast to java.math.BigDecimal (in module: java.base)
at
com.sun.corba.se.impl.corba.TCUtility.marshalIn(java.corba@9-internal/TCUtility.java:158)
at
com.sun.corba.se.impl.corba.AnyImpl.write_value(java.corba@9-internal/AnyImpl.java:613)
at
com.sun.corba.se.impl.corba.RequestImpl.doInvocation(java.corba@9-internal/RequestImpl.java:312)
at
com.sun.corba.se.impl.corba.RequestImpl.invoke(java.corba@9-internal/RequestImpl.java:246)
at
org.apache.cxf.binding.corba.CorbaConduit.buildRequest(CorbaConduit.java:194)
...
{noformat}
or
{noformat}
Caused by: org.omg.CORBA.MARSHAL:
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(java.corba@9-internal/ORBUtilSystemException.java:6890)
at
com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(java.corba@9-internal/ORBUtilSystemException.java:6912)
at
com.sun.corba.se.impl.encoding.BufferManagerReadStream.underflow(java.corba@9-internal/BufferManagerReadStream.java:112)
at
com.sun.corba.se.impl.encoding.CDRInputStream_1_1.grow(java.corba@9-internal/CDRInputStr
[jira] [Commented] (CXF-7054) CORBADocLitClientTypeTest failed with java9
[ https://issues.apache.org/jira/browse/CXF-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490108#comment-15490108 ] Grzegorz Grzybek commented on CXF-7054: --- [~ffang] I need master's advice about my change to core/src/main/java/org/apache/cxf/common/util/ASMHelper.java... > CORBADocLitClientTypeTest failed with java9 > --- > > Key: CXF-7054 > URL: https://issues.apache.org/jira/browse/CXF-7054 > Project: CXF > Issue Type: Sub-task >Reporter: Freeman Fang >Assignee: Freeman Fang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7054) CORBADocLitClientTypeTest failed with java9
[
https://issues.apache.org/jira/browse/CXF-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490105#comment-15490105
]
Grzegorz Grzybek commented on CXF-7054:
---
With this diff:
{noformat}
12:38 $ git diff
diff --git a/core/src/main/java/org/apache/cxf/common/util/ASMHelper.java
b/core/src/main/java/org/apache/cxf/common/util/ASMHelper.java
index 7e64216..67df68d 100644
--- a/core/src/main/java/org/apache/cxf/common/util/ASMHelper.java
+++ b/core/src/main/java/org/apache/cxf/common/util/ASMHelper.java
@@ -372,7 +372,15 @@ public class ASMHelper {
public Class lookupDefinedClass(String name) {
return defined.get(name.replace('/', '.'));
}
-
+
+@Override
+protected Class findClass(String name) throws
ClassNotFoundException {
+if (name.endsWith("package-info")) {
+return getParent().loadClass(name);
+}
+return super.findClass(name);
+}
+
public Class defineClass(String name, byte bytes[]) {
Class ret = defined.get(name.replace('/', '.'));
if (ret != null) {
{noformat}
I was able to fix most of {{CORBADocLitClientTypeTest}} problems and the
remaining were:
{noformat}
Results :
Failed tests:
CORBADocLitClientTypeTest>AbstractTypeTestClient.testSimpleRestriction:1636->Assert.fail:88
x parameter maxLength=10 restriction is violated.
CORBADocLitClientTypeTest>AbstractTypeTestClient.testSimpleRestriction4:1784->Assert.fail:88
x parameter minLength=5 restriction is violated.
Tests in error:
CORBADocLitClientTypeTest>AbstractTypeTestClient.testAnyURIEnum:1589 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient.testDecimalEnum:1524 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient.testNumberEnum:1461 »
WebService
CORBADocLitClientTypeTest>AbstractTypeTestClient.testStringEnum:1492 »
WebService
{noformat}
probably because now my test used {{--patch-module
java.corba=target/java9-jacorb}}. Hmm, Jacorb shouldn't be used without
explicit:
{code:java}
System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
System.setProperty("org.omg.CORBA.ORBSingletonClass",
"org.jacorb.orb.ORBSingleton");
{code}
Here are all exceptions:
{noformat}
testSimpleRestriction4(org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest)
Time elapsed: 0.071 sec <<< FAILURE!
java.lang.AssertionError: x parameter minLength=5 restriction is violated.
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.cxf.systest.type_test.AbstractTypeTestClient.testSimpleRestriction4(AbstractTypeTestClient.java:1784)
...
{noformat}
{noformat}
testDecimalEnum(org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest)
Time elapsed: 0.061 sec <<< ERROR!
javax.xml.ws.WebServiceException: org.apache.cxf.interceptor.Fault: Marshalling
Error: Illegal enum member name: -10.34
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:169)
...
Caused by: org.omg.CORBA.BAD_PARAM: Illegal enum member name: -10.34
at org.jacorb.orb.ORBSingleton.create_enum_tc(ORBSingleton.java:464)
at org.jacorb.orb.ORBSingleton.create_enum_tc(ORBSingleton.java:421)
at
org.apache.cxf.binding.corba.utils.CorbaUtils.getComplexTypeCode(CorbaUtils.java:213)
{noformat}
{noformat}
testNumberEnum(org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest)
Time elapsed: 0.022 sec <<< ERROR!
javax.xml.ws.WebServiceException: org.apache.cxf.interceptor.Fault: Marshalling
Error: Illegal enum member name: 1
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:169)
...
Caused by: org.omg.CORBA.BAD_PARAM: Illegal enum member name: 1
at org.jacorb.orb.ORBSingleton.create_enum_tc(ORBSingleton.java:464)
at org.jacorb.orb.ORBSingleton.create_enum_tc(ORBSingleton.java:421)
at
org.apache.cxf.binding.corba.utils.CorbaUtils.getComplexTypeCode(CorbaUtils.java:213)
{noformat}
{noformat}
testSimpleRestriction(org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest)
Time elapsed: 0.033 sec <<< FAILURE!
java.lang.AssertionError: x parameter maxLength=10 restriction is violated.
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.cxf.systest.type_test.AbstractTypeTestClient.testSimpleRestriction(AbstractTypeTestClient.java:1636)
...
{noformat}
{noformat}
testAnyURIEnum(org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest)
Time elapsed: 0.015 sec <<< ERROR!
javax.xml.ws.WebServiceException: org.apache.cxf.interceptor.Fault: Marshalling
Error: Illegal enum member name: http://www.iona.com
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:169)
at com.sun.proxy.$Proxy63.testAnyURIEnum(Unknown Source)
...
Caused by: org.omg.CORBA.BAD_PARAM: Illegal enum member name:
http://www.iona.com
[jira] [Resolved] (FEDIZ-174) Update CXF version to 3.1.8-SNAPSHOT
[ https://issues.apache.org/jira/browse/FEDIZ-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved FEDIZ-174. Resolution: Fixed > Update CXF version to 3.1.8-SNAPSHOT > > > Key: FEDIZ-174 > URL: https://issues.apache.org/jira/browse/FEDIZ-174 > Project: CXF-Fediz > Issue Type: Task > Components: IDP >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 1.3.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7054) CORBADocLitClientTypeTest failed with java9
[
https://issues.apache.org/jira/browse/CXF-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490091#comment-15490091
]
Grzegorz Grzybek commented on CXF-7054:
---
The problem is with {{java.lang.Package#getPackageInfo()}}.
JDK8 does:
{code:java}
packageInfo = Class.forName(pkgName + ".package-info", false, loader);
{code}
and JDK9 does:
{code:java}
String cn = packageName() + ".package-info";
PrivilegedAction pa = module()::getClassLoader;
ClassLoader loader = AccessController.doPrivileged(pa);
Class c = loader != null ? loader.loadLocalClass(cn)
: BootLoader.loadClassOrNull(cn);
{code}
so JDK8 uses delegation and JDK9 simply can't find {{package-info}}, because it
was never _defined_ by
{{org.apache.cxf.common.util.ASMHelper.TypeHelperClassLoader}}. And these
classes generated ({{helper.loadClass(className + "Extensibility", loader,
bytes)}} by {{org.apache.cxf.wsdl.JAXBExtensionHelper#createExtensionClass()}}
have actually different module assigned.
> CORBADocLitClientTypeTest failed with java9
> ---
>
> Key: CXF-7054
> URL: https://issues.apache.org/jira/browse/CXF-7054
> Project: CXF
> Issue Type: Sub-task
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FEDIZ-174) Update CXF version to 3.1.8-SNAPSHOT
Sergey Beryozkin created FEDIZ-174: -- Summary: Update CXF version to 3.1.8-SNAPSHOT Key: FEDIZ-174 URL: https://issues.apache.org/jira/browse/FEDIZ-174 Project: CXF-Fediz Issue Type: Task Components: IDP Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 1.3.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-112) eroor on deploying cxf-dosgi-ri-singlebundle-distribution bundle in glassfish
[ https://issues.apache.org/jira/browse/DOSGI-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-112. --- Resolution: Cannot Reproduce Assignee: Christian Schneider > eroor on deploying cxf-dosgi-ri-singlebundle-distribution bundle in glassfish > - > > Key: DOSGI-112 > URL: https://issues.apache.org/jira/browse/DOSGI-112 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: anwar >Assignee: Christian Schneider > > when I deploy the greeting sample bundles with the > cxf-dosgi-ri-singlebundle-distribution-1.3.jar in an independent Felix > framework instance it works. > But if I deploy the bundles in glassfish 3.1.2 I get this error when srating > the glasfish domain : > > [#|2012-03-10T22:55:29.310+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=21;_ThreadName=pool-7-thread-2;|Exception > in thread "pool-7-thread-2" |#] > [#|2012-03-10T22:55:29.312+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=21;_ThreadName=pool-7-thread-2;|java.lang.ClassCastException: > org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator cannot > be cast to org.osgi.serv > ice.event.EventAdmin > at > org.apache.cxf.dosgi.dsw.service.EventAdminHelper.getEventAdmins(EventAdminHelper.java:127) > at > org.apache.cxf.dosgi.dsw.service.EventAdminHelper.notifyEventAdmin(EventAdminHelper.java:97) > at > org.apache.cxf.dosgi.dsw.service.EventProducer.publishNotifcation(EventProducer.java:62) > at > org.apache.cxf.dosgi.dsw.service.EventProducer.publishNotifcation(EventProducer.java:47) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:265) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:72) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:67) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:66) > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:38) > at > org.apache.cxf.dosgi.topologymanager.TopologyManager$2.run(TopologyManager.java:267) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > |#] > [#|2012-03-10T22:55:29.416+0100|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=18;_ThreadName=fileinstall-D:\DevTools\glassfish-3.1.2\glassfish-3.1.2\glassfish\domains\domain1/autodeploy/bundles/;|Failed > to update artifact D:\DevTools\glassfish > -3.1.2\glassfish-3.1.2\glassfish\domains\domain1\autodeploy\bundles\cxf-dosgi-ri-singlebundle-distribution-1.3.jar: > java.lang.IllegalStateException: Invalid BundleContext.|#] > [#|2012-03-10T22:55:29.416+0100|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=18;_ThreadName=fileinstall-D:\DevTools\glassfish-3.1.2\glassfish-3.1.2\glassfish\domains\domain1/autodeploy/bundles/;|java.lang.IllegalStateException: > Invalid Bundle > Context. > at > org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514) > at > org.apache.felix.framework.BundleContextImpl.getDataFile(BundleContextImpl.java:491) > at > org.apache.felix.fileinstall.internal.Util.storeChecksum(Util.java:293) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:1064) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.update(DirectoryWatcher.java:849) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:445) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-117) Stopping single bundle distribution hits NPE at org.apache.felix.cm.impl.ConfigurationManager.stop line: 267
[ https://issues.apache.org/jira/browse/DOSGI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-117. --- Resolution: Won't Fix Assignee: Christian Schneider The single bundle distro is not supported anymore. > Stopping single bundle distribution hits NPE at > org.apache.felix.cm.impl.ConfigurationManager.stop line: 267 > > > Key: DOSGI-117 > URL: https://issues.apache.org/jira/browse/DOSGI-117 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.3 > Environment: CXF single bundle distribution 1.3.0 > ZooKeeper 3.4.3 > java version "1.6.0_29" > Mac OS X 10.7.3 >Reporter: Glyn Normington >Assignee: Christian Schneider > > The following NPE occurs in Felix Config Admin when stopping the single > bundle distribution of CXF dosgi. It seems likely that the NPE will be fixed > by FELIX-2813 which was implemented in Felix Config Admin 1.4.0, so the fix > to this bug is to upgrade Felix Config Admin to 1.4.0. > Daemon Thread [Thread-34] (Suspended (exception > java.lang.NullPointerException)) > > org.apache.felix.cm.impl.ConfigurationManager.stop(org.osgi.framework.BundleContext) > line: 267 > > org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stopEmbeddedActivators(org.osgi.framework.BundleContext) > line: 137 > > org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stop(org.osgi.framework.BundleContext) > line: 51 > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run() > line: 771 > > java.security.AccessController.doPrivileged(java.security.PrivilegedExceptionAction) > line: not available [native method] > org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop() line: > 764 > org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(int) > line: 510 > > org.eclipse.osgi.framework.internal.core.BundleHost(org.eclipse.osgi.framework.internal.core.AbstractBundle).stop(int) > line: 464 > org.apache.felix.gogo.command.Basic.stop(boolean, > org.osgi.framework.Bundle[]) line: 817 > sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, > java.lang.Object, java.lang.Object[]) line: not available [native method] > > sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 39 > sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 25 > java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) > line: 597 > > org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, > java.lang.Object, java.lang.String, java.util.List) line: > 136 > > org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 82 > org.apache.felix.gogo.runtime.Closure.executeCmd(java.lang.String, > java.util.List) line: 469 > > org.apache.felix.gogo.runtime.Closure.executeStatement(java.util.List) > line: 395 > org.apache.felix.gogo.runtime.Pipe.run() line: 108 > > org.apache.felix.gogo.runtime.Closure.execute(java.util.List) > line: 183 > > org.apache.felix.gogo.runtime.Closure.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 120 > > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(java.lang.CharSequence) > line: 89 > org.apache.felix.gogo.shell.Console.run() line: 62 > > org.apache.felix.gogo.shell.Shell.console(org.apache.felix.service.command.CommandSession) > line: 203 > > org.apache.felix.gogo.shell.Shell.gosh(org.apache.felix.service.command.CommandSession, > java.lang.String[]) line: 128 > sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, > java.lang.Object, java.lang.Object[]) line: not available [native method] > > sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 39 > sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) line: 25 > java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) > line: 597 > > org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, > java.lang.Object, java.lang.String, java.util.List) line: > 136 > > org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, > java.util.List) line: 82 > org.apache.felix.gogo.runtime.Closure.executeCmd(java.
[jira] [Commented] (DOSGI-122) CXF DOSGi does not work with ctx.getServiceReferences()
[ https://issues.apache.org/jira/browse/DOSGI-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490055#comment-15490055 ] Christian Schneider commented on DOSGI-122: --- Any update on this? > CXF DOSGi does not work with ctx.getServiceReferences() > --- > > Key: DOSGI-122 > URL: https://issues.apache.org/jira/browse/DOSGI-122 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Affects Versions: 1.4.0 >Reporter: David Bosschaert > > CXF-DOSGi doesn't find a remote service is the lookup is done with the > following OSGi API: > bundleContext.getServiceReferences() > However it does work fine when using a ServiceTracker. > This is probably caused by a missing FindHook (see the OSGi Core > Specification, Service Hooks chapter). > We also need to make sure that getServiceReference() and > getAllServiceReferences() works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-106) DSW can not get a handle to OSGI HttpService when a single-bundle distribution is installed
[ https://issues.apache.org/jira/browse/DOSGI-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-106. --- Resolution: Won't Fix Assignee: Christian Schneider Closing this as we do not support the single bundle distro anymore. > DSW can not get a handle to OSGI HttpService when a single-bundle > distribution is installed > --- > > Key: DOSGI-106 > URL: https://issues.apache.org/jira/browse/DOSGI-106 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Attachments: singlebundle.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-101) Update the guide on using DOSGI RI withing Eclipse
[ https://issues.apache.org/jira/browse/DOSGI-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-101. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 I removed the wiki entry. In the examples I now recommend to import the examples using M2E. For debugging in karaf there is documentation in karaf. For plain felix I added an example with a bndtools runner that also allows easy debug. > Update the guide on using DOSGI RI withing Eclipse > -- > > Key: DOSGI-101 > URL: https://issues.apache.org/jira/browse/DOSGI-101 > Project: CXF Distributed OSGi > Issue Type: Improvement >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 2.0.0 > > > several users reported that > http://cxf.apache.org/setting-up-eclipse-for-running-and-debugging-distributed-osgi.html > was not up to date > David - have a look please; take all the time you need please :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-52) -Dorg.apache.cxf.spring.validation.mode=VALIDATION_NONE doesn't have an effect
[ https://issues.apache.org/jira/browse/DOSGI-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-52. -- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 This should be fixed with current CXF versions. > -Dorg.apache.cxf.spring.validation.mode=VALIDATION_NONE doesn't have an effect > -- > > Key: DOSGI-52 > URL: https://issues.apache.org/jira/browse/DOSGI-52 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW, Product >Affects Versions: 1.1 >Reporter: David Bosschaert >Assignee: Christian Schneider > Fix For: 2.0.0 > > > Reported by Shulok, Thomas > http://old.nabble.com/-DOSGI--cxf-2.2.5-in-the-DOSGI-1.2-snapshot-download--td26880487.html > When using CXF 2.2.5 > -Dorg.apache.cxf.spring.validation.mode=VALIDATION_NONE > (the rationale for going to 2.2.5) doesn't seem to have an effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-8) Need to support all value data types for multi-value service properties
[ https://issues.apache.org/jira/browse/DOSGI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-8. - Resolution: Cannot Reproduce Assignee: Christian Schneider > Need to support all value data types for multi-value service properties > --- > > Key: DOSGI-8 > URL: https://issues.apache.org/jira/browse/DOSGI-8 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert >Assignee: Christian Schneider > > In OSGi all service properties that are potentially multi-value, need to > support the following data types: > String, String[] or a Collection of Strings > In the CXF DOSGi code, this is currently not the case everywhere, so we need > to double check/ensure all the service properties and ensure that they > support this flexibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-14) Need to properly handle the ServiceEndpointDescription.getVersion() information.
[ https://issues.apache.org/jira/browse/DOSGI-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-14. -- Resolution: Fixed Assignee: Christian Schneider This should be covered now by Aries RSA. Can you recheck? > Need to properly handle the ServiceEndpointDescription.getVersion() > information. > > > Key: DOSGI-14 > URL: https://issues.apache.org/jira/browse/DOSGI-14 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert >Assignee: Christian Schneider > > The ServiceEndpointDescription contains the version of the interface. This > version number needs to be taken into account when creating the client-side > proxy. > The PackageAdmin specification might help here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-6) dOSGi startup blocks in some cases when other bundles already wait for remote services
[ https://issues.apache.org/jira/browse/DOSGI-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-6. - Resolution: Cannot Reproduce Assignee: Christian Schneider Please reopen if this still happens > dOSGi startup blocks in some cases when other bundles already wait for remote > services > -- > > Key: DOSGI-6 > URL: https://issues.apache.org/jira/browse/DOSGI-6 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: Marc Schaaf >Assignee: Christian Schneider >Priority: Minor > Attachments: Activator_ListenerHook_Bug.patch > > > When the distributed OSGi bundle is deployed in an OSGi container where > already one or more bundles are waiting for remote services, the start-up > blocks until the remote calls of the other bundles are finished if the other > bundles does these calls inside the callback method of the ServiceTracker. > This happens because the registration of the service hook by the distributed > OSGi bundle blocks in the mentioned case. > It looks like the hook is instantly informed about already existing service > listeners. The hook than registers the the proxy services which causes the > execution of the service listeners of the other bundles. The other bundles > than make their remote calls from within the addingService method of the > ServiceTracker. All of this seems to happen in the start-up Thread which > causes the start-up of the distributed OSGi bundle to block until the remote > calls are finished. > Placing the registration of the hook in a different thread seems to solve the > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-20) Get rid of the DynamicImport-Package="*"
[ https://issues.apache.org/jira/browse/DOSGI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-20. -- Resolution: Fixed Assignee: Christian Schneider We do not have the dynamic import anymore. > Get rid of the DynamicImport-Package="*" > > > Key: DOSGI-20 > URL: https://issues.apache.org/jira/browse/DOSGI-20 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert >Assignee: Christian Schneider > > The current DOSGi implementation uses DynamicImport-Package="*". While this > is very convenient, it is potentially unpredictable and could have serious > performance side effects. Therefore it would be better to remove this > dependency and potentially use direct OSGi API to find the required package > potentially via the PackageAdmin only when we need to do this type of thing > i.e. when a proxy is created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-22) It would benefit the RFC 119 TCK if multiple instances of DOSGi could be run in a single OSGi container.
[ https://issues.apache.org/jira/browse/DOSGI-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-22. -- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 CXF DOSGi already uses two DistributionProviders (ws and rs) now. > It would benefit the RFC 119 TCK if multiple instances of DOSGi could be run > in a single OSGi container. > > > Key: DOSGI-22 > URL: https://issues.apache.org/jira/browse/DOSGI-22 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert >Assignee: Christian Schneider > Fix For: 2.0.0 > > > A number of scenarios in RFC 119 concern about what happens when multiple > distribution providers run in a single OSGi container. To be able to test > these use-cases with OSGi it would be quite useful if CXF-DOSGi could be > installed twice in the same OSGi container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-19) Discovery Software doesn't notice changed Service Properties.
[ https://issues.apache.org/jira/browse/DOSGI-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-19. -- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 This should work now. I tested this with a DS based service that I enabled for export after it was published. > Discovery Software doesn't notice changed Service Properties. > -- > > Key: DOSGI-19 > URL: https://issues.apache.org/jira/browse/DOSGI-19 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: Discovery >Reporter: Michael Gerlinger >Assignee: Christian Schneider > Fix For: 2.0.0 > > > If a service is allready registered at the Service Platform without any > "remote service properties" and it's properties become changeg e.g. by using > ConfigAdmin Service, the DSW doesn't notice this chages. At this time, it is > nessecary to update the DSW to get the changed service remote accessible. > It would be nice, if the DSW could notice changed service properties and > create ServicePublications if "osgi.remote." propoerties are set afterwards > via ConfigAdmin Service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-51) Passing an object to the server doesn't work correctly
[ https://issues.apache.org/jira/browse/DOSGI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-51. -- Resolution: Fixed Assignee: Christian Schneider I am closing this as the issue is so old. If the problem still occurs feel free to open a new issue based on the current CXF DOSGi version. > Passing an object to the server doesn't work correctly > -- > > Key: DOSGI-51 > URL: https://issues.apache.org/jira/browse/DOSGI-51 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.0, 1.1 > Environment: OS: Linux Debian Lenny > Java: Sun JDK 1.6.0 Update 13 > OSGi: Equinox 3.5.0.v20090520 > CXF/DOSGi: Single Bundle Distribution 1.0/1.1.SNAPSHOT >Reporter: Saul Goode >Assignee: Christian Schneider > Attachments: PassObjectClient_1.0.0.tryout.jar, > PassObjectInterface_1.0.0.tryout.jar, PassObjectServer_1.0.0.tryout.jar > > > I've got a Service PassObject exposed by CXF/DOSGi running on the server. > This service contains a method passAnObject which receives an object of type > MathHelper. MathHelper is an interface known both to the server and client. > The method passAnObject calls the methods MathHelper.getName() and > MathHelper.isGreaterThanZero(int) on the received object. When the client > calls the method passAnObject and passes an object which implements > MathHelper the following happens: The call to getName works as expected and > returns a String. But the call to the other method raises an exception on the > server (stack trace appended). I have this problem with both 1.0 and the > 1.1.SNAPSHOT. > Is it unsupported to pass objects to a remote service provider? Or is this > some kind of bug? > I didn't find an option to upload sth, so I uploaded the sample code to: > http://ul.to/4vlftz > The archive contains the server, client and interface bundles. The interface > bundle runs on both the server and client. > Server-side Exception output by OSGi with Single Bundle Distribution 1.0: > 02.09.2009 17:29:10 org.apache.cxf.phase.PhaseInterceptorChain doIntercept > INFO: Application has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: isGreaterZero is not delegated. > at > org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:114) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:95) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:302) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:265) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) > Caused by: java.lang.IllegalAccessError: isGreaterZero is not delegated. > at > org.apache.cxf.aegis.type.basic.InterfaceInvocationHandler.invoke(InterfaceInvocationHandler.java:57) > at $Proxy33.isGreaterZero(Unknown
[jira] [Resolved] (DOSGI-23) ServiceListener without objectClass
[ https://issues.apache.org/jira/browse/DOSGI-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-23. -- Resolution: Won't Fix Assignee: Christian Schneider I think we can not easily support listeners without objectClass as this might trigger to import all services. > ServiceListener without objectClass > --- > > Key: DOSGI-23 > URL: https://issues.apache.org/jira/browse/DOSGI-23 > Project: CXF Distributed OSGi > Issue Type: New Feature > Components: Discovery > Environment: felix-2.0.1 >Reporter: Alexander Broekhuis >Assignee: Christian Schneider > > Remote service endpoints are created using the CxfFindListenerHook if a > listener is added with a filter on a service classname. Currently in the > CxfFindListenerHook there is a check to see if objectClass is filled in. If > this is not the case, the discovery is not accessed to look for remote > services. If a listener is added to get a remote service based only on other > properties, no endpoints are created. > As a side note when a listener is added with a filter on > service.imported=true: > The imported property is only set on the imported proxy registration, and not > part of the actual remote service. So it isn't published in discovery. In > this case the service listener could be notified of all remote services found > in the discovery. > See > http://old.nabble.com/-DOSGI--ServiceListener-without-objectClass-td26739822.html > for the thread on the mailing list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-73) OSGi Declarative Service-based consumer does not register proxy service on demand
[
https://issues.apache.org/jira/browse/DOSGI-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-73.
--
Resolution: Fixed
Assignee: Christian Schneider
Fix Version/s: 2.0.0
I switched the tests to DS and can not observe this problem anymore. I guess
this was fixed in scr.
> OSGi Declarative Service-based consumer does not register proxy service on
> demand
> -
>
> Key: DOSGI-73
> URL: https://issues.apache.org/jira/browse/DOSGI-73
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.2
> Environment: Equinox 3.6 with DS
>Reporter: David Bosschaert
>Assignee: Christian Schneider
> Fix For: 2.0.0
>
>
> When using OSGi Declarative Services (DS) you can express interest in an OSGi
> service through an XML descriptor, like this one (from the samples/ds demo):
> {code:xml}http://www.osgi.org/xmlns/scr/v1.1.0";
> name="DS Consumer Sample" activate="start">
> class="org.apache.cxf.dosgi.samples.ds.consumer.AdderConsumer"/>
> name="AdderService" cardinality="1..1" policy="dynamic" bind="bindAdder"
> unbind="unbindAdder"/>
> {code}
> The declarative services implementation will then inject your service into
> your component.
> With CXF-DOSGi a remote service is always registered on-the-fly when a
> service is requested. This is done through a ListenerHook. The listenerhook
> gets called with the filter of services that are looked up by a consumer,
> e.g. what the consumer passed in to a ServiceTracker.
> It seems like the DS implementation uses a single tracker or listener for all
> the services it's interested in, which probably uses an empty filter. This is
> currently ignored by the CXF-DOSGi listener hook implementation, which means
> that the AdderService proxy is not automatically injected in the component.
> There is a workaround. Simply create a bundle (any bundle) in the consumer
> that registers a service tracker to listen for the service that you want to
> be discovered remotely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-152) Update systests2 to use pax-exam 2.5
[ https://issues.apache.org/jira/browse/DOSGI-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-152. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 > Update systests2 to use pax-exam 2.5 > > > Key: DOSGI-152 > URL: https://issues.apache.org/jira/browse/DOSGI-152 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: DSW >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 2.0.0 > > Attachments: paxexam.diff > > > Single bundle distro tests are hanging if DOSGI-106 patch is applied. I think > it is most likely to do with the old pax-exam dependencies. Moving to > pax-exam 3.0 would also let the tests run against specific containers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-157) Single-Bundle distribution missing log4j
[
https://issues.apache.org/jira/browse/DOSGI-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-157.
---
Resolution: Won't Fix
Assignee: Christian Schneider
Single-bundle distro is not supported anymore.
> Single-Bundle distribution missing log4j
>
>
> Key: DOSGI-157
> URL: https://issues.apache.org/jira/browse/DOSGI-157
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: Product
>Affects Versions: 1.4.0
>Reporter: David Bosschaert
>Assignee: Christian Schneider
>
> When configuring Discovery with the Single-Bundle distribution a
> NoClassDefFoundError occurs and discovery does not start up.
> To reproduce, place a org.apache.cxf.dosgi.discovery.zookeeper.cfg file in
> the {{load}} directory with the following content:
> {code}zookeeper.host = 127.0.0.1{code}
> When the CXF-DOSGi bundle is started the following error appears:
> {code} *ERROR* [org.osgi.service.cm.ManagedService, id=25, bundle=5]:
> Unexpected problem updating Configuration
> PID=org.apache.cxf.dosgi.discovery.zookeeper, factoryPID=null,
> bundleLocation=file:/Users/david/checkouts/cxf_dosgi_240113/distribution/single-bundle/target/cxf-dosgi-ri-singlebundle-distribution-1.5-SNAPSHOT.jar
> java.lang.NoClassDefFoundError: org/apache/log4j/Logger
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:108)
> at
> org.apache.cxf.dosgi.discovery.zookeeper.ZooKeeperDiscovery.createZooKeeper(ZooKeeperDiscovery.java:111)
> at
> org.apache.cxf.dosgi.discovery.zookeeper.ZooKeeperDiscovery.updated(ZooKeeperDiscovery.java:72)
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger not
> found by cxf-dosgi-ri-singlebundle-distribution [5]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 6 more{code}
> While CXF-DOSGi has migrated to use SLF4J, the embedded zookeeper code still
> uses Log4J. Log4J is currently not provided in the single bundle distro nor
> marked as imported. The classloader manages to get access to it because of
> the Dynamic-ImportPackage=* which is present in the CXF-DOSGi Single-Bundle
> distro (yuck).
> As the Single-Bundle distro is really about convenience, it should also
> provide the Log4J classes so that the discovery code will work without
> providing any additional bundles.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-84) cxf-dosgi-ri-singlebundle-distribution-1.2.jar does not play well with other bundles
[ https://issues.apache.org/jira/browse/DOSGI-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-84. -- Resolution: Won't Fix Assignee: Christian Schneider Single bundle distro is not supported anymore. > cxf-dosgi-ri-singlebundle-distribution-1.2.jar does not play well with other > bundles > > > Key: DOSGI-84 > URL: https://issues.apache.org/jira/browse/DOSGI-84 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Sven Zethelius >Assignee: Christian Schneider > > singlebundle is registering OSGI services and listening to the OSGi Service > registry without importing/exporting all the packages involved. The > particular case I ran into is with the org.apache.felix.cm.PersistenceManager > services. When the org.apache.felix.configadmin is included in the OSGi > runtime, the ConfigurationAdminImpl/ConfigurationManager instances created by > singlebundle's felix.configadmin sees the PersistanceManager registered by > the external felix.configadmin. > Setup: > org.eclipse.osgi-3.6.0.v20100517.jar > cxf-dosgi-ri-singlebundle-distribution-1.2.jar > org.apache.felix.configadmin-1.2.4.jar > Other bundles using ConfigurationAdmin interface > Our bundle, via a ServiceTracker ends up using the ConfigurationAdmin service > being provided by singlebundle. A call to > ConfigurationAdmin.getConfiguration triggers a call to look up > PersistenceManager instances. The singlebundle's felix.configadmin is > somehow seeing ALL registered instances of PersistenceManager even though the > class loaders are incompatible. It may have to do with the copy of > ServiceTracker included in the felix.configadmin, and using an old version of > the felix.configadmin. > In terms of resolutions: > ConfigurationAdmin was resolved to the external org.apache.felix.configadmin, > and both my bundle and the singlebundle agrees on classloaders, hence why I > am seeing the singlebundle's instance of ConfigurationAdmin > PersistenceManager is split, with the FilePersistenceManager for singlebundle > using singlebundle's definition, and the external felix.configadmin having > it's own. > P.S. You might want to update the Bug form, it shows 1.2 as "Unreleased > Versions" even though its under the release page > http://cxf.apache.org/dosgi-releases.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-144) can not deploy CXF 1.3.1 on Virgo Tomcat 3.5.RELEASE
[ https://issues.apache.org/jira/browse/DOSGI-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-144. --- Resolution: Fixed Assignee: Christian Schneider Fix Version/s: 2.0.0 CXF does not depend on spring anymore. So this should work better now. Can you retest? > can not deploy CXF 1.3.1 on Virgo Tomcat 3.5.RELEASE > > > Key: DOSGI-144 > URL: https://issues.apache.org/jira/browse/DOSGI-144 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.3, 1.3.1 > Environment: Virgo Tomcat 3.5.RELEASE > Java 1.6 >Reporter: Tran Lap >Assignee: Christian Schneider >Priority: Critical > Fix For: 2.0.0 > > > I am trying to deploy CXF 1.3.1 on Virgo Tomcat 3.5.RELEASE by following the > instruction from these articles: > http://cxf.apache.org/dosgi-single-bundle-distribution.html > http://cxf.apache.org/dosgi-multi-bundle-distribution.html > The CXF bundles always conflict with Virgo bundles, specially on the Spring > framework. > I do not know why, please help me to deploy CXF on Virgo Tomcat. > Thanks. > I have the same one on Eclipse's forum: > http://www.eclipse.org/forums/index.php/t/433936/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7054) CORBADocLitClientTypeTest failed with java9
[
https://issues.apache.org/jira/browse/CXF-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489995#comment-15489995
]
Grzegorz Grzybek commented on CXF-7054:
---
Again I have problem, because runtime JAXB data for classes in
{{org.apache.cxf.binding.corba.wsdl}} package doesn't have correct namespace
taken from package's {{@XmlSchema}} annotation, because
class.getPackage().getPackageInfo() returns proxy (meaning we couldn't find
package-info.class) in JDK9.
Here's the difference at the below stacktrace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
...
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641)
at
org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:348)
at
org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:346)
at
java.security.AccessController.doPrivileged(AccessController.java:-1)
at
org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:346)
at
org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:247)
at
org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:170)
at
org.apache.cxf.wsdl.JAXBExtensionHelper.createUnmarshaller(JAXBExtensionHelper.java:258)
- locked <0x982> (a org.apache.cxf.wsdl.JAXBExtensionHelper)
at
org.apache.cxf.wsdl.JAXBExtensionHelper.unmarshall(JAXBExtensionHelper.java:352)
at
com.ibm.wsdl.xml.WSDLReaderImpl.parseExtensibilityElement(WSDLReaderImpl.java:1861)
at
com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(WSDLReaderImpl.java:340)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2352)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2338)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:236)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:163)
at
org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:85)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:393)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
- locked <0x986> (a
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
- locked <0x988> (a org.apache.cxf.jaxws.EndpointImpl)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:136)
at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
at
org.apache.cxf.systest.type_test.corba.CORBADocLitServerImpl.run(CORBADocLitServerImpl.java:41)
at
org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:46)
at
org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:195)
at
org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:90)
at
org.apache.cxf.systest.type_test.corba.CORBADocLitClientTypeTest.startServers(CORBADocLitClientTypeTest.java:198)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.eva
[jira] [Resolved] (DOSGI-159) Endpoint description contains wrong org.apache.cxf.ws.address when using HTTPService style
[
https://issues.apache.org/jira/browse/DOSGI-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-159.
---
Resolution: Fixed
Assignee: Christian Schneider
Fix Version/s: 2.0.0
You need to setup the prefix it should add to the address. See
https://github.com/apache/cxf-dosgi/tree/master/common
> Endpoint description contains wrong org.apache.cxf.ws.address when using
> HTTPService style
> --
>
> Key: DOSGI-159
> URL: https://issues.apache.org/jira/browse/DOSGI-159
> Project: CXF Distributed OSGi
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Christian Schneider
>Priority: Critical
> Fix For: 2.0.0
>
>
> A Service is exported with the following properties:
> {code:xml}
>
> />{code}This results in the following EndpointDescription:{code}***
> EndpointDescription:
> component.id => 0
> component.name => test.simpleprovider
> endpoint.framework.uuid => 103e59c3-876f-0012-1569-9d4713edced0
> endpoint.id => http://:8181/ws/user//UserRepository
> endpoint.package.version. => 1.0.0
> endpoint.service.id => 37
> objectClass => [.UserRepository]
> org.apache.cxf.ws.address =>
> http://:8181/ws/user//UserRepository
> org.apache.cxf.ws.httpservice.context => /ws/user
> service.imported => true
> service.imported.configs => [org.apache.cxf.ws]
> service.intents => [SOAP.1_1, HTTP, SOAP]{code}the problem here is: The
> HTTPService is not running on 8181 but on a different port configured via
> org.osgi.service.http.port and thus the comunication fails. It seems as if
> here a default port is assumed.
> It should atleast honor the org.osgi.service.http.port property, or we need
> some other kind of way to tell it to CXF.
> HTTPService used is the org.ops4j.pax.web.pax-web-jetty-bundle (2.1.0)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DOSGI-16) Exception when Remoting Service with Single-Bundle Distro w/o Discovery Server
[ https://issues.apache.org/jira/browse/DOSGI-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-16. -- Resolution: Won't Fix Assignee: Christian Schneider The single bundle distro is not supported anymore. > Exception when Remoting Service with Single-Bundle Distro w/o Discovery Server > -- > > Key: DOSGI-16 > URL: https://issues.apache.org/jira/browse/DOSGI-16 > Project: CXF Distributed OSGi > Issue Type: Bug >Reporter: David Bosschaert >Assignee: Christian Schneider >Priority: Minor > > When using the Single Bundle Distribution you may get the following exception > when remoting a service: > SEVERE: Exception while processing the addition of a ServicePublication. > org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode > = ConnectionLoss > at org.apache.zookeeper.KeeperException.create(KeeperException.java:59) > at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:593) > at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:620) > at > org.apache.cxf.dosgi.discovery.zookeeper.PublishToZooKeeperCustomizer.ensurePath(PublishToZooKeeperCustomizer.java:112) > at > org.apache.cxf.dosgi.discovery.zookeeper.PublishToZooKeeperCustomizer.addingService(PublishToZooKeeperCustomizer.java:68) > at > org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1021) > at > org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:999) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:924) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:124) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:930) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:757) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:712) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:506) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:524) > at > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.publish(ServiceHookUtils.java:55) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:82) > at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > This happens when you don't have a Zookeeper Discovery Server running. > The exception is harmless and everything still works but it should be changed > into an INFO log message as running without Discovery is a perfectly valid > use case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-211) Support SOAP over JMS in DOSGI
[ https://issues.apache.org/jira/browse/DOSGI-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-211: -- Fix Version/s: 2.0.0 > Support SOAP over JMS in DOSGI > -- > > Key: DOSGI-211 > URL: https://issues.apache.org/jira/browse/DOSGI-211 > Project: CXF Distributed OSGi > Issue Type: New Feature >Reporter: Ranjeeth > Fix For: 2.0.0 > > > Support for SOAP over JMS transport configuration property in DOSGI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-211) Support SOAP over JMS in DOSGI
[ https://issues.apache.org/jira/browse/DOSGI-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-211. --- Resolution: Fixed Assignee: Christian Schneider SOAP over JMS should be possible now using a suitable address as CXF JMS now supports JMS configs in the address. You can also add a JMSConfigFeature using an intent to inject a ConnectionFactory. > Support SOAP over JMS in DOSGI > -- > > Key: DOSGI-211 > URL: https://issues.apache.org/jira/browse/DOSGI-211 > Project: CXF Distributed OSGi > Issue Type: New Feature >Reporter: Ranjeeth >Assignee: Christian Schneider > Fix For: 2.0.0 > > > Support for SOAP over JMS transport configuration property in DOSGI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DOSGI-227) Build fails with JDK 8
[ https://issues.apache.org/jira/browse/DOSGI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489978#comment-15489978 ] Christian Schneider edited comment on DOSGI-227 at 9/14/16 9:48 AM: Builds with JDK 8 now work fine. I add the workaround in CXF Aegis. was (Author: ch...@die-schneider.net): Builds with JDK 8 now work fine. > Build fails with JDK 8 > -- > > Key: DOSGI-227 > URL: https://issues.apache.org/jira/browse/DOSGI-227 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > Fix For: 2.0.0 > > Attachments: java8_classloader_fix.diff > > > The system test failures seem related to classloader changes in the JDK, as > explained at https://bugs.eclipse.org/bugs/show_bug.cgi?id=471551 or > https://java.net/jira/browse/GLASSFISH-19579. > The immediate workaround of setting the context class loader to null > temporarily in org.apache.cxf.aegis.type.XMLTypeCreator and > org.apache.cxf.helpers.XPathUtils works for (Oracle) JDK 8, but then it fails > on JDK 7. So we need to investigate further and find a better solution that > works on all JDK versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-227) Build fails with JDK 8
[ https://issues.apache.org/jira/browse/DOSGI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-227. --- Resolution: Fixed Assignee: Christian Schneider Builds with JDK 8 now work fine. > Build fails with JDK 8 > -- > > Key: DOSGI-227 > URL: https://issues.apache.org/jira/browse/DOSGI-227 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > Attachments: java8_classloader_fix.diff > > > The system test failures seem related to classloader changes in the JDK, as > explained at https://bugs.eclipse.org/bugs/show_bug.cgi?id=471551 or > https://java.net/jira/browse/GLASSFISH-19579. > The immediate workaround of setting the context class loader to null > temporarily in org.apache.cxf.aegis.type.XMLTypeCreator and > org.apache.cxf.helpers.XPathUtils works for (Oracle) JDK 8, but then it fails > on JDK 7. So we need to investigate further and find a better solution that > works on all JDK versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-227) Build fails with JDK 8
[ https://issues.apache.org/jira/browse/DOSGI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-227: -- Fix Version/s: 2.0.0 > Build fails with JDK 8 > -- > > Key: DOSGI-227 > URL: https://issues.apache.org/jira/browse/DOSGI-227 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Amichai Rothman >Assignee: Christian Schneider > Fix For: 2.0.0 > > Attachments: java8_classloader_fix.diff > > > The system test failures seem related to classloader changes in the JDK, as > explained at https://bugs.eclipse.org/bugs/show_bug.cgi?id=471551 or > https://java.net/jira/browse/GLASSFISH-19579. > The immediate workaround of setting the context class loader to null > temporarily in org.apache.cxf.aegis.type.XMLTypeCreator and > org.apache.cxf.helpers.XPathUtils works for (Oracle) JDK 8, but then it fails > on JDK 7. So we need to investigate further and find a better solution that > works on all JDK versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-58) Better handling for port conflicts when using property org.apache.cxf.rs.address
[ https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-58. -- Resolution: Won't Fix Assignee: Christian Schneider With recommendation to use the servlet transport. > Better handling for port conflicts when using property > org.apache.cxf.rs.address > > > Key: DOSGI-58 > URL: https://issues.apache.org/jira/browse/DOSGI-58 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: REST >Affects Versions: 1.1 >Reporter: Daniel Bimschas >Assignee: Christian Schneider >Priority: Minor > Labels: configuration > > Below is an exception from the mailing list thread that describes the > issue... (reverse order!) > I seePerhaps it could recognize that a conflict will occur and print a > more meaningful exception message advising users to use a context property. > If DOSGI will try to silently attach the endpoint to a paxweb-enabled > HttpService then it might become complicated (paxweb may not be installed in > case of multibindle distro) or a user might've used the explicit address > exactly because a standalone jetty were expected to start, etc... > Can you please open a JIRA in a DOSGI subproject so that we can track this > issue and discuss how to fix it ? > thanks, Sergey > - Original Message - From: "Daniel Bimschas" > > To: > Sent: Friday, February 05, 2010 3:07 PM > Subject: Re: DOSGi and JSON responses > Oh, I know of the org.osgi.service.http.port value that lets Pax Web start > it's Jetty instance on 8080 per default. I tried to say that users of DOSGI > (especially newbies) would certainly expect that using > "org.apache.cxf.rs.address" would work nevertheless by simply using the same > port (i.e. if there's no web context conflict). > I guess that some DOSGI (or CXF) bundle which is responsible for registering > the JAX-RS servlet to some Jetty instance could surely check if there's a > servlet container instance running on the desired port and reusing that > instance... > Daniel > Am 05.02.2010 um 15:56 schrieb Sergey Beryozkin: > Hi > This can be easily fixed AFAIK, I can't recall the name of the paxweb > property but you can ensure its Httpservice occupies some other port...Just > checked in ServiceMix, it is > org.osgi.service.http.port=8181, > add it to felix/etc/config.properties. etc > cheers, Sergey > Sergey, > I just stumbled over another issue that may annoy DOSGI users. If you start > the single bundle distribution (no idea if it's the same with multi bundle) > it starts a Jetty on localhost:8080 which should be usable like a OSGi > compendium HTTP service (that's what I understood at least). Now if one uses > the JAX-RS stuff and registers it's instance with the > "org.apache.cxf.rs.address" property he will have to choose a port other than > 8080 or he'll get the following exception: > WARNUNG: WARNING : Problem creating a remote endpoint for > de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource from CXF > PublishHook, reason is null > org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:114) > at > org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:129) > at > org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106) > at > org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80) > at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:637) > Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty server: > Address already in use > at > org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:339) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:157) > at > org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48) > at > org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:164) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:105) > ... 8 more > Caused by: java.net.BindException: Address already in use > at sun.nio.ch.Net.bind(Native Method) > at sun.nio.ch.ServerSocketChann
[jira] [Resolved] (DOSGI-219) DOSGi Fails to Publish Service Under Apache Karaf 3.0.3
[ https://issues.apache.org/jira/browse/DOSGI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-219. --- Resolution: Fixed Assignee: Christian Schneider The upcoming 2.0 version should work fine in karaf but I recommend to use karaf 4.x. > DOSGi Fails to Publish Service Under Apache Karaf 3.0.3 > --- > > Key: DOSGI-219 > URL: https://issues.apache.org/jira/browse/DOSGI-219 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0 > Environment: Linux / Fedora 21 / RHEL 6.x / Apache Karaf 3.0.3 >Reporter: Craig Niles >Assignee: Christian Schneider > > Hard to tell if this is a problem with the Karaf configuration or a bug in > CXF. When trying to evaluate CXF DOSGi using Karaf 3.0.3, I encountered a > bug where the same port is registered twice in jetty for the SOAP interface > on the remote-service hosting instance of Karaf. I had the same problem for > both Karaf feature repository versions 1.7.0-SNAPSHOT and 1.6.0. I tried > using DOSGi version 1.4.0 and the problem does not occur. > Its easy to reproduce: > 1. Download and extract karaf 3.0.3 from > http://karaf.apache.org/index/community/download.html > 2. In the extracted karaf directory, modify > etc/org.apache.karaf.features.repos.cfg and change the cxf-dosgi version from > latests to 1.6.0 (or leave as LATEST to use snapshot) > 3. Start karaf with ./bin/karaf , and use feature:repo-add cxf-dosgi to add > the cxf feature repo > 4. Install cxf dosgi distributed discovery using the command > feature:install cxf-dosgi-distributed-discovery > 5. Install the sample CXF DOSGi Discovery demo service implementation and > API per http://cxf.apache.org/dosgi-discovery-demo-page.html > 6. Start the services > 7. Check the log file data/log/karaf.log There will be some stack traces > resulting from the failure to bind the random port selected > 8. Using lsof -i: you can verify that the port is already bound to the > process id of the running karaf instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-219) DOSGi Fails to Publish Service Under Apache Karaf 3.0.3
[ https://issues.apache.org/jira/browse/DOSGI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-219: -- Fix Version/s: 2.0.0 > DOSGi Fails to Publish Service Under Apache Karaf 3.0.3 > --- > > Key: DOSGI-219 > URL: https://issues.apache.org/jira/browse/DOSGI-219 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0 > Environment: Linux / Fedora 21 / RHEL 6.x / Apache Karaf 3.0.3 >Reporter: Craig Niles >Assignee: Christian Schneider > Fix For: 2.0.0 > > > Hard to tell if this is a problem with the Karaf configuration or a bug in > CXF. When trying to evaluate CXF DOSGi using Karaf 3.0.3, I encountered a > bug where the same port is registered twice in jetty for the SOAP interface > on the remote-service hosting instance of Karaf. I had the same problem for > both Karaf feature repository versions 1.7.0-SNAPSHOT and 1.6.0. I tried > using DOSGi version 1.4.0 and the problem does not occur. > Its easy to reproduce: > 1. Download and extract karaf 3.0.3 from > http://karaf.apache.org/index/community/download.html > 2. In the extracted karaf directory, modify > etc/org.apache.karaf.features.repos.cfg and change the cxf-dosgi version from > latests to 1.6.0 (or leave as LATEST to use snapshot) > 3. Start karaf with ./bin/karaf , and use feature:repo-add cxf-dosgi to add > the cxf feature repo > 4. Install cxf dosgi distributed discovery using the command > feature:install cxf-dosgi-distributed-discovery > 5. Install the sample CXF DOSGi Discovery demo service implementation and > API per http://cxf.apache.org/dosgi-discovery-demo-page.html > 6. Start the services > 7. Check the log file data/log/karaf.log There will be some stack traces > resulting from the failure to bind the random port selected > 8. Using lsof -i: you can verify that the port is already bound to the > process id of the running karaf instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-250) Support capabilities and requirements specified in RSA 1.1
[ https://issues.apache.org/jira/browse/DOSGI-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-250. --- Resolution: Fixed Fixed in commit 5494b35c9145b9709173c1bc9b265a1c0497fb0a > Support capabilities and requirements specified in RSA 1.1 > -- > > Key: DOSGI-250 > URL: https://issues.apache.org/jira/browse/DOSGI-250 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.0.0 > > > See OSGi compendium > 122.9 Capability Namespaces -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-249) Redesign examples
[ https://issues.apache.org/jira/browse/DOSGI-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-249. --- Resolution: Fixed Examples are now simplified and all use DS to make them easier to understand. > Redesign examples > - > > Key: DOSGI-249 > URL: https://issues.apache.org/jira/browse/DOSGI-249 > Project: CXF Distributed OSGi > Issue Type: Improvement > Components: Samples >Affects Versions: 1.9.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-124) ReceiveTimeout not configurable while using cxf-rest service in OSGI
[ https://issues.apache.org/jira/browse/DOSGI-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-124. --- Resolution: Fixed Assignee: Christian Schneider (was: Sergey Beryozkin) Fix Version/s: (was: 1.9.0) 2.0.0 CXF DOSGi now allows to set a HttpConduitFeature as an intent. See the ssl example. > ReceiveTimeout not configurable while using cxf-rest service in OSGI > > > Key: DOSGI-124 > URL: https://issues.apache.org/jira/browse/DOSGI-124 > Project: CXF Distributed OSGi > Issue Type: Bug > Components: DSW > Environment: cxf-dosgi-ri-singlebundle-distribution-1.3.1.jar > deployed in Karaf >Reporter: Nilesh Patel >Assignee: Christian Schneider > Fix For: 2.0.0 > > > I am using CXF-REST services with OSGI (Karaf) by defining the webservice in > remote-services.xml file. > The CXF-RS service I am using is taking more than 60 seconds and due to that > I am getting following error. > aused by: java.net.SocketTimeoutException: SocketTimeoutException invoking > http://localhost:9000/nexgen/conversionService/convertClassicPolicy: Read > timed out > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1458) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1443) > at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:659) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > ... 7 more > Caused by: java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) > at java.io.BufferedInputStream.read(BufferedInputStream.java:317) > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1072) > at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1569) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1521) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1429) > I am not able to define ReadTimeout for CXF-Rest service defined following > way in OSGI as remote-services.xml. > > http://www.osgi.org/xmlns/rsa/v1.0.0";> > > > > com.coverall.mic.rest.policy.service.PCTUploadService > > > name="endpoint.id">http://synpuncvral-05.synechron.com/mic/rest-services/restconversion > value="http://synpuncvral-05.synechron.com/mic/rest-services/restconversion"; > /> > org.apache.cxf.rs > name="org.apache.cxf.rs.out.interceptors">com.coverall.platform.core.context.cxf.interceptor.RequestContextOutInterceptor > > > I also tried defining http-conduit by adding following blueprint.xml in same > bundle. > http://www.osgi.org/xmlns/blueprint/v1.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"; > xmlns:cxf="http://cxf.apache.org/blueprint/core"; > xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs"; > xmlns:jaxws="http://cxf.apache.org/blueprint/jaxws"; > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"; > xsi:schemaLocation=" > http://www.osgi.org/xmlns/blueprint/v1.0.0 > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd > http://www.osgi.org/xmlns/blueprint-ext/v1.1.0 > https://svn.apache.org/repos/asf/aries/tags/blueprint-0.3.1/blueprint-core/src/main/resources/org/apache/aries/blueprint/ext/blueprint-ext.xsd > http://cxf.apache.org/blueprint/jaxws > http://cxf.apache.org/schemas/blueprint/jaxws.xsd > http://cxf.apache.org/blueprint/jaxrs > http://cxf.apache.org/schemas/blueprint/jaxrs.xsd > http://cxf.apache.org/blueprint/core > http://cxf.apache.org/schemas/blueprint/core.xsd > http://camel.apache.org/schema/blueprint > http://camel.apache.org
[jira] [Resolved] (DOSGI-213) ASM library not in Multibundle 1.6.0, so no naming of webservice parameters possible
[ https://issues.apache.org/jira/browse/DOSGI-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-213. --- Resolution: Fixed ASM is now included in the multibundle distro. > ASM library not in Multibundle 1.6.0, so no naming of webservice parameters > possible > > > Key: DOSGI-213 > URL: https://issues.apache.org/jira/browse/DOSGI-213 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: OpenJDK Runtime Environment (IcedTea 2.4.4) > (7u51-2.4.4-0ubuntu0.13.10.1) > OpenJDK Client VM (build 24.45-b08, mixed mode, sharing) > Equinox > Exlipse RCP 4.3.1 >Reporter: Aurelius Robert Baier >Assignee: Christian Schneider >Priority: Minor > Labels: newbie > Fix For: 2.0.0 > > > When I tried to name the webservice method parameters and started my RCP > Application I got the exception pasted below. I got it working by taking the > servicemix.asm bundle of the Mutlibundle distribution 1.5.0 and defining it > in the MANIFEST.MF of my plugin. > Please feel free to tell me what I need to do better in case this is no DOSGi > problem. > Stacktrace > java.lang.RuntimeException: No ASM > ClassWriterFoundjava.lang.RuntimeException: No ASM ClassWriterFound > at > org.apache.cxf.common.util.ASMHelper.createClassWriter(ASMHelper.java:269) > ~[cxf-api-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:151) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:653) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:484) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:704) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at java.security.AccessController.doPrivileged(Native Method) > [na:1.7.0_51] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyMa
[jira] [Updated] (DOSGI-213) ASM library not in Multibundle 1.6.0, so no naming of webservice parameters possible
[ https://issues.apache.org/jira/browse/DOSGI-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-213: -- Fix Version/s: (was: 1.9.0) 2.0.0 > ASM library not in Multibundle 1.6.0, so no naming of webservice parameters > possible > > > Key: DOSGI-213 > URL: https://issues.apache.org/jira/browse/DOSGI-213 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: OpenJDK Runtime Environment (IcedTea 2.4.4) > (7u51-2.4.4-0ubuntu0.13.10.1) > OpenJDK Client VM (build 24.45-b08, mixed mode, sharing) > Equinox > Exlipse RCP 4.3.1 >Reporter: Aurelius Robert Baier >Priority: Minor > Labels: newbie > Fix For: 2.0.0 > > > When I tried to name the webservice method parameters and started my RCP > Application I got the exception pasted below. I got it working by taking the > servicemix.asm bundle of the Mutlibundle distribution 1.5.0 and defining it > in the MANIFEST.MF of my plugin. > Please feel free to tell me what I need to do better in case this is no DOSGi > problem. > Stacktrace > java.lang.RuntimeException: No ASM > ClassWriterFoundjava.lang.RuntimeException: No ASM ClassWriterFound > at > org.apache.cxf.common.util.ASMHelper.createClassWriter(ASMHelper.java:269) > ~[cxf-api-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:151) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:653) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:484) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:704) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at java.security.AccessController.doPrivileged(Native Method) > [na:1.7.0_51] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(Topol
[jira] [Assigned] (DOSGI-213) ASM library not in Multibundle 1.6.0, so no naming of webservice parameters possible
[ https://issues.apache.org/jira/browse/DOSGI-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-213: - Assignee: Christian Schneider > ASM library not in Multibundle 1.6.0, so no naming of webservice parameters > possible > > > Key: DOSGI-213 > URL: https://issues.apache.org/jira/browse/DOSGI-213 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: OpenJDK Runtime Environment (IcedTea 2.4.4) > (7u51-2.4.4-0ubuntu0.13.10.1) > OpenJDK Client VM (build 24.45-b08, mixed mode, sharing) > Equinox > Exlipse RCP 4.3.1 >Reporter: Aurelius Robert Baier >Assignee: Christian Schneider >Priority: Minor > Labels: newbie > Fix For: 2.0.0 > > > When I tried to name the webservice method parameters and started my RCP > Application I got the exception pasted below. I got it working by taking the > servicemix.asm bundle of the Mutlibundle distribution 1.5.0 and defining it > in the MANIFEST.MF of my plugin. > Please feel free to tell me what I need to do better in case this is no DOSGi > problem. > Stacktrace > java.lang.RuntimeException: No ASM > ClassWriterFoundjava.lang.RuntimeException: No ASM ClassWriterFound > at > org.apache.cxf.common.util.ASMHelper.createClassWriter(ASMHelper.java:269) > ~[cxf-api-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:151) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:653) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:484) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:704) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265) > ~[cxf-rt-core-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159) > ~[cxf-rt-frontend-simple-2.7.8.jar:2.7.8] > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211) > ~[cxf-rt-frontend-jaxws-2.7.8.jar:2.7.8] > at > org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119) > ~[cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at java.security.AccessController.doPrivileged(Native Method) > [na:1.7.0_51] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41) > [cxf-dosgi-ri-dsw-cxf-1.6.0.jar:na] > at > org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingR
[jira] [Resolved] (DOSGI-194) Decide how DOSGi needs to handle service.exported.interfaces with multiple values
[ https://issues.apache.org/jira/browse/DOSGI-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-194. --- Resolution: Fixed Assignee: Christian Schneider Resolving this task. I think we agree that we should not support multiple interfaces at the moment. > Decide how DOSGi needs to handle service.exported.interfaces with multiple > values > -- > > Key: DOSGI-194 > URL: https://issues.apache.org/jira/browse/DOSGI-194 > Project: CXF Distributed OSGi > Issue Type: Task > Components: DSW >Reporter: Sergey Beryozkin >Assignee: Christian Schneider > Fix For: 1.9.0 > > > According to the original DOSGi CXF documentation > "service.exported.interfaces" may have multiple values. > The multiple values can be specified as a String array with Declarative > Services or by a having a property value containing a comma-separated list of > strings. > The purpose of this task is to decide how DOSGI should handle this property > when it has multiple String values. If the decision is made that no multiple > values are supported then DOSGI will need to report a service exception when > the property contains multiple values, irrespectively of how these multiple > values have been specified (via Declarative Services or CXF specific > extension) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value
[ https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-108. --- Resolution: Fixed > service.exported.interfaces doesn't support comma-seperated String value > > > Key: DOSGI-108 > URL: https://issues.apache.org/jira/browse/DOSGI-108 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Bert Jacobs >Assignee: Christian Schneider >Priority: Minor > Fix For: 2.0.0 > > > I've got a Declarative Service component which has more than one interface. I > declare the *service.exported.interfaces* property as "interface1,interface2" > and the default type String (I cannot specify String[] per the SCR spec). > According to > http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringSOAPbasedservicesandconsumers > this String can be split on comma's. > The service won't deploy because the *RemoteServiceAdminCore* class _doesn't_ > split this String and hence won't recognize the interfaces. > Tested with 1.3-SNAPSHOT, built on 2012-01-23. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value
[ https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned DOSGI-108: - Assignee: Christian Schneider (was: Sergey Beryozkin) > service.exported.interfaces doesn't support comma-seperated String value > > > Key: DOSGI-108 > URL: https://issues.apache.org/jira/browse/DOSGI-108 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Bert Jacobs >Assignee: Christian Schneider >Priority: Minor > Fix For: 2.0.0 > > > I've got a Declarative Service component which has more than one interface. I > declare the *service.exported.interfaces* property as "interface1,interface2" > and the default type String (I cannot specify String[] per the SCR spec). > According to > http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringSOAPbasedservicesandconsumers > this String can be split on comma's. > The service won't deploy because the *RemoteServiceAdminCore* class _doesn't_ > split this String and hence won't recognize the interfaces. > Tested with 1.3-SNAPSHOT, built on 2012-01-23. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7057) CXF JAXRSClientFactoryBean proxy async support
[
https://issues.apache.org/jira/browse/CXF-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neal Hu updated CXF-7057:
-
Description:
Say we have resource interface org.apache.cxf.Resource, and its impl
org.apache.cxf.ResourceImpl, we can create client proxy via
JAXRSClientFactoryBean as below;
{code:java}
Class type = org.apache.cxf.Resource.class;
JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
bean.setAddress(baseAddress);
bean.setServiceClass(type);
bean.setProviders(providers);
bean.setFeatures(features);
bean.setThreadSafe(true);
T proxy = bean.create(type);
{code}
Then invoke the method via proxy.method1.
As we know the spec client api can invoke via async mode, my question is if the
dynamic proxy mode support async mode.
We are developing micro service framework which based on CXF RS, and the
comsumer's invoker is dynamicly generated by the clientfactory.create. Thanks.
was:
Say we have resource interface org.apache.cxf.Resource, and its impl
org.apache.cxf.ResourceImpl, we can create client proxy via
JAXRSClientFactoryBean as below;
{code:java}
Class type = org.apache.cxf.Resource.class;
JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
bean.setAddress(baseAddress);
bean.setServiceClass(type);
bean.setProviders(providers);
bean.setFeatures(features);
bean.setThreadSafe(true);
T proxy = bean.create(type);
{code}
Then invoke the method via proxy.method1.
As we know the spec client api can invoke via async mode, my question is if the
dynamic proxy mode support async mode.
We are developing micro service framework which based on CXF RS, and the
comsumer's invoker a dynamic generated by the clientfactory.create. Thanks.
> CXF JAXRSClientFactoryBean proxy async support
> --
>
> Key: CXF-7057
> URL: https://issues.apache.org/jira/browse/CXF-7057
> Project: CXF
> Issue Type: Wish
> Components: JAX-RS
>Affects Versions: 3.1.6
> Environment: Linux Mac
>Reporter: Neal Hu
> Fix For: 3.1.8
>
>
> Say we have resource interface org.apache.cxf.Resource, and its impl
> org.apache.cxf.ResourceImpl, we can create client proxy via
> JAXRSClientFactoryBean as below;
> {code:java}
> Class type = org.apache.cxf.Resource.class;
> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress(baseAddress);
> bean.setServiceClass(type);
> bean.setProviders(providers);
> bean.setFeatures(features);
> bean.setThreadSafe(true);
> T proxy = bean.create(type);
> {code}
> Then invoke the method via proxy.method1.
> As we know the spec client api can invoke via async mode, my question is if
> the dynamic proxy mode support async mode.
> We are developing micro service framework which based on CXF RS, and the
> comsumer's invoker is dynamicly generated by the clientfactory.create. Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7057) CXF JAXRSClientFactoryBean proxy async support
[
https://issues.apache.org/jira/browse/CXF-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489939#comment-15489939
]
Sergey Beryozkin commented on CXF-7057:
---
Hi Neal, so this is a CXF dev question, start from here
http://sberyozkin.blogspot.ie/2016/06/asynchronous-jax-rs-proxies-in-cxf.html
give this feature a try and comment here please.
Possible enhancement is to have dedicated async methods returning a Future or
CompletableStage can be generated for WADL-first or Swagger-first cases.
> CXF JAXRSClientFactoryBean proxy async support
> --
>
> Key: CXF-7057
> URL: https://issues.apache.org/jira/browse/CXF-7057
> Project: CXF
> Issue Type: Wish
> Components: JAX-RS
>Affects Versions: 3.1.6
> Environment: Linux Mac
>Reporter: Neal Hu
> Fix For: 3.1.8
>
>
> Say we have resource interface org.apache.cxf.Resource, and its impl
> org.apache.cxf.ResourceImpl, we can create client proxy via
> JAXRSClientFactoryBean as below;
> {code:java}
> Class type = org.apache.cxf.Resource.class;
> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress(baseAddress);
> bean.setServiceClass(type);
> bean.setProviders(providers);
> bean.setFeatures(features);
> bean.setThreadSafe(true);
> T proxy = bean.create(type);
> {code}
> Then invoke the method via proxy.method1.
> As we know the spec client api can invoke via async mode, my question is if
> the dynamic proxy mode support async mode.
> We are developing micro service framework which based on CXF RS, and the
> comsumer's invoker a dynamic generated by the clientfactory.create. Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value
[ https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489933#comment-15489933 ] Christian Schneider commented on DOSGI-108: --- I agree to report an exception for the case of more than one interface. > service.exported.interfaces doesn't support comma-seperated String value > > > Key: DOSGI-108 > URL: https://issues.apache.org/jira/browse/DOSGI-108 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Bert Jacobs >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 2.0.0 > > > I've got a Declarative Service component which has more than one interface. I > declare the *service.exported.interfaces* property as "interface1,interface2" > and the default type String (I cannot specify String[] per the SCR spec). > According to > http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringSOAPbasedservicesandconsumers > this String can be split on comma's. > The service won't deploy because the *RemoteServiceAdminCore* class _doesn't_ > split this String and hence won't recognize the interfaces. > Tested with 1.3-SNAPSHOT, built on 2012-01-23. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value
[ https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-108: -- Fix Version/s: (was: 1.9.0) 2.0.0 > service.exported.interfaces doesn't support comma-seperated String value > > > Key: DOSGI-108 > URL: https://issues.apache.org/jira/browse/DOSGI-108 > Project: CXF Distributed OSGi > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Bert Jacobs >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 2.0.0 > > > I've got a Declarative Service component which has more than one interface. I > declare the *service.exported.interfaces* property as "interface1,interface2" > and the default type String (I cannot specify String[] per the SCR spec). > According to > http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringSOAPbasedservicesandconsumers > this String can be split on comma's. > The service won't deploy because the *RemoteServiceAdminCore* class _doesn't_ > split this String and hence won't recognize the interfaces. > Tested with 1.3-SNAPSHOT, built on 2012-01-23. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOSGI-194) Decide how DOSGi needs to handle service.exported.interfaces with multiple values
[ https://issues.apache.org/jira/browse/DOSGI-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489926#comment-15489926 ] Christian Schneider commented on DOSGI-194: --- I agree that implementing this would be quite difficult. How about we document that we do not support multiple interfaces for now? > Decide how DOSGi needs to handle service.exported.interfaces with multiple > values > -- > > Key: DOSGI-194 > URL: https://issues.apache.org/jira/browse/DOSGI-194 > Project: CXF Distributed OSGi > Issue Type: Task > Components: DSW >Reporter: Sergey Beryozkin > Fix For: 1.9.0 > > > According to the original DOSGi CXF documentation > "service.exported.interfaces" may have multiple values. > The multiple values can be specified as a String array with Declarative > Services or by a having a property value containing a comma-separated list of > strings. > The purpose of this task is to decide how DOSGI should handle this property > when it has multiple String values. If the decision is made that no multiple > values are supported then DOSGI will need to report a service exception when > the property contains multiple values, irrespectively of how these multiple > values have been specified (via Declarative Services or CXF specific > extension) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-243) Update to OSGi spec 5.0.0
[ https://issues.apache.org/jira/browse/DOSGI-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-243. --- Resolution: Fixed > Update to OSGi spec 5.0.0 > - > > Key: DOSGI-243 > URL: https://issues.apache.org/jira/browse/DOSGI-243 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.0.0 > > > Update to 5.0.0 spec to use new DS options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOSGI-243) Update to OSGi spec 5.0.0
[ https://issues.apache.org/jira/browse/DOSGI-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated DOSGI-243: -- Fix Version/s: (was: 1.9.0) 2.0.0 > Update to OSGi spec 5.0.0 > - > > Key: DOSGI-243 > URL: https://issues.apache.org/jira/browse/DOSGI-243 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.0.0 > > > Update to 5.0.0 spec to use new DS options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7057) CXF JAXRSClientFactoryBean proxy async support
Neal Hu created CXF-7057:
Summary: CXF JAXRSClientFactoryBean proxy async support
Key: CXF-7057
URL: https://issues.apache.org/jira/browse/CXF-7057
Project: CXF
Issue Type: Wish
Components: JAX-RS
Affects Versions: 3.1.6
Environment: Linux Mac
Reporter: Neal Hu
Fix For: 3.1.8
Say we have resource interface org.apache.cxf.Resource, and its impl
org.apache.cxf.ResourceImpl, we can create client proxy via
JAXRSClientFactoryBean as below;
{code:java}
Class type = org.apache.cxf.Resource.class;
JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
bean.setAddress(baseAddress);
bean.setServiceClass(type);
bean.setProviders(providers);
bean.setFeatures(features);
bean.setThreadSafe(true);
T proxy = bean.create(type);
{code}
Then invoke the method via proxy.method1.
As we know the spec client api can invoke via async mode, my question is if the
dynamic proxy mode support async mode.
We are developing micro service framework which based on CXF RS, and the
comsumer's invoker a dynamic generated by the clientfactory.create. Thanks.
--
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&focusedCommentId=15489877#comment-15489877
]
Sergey Beryozkin commented on CXF-7045:
---
Yes, I realized afterwards Swagger was pulling in a Jackson provider itself :-).
> 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-7053) CorbaTimeoutTest failed with java9
[ https://issues.apache.org/jira/browse/CXF-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489756#comment-15489756 ] Grzegorz Grzybek commented on CXF-7053: --- PR: https://github.com/apache/cxf/pull/168 > CorbaTimeoutTest failed with java9 > -- > > Key: CXF-7053 > URL: https://issues.apache.org/jira/browse/CXF-7053 > Project: CXF > Issue Type: Sub-task >Reporter: Freeman Fang >Assignee: Freeman Fang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7049) Getting too many CLOSE_WAIT that lives forever
[ https://issues.apache.org/jira/browse/CXF-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489725#comment-15489725 ] Nithesh commented on CXF-7049: -- Found out that cxf logging interceptor is interfering with Log4j's logging module. after adding the below for org.apache.cxf package in log4j.xml, close waits disappeared. If i change this to ERROR, then there exists 200+ CLOSE_WAITs in the back-end, which eventually will consume all the sockets/file-descriptor and sever will stop respoding for ever. Seems like a bug to me in CXF. Thanks, Nithesh > Getting too many CLOSE_WAIT that lives forever > -- > > Key: CXF-7049 > URL: https://issues.apache.org/jira/browse/CXF-7049 > Project: CXF > Issue Type: Bug > Components: Bus, Core, Integration >Affects Versions: 3.0.6 > Environment: Jetty 9.3.3 Application server, jdk 1.8, Camel 2.15.3 , > CXF 3.0.6 >Reporter: Nithesh > Labels: newbie, performance > > When ever cxf endpoint is invoked first the connection to that endpoint is > established, after the response is received connection goes to CLOSE_WAIT and > stays in this state forever !! > after a load test i can see 1500+ connections is in close_wait and stays in > this state ! > Total no. Connection : 1571, TIME_WAIT : 0, CLOSE_WAIT : 1571, ESTABLISHED:0 > I'm facing the problems as stated in the below two forums: > 1. https://developer.jboss.org/thread/272238 > 2. > http://stackoverflow.com/questions/39349670/too-many-close-wait-with-jetty-9-3-3-observed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
