[jira] Commented: (CXF-2970) Service cannot create a Socket
[
https://issues.apache.org/jira/browse/CXF-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907129#action_12907129
]
Willem Jiang commented on CXF-2970:
---
Hi Paulo,
Please feel free to add comments on that page or tell me what need to change in
case you don't have the right the change the page.
Willem
> Service cannot create a Socket
> --
>
> Key: CXF-2970
> URL: https://issues.apache.org/jira/browse/CXF-2970
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP, Java jdk1.6.0_20, Maven 2.2.1, Eclipse
> 3.6.0, activemq-core 5.4.0
>Reporter: Paulo Rodrigez
>Assignee: Willem Jiang
>Priority: Minor
>
> Hey
> I've got a problem to create a service SOAP over JMS. I have created a WSDL
> and use you codegen plugin to generate the server-skel. Now I try to start
> this service with the following lines:
> {code}
> public class ProjectServer {
> private ProjectServer() throws NamingException {
> // You just need to set the address with JMS URI
> String address =
> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue"
> + "?jndiInitialContextFactory"
> +
> "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
> +
> "&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61610";
> Project implementor = new ProjectImpl();
> JaxWsServerFactoryBean svrFactory = new
> JaxWsServerFactoryBean();
> svrFactory.setServiceClass(Project.class);
> svrFactory.setAddress(address);
> // And specify the transport ID with SOAP over JMS specification
>
> svrFactory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
> svrFactory.setServiceBean(implementor);
> svrFactory.create();
> }
> /**
>* @param args
>* @throws NamingException
>*/
> public static void main(String[] args) throws NamingException {
> new ProjectServer();
> }
> }
> {code}
> Here is my WSDL:
> {code}
>
> http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:tns="http://www.mycompany.com/project/service";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/";
> xmlns:model="http://www.mycompany.com/project/model";
> name="project"
> targetNamespace="http://www.mycompany.com/project/service";>
>
>targetNamespace="http://www.mycompany.com/project/model";>
>
>
>
>type="xsd:string" />
>
>
>
>
>
>
>type="xsd:string" />
>
>
>
>type="xsd:string">
>type="xsd:string">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://www.w3.org/2008/07/soap/bindings/JMS/"; />
>
> ConnectionFactory
>
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory
>
> tcp://localhost:61616
> PERSISTENT
> 5
> 1000
>
>soapAction="http://www.mycompany.com/project/service/GreetMeOp"; />
>
>
>
>
>
>
>
>
>
>
>location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
>
>
>
> {code}
> Error is:
> INFO: Setting the server's publish address to be
> jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61610
> Exception in thread "main" org.springframework.jms.UncategorizedJmsException:
> Uncategorized exception occured during JMS processing; nested exception is
> javax.jms.JMSException: Could not connect to broker URL:
> tcp:/
[jira] Commented: (CXF-2970) Service cannot create a Socket
[
https://issues.apache.org/jira/browse/CXF-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907159#action_12907159
]
Paulo Rodrigez commented on CXF-2970:
-
Hi Willem
I can't edit the page. This information I needed for my example:
- Create a message JMS broker.
- In the example "WSDL Usage" there is something missing in the :
{code}
ConnectionFactory
org.apache.activemq.jndi.ActiveMQInitialContextFactory
{code}
Thanks for your help.
Paulo
> Service cannot create a Socket
> --
>
> Key: CXF-2970
> URL: https://issues.apache.org/jira/browse/CXF-2970
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP, Java jdk1.6.0_20, Maven 2.2.1, Eclipse
> 3.6.0, activemq-core 5.4.0
>Reporter: Paulo Rodrigez
>Assignee: Willem Jiang
>Priority: Minor
>
> Hey
> I've got a problem to create a service SOAP over JMS. I have created a WSDL
> and use you codegen plugin to generate the server-skel. Now I try to start
> this service with the following lines:
> {code}
> public class ProjectServer {
> private ProjectServer() throws NamingException {
> // You just need to set the address with JMS URI
> String address =
> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue"
> + "?jndiInitialContextFactory"
> +
> "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
> +
> "&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61610";
> Project implementor = new ProjectImpl();
> JaxWsServerFactoryBean svrFactory = new
> JaxWsServerFactoryBean();
> svrFactory.setServiceClass(Project.class);
> svrFactory.setAddress(address);
> // And specify the transport ID with SOAP over JMS specification
>
> svrFactory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
> svrFactory.setServiceBean(implementor);
> svrFactory.create();
> }
> /**
>* @param args
>* @throws NamingException
>*/
> public static void main(String[] args) throws NamingException {
> new ProjectServer();
> }
> }
> {code}
> Here is my WSDL:
> {code}
>
> http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:tns="http://www.mycompany.com/project/service";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/";
> xmlns:model="http://www.mycompany.com/project/model";
> name="project"
> targetNamespace="http://www.mycompany.com/project/service";>
>
>targetNamespace="http://www.mycompany.com/project/model";>
>
>
>
>type="xsd:string" />
>
>
>
>
>
>
>type="xsd:string" />
>
>
>
>type="xsd:string">
>type="xsd:string">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://www.w3.org/2008/07/soap/bindings/JMS/"; />
>
> ConnectionFactory
>
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory
>
> tcp://localhost:61616
> PERSISTENT
> 5
> 1000
>
>soapAction="http://www.mycompany.com/project/service/GreetMeOp"; />
>
>
>
>
>
>
>
>
>
>
>location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
>
>
>
> {code}
> Error is:
> INFO: Setting the server's publish address to be
> jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialCon
[jira] Updated: (CXF-2976) Allow to configure SSL session cache size and TTL on the client
[ https://issues.apache.org/jira/browse/CXF-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Mucha updated CXF-2976: Attachment: sslSessionTimeout.patch Attached sample patch file > Allow to configure SSL session cache size and TTL on the client > --- > > Key: CXF-2976 > URL: https://issues.apache.org/jira/browse/CXF-2976 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.2.6, 2.2.7 > Environment: Windows/Linux, jdk1.6 >Reporter: Grzegorz Mucha > Attachments: sslSessionTimeout.patch > > > JDK SSL connectivity maintains a cache of SSLSessions that it reuses for > subsequent connection. Unfortunately the default TTL in this cache is set to > 24h. We have ran into an issue with a specific environment setup on the > server side - with a F5 loadbalancer doing SSL offloading, the SSL sessions > were valid on the load balancer but were broken beyond that point. The > problem turned out the TTL of that cache being too long - in our case tuning > it down to 60 seconds resolved the issue. FWIW we have actually encountered > this issue with multiple vendors. > The timeout can be configured via > SSLSession.getClientSessionContext().setSessionTimeout(int) - the suggestion > is to add this parameter to be configured via TLSClientParams. Unfortunately > the only way that the SSLSession is now accessed/configured is inside > HttpsURLConnectionFactory - and this class is right now tightly coupled to a > HttpConduit. There isn't actually a way to set the default TTL - or set it > globally in the JVM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2981) Outbound MapAggregator loses reference parameters of generic ReplyTo EPRs
Outbound MapAggregator loses reference parameters of generic ReplyTo EPRs -- Key: CXF-2981 URL: https://issues.apache.org/jira/browse/CXF-2981 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.2.10 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.3, 2.2.11 If non-null ReplyTo EPR has either None or Anonymous address then MAPAggregator will replace it with a new ReplyTo EPR having an Anonymous address if no alternative ReplyTo can be found from the decoupled Destination. The net effect is that the reference parameters if any are lost during the replacement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2982) Don't throw the SuspendedInvocationException when call the suspend() method of CXF continuation
Don't throw the SuspendedInvocationException when call the suspend() method of CXF continuation --- Key: CXF-2982 URL: https://issues.apache.org/jira/browse/CXF-2982 Project: CXF Issue Type: Improvement Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.3 Current CXF Continuation suspend implementation is based on throw SuspendedInvocationException, This implementation has a shortcoming which cannot call the other framework's async API after continuation suspend is called as Jetty7 does. So I introduce a flag of Message.CONTINUATION_SUSPENDED to break out current interceptor chain as the SuspendedInvocation does, but It will make CXF continuation API more easy to use and it supports the Jetty7 continuation or Servlet3 suspend resume semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2982) Don't throw the SuspendedInvocationException when call the suspend() method of CXF continuation
[ https://issues.apache.org/jira/browse/CXF-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CXF-2982: -- Attachment: cxf-2982.patch Attache the patch with new implementation. > Don't throw the SuspendedInvocationException when call the suspend() method > of CXF continuation > --- > > Key: CXF-2982 > URL: https://issues.apache.org/jira/browse/CXF-2982 > Project: CXF > Issue Type: Improvement >Reporter: Willem Jiang >Assignee: Willem Jiang > Fix For: 2.3 > > Attachments: cxf-2982.patch > > > Current CXF Continuation suspend implementation is based on throw > SuspendedInvocationException, This implementation has a shortcoming which > cannot call the other framework's async API after continuation suspend is > called as Jetty7 does. > So I introduce a flag of Message.CONTINUATION_SUSPENDED to break out current > interceptor chain as the SuspendedInvocation does, but It will make CXF > continuation API more easy to use and it supports the Jetty7 continuation or > Servlet3 suspend resume semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2982) Don't throw the SuspendedInvocationException when call the suspend() method of CXF continuation
[
https://issues.apache.org/jira/browse/CXF-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907215#action_12907215
]
Willem Jiang commented on CXF-2982:
---
Before apply the patch, my camel-cxf consumer is like this
{code}
private Object asyncInvoke(Exchange cxfExchange, final Continuation
continuation) {
if (continuation.isNew()) {
final org.apache.camel.Exchange camelExchange =
perpareCamelExchange(cxfExchange);
// use the asynchronous API to process the exchange
boolean sync = getAsyncProcessor().process(camelExchange,
new AsyncCallback() {
public void done(boolean doneSync) {
if (LOG.isTraceEnabled()) {
LOG.trace("Resuming continuation of exchangeId:
"
+ camelExchange.getExchangeId());
}
// resume processing after both, sync and async
callbacks
continuation.setObject(camelExchange);
continuation.resume();
}
});
// just need to avoid the continuation.resume is called
// before the continuation.suspend is called
if (continuation.getObject() != camelExchange && !sync) {
// Now we don't set up the timeout value
if (LOG.isTraceEnabled()) {
LOG.trace("Suspending continuation of exchangeId: "
+ camelExchange.getExchangeId());
}
// The continuation could be called before the suspend
// is called
continuation.suspend(0);
} else {
// just set the response back, as the invoking thread is
// not changed
if (LOG.isTraceEnabled()) {
LOG.trace("Processed the Exchange : " +
camelExchange.getExchangeId());
}
setResponseBack(cxfExchange, camelExchange);
}
}
if (continuation.isResumed()) {
org.apache.camel.Exchange camelExchange =
(org.apache.camel.Exchange)continuation
.getObject();
setResponseBack(cxfExchange, camelExchange);
}
return null;
}
{code}
After applying the patch , my camel-cxf consumer code is much clearer
{code}
private Object asyncInvoke(Exchange cxfExchange, final Continuation
continuation) {
if (continuation.isNew()) {
final org.apache.camel.Exchange camelExchange =
perpareCamelExchange(cxfExchange);
// Now we don't set up the timeout value
if (LOG.isTraceEnabled()) {
LOG.trace("Suspending continuation of exchangeId: "
+ camelExchange.getExchangeId());
}
// now we could call the suspend here
continuation.suspend(0);
// use the asynchronous API to process the exchange
getAsyncProcessor().process(camelExchange, new
AsyncCallback() {
public void done(boolean doneSync) {
if (LOG.isTraceEnabled()) {
LOG.trace("Resuming continuation of exchangeId:
"
+ camelExchange.getExchangeId());
}
// resume processing after both, sync and async
callbacks
continuation.setObject(camelExchange);
continuation.resume();
}
});
}
if (continuation.isResumed()) {
org.apache.camel.Exchange camelExchange =
(org.apache.camel.Exchange)continuation
.getObject();
setResponseBack(cxfExchange, camelExchange);
}
return null;
}
{code}
> Don't throw the SuspendedInvocationException when call the suspend() method
> of CXF continuation
> ---
>
> Key: CXF-2982
> URL: https://issues.apache.org/jira/browse/CXF-2982
> Project: CXF
> Issue Type: Improvement
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.3
>
> Attachments
[jira] Commented: (CXF-2164) CXFBusImpl never removed from ThreadLocal, generates permgen out of memory error after some redeployments
[ https://issues.apache.org/jira/browse/CXF-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907265#action_12907265 ] Mauro Molinari commented on CXF-2164: - I don't know if it's better to reopen this bug or to file a new one. I still have problems with ThreadLocals not being released. The problem is that cxf.xml declares the following bean: Here, the destroy-method is not declared. This means that when Sping shuts down the context, it does not call any shutdown method on the CXFBusImpl. This has nothing to do with the init and destroy methods of the CXFServlet, which might occur in different threads. Moreover, I see the problem even if I don't start the CXFServlet at all (no load-on-startup). The net result is the following: - Tomcat starts - Tomcat starts my web application - this declares a Spring web application context that gets parsed - at some point cxf.xml is parsed, so the bean named cxf is created and an org.apache.cxf.bus.CXFBusImpl instance is created using the constructor org.apache.cxf.bus.CXFBusImpl.CXFBusImpl(Map), which causes the org.apache.cxf.BusFactory.localBus ThreadLocal to be assigned a value of this type, through a call to org.apache.cxf.BusFactory.possiblySetDefaultBus(Bus); I see that this happens in a thread called "main" - if I stop the web application, Spring closes down the context; however, as I said before, this does not cause any shutdown method of the cxf bean to be called - so there's no null-setting or removing operation of the org.apache.cxf.BusFactory.localBus ThreadLocal for the thread "main" I think the easiest fix is to modify the cxf bean definition in this way: However, org.apache.cxf.bus.CXFBusImpl.shutdown(boolean) should be refactored so that it does not take the boolean parameter (it's not used actually), otherwise an overloading of this method without parameters should be provided. However, this will work with the assumption that the Spring context load and shutdown operations are both executed in the same thread. I don't know if this is guaranteed by the servlet specifications or not (I'm using the org.springframework.web.context.ContextLoaderListener servlet listener to handle the lifecycle of the webapp application context). A better fix could be to avoid to hold state information for the CXFBusImpl in this way (i.e.: why does a constructor set a ThreadLocal and leave it there???). Please note I'm working with CXF 2.2.10. > CXFBusImpl never removed from ThreadLocal, generates permgen out of memory > error after some redeployments > - > > Key: CXF-2164 > URL: https://issues.apache.org/jira/browse/CXF-2164 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.1.4 >Reporter: Francois Masurel >Assignee: Bharath Ganesh > Fix For: 2.2.2 > > Attachments: cxf_threadlocal.jpg, > Heap_Walker_Incoming_References.zip, threadlocal.patch > > > I've found this message on a mailing list recently, and it doesn't seem to > have been resolved as we have the same problem with version 2.1.4 of CXF on > one of our webapp : > Hello CXF users, > I've been working on figuring out why our JBoss servers keep going down with > permgen out > of memory exceptions when we redeploy our war files. To do this I had been > using a profiler > to inspect the WebAppClassloader to find out what was keeping it from being > garbage collected. > One such culprit was the class org.apache.cxf.BusFactory > The BusFactory has a ThreadLocal in which it stores a copy of CXFBusImpl. > However, this isn't > getting cleaned up properly when the war is undeployed. I noticed that > CXFBusImpl has a shutdown > method that calls BusFactory.setDefaultBus(null) which in turn sets the value > stored in the > ThreadLocal to null. However, this doesn't seem to be getting called. > The way we are using CXF from spring is with the following > WEB-INF/services.xml file in our > war: > http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:amq="http://activemq.org/config/1.0"; > xmlns:jaxws="http://cxf.apache.org/jaxws"; > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd > http://activemq.org/config/1.0 > http://activemq.apache.org/schema/core/activemq-core-5.0.0.xsd"; > default-autowire="byType"> > > > >
[jira] Commented: (CXF-2164) CXFBusImpl never removed from ThreadLocal, generates permgen out of memory error after some redeployments
[
https://issues.apache.org/jira/browse/CXF-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907283#action_12907283
]
Mauro Molinari commented on CXF-2164:
-
I must correct myself. As the original reporter said, the call to shutdown does
not resolve the problem, because I just saw that it does not unset the
ThreadLocal, but simply sets to null an internal property (defaultBus).
The bad news is that I just realized that the shutdown sequence can actually be
made on a different thread: that is, the context may be created in thread
"main", but destroyed in thread htttp-8080-1 (the one that serves my request to
stop the web application in the Tomcat Manager application).
So, I don't see any straight way to fix this problem without thinking about the
reason of that ThreadLocal. Maybe the method
org.apache.cxf.BusFactory.setDefaultBus(Bus) should at least let the user
specify whether the TheadLocal localBus property should also be set together
with the defaultBus property. After that, maybe the constructor of CXFBusImpl
should set only the default bus property, not the localBus one.
Mauro.
> CXFBusImpl never removed from ThreadLocal, generates permgen out of memory
> error after some redeployments
> -
>
> Key: CXF-2164
> URL: https://issues.apache.org/jira/browse/CXF-2164
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.1.4
>Reporter: Francois Masurel
>Assignee: Bharath Ganesh
> Fix For: 2.2.2
>
> Attachments: cxf_threadlocal.jpg,
> Heap_Walker_Incoming_References.zip, threadlocal.patch
>
>
> I've found this message on a mailing list recently, and it doesn't seem to
> have been resolved as we have the same problem with version 2.1.4 of CXF on
> one of our webapp :
> Hello CXF users,
> I've been working on figuring out why our JBoss servers keep going down with
> permgen out
> of memory exceptions when we redeploy our war files. To do this I had been
> using a profiler
> to inspect the WebAppClassloader to find out what was keeping it from being
> garbage collected.
> One such culprit was the class org.apache.cxf.BusFactory
> The BusFactory has a ThreadLocal in which it stores a copy of CXFBusImpl.
> However, this isn't
> getting cleaned up properly when the war is undeployed. I noticed that
> CXFBusImpl has a shutdown
> method that calls BusFactory.setDefaultBus(null) which in turn sets the value
> stored in the
> ThreadLocal to null. However, this doesn't seem to be getting called.
> The way we are using CXF from spring is with the following
> WEB-INF/services.xml file in our
> war:
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:amq="http://activemq.org/config/1.0";
> xmlns:jaxws="http://cxf.apache.org/jaxws";
> xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> http://activemq.org/config/1.0
> http://activemq.apache.org/schema/core/activemq-core-5.0.0.xsd";
> default-autowire="byType">
>
>
>
> address="/HelloService" />
>
> I'm not really sure why this Bus.shutdown() isn't getting called or even who
> is responsible
> for calling it. I tried doing something along the lines of:
> WebApplicationContext webContext =
> WebApplicationContextUtils.getRequiredWebApplicationContext(context);
> if (webContext.containsBean("cxf")) {
> CXFBusImpl cxfBus = (CXFBusImpl) webContext.getBean("cxf");
> cxfBus.shutdown(true);
> }
> But that didn't work. What I eventually ended up doing was to have the
> following hack in the
> shutdown sequence of our webapp:
> Field field = org.apache.cxf.BussFactory.class.getDeclaredField("localBus");
> field.setAccessible(true);
> ThreadLocal localBus = (ThreadLocal) field.get(null);
> localBus.remove();
> This did work but obviously it is a bit of an ugly hack. Is there something
> that needs to
> be included in our service.xml file to tell spring how to cleanup CXF? Is
> this maybe a bug
> in CXF that the CXFBusImpl.shutdown(Boolean) just isn't getting called at all
> or maybe that
> in BusFactory.setThreadDefaultBus(Bus) that there should be some check such
> as:
> if (bus == null) {
> localBus.remove();
> } else {
> localBus.set(bus);
> }
> Or maybe some combination of all of these. I'm reasonably new to CXF, Spring,
> and all t
[jira] Issue Comment Edited: (CXF-2164) CXFBusImpl never removed from ThreadLocal, generates permgen out of memory error after some redeployments
[ https://issues.apache.org/jira/browse/CXF-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907283#action_12907283 ] Mauro Molinari edited comment on CXF-2164 at 9/8/10 12:23 PM: -- I must correct myself. As the original reporter said, the call to shutdown does not resolve the problem, because I just saw that it does not unset the ThreadLocal, but simply sets to null an internal property (defaultBus). The bad news is that I just realized that the shutdown sequence can actually be made on a different thread: that is, the context may be created in thread "main", but destroyed in thread htttp-8080-1 (the one that serves my request to stop the web application in the Tomcat Manager application). So, I don't see any straight way to fix this problem without thinking about the reason of that ThreadLocal. Maybe the method org.apache.cxf.BusFactory.setDefaultBus(Bus) should at least let the user specify whether the TheadLocal localBus property should also be set together with the defaultBus property. After that, maybe the constructor of CXFBusImpl should set only the default bus property, not the localBus one. Or at least this should happen just for the CXFBusImpl instance created by cxf.xml Spring application context Mauro. was (Author: mauromol): I must correct myself. As the original reporter said, the call to shutdown does not resolve the problem, because I just saw that it does not unset the ThreadLocal, but simply sets to null an internal property (defaultBus). The bad news is that I just realized that the shutdown sequence can actually be made on a different thread: that is, the context may be created in thread "main", but destroyed in thread htttp-8080-1 (the one that serves my request to stop the web application in the Tomcat Manager application). So, I don't see any straight way to fix this problem without thinking about the reason of that ThreadLocal. Maybe the method org.apache.cxf.BusFactory.setDefaultBus(Bus) should at least let the user specify whether the TheadLocal localBus property should also be set together with the defaultBus property. After that, maybe the constructor of CXFBusImpl should set only the default bus property, not the localBus one. Mauro. > CXFBusImpl never removed from ThreadLocal, generates permgen out of memory > error after some redeployments > - > > Key: CXF-2164 > URL: https://issues.apache.org/jira/browse/CXF-2164 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.1.4 >Reporter: Francois Masurel >Assignee: Bharath Ganesh > Fix For: 2.2.2 > > Attachments: cxf_threadlocal.jpg, > Heap_Walker_Incoming_References.zip, threadlocal.patch > > > I've found this message on a mailing list recently, and it doesn't seem to > have been resolved as we have the same problem with version 2.1.4 of CXF on > one of our webapp : > Hello CXF users, > I've been working on figuring out why our JBoss servers keep going down with > permgen out > of memory exceptions when we redeploy our war files. To do this I had been > using a profiler > to inspect the WebAppClassloader to find out what was keeping it from being > garbage collected. > One such culprit was the class org.apache.cxf.BusFactory > The BusFactory has a ThreadLocal in which it stores a copy of CXFBusImpl. > However, this isn't > getting cleaned up properly when the war is undeployed. I noticed that > CXFBusImpl has a shutdown > method that calls BusFactory.setDefaultBus(null) which in turn sets the value > stored in the > ThreadLocal to null. However, this doesn't seem to be getting called. > The way we are using CXF from spring is with the following > WEB-INF/services.xml file in our > war: > http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:amq="http://activemq.org/config/1.0"; > xmlns:jaxws="http://cxf.apache.org/jaxws"; > xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.5.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd > http://activemq.org/config/1.0 > http://activemq.apache.org/schema/core/activemq-core-5.0.0.xsd"; > default-autowire="byType"> > > > > address="/HelloService" /> > > I'm not really sure why this Bus.shutdown() isn't getting called or even who > is responsible > for calling it. I tried doing something
[jira] Commented: (CXF-2978) CLONE -Return Type List gets null on client if an empty list is returned
[
https://issues.apache.org/jira/browse/CXF-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907298#action_12907298
]
Staffan Forsell commented on CXF-2978:
--
So if this is per spec, is there no simple/clean way to enforce that empty
Lists/Collection/Arrays are returned, if supplied?
Do you have to provide a ResponseWrapper to control this?
Changing the return type to an array doesn't seem to matter either.
> CLONE -Return Type List gets null on client if an empty list is returned
>
>
> Key: CXF-2978
> URL: https://issues.apache.org/jira/browse/CXF-2978
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.1.8, 2.2.7, 2.2.9, 2.2.10
> Environment: JSE 1.5 on Win XP
>Reporter: Staffan Forsell
>Assignee: Daniel Kulp
>Priority: Critical
> Attachments: EmptyListExample-2.2.10.tar.gz
>
>
> If you have a function that returns an empty list the result will be null on
> client. Even If add a Responsewrapper to the interface it doesn't work. If
> have attached a little test project / program:
> Interface:
> @WebService(targetNamespace =
> "http://cxf.apache.org/demo/CustomerService/1/";, name = "CustomerService")
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
> SOAPBinding.Use.LITERAL)
> public interface CustomerService {
> @WebMethod(action = "findCustomer", operationName = "findCustomer")
> public @WebResult(name = "customerList")
> List findCustomer();
>
>
> @WebMethod(action = "findCustomer2", operationName = "findCustomer2")
> @ResponseWrapper(className="demo.service.CustomerListResponse")
> public @WebResult(name = "customerList")
> List findCustomer2();
> }
> The Implementation:
> @WebService(name = "CustomerService", serviceName = "CustomerService",
> targetNamespace = "http://cxf.apache.org/demo/CustomerService/1/";,
> endpointInterface = "demo.service.CustomerService")
> public class CustomerServiceImpl implements CustomerService {
> public List findCustomer() {
> // very stupid method
> return new ArrayList();
> }
> public List findCustomer2() {
> // another very stupid method
> return new ArrayList();
> }
> }
> And this is the main programm:
> public static void main(String args[]) throws Exception {
> new Server();
> System.out.println("Server ready...");
> // Now Call the Service
> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.setServiceClass(CustomerService.class);
> factory.setAddress("http://localhost:9000/CustomerService";);
> CustomerService client = (CustomerService) factory.create();
> System.out.println("call findCustomer()");
> List result = client.findCustomer();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("call findCustomer2()");
> result = client.findCustomer2();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("Server exiting");
> System.exit(0);
> }
> This will print the following output:
> Server ready...
> call findCustomer()
> 20.01.2010 07:49:45
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 1
> Address: http://localhost:9000/CustomerService
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=["findCustomer"], Accept=[*/*]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> xmlns:ns2="http://cxf.apache.org/demo/CustomerService/1/"/>
> --
> 20.01.2010 07:49:45 org.apache.cxf.interceptor.LoggingInInterceptor logging
> INFO: Inbound Message
>
> ID: 1
> Encoding: UTF-8
> Content-Type: text/xml; charset=utf-8
> Headers: {Content-Length=[194], Server=[Jetty(6.1.21)],
> content-type=[text/xml; charset=utf-8]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> xmlns:ns2="http://cxf.apache.org/demo/CustomerService/1/"/>
> --
> List is null: null
> call findCustomer2()
> 20.
[jira] Commented: (CXF-2978) CLONE -Return Type List gets null on client if an empty list is returned
[
https://issues.apache.org/jira/browse/CXF-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907325#action_12907325
]
Daniel Kulp commented on CXF-2978:
--
Well, for RETURN values (not parameters), you can add an
@XmlElementWrapper(nillable = true, name = "return") directly to the
List findCustomer(); method of the CustomerService class and that
will work with CXF 2.2.10. Doing so is going outside the JAXWS spec though as
the spec doesn't provide for the XmlElementWrapper annotation to be added to
the WebMethods. It also ONLY works for return values as XmElementWrapper is
not allowed on method params. Just method and field locations.
But for the most part, according to spec, in this case, null is the correct
return. One the wire, there would not be any difference if you return an
empty list or null so, according to spec, it's mapped to null by default.
> CLONE -Return Type List gets null on client if an empty list is returned
>
>
> Key: CXF-2978
> URL: https://issues.apache.org/jira/browse/CXF-2978
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.1.8, 2.2.7, 2.2.9, 2.2.10
> Environment: JSE 1.5 on Win XP
>Reporter: Staffan Forsell
>Assignee: Daniel Kulp
>Priority: Critical
> Attachments: EmptyListExample-2.2.10.tar.gz
>
>
> If you have a function that returns an empty list the result will be null on
> client. Even If add a Responsewrapper to the interface it doesn't work. If
> have attached a little test project / program:
> Interface:
> @WebService(targetNamespace =
> "http://cxf.apache.org/demo/CustomerService/1/";, name = "CustomerService")
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
> SOAPBinding.Use.LITERAL)
> public interface CustomerService {
> @WebMethod(action = "findCustomer", operationName = "findCustomer")
> public @WebResult(name = "customerList")
> List findCustomer();
>
>
> @WebMethod(action = "findCustomer2", operationName = "findCustomer2")
> @ResponseWrapper(className="demo.service.CustomerListResponse")
> public @WebResult(name = "customerList")
> List findCustomer2();
> }
> The Implementation:
> @WebService(name = "CustomerService", serviceName = "CustomerService",
> targetNamespace = "http://cxf.apache.org/demo/CustomerService/1/";,
> endpointInterface = "demo.service.CustomerService")
> public class CustomerServiceImpl implements CustomerService {
> public List findCustomer() {
> // very stupid method
> return new ArrayList();
> }
> public List findCustomer2() {
> // another very stupid method
> return new ArrayList();
> }
> }
> And this is the main programm:
> public static void main(String args[]) throws Exception {
> new Server();
> System.out.println("Server ready...");
> // Now Call the Service
> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.setServiceClass(CustomerService.class);
> factory.setAddress("http://localhost:9000/CustomerService";);
> CustomerService client = (CustomerService) factory.create();
> System.out.println("call findCustomer()");
> List result = client.findCustomer();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("call findCustomer2()");
> result = client.findCustomer2();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("Server exiting");
> System.exit(0);
> }
> This will print the following output:
> Server ready...
> call findCustomer()
> 20.01.2010 07:49:45
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 1
> Address: http://localhost:9000/CustomerService
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=["findCustomer"], Accept=[*/*]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> xmlns:ns2="http://cxf.apache.org/demo/CustomerService/1/"/>
> --
> 20.01.2010 07:49:45 org.apache.cxf.interceptor.Log
[jira] Commented: (CXF-2164) CXFBusImpl never removed from ThreadLocal, generates permgen out of memory error after some redeployments
[
https://issues.apache.org/jira/browse/CXF-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907346#action_12907346
]
Daniel Kulp commented on CXF-2164:
--
Definitely log a new bug for this.
I'm thinking we MAY need to do the same thing we did for the request/response
objects in the ClientImpl of using something like:
protected Map threadBusses
= Collections.synchronizedMap(new WeakHashMap());
The destroy method could walk the map and remove any keys that are associated
with that Bus.
Anyway, please log a new bug. A patch would be great as well. :-)
> CXFBusImpl never removed from ThreadLocal, generates permgen out of memory
> error after some redeployments
> -
>
> Key: CXF-2164
> URL: https://issues.apache.org/jira/browse/CXF-2164
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.1.4
>Reporter: Francois Masurel
>Assignee: Bharath Ganesh
> Fix For: 2.2.2
>
> Attachments: cxf_threadlocal.jpg,
> Heap_Walker_Incoming_References.zip, threadlocal.patch
>
>
> I've found this message on a mailing list recently, and it doesn't seem to
> have been resolved as we have the same problem with version 2.1.4 of CXF on
> one of our webapp :
> Hello CXF users,
> I've been working on figuring out why our JBoss servers keep going down with
> permgen out
> of memory exceptions when we redeploy our war files. To do this I had been
> using a profiler
> to inspect the WebAppClassloader to find out what was keeping it from being
> garbage collected.
> One such culprit was the class org.apache.cxf.BusFactory
> The BusFactory has a ThreadLocal in which it stores a copy of CXFBusImpl.
> However, this isn't
> getting cleaned up properly when the war is undeployed. I noticed that
> CXFBusImpl has a shutdown
> method that calls BusFactory.setDefaultBus(null) which in turn sets the value
> stored in the
> ThreadLocal to null. However, this doesn't seem to be getting called.
> The way we are using CXF from spring is with the following
> WEB-INF/services.xml file in our
> war:
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:amq="http://activemq.org/config/1.0";
> xmlns:jaxws="http://cxf.apache.org/jaxws";
> xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> http://activemq.org/config/1.0
> http://activemq.apache.org/schema/core/activemq-core-5.0.0.xsd";
> default-autowire="byType">
>
>
>
> address="/HelloService" />
>
> I'm not really sure why this Bus.shutdown() isn't getting called or even who
> is responsible
> for calling it. I tried doing something along the lines of:
> WebApplicationContext webContext =
> WebApplicationContextUtils.getRequiredWebApplicationContext(context);
> if (webContext.containsBean("cxf")) {
> CXFBusImpl cxfBus = (CXFBusImpl) webContext.getBean("cxf");
> cxfBus.shutdown(true);
> }
> But that didn't work. What I eventually ended up doing was to have the
> following hack in the
> shutdown sequence of our webapp:
> Field field = org.apache.cxf.BussFactory.class.getDeclaredField("localBus");
> field.setAccessible(true);
> ThreadLocal localBus = (ThreadLocal) field.get(null);
> localBus.remove();
> This did work but obviously it is a bit of an ugly hack. Is there something
> that needs to
> be included in our service.xml file to tell spring how to cleanup CXF? Is
> this maybe a bug
> in CXF that the CXFBusImpl.shutdown(Boolean) just isn't getting called at all
> or maybe that
> in BusFactory.setThreadDefaultBus(Bus) that there should be some check such
> as:
> if (bus == null) {
> localBus.remove();
> } else {
> localBus.set(bus);
> }
> Or maybe some combination of all of these. I'm reasonably new to CXF, Spring,
> and all this
> stuff so I apologize ahead of time if there is some obvious solution that I
> just didn't come
> across but I've been trying to scour the CXF and Spring documentation for
> some idea of the
> correct way to do this and why BusFactory is keeping its ThreadLocal but I
> can't figure it
> out.
> Thanks!
> Ben Dean
> Software Engineer
> Ontario Systems, LLC
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2978) CLONE -Return Type List gets null on client if an empty list is returned
[
https://issues.apache.org/jira/browse/CXF-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2978.
--
Fix Version/s: Invalid
Resolution: Not A Problem
Working per spec.
> CLONE -Return Type List gets null on client if an empty list is returned
>
>
> Key: CXF-2978
> URL: https://issues.apache.org/jira/browse/CXF-2978
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Affects Versions: 2.1.8, 2.2.7, 2.2.9, 2.2.10
> Environment: JSE 1.5 on Win XP
>Reporter: Staffan Forsell
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: Invalid
>
> Attachments: EmptyListExample-2.2.10.tar.gz
>
>
> If you have a function that returns an empty list the result will be null on
> client. Even If add a Responsewrapper to the interface it doesn't work. If
> have attached a little test project / program:
> Interface:
> @WebService(targetNamespace =
> "http://cxf.apache.org/demo/CustomerService/1/";, name = "CustomerService")
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use =
> SOAPBinding.Use.LITERAL)
> public interface CustomerService {
> @WebMethod(action = "findCustomer", operationName = "findCustomer")
> public @WebResult(name = "customerList")
> List findCustomer();
>
>
> @WebMethod(action = "findCustomer2", operationName = "findCustomer2")
> @ResponseWrapper(className="demo.service.CustomerListResponse")
> public @WebResult(name = "customerList")
> List findCustomer2();
> }
> The Implementation:
> @WebService(name = "CustomerService", serviceName = "CustomerService",
> targetNamespace = "http://cxf.apache.org/demo/CustomerService/1/";,
> endpointInterface = "demo.service.CustomerService")
> public class CustomerServiceImpl implements CustomerService {
> public List findCustomer() {
> // very stupid method
> return new ArrayList();
> }
> public List findCustomer2() {
> // another very stupid method
> return new ArrayList();
> }
> }
> And this is the main programm:
> public static void main(String args[]) throws Exception {
> new Server();
> System.out.println("Server ready...");
> // Now Call the Service
> JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
> factory.getInInterceptors().add(new LoggingInInterceptor());
> factory.getOutInterceptors().add(new LoggingOutInterceptor());
> factory.setServiceClass(CustomerService.class);
> factory.setAddress("http://localhost:9000/CustomerService";);
> CustomerService client = (CustomerService) factory.create();
> System.out.println("call findCustomer()");
> List result = client.findCustomer();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("call findCustomer2()");
> result = client.findCustomer2();
> if (result != null)
> System.out.println("Listsize: " + result.size());
> else
> System.out.println("List is null: " + result);
> System.out.println("Server exiting");
> System.exit(0);
> }
> This will print the following output:
> Server ready...
> call findCustomer()
> 20.01.2010 07:49:45
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 1
> Address: http://localhost:9000/CustomerService
> Encoding: UTF-8
> Content-Type: text/xml
> Headers: {SOAPAction=["findCustomer"], Accept=[*/*]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> xmlns:ns2="http://cxf.apache.org/demo/CustomerService/1/"/>
> --
> 20.01.2010 07:49:45 org.apache.cxf.interceptor.LoggingInInterceptor logging
> INFO: Inbound Message
>
> ID: 1
> Encoding: UTF-8
> Content-Type: text/xml; charset=utf-8
> Headers: {Content-Length=[194], Server=[Jetty(6.1.21)],
> content-type=[text/xml; charset=utf-8]}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> xmlns:ns2="http://cxf.apache.org/demo/CustomerService/1/"/>
> --
> List is null: null
> call findCustomer2()
> 20.01.2010 07:49:45
> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
> INFO: Outbound Message
> ---
> ID: 2
> Address: http://localhost:9000/CustomerSer
[jira] Created: (CXF-2983) Instrumentation MBean fails to register with Websphere MBean Server
Instrumentation MBean fails to register with Websphere MBean Server --- Key: CXF-2983 URL: https://issues.apache.org/jira/browse/CXF-2983 Project: CXF Issue Type: Bug Components: Bus Affects Versions: 2.2.9 Reporter: Josh Cummings With the following configuration: On WebSphere, MBean registration will fail on startup with the following error: javax.management.NotCompliantMBeanException: MBean class org.apache.cxf.bus.ManagedBus does not implement DynamicMBean, neither follows the Standard MBean conventions (javax.management.NotCompliantMBeanException: Class org.apache.cxf.bus.ManagedBus is not a JMX compliant Standard MBean) nor the MXBean conventions (javax.management.NotCompliantMBeanException: org.apache.cxf.bus.ManagedBus: Class org.apache.cxf.bus.ManagedBus is not a JMX compliant MXBean) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2983) Instrumentation MBean fails to register with Websphere MBean Server
[ https://issues.apache.org/jira/browse/CXF-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907422#action_12907422 ] Josh Cummings commented on CXF-2983: Sorry, where "" refers to the http://www.springframework.org/schema/context namespace > Instrumentation MBean fails to register with Websphere MBean Server > --- > > Key: CXF-2983 > URL: https://issues.apache.org/jira/browse/CXF-2983 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.2.9 >Reporter: Josh Cummings > > With the following configuration: > > >class="org.apache.cxf.management.jmx.InstrumentationManagerImpl"> > > > > > > On WebSphere, MBean registration will fail on startup with the following > error: > javax.management.NotCompliantMBeanException: MBean class > org.apache.cxf.bus.ManagedBus does not implement DynamicMBean, neither > follows the Standard MBean conventions > (javax.management.NotCompliantMBeanException: Class > org.apache.cxf.bus.ManagedBus is not a JMX compliant Standard MBean) nor the > MXBean conventions (javax.management.NotCompliantMBeanException: > org.apache.cxf.bus.ManagedBus: Class org.apache.cxf.bus.ManagedBus is not a > JMX compliant MXBean) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2970) Service cannot create a Socket
[
https://issues.apache.org/jira/browse/CXF-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907499#action_12907499
]
Willem Jiang commented on CXF-2970:
---
Hi Paulo,
I update the wiki page as you suggested, please check it out for double check :)
Willem
> Service cannot create a Socket
> --
>
> Key: CXF-2970
> URL: https://issues.apache.org/jira/browse/CXF-2970
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP, Java jdk1.6.0_20, Maven 2.2.1, Eclipse
> 3.6.0, activemq-core 5.4.0
>Reporter: Paulo Rodrigez
>Assignee: Willem Jiang
>Priority: Minor
>
> Hey
> I've got a problem to create a service SOAP over JMS. I have created a WSDL
> and use you codegen plugin to generate the server-skel. Now I try to start
> this service with the following lines:
> {code}
> public class ProjectServer {
> private ProjectServer() throws NamingException {
> // You just need to set the address with JMS URI
> String address =
> "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue"
> + "?jndiInitialContextFactory"
> +
> "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
> +
> "&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61610";
> Project implementor = new ProjectImpl();
> JaxWsServerFactoryBean svrFactory = new
> JaxWsServerFactoryBean();
> svrFactory.setServiceClass(Project.class);
> svrFactory.setAddress(address);
> // And specify the transport ID with SOAP over JMS specification
>
> svrFactory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICIATION_TRANSPORTID);
> svrFactory.setServiceBean(implementor);
> svrFactory.create();
> }
> /**
>* @param args
>* @throws NamingException
>*/
> public static void main(String[] args) throws NamingException {
> new ProjectServer();
> }
> }
> {code}
> Here is my WSDL:
> {code}
>
> http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:tns="http://www.mycompany.com/project/service";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/";
> xmlns:model="http://www.mycompany.com/project/model";
> name="project"
> targetNamespace="http://www.mycompany.com/project/service";>
>
>targetNamespace="http://www.mycompany.com/project/model";>
>
>
>
>type="xsd:string" />
>
>
>
>
>
>
>type="xsd:string" />
>
>
>
>type="xsd:string">
>type="xsd:string">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://www.w3.org/2008/07/soap/bindings/JMS/"; />
>
> ConnectionFactory
>
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory
>
> tcp://localhost:61616
> PERSISTENT
> 5
> 1000
>
>soapAction="http://www.mycompany.com/project/service/GreetMeOp"; />
>
>
>
>
>
>
>
>
>
>
>location="jms:jndi:dynamicQueues/test.cxf.jmstransport.queue" />
>
>
>
> {code}
> Error is:
> INFO: Setting the server's publish address to be
> jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61610
> Exception in thread "main" org.springframework.jms.UncategorizedJmsException:
> Uncategorized exception occured during JMS processing; nested exception is
> javax.jms.JMSException: Could not connect to broker URL:
> tcp://localhost:61610. Reason: java.net.ConnectException:
[jira] Assigned: (CXF-2976) Allow to configure SSL session cache size and TTL on the client
[ https://issues.apache.org/jira/browse/CXF-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-2976: - Assignee: Freeman Fang > Allow to configure SSL session cache size and TTL on the client > --- > > Key: CXF-2976 > URL: https://issues.apache.org/jira/browse/CXF-2976 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.2.6, 2.2.7 > Environment: Windows/Linux, jdk1.6 >Reporter: Grzegorz Mucha >Assignee: Freeman Fang > Attachments: sslSessionTimeout.patch > > > JDK SSL connectivity maintains a cache of SSLSessions that it reuses for > subsequent connection. Unfortunately the default TTL in this cache is set to > 24h. We have ran into an issue with a specific environment setup on the > server side - with a F5 loadbalancer doing SSL offloading, the SSL sessions > were valid on the load balancer but were broken beyond that point. The > problem turned out the TTL of that cache being too long - in our case tuning > it down to 60 seconds resolved the issue. FWIW we have actually encountered > this issue with multiple vendors. > The timeout can be configured via > SSLSession.getClientSessionContext().setSessionTimeout(int) - the suggestion > is to add this parameter to be configured via TLSClientParams. Unfortunately > the only way that the SSLSession is now accessed/configured is inside > HttpsURLConnectionFactory - and this class is right now tightly coupled to a > HttpConduit. There isn't actually a way to set the default TTL - or set it > globally in the JVM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2976) Allow to configure SSL session cache size and TTL on the client
[ https://issues.apache.org/jira/browse/CXF-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-2976. --- Resolution: Fixed apply patch on behalf of Grzegorz Mucha with thanks http://svn.apache.org/viewvc?rev=995314&view=rev for trunk http://svn.apache.org/viewvc?rev=995326&view=rev for 2.2.x branch > Allow to configure SSL session cache size and TTL on the client > --- > > Key: CXF-2976 > URL: https://issues.apache.org/jira/browse/CXF-2976 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.2.6, 2.2.7 > Environment: Windows/Linux, jdk1.6 >Reporter: Grzegorz Mucha >Assignee: Freeman Fang > Attachments: sslSessionTimeout.patch > > > JDK SSL connectivity maintains a cache of SSLSessions that it reuses for > subsequent connection. Unfortunately the default TTL in this cache is set to > 24h. We have ran into an issue with a specific environment setup on the > server side - with a F5 loadbalancer doing SSL offloading, the SSL sessions > were valid on the load balancer but were broken beyond that point. The > problem turned out the TTL of that cache being too long - in our case tuning > it down to 60 seconds resolved the issue. FWIW we have actually encountered > this issue with multiple vendors. > The timeout can be configured via > SSLSession.getClientSessionContext().setSessionTimeout(int) - the suggestion > is to add this parameter to be configured via TLSClientParams. Unfortunately > the only way that the SSLSession is now accessed/configured is inside > HttpsURLConnectionFactory - and this class is right now tightly coupled to a > HttpConduit. There isn't actually a way to set the default TTL - or set it > globally in the JVM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2984) Added getState() method into InterceptorChain
Added getState() method into InterceptorChain -- Key: CXF-2984 URL: https://issues.apache.org/jira/browse/CXF-2984 Project: CXF Issue Type: Improvement Components: Core Reporter: Willem Jiang Assignee: Willem Jiang Priority: Minor Fix For: 2.3 We can get the InterceptorChain from message, if we can get the stats of the InterceptorChain, that will be great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
