4 Replies Latest reply on Jul 9, 2006 4:34 PM by starksm64

    JCA and JAXB

    weston.price
    weston.price Jul 8, 2006 9:30 AM

      I converted the *-ds.xml file to a schema represenation (simple conversion using Oxygen, nothing fancy), ran it through the latest xjc compiler, unmarshalled a *-ds.xml document etc, etc.

      Is there any reason why we shouldn't be using this technology over XB. I can understand for the existing ra.xml stuff since it's already done, but for the ds.xml it would seem to make sense at the very least it would eliminate a lot of code that doesn't do anything besides XML binding which JAXB already provides.

      I know that we are going to be using the JAXB RI in 5.0 moving forward so IMO we should go ahead and start leveraging this. In many ways, I would be inclined to replace the ResourceAdapterObjectModel factory as well.




      • 10306 Views
      • Tags:
        • 1. Re: JCA and JAXB
          weston.price
          weston.price Jul 8, 2006 9:31 AM (in response to weston.price)

          Sigh...sorry...the


          I converted the *-ds.xml file to a schema represenation


          Should read ...converted the jboss-ds_1_X.dtd(s)



            • Actions
          • 2. Re: JCA and JAXB
            starksm64
            starksm64 Jul 8, 2006 3:58 PM (in response to weston.price)

            My fundamental problem with jaxb is that is drives the java model from schema/xml and as such has limitations. I want the java object model to be what it needs to be, not fit into something that jaxb can support.

              • Actions
            • 3. Re: JCA and JAXB
              weston.price
              weston.price Jul 8, 2006 7:42 PM (in response to weston.price)

              An external mapping file can allow for differences in the xsd->object model if necessary. I could see this if they object model was something more than just dumb data containers, but in parsing deployment descriptors, that's exactly what the object model is. The meta data is just a wrapper of the underlying XML.

              I guess I am seeing it in terms of

              1) Code elimination
              2) Ease of use
              3) A technology that is already a part of our stack (at least this is what was discussed on one of the R&D conference calls)




                • Actions
              • 4. Re: JCA and JAXB
                starksm64
                starksm64 Jul 9, 2006 4:34 PM (in response to weston.price)

                The customization support in jaxb was not sufficient for handling object/xml mapping in the past. The parsing required of the jboss.xml file is an example.

                  • Actions