[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816382#comment-17816382
 ] 

Amichai Rothman commented on CXF-8962:
--

Scrath that, it's working now, though I have no idea why it didn't the first 
few hours I was debugging through it, and now it does. Didn't change the code 
in between... maybe just something not updating right in debugger or something. 
Thanks for the workaround! btw does anyone know in what version the workaround 
broke? So we don't update to it by mistake...

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816378#comment-17816378
 ] 

Amichai Rothman commented on CXF-8962:
--

That doesn't work. I put a breakpoint there and see it set, then another 
breakpoint in Headers.setProtocolHeadersInConnection where it reads it with 
setCtForEmptyRequestProp = 
message.getContextualProperty(SET_EMPTY_REQUEST_CT_PROPERTY); but there the 
property is null.

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816318#comment-17816318
 ] 

Amichai Rothman commented on CXF-8962:
--

This is embarassing but I can't figure out where to set that property on the 
WebClient... client.getConfiguration().getBus().setProperty() didn't work, 
client.
getConfiguration().getRequestContext().put() didn't work, where are these 
properties supposed to come from?

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815784#comment-17815784
 ] 

Amichai Rothman edited comment on CXF-8962 at 2/8/24 6:35 PM:
--

We're also seeing rejected DELETE requests due to this issue (on 3.5.2) :(

Is there a known workaround?


was (Author: amichai):
We're also seeing rejected DELETE requests due to this issue :(

Is there a known workaround?

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815784#comment-17815784
 ] 

Amichai Rothman commented on CXF-8962:
--

We're also seeing rejected DELETE requests due to this issue :(

Is there a known workaround?

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544936#comment-17544936
 ] 

Amichai Rothman edited comment on CXF-8636 at 6/1/22 2:31 PM:
--

After digging a bit deeper, and better understanding what was wrong and why the 
docs are still confusing:
 * The workaround is activated only if the SwaggerUIConfig exists, it has a url 
property, and either doesn't have the queryConfigEnabled or has it set to 
'false'. or inversely: it does not work out of the box (when no config exists), 
does not work if a url is not set (which is not apparent from the docs - the 
query parameter exists but is ignored and only the config url is used), or if 
queryConfigEnabled is set to 'true'.
 * I went straight for the latest swagger-ui 4.11.1, but as it turns out, the 
CXF 3.5.2 workaround is broken on it. The last swagger-ui for which CXF 3.5.2 
still works is 4.8.1. It looks like the workaround may have been updated to 
work with newer swagger-ui only in newer CXF, hopefully backwards-compatible 
with all the intermediate swagger-ui versions as well.
 * The url query parameter is still added and redirected to, but then ignored 
(only url from config is used).

So in short,it works with CXF 3.5.2 but only up to swagger-ui 4.8.1, with an 
explicit SwaggerUIConfig with explicit url and false or unset 
queryConfigEnabled.

To save others a few hours of work, I think a fuller explanation with all the 
details should be updated in the docs (both for swagger and openapi features).

I hope this helps...


was (Author: amichai):
After digging a bit deeper, and better understood what was wrong and why the 
docs are still confusing:
 * The workaround is activated only if the SwaggerUIConfig exists, it has a url 
property, and either doesn't have the queryConfigEnabled or has it set to 
'false'. or inversely: it does not work out of the box (when no config exists), 
does not work if a url is not set (which is not apparent from the docs - the 
query parameter exists but is ignored and only the config url is used), or if 
queryConfigEnabled is set to 'true'.
 * I went straight for the latest swagger-ui 4.11.1, but as it turns out, the 
CXF 3.5.2 workaround is broken on it. The last swagger-ui for which CXF 3.5.2 
still works is 4.8.1. It looks like the workaround may have been updated to 
work with newer swagger-ui only in newer CXF, hopefully backwards-compatible 
with all the intermediate swagger-ui versions as well.
 * The url query parameter is still added and redirected to, but then ignored 
(only url from config is used).

So in short,it works with CXF 3.5.2 but only up to swagger-ui 4.8.1, with an 
explicit SwaggerUIConfig with explicit url and false or unset 
queryConfigEnabled.

To save others a few hours of work, I think a fuller explanation with all the 
details should be updated in the docs (both for swagger and openapi features).

I hope this helps...

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544936#comment-17544936
 ] 

Amichai Rothman commented on CXF-8636:
--

After digging a bit deeper, and better understood what was wrong and why the 
docs are still confusing:
 * The workaround is activated only if the SwaggerUIConfig exists, it has a url 
property, and either doesn't have the queryConfigEnabled or has it set to 
'false'. or inversely: it does not work out of the box (when no config exists), 
does not work if a url is not set (which is not apparent from the docs - the 
query parameter exists but is ignored and only the config url is used), or if 
queryConfigEnabled is set to 'true'.
 * I went straight for the latest swagger-ui 4.11.1, but as it turns out, the 
CXF 3.5.2 workaround is broken on it. The last swagger-ui for which CXF 3.5.2 
still works is 4.8.1. It looks like the workaround may have been updated to 
work with newer swagger-ui only in newer CXF, hopefully backwards-compatible 
with all the intermediate swagger-ui versions as well.
 * The url query parameter is still added and redirected to, but then ignored 
(only url from config is used).

So in short,it works with CXF 3.5.2 but only up to swagger-ui 4.8.1, with an 
explicit SwaggerUIConfig with explicit url and false or unset 
queryConfigEnabled.

To save others a few hours of work, I think a fuller explanation with all the 
details should be updated in the docs (both for swagger and openapi features).

I hope this helps...

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17544867#comment-17544867
 ] 

Amichai Rothman commented on CXF-8636:
--

Thanks for the updates!

I still can't get it to work though. On Karaf 4.3.7, CXF 3.5.2, blueprint, 
OpenApiFeature with or without an explicit SwaggerUiConfig bean, the cxf 
services list page still shows the url query parameter on the link (as I pasted 
above - this may be a separate but related issue), and also browsing to the 
page with or without the query string, even with adding an explicit index.html 
manually (as far as I can see in the code it looks for that hard-coded string 
when applying the workaround), everything results in seeing the petstore api. 
In fact it seems to redirect (307) from all those variants back to the original 
url with the query string, which then still shows the petstore api. Maybe 
there's something else I need to be doing, but this used to work out of the 
box, and now does not.

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543932#comment-17543932
 ] 

Amichai Rothman commented on CXF-8636:
--

Great! Perhaps you can also update the OpenAPIFeature docs about this? They 
still show the url query param and don't mention any of the required changes 
and what works or doesn't work out of the box now...

[https://cwiki.apache.org/confluence/display/CXF20DOC/OpenAPIFeature#OpenApiFeature-EnablingSwaggerUI]

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543776#comment-17543776
 ] 

Amichai Rothman commented on CXF-8636:
--

I read the documentation, which says that prior to CXF 3.5.1 it would pass the 
url as the query parameter, and in newer CXF it employs a different strategy. 
In this services list page it still passes the url as a query parameter also in 
3.5.2. The documentation also says the new strategy "could be turned off by 
setting {{queryConfigEnabled}}  property of the *SwaggerUiConfig* to 
{{{}true{}}}". It doesn't say anything about having to set this property to get 
it to work in the first place. Perhaps the documentation should be clarified if 
that's not the case.

Also, how does one configure this when using the OpenAPIFeature (from 
blueprint)? is it the same configuration property?

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8636) Swagger2Feature: Can't set url in UI through SwaggerUiConfig

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543639#comment-17543639
 ] 

Amichai Rothman commented on CXF-8636:
--

The services list page generated by CXF still shows e.g.:


|Endpoint address: https://localhost:8183/api/v1
WADL : 
[https://localhost:8183/api/v1?_wadl|https://localhost:8183/api/psd2?_wadl]
OpenAPI : 
[https://localhost:8183/api/v1/api-docs?url=/api/v1/openapi.json|https://localhost:8183/api/psd2/api-docs?url=/api/psd2/openapi.json]|

With the bottom link broken by this issue (showing the petstore instead of the 
application api that it used to show in previous versions).

> Swagger2Feature: Can't set url in UI through SwaggerUiConfig
> 
>
> Key: CXF-8636
> URL: https://issues.apache.org/jira/browse/CXF-8636
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Markus Plangg
>Assignee: Andriy Redko
>Priority: Minor
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> I've included the swagger ui by adding a dependency on org.webjars:swagger-ui.
> The 
> [Documentation|https://cxf.apache.org/docs/swagger2feature.html#Swagger2Feature-ConfiguringSwaggerUI(3.2.7+)]
>  mentions that the swagger UI can be configured through SwaggerUiConfig which 
> sets config as query params.
>  
> Since [swagger ui 
> 4.1.3|https://github.com/swagger-api/swagger-ui/releases/tag/v4.1.3] passing 
> the default url as query parameter, e.g. `?url=swagger.json` is disabled by 
> default due to security concerns. Instead the default swagger PetStore 
> definition is loaded.
>  
> It's possible to restore the old behaviour by setting queryConfigEnabled, but 
> I couldn't find a way to set this. Of course enabling this also brings back 
> the security issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (CXF-8593) Error when installing CXF OpenAPI v3 under Karaf 4.2.11

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444602#comment-17444602
 ] 

Amichai Rothman commented on CXF-8593:
--

Thanks a bunch to both of you... the workaround seems to work! It would be 
great if this could be made to work out of the box in karaf...

In the meantime, I couldn't find any documentation on the 
org.apache.karaf.faetures.xml configuration file (other than its existence) - 
for example, is it possible to use variables or defaults for the version 
numbers? I'm sure next time someone tries to upgrade karaf or cxf and things 
will break nobody will know about the workaround hiding in this config file :)

> Error when installing CXF OpenAPI v3 under Karaf 4.2.11
> ---
>
> Key: CXF-8593
> URL: https://issues.apache.org/jira/browse/CXF-8593
> Project: CXF
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: 3.4.4
>Reporter: Serge Huber
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.5
>
> Attachments: cxf-servlet-compatible-3.4.4.jar, 
> org.apache.karaf.features.xml
>
>
> I've found an error when using the CXF OpenAPI v3 feature with Karaf 4.2.11.
> Here's a reproduction scenario:
> {code}
> __ __    
>/ //_/ __ _/ __/  
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/ 
>   Apache Karaf (4.2.11)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> feature:repo-add cxf
> Adding feature url mvn:org.apache.cxf.karaf/apache-cxf/RELEASE/xml/features
> karaf@root()> feature:install cxf-rs-description-openapi-v3
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles:
>   Activator start error in bundle org.apache.cxf.cxf-rt-transports-http 
> [85].
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1052)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1063)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
>   Suppressed: org.osgi.framework.BundleException: Activator start error 
> in bundle org.apache.cxf.cxf-rt-transports-http [85].
>   at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>   at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1154)
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1044)
>   ... 6 more
>   Caused by: java.lang.NoClassDefFoundError: 
> org/osgi/service/http/HttpService
>   at 
> org.apache.cxf.transport.http.osgi.HTTPTransportActivator.start(HTTPTransportActivator.java:62)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   ... 12 more
>   Caused by: java.lang.ClassNotFoundException: 
> org.osgi.service.http.HttpService not found by 
> org.apache.cxf.cxf-rt-transports-http [85]
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   ... 15 more
> Error executing command: Error restarting bundles:
>   Activator start error in bundle org.apache.cxf.cxf-rt-transports-http 
> [85].
> {code}
> The corresponding log : 
> {code}
> 18:08:34.905 INFO [pipe-feature:install cxf-rs-description-openapi-v3] Adding 

[jira] [Commented] (CXF-8593) Error when installing CXF OpenAPI v3 under Karaf 4.2.11

[Amichai Rothman (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443857#comment-17443857
 ] 

Amichai Rothman commented on CXF-8593:
--

This feature still fails to install on Karaf 4.3.3 with CXF 3.4.5. Still due to 
conflicting servlet api versions. I'm not sure why this was marked as fixed :(

> Error when installing CXF OpenAPI v3 under Karaf 4.2.11
> ---
>
> Key: CXF-8593
> URL: https://issues.apache.org/jira/browse/CXF-8593
> Project: CXF
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: 3.4.4
>Reporter: Serge Huber
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.4.5
>
> Attachments: cxf-servlet-compatible-3.4.4.jar, 
> org.apache.karaf.features.xml
>
>
> I've found an error when using the CXF OpenAPI v3 feature with Karaf 4.2.11.
> Here's a reproduction scenario:
> {code}
> __ __    
>/ //_/ __ _/ __/  
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/ 
>   Apache Karaf (4.2.11)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> karaf@root()> feature:repo-add cxf
> Adding feature url mvn:org.apache.cxf.karaf/apache-cxf/RELEASE/xml/features
> karaf@root()> feature:install cxf-rs-description-openapi-v3
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles:
>   Activator start error in bundle org.apache.cxf.cxf-rt-transports-http 
> [85].
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1052)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1063)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
>   Suppressed: org.osgi.framework.BundleException: Activator start error 
> in bundle org.apache.cxf.cxf-rt-transports-http [85].
>   at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>   at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>   at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1154)
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1044)
>   ... 6 more
>   Caused by: java.lang.NoClassDefFoundError: 
> org/osgi/service/http/HttpService
>   at 
> org.apache.cxf.transport.http.osgi.HTTPTransportActivator.start(HTTPTransportActivator.java:62)
>   at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>   at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>   ... 12 more
>   Caused by: java.lang.ClassNotFoundException: 
> org.osgi.service.http.HttpService not found by 
> org.apache.cxf.cxf-rt-transports-http [85]
>   at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>   at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>   at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   ... 15 more
> Error executing command: Error restarting bundles:
>   Activator start error in bundle org.apache.cxf.cxf-rt-transports-http 
> [85].
> {code}
> The corresponding log : 
> {code}
> 18:08:34.905 INFO [pipe-feature:install cxf-rs-description-openapi-v3] Adding 
> features: cxf-rs-description-openapi-v3/[3.4.4,3.4.4]
> 18:08:35.300 INFO [features-3-thread-1] Changes to perform:
> 18:08:35.300 INFO [features-3-thread-1]   Region: root
> 18:08:35.301 INFO [features-3-thread-1] Bundles to install:
> 18:08:35.301 INFO [features-3-thread-1]   
> mvn:com.fasterxml.jackson.core/jackson-annotations/2.11.4

