Announcement Announcement Module
Collapse
No announcement yet.
Why ROO avoid ITD generation to Enumeration class Types ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why ROO avoid ITD generation to Enumeration class Types ?

    Hi!

    My question is about the ITD generation to Enumeration class types.
    You Only can generate ITD for Class types.

    ROO avoid this behaviour in AbstractItdMetadataProvider method get:

    Code:
    public final MetadataItem get(String metadataIdentificationString) {
    
    ...	    
    // Cancel production if the governor is not a class, and the subclass only wants to know about classes
    if (cid != null && dependsOnGovernorBeingAClass && cid.getPhysicalTypeCategory() != PhysicalTypeCategory.CLASS) {
            produceMetadata = false;
    }
    ...
    Why ?
    My problem is that I not able to add an ITD to an Enumeration Class or in other cases to another class type that is not a class.

    Is there any reason or this could be an improvement ?

    Thank you for your time !

    Roo v1.1.0-M1
    jdk 1.5.07
    Ubuntu 10.04

  • #2
    I'm curious why you'd like to add ITD members to a non-class governor. Can you please expand on this? Feel free to log it as a Jira request so we can capture it there.

    Comment


    • #3
      Hi!

      We are developing an Add-on to manage/create web services.

      I want to generate ITD to an enumeration class because we want to publish classes as XmlElement involved in a web service operation using ITD.

      To continue with ROO Add-on philosophy, create annotations and handle classes behaviour with its ITD, this kind of class has to be managed using ITD too.

      An Enumeration class could be defined with jax-ws @nnotations to be used in a web service operation as an element.

      Thank you !
      I hope I've made a good explanation for my goal.

      Comment


      • #4
        Hi!
        In other hand the construction of enum constants could be more complex like EnumDeclaration from japa library:

        Code:
        public final class EnumConstantDeclaration extends BodyDeclaration {
        
            private String name;
        
            private List<Expression> args;
        
            private List<BodyDeclaration> classBody;
        ...
        }
        Not as is defined with only JavaSymbolName List.
        Code:
        private List<JavaSymbolName> enumConstants = new ArrayList<JavaSymbolName>();
        Because we lost lots of information related to a constant like invocations and annotations:
        Code:
            ABT("ABT"),
            CC("CC"),
            ACH("ACH"),
            @XmlEnumValue("Debt")
            DEBT("Debt"),
            @XmlEnumValue("Prepaid")
            PREPAID("Prepaid");
        Thank you !

        PD: It's better to post a JIRA describing the improvement for these cases ?

        Comment


        • #5
          Originally posted by ricardo_garcia View Post
          Hi!


          PD: It's better to post a JIRA describing the improvement for these cases ?
          Post to the Jira and discuss there and here as you find appropriate. I usually link to the forums at the Jira and to the Jira here at the forum.

          Comment

          Working...
          X