Menu
▾
▴
springframework-developer
|
From: Darren D. <da...@da...> - 2004-11-04 17:55:21
|
I've done a bit of work on a tool to document and graph context files. It= =20 still needs some work in a few areas but it's starting to show promise I=20 think. Although highly configurable in terms of output, the defaults are pretty=20 sane and were used to generate docs from JPetStore's config. They can be=20 seen at http://www.davison.uk.net/beandoc/ for a short while. All of the=20 HTML and graphs were generated by simply calling the main class and=20 supplying the input files and an output location as command line args. The only changes made to the input files was to move some of the XML=20 comments into <description> tags. Output of <list> <map> <set> and one or= =20 two other tags is currently either broken or not started, but there's=20 enough there to get the idea. Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc.= =20 etc. Is there any interest from others in using this and seeing it added as a=20 subproject (like RCP or Spring-IDE)? =2D-=20 Darren Davison Public Key: #DD356B0D |
|
From: Rodrigo U. F. J. <rod...@us...> - 2004-11-04 18:36:21
|
great tool, I was looking for some think like this, that can graph "autowire" relationships too. if you want, I can help to implement this an other things :D Darren Davison wrote: >I've done a bit of work on a tool to document and graph context files. It >still needs some work in a few areas but it's starting to show promise I >think. > >Although highly configurable in terms of output, the defaults are pretty >sane and were used to generate docs from JPetStore's config. They can be >seen at http://www.davison.uk.net/beandoc/ for a short while. All of the >HTML and graphs were generated by simply calling the main class and >supplying the input files and an output location as command line args. > >The only changes made to the input files was to move some of the XML >comments into <description> tags. Output of <list> <map> <set> and one or >two other tags is currently either broken or not started, but there's >enough there to get the idea. > >Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. >etc. > >Is there any interest from others in using this and seeing it added as a >subproject (like RCP or Spring-IDE)? > > > |
|
From: Keith D. <kd...@cs...> - 2004-11-04 18:48:54
|
This is great! Very cool! I think we need this--Hivemind has HiveDoc, why can't we have SpringDoc? :-) Perhaps a slogan, too? "SpringDoc: dependency visualization for Spring-powered applications" :-) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Darren Davison Sent: Thursday, November 04, 2004 12:55 PM To: spr...@li... Subject: [Springframework-developer] beandoc tool I've done a bit of work on a tool to document and graph context files. It still needs some work in a few areas but it's starting to show promise I think. Although highly configurable in terms of output, the defaults are pretty sane and were used to generate docs from JPetStore's config. They can be seen at http://www.davison.uk.net/beandoc/ for a short while. All of the HTML and graphs were generated by simply calling the main class and supplying the input files and an output location as command line args. The only changes made to the input files was to move some of the XML comments into <description> tags. Output of <list> <map> <set> and one or two other tags is currently either broken or not started, but there's enough there to get the idea. Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. etc. Is there any interest from others in using this and seeing it added as a subproject (like RCP or Spring-IDE)? -- Darren Davison Public Key: #DD356B0D |
|
From: Dmitriy K. <dko...@ru...> - 2004-11-04 19:13:51
|
Looks good to me too! Keith Donald wrote: >This is great! Very cool! I think we need this--Hivemind has HiveDoc, why >can't we have SpringDoc? :-) > >Perhaps a slogan, too? >"SpringDoc: dependency visualization for Spring-powered applications" :-) > >Keith > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...] On Behalf Of >Darren Davison >Sent: Thursday, November 04, 2004 12:55 PM >To: spr...@li... >Subject: [Springframework-developer] beandoc tool > >I've done a bit of work on a tool to document and graph context files. It >still needs some work in a few areas but it's starting to show promise I >think. > >Although highly configurable in terms of output, the defaults are pretty >sane and were used to generate docs from JPetStore's config. They can be >seen at http://www.davison.uk.net/beandoc/ for a short while. All of the >HTML and graphs were generated by simply calling the main class and >supplying the input files and an output location as command line args. > >The only changes made to the input files was to move some of the XML >comments into <description> tags. Output of <list> <map> <set> and one or >two other tags is currently either broken or not started, but there's >enough there to get the idea. > >Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. >etc. > >Is there any interest from others in using this and seeing it added as a >subproject (like RCP or Spring-IDE)? > > > |
|
From: Andy D. <an...@ma...> - 2004-11-04 19:11:47
|
I would most certainly use it and see alot of value in something like this for what I'm doing. - Andy On Thursday 04 November 2004 09:54 am, Darren Davison wrote: > I've done a bit of work on a tool to document and graph context files. It > still needs some work in a few areas but it's starting to show promise I > think. > > Although highly configurable in terms of output, the defaults are pretty > sane and were used to generate docs from JPetStore's config. They can be > seen at http://www.davison.uk.net/beandoc/ for a short while. All of the > HTML and graphs were generated by simply calling the main class and > supplying the input files and an output location as command line args. > > The only changes made to the input files was to move some of the XML > comments into <description> tags. Output of <list> <map> <set> and one or > two other tags is currently either broken or not started, but there's > enough there to get the idea. > > Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. > etc. > > Is there any interest from others in using this and seeing it added as a > subproject (like RCP or Spring-IDE)? |
|
From: Colin S. <col...@ex...> - 2004-11-04 19:43:52
|
That is way cool! Darren Davison wrote: >I've done a bit of work on a tool to document and graph context files. It >still needs some work in a few areas but it's starting to show promise I >think. > >Although highly configurable in terms of output, the defaults are pretty >sane and were used to generate docs from JPetStore's config. They can be >seen at http://www.davison.uk.net/beandoc/ for a short while. All of the >HTML and graphs were generated by simply calling the main class and >supplying the input files and an output location as command line args. > >The only changes made to the input files was to move some of the XML >comments into <description> tags. Output of <list> <map> <set> and one or >two other tags is currently either broken or not started, but there's >enough there to get the idea. > >Stuff still to do: finish XSLT templates, add an ANT task, write docs, etc. >etc. > >Is there any interest from others in using this and seeing it added as a >subproject (like RCP or Spring-IDE)? > > > |
|
From: Daniel P. <po...@ci...> - 2004-11-05 00:40:10
|
Will it handle autowired bean factories? I really like the approach you've taken with this (sort of a combination of SpringViz and JavaDoc). A few weeks ago, someone suggested the idea of actually loading the application context or bean factory and generating the graph and documentation from that. It seems like this would be the only way to support autowired configurations, but obviously poses problems b/c you don't want to actually instantiate/lookup all the beans. I played with this a bit and wrote a custom BeanFactory or ApplicationContext (can't remember which) that simply skipped bean creation. I thought I'd just be able to then query for all the bean definitions and use them to generate the documentation, including dependency links. Unfortunately, it turns out that autowired dependencies aren't stored in the collection of bean definitions (the definitions just reflect what was in the configuration files). I stopped there and decided to wait for someone else to figure it out. ;) Perhaps all that is needed is a custom BeanFactory that maintains these details and updates its bean definitions to reflect autowired dependencies as it's loaded? Thoughts? Daniel On Thu, Nov 04, 2004 at 02:42:57PM -0500, Colin Sampaleanu wrote: > That is way cool! > > Darren Davison wrote: > > >I've done a bit of work on a tool to document and graph context files. It > >still needs some work in a few areas but it's starting to show promise I > >think. > > > >Although highly configurable in terms of output, the defaults are pretty > >sane and were used to generate docs from JPetStore's config. They can be > >seen at http://www.davison.uk.net/beandoc/ for a short while. All of the > >HTML and graphs were generated by simply calling the main class and > >supplying the input files and an output location as command line args. > > > >The only changes made to the input files was to move some of the XML > >comments into <description> tags. Output of <list> <map> <set> and one or > >two other tags is currently either broken or not started, but there's > >enough there to get the idea. > > > >Stuff still to do: finish XSLT templates, add an ANT task, write docs, > >etc. etc. > > > >Is there any interest from others in using this and seeing it added as a > >subproject (like RCP or Spring-IDE)? > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2004-11-05 02:24:55
|
On Friday 05 November 2004 00:53, Daniel Potter wrote: > Will it handle autowired bean factories? not right now, some of the really basic stuff isn't finished yet ;) > I really like the approach=20 > you've taken with this (sort of a combination of SpringViz and > JavaDoc). A few weeks ago, someone suggested the idea of actually > loading the application context or bean factory and generating the graph > and documentation from that. It seems like this would be the only way > to support autowired configurations, but obviously poses problems b/c > you don't want to actually instantiate/lookup all the beans. exactly. Some of which may depend on container resources and so on. At th= e=20 moment the tool has no dependencies on anything other than a couple of=20 libs. > I played=20 > with this a bit and wrote a custom BeanFactory or ApplicationContext > (can't remember which) that simply skipped bean creation. I thought I'd > just be able to then query for all the bean definitions and use them to > generate the documentation, including dependency links. Unfortunately, > it turns out that autowired dependencies aren't stored in the collection > of bean definitions (the definitions just reflect what was in the > configuration files). I stopped there and decided to wait for someone > else to figure it out. ;) Perhaps all that is needed is a custom > BeanFactory that maintains these details and updates its bean > definitions to reflect autowired dependencies as it's loaded? > > Thoughts? depends how many are really using autowiring heavily - may look at it in th= e=20 future but there's lots of other stuff to do first. =2D-=20 Darren Davison Public Key: #DD356B0D |
|
From: Rod J. <ro...@in...> - 2004-11-05 10:48:55
|
>>I really like the approach >>you've taken with this (sort of a combination of SpringViz and >>JavaDoc). A few weeks ago, someone suggested the idea of actually >>loading the application context or bean factory and generating the graph >>and documentation from that. It seems like this would be the only way >>to support autowired configurations, but obviously poses problems b/c >>you don't want to actually instantiate/lookup all the beans. This will also allow you to get at AOP advice. You can cast any proxy to Advised and walk the advice chain, unless the config explicitly sets the "opaque" flag to disable that (for example, for security reasons). The problem is if you require a JNDI environment etc to load the context. I think this tool is important. Thanks, Darren! |
|
From: Daniel P. <po...@ci...> - 2004-11-05 14:23:34
|
How difficult would it be to write a BeanFactory that simply recorded what it WOULD do to load all of its beans if it were a REAL BeanFactory, but not actually do it? (tracking autowired dependencies, advices/interceptors applied, etc). This 'mock' factory could expose this information in whatever fashion is most convenient for a tool like Darren's to produce the desired graphs and documentation. Daniel On Fri, Nov 05, 2004 at 10:48:33AM +0000, Rod Johnson wrote: > > >>I really like the approach > >>you've taken with this (sort of a combination of SpringViz and > >>JavaDoc). A few weeks ago, someone suggested the idea of actually > >>loading the application context or bean factory and generating the graph > >>and documentation from that. It seems like this would be the only way > >>to support autowired configurations, but obviously poses problems b/c > >>you don't want to actually instantiate/lookup all the beans. > > This will also allow you to get at AOP advice. You can cast any proxy to > Advised and walk the advice chain, unless the config explicitly sets the > "opaque" flag to disable that (for example, for security reasons). > > The problem is if you require a JNDI environment etc to load the context. > > I think this tool is important. Thanks, Darren! > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Andy D. <an...@ma...> - 2004-11-05 16:20:11
|
I wonder if one could device a way to separate it enough so that it could be paired with different already-existing BeanFactorys? For example, some people are experimenting with configuration formats other than XML... it would be cool if this tool could work for those alternate formats (such as a database based Spring config or a Groovy based Spring config)... Let the alternate config implementations create their internal representation of the config and then use this internal representation as the basis for all beandocs. I'm not very familiar to the internal workings of the BeanFactory or ApplicationContext, so I'm not sure if this is braindead easy or pipe dream impossible? - Andy On Friday 05 November 2004 06:37 am, Daniel Potter wrote: > How difficult would it be to write a BeanFactory that simply recorded > what it WOULD do to load all of its beans if it were a REAL BeanFactory, > but not actually do it? (tracking autowired dependencies, > advices/interceptors applied, etc). This 'mock' factory could expose > this information in whatever fashion is most convenient for a tool like > Darren's to produce the desired graphs and documentation. > > Daniel |
|
From: Darren D. <da...@da...> - 2004-11-06 00:45:49
|
On Friday 05 November 2004 16:19, Andy Depue wrote: > I wonder if one could device a way to separate it enough so that it could > be paired with different already-existing BeanFactorys? For example, > some people are experimenting with configuration formats other than > XML... it would be cool if this tool could work for those alternate > formats (such as a database based Spring config or a Groovy based Spring > config)... Let the alternate config implementations create their internal > representation of the config and then use this internal representation as > the basis for all beandocs. I'm not very familiar to the internal > workings of the BeanFactory or ApplicationContext, so I'm not sure if > this is braindead easy or pipe dream impossible? A standard internal representation of bean factory configurations, entirely= =20 seperate from the config itself is ideal. I'm not completely au fait with= =20 this aspect of Spring - the last time I tried to figure it out, I got a bit= =20 lost in the distinction between the bean definition readers and the bean=20 factories. I found it difficult to see clear distinction between the two=20 aspects - I should delve into this again. The current code in the beandoc tool essentially works this way now. It=20 parses the config files to produce in-memory DOM representations, and then= =20 works on this representation, decorating it with additional attributes=20 based on beandoc configuration to make the XSLT part much simpler. The=20 output of HTML and the .dot files (used to make the graphs) is generated=20 from this decorated DOM and not the actual config files. Input file=20 parsing would be trivial to refactor into an interfaced plug-in for=20 beandoc. Any input file in any format existing or new could be used to create the=20 same DOM, so long as the parsers can be written for it - as they already=20 have been for XML of course. So this would be a perfectly adequate format= =20 for that standard representation. =2D-=20 Darren Davison Public Key: #DD356B0D |
