CXF Apache: null pointer problem with my reponse
Hello,
I have a big problem with reception of a CXF answer and i'm looking for a
solution since many days. In my aut-generated classes, i have a null
pointer.
I use "apache-cxf-2.1.2". From a wsdl file, with https, i've auto-generated
many classes with wsdl2java. My application send a request to LDAP server
with webservice (using https). Communication work fine: my request is sent
and web service send me a correct response. I think my problem is in these
auto-generated classes with wsdl2java, because at the reception of the
response, inside of the response class (a bean), the pointer to another
class (an other bean), is null and my response (in log) is correct and well
formed (like in util soapUI).
For more information, here is my request xml:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:urn="urn:ldaplogonwsdl">
user
pwd
Here is my response:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";>
SUCCESS
1
user
name
surname
[EMAIL PROTECTED]
111
test
Here is the auto-generated code with wsdl2java for response:
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "connectResponseType", propOrder = {
"_return"
})
public class ConnectResponseType {
@XmlElement(name = "return", required = true)
protected ConnectedUser _return;
public ConnectedUser getReturn() {
return _return;
}
public void setReturn(ConnectedUser value) {
this._return = value;
}
}
The "_return" pointer has value null at response time.
Here is my call code:
URL wsdlURL = new URL("https://adress/ldaplogon?wsdl";);
QName SERVICE_NAME = new QName("urn:ldaplogonwsdl", "ldaplogonwsdl");
Ldaplogonwsdl ss = new Ldaplogonwsdl(wsdlURL, SERVICE_NAME);
LdaplogonwsdlPortType port = ss.getLdaplogonwsdlPort();
org.apache.cxf.endpoint.Client client = ClientProxy.getClient(port);
HTTPConduit httpConduit = (HTTPConduit) client.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("SSL");
httpConduit.setTlsClientParameters(tlsParams);
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(32000);
httpConduit.setClient(httpClientPolicy);
ConnectRequestType _connect_parameters = new ConnectRequestType();
User myUser = new User();
myUser.setLogin(username);
myUser.setPwd(password);
_connect_parameters.setUser(myUser);
ConnectResponseType _connect__return = port.connect(_connect_parameters);
System.out.println("_connect__return=" + _connect__return);
ConnectedUser connectedUser = (ConnectedUser) _connect__return.getReturn();
And connectedUser has value null.
Please, could you help me?
Thank you in advance,
Vincent
--
View this message in context:
http://www.nabble.com/CXF-Apache%3A-null-pointer-problem-with-my-reponse-tp19857308p19857308.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Proposal for a new JMS configuration for CXF
Daniel Kulp wrote: - ensuring the multiplicity of conduit beans configured alongside a failover selector is consistent with the set of ports defined in the WSDL, as the CXF static failover strategy is based on burning the alternate ports into a multi-port service definition in the WSDL. Well, this COULD actually remove that limitation. A FailoverSelector could have a bunch of conduits configured via configuration (like roundrobin) and failover from one to the other. Thus, the failover stuff would work for code first cases much better. If the FailoverSelector doesn't have any conduits coming in from spring, it could use the multi-port strategy it currently uses. Yeah, that makes sense all right in the particular case of the alternate addresses being taken from the WSDL. Encoding the alternate addresses in s versus configuring the same info in the would be similar strategies in the sense that in both cases the cluster is statically defined (i.e. of fixed size and membership, modulo changes to WSDL or config, which would generally require a restart/refresh in the client). But I also had in mind the case where the addresses are retrieved dynamically from some external agency, such as a registry service. I've built an example of this approach in another project which is layered over CXF. In this case the cluster is dynamically assembled, and no specific addressing info is statically burned into the client's WSDL (or config). Now in this latter case, there's a slightly different possible use-case for the wiring. Instead of using this mechanism to inject the target addresses (and other config) for individual conduits, we could instead have a place-holder "abstract" conduit bean containing only non-address config to be used for any concrete conduit instance (of a particular type) created for this proxy over its lifetime, including any failover events. So for example, suppose I wanted to ensure that AllowChunking was always set to false for a particular proxy because I suspect there's a bug in the server-side stack's support for HTTP chunking (real-life example from our own in-house interop testing). And say I'm using my registry-mediated faliover strategy. In this case it would be neat to just do something like: http://apache.org/hw}MyPort";> http://apache.org/hw}MyPort.http-conduit"; abstract="true"> ... and have the AllowChunking="false" applied to *any* HTTP conduit created for this proxy over its lifetime. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
[DOSGi] patch with further pieces for CXD-1836
Hi all, I've attached another patch to https://issues.apache.org/jira/browse/CXF-1836 that implements the required Service Properties on the DistributionProvider service. The patch is called DistributionProvider-properties.patch and a direct link to it can be found here: https://issues.apache.org/jira/secure/attachment/12391635/DistributionProvider-properties.patch It would be great if someone could apply the patch. Thanks! David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: svn commit: r702443 - in /cxf/branches/2.1.x-fixes: ./ api/ api/src/main/java/org/apache/cxf/jca/ api/src/main/java/org/apache/cxf/jca/outbound/ distribution/src/main/release/samples/integration/j
Quick question: On Tuesday 07 October 2008, [EMAIL PROTECTED] wrote: > Modified: cxf/branches/2.1.x-fixes/api/pom.xml > > + org.apache.geronimo.specs > + geronimo-j2ee-connector_1.5_spec > + Could this have provided so we don't ship this and have it added to the class path and such? Your J2EE container should already provide that so we shouldn't need to ship it. -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [DOSGi] patch with further pieces for CXD-1836
Thanks David, patch applied. /Eoghan David Bosschaert wrote: Hi all, I've attached another patch to https://issues.apache.org/jira/browse/CXF-1836 that implements the required Service Properties on the DistributionProvider service. The patch is called DistributionProvider-properties.patch and a direct link to it can be found here: https://issues.apache.org/jira/secure/attachment/12391635/DistributionProvider-properties.patch It would be great if someone could apply the patch. Thanks! David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: svn commit: r702443 - in /cxf/branches/2.1.x-fixes: ./ api/ api/src/main/java/org/apache/cxf/jca/ api/src/main/java/org/apache/cxf/jca/outbound/ distribution/src/main/release/samples/integration/j
Yes, we should not ship this jar, I will fix it in my next commit. Thanks, Willem Daniel Kulp wrote: Quick question: On Tuesday 07 October 2008, [EMAIL PROTECTED] wrote: Modified: cxf/branches/2.1.x-fixes/api/pom.xml +org.apache.geronimo.specs +geronimo-j2ee-connector_1.5_spec + Could this have provided so we don't ship this and have it added to the class path and such? Your J2EE container should already provide that so we shouldn't need to ship it.
Re: CXF Apache: null pointer problem with my reponse
Most likely, the response message is actually wrong according to the
schema.
The request message makes it look like the element form of the schema is
set to "unqualified". The "urn:connect" element is qualified properly,
but the child elements (user, etc...) are not namespace qualified.
The response message, however, puts all the elements into
the "urn:ldaplogonwsdl" namespace. If the schema says that the xml
should be unqualified, then the message is wrong. CXF will not know how
to deserialize it.
Dan
On Tuesday 07 October 2008, vincerix wrote:
> Hello,
>
> I have a big problem with reception of a CXF answer and i'm looking
> for a solution since many days. In my aut-generated classes, i have a
> null pointer.
> I use "apache-cxf-2.1.2". From a wsdl file, with https, i've
> auto-generated many classes with wsdl2java. My application send a
> request to LDAP server with webservice (using https). Communication
> work fine: my request is sent and web service send me a correct
> response. I think my problem is in these auto-generated classes with
> wsdl2java, because at the reception of the response, inside of the
> response class (a bean), the pointer to another class (an other bean),
> is null and my response (in log) is correct and well formed (like in
> util soapUI).
>
> For more information, here is my request xml:
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:urn="urn:ldaplogonwsdl">
>
>
>
>
>
> user
> pwd
>
>
>
>
>
> Here is my response:
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";>
>
>
>
> SUCCESS
> 1
> user
> name
> surname
> [EMAIL PROTECTED]
>
>111
>test
>
>
>
>
>
>
> Here is the auto-generated code with wsdl2java for response:
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "connectResponseType", propOrder = {
> "_return"
> })
>
> public class ConnectResponseType {
>
> @XmlElement(name = "return", required = true)
> protected ConnectedUser _return;
>
> public ConnectedUser getReturn() {
> return _return;
> }
>
> public void setReturn(ConnectedUser value) {
> this._return = value;
> }
> }
>
> The "_return" pointer has value null at response time.
>
> Here is my call code:
> URL wsdlURL = new URL("https://adress/ldaplogon?wsdl";);
> QName SERVICE_NAME = new QName("urn:ldaplogonwsdl", "ldaplogonwsdl");
> Ldaplogonwsdl ss = new Ldaplogonwsdl(wsdlURL, SERVICE_NAME);
> LdaplogonwsdlPortType port = ss.getLdaplogonwsdlPort();
> org.apache.cxf.endpoint.Client client = ClientProxy.getClient(port);
> HTTPConduit httpConduit = (HTTPConduit) client.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> httpConduit.setTlsClientParameters(tlsParams);
> HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
> httpClientPolicy.setConnectionTimeout(36000);
> httpClientPolicy.setAllowChunking(false);
> httpClientPolicy.setReceiveTimeout(32000);
> httpConduit.setClient(httpClientPolicy);
> ConnectRequestType _connect_parameters = new ConnectRequestType();
> User myUser = new User();
> myUser.setLogin(username);
> myUser.setPwd(password);
> _connect_parameters.setUser(myUser);
> ConnectResponseType _connect__return =
> port.connect(_connect_parameters);
> System.out.println("_connect__return=" + _connect__return);
> ConnectedUser connectedUser = (ConnectedUser)
> _connect__return.getReturn();
>
> And connectedUser has value null.
> Please, could you help me?
>
> Thank you in advance,
> Vincent
--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: How to handle a configuration problem generally in CXF code
I'd definitely prefer if the excpetion was on of the I18N things. A LARGE chunk of our users are actually from China. According to google analytics, China is #2 after the US. It's definitely important to keep the option open to make this stuff localizable. ESPECIALLY for configuration things where a non-developer might need to make changes. More "admin" like tasks. Note: if you have a Logger, you already have the bundle. The i18n message can take the Logger instead of the bundle. Dan On Monday 06 October 2008, Christian Schneider wrote: > Hi all, > > when there is a problem with the configuration i currently throw a > simple RuntimeException. I think this can be handled better. > I have found a class ConfigurationException but it only accepts a > message as i18 Message. Should this class be used? I do not like that > much that it always needs a resource definition. > Is internationalization for config errors that usefull? Whenever I got > a german exception I had much problems trying to google for it. So I > personally like english exceptions. > Another possibility would be to throw an AssertionError. As it is for > example an assertion that a certain property is not null. > > Any ideas? > > Greetings > > Christian -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: How to handle a configuration problem generally in CXF code
Hi Dan,
I have included a first exception. It looks like this:
org.apache.cxf.common.i18n.Message msg = new
org.apache.cxf.common.i18n.Message("INSUFFICIENT_CONFIGURATION_CONDUIT",
LOG, name);
throw new ConfigurationException(msg);
This looks extremly ugly as Message is already imported either as a CXF
message or a JMS message. It will be even uglier when the code formatter
has done its work.
Is it necessary that the Message is built with new? Can´t we simply do
something like this:
throw new ConfigurationException("INSUFFICIENT_CONFIGURATION_CONDUIT",
LOG, name);
We could add this Constructor to UncheckedException.
Greetings
Christian
Daniel Kulp schrieb:
I'd definitely prefer if the excpetion was on of the I18N things. A
LARGE chunk of our users are actually from China. According to google
analytics, China is #2 after the US. It's definitely important to keep
the option open to make this stuff localizable. ESPECIALLY for
configuration things where a non-developer might need to make changes.
More "admin" like tasks.
Note: if you have a Logger, you already have the bundle. The i18n
message can take the Logger instead of the bundle.
Dan
--
Christian Schneider
---
http://www.liquid-reality.de
Re: How to handle a configuration problem generally in CXF code
Yes, it was good that James Mao created a CXF-zh list, with so many Chinese committers, developing a Chinese language CXF community was a huge bonus for us that the other web service stacks didn't have. Doing Google blog searches, we do seem to lag in Japan though because the Axis 1.x web site is translated into Japanese. Glen dkulp wrote: > > > I'd definitely prefer if the excpetion was on of the I18N things. A > LARGE chunk of our users are actually from China. According to google > analytics, China is #2 after the US. It's definitely important to keep > the option open to make this stuff localizable. ESPECIALLY for > configuration things where a non-developer might need to make changes. > More "admin" like tasks. > > Note: if you have a Logger, you already have the bundle. The i18n > message can take the Logger instead of the bundle. > > Dan > > > On Monday 06 October 2008, Christian Schneider wrote: >> Hi all, >> >> when there is a problem with the configuration i currently throw a >> simple RuntimeException. I think this can be handled better. >> I have found a class ConfigurationException but it only accepts a >> message as i18 Message. Should this class be used? I do not like that >> much that it always needs a resource definition. >> Is internationalization for config errors that usefull? Whenever I got >> a german exception I had much problems trying to google for it. So I >> personally like english exceptions. >> Another possibility would be to throw an AssertionError. As it is for >> example an assertion that a certain property is not null. >> >> Any ideas? >> >> Greetings >> >> Christian > > > > -- > J. Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > -- View this message in context: http://www.nabble.com/How-to-handle-a-configuration-problem-generally-in-CXF-code-tp19847560p19867935.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to handle a configuration problem generally in CXF code
I'm +1 to the constructor. I find the new-ing of messages to be a pain.
On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider <[EMAIL PROTECTED]
> wrote:
> Hi Dan,
>
> I have included a first exception. It looks like this:
>
> org.apache.cxf.common.i18n.Message msg = new
> org.apache.cxf.common.i18n.Message("INSUFFICIENT_CONFIGURATION_CONDUIT",
> LOG, name);
> throw new ConfigurationException(msg);
>
> This looks extremly ugly as Message is already imported either as a CXF
> message or a JMS message. It will be even uglier when the code formatter has
> done its work.
>
> Is it necessary that the Message is built with new? Can´t we simply do
> something like this:
> throw new ConfigurationException("INSUFFICIENT_CONFIGURATION_CONDUIT", LOG,
> name);
>
> We could add this Constructor to UncheckedException.
>
> Greetings
>
> Christian
>
>
> Daniel Kulp schrieb:
>
>> I'd definitely prefer if the excpetion was on of the I18N things. A
>> LARGE chunk of our users are actually from China. According to google
>> analytics, China is #2 after the US. It's definitely important to keep the
>> option open to make this stuff localizable. ESPECIALLY for configuration
>> things where a non-developer might need to make changes. More "admin" like
>> tasks.
>> Note: if you have a Logger, you already have the bundle. The i18n
>> message can take the Logger instead of the bundle.
>>
>> Dan
>>
>>
>>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
Re: svn commit: r702656 - in /cxf/trunk/rt/transports/jms/src: main/java/org/apache/cxf/transport/jms/ test/java/org/apache/cxf/transport/jms/
Christian, usage of "you" is somewhat uncommon in error messages, wouldn't you say? Although I think it's more permissable for the first two messages below, because you're asking a question, but normally the latter two should avoid "you". Glen cschneider-2 wrote: > > DISPATCH_FAILURE_MSG = Dispatch of incoming JMS request failed > +INSUFFICIENT_CONFIGURATION_CONDUIT = Insufficient configuration for > Conduit. Did you configure a and set the > jndiConnectionFactoryName ? Be sure to configure a ... and set the jndiConnectionFactoryName. > +INSUFFICIENT_CONFIGURATION_DESTINATION = Insufficient configuration for > Destination. Did you configure a and set > the jndiConnectionFactoryName ? Be sure to configure a ... and set the jndiConnectionFactoryName. > +JMSCONFIGFEATURE_ONLY_JMS = You can only use JMSConfigFeature with the > jms transport JMSConfigFeature can only be used with jms transport. > +JMSCONFIG_REQUIRED = You have to set the property jmsConfig Property jmsConfig has to be set -or- was not set -or- must be set -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r702656---in--cxf-trunk-rt-transports-jms-src%3A-main-java-org-apache-cxf-transport-jms--test-java-org-apache-cxf-transport-jms--tp19869512p19869512.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: svn commit: r702656 - in /cxf/trunk/rt/transports/jms/src: main/java/org/apache/cxf/transport/jms/ test/java/org/apache/cxf/transport/jms/
Well, I've always liked technical writing that uses 'you' to avoid the passive. Since this is a config error, it seems to me to have an audience that can handle a you. But that's just my opinion. On Tue, Oct 7, 2008 at 7:25 PM, Glen Mazza <[EMAIL PROTECTED]> wrote: > > Christian, usage of "you" is somewhat uncommon in error messages, wouldn't > you say? Although I think it's more permissable for the first two messages > below, because you're asking a question, but normally the latter two should > avoid "you". > > Glen > > cschneider-2 wrote: > > > > DISPATCH_FAILURE_MSG = Dispatch of incoming JMS request failed > > +INSUFFICIENT_CONFIGURATION_CONDUIT = Insufficient configuration for > > Conduit. Did you configure a and set the > > jndiConnectionFactoryName ? > > Be sure to configure a ... and set the jndiConnectionFactoryName. > > > +INSUFFICIENT_CONFIGURATION_DESTINATION = Insufficient configuration for > > Destination. Did you configure a and set > > the jndiConnectionFactoryName ? > > Be sure to configure a ... and set the jndiConnectionFactoryName. > > > +JMSCONFIGFEATURE_ONLY_JMS = You can only use JMSConfigFeature with the > > jms transport > > JMSConfigFeature can only be used with jms transport. > > > +JMSCONFIG_REQUIRED = You have to set the property jmsConfig > > Property jmsConfig has to be set -or- was not set -or- must be set > > -- > View this message in context: > http://www.nabble.com/Re%3A-svn-commit%3A-r702656---in--cxf-trunk-rt-transports-jms-src%3A-main-java-org-apache-cxf-transport-jms--test-java-org-apache-cxf-transport-jms--tp19869512p19869512.html > Sent from the cxf-dev mailing list archive at Nabble.com. > >
Re: svn commit: r702656 - in /cxf/trunk/rt/transports/jms/src: main/java/org/apache/cxf/transport/jms/ test/java/org/apache/cxf/transport/jms/
I like the use of "you" also. It avoids needlessly convoluted syntax and it makes the messages a little more personal. That said consistency is king. How about: Configure a and set the jndiConnectionFactoryName. The jmsConfig property is required. Benson's suggestion for the second error message is perfect. > On Tue, 2008-10-07 at 19:28 -0400, Benson Margulies wrote: > Well, I've always liked technical writing that uses 'you' to avoid the > passive. Since this is a config error, it seems to me to have an audience > that can handle a you. But that's just my opinion. > > On Tue, Oct 7, 2008 at 7:25 PM, Glen Mazza <[EMAIL PROTECTED]> wrote: > > > > > Christian, usage of "you" is somewhat uncommon in error messages, wouldn't > > you say? Although I think it's more permissable for the first two messages > > below, because you're asking a question, but normally the latter two should > > avoid "you". > > > > Glen > > > > cschneider-2 wrote: > > > > > > DISPATCH_FAILURE_MSG = Dispatch of incoming JMS request failed > > > +INSUFFICIENT_CONFIGURATION_CONDUIT = Insufficient configuration for > > > Conduit. Did you configure a and set the > > > jndiConnectionFactoryName ? > > > > Be sure to configure a ... and set the jndiConnectionFactoryName. > > > > > +INSUFFICIENT_CONFIGURATION_DESTINATION = Insufficient configuration for > > > Destination. Did you configure a and set > > > the jndiConnectionFactoryName ? > > > > Be sure to configure a ... and set the jndiConnectionFactoryName. > > > > > +JMSCONFIGFEATURE_ONLY_JMS = You can only use JMSConfigFeature with the > > > jms transport > > > > JMSConfigFeature can only be used with jms transport. > > > > > +JMSCONFIG_REQUIRED = You have to set the property jmsConfig > > > > Property jmsConfig has to be set -or- was not set -or- must be set > > > > -- > > View this message in context: > > http://www.nabble.com/Re%3A-svn-commit%3A-r702656---in--cxf-trunk-rt-transports-jms-src%3A-main-java-org-apache-cxf-transport-jms--test-java-org-apache-cxf-transport-jms--tp19869512p19869512.html > > Sent from the cxf-dev mailing list archive at Nabble.com. > > > >
Re: svn commit: r702656 - in /cxf/trunk/rt/transports/jms/src: main/java/org/apache/cxf/transport/jms/ test/java/org/apache/cxf/transport/jms/
Technical documentation, yes, I use "you" all the time there. Windows- and browser-error messages, frequently yes also, because you're trying to be warm and friendly to a non-technical user. Lower-level Oracle database error[1] or operating system messages, I would say "you" looks strange, and irritating to the reader. I guess CXF is in a grey zone between the two--but since these are config errors, perhaps OK to use "you". Sometimes firmness/coldness in error messages gives the user a more comfortable feeling about the robustness of the application he/she are using. Oracle probably wouldn't seem as solid a database if it used "you" in its system-level error messages. It is similar to the situation with automated voices. While setting your voicemail account or listening to your cell phone messages, a pleasant female voice is normally used, but in prerecorded emergency messages over a loudspeaker (say for a fire alarm), a male voice is used because it makes people more comfortable in that scenario. Glen [1] http://www.oracle.com/pls/db92/db92.error_search Benson Margulies-4 wrote: > > Well, I've always liked technical writing that uses 'you' to avoid the > passive. Since this is a config error, it seems to me to have an audience > that can handle a you. But that's just my opinion. > > On Tue, Oct 7, 2008 at 7:25 PM, Glen Mazza <[EMAIL PROTECTED]> wrote: > >> >> Christian, usage of "you" is somewhat uncommon in error messages, >> wouldn't >> you say? Although I think it's more permissable for the first two >> messages >> below, because you're asking a question, but normally the latter two >> should >> avoid "you". >> >> Glen >> >> cschneider-2 wrote: >> > >> > DISPATCH_FAILURE_MSG = Dispatch of incoming JMS request failed >> > +INSUFFICIENT_CONFIGURATION_CONDUIT = Insufficient configuration for >> > Conduit. Did you configure a and set the >> > jndiConnectionFactoryName ? >> >> Be sure to configure a ... and set the jndiConnectionFactoryName. >> >> > +INSUFFICIENT_CONFIGURATION_DESTINATION = Insufficient configuration >> for >> > Destination. Did you configure a and set >> > the jndiConnectionFactoryName ? >> >> Be sure to configure a ... and set the jndiConnectionFactoryName. >> >> > +JMSCONFIGFEATURE_ONLY_JMS = You can only use JMSConfigFeature with the >> > jms transport >> >> JMSConfigFeature can only be used with jms transport. >> >> > +JMSCONFIG_REQUIRED = You have to set the property jmsConfig >> >> Property jmsConfig has to be set -or- was not set -or- must be set >> >> -- >> View this message in context: >> http://www.nabble.com/Re%3A-svn-commit%3A-r702656---in--cxf-trunk-rt-transports-jms-src%3A-main-java-org-apache-cxf-transport-jms--test-java-org-apache-cxf-transport-jms--tp19869512p19869512.html >> Sent from the cxf-dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r702656---in--cxf-trunk-rt-transports-jms-src%3A-main-java-org-apache-cxf-transport-jms--test-java-org-apache-cxf-transport-jms--tp19869512p19869996.html Sent from the cxf-dev mailing list archive at Nabble.com.
wsa:Action interop issue
Hi,
I ran into an interesting interop issue with wsa:Action between CXF
and JAX-WS RI (2.1.4). I have a simple service class, no sei, no
@Action annotations, something like:
@WebService
@Addressing
class Calculator {
public int add(in n1, in2) {
return n1 + n2;
}
}
CXF generated the following wsdl:operation for the "add" method:
JAX-WS RI generated the following wsdl:operation for the same method:
http://geronimo.apache.org/calculator/Calculator/addRequest"/>
Now, the wsa:Action for the CXF generated wsdl:operation would be
"http://geronimo.apache.org/calculator/Calculator/add";, and for RI is
"http://geronimo.apache.org/calculator/Calculator/addRequest";. Since
the wsa:Action are slightly different that might create an interop
problem. I couldn't really find that much info on this issue in the
JAX-WS spec but I assume if the @Action is not specified the default
algorithm (as defined in the WS-A spec) should be used. The wsa:Action
generated by the RI conforms to that algorithm.
So I think the CXF should either not add the "name" attribute to
wsdl:input/output messages or add in an explicit wsa:Action attribute
as the RI does.
Thoughts?
Jarek
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
With a strong reation from opensource community, SpringSource seems to have taken a major turnaround. Rod Johnson, in a recent post on SpringSource has announced modifications in the Spring enterprise maintenance policy. More on this link: http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/ http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/ I wonder why would one need a seprate project like 'freeSpring' now ??? Cheers dkulp wrote: > > > Looks like a project has already popped up to support spring: > http://freespring.org/ > > Dan > > -- View this message in context: http://www.nabble.com/Potential-impact-of-SpringSource-Enterprise-Maintenance-Policy-on-CXF-tp19833297p19872906.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
It seems it's not needed anymore. On Wed, Oct 8, 2008 at 8:13 AM, CXF Explorer <[EMAIL PROTECTED]> wrote: > > With a strong reation from opensource community, SpringSource seems to have > taken a major turnaround. Rod Johnson, in a recent post on SpringSource has > announced modifications in the Spring enterprise maintenance policy. More on > this link: > > http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/ > http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/ > > I wonder why would one need a seprate project like 'freeSpring' now ??? > > Cheers > > > > dkulp wrote: >> >> >> Looks like a project has already popped up to support spring: >> http://freespring.org/ >> >> Dan >> >> > -- > View this message in context: > http://www.nabble.com/Potential-impact-of-SpringSource-Enterprise-Maintenance-Policy-on-CXF-tp19833297p19872906.html > Sent from the cxf-dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com
