Brice,
Thanks much, we will take a look at what you're doing... -dh ________________________________ From: Ruth, Brice D [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 21, 2006 9:27 AM To: [email protected] Subject: RE: [xfire-user] XFire using enum POJOs We don't do any schema first stuff. Yeah, this is a way of using JAXB, but not what we have. Here's what we have: <!-- Import XFire beans --> <import resource="classpath:org/codehaus/xfire/spring/xfire.xml"/> <!-- Initialize JAXB2 service factory --> <bean name="jaxbServiceFactory" class="org.codehaus.xfire.jaxb2.JaxbServiceFactory"> <constructor-arg ref="xfire.transportManager" /> </bean> <bean id="ewsng.TaskController.service" class="org.codehaus.xfire.spring.ServiceBean"> <property name="serviceBean" ref="ewsng.taskController" /> <property name="serviceFactory" ref="jaxbServiceFactory" /> <property name="faultHandlers"> <list> <ref bean="ewsng.faultHandler"/> </list> </property> </bean> The main thing here is that you're plugging in the JaxbServiceFactory (from jaxb2) - you can do this with a BeanPostProcessor as well (if you have no need to define the services individually): <!-- Define Jsr181 post-processor --> <bean id="xfire.WebAnnotations" class="org.codehaus.xfire.annotations.jsr181.Jsr181WebAnnotations" /> <bean id="Jsr181PostProcessor" class="org.codehaus.xfire.spring.Jsr181BeanPostProcessor"> <constructor-arg index="0" ref="xfire.WebAnnotations"/> <constructor-arg index="1" ref="jaxbServiceFactory" /> <constructor-arg index="2" ref="xfire.serviceRegistry" /> </bean> Of course, we're using JSR-181 annotations - YMMV with other deployment techniques. We don't do anything else (schema definition, etc.). This allows Aegis to delegate marshalling & WSDL generation to the underlying JAXB2 implementation. To your question of "why"? JAXB2 is identified as the "strategic standard" for xml marshalling/unmarshalling where I work, so we configured it because we thought we needed to. Now I'm glad we did - I didn't realize Aegis didn't natively support enums! Cheers, Brice -----Original Message----- From: Dave Hoffer [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 21, 2006 6:40 AM To: [email protected] Subject: RE: [xfire-user] XFire using enum POJOs Perhaps you could provide a simple summary of why you chose JAXB over Aegis. When we look at web services we see them as a means to an end. That is, we are Java developers and sometimes we need to communicate across processes and often between programming languages as well. So we look at web services as a way to pass objects when all code can't be in the same Java process. I really don't care how the java objects are formatted in XML and sent over SOAP, all I care is that it is quick and it works. It seems that many of the non-Aegis approaches, such as JAXB, make you start with defining XML schemas. Why is this desirable? Are there tools that let you start with the Java classes and generate the schemas? Perhaps the answer comes down to the issue of how we use web services verses the current trends, we use it in a RPC fashion, where the current trends seem to be to use it to pass XML documents around. Any thoughts or comments are welcome. -dh ________________________________ From: Brice Ruth [mailto:[EMAIL PROTECTED] Sent: Monday, November 20, 2006 10:19 PM To: [email protected] Subject: Re: [xfire-user] XFire using enum POJOs Ah, that could explain it - we're using JAXB2 instead of just Aegis. Cheers, Brice On 11/20/06, Dave Hoffer < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: Yeah, I don't even know what a CertPath is; it's not part of my object. I will look at JAXB...Thanks, -dh ________________________________ From: Dan Diephouse [mailto:[EMAIL PROTECTED] Sent: Monday, November 20, 2006 10:12 PM To: [email protected] Subject: Re: [xfire-user] XFire using enum POJOs It sounds like your object graph is somehow including java.security.cert.CertPath. I'm going to guess that you don't want to send the CertPath class over as an XML type (even if you did, XFire wouldn't allow it). Part of the problem may be that Aegis doesn't really support enums at the moment. However, if you switch to JAXB it should work no problem. See the docs for info on how to do that... Regards - Dan On 11/20/06, Dave Hoffer <[EMAIL PROTECTED]> wrote: Hum, I had an enum as a member of a pojo that was a parameter of a webservice method. When I tried to generate the wsdl I got: org.codehaus.xfire.XFireRuntimeException: Couldn't create type for property certificates on class java.security.cert.CertPath: Cannot create mapping for java.util.List, unspecified component type for property certificates When I changed this to a string it worked fine. Any ideas? (I figured that enums didn't work because they aren't beans.) -dh ________________________________________ From: Brice Ruth [mailto:[EMAIL PROTECTED] Sent: Monday, November 20, 2006 7:20 PM To: [email protected] Subject: Re: [xfire-user] XFire using enum POJOs It just works. Java 1.4 clients will be able to use 'em, too - the WSDL/XSD supports this natively. -Brice On 11/20/06, Dave Hoffer < [EMAIL PROTECTED]> wrote: If I have Java 1.5 pojos that contain enums, can I marshal these through the webservice as an enum?Is there a way to make these a bean so XFire treats these similar to any other bean?Enums are not listed as supported on http://xfire.codehaus.org/Aegis+Binding . If this can't be done this way, what is the recommended way of marshalling enums? -dh --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email -- Brice Ruth Software Engineer, Madison WI --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email <http://xircles.codehaus.org/manage_email> -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog -- Brice Ruth Software Engineer, Madison WI