[jira] [Created] (DOSGI-285) ServiceException missing REMOTE type

[Amichai Rothman (Jira)]

Amichai Rothman created DOSGI-285:
-

 Summary: ServiceException missing REMOTE type
 Key: DOSGI-285
 URL: https://issues.apache.org/jira/browse/DOSGI-285
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: common
Affects Versions: 2.3.0
Reporter: Amichai Rothman


In ExceptionMapper.mapException() an exception is created via:

{{return new ServiceException(REMOTE_EXCEPTION_TYPE, ex);}}

With

{{private static final String REMOTE_EXCEPTION_TYPE = "REMOTE";}}

so the exception is thrown with the string "REMOTE" but type 
ServiceException.UNSPECIFIED.

 

Wouldn't it make more sense to create it with the ServiceException.REMOTE type?

i.e.

{{return new ServiceException(REMOTE_EXCEPTION_TYPE, ServiceException.REMOTE, 
ex);}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DOSGI-280) Upgrade to Aries RSA 1.14.0

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845906#comment-16845906
 ] 

Amichai Rothman commented on DOSGI-280:
---

I opened a PR on github, it doesn't seem to get synced to Jira automatically... 
maybe something needs to be configured somewhere for it to work.

> Upgrade to Aries RSA 1.14.0
> ---
>
> Key: DOSGI-280
> URL: https://issues.apache.org/jira/browse/DOSGI-280
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>  Components: common
>Affects Versions: 2.3.0
>Reporter: Amichai Rothman
>Priority: Major
>
> It fixes a bunch of important issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DOSGI-280) Upgrade to Aries RSA 1.14.0

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-280:
-

 Summary: Upgrade to Aries RSA 1.14.0
 Key: DOSGI-280
 URL: https://issues.apache.org/jira/browse/DOSGI-280
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: common
Affects Versions: 2.3.0
Reporter: Amichai Rothman


It fixes a bunch of important issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DOSGI-252) Unable to export RS services with same addresses and different contexts

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803076#comment-16803076
 ] 

Amichai Rothman commented on DOSGI-252:
---

I have a question: if BaseDistributionProvider.createBus() is changed so that 
it skips the registerServlet call if a servlet was already registered for the 
given contextRoot, it seems to work as expected (in the example above, both 
/api/service1/v1 and /api/service2/v1 work properly). However I'm not 
proficient with the rest of the architecture here... would such a change have 
any other repercussions? Is this a reasonable fix? Because if the fix is as 
simple as that, I'd be happy to provide a PR.

> Unable to export RS services with same addresses and different contexts
> ---
>
> Key: DOSGI-252
> URL: https://issues.apache.org/jira/browse/DOSGI-252
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Dmytro Pishchukhin
>Priority: Major
>
> I've tried to export RS services with such urls:
> {noformat}
> http://:/service1/v1
> http://:/service2/v1
> {noformat}
> if I use only 
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1/v1
> org.apache.cxf.rs.httpservice.context=/service2/v1
> {noformat}
> I receive an exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
>   at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:219)
> ...
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There 
> is an endpoint already running on /.
>   at 
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:85)
> {noformat}
> If I use 
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1
> org.apache.cxf.rs.address=/v1
> org.apache.cxf.rs.httpservice.context=/service2
> org.apache.cxf.rs.address=/v1
> {noformat}
> I receive another exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
>   at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:219)
> ...
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There 
> is an endpoint already running on /v1.
>   at 
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:85)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DOSGI-252) Unable to export RS services with same addresses and different contexts

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802931#comment-16802931
 ] 

Amichai Rothman commented on DOSGI-252:
---

When leaving out the context as suggested, both /cxf/service1/v1 and 
/cxf/service2/v1 work properly.

However when both services (in my case in different bundles) also have 
context=/api, then /api/service1/v1 works but /api/service2/v1 does not, and 
the log shows:

org.osgi.framework.ServiceException: CXF DOSGi: problem registering CXF HTTP 
Servlet
    at 
org.apache.cxf.dosgi.common.httpservice.HttpServiceManager.registerServlet(HttpServiceManager.java:100)
 ~[?:?]
    at 
org.apache.cxf.dosgi.common.handlers.BaseDistributionProvider.createBus(BaseDistributionProvider.java:67)
 ~[?:?]
    at 
org.apache.cxf.dosgi.dsw.handlers.rest.RsProvider.exportService(RsProvider.java:141)
 ~[?:?]
    at 
org.apache.aries.rsa.core.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:212)
 ~[?:?]
    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:157)
 [115:org.apache.aries.rsa.topology-manager:1.11.0]
    at 
org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport.doExport(TopologyManagerExport.java:127)
 [115:org.apache.aries.rsa.topology-manager:1.11.0]
    at 
org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport.access$000(TopologyManagerExport.java:55)
 [115:org.apache.aries.rsa.topology-manager:1.11.0]
    at 
org.apache.aries.rsa.topologymanager.exporter.TopologyManagerExport$1.run(TopologyManagerExport.java:99)
 [115:org.apache.aries.rsa.topology-manager:1.11.0]
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[?:?]
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: org.osgi.service.http.NamespaceException: alias: '/api' is already 
in use in this or another context
    at 
org.ops4j.pax.web.service.spi.model.ServerModel.addServletModel(ServerModel.java:124)
 ~[?:?]
    at 
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:243)
 ~[?:?]
    at 
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:223)
 ~[?:?]
    at 
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:207)
 ~[?:?]
    at 
org.ops4j.pax.web.service.internal.HttpServiceProxy.registerServlet(HttpServiceProxy.java:69)
 ~[?:?]
    at 
org.apache.cxf.dosgi.common.httpservice.HttpServiceManager.registerServlet(HttpServiceManager.java:94)
 ~[?:?]
    ... 16 more

> Unable to export RS services with same addresses and different contexts
> ---
>
> Key: DOSGI-252
> URL: https://issues.apache.org/jira/browse/DOSGI-252
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Dmytro Pishchukhin
>Priority: Major
>
> I've tried to export RS services with such urls:
> {noformat}
> http://:/service1/v1
> http://:/service2/v1
> {noformat}
> if I use only 
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1/v1
> org.apache.cxf.rs.httpservice.context=/service2/v1
> {noformat}
> I receive an exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
>   at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:219)
> ...
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: There 
> is an endpoint already running on /.
>   at 
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:85)
> {noformat}
> If I use 
> {noformat}
> org.apache.cxf.rs.httpservice.context=/service1
> org.apache.cxf.rs.address=/v1
> org.apache.cxf.rs.httpservice.context=/service2
> org.apache.cxf.rs.address=/v1
> {noformat}
> I receive another exception
> {noformat}
> org.apache.cxf.service.factory.ServiceConstructionException
>   at 
> 

[jira] [Commented] (DOSGI-140) Support the registration of multiple bundles sharing the same HTTP context

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792431#comment-16792431
 ] 

Amichai Rothman commented on DOSGI-140:
---

Still waiting for this to work properly... and there's also DOSGI-197 and 
DOSGI-252.. multiple issues related to context/address configuration.

I think all combinations of context/address settings should be considered, 
including same/different context, same/different address, same/different 
bundles, with/without the root context and/or default context too. The proper 
desired behavior of each combination should be defined and fixed. Currently the 
only thing that works for me is using unique address and unique context per 
bundle, which makes for some badly named urls, and even then iirc there is some 
mixup (both addresses are available on both contexts - though it's possible 
this happened with some other combination of context/address settings).

Any chance this will get fixed once and for all?


> Support the registration of multiple bundles sharing the same HTTP context
> --
>
> Key: DOSGI-140
> URL: https://issues.apache.org/jira/browse/DOSGI-140
> Project: CXF Distributed OSGi
>  Issue Type: Improvement
>  Components: common
>Reporter: Sergey Beryozkin
>Priority: Major
> Fix For: 2.4.0
>
>
> When an application consists of different implementation bundles, it is not 
> possible at the moment to share the same HTTP context which makes it 
> difficult to rely on Servlet container support for sessions, security, etc.
> Note that right now it is possible for a bundle to use a combination of 
> HttpContext and relative ws/rs addresses, example,
> {code}
> "org.apache.cxf.rs.httpservice.context=/rs" 
> "org.apache.cxf.rs.address="/service"
> {code}
> will lead to "/rs/service" relative base address be created for a given 
> endpoint.
> It should be possible to do
> {code}
> // First bundle
> "org.apache.cxf.rs.httpservice.context=/rs" 
> "org.apache.cxf.rs.address="/service1"
> // Second bundle
> "org.apache.cxf.rs.httpservice.context=/rs" 
> "org.apache.cxf.rs.address="/service2"
> {code}
>  
> with both bundles binding to "/service" HTTP context but having different 
> base addresses ("/rs/service1", "/rs/service2"). 
> Perhaps we can also optimize when only relative ws/rs address property is 
> set, example:
> {code}
> // First bundle
> "org.apache.cxf.ws.address="/service1"
> // Second bundle
> "org.apache.cxf.ws.address="/service2"
> {code}
>  
> means that both bundles have to be bound to the default CXF "/cxf" or 
> "/services" context



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DOSGI-279) Please upgrade RSA, CXF and other dependencies

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-279:
-

 Summary: Please upgrade RSA, CXF and other dependencies
 Key: DOSGI-279
 URL: https://issues.apache.org/jira/browse/DOSGI-279
 Project: CXF Distributed OSGi
  Issue Type: New Feature
  Components: common
Affects Versions: 2.3.0
Reporter: Amichai Rothman


The CXF version in the current release causes problems due do an issue with a 
version range specifier in its features xml (fixed in more recent versions of 
CXF). Latest version is also JDK-11 ready. Also RSA had some issues fixed and 
can be upgraded, same for ZooKeeper. Of course 'mvn 
versions:display-dependency-updates' can show you other dependencies that can 
be upgraded as well as necessary :-)

I suppose this upgrade check can be done before every release, but it doesn't 
always happen, and sometimes there isn't a release for a long time so an issue 
like this can help encourage one...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DOSGI-178) NullPointerException when interface method declares throwing custom exception

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862787#comment-15862787
 ] 

Amichai Rothman commented on DOSGI-178:
---

I don't have the original setup, but I just tried adding such a checked 
exception to the interface and impl in the soap sample project, as described in 
this issue, and removed the WebService annotation so it should use Aegis. It 
seems to work fine now (DOSGi 2.0.0).

> 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
> Fix For: 2.2.0
>
>
> 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 
> 

[jira] [Resolved] (DOSGI-258) itests fail when port 8080 is in use

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-258.
---
Resolution: Fixed

The itests HTTP port is now specified in a constant that can be changed as 
necessary, and the default is changed to port 8989.

> itests fail when port 8080 is in use
> 
>
> Key: DOSGI-258
> URL: https://issues.apache.org/jira/browse/DOSGI-258
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Amichai Rothman
>Assignee: Amichai Rothman
>
> Many web servers and containers use port 8080 by default, as do the DOSGi 
> itests, which then fail since the address is already in use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DOSGI-257) Can't set bus properties

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-257.
---
   Resolution: Fixed
Fix Version/s: 2.1.0

Bus properties can now be set via service properties of the form 
cxf.bus.prop.=

> Can't set bus properties
> 
>
> Key: DOSGI-257
> URL: https://issues.apache.org/jira/browse/DOSGI-257
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Amichai Rothman
>Assignee: Amichai Rothman
> Fix For: 2.1.0
>
>
> There is no way to set CXF bus properties when using DOSGi.
> These are sometimes required, e.g. for setting the 
> skip.default.json.provider.registration property, without which a custom JSON 
> serialization provider does not get precedence (since the change in provider 
> sort order in CXF 3.1.2) and can no longer be used. Other bus properties can 
> be useful as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DOSGI-258) itests fail when port 8080 is in use

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-258:
-

 Summary: itests fail when port 8080 is in use
 Key: DOSGI-258
 URL: https://issues.apache.org/jira/browse/DOSGI-258
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman


Many web servers and containers use port 8080 by default, as do the DOSGi 
itests, which then fail since the address is already in use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DOSGI-257) Can't set bus properties

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-257:
-

 Summary: Can't set bus properties
 Key: DOSGI-257
 URL: https://issues.apache.org/jira/browse/DOSGI-257
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman


There is no way to set CXF bus properties when using DOSGi.

These are sometimes required, e.g. for setting the 
skip.default.json.provider.registration property, without which a custom JSON 
serialization provider does not get precedence (since the change in provider 
sort order in CXF 3.1.2) and can no longer be used. Other bus properties can be 
useful as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (DOSGI-256) ContextResolver intents are not registered as providers

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-256:
-

 Summary: ContextResolver intents are not registered as providers
 Key: DOSGI-256
 URL: https://issues.apache.org/jira/browse/DOSGI-256
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman


