Re: Activators for individual frontends
On 19/12/11 10:35, Sergey Beryozkin wrote: Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own I guess they actually may once we get individual modules OSGI-fied. But when get cxf-bundle or cxf-rs bundle deployed these activators are plain beans; I think they have to get hold of the root activator, which is org.apache.cxf.bus.osgi.OSGiExtensionLocator, and get BundleContext from it and do whatever they need to do - ServiceTrack(er) the Application interfaces, or in case of JAX-WS listening on bundles with jaxws annotations, something like that, etc. IMHO that will be actually cool - will add a lot of dynamism, and it won't interfere with say the existing deployment model where we create blueprint or spring contexts What I don't understand is how say OSGiExtensionLocator will pass BundleContext to frontend-specific Activator beans. Sergey , they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Could not instantiate bean SpringBus: 2.4.1
Hi, I have found the solution. 1. need to make the class loader policy at module level to be PARENT_LAST 2. delete following jars geronimo-activation_1.1_spec-1.1.jar geronimo-annotation_1.0_spec-1.1.1.jar geronimo-javamail_1.4_spec-1.7.1.jar geronimo-servlet_2.5_spec-1.1.2.jar geronimo-stax-api_1.0_spec-1.0.1.jar Then this worked fine Regards, Lalit Kumar - Lalit Kumar Technical Specialist Fidelity International -- View this message in context: http://cxf.547215.n5.nabble.com/Could-not-instantiate-bean-SpringBus-2-4-1-tp4539354p5088879.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: bus extensions association under multiple buses
Hi, While trying to write a few test cases, I just found out that the bus's id attribute seems to be already providing the same effect originally intended by the persistentBusId property. So, to assign the jmx registration name for each bus, we just need to set the id attribute for that bus. That means, for the container case, we don't need to configure the instrumentation manager bean at all, as its default setting will ensure the correct registration. For the standalone case, I can introduce bus properties bus.jmx.enabled etc to configure the instrumentation manager within the bus configuration. In this way, you don't need to refer to this instrumentation manager impl class in your configuration. regards, aki 2011/12/20 Aki Yoshida elak...@googlemail.com: 2011/12/19 Daniel Kulp dk...@apache.org: Inline On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote: There is a problem in the bus extension association under multiple buses that may result in some concrete problem in some cases. I have a possible fix for this problem but there is also a related question to it. So, I would like to get your opinion about how we should proceed. Concretely, the problem is that the association of the InstrumentationManager extension to its bus is not correctly happening when this extension is explicitly configured as a bean referencing to a specific bus instance using its bus property parameter. A particular use case of this occurs when one wants to use the persistentBusId property of the instrumentation manager to specify the jmx registration name for the bus instead of using the generated name for the registration. To support this registration name use case itself, we could probably generate the registration name based partly on the bus name (ie. the bus name along with some hash value and its bundle symbolic name if available) instead of utilizing this persistedBusId mechanism. I think I would have considered this approach if this persitentBusId didn't exist. In this case, we would not have needed to configure the instrumentation manager bean only to set the persistendBusId property. But if we want to utilize the current persistentBusId mechanism, namely to use this property value of the instrumentation manager associated with the bus as the jmx registration name, it appears that we need to make certain changes in the way how the extensions are instantiated so that the bus-extension association is correctly done and these buses are registered under the correct names. The concrete changes that I think needed are: 1. remove the annotation at InstrumentationManagerIml's setBus so that the invocation of this method can be controlled. +1 2. In org.apache.cxf.bus.extension.Extension's load method, invoke the setBus method if the extension has no bus-argument constructor but has the setBus method. This will ensure the implicit extension loading by the default bus to work even after the removal of the annotation above. OK. But I'd likely just add a second Bus constructor to the InstrumentationManager that would get invoked. But it's still a good idea. I now think introducing the bus-argument constructor for InstManager might be a safer approach than calling the setBus method. This does not involve any change to Extension and hence is less invasive. In this way, we can avoid this extra setBus call by just providing the bus-argument constructor. Your simple adding the bus constructor approach has an additional benefit of being able to distinguish between the two bus settings cases in the method: the initial bus setting at the extension construction (over the constructor) and a subsequent bus setting (over setBus). 3. In InstrumentationManagerImpl's setBus method, verify if the bus argument is already associated with another InstrumentationManagerImpl instance. This will happen when this instrumentation bean is explicitly configured as a bean in the described use case above. In this case, update the association of the bus so that the bus is associated with the explicitly configured instrumentation manager and not the one that is implicitly loaded (so that this bus will be registered under the persistentBusId name instead of the generated registration name). I'm OK with that. HOWEVER.. I would ALSO have it call something like: bus.getProperty(bus.jmx.persistentId) bus.getProperty(bus.jmx.url) etc... and anything else it may need. In that way, the entire management of the Bus can be configured in with just Bus properties without actually having to configure in an InstrumentationManagerImpl. Just some (hopefully documented) properties set on the bus would be enough. Yes. That sounds good. This will simplify the configuration. With these changes, I can see the buses, their endpoints, etc registered under their persistent bus Id names. But before taking any concrete action, I would like to ask you how we
Re: bus extensions association under multiple buses
On Tuesday, December 20, 2011 5:58:23 PM Aki Yoshida wrote: Hi, While trying to write a few test cases, I just found out that the bus's id attribute seems to be already providing the same effect originally intended by the persistentBusId property. So, to assign the jmx registration name for each bus, we just need to set the id attribute for that bus. That means, for the container case, we don't need to configure the instrumentation manager bean at all, as its default setting will ensure the correct registration. Yep. Actually, that's already the case in OSGi to some extent, but this will also extend it out beyond OSGi.With 2.5.x, if an MBeanServer is found either in the application context (Spring) or as an OSGi service (osgi, both Blueprint and Spring), then the management is automatically enabled. For example, if you deploy CXF into Karaf, Karaf pretty much always has an MBeanServer registered as an OSGi service. Thus, CXF is always instrumented there. For the standalone case, I can introduce bus properties bus.jmx.enabled etc to configure the instrumentation manager within the bus configuration. In this way, you don't need to refer to this instrumentation manager impl class in your configuration. +1. Getting rid of references to Impl classes is great. :-) Dan regards, aki 2011/12/20 Aki Yoshida elak...@googlemail.com: 2011/12/19 Daniel Kulp dk...@apache.org: Inline On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote: There is a problem in the bus extension association under multiple buses that may result in some concrete problem in some cases. I have a possible fix for this problem but there is also a related question to it. So, I would like to get your opinion about how we should proceed. Concretely, the problem is that the association of the InstrumentationManager extension to its bus is not correctly happening when this extension is explicitly configured as a bean referencing to a specific bus instance using its bus property parameter. A particular use case of this occurs when one wants to use the persistentBusId property of the instrumentation manager to specify the jmx registration name for the bus instead of using the generated name for the registration. To support this registration name use case itself, we could probably generate the registration name based partly on the bus name (ie. the bus name along with some hash value and its bundle symbolic name if available) instead of utilizing this persistedBusId mechanism. I think I would have considered this approach if this persitentBusId didn't exist. In this case, we would not have needed to configure the instrumentation manager bean only to set the persistendBusId property. But if we want to utilize the current persistentBusId mechanism, namely to use this property value of the instrumentation manager associated with the bus as the jmx registration name, it appears that we need to make certain changes in the way how the extensions are instantiated so that the bus-extension association is correctly done and these buses are registered under the correct names. The concrete changes that I think needed are: 1. remove the annotation at InstrumentationManagerIml's setBus so that the invocation of this method can be controlled. +1 2. In org.apache.cxf.bus.extension.Extension's load method, invoke the setBus method if the extension has no bus-argument constructor but has the setBus method. This will ensure the implicit extension loading by the default bus to work even after the removal of the annotation above. OK. But I'd likely just add a second Bus constructor to the InstrumentationManager that would get invoked. But it's still a good idea. I now think introducing the bus-argument constructor for InstManager might be a safer approach than calling the setBus method. This does not involve any change to Extension and hence is less invasive. In this way, we can avoid this extra setBus call by just providing the bus-argument constructor. Your simple adding the bus constructor approach has an additional benefit of being able to distinguish between the two bus settings cases in the method: the initial bus setting at the extension construction (over the constructor) and a subsequent bus setting (over setBus). 3. In InstrumentationManagerImpl's setBus method, verify if the bus argument is already associated with another InstrumentationManagerImpl instance. This will happen when this instrumentation bean is explicitly configured as a bean in the described use case above. In this case, update the association of the bus so that the bus is associated with the explicitly configured instrumentation manager and not the one that is implicitly loaded (so that this bus will be registered under the persistentBusId name instead of
Re: Consume webservice error in request header ?
The error is the next , I reallly i dont understand it.
javax.xml.ws.soap.SOAPFaultException: Object reference not set to an
instance of an object.
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
Is there more information to that like a stack trace or similar? A caused
by exception? That might help diagnose this.
Dan
On Monday, December 19, 2011 6:48:22 AM sebastianv wrote:
HI, i have to consume a wcf service with token security in .net from
java client with eclipse and cxf library.
the service must recive two data in the header identificador1 and
identificador2.
In my code i have first a request header
Client client = org.apache.cxf.frontend.ClientProxy.getClient(port);
ListHeader headers = new ArrayListHeader();
try {
Header dummyHeader1=new Header(new QName(Identificador1),
Identificador1,
new
JAXBDataBinding(String.class));
Header dummyHeader2=new Header(new QName(Identificador2),
123,
new
JAXBDataBinding(String.class));
adn then i have the configuration for the token security
Map ctx = ((BindingProvider)port).getRequestContext();
ctx.put(ws-security.username,test);
ctx.put(ws-security.callback-handler, Test1.class.getName());
test1 is the class where the callback get the password.
The error is the next , I reallly i dont understand it.
javax.xml.ws.soap.SOAPFaultException: Object reference not set to an
instance of an object.
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146
is there some can help me with this.
Regarts
Sebastian
--
View this message in context:
http://cxf.547215.n5.nabble.com/Consume-webservice-error-in-request-header-
tp5086333p5086333.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: Activators for individual frontends
On Monday, December 19, 2011 10:35:07 AM Sergey Beryozkin wrote: Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own, they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. Well, we could have the current activator grab a list out of the current bundle (cxf-bundle) of other activators to instantiate and call. For example, we could have a META-INF/cxf/osgi-activators.txt that is created during bundling (shade can do it) that the OSGiExtensionLocator thing will grab and then call the start/stop on it. We'd only need to look in the current bundle. Once we split into modules, the core bundle would not have that and thus wouldn't do anything, but the jaxrs bundle could properly define it's own activator in it's manifest.This wouldn't be hard to do. Dan For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Consume webservice error in request header ?
hi daniel , thanks you for answer . the error complete and the stack is this : ( i hope this help us :) ) javax.xml.ws.soap.SOAPFaultException: Object reference not set to an instance of an object. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146) at $Proxy38.consultarElegibilidad(Unknown Source) at com.sfs.pogomed.util.Test3.main(Test3.java:219) Caused by: org.apache.cxf.binding.soap.SoapFault: Object reference not set to an instance of an object. at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.unmarshalFault(Soap12FaultInInterceptor.java:114) at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:59) at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessage(Soap12FaultInInterceptor.java:46) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:104) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:762) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1582) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1467) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1375) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:623) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:510) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:343) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:295) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) ... 2 more -- View this message in context: http://cxf.547215.n5.nabble.com/Consume-webservice-error-in-request-header-tp5086333p5089828.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Consume webservice error in request header ?
Well, it shows that the issue is a fault being sent back from the server side. You would need to look at the logs on the server side to see what is happening over there. Dan On Tuesday, December 20, 2011 11:19:10 AM sebastianv wrote: hi daniel , thanks you for answer . the error complete and the stack is this : ( i hope this help us :) ) javax.xml.ws.soap.SOAPFaultException: Object reference not set to an instance of an object. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146) at $Proxy38.consultarElegibilidad(Unknown Source) at com.sfs.pogomed.util.Test3.main(Test3.java:219) Caused by: org.apache.cxf.binding.soap.SoapFault: Object reference not set to an instance of an object. at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.unmarshalFa ult(Soap12FaultInInterceptor.java:114) at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessa ge(Soap12FaultInInterceptor.java:59) at org.apache.cxf.binding.soap.interceptor.Soap12FaultInInterceptor.handleMessa ge(Soap12FaultInInterceptor.java:46) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain .java:263) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(Abs tractFaultChainInitiatorObserver.java:104) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage( CheckFaultInterceptor.java:69) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage( CheckFaultInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain .java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:762) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse Internal(HTTPConduit.java:1582) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse (HTTPConduit.java:1467) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCond uit.java:1375) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:623) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInter ceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain .java:263) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:510) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:343) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:295) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) ... 2 more -- View this message in context: http://cxf.547215.n5.nabble.com/Consume-webservice-error-in-request-header- tp5086333p5089828.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: Consume webservice error in request header ?
ok, i will see and check it in the server Regarts -- View this message in context: http://cxf.547215.n5.nabble.com/Consume-webservice-error-in-request-header-tp5086333p5089870.html Sent from the cxf-dev mailing list archive at Nabble.com.
[ANN] Apache CXF 2.5.1, 2.4.5, and 2.3.8 released
The Apache CXF team is proud to announce the availability of the latest patches: 2.5.1, 2.4.5, and 2.3.8. Apache CXF is an open source services framework. CXF helps you build and develop services using front end programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. This is mostly a patch release to fix problems and issues that users have encountered. 2.5.1 fixes over 75 JIRA issues reported against 2.5.0.See: http://cxf.apache.org/cxf-251-release-notes.html 2.4.5 fixes over 40 JIRA issues reported against 2.4.4.See: http://cxf.apache.org/cxf-245-release-notes.html 2.3.8 fixes over 30 JIRA issues reported against 2.3.7.See: http://cxf.apache.org/apache-cxf-238-release-notes.html Note: these releases are *NOT* JAX-WS compliant as they have not passed the JAX-WS TCK. We plan to fix any issues so the next patch releases will again be JAX-WS compliant. For more information see: * Download: http://cxf.apache.org/download.html * Website: http://cxf.apache.org/ * Mailing lists: http://cxf.apache.org/mailing-lists.html If you have feedback, questions or would like to get involved in the CXF project please join the mailing lists and let us know your thoughts. The Apache CXF Team http://cxf.apache.org/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com signature.asc Description: This is a digitally signed message part.
Re: Activators for individual frontends
On 20/12/11 19:04, Daniel Kulp wrote: On Monday, December 19, 2011 10:35:07 AM Sergey Beryozkin wrote: Hi KL, All, On 16/12/11 22:34, K Fung wrote: In 2.5.2 on later we can think of introducing an activator into the jaxrs frontend so that it can discover custom Applications and providers registered as OSGI services Perhaps we should have a discussion on a separate thread to discuss how you envision seeing this? In particular, I'm wondering what's the baseline/environment you think this would be running. For example, right now there is no activator in the CXF JAX-RS bundle but what are the consequence of an activator in 2.5.2+ - can it be disabled? Do we rely on the OSGI HttpService or do we use a built-in Jetty? Can we support both? I guess you can see that I'm pretty interested in this topic :-) I was thinking earlier on that CXF can get a master/root activator which will provide BundleContext, etc to individual activators which say JAXWS and JAXRS frontends may offer; I think these activators will not act as independent activators on its own, they will simply be able to react to the information (BundleContext for ex) that the actual root activator may offer. Well, we could have the current activator grab a list out of the current bundle (cxf-bundle) of other activators to instantiate and call. For example, we could have a META-INF/cxf/osgi-activators.txt that is created during bundling (shade can do it) that the OSGiExtensionLocator thing will grab and then call the start/stop on it. Super, this looks like a good way to start We'd only need to look in the current bundle. Once we split into modules, the core bundle would not have that and thus wouldn't do anything, but the jaxrs bundle could properly define it's own activator in it's manifest.This wouldn't be hard to do. Yea; Cheers, Sergey Dan For example, in case of JAX-RS, this sub-activator will probably register ServiceTrackers and start listening for (JAX-RS) Application interfaces and then will create an endpoint by using HttpService or embedded Jetty, something like that What do you think ? Sergey
