[jira] [Commented] (CXF-6834) add support for CXF inside Spring Boot
[
https://issues.apache.org/jira/browse/CXF-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245222#comment-15245222
]
Vedran Pavic commented on CXF-6834:
---
Hi Sergey - thanks for your interest.
Generally, a 3rd party starter for Spring Boot offers the following advantages:
- provides dependency management - user only needs to add the starter as a
dependency to their project, everything else will then get pulled in
transitively with correct versions
- auto-configuration for common use cases which is triggered simply by presence
of required classes in the classpath; in CXF's case this includes registration
of {{CXFServlet}} which is mapped to {{/services/*}} and automatic import of
default config for {{SpringBus}} via
{{cxf-core-3.1.6.jar!/META-INF/cxf/cxf.xml}}
- configuration properties for customization of auto-configured
functionalities; in this case, the auto-configured {{CXFServlet}}'s path
mapping, servlet {{loadOnStartup}} and servlet init params can be customized
using (externalized) application properties (we can also evaluate if there's
something else to allow customization for)
With this approach, all that's left for used to do in a Spring Boot application
is to register their {{Endpoint}} beans. Please take a look at the sample
application in my original PR:
https://github.com/spring-projects/spring-boot/pull/5659
I hope this addresses your concerns.
> add support for CXF inside Spring Boot
> --
>
> Key: CXF-6834
> URL: https://issues.apache.org/jira/browse/CXF-6834
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: james strachan
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> right now spring boot has support for Jersey; it'd be great to integrate
> support for CXF too.
> e.g.
> *
> https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey
> *
> https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey
> *
> https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey
> *
> https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey1
> mostly this is about submitting a PR against the spring-boot project; but it
> may require a few changes in CXF to be more spring/spring-boot ready or to
> work better with Spring Boot's auto configuration mechanism and tooling:
> *
> https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html
> *
> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
> Docs on creating auto configuration here:
> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245240#comment-15245240
]
Vedran Pavic commented on CXF-6869:
---
Sergey, I'll be glad port it.
Hopefully will be able to fit that to my schedule within the next week or two.
Since this will result in a new CXF artifact(s), I need you to point me to
place where to put my code.
At first look, it looks to be a fit under integration modules.
Artifacts should be named with respect to Spring Boot's guidelines for 3rd
party starters:
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-custom-starter
Assuming the integration assumption from above was correct, the modules would
be named {{cxf-integration-spring-boot-autoconfigure}} and
{{cxf-integration-spring-boot-starter}}. Would it be possible to omit the
{{integration}} part?
Regarding sample application, I've seen your already have a space for that.
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6834) add support for CXF inside Spring Boot
[ https://issues.apache.org/jira/browse/CXF-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245371#comment-15245371 ] Sergey Beryozkin commented on CXF-6834: --- Thanks, that was the curiosity as opposed to the concerns :-). OK, so speaking of the existing CXF JAX-WS and JAX-RS Spring Boot demos, we are talking about omitting the explicit CXFServlet registration as in (1) https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jaxws_spring_boot/src/main/java/sample/ws/WebServiceConfig.java#L39 or (2) https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service/SampleRestApplication.java#L44 for (2) I can def have an extension of JaxRsConfig annotation, say JaxRsServletConfig where the default CXFServlet is added. and with the fewer dependencies, etc... The customization of the servlet URI mappings will help, in (2), to get rid of this code: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service/SampleScanRestApplication2.java#L48 which is a variation of (2) but the servlet mapping gets customized with Application's ApplicationPaths annotation... This is similar to the default CXF HTTP OSGI 'transport'. Thanks > add support for CXF inside Spring Boot > -- > > Key: CXF-6834 > URL: https://issues.apache.org/jira/browse/CXF-6834 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: james strachan >Assignee: Sergey Beryozkin > Fix For: 3.1.7, 3.2.0 > > > right now spring boot has support for Jersey; it'd be great to integrate > support for CXF too. > e.g. > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey1 > mostly this is about submitting a PR against the spring-boot project; but it > may require a few changes in CXF to be more spring/spring-boot ready or to > work better with Spring Boot's auto configuration mechanism and tooling: > * > https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html > * > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html > Docs on creating auto configuration here: > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245378#comment-15245378
]
Sergey Beryozkin commented on CXF-6869:
---
Hi, sure
how about
integration/spring-boot being a parent directory containing
/autoconfigure (cxf-spring-boot-autoconfigure)
/starter (cxf-spring-boot-starter)
?
By the way I've read in their docs it could be a single module combining the
auto-configuration and the starter features. Would it make sense to combine or
it is better to keep it separate ?
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6870) CXF doesn't check the message body's generic type
[
https://issues.apache.org/jira/browse/CXF-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245387#comment-15245387
]
Sergey Beryozkin commented on CXF-6870:
---
Thanks. By the way, I'm not sure, based on one of the tests how much checking
RI does in this case.
Such signatures can be tricky to deal with, example, where is the limit, say we
have List of Strings and List of Map of Integer to Strings, so writing the code
which can cleanly separate the providers is not easy (can be quite messy I
guess).
The workaround always exists as you demonstrated (checking Type in
isReadable/isWriteable).
But I agree this issue needs to be investigated.
> CXF doesn't check the message body's generic type
> -
>
> Key: CXF-6870
> URL: https://issues.apache.org/jira/browse/CXF-6870
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.6, 3.0.9
> Environment: mac, windows
>Reporter: Neal Hu
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: ListAProvider.java, ListBProvider.java, Resource.java,
> beans.xml
>
>
> CXF doesn't check the message body's generic type, please see the sample
> below.
> {code:java}
> public class ListAProvider implements MessageBodyWriter>
> public class ListBProvider implements MessageBodyWriter>
> resource class:
> @GET
> @Path("/echo/{param}")
> @Produces("application/json")
> public List echo(@PathParam("param")String name){
> List list = new ArrayList();
> list.add("hello");
> list.add(name);
> return list;
> }
>
> @GET
> @Path("/echo2/{param}")
> @Produces("application/json")
> public List echo2(@PathParam("param")String name){
> List list = new ArrayList();
> list.add(1);
> list.add(2);
> return list;
> }
> {code}
> No matter you request echo or echo2 resource method, the selected provider is
> ListBProvider
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6870) CXF doesn't check the message body's generic type
[
https://issues.apache.org/jira/browse/CXF-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245422#comment-15245422
]
Neal Hu commented on CXF-6870:
--
I checked RI, which has not deal with generic type of the Providers' and
message body's.
Deal with the matching logic of Provider's and message body's generic type will
be very complex.
> CXF doesn't check the message body's generic type
> -
>
> Key: CXF-6870
> URL: https://issues.apache.org/jira/browse/CXF-6870
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.3, 3.1.6, 3.0.9
> Environment: mac, windows
>Reporter: Neal Hu
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
> Attachments: ListAProvider.java, ListBProvider.java, Resource.java,
> beans.xml
>
>
> CXF doesn't check the message body's generic type, please see the sample
> below.
> {code:java}
> public class ListAProvider implements MessageBodyWriter>
> public class ListBProvider implements MessageBodyWriter>
> resource class:
> @GET
> @Path("/echo/{param}")
> @Produces("application/json")
> public List echo(@PathParam("param")String name){
> List list = new ArrayList();
> list.add("hello");
> list.add(name);
> return list;
> }
>
> @GET
> @Path("/echo2/{param}")
> @Produces("application/json")
> public List echo2(@PathParam("param")String name){
> List list = new ArrayList();
> list.add(1);
> list.add(2);
> return list;
> }
> {code}
> No matter you request echo or echo2 resource method, the selected provider is
> ListBProvider
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6834) add support for CXF inside Spring Boot
[ https://issues.apache.org/jira/browse/CXF-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246117#comment-15246117 ] Vedran Pavic commented on CXF-6834: --- I didn't have time to take a better look at existing samples yet, will try to do so over the next few days. Thanks for providing the references Sergey :) > add support for CXF inside Spring Boot > -- > > Key: CXF-6834 > URL: https://issues.apache.org/jira/browse/CXF-6834 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: james strachan >Assignee: Sergey Beryozkin > Fix For: 3.1.7, 3.2.0 > > > right now spring boot has support for Jersey; it'd be great to integrate > support for CXF too. > e.g. > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey1 > mostly this is about submitting a PR against the spring-boot project; but it > may require a few changes in CXF to be more spring/spring-boot ready or to > work better with Spring Boot's auto configuration mechanism and tooling: > * > https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html > * > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html > Docs on creating auto configuration here: > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246156#comment-15246156
]
Vedran Pavic commented on CXF-6869:
---
Thanks Sergey, the proposed layout looks good to me!
Regarding the separation question - although there are no hard constraints on
3rd party Boot integrations with regard to this concern, it is a Spring Boot
practice for starter modules to contain no code.
If having two extra modules is not an issue for you, I'd recommend to take that
route and be consistent with Boot's approach.
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6454) Orphaned JMS connections created in endless loop
[ https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246435#comment-15246435 ] ASF GitHub Bot commented on CXF-6454: - GitHub user vikash32504 opened a pull request: https://github.com/apache/cxf/pull/131 3.1.x fixes CXF-6454 - Orphaned JMS connections created in endless loop Changing the code to limit the number of retries to a pre-defined value. It can be configured as maxNoOfRetries in JMS Enpoint. Adding another property to make the sleep time configurable. We were seeing high CPU consumption because of low sleep interval time. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/cxf 3.1.x-fixes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/131.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #131 commit 0ddd071dd1e7c475d8a0463564a991d62c96e3b0 Author: Colm O hEigeartaigh Date: 2016-02-04T17:08:56Z Introducing a REST interface for the STS commit 9f457003d766950abc6a22d87d7045d3cf6aee44 Author: Sergey Beryozkin Date: 2016-02-05T13:32:33Z Cleaning up AbstractImplicitService and prototyping the code to deal with id_token response type in OidcImplicitService, not complete yet commit 89b7bb172804ebaffaa69c9207065e50eb5a5d36 Author: Sergey Beryozkin Date: 2016-02-05T14:15:58Z Converting most of AbstractJose* helpers into concrete classes to make it simpler to delegate to them without having to extend commit c3399966e4060837fd17511d604a26c8d12dad7c Author: Sergey Beryozkin Date: 2016-02-05T14:20:40Z Adding the renamed resources commit 14ed2e2c44b6da7641c95fb57212f8b5a5e77f3d Author: Sergey Beryozkin Date: 2016-02-05T14:30:05Z Updating OidcImplicitService to process IdToken commit 6a08736476f84c3bc40826d6debc6d4d96589cde Author: Sergey Beryozkin Date: 2016-02-05T14:32:25Z Fixing a typo commit dbfaf2b5aea3c4b09a825c82cae88c9d5f777aac Author: Colm O hEigeartaigh Date: 2016-02-05T12:09:56Z Renaming tests commit 9aae5c5622dec1198a333ac6bb3508d3ca4634c1 Author: Colm O hEigeartaigh Date: 2016-02-05T14:54:03Z Refactor of "BasicAuthFilter" commit 0b7e0e914328aa7a78a2eab00bb1040c703e9b63 Author: Sergey Beryozkin Date: 2016-02-05T16:53:40Z Prototyping OAuth2 redirection service which can support all the response types on a single path commit 194224faeb3e8eb6c8feabe6397f6b42ff0f605d Author: Colm O hEigeartaigh Date: 2016-02-05T16:14:08Z Fixed TLS client auth issue commit bbe5e870579720272af49b9cea65b8293d5b1f3c Author: Colm O hEigeartaigh Date: 2016-02-05T17:53:25Z Changing the default to issue tokens rather than WS-Trust responses commit 96802a240f833a1e1cf66cca376f8123b75d68cf Author: Colm O hEigeartaigh Date: 2016-02-05T17:53:39Z Update SourceProvider to be able to write out any Nodes and not just Documents commit 04300f6e34a3243418f764640f85be60eb7e05df Author: Sergey Beryozkin Date: 2016-02-08T12:05:34Z Return a correct error if a composite oAuth AS can not find the right service commit 814dafbb8d0b6124b3a7efe5ead768f731a9ff66 Author: Sergey Beryozkin Date: 2016-02-08T13:23:31Z Updating SubjectCreator to accept Client too as it may be needed to create UserSubject correctly commit e8719af028f014782a282da4c5907ea2252c5095 Author: Sergey Beryozkin Date: 2016-02-08T14:16:56Z Fixing a duplicate state property issue when OidcImplicitService handles an id_token response type commit 03a3cf4f94236f94fc35c39b5c075ff79c82e0dc Author: Sergey Beryozkin Date: 2016-02-08T16:02:12Z Adding a homeRealm property to OAuth2 Client commit b60702df6f4f8a651395999ee7cc583bb89589e3 Author: Colm O hEigeartaigh Date: 2016-02-08T11:24:06Z Adding more STS tests commit 01956cc9af68f80d4f12018a3779c12f36d5308e Author: Colm O hEigeartaigh Date: 2016-02-08T11:58:36Z Adding AppliesTo support commit bc025f0fe4acf7191430230080318346272543e1 Author: Colm O hEigeartaigh Date: 2016-02-08T12:17:57Z Adding claims test commit 9da51a99400fad5e6396949bd74a9efaf2093ade Author: Colm O hEigeartaigh Date: 2016-02-08T14:13:16Z Got the PublicKey case working with TLS client certs commit 1808d49f62dd08b701c886f529ae7b9efb4b9fbe Author: Colm O hEigeartaigh Date: 2016-02-08T14:42:35Z Got WS-Trust issuing working again commit 547f8af0519e6fd973e9cf379034fa6940eb7ceb Author: Colm O hEigeartaigh Date: 2016-02-08T16:33:51Z Adding tests for POST interface commit 448fdcf01e27006fef31de39c7672cc251e07dbc Author: Sergey Beryozkin Date: 2016-02-09T12:19:47Z Passing request params to SubjectCreator too commit d0e42861b5df45cf24985d956372f75bf04800f3 Author: Sergey Beryozkin Date: 2016-
[jira] [Commented] (CXF-6454) Orphaned JMS connections created in endless loop
[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246578#comment-15246578
]
ASF GitHub Bot commented on CXF-6454:
-
GitHub user vikash32504 opened a pull request:
https://github.com/apache/cxf/pull/132
3.1.x fixes - CXF-6454
CXF-6454 - Orphaned JMS connections created in endless loop
Changing the code to limit the number of retries to a pre-defined value. It
can be configured as maxNoOfRetries in JMS Enpoint.
Adding another property to make the sleep time configurable. We were seeing
high CPU consumption because of low sleep interval time.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vikash32504/cxf 3.1.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/132.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #132
commit 9b2e894a04fd40ab0178c9f752a760a1dca0fec4
Author: Vikash Kumar
Date: 2016-04-18T21:17:23Z
Update JMSEndpoint.java
commit c3b98d5602db868e713762279e5c460e18f582c5
Author: Vikash Kumar
Date: 2016-04-18T21:21:06Z
Update JMSDestination.java
commit 9a2e9e14e758a18b079cca75807e3dd754df6c21
Author: Vikash Kumar
Date: 2016-04-18T21:22:53Z
Update JMSConfiguration.java
commit 744c4a1d995338fd8703f5baea7002c469035411
Author: Vikash Kumar
Date: 2016-04-18T21:24:28Z
Update JMSConfigFactory.java
> Orphaned JMS connections created in endless loop
>
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
>Affects Versions: 3.0.5
>Reporter: Waldemar Szostak
>Priority: Critical
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6454) Orphaned JMS connections created in endless loop
[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246585#comment-15246585
]
Vikash Kumar commented on CXF-6454:
---
https://github.com/apache/cxf/pull/132 - submitted for review.
> Orphaned JMS connections created in endless loop
>
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
>Affects Versions: 3.0.5
>Reporter: Waldemar Szostak
>Priority: Critical
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-6454) Orphaned JMS connections created in endless loop
[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikash Kumar updated CXF-6454:
--
Comment: was deleted
(was: https://github.com/apache/cxf/pull/132 - submitted for review.)
> Orphaned JMS connections created in endless loop
>
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
>Affects Versions: 3.0.5
>Reporter: Waldemar Szostak
>Priority: Critical
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6871) Adjust default User-Agent header format to better comply with HTTP specification
Colin Hurley created CXF-6871:
-
Summary: Adjust default User-Agent header format to better comply
with HTTP specification
Key: CXF-6871
URL: https://issues.apache.org/jira/browse/CXF-6871
Project: CXF
Issue Type: Improvement
Components: Transports
Affects Versions: 3.1.6, 2.7.11
Reporter: Colin Hurley
Priority: Trivial
The default value CXF sends for the User-Agent HTTP header is formatted as E.g.
{{Apache CXF 3.1.6}}.
According to the HTTP specification, multiple products in the User-Name header
are delimited by whitespace, and a product can optionally indicate its version
by separating the product name and product version with a slash. ??RFC-1945,
Sections 10.15, 3.7; RFC-2616, Sections 14.43, 3.8??
Based on this information, CXF's default User-Agent value is indicating three
products with unspecified versions: {{Apache}}, {{CXF}}, and {{3.1.6}}, rather
than the intended Product Name = {{Apache CXF}} and Product Version = {{3.1.6}}.
I suggest altering the formatting so the default User-Agent for CXF becomes
E.g. {{Apache-CXF/3.1.6}}. This will convey the intended product information
so it semantically complies with RFC-1945 and RFC-2616.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