When an intent service returns a ContextResolver, it is not registered as a 
JAX-RS provider as it should. This is because RsProvider.isProvider() checks 
the intent instance to see if it is one of the provider classes, but 
ContextResolver is missing form the supported class list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (DOSGI-256) ContextResolver intents are not registered as providers

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-256.
---
   Resolution: Fixed
Fix Version/s: 2.1.0

> ContextResolver intents are not registered as providers
> ---
>
> Key: DOSGI-256
> URL: https://issues.apache.org/jira/browse/DOSGI-256
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Amichai Rothman
>Assignee: Amichai Rothman
> Fix For: 2.1.0
>
>
> When an intent service returns a ContextResolver, it is not registered as a 
> JAX-RS provider as it should. This is because RsProvider.isProvider() checks 
> the intent instance to see if it is one of the provider classes, but 
> ContextResolver is missing form the supported class list.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DOSGI-217) Security filters don't work in Karaf 3.0.x

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621679#comment-15621679
 ] 

Amichai Rothman commented on DOSGI-217:
---

Any idea in what version it was fixed? In Karaf 4.0.4 I see the same issue as 
in the linked bug - the init/destroy filter methods are never called. Is it 
supposed to work now?

> 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] [Created] (DOSGI-227) Build fails with JDK 8

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-227:
-

 Summary: 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


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

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-227:
--
Attachment: java8_classloader_fix.diff

Attached an ugly patch to demonstrate the workaround. This one works in Oracle 
JDK 7/8 (untested on JDK 6 or non-Oracle JDKs - AIUI this is an 
implementation-dependent thing).

Perhaps someone with more experience with these XML parser classloader issues 
can suggest a proper fix (boot delegation configuration? explicit classloader? 
something else?)

I hope this is enough to get you started :-)


> 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
> 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] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-6737:
-
Attachment: fix_void_method.diff

added patch with potential fix for the issue.

> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff, bad_client_example.diff, 
> bad_client_example3.diff, fix_void_method.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-6737:
-
Attachment: bad_client_example3.diff

updated example with a flag to use jaxb or aegis, and test exception throwing 
as well.

> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff, bad_client_example.diff, 
> bad_client_example3.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-2548) Aegis component attempts to assign new schema objects with an existing namespace URI to ServiceInfo if consecutive Clients are created for the same WSDL causing XmlSchema

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15119746#comment-15119746
 ] 

Amichai Rothman commented on CXF-2548:
--

I think I just came across the same issue while working on CXF-6737. If you 
take the sample project #3 attached there and set the test flag to use Aegis 
and then press the Go button twice - you will get this exception:
{quote}
org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in 
collection
at org.apache.ws.commons.schema.XmlSchema.(XmlSchema.java:126)
at org.apache.ws.commons.schema.XmlSchema.(XmlSchema.java:140)
at 
org.apache.cxf.common.xmlschema.SchemaCollection.newXmlSchemaInCollection(SchemaCollection.java:194)
at 
org.apache.cxf.service.model.ServiceInfo.addNewSchema(ServiceInfo.java:165)
at 
org.apache.cxf.aegis.databinding.AegisDatabinding.createSchemas(AegisDatabinding.java:450)
at 
org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:262)
at 
org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
at 
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:423)
at 
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:525)
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.ClientFactoryBean.create(ClientFactoryBean.java:91)
at 
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:157)
at 
org.apache.cxf.dosgi.samples.greeter.client.BadClient.createServiceProxy(BadClient.java:45)
at 
org.apache.cxf.dosgi.samples.greeter.client.BadClient.go(BadClient.java:50)
at 
org.apache.cxf.dosgi.samples.greeter.client.GreeterDialog$4.actionPerformed(GreeterDialog.java:114)
...
{quote}

(tested with CXF 3.1.1, which is the version used by the latest DOSGi)

> Aegis component attempts to assign new schema objects with an existing 
> namespace URI to ServiceInfo if consecutive Clients are created for the same 
> WSDL causing XmlSchemaException: Schema name conflict in collection
> ---
>
> Key: CXF-2548
> URL: https://issues.apache.org/jira/browse/CXF-2548
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding
>Affects Versions: 2.2.5, 2.2.6
> Environment: BEA JRockit 1.6.0 + WebLogic 10.3, Sun JDK 1.6.0
>Reporter: Antal Varga
>Priority: Critical
> Fix For: Invalid
>
>
> Revision 826052 changed the behaviour of 
> org.apache.cxf.frontend.ClientFactoryBean.create() so that subsequent calls 
> will create new Client objects.
> The ServiceInfos are cached between the creation of these objects so that the 
> SchemaCollection objects assigned to them also remain the same.
> However when an endpoint is created (it is called for both of the Clients) 
> and org.apache.cxf.aegis.databinding.AegisDatabinding.createSchemas()
> is run then (line 457) a new SchemaInfo is attempted to be added to the 
> schema collection with a namespace URI already in the collection
> (see API component 
> org.apache.cxf.service.model.ServiceInfo.addNewSchema(String)) because it was 
> already added
> during the creation of the previous Client object.
> I think prior to adding the new SchemaInfo it should be checked if an entry 
> with the given namespace URI already exists.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15119737#comment-15119737
 ] 

Amichai Rothman commented on CXF-6737:
--

After applying the patch with the suggested fix, the sample project (example 3) 
works flawlessly when setting the flag to use jaxb, and when setting it to 
aegis it works correctly the first time, and gives an exception on subsequent 
invocations - but the latter seems to be unrelated, perhaps it's triggering 
CXF-2548.

> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff, bad_client_example.diff, 
> bad_client_example3.diff, fix_void_method.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-6737:
-
Attachment: bad_client_example.diff

updated sample (added org.apache.cxf.ws.databinding=jaxb and 
org.apache.cxf.ws.frontent=jaxws properties)

> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff, bad_client_example.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090091#comment-15090091
 ] 

Amichai Rothman commented on CXF-6737:
--

The method in this test project takes no arguments and returns void, so I don't 
think it's related to parameter naming.

Putting a breakpoint in ReflectionServiceFactoryBean.initializeWSDLOperation 
and following the code flow through these 3 methods in the class (as described 
above) appears to point at mis-handling the return type, I think. Maybe it 
shouldn't be calling initializeParameter at all on a void return type? Or void 
should be handled differently within initializeParameter? (btw, it's indeed 
confusing that a method called initializeParameter is being invoked for the 
return type and not only parameters)


> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-6737:
-
Attachment: bad_client_example.diff

I've attached a little mashup that attempts to demonstrate the issue. It's a 
patch on top of the dosgi greeter example, adding another void method to the 
service and a Go button to the dialog that uses a BadClient to attempt to 
invoke the method.

This results in a NO_OPERATION_INFO exception, but if you debug into 
ReflectionServiceFactoryBean you can see the same behavior as reported above 
(and here too, manually changing the flow results in everything working fine).

> ClientProxyFactoryBean doesn't work with void methods
> -
>
> Key: CXF-6737
> URL: https://issues.apache.org/jira/browse/CXF-6737
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: DOSGi 1.7.0
>Reporter: Amichai Rothman
> Attachments: bad_client_example.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods

[Amichai Rothman (JIRA)]

Amichai Rothman created CXF-6737:


 Summary: ClientProxyFactoryBean doesn't work with void methods
 Key: CXF-6737
 URL: https://issues.apache.org/jira/browse/CXF-6737
 Project: CXF
  Issue Type: Bug
Affects Versions: 3.1.1
 Environment: DOSGi 1.7.0
Reporter: Amichai Rothman


I'm trying to use a simple ClientProxyFactoryBean to connect to a 
dosgi-exported service. Without specifying the wsdl url, it doesn't work since 
apparently the method argument names don't match (arg0 vs actual parameter 
name, as explained in CXF-897), so I added the wsdl url. Now service methods 
that have a return value seem to work ok, but those with void return type do 
not.

Further investigation suggests that the issue might be in 
ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning (no 
method for op) instead of binding the operation, because initializeClassInfo 
returns false, because initializeParameter called with the return type (near 
the bottom of initializeClassInfo) returns false, since 
o.getOutput().getMessagePart/getMessagePartByIndex return null (since there are 
no parts - the method can throw an exception, for which the output message 
exists, but there is no actual return type).

A quick test in the debugger shows that if I manipulate the flow manually (e.g. 
execute the if caluse in initializeWSDLOperation after initializeClassInfo 
returns) then the method invocation works ok.

I am not familiar with the inner workings of WSDL or these classes, so I'm not 
sure what is the correct place to apply a fix.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CXF-6246) missing osgi import of javax.jws

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317928#comment-14317928
 ] 

Amichai Rothman commented on CXF-6246:
--

Thanks for the quick resolution!

 missing osgi import of javax.jws
 

 Key: CXF-6246
 URL: https://issues.apache.org/jira/browse/CXF-6246
 Project: CXF
  Issue Type: Bug
  Components: Aegis Databinding
Affects Versions: 2.7.14
Reporter: Amichai Rothman
Assignee: Daniel Kulp
Priority: Minor
 Fix For: 3.0.4, 2.7.15


 In the org.apache.cxf.aegis.type.java5.AnnotationReader class, the two lines
 {code}
 private static final Class? extends Annotation WEB_PARAM = 
 load(javax.jws.WebParam);
 private static final Class? extends Annotation WEB_RESULT = 
 load(javax.jws.WebResult);
 {code}
 attempt to load classes from the javax.jws package reflectively. However, the 
 javax.jws package is not imported in the osgi bundle (jar) headers, which 
 means they will always fail in an osgi environment.
 Please add this package to the bundle's imported packages header (possibly 
 with resolution:=optional, if it should be optional) so that it will behave 
 the same in an osgi environment as it does outside of it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CXF-6246) missing osgi import of javax.jws

[Amichai Rothman (JIRA)]

Amichai Rothman created CXF-6246:


 Summary: missing osgi import of javax.jws
 Key: CXF-6246
 URL: https://issues.apache.org/jira/browse/CXF-6246
 Project: CXF
  Issue Type: Bug
  Components: Aegis Databinding
Affects Versions: 2.7.14
Reporter: Amichai Rothman
Priority: Minor


In the org.apache.cxf.aegis.type.java5.AnnotationReader class, the two lines
{code}
private static final Class? extends Annotation WEB_PARAM = 
load(javax.jws.WebParam);
private static final Class? extends Annotation WEB_RESULT = 
load(javax.jws.WebResult);
{code}

attempt to load classes from the javax.jws package reflectively. However, the 
javax.jws package is not imported in the osgi bundle (jar) headers, which means 
they will always fail in an osgi environment.

Please add this package to the bundle's imported packages header (possibly with 
resolution:=optional, if it should be optional) so that it will behave the same 
in an osgi environment as it does outside of it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DOSGI-217) Security filters don't work in Karaf 3.0.x

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-217:
-

 Summary: 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


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.2#6252)

[jira] [Resolved] (DOSGI-216) ZookeeperStarter restarts ZooKeeper too easily

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-216.
---

   Resolution: Fixed
Fix Version/s: 1.7.0
 Assignee: Amichai Rothman

 ZookeeperStarter restarts ZooKeeper too easily
 --

 Key: DOSGI-216
 URL: https://issues.apache.org/jira/browse/DOSGI-216
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.6.0
Reporter: Timo Heinonen
Assignee: Amichai Rothman
Priority: Minor
 Fix For: 1.7.0


 ZooKeeperStarter shutdowns old zookeeper server and creates new one always 
 when updated() is called even if the configuration is the same as used 
 currently. 
 This issue is very similar to https://issues.apache.org/jira/browse/DOSGI-215



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DOSGI-214) Endpoint publication to discovery does not always work

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-214.
---

   Resolution: Fixed
Fix Version/s: 1.7.0
 Assignee: Amichai Rothman  (was: Christian Schneider)

Nice catch! And a good analysis too - thanks.

I made the second fix using the SimpleServiceTracker helper class though, since 
it's simpler (keeps concurrency logic separate from the business logic) and I 
think using synchronized as suggested would still leave a small gap between 
when addingService returns and when the new service is added to the 
getServiceReferences result where a new export might get lost.

 Endpoint publication to discovery does not always work
 --

 Key: DOSGI-214
 URL: https://issues.apache.org/jira/browse/DOSGI-214
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.6.0
 Environment: Windows 7, Linux (OpenSuse), seems to happen more often 
 with slower CPU computers
