Re: [VOTE] Cyrille Le Clerc for committer....
+1 Cheers, Eoghan 2009/12/3 Daniel Kulp > > > Cyrille has submitted several patches to various management and logging > related things for CXF starting way back in February. I think he's up to > 7 > or 8 submitted patches.He's also been hanging around the user list for > almost a year answering some questions.Thus, I think he's a bit over > due > to become a committer. > > Here is my +1. > > Vote will be open for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Cyrille Le Clerc for committer....
+1 Daniel Kulp wrote: Cyrille has submitted several patches to various management and logging related things for CXF starting way back in February. I think he's up to 7 or 8 submitted patches.He's also been hanging around the user list for almost a year answering some questions.Thus, I think he's a bit over due to become a committer. Here is my +1. Vote will be open for at least 72 hours. -- Alessio Soldano Web Service Lead, JBoss
NPE when handling Addressing by JAX-WS message mode provider
Hi, I have created a test case that expsoses what I think is a bug, attached to issue: https://issues.apache.org/jira/browse/CXF-2572 BTW, this is in continuation of this thread from the user list: http://thread.gmane.org/gmane.comp.apache.cxf.user/4153 I am trying to figure out what is going on, but it has something to do with processing at the provider (server) side. The client proxy seems to do things correctly and sends out proper WS-Addressing headers in the request. Any pointers would be appreciated (especially if it would be easy to fix for a newcomer). Thanks, Alex
Migrating CXF-DOSGi to be complaint with the new OSGi Remote Service Admin spec
Hi all, As you've seen, the CXF-DOSGi 1.1 release is out [1]. Thanks Eoghan! 1.1 is compliant with the current OSGi 4.2 Remote Services spec [2]. In the mean time, in the OSGi Alliance an additional 'Distributed OSGi' specification is nearing completion: Remote Service Admin [3]. This spec defines a number of APIs used internally in Distributed OSGi implementations. The APIs define the interaction between the Distribution Provider, Discovery System and a component called the Topology Manager. The benefit of implementing this standard is that you can mix & match components from various implementations together. For instance if someone provided a compliant Discovery implementation based on UDDI, you could just replace the ZooKeeper-based one in CXF with that UDDI one. It would just be a matter of replacing the bundles. CXF-DOSGi is the Reference Implementation of chapter 13, and will also be the reference implementation of chapter 122. Marc Schaaf has been working on refactoring the CXF-DOSGi implementation to also be compliant with Remote Service Admin while maintaining backward compatibility. Marc and I are planning to contribute this work to CXF-DOSGi trunk over the coming weeks. This might destabilize http://svn.apache.org/repos/asf/cxf/dosgi/trunk for a little while, which is one of the reasons why we waited until after the 1.1 release. Hope everyone is ok with this. Best regards, David [1] http://cxf.apache.org/dosgi-releases.html [2] Chapter 13 in the 4.2 Compendium http://www.osgi.org/Download/Release4V42 [3] Chapter 122 in http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf
Re: JMS reconnectOnException
This is really a Spring JMS thing, I think. We just call the setReconnectOnException method on the Spring SingleConnectionFactory. You can probably ask at: http://forum.springsource.org/forumdisplay.php?f=30 Dan On Thu December 3 2009 9:06:09 pm Erich Hochmuth wrote: > Not sure if this is the correct forum or the correct format. > > In CXF 2.2.4 with a JMS bases service we are getting the following > exception when the web application starts up in WebLogic 10.3. > > This only seems to happen when we set the "reconnectOnException" > property of the JMSConfiguration to true: > http://cwiki.apache.org/CXF20DOC/using-the-jmsconfigfeature.html > > Please let me know what additional information I can provide or any > ideas on what I can do to fix this issue or if it is a configuration > error on my side. > > Caused by: org.springframework.jms.UncategorizedJmsException: Uncategorized > exception occured during JMS processing; nested exception is > javax.jms.JMSException: [JMSPool:169801]The JMS method setExceptionListener > may not be called inside an EJB or servlet > at > org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils > .java:308) at > org.springframework.jms.support.JmsAccessor.convertJmsAccessException(JmsAc > cessor.java:168) at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:474) > at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:436) > at > org.apache.cxf.transport.jms.JMSFactory.resolveOrCreateDestination(JMSFacto > ry.java:260) at > org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.java:2 > 40) at > org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.java:1 > 46) at > org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:11 > 1) at > org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObse > rvable.java:48) at > org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFa > ctory.java:164) at > org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFacto > ry.java:766) at > org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122) at > org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:271) ... 61 > more > Caused by: javax.jms.JMSException: [JMSPool:169801]The JMS method > setExceptionListener may not be called inside an EJB or servlet > at > weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions.java:22 > ) at > weblogic.deployment.jms.PooledConnection.setExceptionListener(PooledConnect > ion.java:180) at > org.springframework.jms.connection.SingleConnectionFactory.prepareConnectio > n(SingleConnectionFactory.java:365) at > org.springframework.jms.connection.SingleConnectionFactory.initConnection(S > ingleConnectionFactory.java:291) at > org.springframework.jms.connection.SingleConnectionFactory.createConnection > (SingleConnectionFactory.java:227) at > org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor.ja > va:184) at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:461) > ... 71 more > > > > Thanks, > > Erich > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Disabling WS-SecurityPolicy if Policy and Security modules present?
Glen, At this point, you cannot turn off the WS-SecPol stuff, but you CAN turn off the entire Policy engine. See: http://cxf.apache.org/docs/wspconfiguration.html Dan On Sun November 22 2009 5:49:37 pm Glen Mazza wrote: > Hello, on this page: > http://cwiki.apache.org/confluence/display/CXF20DOC/WS-SecurityPolicy, it > says: > > "In CXF 2.2, if the cxf-rt-ws-policy and cxf-rt-ws-security modules are > available on the classpath, the WS-SecurityPolicy stuff is automatically > enabled. Since the entire security runtime is policy driven, the only > requirement is that the policy engine and security policies be available. > > If you are using the full "bundle" jar, all the security and policy stuff > is already included." > > But can we explicitly *disable* WS-SecurityPolicy via configuration if we > already have included those two modules? Perhaps we should update our docs > with this info. > > Glen > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: NPE when handling Addressing by JAX-WS message mode provider
Thanks for the test case. Helped a lot. The problem is due to the partial responses on one-way operations. In that case, the list IS null so the null check is appropriate. Fix is committed. Thanks a bunch for the test case. Dan On Fri December 4 2009 5:19:35 am Alexandros Karypidis wrote: > Hi, > > I have created a test case that expsoses what I think is a bug, attached > to issue: > https://issues.apache.org/jira/browse/CXF-2572 > > BTW, this is in continuation of this thread from the user list: > http://thread.gmane.org/gmane.comp.apache.cxf.user/4153 > > I am trying to figure out what is going on, but it has something to do > with processing at the provider (server) side. The client proxy seems to > do things correctly and sends out proper WS-Addressing headers in the > request. Any pointers would be appreciated (especially if it would be > easy to fix for a newcomer). > > Thanks, > Alex > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
