[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591438#comment-15591438 ] ASF GitHub Bot commented on CXF-6986: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/182 Why is default application needed ? thanks > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591458#comment-15591458 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/182 @sberyozkin In JAXRSCdiResourceExtension#load it loops through the application instances discovered. I figured the cleanest way was to add a custom application instance. In the scenario I have, there is no application instance, as a result, no JAX-RS servers get instantiated. Now that you're pointing it out, I could also do if the app instances are empty, manually instantiate a JAX-RS server. Preferences? > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591510#comment-15591510 ] ASF GitHub Bot commented on CXF-6986: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/182 I see, IMHO this should be OK, as #load checks if it is an empty app and proceeds accordingly. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7096) Server side memory leaking if clients do not send CloseSequence
[ https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591521#comment-15591521 ] Sergey Beryozkin commented on CXF-7096: --- Unfortunately I've no experience with WS-RM at all. [~akiy] Hi Aki, can you please have a look when you get a chance ? thanks > Server side memory leaking if clients do not send CloseSequence > --- > > Key: CXF-7096 > URL: https://issues.apache.org/jira/browse/CXF-7096 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.6, 3.1.7, 3.1.8 > Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual > Studio 12 client, Java 7, JBoss EAP 6 >Reporter: Andy Zhang >Priority: Blocker > Labels: features > Fix For: 3.1.9 > > > I have a dot net client that invokes a RM web service many times. It does not > send CloseSequence at the end. The server side tries to terminate the > sequence based on inactivityTimeout in the WSDL. But it does not seem to > cleanup the sequence completely since the memory usage gets larger and larger > and eventually the server will run out of memory. java.lang.OutOfMemoryError: > Java heap space -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591583#comment-15591583 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/182 Ok, thanks. I have no idea why CI failed, and suspect its not related to my change. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15591609#comment-15591609 ] ASF GitHub Bot commented on CXF-6986: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/182 Sorry, would you still like this patch applied, did you mean to reply to https://github.com/apache/cxf/pull/181 with your last comment ? > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7082) JAX-RS OSGI tests fail on the master branch
[ https://issues.apache.org/jira/browse/CXF-7082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7082. --- Resolution: Fixed Assignee: Sergey Beryozkin > JAX-RS OSGI tests fail on the master branch > --- > > Key: CXF-7082 > URL: https://issues.apache.org/jira/browse/CXF-7082 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Affects Versions: 3.2.0 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-87) Fediz 1.1.1 Tomcat FederationAuthenticator SSO between web apps
[ https://issues.apache.org/jira/browse/FEDIZ-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Bernhardt closed FEDIZ-87. -- Resolution: Not A Problem > Fediz 1.1.1 Tomcat FederationAuthenticator SSO between web apps > --- > > Key: FEDIZ-87 > URL: https://issues.apache.org/jira/browse/FEDIZ-87 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Lou Aloia >Priority: Minor > > Enable SSO between multiple web apps deployed on Tomcat so that users already > authenticated in one web app are not redirected to the IdP when they access > another web app from the same browser. Seems like integrating the > functionality in the Tomcat SingleSignOn valve would be a possible solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592410#comment-15592410 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/182 @sberyozkin nope, this one. That's romain's change in #181. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7094) MQJCA1018: Only one session per connection is allowed
[ https://issues.apache.org/jira/browse/CXF-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rainer Müller closed CXF-7094. -- Resolution: Fixed Fix Version/s: Invalid see CXF-7023 > MQJCA1018: Only one session per connection is allowed > - > > Key: CXF-7094 > URL: https://issues.apache.org/jira/browse/CXF-7094 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.6 >Reporter: Rainer Müller > Fix For: Invalid > > > We upgraded from CXF 2.7.14 to 3.16 running in EAP 7.0 container. > The WebSphere MQ resource adapter 7.5.0 shows following error message > - MQJCA1018: Only one session per connection is allowed > In class JMSConduit#setupReplyDestination the existing connection is used to > instantiate class MessageListenerContainer. > MessageListenerContainer#start calls createSession on given connection. > Is there a way to force the 'one session per connection' restriction of our > resource adapter? In version 2.7.14 we never had this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627 ] Rainer Müller commented on CXF-7023: Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592627#comment-15592627 ] Rainer Müller edited comment on CXF-7023 at 10/20/16 6:42 PM: -- Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA and Apache CXF version 3.1.6. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. was (Author: rainer.mueller): Patch fixed our issue with WebSphere MQ Resource Adapter running in JBoss EAP 7.0.2.GA. Any plans when the fix will be release with Apache CXF? Closed the duplicate issue CXF-7094. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592683#comment-15592683 ] ASF GitHub Bot commented on CXF-6986: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/182 Well I found your comment about CI confusing, not sure what it was to do with our discussion given that this PR was not applied to the CXF source > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592735#comment-15592735 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/182 You have a PR builder, which is failing for me for some reason. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592747#comment-15592747 ] ASF GitHub Bot commented on CXF-6986: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/182 Yeah, sorry for being so ignorant :-), realized after I made this comment. +1 from my side to this patch, thanks > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7100) CXF and Server Name Identification support
Michal Sabo created CXF-7100: Summary: CXF and Server Name Identification support Key: CXF-7100 URL: https://issues.apache.org/jira/browse/CXF-7100 Project: CXF Issue Type: Bug Components: Core Affects Versions: 3.0.9 Environment: JRE 1.8.0_101-b13 Reporter: Michal Sabo CXF should support Server Name Identification (SNI) since it utilizes custom hostname verification. It is mainly a Java problem, however a fix can be made also on the CXF's site. More info can be found here: http://javabreaks.blogspot.sk/2015/12/java-ssl-handshake-with-server-name.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593309#comment-15593309 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on a diff in the pull request: https://github.com/apache/cxf/pull/182#discussion_r84393963 --- Diff: integration/cdi/src/main/java/org/apache/cxf/cdi/CdiUtil.java --- @@ -0,0 +1,42 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.cxf.cdi; --- End diff -- The problem is that its duplicated. CDI 2.0 is introducing a better bean definition tool, would prefer to wait until that's available to leverage. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593414#comment-15593414 ] ASF GitHub Bot commented on CXF-6986: - Github user reta commented on a diff in the pull request: https://github.com/apache/cxf/pull/182#discussion_r84398911 --- Diff: integration/cdi/src/main/java/org/apache/cxf/cdi/CdiUtil.java --- @@ -0,0 +1,42 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.cxf.cdi; --- End diff -- Oh I see, good to know, may be just rename the method to `getDefaultQualifiers`? Because `getQualifiers` doesn't really such much, Thanks @johnament ! > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7096) Server side memory leaking if clients do not send CloseSequence
[ https://issues.apache.org/jira/browse/CXF-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593428#comment-15593428 ] Andy Zhang commented on CXF-7096: - [~sergeyb][~akiy] Thank both of you very much. > Server side memory leaking if clients do not send CloseSequence > --- > > Key: CXF-7096 > URL: https://issues.apache.org/jira/browse/CXF-7096 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.6, 3.1.7, 3.1.8 > Environment: Windows 7, CXF3.1.6, CXF3.1.7 and CXF3.1.8, Visual > Studio 12 client, Java 7, JBoss EAP 6 >Reporter: Andy Zhang >Priority: Blocker > Labels: features > Fix For: 3.1.9 > > > I have a dot net client that invokes a RM web service many times. It does not > send CloseSequence at the end. The server side tries to terminate the > sequence based on inactivityTimeout in the WSDL. But it does not seem to > cleanup the sequence completely since the memory usage gets larger and larger > and eventually the server will run out of memory. java.lang.OutOfMemoryError: > Java heap space -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6986) Don't require an application class if using CDI
[ https://issues.apache.org/jira/browse/CXF-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593702#comment-15593702 ] ASF GitHub Bot commented on CXF-6986: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/182 OK, IMHO this is a bit cleaner. Use a base class for the common stuff. > Don't require an application class if using CDI > --- > > Key: CXF-6986 > URL: https://issues.apache.org/jira/browse/CXF-6986 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > The current CXF-CDI integration assumes there will be an application class. > It would be great if CXF did not require an application class, to simplify > developer workload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594239#comment-15594239 ] Nikolay Boklaschuk commented on CXF-7023: - Glad to see that my patch come useful for you. There is no any response from cxf team, so I am waiting. One more thing: the whole jms transport implementation not good because based on pooling. There is outdated implementation by Benoit from OW2 JOnAS project based on mdb. But I did not tried it, because our project has been stopped. I think it could be merged in mainline with some improvements alongside with current transport. > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