Reporter: Timo Heinonen
Assignee: Amichai Rothman
 Fix For: 1.7.0


 TopologyManager bundle's EndpointListenerNotifier does not call all 
 EndpointListener's at all times correctly and therefore some endpoints don't 
 get published to discovery (zookeeper). 
 I found following problems with the current implementation:
 1) TopologyManagerExport.exportServiceUsingRemoteServiceAdmin():
 In the end of the exportServiceUsingRemoteServiceAdmin() notifyListeners() is 
 called before updating endpointregistry. This causes problem in 
 EndpointListenerNotifier, because endpointRepository.getAllEndpoints() does 
 not return correct state before endpoints are updated. Basically problem 
 exists when ServiceTracker's addingService() is called simultaneously for 
 discovery bundle's EndpointLIstener and other thread (call coming from 
 TopologyManagerExport) calls notfiyListeners(). 
 stEndpointListeners.getServiceReferences() does not yet return the endpoint 
 listener of discovery bundle and therefore discovery is not notified. Also, 
 addingService() call does not find endpoint from endpointRegistry and 
 therefore does not publish it.
 FIX: By changing the order of notifyListeners() and addEndpoints() in 
 TopologyManagerExport the above is fixed.
 2) EndpointListenerNotifier is not threadsafe although ServiceTracker is. 
 stEndpointListeners.getServiceReferences() returns just added 
 EndpointListener (the one from discovery bundle) only AFTER whole overrided 
 addingService() method has finished. So following can happen:
 a) addingService() is called with discovery bundle's EPL
 b) super.addingService() call is finished and notifyListener() is called with 
 no new Endpoint because TopologyManagerExport has not yet added it to 
 endPointRepo
 c) TopologyManagerExport calls addEndpoint() and notifyListeners() (in fixed 
 order) and EndpointListenerNotifier does not notify discove EPL, because 
 addingService() call has not yet returned and therefore 
 stEndpointListeners.getServiceReferences() still returns 1 EPL (from 
 topologyManager bundle)
 FIX: Add synchronized (EndpointListenerNotifier.this) to both methods 
 addingService and modifiedService. Also add synchronized (this) to 
 notifyListeners() method so that lock guards call to 
 stdEndpointListeners.getServiceReference(). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DOSGI-215) ZooKeeperDiscovery restarts ZooKeeper-connection for no reason

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-215.
---

   Resolution: Fixed
Fix Version/s: 1.7.0
 Assignee: Amichai Rothman

 ZooKeeperDiscovery restarts ZooKeeper-connection for no reason
 --

 Key: DOSGI-215
 URL: https://issues.apache.org/jira/browse/DOSGI-215
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.6.0
Reporter: Timo Heinonen
Assignee: Amichai Rothman
Priority: Minor
 Fix For: 1.7.0


 ZooKeeperDiscovery class calls createZookeeper() even if the configuration 
 given to updated() method is the same that is currently used. This reconnects 
 to zookeeper for no reason.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (DOSGI-171) service objects are never released (using ungetService)

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681323#comment-13681323
 ] 

Amichai Rothman edited comment on DOSGI-171 at 1/6/14 3:33 PM:
---

Update: most of these usages have been fixed, but a few troublemakers still 
remain. Specifically, getService usages in RemoteServiceAdminCore and 
JaxRSUtils need to be reviewed.


was (Author: amichai):
Update: most of these usages have been fixed, but a few troublemakers still 
remain.

 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

 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.1.5#6160)

[jira] [Resolved] (DOSGI-210) Service registration and memory leaks

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-210.
---

Resolution: Fixed

 Service registration and memory leaks
 -

 Key: DOSGI-210
 URL: https://issues.apache.org/jira/browse/DOSGI-210
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0, 1.6.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


 While doing some memory profiling on a custom application using DOSGi, I 
 noticed after a while there were many existing ZooKeeper instances, with 
 their references being held by multiple registered 
 PublishingEndpointListenerFactory services and some LocalDiscovery references 
 too. Further investigation found several issues:
 1. PublishingEndpointListenerFactory was registered as a service when 
 started, but did not unregister the service when stopped (the bundle itself 
 does not get deactivated, so there's no automatic unregistering).
 2. ZookeeperDiscovery was re-creating a new instance of 
 PublishingEndpointListenerFactory (and the rest of its implementation 
 classes, registrations, etc.) whenever it received a ZooKeeper SyncConnected 
 event, however these can be received more than once in a row (e.g. with a 
 unhandled Disconnected event in between), thus leaking copies of everything 
 it initializes.
 3. LocalDiscovery was missing synchronization code, and also had a little 
 memory leak (filter strings of removed endpoint listeners were never removed 
 from its internal data structures).
 All issues are now fixed, and these memory/service leaks no longer occur.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (DOSGI-51) Passing an object to the server doesn't work correctly

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831595#comment-13831595
 ] 

Amichai Rothman commented on DOSGI-51:
--

I just hit this issue as well. I'm not sure what resolution 'Later' means on a 
closed bug - will anyone ever look at it again if it is closed? In any case I 
think it should be re-opened, since it's still there 4 years later (I'm on JDK 
7u45, DOSGi 1.6-SNAPSHOT). In my case the workaround of specifying the impl 
class in the method signature won't work, since there is more than one 
implementation for the interface, which is pretty much the point of using 
interfaces. Is there any other known workaround or solution?

 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: David Bosschaert
 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 
 

[jira] [Created] (DOSGI-210) Service registration and memory leak

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-210:
-

 Summary: Service registration and memory leak
 Key: DOSGI-210
 URL: https://issues.apache.org/jira/browse/DOSGI-210
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0, 1.6.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


While doing some memory profiling on a custom application using DOSGi, I 
noticed after a while there were many existing ZooKeeper instances, with their 
references being held by multiple registered PublishingEndpointListenerFactory 
services and some LocalDiscovery references too. Further investigation found 
several issues:

1. PublishingEndpointListenerFactory was registered as a service when started, 
but did not unregister the service when stopped (the bundle itself does not get 
deactivated, so there's no automatic unregistering).

2. ZookeeperDiscovery was re-creating a new instance of 
PublishingEndpointListenerFactory (and the rest of its implementation classes, 
registrations, etc.) whenever it received a ZooKeeper SyncConnected event, 
however these can be received more than once in a row (e.g. with a unhandled 
Disconnected event in between), thus leaking copies of everything it 
initializes.

3. LocalDiscovery was missing synchronization code, and also had a little 
memory leak (filter strings of removed endpoint listeners were never removed 
from its internal data structures).

All issues are now fixed, and these memory/service leaks no longer occur.




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (DOSGI-210) Service registration and memory leaks

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-210:
--

Summary: Service registration and memory leaks  (was: Service registration 
and memory leak)

 Service registration and memory leaks
 -

 Key: DOSGI-210
 URL: https://issues.apache.org/jira/browse/DOSGI-210
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0, 1.6.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


 While doing some memory profiling on a custom application using DOSGi, I 
 noticed after a while there were many existing ZooKeeper instances, with 
 their references being held by multiple registered 
 PublishingEndpointListenerFactory services and some LocalDiscovery references 
 too. Further investigation found several issues:
 1. PublishingEndpointListenerFactory was registered as a service when 
 started, but did not unregister the service when stopped (the bundle itself 
 does not get deactivated, so there's no automatic unregistering).
 2. ZookeeperDiscovery was re-creating a new instance of 
 PublishingEndpointListenerFactory (and the rest of its implementation 
 classes, registrations, etc.) whenever it received a ZooKeeper SyncConnected 
 event, however these can be received more than once in a row (e.g. with a 
 unhandled Disconnected event in between), thus leaking copies of everything 
 it initializes.
 3. LocalDiscovery was missing synchronization code, and also had a little 
 memory leak (filter strings of removed endpoint listeners were never removed 
 from its internal data structures).
 All issues are now fixed, and these memory/service leaks no longer occur.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (DOSGI-208) OSGi compendium bundle installed by feature causes problems

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-208.
---

   Resolution: Fixed
Fix Version/s: 1.6.0

Added a new bundle with the minimal required OSGi Compendium exports, which is 
referenced by the feature instead of the full compendium bundle.

 OSGi compendium bundle installed by feature causes problems
 ---

 Key: DOSGI-208
 URL: https://issues.apache.org/jira/browse/DOSGI-208
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.6.0
 Environment: Karaf 2.3.3
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


 The DOSGi feature installs the OSGi compendium bundle. This bundle exports 
 lots of OSGi apis, and when installed in Karaf it causes various failures - 
 for example ActiveMQ fails to start (see AMQ-4777), some blueprint errors 
 etc. This is probably due to duplicate exports of some of these apis. 
 Limiting the exported OSGi packages, i.e. not installing the entire 
 compendium bundle, fixes the issues.
 There are several possible fixes:
 1. Include the OSGi enterprise bundle instead of the compendium. This bundle 
 exports fewer apis, but still more than DOSGi needs, and so can theoretically 
 cause the same sort of issues.
 2. Have one of the core DOSGi bundles embed+import+export only the required 
 OSGi apis via an appropriate maven bundle plugin configuration.
 3. Create a new DOSGi bundle with nothing but the required OSGi exports as in 
 #2.
 After a little discussion 
 (http://irclogs.dankulp.com/logs/irclogger_log/karaf?date=2013-10-11,Fri) it 
 seems #3 is the preferred option.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (DOSGI-208) OSGi compendium bundle installed by feature causes problems

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-208:
-

 Summary: OSGi compendium bundle installed by feature causes 
problems
 Key: DOSGI-208
 URL: https://issues.apache.org/jira/browse/DOSGI-208
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.6.0
 Environment: Karaf 2.3.3
Reporter: Amichai Rothman
Assignee: Amichai Rothman


The DOSGi feature installs the OSGi compendium bundle. This bundle exports lots 
of OSGi apis, and when installed in Karaf it causes various failures - for 
example ActiveMQ fails to start (see AMQ-4777), some blueprint errors etc. This 
is probably due to duplicate exports of some of these apis. Limiting the 
exported OSGi packages, i.e. not installing the entire compendium bundle, fixes 
the issues.

There are several possible fixes:
1. Include the OSGi enterprise bundle instead of the compendium. This bundle 
exports fewer apis, but still more than DOSGi needs, and so can theoretically 
cause the same sort of issues.
2. Have one of the core DOSGi bundles embed+import+export only the required 
OSGi apis via an appropriate maven bundle plugin configuration.
3. Create a new DOSGi bundle with nothing but the required OSGi exports as in 
#2.

After a little discussion 
(http://irclogs.dankulp.com/logs/irclogger_log/karaf?date=2013-10-11,Fri) it 
seems #3 is the preferred option.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (CXF-5188) Leaks in ServiceImpl when stopping/restarting bundles

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739474#comment-13739474
 ] 

Amichai Rothman commented on CXF-5188:
--

The main leak turns out to be higher up the stack in ServerFactoryBean - when a 
server is initialized successfully but then throws an exception when started 
(such as the one above), the exception is propagated and the server is not 
properly disposed of. I fixed it to first destroy the server before propagating 
the exception.

After this fix the main leak (which was easily recreated on almost every 
restart) is closed, but there's still another leak somewhere that's harder to 
recreate, I've seen it a couple of times and haven't tracked it down yet - I'll 
open a separate issue when I have more details.

 Leaks in ServiceImpl when stopping/restarting bundles
 -

 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman
 Attachments: ServiceImpl_leak_snapshot.png


 I've been looking at VisualVM heap dumps after restarting some custom bundles 
 in Karaf and noticed the stopped services (exported via DOSGi) linger in 
 memory and are never garbage collected (screenshot attached, StoreServiceImpl 
 being the lingering custom service). Browsing through the instance hierarchy 
 from the snapshot I found something suspicious - 
 org.apache.cxf.endpoint.ServiceImpl registers the ManagedEndpoint with the 
 ServerLifeCycleManager, but doesn't seem to unregister it when the instance 
 is destroyed. Could this be the memory leak preventing the old bundles from 
 being collected?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CXF-5188) Leaks in ServiceImpl when stopping/restarting bundles

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved CXF-5188.
--

   Resolution: Fixed
Fix Version/s: 2.7.7
Reproduced In: 2.7.2
 Assignee: Amichai Rothman

 Leaks in ServiceImpl when stopping/restarting bundles
 -

 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 2.7.7

 Attachments: ServiceImpl_leak_snapshot.png


 I've been looking at VisualVM heap dumps after restarting some custom bundles 
 in Karaf and noticed the stopped services (exported via DOSGi) linger in 
 memory and are never garbage collected (screenshot attached, StoreServiceImpl 
 being the lingering custom service). Browsing through the instance hierarchy 
 from the snapshot I found something suspicious - 
 org.apache.cxf.endpoint.ServiceImpl registers the ManagedEndpoint with the 
 ServerLifeCycleManager, but doesn't seem to unregister it when the instance 
 is destroyed. Could this be the memory leak preventing the old bundles from 
 being collected?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CXF-5188) Possible memory leak in ServiceImpl

[Amichai Rothman (JIRA)]

Amichai Rothman created CXF-5188:


 Summary: Possible memory leak in ServiceImpl
 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman


I've been looking at VisualVM heap dumps after restarting some custom bundles 
in Karaf and noticed the stopped services (exported via DOSGi) linger in memory 
and are never garbage collected (screenshot attached, StoreServiceImpl being 
the lingering custom service). Browsing through the instance hierarchy from the 
snapshot I found something suspicious - org.apache.cxf.endpoint.ServiceImpl 
registers the ManagedEndpoint with the ServerLifeCycleManager, but doesn't seem 
to unregister it when the instance is destroyed. Could this be the memory leak 
preventing the old bundles from being collected?


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CXF-5188) Possible memory leak in ServiceImpl

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-5188:
-

Attachment: ServiceImpl_leak_snapshot.png

 Possible memory leak in ServiceImpl
 ---

 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman
 Attachments: ServiceImpl_leak_snapshot.png


 I've been looking at VisualVM heap dumps after restarting some custom bundles 
 in Karaf and noticed the stopped services (exported via DOSGi) linger in 
 memory and are never garbage collected (screenshot attached, StoreServiceImpl 
 being the lingering custom service). Browsing through the instance hierarchy 
 from the snapshot I found something suspicious - 
 org.apache.cxf.endpoint.ServiceImpl registers the ManagedEndpoint with the 
 ServerLifeCycleManager, but doesn't seem to unregister it when the instance 
 is destroyed. Could this be the memory leak preventing the old bundles from 
 being collected?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CXF-5188) Possible memory leak in ServiceImpl

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/CXF-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733989#comment-13733989
 ] 

