Re: Why Apache CXF not being used in WebLogic 12c ?
Hi Daniel, I tried what you said, this is declaring an endpoint in my cxf-servlet.xml. I added the following lines: And now, when I deploy in WebLogic 12c I am getting this error: java.lang.ClassCastException: weblogic.wsee.jaxws.spi.WLSProvider cannot be cast to javax.xml.ws.spi.Provider Any idea ? In weblogic logs I see this error and then references to cxf, so it looks promising, but I don't see how to fix it. Thanks Daniel -- View this message in context: http://cxf.547215.n5.nabble.com/Why-Apache-CXF-not-being-used-in-WebLogic-12c-tp5749219p5749272.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Why Apache CXF not being used in WebLogic 12c ?
Thanks Krzysztof I tried but still not working -- View this message in context: http://cxf.547215.n5.nabble.com/Why-Apache-CXF-not-being-used-in-WebLogic-12c-tp5749219p5749273.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Why Apache CXF not being used in WebLogic 12c ?
Do you have a jaxws-api jar in your war/ear? If so, try removing it (and pretty much all the other api jars) and use the version provided by the jre/weblogic. That may help. That said, not sure why it’s still trying to create the weblogic.wsee.jaxws.spi.WLSProvider thing. Dan On Sep 26, 2014, at 6:14 AM, Felix.1973 wrote: > Hi > > Daniel, I tried what you said, this is declaring an endpoint in my > cxf-servlet.xml. I added the following lines: > > > > address="/HelloWorld"/> > > And now, when I deploy in WebLogic 12c I am getting this error: > > java.lang.ClassCastException: weblogic.wsee.jaxws.spi.WLSProvider cannot be > cast to javax.xml.ws.spi.Provider > > Any idea ? In weblogic logs I see this error and then references to cxf, so > it looks promising, but I don't see how to fix it. > > Thanks Daniel > > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Why-Apache-CXF-not-being-used-in-WebLogic-12c-tp5749219p5749272.html > Sent from the cxf-dev mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Why Apache CXF not being used in WebLogic 12c ?
I don't have any jaxws-api jar. api's that I see are: cxf-services-ws-discovery-api-2.7.12.jar cxf-services-wsn-api-2.7.12.jar javax.ws.rs-api-2.0-m10.jar slf4j-api-1.7.7.jar stax2-api-3.1.4.jar this weblogic configuration is being a total nightmare -- View this message in context: http://cxf.547215.n5.nabble.com/Why-Apache-CXF-not-being-used-in-WebLogic-12c-tp5749219p5749278.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Why Apache CXF not being used in WebLogic 12c ?
By the way, I took the "java_first_spring_support" coming in the samples folder of my apache-cxf-2.7.12 installation and the only thing I did was adding Thread.dumpStack() in the Web Service plus create a weblogic-application.xml file etc as stated here: http://cxf.apache.org/docs/application-server-specific-configuration-guide.html#ApplicationServerSpecificConfigurationGuide-WebLogic Final result... the same... works fine in Intellij (it uses CXF) and the deployement in WebLogic works fine (helloWorld works) but using weblogic.wsee.jaxws So same behaviour... So I still want WebLogic to use CXF but no luck :-( -- View this message in context: http://cxf.547215.n5.nabble.com/Why-Apache-CXF-not-being-used-in-WebLogic-12c-tp5749219p5749282.html Sent from the cxf-dev mailing list archive at Nabble.com.
RE: configuration of ClientId using JMS compliant style (CXF 3.x.x); unsubscribe from durable subscriptions
It seems that configuration option for (1: ClientId) is already in place. Client or service can register a feature containing properties to be overriding. This feature will retrieve Conduit or Destination from client or sever and replace configured properties in JMSConfiguration of Conduit or Destination correspondingly. It is possible to override any URL JMS property, if necessary. Any thoughts regarding (2): unsubscribing from durable subscriptions? Regards, Andrei. > -Original Message- > From: Andrei Shakirin [mailto:ashaki...@talend.com] > Sent: Donnerstag, 25. September 2014 16:03 > To: dev@cxf.apache.org > Cc: Christian Schneider > Subject: JMS: configuration of ClientId using JMS compliant style (CXF 3.x.x); > unsubscribe from durable subscriptions > > Hi, > > I am analysing possible extension of ClientId JMS configuration using JMS > compliant style (through URL). > > 1. ClientId. > Use case: the CXF client and service communicating using JMS Topic and > durable subscription. > Both client and service using ClientId and durable subscription name in order > to > identify state maintained on behalf of the client by a provider. > ClientId is specified through durableSubscriptionClientId parameter in > endpoint > URL. > URL is resolved globally for client and service through the WSDL stored into > ServiceRegistry / ServiceLocator. Therefore URL is shared between all client > and service instances of this service. > > Problem: as soon as some client instances are running on the same host (or > client and service are running on the same host), the JMS connection is > rejected because of using the same ClientId. > > Proposal: Would it makes sense to provide a way to override ClientId in the > URL: for example define ClientId as local jax-ws property on the client and on > the server sides. JMS transport will check for this property, if it isn't set > - use > value from URL. If it is set - use property value. > > 2. Durable subscription. > Currently CXF destination hasn't any mechanism to unsubscribe from durable > Topic subscription. Of course, we cannot simply unsubscribe by Destination > deactivation, because service can expect to receive the messages from the > Topic by next start. I see two options: > a) introduce kind of property to explicitly specify when destination should > be > unsubscribed from the durable Topic subscription > b) leave it completely out of scope of CXF and document that it is > administration activity to remove durable JMS subscriptions > > Any thoughts? > > Regards, > Andrei.
RE: configuration of ClientId using JMS compliant style (CXF 3.x.x); unsubscribe from durable subscriptions
Yeah, I incline to leave it out of scope as well. If there are no objections, I will update JMS documentation in this way. Regards, Andrei. > -Original Message- > From: Christian Schneider > Sent: Freitag, 26. September 2014 17:43 > To: Andrei Shakirin; dev@cxf.apache.org > Subject: Re: configuration of ClientId using JMS compliant style (CXF 3.x.x); > unsubscribe from durable subscriptions > > IMHO unsubscribing from durable subscriptions is a management task. So I > would consider this to be out of scope. > > Christian > > > On 26.09.2014 17:34, Andrei Shakirin wrote: > > It seems that configuration option for (1: ClientId) is already in place. > > Client or service can register a feature containing properties to be > > overriding. > > This feature will retrieve Conduit or Destination from client or sever and > replace configured properties in JMSConfiguration of Conduit or Destination > correspondingly. > > It is possible to override any URL JMS property, if necessary. > > > > Any thoughts regarding (2): unsubscribing from durable subscriptions? > > > > Regards, > > Andrei. > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com
New metrics in rt-management
I’ve just pushed (to 3.1) a new class in ft-management that enables some more advance metric tracking for CXF endpoints and operations. The current CounterRepository provides some very basic min/max/avg/count type metrics. That’s useful, but more advanced information like stddevs and percentiles and such. Also, stats per type of fault is useful as well. Example: maybe the runtime faults are causing the major slowdown. To accomplish this, I’ve used the coda hale library and it’s Timer objects (also added an “In Flight” counter to record how many requests are being processed). The main “issue” is that all the metrics are in a different place in the JMX tree. However, both the older CounterRepository and the new Metrics thing can be enabled at the same time if required. I’ve updated the wsdl_first demo’s -Pserver-spring spring based server to enable the new metrics. Feel free to give it a try and let me know what you think.It has both enabled so once you hit the server (mvn -Pclient will work), you can dig through the “Metrics.Server” section in jconsole and see some of what’s there. Right now, I’ve only added capabilities for the server side. I won’t have time for a week or so to look at the client side, but if someone would like to pick that up, that would be great. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: configuration of ClientId using JMS compliant style (CXF 3.x.x); unsubscribe from durable subscriptions
IMHO unsubscribing from durable subscriptions is a management task. So I would consider this to be out of scope. Christian On 26.09.2014 17:34, Andrei Shakirin wrote: It seems that configuration option for (1: ClientId) is already in place. Client or service can register a feature containing properties to be overriding. This feature will retrieve Conduit or Destination from client or sever and replace configured properties in JMSConfiguration of Conduit or Destination correspondingly. It is possible to override any URL JMS property, if necessary. Any thoughts regarding (2): unsubscribing from durable subscriptions? Regards, Andrei. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
