Visualizing the Application Context

[ayang_ca]

When everything was explicitly defined in an XML file, it was relatively easy to get a sense of the various components wired together with Spring, but annotations are making it much harder to grok a system.

Are there any tools that can take a fully-constructed/wired Spring application context and export some kind of realization of it? Perhaps some kind "injection/wiring event" listener maintaing some kind of structure that could be passed to GraphViz? Being able to map out what aspects are applied and which beans are injected where would be very useful.

Andy

[bytor99999]

Well, the IDEs do a fairly good job of it, however, there are still some annotations that the IDEs don't have quite right yet. The key word, yet. They will.

Mostly the thing with the Annotations, is, and in my opinion, that I don't need to know specifically what classes have Annotations, because my applications follow a simple architecture that I can pretty much deduce what is dependent on each other. If I have a good package structure, I know that I have a service(s) package for my services that will have dependencies to my repository package. In the repository classes there will be injection of SessionFactory or EntityManager if I am using Hibernate or any implementation of JPA. I might have a SimpleJdbcTemplate injected in my repository if I am using JDBC.

In Spring MVC, I know I will have a controller package where my in there will be annotated with @Controllers, and they will have dependeny injection annotations for my service classes in my service package.

So for me, it is the architecture and design that tells me everything I ever could need, it makes my life so much easier.

Now that said, if you don't have a nice clean and easy to understand architecture/design. Then hell yes, xml is nice to see that whole picture in one place.

For me, both arguments for and against both xml and annotations are 100% valid. It isn't whether one side is right or wrong. It is what is your architecture, what is the decision your team makes as to the direction you want to go.

Spring is flexible enough that you can choose, rather than it dicatating how you do it.

Good Luck

Mark

[ayang_ca]

Totally agree with what you said - Spring makes life easier (I don't need to be sold on Spring) but it doesn't obviate the need for clean design and good hygiene on the developer's part.

Where I'm coming from however, is that I'm presented with having to assimilate a Spring app I didn't write. And as you alluded to, if it's software that you're not familiar with, then not having the XML is a different story. Deducing the architecture or naming conventions the original developer followed can be done, but takes time.

Being able to render an Application Context to include wiring via annotations would go a long way towards surfacing the architecture/design. In other words, Spring is doing this processing anyways - why not provide a way of producing a snapshot of its end result?

I'm imagining something like Maven's help:effective-pom where it rips through all the poms in your build and presents you the final hierarchy of dependencies it will use to build your project.

(Please don't hold the fact that I'm using Maven as an example of something useful against me. I'm just as stunned as you are.....)

Andy

[bytor99999]

True, but what my main point is that there is a standard, best practice design architecture to Spring with naming conventions et al, that if followed, anyone with knowledge of Spring would be able to figure out an application someone else wrote. At least that is my vision of a perfect world.

Again what actually happens out there right now is a totally different story.

Mark