Amichai Rothman commented on CXF-5188:
--

In addition, ServiceImpl adds a listener to the bindingFactory, but never 
removes it. That might explain exceptions that appear when restarting bundles. 
I'm not familiar with these mechanisms, so if someone in the know could have a 
look at ServiceImpl and make sure all the resources/listeners are properly 
managed, that would be great!

java.lang.RuntimeException: Soap 1.1 endpoint already registered on address 
http://192.168.1.100:9000/com/example/MyService
at 
org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:921)
at 
org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)[142:org.apache.cxf.cxf-api:2.7.2]
at 
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:204)[150:org.apache.cxf.cxf-rt-frontend-simple:2.7.2]
at 
org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_25]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41)[161:cxf-dosgi-ri-dsw-cxf:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(TopologyManagerExport.java:185)[160:cxf-dosgi-ri-topology-manager:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.doExportService(TopologyManagerExport.java:168)[160:cxf-dosgi-ri-topology-manager:1.6.0.SNAPSHOT]
at 
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport$3.run(TopologyManagerExport.java:143)[160:cxf-dosgi-ri-topology-manager:1.6.0.SNAPSHOT]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_25]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_25]
at java.lang.Thread.run(Thread.java:724)[:1.7.0_25]


 Possible memory leak in ServiceImpl
 ---

 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman
 Attachments: ServiceImpl_leak_snapshot.png


 I've been looking at VisualVM heap dumps after restarting some custom bundles 
 in Karaf and noticed the stopped services (exported via DOSGi) linger in 
 memory and are never garbage collected (screenshot attached, StoreServiceImpl 
 being the lingering custom service). Browsing through the instance hierarchy 
 from the snapshot I found something suspicious - 
 org.apache.cxf.endpoint.ServiceImpl registers the ManagedEndpoint with the 
 ServerLifeCycleManager, but doesn't seem to unregister it when the instance 
 is destroyed. Could this be the memory leak preventing the old bundles from 
 being collected?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CXF-5188) Leaks in ServiceImpl when stopping/restarting bundles

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CXF-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated CXF-5188:
-

Summary: Leaks in ServiceImpl when stopping/restarting bundles  (was: 
Possible memory leak in ServiceImpl)

 Leaks in ServiceImpl when stopping/restarting bundles
 -

 Key: CXF-5188
 URL: https://issues.apache.org/jira/browse/CXF-5188
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.7.2
 Environment: Karaf 2.3.2, DOSGi 1.6.0-SNAPSHOT
Reporter: Amichai Rothman
 Attachments: ServiceImpl_leak_snapshot.png


 I've been looking at VisualVM heap dumps after restarting some custom bundles 
 in Karaf and noticed the stopped services (exported via DOSGi) linger in 
 memory and are never garbage collected (screenshot attached, StoreServiceImpl 
 being the lingering custom service). Browsing through the instance hierarchy 
 from the snapshot I found something suspicious - 
 org.apache.cxf.endpoint.ServiceImpl registers the ManagedEndpoint with the 
 ServerLifeCycleManager, but doesn't seem to unregister it when the instance 
 is destroyed. Could this be the memory leak preventing the old bundles from 
 being collected?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-199) NoSuchMethodError in tests (Jetty version mismatch)

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-199:
--

Description: 
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)


  was:
When running the tests, I sometimes see the exception below. Seems to be a 
mismatch of eclipse/pax-web Jetty dependency versions.

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 

[jira] [Created] (DOSGI-200) ServiceConstructionException in tests

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-200:
-

 Summary: 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


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.init(ServerImpl.java:72)
at 
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:160)
... 15 more


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-199) NoSuchMethodError in tests (Jetty version mismatch)

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-199:
-

 Summary: 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
Priority: Minor


When running the tests, I sometimes see the exception below. Seems to be a 
mismatch of eclipse/pax-web Jetty dependency versions.

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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-198) Imported service is gone after client bundle is restarted

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-198:
-

 Summary: Imported service is gone after client bundle is restarted
 Key: DOSGI-198
 URL: https://issues.apache.org/jira/browse/DOSGI-198
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.6.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman


When a local bundle uses a remote (imported) service using ZooKeeper discovery, 
and the local bundle is restarted, the imported service may no longer be 
available (until the remote service bundle is also restarted).

This may occur inconsistently due to a race condition - I've managed to 
recreate it in a debugger such that whenever I stop at some breakpoint in 
TopologyManagerImport for a few seconds the service is re-imported properly, 
but when I let it run without stalling at a breakpoint it is never imported 
after the bundle restart.

After much investigation the root cause was found to be in the ZooKeeper 
discovery's InterfaceMonitorManager, which does not properly notify modified 
EndpointListeners of pre-discovered endpoints. When the client bundle is 
restarted, the TopologyManagerImport (which is an EndpointListener) service 
properties are modified to reflect the changing interest scope (reduce followed 
by expand of requested remote service), but due to said bug it will not receive 
a notification about the previously-known remote service endpoint. Since the 
TMI's actual un-export/re-import is done in a separate thread, there is a race 
condition of whether or not the endpoint will be known at the time of import, 
and thus it will sometimes not be re-imported.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-198) Imported service is gone after client bundle is restarted

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-198:
--

Affects Version/s: (was: 1.6.0)
   1.5.0

 Imported service is gone after client bundle is restarted
 -

 Key: DOSGI-198
 URL: https://issues.apache.org/jira/browse/DOSGI-198
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


 When a local bundle uses a remote (imported) service using ZooKeeper 
 discovery, and the local bundle is restarted, the imported service may no 
 longer be available (until the remote service bundle is also restarted).
 This may occur inconsistently due to a race condition - I've managed to 
 recreate it in a debugger such that whenever I stop at some breakpoint in 
 TopologyManagerImport for a few seconds the service is re-imported properly, 
 but when I let it run without stalling at a breakpoint it is never imported 
 after the bundle restart.
 After much investigation the root cause was found to be in the ZooKeeper 
 discovery's InterfaceMonitorManager, which does not properly notify modified 
 EndpointListeners of pre-discovered endpoints. When the client bundle is 
 restarted, the TopologyManagerImport (which is an EndpointListener) service 
 properties are modified to reflect the changing interest scope (reduce 
 followed by expand of requested remote service), but due to said bug it will 
 not receive a notification about the previously-known remote service 
 endpoint. Since the TMI's actual un-export/re-import is done in a separate 
 thread, there is a race condition of whether or not the endpoint will be 
 known at the time of import, and thus it will sometimes not be re-imported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-198) Imported service is gone after client bundle is restarted

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-198.
---

   Resolution: Fixed
Fix Version/s: 1.6.0

 Imported service is gone after client bundle is restarted
 -

 Key: DOSGI-198
 URL: https://issues.apache.org/jira/browse/DOSGI-198
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.6.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.6.0


 When a local bundle uses a remote (imported) service using ZooKeeper 
 discovery, and the local bundle is restarted, the imported service may no 
 longer be available (until the remote service bundle is also restarted).
 This may occur inconsistently due to a race condition - I've managed to 
 recreate it in a debugger such that whenever I stop at some breakpoint in 
 TopologyManagerImport for a few seconds the service is re-imported properly, 
 but when I let it run without stalling at a breakpoint it is never imported 
 after the bundle restart.
 After much investigation the root cause was found to be in the ZooKeeper 
 discovery's InterfaceMonitorManager, which does not properly notify modified 
 EndpointListeners of pre-discovered endpoints. When the client bundle is 
 restarted, the TopologyManagerImport (which is an EndpointListener) service 
 properties are modified to reflect the changing interest scope (reduce 
 followed by expand of requested remote service), but due to said bug it will 
 not receive a notification about the previously-known remote service 
 endpoint. Since the TMI's actual un-export/re-import is done in a separate 
 thread, there is a race condition of whether or not the endpoint will be 
 known at the time of import, and thus it will sometimes not be re-imported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689444#comment-13689444
 ] 

Amichai Rothman commented on DOSGI-108:
---

Answering Sergey's previous question, the main things that triggered me to 
raise this discussion, and which should be taken into consideration, are:

- This issue was opened not due to lacking functionality or an implementation 
error, but simply due to overlooking how to configure things by the book (it 
happens.) There was no real issue with DOSGi that needed solving, just a 
friendly pointer to an external spec (which I've added above for anyone who 
might stumble upon this). To the best of my knowledge a multi-valued property 
is supported in DS/SCR, Blueprint, direct coding - what is the use case where 
this extension is useful?
 
- I honestly don't know why the DOSGi website said the service property can be 
comma separated (when at the time it was not supported in practice). Maybe 
there was demand for this elsewhere, which should be considered. Maybe it was 
just a documentation bug.

- I'm of the opinion that non-compliance with specs, and complexity in general, 
should not be encouraged unless there is a significant benefit. Otherwise it 
just ends up wasting people's time (whether devs or users).

- This is not just an extension of the spec, it actually breaks it. String+ 
properties are not limited in what strings they contain, and commas are valid 
characters within them, so splitting them around commas is inviting a new bug. 
The specific property discussed here contains interface/class names, so that's 
safe for commas, but this is implemented as a general-purpose method that is 
and will be used for other properties as well. I was considering adding a 
boolean parameter specifying this, with an appropriate warning in its javadoc, 
and doing the extra parsing only for this one property. Then again, supporting 
this syntax in some properties and not in others is even more confusing to 
users and complicates documentation.

- My guess is that this is functionality that is rarely used in any case (and 
as mentioned before, not sure it even works - if not, then nobody uses it, and 
even backwards compatibility is not needed). Most users just export one 
interface.

So all things considered, I'm not convinced that it's useful enough (or at all) 
to be worth the added complexity, implementation, documentation, non-compliance 
and risks. Thus I recommended to just kill the feature, leaving only minimal 
backwards-compatibility (support only for this particular property, with a 
deprecated notice, and correcting the docs so this doesn't continue being used).

Of course, I may be wrong :-)


 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: 1.3


 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-193) Split discovery.zookeeper package into subpackages

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-193:
-

 Summary: Split discovery.zookeeper package into subpackages
 Key: DOSGI-193
 URL: https://issues.apache.org/jira/browse/DOSGI-193
 Project: CXF Distributed OSGi
  Issue Type: Improvement
  Components: Discovery
Affects Versions: 1.4.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
Priority: Minor


The o.a.c.d.discovery.zookeeper package contains two distinct and independent 
sets of classes: Those responsible for publishing local endpoints to ZooKeeper, 
and those responsible for listening for endpoints that are remotely published 
to ZooKeeper. These should be grouped into two corresponding subpackages to 
better convey the code structure and function.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-193) Split discovery.zookeeper package into subpackages

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-193.
---

   Resolution: Fixed
Fix Version/s: 1.5.0

 Split discovery.zookeeper package into subpackages
 --

 Key: DOSGI-193
 URL: https://issues.apache.org/jira/browse/DOSGI-193
 Project: CXF Distributed OSGi
  Issue Type: Improvement
  Components: Discovery
Affects Versions: 1.4.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
Priority: Minor
 Fix For: 1.5.0


 The o.a.c.d.discovery.zookeeper package contains two distinct and independent 
 sets of classes: Those responsible for publishing local endpoints to 
 ZooKeeper, and those responsible for listening for endpoints that are 
 remotely published to ZooKeeper. These should be grouped into two 
 corresponding subpackages to better convey the code structure and function.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689681#comment-13689681
 ] 

Amichai Rothman commented on DOSGI-108:
---

If that's the consensus then no problem - let's just leave it alone.

 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: 1.3


 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-191) ZooKeeperDiscovery instance reconnects to ZooKeeper after bundle is stopped

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-191:
-

 Summary: ZooKeeperDiscovery instance reconnects to ZooKeeper after 
bundle is stopped
 Key: DOSGI-191
 URL: https://issues.apache.org/jira/browse/DOSGI-191
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.4.0, 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman


After the ZooKeeper discovery bundle is stopped, which also closes the 
ZooKeeper instance, ZooKeeperDiscovery still gets the Expired notification from 
ZK, but then goes on to create a new ZooKeeper instace and start it.

This also relates to ZOOKEEPER-795, which was fixed on a later version than the 
one we use.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-191) ZooKeeperDiscovery instance reconnects to ZooKeeper after bundle is stopped

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-191.
---

   Resolution: Fixed
Fix Version/s: 1.5.0

Fixed, although the ZK event thread is still not being shut down - that is the 
ZOOKEEPER-795 bug. I'm closing this issue anyway under the assumption that 
we'll be upgrading the ZK dependency library to a newer version in any case 
when the new release comes out.

 ZooKeeperDiscovery instance reconnects to ZooKeeper after bundle is stopped
 ---

 Key: DOSGI-191
 URL: https://issues.apache.org/jira/browse/DOSGI-191
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.4.0, 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0


 After the ZooKeeper discovery bundle is stopped, which also closes the 
 ZooKeeper instance, ZooKeeperDiscovery still gets the Expired notification 
 from ZK, but then goes on to create a new ZooKeeper instace and start it.
 This also relates to ZOOKEEPER-795, which was fixed on a later version than 
 the one we use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681050#comment-13681050
 ] 

Amichai Rothman commented on DOSGI-108:
---

I think this fix is problematic:

