You should be able to start from the annotated classes without any problems. See my other reply in this thread.
On 11/16/06, moraleslos <[EMAIL PROTECTED]> wrote:
Thanks. I think I understand the concept now. However, when looking at the wsdl_first example, seems like everything is driven from the wsdl-- the classes, POJO types, etc. My situation is almost the opposite. I already have my domain model with Jaxb2 annotations. Therefore all of the <wsdl_types> defined in the wsdl example is unnecessary for me (I think). So I assume the only thing I need to do is create a simpler WSDL-- the portType, binding and service-- and create the actual Web service similar to PersonImpl from the example. Am I on the money with this? -los gnodet wrote: > > On 11/16/06, Anders Hammar <[EMAIL PROTECTED]> wrote: >> >> Ok, I think there could be some confusion here. I'm not 100% sure as I'm >> struggling with a simular topic, but I do think I have a grip of it. >> >> What your write below is not the correct way to go. You were right on >> track >> earlier on. In your case, if I understand you, you want to read a file >> and >> persist the information based on a specific object model. I think you >> were >> thinking correctly earlier on, where you stated that you would use a file >> binding component to read the file, then through an XSLT service engine >> to >> transform the information to the XML format possible to unmarshal into >> your >> pojos, and then to a jsr181 service. >> I'd like someone who really knows smx to confirm this, but what you need >> to >> do is use (for instance) jaxb2 annotations on your pojos for your object >> model (you specify this with the typeMapping in the xbeans.xml file for >> the >> jsr181 SU). This will make it possible for xfire to create the schema. >> The >> xml that your transform to (via the XSLT service) must comply with this >> schema! Your jsr181 service (a pojo) will then be able to receive the >> unmarshalled objects basd on the xml message (the unmarshalling is taken >> care of magically by xfire). In your service you can then persist the >> data >> any way you'd like. > > Yes, that's the way to go. > >> >> You probably want to read another thread here on the forum where a >> problem >> with different namespaces for your service and your pojos is described. >> As >> of now, your object model has to be in the same namespace as your service >> or >> the generated schema will not include them. There is also a Jira for this >> issue. >> >> Having said this, I'm struggling with getting two jsr181 services talking >> to >> each other passing objects of my object model. I'm seeing null being >> passed >> between them, not my objects, so I could be completely wrong here. But I >> don't think so and someone could probably verify that. > > If you use jaxb2 binding, you need to either specify it explicitely > on the jsr181 endpoint or to put a @WebService annotation, which > should automatically switch to jaxb2. > Also, if the xml is not valid wrt to the wsdl, XFire does not always > return errors and sometimes just return null instead. > >> >> /Anders >> >> >> moraleslos wrote: >> > >> > I'm a bit confused. All I want to do is unmarshal data from an XML >> > document that is coming from the NMR into my pojos... I thought that >> was >> > what the typeMapping attribute was for. >> > >> > So if I'm understanding correctly, I'll need to create a Web service >> that >> > will accept this XML document and then invoke another service that will >> > use jaxb2 APIs to unmarshal the data? Again, I'm still fairly new to >> all >> > of this jsr181 stuff. Thanks in advance. >> > >> > -los >> > >> >> -- >> View this message in context: >> http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html#a7374613 >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html#a7381141 Sent from the ServiceMix - User mailing list archive at Nabble.com.
-- Cheers, Guillaume Nodet
