Announcement Announcement Module
Collapse
No announcement yet.
Required annotation check Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Required annotation check

    Is there any way to get Spring IDE to display a warning or error if a required dependency (w/ the @Required annotation) is not set? Right now I can only see this by restarting the application and watching it bomb...

    If such a feature does not exist, maybe it should? Does this sound useful to people?

  • #2
    Hi,

    If such a feature does not exist, maybe it should? Does this sound useful to people?
    Yes it does sound useful. Go ahead and open an enhancement request for this over at our ticketing system and you'll get support for @Required.

    Christian

    Comment


    • #3
      created ticket

      Thanks. I went ahead and created the ticket. It's here:
      http://springide.org/project/ticket/669

      Spring IDE is really cool, even w/out this feature!

      Comment


      • #4
        Implemented! It should be available with the next nightly build.

        Give it a test drive.

        Christian

        Comment


        • #5
          Yay!

          It works! Thanks so much for implementing this, and so quickly! Definitely a very handy feature.

          Comment


          • #6
            I do notice it's an error, not a warning. That's fine with me though. I'm not sure exactly how one decides what is appropriate. I guess since the app won't run without the required field set an error makes sense.

            Comment


            • #7
              I guess since the app won't run without the required field set an error makes sense.
              Yes, that's why I decided to use an error instead of a warning. The validation can be disabled by using the 'Project Validators' preference page in the project properties.

              Please note that I fixed another error with the @Required check this morning which was related to abstract bean definitions.

              Christian

              Comment


              • #8
                alternative annotation

                The RequiredAnnotationBeanPostProcessor supports custom annotations for the validation via setRequiredAnnotationType(). Spring IDE supports "@Required property" validation rule but has no option for the annotation class. It uses always the default @Required class. Would it be possible to make this configurable?

                P.S.: I already tried to write a validator by my own but it seems to be heavy because most of the classes I need (e.g. BeansValidationContext) have restricted access.

                Comment


                • #9
                  Hi iterator,

                  Would it be possible to make this configurable?
                  Yes sure, but I guess it would be more intuitive if Spring IDE just uses the configured Annotation class from your configuration file. WDYT?

                  Can you go ahead an open a JIRA issue for that, please?

                  ... most of the classes I need (e.g. BeansValidationContext) have restricted access.
                  Is it hard because the class is contained in an internal package or it is hard due to some other reasons (documentation)? Please let me know so we can improve it.

                  Christian

                  Comment


                  • #10
                    Originally posted by Christian Dupuis View Post
                    Yes sure, but I guess it would be more intuitive if Spring IDE just uses the configured Annotation class from your configuration file. WDYT?
                    I agree with you but there remains a question: What if there is used more than one Annotation class. Would the validator find all the RequiredAnnotationBeanPostProcessor instances and not just one?

                    Originally posted by Christian Dupuis View Post
                    Can you go ahead an open a JIRA issue for that, please?
                    Done: 733
                    The ticket also describes the demand of more than one checked annotation class.

                    Originally posted by Christian Dupuis View Post
                    Is it hard because the class is contained in an internal package or it is hard due to some other reasons (documentation)? Please let me know so we can improve it.
                    Yes because of the internal packages. Most of the already existing useful code that is used in the existing validations is not reachable for other plugins. I also have other demands to write validators than the @Required case and it would be good to have the same possibilities in an extension plugin like the internal RequiredPropertyRule class for example.

                    iterator

                    Comment


                    • #11
                      Iterator,

                      thanks for opening the JIRA issue. I'll make sure that the validation rule will honar every instance of type RequiredAnnotationBeanPostProcessor because if this works with Spring it should work with Spring IDE as well.

                      Yes because of the internal packages.
                      Since the validation API is considered as open extension point of Spring IDE that could be used by clients to implement custom validation logic, I think you are right that the usage of internal classes is a little unsatisfying (please note that one can implement a validation rule with only the use of non-internal classes).

                      Would moving the BeansValidationContext (hmm why not adding a public IBeansValidationContext interface?), AbstractBeanValidationRule and AbstractNonInfrastructureBeanValidationRule into the package org.springframework.ide.eclipse.beans.core.model.v alidation solve your problem? I think we could go ahead and consider these classes 'public API'.

                      Christian

                      Comment


                      • #12
                        Christian,

                        thank you for your fast response.

                        Originally posted by Christian Dupuis View Post
                        please note that one can implement a validation rule with only the use of non-internal classes.
                        I tried this, but got lost in unknown terrain. I am new to the whole eclipse plugin stuff and also new to the Spring IDE extension points. I couldn't find detailed information about the exension points. I found the blog entry http://springide.org/blog/2007/04/05...om-namespaces/
                        where the linked example is not upto date to the extension points. I read the sources of the existing namespace extensions and found my way but it was not easy. Now I am happy to have also hyperlink and content assist functionality. But with the validation I got into trouble because I do not understand the way it works. Is there any further documentation?


                        Originally posted by Christian Dupuis View Post
                        Would moving the BeansValidationContext (hmm why not adding a public IBeansValidationContext interface?), AbstractBeanValidationRule and AbstractNonInfrastructureBeanValidationRule into the package org.springframework.ide.eclipse.beans.core.model.v alidation solve your problem? I think we could go ahead and consider these classes 'public API'.
                        It would be helpful. But like stated before I do not yet understand the validation API and so I am not sure if I could already do what I want.

                        Comment


                        • #13
                          I created IDE-735 to remind me to move the classes into an public package. Futhermore I will introduce a IBeansValidationContext interface.

                          I'll try blog about the validation API and some other improvements no later than the Spring IDE 2.0.2 release. We have made some progress in the content assist and hyperlinking area as well.

                          Christian

                          Comment


                          • #14
                            Hi Christian,

                            that sounds good. I am looking forward to read about the validation API. Thank you.

                            Dirk

                            Comment

                            Working...
                            X