beandoc: 2 problems/ideas

[simcha]

Hi,
I don't know if "Core Container" is a proper place for the post but don't see better.
First beandoc is really super. I found 2 problems when using it. First is minor:
In my project we use common names for context files of same type this files are spread in folders. For example "thisModule/type1.xml" and "otherModule/type1.xml". Beandoc creates graphs and html file names from context file names thus overriding one context with another. I'm not sure what is a correct solution for that problem but we can work it out and I can code it if you like.
Second problem is major. We are using autowiring as nearly only way of bean wiring. Is there a way and you do you find it usefull to extend Beandoc so it can make autowiring. If yes I would like to help.
Again thx for grate tool,
Regards
jan

[davison]

Jan,

Output filenames are currently generated from Resource.getFileName() which returns the filename and no path information for the file system resources used as input files. Clearly this is the wrong strategy as your usecase highlights. I'm in the process of fixing this now so that additional path components will be used until all input files are uniquely identified. We could just always use the full path for the input file, but I don't like that idea too much.

Autowiring is tricky. BeanDoc works in isolation of the Spring container and can document context files without having to instantiate the container and load all the dependencies and so on. This means it's easy to document any context file even if it contains EJB/JNDI references and so on. Autowiring is container-provided magic and I don't see a way for BeanDoc to provide this unless a BeanFactory can be realised without requiring the compiled classes and associated dependencies. To be honest, I'm not a fan of autowiring anyway and never use it as I think it has the potential for maintenance headaches in evolving code.

However, if you can think of a way to do it I'd be delighted to implement it for you

Regards,

[simcha]

Darren,
I totally agree whit you on full paths and thx I'm waiting for new version.
On autowiring I see two possible solutions just ideas now:
1. Make new wrapper for BeanFactory so it can dump XML file with autowire dependences resolved to normal ref tags, It holds all data anyway. Than one can use wrapper on production environment dump file and feed BeanDoc with it. This file can be usefull for other perposes to.
2. Add someting (plug-in, extention) to BeanDoc. Extension will resolve beans to classes given in classpath. And than make autowiring by name and type taking definitions of thouse classes. As far as I understand one needs only bean type hierarchy and bean property names and types.
For implementation we need much more detailed Ideas but for now I would like to know which solution sounds better. Or there are better ones or You don't like it at all.
Regards,
jan

[simcha]

Answering my own post
I've made some "research" on how autowiring works. And
for now I think that I would go method 2. Writing a wrapper is not easy and one can simplify autowiring a little. It would introduce some difference in how we autowire to how spring is really doing it. But I think we can live with this difference. Disclaimer I did not dig into constructor autowiring jet so the text is only on autowiring properties.

From what I understand autowiring is done for properties that are not set on object initialisation, so one must initialise bean to make autowiring. This is impossible without starting application. So I think we should autowire all properties that are not wired manually. That would make some extra autowiring normally not done. It's generally not good:

1. Properties initialised manually in the bean are not really IoC as I understand this so I would not bother.
2. Some properties can be set from another properties and this is real problem but maybe not so common.

If we can live with it process of wiring by type will go as follows:
1. Load XML and parse it to list of bean definitions. Bean definition must contain: bean names, names of properties set manually, information if bean that should be autowired, autowire method. Take care of beans with the same id (override definition?).
2. For each bean that should be autowired load its class and list all not readonly properties of a class.
3. For each property not wired manually and not of simple type (list needed) find beans of the class that .isAssignableFrom() that property class.
4. If there found more than one bean log warning and do nothing.
5. If there is one bean of a type add property tag to XML file.

I would welcome any comments with "total crap" and "don't understand a word from your English" included.

Other autowire types can be handled in similar way.

I don't know if Darren will find it nice enough to implement it if not I will try

Jan