Re: enumeration values are alphabetized
On Tue February 23 2010 11:50:18 am Matt wrote: > We are using WSDLToJava to build a web service. We have a simple type that > is restricted to an enumeration. In the xml we define the order of the > enumeration values. After the WSDLToJava the enumeration values are > alphabetized in the .java file. Is there a way to turn tell CXF to leave > the order alone? This is really a question for the JAXB folks. I don't see anything in the specs that provides a customization to force this.You'll probably need to ask on their forums at jaxb.dev.java.net. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to have JAXB SchemaCompiler generating code for schema elements
Hi Dan This is useful, I may play with it later on, and the hint to do with causing anonymous types be created is something we can advise to code-first users...I needed classes created from element for wadl:representation/@element values be resolved easier but I also ended up creating a map of schema element names to type names which I'm using as a last resort to actually resolve wadl:representation/@element... thanks, Sergey - Original Message - From: "Daniel Kulp" To: Cc: "Sergey Beryozkin" Sent: Wednesday, February 24, 2010 5:08 PM Subject: Re: How to have JAXB SchemaCompiler generating code for schema elements Since you are mucking in code, if you create a binding customization file that has a jaxb:globalBindings element with generateElementClass="true" attribute, it will generate a class for the element. It's kind of an ugly class though and possibly not really usable. Dan On Tue February 23 2010 12:02:59 pm Sergey Beryozkin wrote: Hi I've started working on the wadl-first code generation (well not quite the wadl-first one yet...) and I'm using the code I've 'borrowed' from the DynamicClientFactory from cxf-rt-databinding-jaxb. At the moment I can only see files corresponding to schema types being generated. How can I configure SchemaCompiler to generate the code for xs:elements ? thanks, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to have JAXB SchemaCompiler generating code for schema elements
Since you are mucking in code, if you create a binding customization file that has a jaxb:globalBindings element with generateElementClass="true" attribute, it will generate a class for the element. It's kind of an ugly class though and possibly not really usable. Dan On Tue February 23 2010 12:02:59 pm Sergey Beryozkin wrote: > Hi > > I've started working on the wadl-first code generation (well not quite the > wadl-first one yet...) and I'm using the code I've 'borrowed' from the > DynamicClientFactory from cxf-rt-databinding-jaxb. At the moment I can > only see files corresponding to schema types being generated. How can I > configure SchemaCompiler to generate the code for xs:elements ? > > thanks, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to have JAXB SchemaCompiler generating code for schema elements
On Wed February 24 2010 5:42:31 am Sergey Beryozkin wrote: > Now, the compiler takes care of elements with anonymous complex types, but > ignores elements referring to public complex types which probably makes > sense but what does not make sense is that when generating the types only > in this latter case it omits the @XmlRootElement. > > It is probably not quite that straightforward but it's kind of limiting > nonetheless, example, code-first - to - wadl/wsdl -back to code does not > produce the same result, in other words, if we start from a source having > types with @XmlRootElement the produced schema section will have elements > referring to public complex types and now when we try to get back to the > code we have types with no @XmlRootElements... Probably not a big deal for > JAXRS-based services given that users can configure a JAXBElementProvider > use JAXBElement under the hood and for real wadl-first cases we can > recommend users doing elements with anonymous types if needed. > > Next question : when JAXBContext generates a schema, is it possible to > configure it to optionally use anonymoos types, may work ok for cases when > types are not reused across multiple diff elements... You would need to add an @XmlType(name="") annotation to the type that also has the @XmlRootElement annotation on it. That creates and element for it, but not a type so it ends up being anonymous. Dan > > cheers, Sergey > - Original Message - > From: Sergey Beryozkin > To: dev@cxf.apache.org > Sent: Tuesday, February 23, 2010 5:02 PM > Subject: How to have JAXB SchemaCompiler generating code for schema > elements > > > Hi > > I've started working on the wadl-first code generation (well not quite > the wadl-first one yet...) and I'm using the code I've 'borrowed' from the > DynamicClientFactory from cxf-rt-databinding-jaxb. At the moment I can > only see files corresponding to schema types being generated. How can I > configure SchemaCompiler to generate the code for xs:elements ? > > thanks, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Excessive SSL warnings in logs
Are you sure you are using Log4J for CXF logging? (aka: followed instructions at: http://cxf.apache.org/docs/debugging-and-logging.html to turn on log4j) The formatting of that log looks more like the default j.u.l logging in which case you would need to configure a logging.properties file for j.u.l. Dan On Wed February 24 2010 12:08:17 am Naresh Tallapelli wrote: > I am using log4j to log the statements into a file. But when i add > log4j.logger.org.apache.cxf. > > > transport.https.SSLUtils=WARN > > statement in log4j.properties also it did not work. All the below mentioned > statements are getting logged into a file. Please let me know is there any > other way. > > Thank you, > Naresh. > > On Wed, Feb 24, 2010 at 1:58 AM, Tsering Shrestha wrote: > > Assuming u are using log4j, wouldn't > > log4j.logger.org.apache.cxf.transport.https.SSLUtils=WARN > > in the log4j.properties file not work? > > (I am assuming that org.apache.cxf.transport.https.SSLUtils is not the > > class which prints the soap messages) > > > > -Original Message- > > From: Naresh Tallapelli [mailto:naresh.tallape...@gmail.com] > > Sent: Tuesday, February 23, 2010 9:10 AM > > To: us...@cxf.apache.org; dev@cxf.apache.org > > Subject: Excessive SSL warnings in logs > > > > Hi All, > > > > I am using cxf -2.1.2 in my web service application. I have enabled > > logging interceptors for all the operations. And when web service client > > sends any request to the server, following messages are getting logged > > all the times, > > > > > > Jun 22, 2009 2:55:17 PM > > org.apache.cxf.service.factory.ReflectionServiceFactoryBean > > buildServiceFromClass > > Jun 22, 2009 2:55:17 PM org.apache.cxf.transport.https.SSLUtils > > getCiphersuites > > INFO: The cipher suites have not been configured, falling back to cipher > > suite filters. > > Jun 22, 2009 2:55:17 PM org.apache.cxf.transport.https.SSLUtils > > getCiphersuites > > INFO: The cipher suite filters have not been configured, falling back to > > default filters. > > Jun 22, 2009 2:55:17 PM org.apache.cxf.transport.https.SSLUtils > > getCiphersFromList > > INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, > > SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, > > SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, > > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, > > SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, > > SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, > > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, > > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, > > TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, > > TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, > > TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, > > TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, > > TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. > > Jun 22, 2009 2:55:17 PM > > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose > > > > Is there any way to supres these messages ?. I just wan to print only > > soap messages in the logs. > > > > Any help will be much appreciated. > > > > Thank you, > > Naresh. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to have JAXB SchemaCompiler generating code for schema elements
Now, the compiler takes care of elements with anonymous complex types, but ignores elements referring to public complex types which probably makes sense but what does not make sense is that when generating the types only in this latter case it omits the @XmlRootElement. It is probably not quite that straightforward but it's kind of limiting nonetheless, example, code-first - to - wadl/wsdl -back to code does not produce the same result, in other words, if we start from a source having types with @XmlRootElement the produced schema section will have elements referring to public complex types and now when we try to get back to the code we have types with no @XmlRootElements... Probably not a big deal for JAXRS-based services given that users can configure a JAXBElementProvider use JAXBElement under the hood and for real wadl-first cases we can recommend users doing elements with anonymous types if needed. Next question : when JAXBContext generates a schema, is it possible to configure it to optionally use anonymoos types, may work ok for cases when types are not reused across multiple diff elements... cheers, Sergey - Original Message - From: Sergey Beryozkin To: dev@cxf.apache.org Sent: Tuesday, February 23, 2010 5:02 PM Subject: How to have JAXB SchemaCompiler generating code for schema elements Hi I've started working on the wadl-first code generation (well not quite the wadl-first one yet...) and I'm using the code I've 'borrowed' from the DynamicClientFactory from cxf-rt-databinding-jaxb. At the moment I can only see files corresponding to schema types being generated. How can I configure SchemaCompiler to generate the code for xs:elements ? thanks, Sergey