* It changed a String+ property parsing method (normalizeStringPlus) to accept 
a single comma-separated string and split it into an array of strings, while I 
can't find any indication in the specs that this is a valid interpretation of a 
String+ property value. If I am correct, then we are actually encouraging users 
to use a non-compliant (and thus non-portable) configuration, and possibly 
propagating the error to other properties which are parsed using the same 
method.

* The two properties in the link above are said to be of type String, while the 
specs say they are in fact of type String+. Our doc seems incorrect, which 
caused us to fix something that wasn't broken in the code. We should probably 
just fix the docs (change the property type, and remove the 'comma separated' 
part).

* To my understanding of section 112.4.5 of the OSGi 4.2 compendium spec about 
Declerative Services properties, under the bullet 'element body', a String[] 
value for a property can be defined by omitting the value attribute from an 
element, and instead putting the values on separate lines in the element body. 
So in our case we would replace e.g.
{code:xml}
property name=service.exported.interfaces value=interface1,interface2 /
{code}
with
{code:xml}
property name=service.exported.interfaces
interface1
interface2
/property
{code}
(disclaimer: I didn't try this - I'm just reading the spec).

I think the proper fix is to revert the code changes, fix the documentation, 
and let users change their configuration into a valid one. As a bonus, this 
would also allow us to consolidate the 4 different String+ parsing utility 
methods in our codebase into one.

Any thoughts? Did I miss anything?

Also, how should we handle backward compatibility on this? Put a bold warning 
in the docs? Make comma-separated values deprecated but still work for another 
version or two? Just fix it and write about it in the release notes?


 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: 1.3


 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-171) service objects are never released (using ungetService)

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681323#comment-13681323
 ] 

Amichai Rothman commented on DOSGI-171:
---

Update: most of these usages have been fixed, but a few troublemakers still 
remain.

 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

 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-188) services aren't re-imported after RemoteServiceAdmin restart

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-188.
---

   Resolution: Fixed
Fix Version/s: 1.5.0

 services aren't re-imported after RemoteServiceAdmin restart
 

 Key: DOSGI-188
 URL: https://issues.apache.org/jira/browse/DOSGI-188
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.4.0, 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0


 After restarting the Remote Service Admin bundle, previously imported 
 services are not re-imported and are no longer available. This happens 
 because they are not closed properly, so the topology manager thinks the 
 imports are still available when in fact they are not, and as a result does 
 not re-import them when the RSA is started again.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-161) services sometimes don't get exported

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-161.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

Fixed, using a different approach for the tracker misuse - by fixing the custom 
tracker (previously RemoteServiceAdminTracker, now the general-purpose 
SimpleServiceTracker) to include a newly added service in the returned list of 
services even if called from within the event handler (unlike the 
ServiceTracker.getServices() behavior).

 services sometimes don't get exported
 -

 Key: DOSGI-161
 URL: https://issues.apache.org/jira/browse/DOSGI-161
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.4.0
 Environment: Oracle JDK 1.7.0_17, Karaf 2.3.1, DOSGi 1.4.0 (installed 
 from Karaf feature)
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_topologymanagerexport_1.diff, 
 fix_topologymanagerexport_2.diff, fix_topologymanagerexport_3.diff


 When starting up a fresh Karaf instance repeatedly, a service that should be 
 exported sometimes does not in fact get exported. The issue stems from some 
 bugs in the TopologyManagerExport class, the main ones being wrong 
 assumptions about the state of the Tracker within its callback method (during 
 the callback its internal state is not yet updated, but the code assumes it 
 is), unconditional overwriting of data structures (which may already exist) 
 and synchronization issues.
 During my investigations I came across various other small issues and 
 enhancements in the class, so the provided patch includes the final result I 
 arrived with including all changes. I've split it up into several consecutive 
 patches in order to make the review easier. These are the changes:
 Patch #1 - cleanup (no semantic changes):
 - fixed typos in docs and logs.
 - fixed formatting to be more consistent and readable.
 - added debug logs to RemoteServiceAdminLifeCycleListener.added/removed 
 callbacks (this proved the serious tracker bug below, but is also useful for 
 general debugging).
 - simplified shouldExportService returned boolean expression.
 - removed removeExportRegistration, removeExportReference and 
 remoteAdminEvent methods, all of which are both unused and have a no-op 
 implementation.
 Patch #2 (improved iterations):
 - replaced iterations on map keys followed by a get of the corresponding 
 value with an iteration on Map.Entry (prevents unnecessary lookups).
 - replaced map containsKey checks followed by get with a get followed by null 
 check (prevents unnecessary lookups, and theoretically race conditions too).
 - fixed remoteServiceAdmin.exportService return value handling - its docs say 
 the result can never be null, but the code assumes it might be. This is now 
 replaced with an isEmpty() check instead, I hope there are no other 
 consequences. The reason this is bundled with the iterations fixes is since 
 it shows explicitly that map values cannot in fact be null, which proves the 
 iteration fixes to be correct (i.e. if Map.get returns null, the key does not 
 exist, so this is equivalent to calling Map.containsKey).
 Patch #3 (tracker and sync issues):
 - fixed tracker misuse: when tracker callback (added) is called, the tracker 
 itself does not yet reflect the new state, so accessing services (or size) on 
 the tracker from within the callback will fail to include the new service. 
 Although the actual service export triggered by the callback is performed on 
 a separate thread, this still leaves a race condition between the two which 
 sometimes causes the export to fail (with No RemoteServiceAdmin available! 
 log). To fix this, the newly added RSA is passed down the method chain to the 
 doExportService method explicitly. doExportService then uses the reference if 
 it is given, or if null (as when called from elsewhere), uses the tracker to 
 get the service list as it did in the past.
 - fixed exportService always overwriting a service's entry in 
 exportedServices with a new empty data structure - now it only does so if it 
 does not already exist.
 - fixed exportedServices inner maps to be created as synchronized maps - 
 previously doExportService wrapped it in a synchronized map on each 
 invocation, which results effectively in no synchronization, since the 
 synchronized wrapper map is local only so each thread accessing the map uses 
 a different lock. Also fixed other accesses of the inner maps to be 
 synchronized (Collections.synchronizedMap requires external synchronization 
 on it when being iterated, as specified in the docs).
 - fixed exports null check in doExportService (in the old code, 
 

[jira] [Commented] (DOSGI-114) RemoteServiceAdmin is not available warnings in DOSGi 1.3

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677628#comment-13677628
 ] 

Amichai Rothman commented on DOSGI-114:
---

I'm not familiar with the full history of this issue, but thought it might be 
helpful to mention that DOSGI-160 and DOSGI-161, which were recently fixed in 
1.5, could also be possible causes for the No RemoteServiceAdmin available 
error (in addition to whatever was fixed in 1.4). In my own experience I 
haven't seen the error since working with the fixes in 1.5. It would be great 
to hear if anyone can reproduce this or related issues in a current 1.5 
snapshot.

 RemoteServiceAdmin is not available warnings in DOSGi 1.3
 -

 Key: DOSGI-114
 URL: https://issues.apache.org/jira/browse/DOSGI-114
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.3
Reporter: Sergey Beryozkin
Assignee: Christian Schneider
 Fix For: 1.4.0


 Some users have reported that the RemoteServiceAdmin is not available in 1.3, 
 example:
  SEVERE: No RemoteServiceAdmin available! Unable to export service from
   bundle cxf-dosgi-ri-samples-greeter-rest-impl
 Needs to be confirmed with the existing demos

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-158) NPE on shutdown of DOSGi service

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-158.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

This was fixed along with DOSGI-175 in the new ReferenceCounter class.

 NPE on shutdown of DOSGi service
 

 Key: DOSGI-158
 URL: https://issues.apache.org/jira/browse/DOSGI-158
 Project: CXF Distributed OSGi
  Issue Type: Bug
Reporter: Christoph Läubrich
Assignee: Amichai Rothman
 Fix For: 1.5.0


 Shutting down the framework results in NPE thrown (using the multi bundle 
 version):
 {code}org.osgi.framework.ServiceException: Exception in 
 org.apache.cxf.dosgi.topologymanager.importer.ListenerHookImpl.removed()
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1247)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1222)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyListenerHooksPrivileged(ServiceRegistry.java:1342)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyListenerHooks(ServiceRegistry.java:1324)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.removeServiceListener(ServiceRegistry.java:730)
   at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.removeServiceListener(BundleContextImpl.java:258)
   at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:400)
   at 
 org.apache.cxf.dosgi.topologymanager.exporter.EndpointListenerNotifier.stop(EndpointListenerNotifier.java:75)
   at 
 org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.stop(TopologyManagerExport.java:176)
   at 
 org.apache.cxf.dosgi.topologymanager.Activator.stop(Activator.java:50)
   at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
   at 
 org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
   at 
 org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:565)
   at 
 org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1161)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:595)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257)
   at 
 org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215)
   at 
 org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284)
   at 
 org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:691)
   at 
 org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:598)
   at 
 org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._close(FrameworkCommandProvider.java:1224)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
 org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:209)
   at 
 org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:155)
   at 
 org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:140)
   at 
 org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:104)
   at java.lang.Thread.run(Unknown Source)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.cxf.dosgi.topologymanager.importer.RefManager.removeReference(RefManager.java:55)
   at 
 org.apache.cxf.dosgi.topologymanager.importer.TopologyManagerImport.removeServiceInterest(TopologyManagerImport.java:130)
   at 
 org.apache.cxf.dosgi.topologymanager.importer.ListenerHookImpl.removed(ListenerHookImpl.java:111)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$10.call(ServiceRegistry.java:1348)
   at 
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1239)
   ... 31 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-151) java.lang.NoClassDefFoundError: org/apache/log4j/Logger

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-151.
---

Resolution: Duplicate

 java.lang.NoClassDefFoundError: org/apache/log4j/Logger
 ---

 Key: DOSGI-151
 URL: https://issues.apache.org/jira/browse/DOSGI-151
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.4.0
 Environment: 1 JDK 1.6
 2 zookeeper-3.4.5
 3 Windows XP Sp2
 4 DOSGi 1.4 Trunk SnapShot
Reporter: TangYong

 While using DOSGi Discovery with zookeeper, if not putting/installing log4j 
 bundle, the following exception will be thrown:
 D:\gf\org.apache.felix.main.distribution-4.0.3\felix-framework-4.0.3java 
 -jar bin\felix.jar
 *ERROR* [org.osgi.service.cm.ManagedService, id=11, bundle=1]: Unexpected 
 problem updating Configuration PID=org.apache.cxf.dosgi.discovery.zookeeper, 
 factoryPID=null, 
 bundleLocation=file:/D:/gf/org.apache.felix.main.distribution-4.0.3/felix-framework-4.0.3/bundle/cxf-dosgi-ri-singlebundle-distribution-1.4-SNAPSHOT.jar
 java.lang.NoClassDefFoundError: org/apache/log4j/Logger
 at org.apache.zookeeper.ZooKeeper.clinit(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:662)
 Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger not 
 found by cxf-dosgi-ri-singlebundle-distribution [1]
 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
 
 Welcome to Apache Felix Gogo
 Although this can be considered as a user error, dosgi-discovery[1] should 
 give us more stating and let user can install log4j bundle in ahead of time.
 [1]:http://cxf.apache.org/dosgi-discovery.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-176) zookeeper discovery sending multiple duplicate endpoint notifications

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-176.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

 zookeeper discovery sending multiple duplicate endpoint notifications
 -

 Key: DOSGI-176
 URL: https://issues.apache.org/jira/browse/DOSGI-176
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_duplicate_endpoint_notifications.diff


 To my understanding of the current behavior, the InterfaceMonitorManager 
 creates a ZooKeeper watcher (InterfaceMonitor) per scope. The 
 InterfaceMonitor however monitors ZK nodes according to the objectClass 
 (ignoring scope). When a ZK node change is detected, the IMs watching that 
 node all trigger IMM's event handler. But instead of sending out the 
 EndpointListener events corresponding to the scope for which each IM was 
 created, it loops through all of the EndpointListener requested scopes and 
 notifies the first matching one. This effectively causes multiple events to 
 be triggered for the same scope (instead of one per IM scope), and possibly 
 others to be missed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-173) unregistering an exported service does not remove it from zookeeper (and remote clients)

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-173.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

The first part of this issue, incorrect closing of exported services, is fixed 
by DOSGI-180.

