Announcement Announcement Module
Collapse
No announcement yet.
Spring to make a Class entend an abstract? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring to make a Class entend an abstract?

    I am trying to get a wsdl2java generated Data Object to extend an abstract class of mine so that I can enforce that the generated class implements methods.

    So I get this generated:

    public ObjectType implements Serializable{...}

    What I want is:

    public ObjectType extends AbstractObjectType implements Serializable{...}

    Then abstractObjectType will define:

    public String getCustomerReferenceNumber();

    Then if ObjectType does not implement getCustomerReferenceNumber() I can get an error at startup or something.

    Can anyone help with something like this in Spring?

  • #2
    I'm not sure if I understand the problem correctly, but you can use a BeanPostProcessor to extend the Spring container behaviour. A BPP is a listener that is notified of the instantiation of Spring-managed classes, and you can perform whatever checks you like there.

    HTH,
    Rod

    Comment


    • #3
      I don't understand why would you need that really. You run wsdl2java once. Rest of your code compiles against generated classes or not. If some method you need is missing you get compile time errors. If wsdl changes you have to run wsdl2java again to generate new classes. If you try to old use generated classes against changed service points you'll get runtime errors.

      Comment


      • #4
        Not exactly.
        I get ObjectType's generated from webspheres wsdl2java. And I can't use them in my UI.
        So, I use this to copy the properties from the generated Object to my new object:
        BeanUtils.copyProperties(targetObject, generatedObject);

        So, when the wsdl changes and the generated Types now change, the copyProperties now does not copy the properties correctly as there is a method name mismatch. I don't find out about this until runtime. Then, it is almost always confused with a DB data error as the field is missing. So, a bug goes un-noticed for some time and heaps of research to determine that the group that manages the wsdl made changes that effect us.

        So, I want a way at compile time, or startup time to get these errors identified. Hence enforcing an extends, or implements that will raise an error if there is one.
        I started playing with introduction, but that does not seem to do what I am describing. Wrong?


        Originally posted by dejanp
        I don't understand why would you need that really. You run wsdl2java once. Rest of your code compiles against generated classes or not. If some method you need is missing you get compile time errors. If wsdl changes you have to run wsdl2java again to generate new classes. If you try to old use generated classes against changed service points you'll get runtime errors.

        Comment


        • #5
          Ah, you should have mentioned reflection right away...

          Clean, generation time - you could try to make wsdl2java generate such classes, I have no idea how hard or easy that is, but using custom type mapping it should be possible.

          Dirty, compile time - you create an ant target that changes the source file so that it contains 'extends xy' (I think you need 'implements xy' though)

          Workaround, runtime - somewhere at startup create an instance of both classes and use BeanWrapper to loop through properties and use isReadableProperty()/isWritableProperty() to check if they are compatible.

          Comment


          • #6
            I have taken my issue to IBM support, and there is NO way to make the wsdl2java utility to create the extends according to them. They said I would have to run some secondary xslt processor to add this. I do not know much/anything about that so I don't know if that is ugly or not..... Anyone have an idea?

            The dirty option you mentioned is way too dirty for me and I really don't want to touch that.

            That is why I started looking at some Spring/AOP workaround.
            Can you please elaborate on the workaround solution you mentioned?


            Originally posted by dejanp
            Ah, you should have mentioned reflection right away...

            Clean, generation time - you could try to make wsdl2java generate such classes, I have no idea how hard or easy that is, but using custom type mapping it should be possible.

            Dirty, compile time - you create an ant target that changes the source file so that it contains 'extends xy' (I think you need 'implements xy' though)

            Workaround, runtime - somewhere at startup create an instance of both classes and use BeanWrapper to loop through properties and use isReadableProperty()/isWritableProperty() to check if they are compatible.

            Comment


            • #7
              I'm writing this out of my head, so it's not going to compile really.

              Code:
              BeanWrapper original = new BeanWrapper(new O());
              BeanWrapper target = new BeanWrapper(new T());
              
              PropertyDescriptors[] pds = target.getPropertyDescriptors();
              
              for(PropertyDescriptor pd:pds) {
                String name = pd.getBaseName();
                if(!original.isReadableProperty(name))
                  throw new OmgTheyChangedItAgain(name);
              }

              Comment


              • #8
                Can this copy behavior be put into some junit tests and run as part of the build? Or at least a junit test case that uses BeanUtils to assert the method is there?

                Comment


                • #9
                  I have another twist in this as well.

                  I have 8 different wsdl's that I am using sofar from another group.
                  Each of the wsdl's generate code that is in different packages, but there are some common classes that only differ in package name.:

                  com.declinedQuery.IPCHeader
                  com.consumerQuery.IPCHeader

                  So, not only do I have to ensure that my 'com.consumer.IPCHeader' matches both declinedQuery and consumerQuery, I have to treat each of the IPCHeaders differently, where as if I could make an AbstractIPCHeader that all 3 extend, I could treat all 3 as the AbstractIPCHeader.

                  Is this proper thinking, or is there a better way to achieve this?

                  Comment


                  • #10
                    ping...???

                    Comment


                    • #11
                      Runtime changing of the class hierarchy would be (imo) a hack - as bad as ant-task to change your source files, if not worse. I don't think it's possible, and I don't think it should be done anyway.

                      More general bean2bean mapping solution you might want to check is Dozer http://sourceforge.net/projects/dozer

                      Comment

                      Working...
                      X