Announcement Announcement Module
Collapse
No announcement yet.
When will BeanDoc suppport Spring 2.0 XSD-based config? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • When will BeanDoc suppport Spring 2.0 XSD-based config?

    I'm updating to Spring 2.0's XSD based config, and BeanDoc is blowing up reading them. Any ETA on when these might be supported?

  • #2
    um, as soon as I can get around to it really. Had another busy spell at work over the last few weeks (it does have a habit of getting in the way). "Hoping to make a start shortly" is the best I can offer.

    Regards,

    Comment


    • #3
      Originally posted by davison
      um, as soon as I can get around to it really. Had another busy spell at work over the last few weeks (it does have a habit of getting in the way). "Hoping to make a start shortly" is the best I can offer.

      Regards,
      Any update on this?

      Comment


      • #4
        Any update?

        Comment


        • #5
          I made an attempt at this a couple of months ago and came across several issues.

          Originally, BeanDoc was created to work independently of any Spring machinery - operating solely on the XML files. This was by design in an attempt to make it easier to operate the tool without requiring the building of bean factories or needing access to the classes that the beans represented.

          With 2.0 extensible schemas, this would need to change. If it continues to operate only on the XML then it will need to duplicate the knowledge inbuilt in Spring about how the various namespace elements actually translate into bean definitions. Duplicating would not only be pointless, it would additionally mean that the tool was constantly playing catchup as more namespaces were added. More importantly, it makes it impossible to document any additional custom namespace schemas that you might be using on your project.

          So it seems the obvious way to proceed would be to rely on Spring simply to build a BeanFactory from the supplied resources, depending in the process on the core Spring machinery, Spring's NamespaceHandler classes and any custom NamespaceHandlers used by the project.

          Herein lies the first issue: description tags are just lost as the BeanFactory is created and BeanDefinition objects created. Secondly, once a bean (or multiple beans) are created from the namespaces, there is no simple way to tie the BeanDefinitions back to the XML fragments that created them. In order to do this, some kind of two phase approach to the generation of the BeanDoc output would be required unless additional hooks were put into the Spring factory parsing to cope with this scenario explicitly (and I see no other benefit to making such changes to Spring API's/SPI's so it's unlikely they would be too keen to do it). The same applies in terms of tying beans back to the physical files or resources they were defined in for people aggregating context definitions (most I imagine).

          Despite all that, I got some way towards making this work in part by trying to extend some of the xml parsing and bean definition code, and then came across other limitations in the Spring internals that prevented me from completing it I don't have access to the details of that right now as I'm working away from home but I'll try to dig them out and post back.

          I mailed the Spring dev list about this some time ago asking for some guidance, but I don't think there was a response. Essentially, I probably need someone who knows that part of the core code a little better than I do to assist on this.

          In terms of BeanDoc "blowing up" reading them, it shouldn't - it should just ignore them as the XML parsing just filters out everything that's not a <bean>.

          I'd really like to get this working as I have a number of other improvements waiting to commit too based on using this thing in several of our clients recently.

          Darren.

          Comment


          • #6
            Well, rock on. I can help out with some of the coding if that is the issue.

            Comment


            • #7
              well, as I said - it's not the coding of beandoc that's the issue, it's the limitation in the Spring code that I can't see the right way to overcome.

              Comment


              • #8
                Bean Factories and Metadata

                I'm not necessarily the person to really comment on this so I will refer you to Christian Dupius of the SpringIDE project, but here's what I think to be true.

                With the release of Spring 2.0, the SpringIDE project had the same issues parsing out the metadata of the new namespaces. So some improvements were made to the Spring container to support what is called the 'Tooling API'. This API allows the BeanDefinitionParsers to register exactly what fragment created what bean definition to relate the two objects to one another. At this time, both Spring and the latest nightly build of Web Flow do this. There's also a portion of the API that is used by tools (beandoc and springide) to start a BeanFactory but not instantiate anything. Then the tooling metadata can be read and interpreted and displayed to the user.

                In the end, the new tooling API makes namespaces register their own internal metadata so that tools can treat them generically without having to know anything about the internals. If you've been following the SpringIDE milestone releases, you've seen what's possible with the tooling API. But once again, I don't really have the experience to direct you what to do, but Christian would be a source.

                Comment


                • #9
                  Originally posted by davison View Post
                  In terms of BeanDoc "blowing up" reading them, it shouldn't - it should just ignore them as the XML parsing just filters out everything that's not a <bean>.
                  Does this mean that it is just the namespaces that is filtered out, or the complete file contents (all the beans)?

                  I tried BeanDoc on some xsd-based Spring config files (setting processor.validateFiles=false in beandoc.properties), but ended up with empty "template results" ("All Beans" contains no beans, "files making up this application context" contains no files, empty png files, and so on).

                  Comment


                  • #10
                    Patch with Spring 2.0 support

                    Fully working patch for BeanDoc Spring 2.0 support is available here: http://slonopotamus.org/beandoc-spring2.0.patch

                    Additionally, built jar can be obtained via my maven repository: http://maven2.slonopotamus.org/org/s...c/0.8-SPRING2/
                    Last edited by slonopotamus; May 29th, 2007, 05:53 AM.

                    Comment


                    • #11
                      Originally posted by slonopotamus View Post
                      Fully working patch for BeanDoc Spring 2.0 support is available here: http://slonopotamus.org/beandoc-spring2.0.patch

                      Additionally, built jar can be obtained via my maven repository: http://maven2.slonopotamus.org/org/s...c/0.8-SPRING2/
                      Well, it doesn't work. Empty templates are generated. But there was a warning "Invalid attribute 'xpath-default-namespace'", so this could be the problem.
                      I'm not strong in XSLT so I can't solve it. I think this is very nice tool and useful. Thus I'd like to run it also with Spring2 definitions. Any suggestions please?

                      Comment


                      • #12
                        Originally posted by storm View Post
                        Well, it doesn't work. Empty templates are generated. But there was a warning "Invalid attribute 'xpath-default-namespace'", so this could be the problem.
                        I'm not strong in XSLT so I can't solve it. I think this is very nice tool and useful. Thus I'd like to run it also with Spring2 definitions. Any suggestions please?
                        Hi, storm. Could you please try out latest snapshot from http://mojo.codehaus.org/maven-springbeandoc-plugin/ ?

                        Comment


                        • #13
                          Originally posted by slonopotamus View Post
                          Hi, storm. Could you please try out latest snapshot from http://mojo.codehaus.org/maven-springbeandoc-plugin/ ?
                          I'm using Ant. Unfortunately I don't know almost nothing about Maven.
                          Is there any way to integrate it into ant?

                          Comment


                          • #14
                            Originally posted by storm View Post
                            I'm using Ant. Unfortunately I don't know almost nothing about Maven.
                            Is there any way to integrate it into ant?
                            If you're not using Maven plugin then you should manually add Saxon to classpath (and remove other XSLT processors). The reason is that Saxon supports XSLT 2.0.

                            Comment

                            Working...
                            X