The second part, removing unnecessary recreation of InterfaceMonitors, is 
committed.

 unregistering an exported service does not remove it from zookeeper (and 
 remote clients)
 

 Key: DOSGI-173
 URL: https://issues.apache.org/jira/browse/DOSGI-173
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_zk_unregisteration.diff


 I have some bundles exporting and consuming services, running on two hosts. 
 I've noticed more than once that while stopping and starting different 
 bundles on the two hosts (just playing around with them manually to see how 
 robust the distributed system is), at some point one of the hosts doesn't see 
 that a service it was using from the other host is down. Connecting to 
 ZooKeeper directly, I see the node for that service is still there, i.e. the 
 service was not properly removed from ZK even though the bundle is stopped 
 and service is gone.
 Investigating this is a bit tricky, since it involves various trackers, 
 endpoint listeners and service listeners and there is not enough code 
 documentation to understand what the intended flow is... however I've found a 
 few interesting related findings that may point at the solution:
 1. Following the logs and some debugging, it appears that the problem is not 
 with the discovery.zookeeper package/bundle itself, since the endpoint 
 removed event never gets there.
 2. In EndpointListenerNotifier.notifyListenersOfRemoval(), the 
 EndpointDescription appears to be null, so there is never a filter match and 
 the endpointRemoved callback is never triggered on the EndpointListeners. 
 This is because all of the ExportRegistrations are already closed by the time 
 they get there. It seems that the premature closing is done by the service 
 tracker created in ExportRegistrationImpl.startServiceTracker(). My guess is 
 that the order in which the service tracker and service listener (in 
 TopologyManagerExport, which triggers the EndpointListenerNotifier) receive 
 the events is arbitrary depending on some race condition somewhere, which may 
 explain why this is an inconsistently reproducible bug. I would like to say 
 that the solution is to get rid of the service tracker altogether (it doesn't 
 do anything else, and as a separate bug, is never closed), but I'm not sure 
 why it was introduced in the first place or if there are any other scenarios 
 in which it was necessary, so I really don't know what the proper solution 
 should be.
 3. Another element that may have been masking this bug to some degree is the 
 local discovery bundle which was running, and during debugging I saw it 
 triggering some EndpointListener removal events which were picked up by the 
 other components. I'm not entirely sure yet of what this bundle does (I 
 didn't find any mention of it on the website, and didn't get to the code 
 yet), but I just leave this bundle in the stopped state for now, with no 
 visible effects on the testing, making debugging easier.
 4. An additional related issue which bugged me during a previous code review 
 was that InterfaceMonitorManager.addInterest() is closing and recreating an 
 InterfaceMonitor every time it is invoked with an existing scope, even though 
 the old and new IMs monitor the same ZK node and are practically identical - 
 so why not just leave the old monitor running? This replacement causes a 
 bunch of unnecessary extra work (including several ZK server accesses), a 
 flurry of unnecessary filter-matching logs, and and unnecessary gap in 
 monitoring for ZK changes. This also relates to the bug at hand since 
 InterfaceMonitor.close() also sends some EndpointListener notifications about 
 the endpoints being removed, which leaves some gaps in the registration 
 coverage (before they are re-added moments later) and might interact in some 
 other unpredictable (at least to me) way with the rest of the mechanism. It 
 seems these IM close/start cycles sometimes occur tens of times in a row.
 To sum it up, there's definitely a bug occurring. When I tested a bit with 
 fixes for both potential causes above (IM stop/start replaced with a single 
 start the first time a given scope is encountered, and close invocation in 
 service tracker removed) - I could no longer recreate the bug, but I don't 
 understand all the component 

[jira] [Resolved] (DOSGI-177) stopped services still appear as available to clients

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-177.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

 stopped services still appear as available to clients
 -

 Key: DOSGI-177
 URL: https://issues.apache.org/jira/browse/DOSGI-177
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_services_not_removed.diff


 Sometimes TopologyManagerImport receives more than one endpointAdded event 
 for the same endpoint and filter. Currently this causes it to add the 
 endpoint multiple times to an internal list. However when the endpoint is 
 removed, only one endpointRemoved event is triggered, one instance is removed 
 from the list, and the other copies remain. The rest of the code treats this 
 as the endpoint still being available, which is what the clients see as well 
 (the import is never closed).
 The patch simply adds a check so that the endpoint will not be added to the 
 list if it's already there. It also removes empty import lists when all 
 imports are removed, preventing a leak.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-174) synchronization issues and resource leaks in TopologyManagerImport and related classes

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-174.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

 synchronization issues and resource leaks in TopologyManagerImport and 
 related classes
 --

 Key: DOSGI-174
 URL: https://issues.apache.org/jira/browse/DOSGI-174
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_sync_and_leaks.diff


 The synchronization is missing and/or incorrect, and items are not properly 
 cleaned up from the internal data structures when they are no longer needed, 
 and sometimes added when not needed in the first place. The patch includes:
 - cleaned up and simplified some code
 - fixed some docs and logs
 - changed EndpointListenerNotifier to skip null endpoints (reducing 
 unnecessary processing and many logs)
 - made method access modifiers more consistent
 - fixed synchronization and concurrency issues
 - fixed memory leak (items not removed from data structure, or added when 
 unnecessary)
 - fixed closing of resources

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-172) o.a.c.d.discovery.zookeeper package classes are not properly synchronized

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-172.
---

   Resolution: Fixed
Fix Version/s: 1.5.0
 Assignee: Amichai Rothman

 o.a.c.d.discovery.zookeeper package classes are not properly synchronized
 -

 Key: DOSGI-172
 URL: https://issues.apache.org/jira/browse/DOSGI-172
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_discovery_zk_1.diff, fix_discovery_zk_2.diff, 
 fix_discovery_zk_3.diff


 The org.apache.cxf.dosgi.discovery.zookeeper package classes are not properly 
 synchronized - some synchronization is missing, some is incorrect. These 
 classes must be thread-safe since they use events triggered by various 
 sources and threads.
 The provided patch set is split into 3 parts: the first two include some 
 cleanup and organizing of the code (split into 2 parts for easier review), 
 and the third contains the synchronization fixes themselves.
 There are a few debug logs added and some little refactorings which you may 
 or may not wish to commit (I find them all useful, but realize some may be a 
 matter of taste).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-175) TopologyManagerImport's reference counter doesn't count

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-175:
--

Assignee: Amichai Rothman

 TopologyManagerImport's reference counter doesn't count
 ---

 Key: DOSGI-175
 URL: https://issues.apache.org/jira/browse/DOSGI-175
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Attachments: fix_ref_count.diff


 the RefManager class used by TopologyManagerImport is supposed to manage 
 reference counts for the various filters its clients are interested in, 
 however the current implementation doesn't count - it just stays at zero 
 after every add, and consequently is marked as released at every release. 
 This causes mismanagement of the references by the TMI.
 In addition, while debugging I've seen removeServiceInterest called with 
 filters that have no reference count (even after the fix for the above 
 issue), which would cause it to throw an exception. The fix handles this by 
 returning -1 as the reference count, and the TMI simply ignores this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-175) TopologyManagerImport's reference counter doesn't count

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667157#comment-13667157
 ] 

Amichai Rothman commented on DOSGI-175:
---

I eventually replaced the suggested fixes in RefManager with a brand new 
ReferenceCounter class which is lock-less and generified.

 TopologyManagerImport's reference counter doesn't count
 ---

 Key: DOSGI-175
 URL: https://issues.apache.org/jira/browse/DOSGI-175
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Attachments: fix_ref_count.diff


 the RefManager class used by TopologyManagerImport is supposed to manage 
 reference counts for the various filters its clients are interested in, 
 however the current implementation doesn't count - it just stays at zero 
 after every add, and consequently is marked as released at every release. 
 This causes mismanagement of the references by the TMI.
 In addition, while debugging I've seen removeServiceInterest called with 
 filters that have no reference count (even after the fix for the above 
 issue), which would cause it to throw an exception. The fix handles this by 
 returning -1 as the reference count, and the TMI simply ignores this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DOSGI-175) TopologyManagerImport's reference counter doesn't count

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman resolved DOSGI-175.
---

   Resolution: Fixed
Fix Version/s: 1.5.0

 TopologyManagerImport's reference counter doesn't count
 ---

 Key: DOSGI-175
 URL: https://issues.apache.org/jira/browse/DOSGI-175
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Amichai Rothman
Assignee: Amichai Rothman
 Fix For: 1.5.0

 Attachments: fix_ref_count.diff


 the RefManager class used by TopologyManagerImport is supposed to manage 
 reference counts for the various filters its clients are interested in, 
 however the current implementation doesn't count - it just stays at zero 
 after every add, and consequently is marked as released at every release. 
 This causes mismanagement of the references by the TMI.
 In addition, while debugging I've seen removeServiceInterest called with 
 filters that have no reference count (even after the fix for the above 
 issue), which would cause it to throw an exception. The fix handles this by 
 returning -1 as the reference count, and the TMI simply ignores this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-162) Compilation errors when using OSGi core 4.3.0/4.3.1/5.0.0

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666518#comment-13666518
 ] 

Amichai Rothman commented on DOSGI-162:
---

As it turns out, the Felix Framework bundle indeed contains a copy of the 
org.osgi core packages, so even when the osgi bundle versions were changed, it 
was still compiling against the older osgi API. Updating the corresponding 
Felix version caused it to actually compile against the newer osgi API. I've 
added a comment explaining this in the pom, plus the two missing fixes (missing 
cast and one forgotten dependency version fix).

 Compilation errors when using OSGi core 4.3.0/4.3.1/5.0.0
 -

 Key: DOSGI-162
 URL: https://issues.apache.org/jira/browse/DOSGI-162
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.4.0
 Environment: Oracle JDK 1.7.0_17
Reporter: Amichai Rothman
Assignee: Christian Schneider
Priority: Minor
 Fix For: 1.5.0

 Attachments: fix_osgi_compilation_errors.diff


 When trying to compile against the OSGi core library releases 4.3.0, 4.3.1 
 and 5.0.0, there are several compilation errors. The fix includes:
 - cast null to String when calling BundleContext.getServiceReferences (an 
 overloaded method was added, and passing null now causes ambiguity)
 - fix generic types and use of Properties (which extend HashtableObject, 
 Object), by using DictionaryString, String implemented as 
 HashtableString, String instead.
 - split between osgi.version and osgi.enterprise.version POM properties since 
 the two have independent release versions (specifically, there are no 
 enterprise 4.3.0/4.3.1 releases).
 The fix is backward-compatible, so compilation is successful on 
 4.2.0/4.3.0/4.3.1/5.0.0 with the patch applied. However, there are still 4 
 unit tests which fail in the later versions, but these are unrelated to the 
 compilation errors and have to do with other dependency library versions (the 
 patch does not change any versions). So consider this the first step.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-180) CXF service does not disappear if exporting bundle is stopped

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661886#comment-13661886
 ] 

Amichai Rothman commented on DOSGI-180:
---

See also DOSGI-173...

 CXF service does not disappear if exporting bundle is stopped
 -

 Key: DOSGI-180
 URL: https://issues.apache.org/jira/browse/DOSGI-180
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.4.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 1.5


 I used the example at https://github.com/sneakybeaky/DOSGi-Spike but with an 
 address of /display.
 The cxf endpoint came up when starting the feature but did not go down when 
 stopping the service bundle.
 See this post for the original bug report:
 http://cxf.547215.n5.nabble.com/DOSGi-service-still-available-after-being-unregistered-td5727594.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (DOSGI-180) CXF service does not disappear if exporting bundle is stopped

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661886#comment-13661886
 ] 

Amichai Rothman edited comment on DOSGI-180 at 5/20/13 10:27 AM:
-

Original issue is likely a duplicate of DOSGI-165.

See also DOSGI-173 for ZooKeeper issue...


  was (Author: amichai):
See also DOSGI-173...
  
 CXF service does not disappear if exporting bundle is stopped
 -

 Key: DOSGI-180
 URL: https://issues.apache.org/jira/browse/DOSGI-180
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.4.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 1.5


 I used the example at https://github.com/sneakybeaky/DOSGi-Spike but with an 
 address of /display.
 The cxf endpoint came up when starting the feature but did not go down when 
 stopping the service bundle.
 See this post for the original bug report:
 http://cxf.547215.n5.nabble.com/DOSGi-service-still-available-after-being-unregistered-td5727594.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-180) CXF service does not disappear if exporting bundle is stopped

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661911#comment-13661911
 ] 

Amichai Rothman commented on DOSGI-180:
---

I see... I understood from above that the original report is DOSGI-165 which 
could not be recreated with the current snapshot, whereas the zookeeper issue 
sounded like DOSGI-173 (whose patch was not yet applied), but I may have missed 
something.

I'm afraid of double-work being done until previous patches will be applied, as 
I've encountered some of these issues too in my tests and already made some 
fixes that appear to be duplicated in the latest commits, but I hope soon 
everything will be up to date and the slate will be clean for further tests and 
fixes. I'll review everything in any case. I hope the patch merges won't be too 
painful :-)


 CXF service does not disappear if exporting bundle is stopped
 -

 Key: DOSGI-180
 URL: https://issues.apache.org/jira/browse/DOSGI-180
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.4.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 1.5


 I used the example at https://github.com/sneakybeaky/DOSGi-Spike but with an 
 address of /display.
 The cxf endpoint came up when starting the feature but did not go down when 
 stopping the service bundle.
 See this post for the original bug report:
 http://cxf.547215.n5.nabble.com/DOSGi-service-still-available-after-being-unregistered-td5727594.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DOSGI-184) Split Endpoint repository from TopologyManagerExport

[Amichai Rothman (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661974#comment-13661974
 ] 

Amichai Rothman commented on DOSGI-184:
---

+1 on splitting it, the topology manager and some other components could sure 
use some simplification.

The fix on trunk has a little bug though: EndpointRepository.getServices() 
leaks the inner structure to its caller(s), which then access it without proper 
synchronization. The simplest fix would be to return a copy of the set, 
although filtering via isAlreadyExportedForRsa internally and then returning 
only the non-exported services might also be nice, adding a bit more 
encapsulation.

Also, the class is public but none of its methods are (they are 
package-visible) - it would be clearer if the methods were made public as well.


 Split Endpoint repository from TopologyManagerExport
 

 Key: DOSGI-184
 URL: https://issues.apache.org/jira/browse/DOSGI-184
 Project: CXF Distributed OSGi
  Issue Type: Improvement
Affects Versions: 1.4.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 1.5


 The TopologyManager is a bit difficult to understand as it manages the known 
 services map and also has to do the communication with ServiceListener, 
 EndpointListenerNotifer and RemoteServiceAdmin. 
 Especially the synchronized blocks make the code complicated. 
 So I propose to split the handling of the map of known Endpoints into a 
 EndpointRepository.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-178) NullPointerException when interface method declares throwing custom exception

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-178:
-

 Summary: 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
 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)[165:org.apache.cxf.cxf-rt-core:2.7.2]
