Hi James, Sorry, I was looking at the old jms.xsd file didn't update my snapshot in last few days, you are correct the type is changed to AddressType.
UseMessageIDAsCorrelationID and DurableSubscriberName belongs to ServerBehaviorPolicyType so they are at correct place. About the missing attributes, these are missing from the schema to give it more generality I think. However they will come from the sequence of properties element JMSNamingProperty in AddressType and can be named differently for different JMS brokers. You can remove those arguments in wsdl2service tool as these are now sort of runtime/generic properties. Regards, Ulhas Bhole -----Original Message----- From: James Mao [mailto:[EMAIL PROTECTED] Sent: 12 February 2007 13:05 To: [email protected] Subject: Re: JMS address wsdl extension Hi Ulhas, It's the \cxf\rt\transports\jms\src\main\resources\schemas\wsdl\jms.xsd Previous tools has it's own wsdl jms extensions, since we are re-using the wsdldefinition builder in the rt, we have to use the same schema. I really doubt if JMSAddressPolicyType still exist, i guess its been replaced by AddressType, But i found UseMessageIDAsCorrelationID and DurableSubscriberName is in java/org/apache/cxf/transport/jms/ServerBehaviorPolicyType.java not in AddressType, is it belongs to AddressType? "jndiProviderURL" is missing, which i think should also in AddressType. I just check the log, we do change the schema and jms lot. I mean if we really dont' need those attributes, then i'll remove the according arguments in wsdl2service tool. if we do need, then we have to add to the jms.xsd. and generate the correct wsdl extensions Thanks, James. Ulhas wrote: > Hi James, > > Can you be more specific on which schemas you are referring to? > > DestinationStyle is in JMSAddressPolicyType. > UseMessageIDAsCorrelationID & DurableSubscriberName are in > JMSServerBehaviorPolicyType. > > jndiProviderURL and initialContextFactory is missing which should have > been into JMSAddressPolicyType. I just had a look at the code in > JMSProviderHub which calls onto the JMSUtils.getInitialContext()and it > looks like these properties are no longer taken from the WSDL extensor > directly as attributes but come from the name-value pairs properties > in the WSDL Extensor. > > I did the initial work with JMS in celtix land but don't know all the > changes that happened in CXF so may be missing something but my > feeling is the changes must have been made to generalize the mechanism > of getting connection to work with differences in getting connection > brokers address via generic properties that goes into environment for > getting initialContext. > > Regards, > > Ulhas Bhole > > -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: 12 February 2007 02:13 > To: [email protected] > Subject: JMS address wsdl extension > > Hi, > > I'm working on porting wsdl2service from tools to tools2, i have > reused the wsdldefinition builder in the rt. > But i found that the jms extension schema is not consist with the one > in tools. > > Several address extensions are lost. e.g DestinationStyle > jndiProviderURL initialContextFactory UseMessageIDAsCorrelationID > DurableSubscriberName > > > I'm not jms expert, so i would like ask our jms guru, if those > attributes are needed any more? > > > BTW, the namespace in jms.xsd is http://cxf.apache.org/transports/jms, > and we use the jms.xjb to change the namespace to > http://cxf.apache.org/transports/jms > > Is it necessary? why not use http://cxf.apache.org/transports/jms > directly in jms.xsd? > > > Thanks, > James. > > >
