Announcement Announcement Module
Collapse
No announcement yet.
Spring bean description validation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring bean description validation

    Hi

    When the instatiation of Spring beans is lazy then it's possible to do a getBean() on the bean factory and get a BeansException thrown due to, say, a property being specified on a bean that does not exist.

    Even when the instantiation is lazy, if the class="com.company.app.Something" and the Something class doesn't actually have a property setter of myProperty, yet you've specified <property name="myProperty>, then it's surely easy to programmatically verify that this is going to be a problem before deployment/runtime?

    Has someone written something to do this already? It need to be programmatic, really - just coloring a name red in an IDE isn't really an aggressive enough validation check when deploying an app that may have lots of Spring config files and inexperienced users have changed implementation classes without checking that their changes are consistent with the Spring config files.

    Tim

  • #2
    You can use ref local as much as possible to do XML validation. Otherwise I think you should take a look at BeanDoc which creates drawings of the application. Probably you can use their API if the drawings are not good enough.

    Comment


    • #3
      BeanDoc works in isolation of the class libraries - it only needs the XML files to operate. So in the OP's case it wouldn't help.

      Still worth checking out though

      Comment


      • #4
        How to turn off bean validation at application deployment time

        My case is on the opposite. I use ContextSingletonLocator. The beanRefContext.xml contains several bean xmls which are located at different jars under ear. At deployment time, when one jar is loaded, spring validation complains that some beans are not found. Ofcouse they are not found becase the rest of jars have not loaded yet. This causes big problem for us. Is there a way to turn off the bean validation at deployment time. After the deployment is done (with all jar and wars are loaded, spring should be able to find all bean classes.

        Also, when we use non-singleton bean, it cannot be declared "lazy-init=true", why?

        Thanks.

        Comment


        • #5
          Originally posted by yangju
          Also, when we use non-singleton bean, it cannot be declared "lazy-init=true", why?
          it's because of the prototype's nature: they are fully configured, wired-up and instantiated upon EACH call, and never before.

          Comment


          • #6
            Prototypes are not managed by Spring - they are initialized and given to the client (other dependencies) but since they are created only when they are needed there is no point in lazy initialization.

            Comment


            • #7
              How to disable classpath verfication at startup time

              We use jboss and ContextSingletonBeanFactoryLocator in Spring.
              The problem is: when the jboss server is started, not all classes that are referred in the bean definition file are loaded. They will be loaded eventually. But it seems to us that spring loads the bean definition xml file and tries to verify each of the classpath of the beans. Because not all classes are loaded yet, spring gives us bunch of exceptions saying class not found. This happens even we define lazy-init="true".

              Is there anyway we can defer the verfication of bean classpath?

              Thanks.

              Comment


              • #8
                I'm not sure how your classpath is constructed by the classes definitions have to exist since they are required for validating the configuration. What you can do is load the application context only after the classpath has been defined (or divide the app context into several pieces and load them step by step after the classpath has been constructed).

                Comment

                Working...
                X