at 
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:101)[172:org.apache.cxf.cxf-rt-frontend-simple:2.7.2]
at 
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)[172:org.apache.cxf.cxf-rt-frontend-simple:2.7.2]
at 

[jira] [Updated] (DOSGI-173) unregistering an exported service does not remove it from zookeeper (and remote clients)

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-173:
--

Attachment: fix_zk_unregisteration.diff

Attaching the fixes I'm using (so far so good).

 unregistering an exported service does not remove it from zookeeper (and 
 remote clients)
 

 Key: DOSGI-173
 URL: https://issues.apache.org/jira/browse/DOSGI-173
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_zk_unregisteration.diff


 I have some bundles exporting and consuming services, running on two hosts. 
 I've noticed more than once that while stopping and starting different 
 bundles on the two hosts (just playing around with them manually to see how 
 robust the distributed system is), at some point one of the hosts doesn't see 
 that a service it was using from the other host is down. Connecting to 
 ZooKeeper directly, I see the node for that service is still there, i.e. the 
 service was not properly removed from ZK even though the bundle is stopped 
 and service is gone.
 Investigating this is a bit tricky, since it involves various trackers, 
 endpoint listeners and service listeners and there is not enough code 
 documentation to understand what the intended flow is... however I've found a 
 few interesting related findings that may point at the solution:
 1. Following the logs and some debugging, it appears that the problem is not 
 with the discovery.zookeeper package/bundle itself, since the endpoint 
 removed event never gets there.
 2. In EndpointListenerNotifier.notifyListenersOfRemoval(), the 
 EndpointDescription appears to be null, so there is never a filter match and 
 the endpointRemoved callback is never triggered on the EndpointListeners. 
 This is because all of the ExportRegistrations are already closed by the time 
 they get there. It seems that the premature closing is done by the service 
 tracker created in ExportRegistrationImpl.startServiceTracker(). My guess is 
 that the order in which the service tracker and service listener (in 
 TopologyManagerExport, which triggers the EndpointListenerNotifier) receive 
 the events is arbitrary depending on some race condition somewhere, which may 
 explain why this is an inconsistently reproducible bug. I would like to say 
 that the solution is to get rid of the service tracker altogether (it doesn't 
 do anything else, and as a separate bug, is never closed), but I'm not sure 
 why it was introduced in the first place or if there are any other scenarios 
 in which it was necessary, so I really don't know what the proper solution 
 should be.
 3. Another element that may have been masking this bug to some degree is the 
 local discovery bundle which was running, and during debugging I saw it 
 triggering some EndpointListener removal events which were picked up by the 
 other components. I'm not entirely sure yet of what this bundle does (I 
 didn't find any mention of it on the website, and didn't get to the code 
 yet), but I just leave this bundle in the stopped state for now, with no 
 visible effects on the testing, making debugging easier.
 4. An additional related issue which bugged me during a previous code review 
 was that InterfaceMonitorManager.addInterest() is closing and recreating an 
 InterfaceMonitor every time it is invoked with an existing scope, even though 
 the old and new IMs monitor the same ZK node and are practically identical - 
 so why not just leave the old monitor running? This replacement causes a 
 bunch of unnecessary extra work (including several ZK server accesses), a 
 flurry of unnecessary filter-matching logs, and and unnecessary gap in 
 monitoring for ZK changes. This also relates to the bug at hand since 
 InterfaceMonitor.close() also sends some EndpointListener notifications about 
 the endpoints being removed, which leaves some gaps in the registration 
 coverage (before they are re-added moments later) and might interact in some 
 other unpredictable (at least to me) way with the rest of the mechanism. It 
 seems these IM close/start cycles sometimes occur tens of times in a row.
 To sum it up, there's definitely a bug occurring. When I tested a bit with 
 fixes for both potential causes above (IM stop/start replaced with a single 
 start the first time a given scope is encountered, and close invocation in 
 service tracker removed) - I could no longer recreate the bug, but I don't 
 understand all the component interactions well enough to know if there are 
 any side effects, or why they were implemented this way in the first place (I 
 tend to assume there was a good reason for it which I'm unaware of).

--
This message is automatically generated by 

[jira] [Created] (DOSGI-174) synchronization issues and resource leaks in TopologyManagerImport and related classes

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-174:
-

 Summary: synchronization issues and resource leaks in 
TopologyManagerImport and related classes
 Key: DOSGI-174
 URL: https://issues.apache.org/jira/browse/DOSGI-174
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Amichai Rothman


The synchronization is missing and/or incorrect, and items are not properly 
cleaned up from the internal data structures when they are no longer needed, 
and sometimes added when not needed in the first place. The patch includes:

- cleaned up and simplified some code
- fixed some docs and logs
- changed EndpointListenerNotifier to skip null endpoints (reducing unnecessary 
processing and many logs)
- made method access modifiers more consistent
- fixed synchronization and concurrency issues
- fixed memory leak (items not removed from data structure, or added when 
unnecessary)
- fixed closing of resources


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-174) synchronization issues and resource leaks in TopologyManagerImport and related classes

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-174:
--

Attachment: fix_sync_and_leaks.diff

 synchronization issues and resource leaks in TopologyManagerImport and 
 related classes
 --

 Key: DOSGI-174
 URL: https://issues.apache.org/jira/browse/DOSGI-174
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_sync_and_leaks.diff


 The synchronization is missing and/or incorrect, and items are not properly 
 cleaned up from the internal data structures when they are no longer needed, 
 and sometimes added when not needed in the first place. The patch includes:
 - cleaned up and simplified some code
 - fixed some docs and logs
 - changed EndpointListenerNotifier to skip null endpoints (reducing 
 unnecessary processing and many logs)
 - made method access modifiers more consistent
 - fixed synchronization and concurrency issues
 - fixed memory leak (items not removed from data structure, or added when 
 unnecessary)
 - fixed closing of resources

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-175) TopologyManagerImport's reference counter doesn't count

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-175:
-

 Summary: TopologyManagerImport's reference counter doesn't count
 Key: DOSGI-175
 URL: https://issues.apache.org/jira/browse/DOSGI-175
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Amichai Rothman


the RefManager class used by TopologyManagerImport is supposed to manage 
reference counts for the various filters its clients are interested in, however 
the current implementation doesn't count - it just stays at zero after every 
add, and consequently is marked as released at every release. This causes 
mismanagement of the references by the TMI.

In addition, while debugging I've seen removeServiceInterest called with 
filters that have no reference count (even after the fix for the above issue), 
which would cause it to throw an exception. The fix handles this by returning 
-1 as the reference count, and the TMI simply ignores this.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-175) TopologyManagerImport's reference counter doesn't count

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-175:
--

Attachment: fix_ref_count.diff

 TopologyManagerImport's reference counter doesn't count
 ---

 Key: DOSGI-175
 URL: https://issues.apache.org/jira/browse/DOSGI-175
 Project: CXF Distributed OSGi
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_ref_count.diff


 the RefManager class used by TopologyManagerImport is supposed to manage 
 reference counts for the various filters its clients are interested in, 
 however the current implementation doesn't count - it just stays at zero 
 after every add, and consequently is marked as released at every release. 
 This causes mismanagement of the references by the TMI.
 In addition, while debugging I've seen removeServiceInterest called with 
 filters that have no reference count (even after the fix for the above 
 issue), which would cause it to throw an exception. The fix handles this by 
 returning -1 as the reference count, and the TMI simply ignores this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-176) zookeeper discovery sending multiple duplicate endpoint notifications

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-176:
-

 Summary: zookeeper discovery sending multiple duplicate endpoint 
notifications
 Key: DOSGI-176
 URL: https://issues.apache.org/jira/browse/DOSGI-176
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5
Reporter: Amichai Rothman


To my understanding of the current behavior, the InterfaceMonitorManager 
creates a ZooKeeper watcher (InterfaceMonitor) per scope. The InterfaceMonitor 
however monitors ZK nodes according to the objectClass (ignoring scope). When a 
ZK node change is detected, the IMs watching that node all trigger IMM's event 
handler. But instead of sending out the EndpointListener events corresponding 
to the scope for which each IM was created, it loops through all of the 
EndpointListener requested scopes and notifies the first matching one. This 
effectively causes multiple events to be triggered for the same scope (instead 
of one per IM scope), and possibly others to be missed.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-176) zookeeper discovery sending multiple duplicate endpoint notifications

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-176:
--

Attachment: fix_duplicate_endpoint_notifications.diff

this patch is on top of the DOSGI-172 patch for convenience (no conflict if 
they will be applied in order). I can rebase it from trunk if necessary.

 zookeeper discovery sending multiple duplicate endpoint notifications
 -

 Key: DOSGI-176
 URL: https://issues.apache.org/jira/browse/DOSGI-176
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: Discovery
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_duplicate_endpoint_notifications.diff


 To my understanding of the current behavior, the InterfaceMonitorManager 
 creates a ZooKeeper watcher (InterfaceMonitor) per scope. The 
 InterfaceMonitor however monitors ZK nodes according to the objectClass 
 (ignoring scope). When a ZK node change is detected, the IMs watching that 
 node all trigger IMM's event handler. But instead of sending out the 
 EndpointListener events corresponding to the scope for which each IM was 
 created, it loops through all of the EndpointListener requested scopes and 
 notifies the first matching one. This effectively causes multiple events to 
 be triggered for the same scope (instead of one per IM scope), and possibly 
 others to be missed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DOSGI-177) stopped services still appear as available to clients

[Amichai Rothman (JIRA)]

Amichai Rothman created DOSGI-177:
-

 Summary: stopped services still appear as available to clients
 Key: DOSGI-177
 URL: https://issues.apache.org/jira/browse/DOSGI-177
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_services_not_removed.diff

Sometimes TopologyManagerImport receives more than one endpointAdded event for 
the same endpoint and filter. Currently this causes it to add the endpoint 
multiple times to an internal list. However when the endpoint is removed, only 
one endpointRemoved event is triggered, one instance is removed from the list, 
and the other copies remain. The rest of the code treats this as the endpoint 
still being available, which is what the clients see as well (the import is 
never closed).

The patch simply adds a check so that the endpoint will not be added to the 
list if it already there. It also removes empty import lists when all imports 
are removed, preventing a leak.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-177) stopped services still appear as available to clients

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-177:
--

Attachment: fix_services_not_removed.diff

 stopped services still appear as available to clients
 -

 Key: DOSGI-177
 URL: https://issues.apache.org/jira/browse/DOSGI-177
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_services_not_removed.diff


 Sometimes TopologyManagerImport receives more than one endpointAdded event 
 for the same endpoint and filter. Currently this causes it to add the 
 endpoint multiple times to an internal list. However when the endpoint is 
 removed, only one endpointRemoved event is triggered, one instance is removed 
 from the list, and the other copies remain. The rest of the code treats this 
 as the endpoint still being available, which is what the clients see as well 
 (the import is never closed).
 The patch simply adds a check so that the endpoint will not be added to the 
 list if it already there. It also removes empty import lists when all imports 
 are removed, preventing a leak.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DOSGI-177) stopped services still appear as available to clients

[Amichai Rothman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DOSGI-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amichai Rothman updated DOSGI-177:
--

Description: 
Sometimes TopologyManagerImport receives more than one endpointAdded event for 
the same endpoint and filter. Currently this causes it to add the endpoint 
multiple times to an internal list. However when the endpoint is removed, only 
one endpointRemoved event is triggered, one instance is removed from the list, 
and the other copies remain. The rest of the code treats this as the endpoint 
still being available, which is what the clients see as well (the import is 
never closed).

The patch simply adds a check so that the endpoint will not be added to the 
list if it's already there. It also removes empty import lists when all imports 
are removed, preventing a leak.

  was:
Sometimes TopologyManagerImport receives more than one endpointAdded event for 
the same endpoint and filter. Currently this causes it to add the endpoint 
multiple times to an internal list. However when the endpoint is removed, only 
one endpointRemoved event is triggered, one instance is removed from the list, 
and the other copies remain. The rest of the code treats this as the endpoint 
still being available, which is what the clients see as well (the import is 
never closed).

The patch simply adds a check so that the endpoint will not be added to the 
list if it already there. It also removes empty import lists when all imports 
are removed, preventing a leak.


 stopped services still appear as available to clients
 -

 Key: DOSGI-177
 URL: https://issues.apache.org/jira/browse/DOSGI-177
 Project: CXF Distributed OSGi
  Issue Type: Bug
  Components: DSW
Affects Versions: 1.5
Reporter: Amichai Rothman
 Attachments: fix_services_not_removed.diff


 Sometimes TopologyManagerImport receives more than one endpointAdded event 
 for the same endpoint and filter. Currently this causes it to add the 
 endpoint multiple times to an internal list. However when the endpoint is 
 removed, only one endpointRemoved event is triggered, one instance is removed 
 from the list, and the other copies remain. The rest of the code treats this 
 as the endpoint still being available, which is what the clients see as well 
 (the import is never closed).
 The patch simply adds a check so that the endpoint will not be added to the 
 list if it's already there. It also removes empty import lists when all 
 imports are removed, preventing a leak.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira