Annotation Scanners (and limitations)

[archsynthe]

I'm curious about the limitations of the annotation scanners that are used in the switchyard-plugin for maven that are used to populate the switchyard.xml at build time (BeanSwitchYardScanner, TransformSwitchyardScanner, ValidateSwitchyardScanner).  From what I can tell, these scanners will automatically add configuration to the switchyard.xml for beans annotated with @Service, @Transformer and @Validtor, respectively.  Is that the extent of the annotation-scanning functionality?  Is there any ability to add bindings or promotion to the configuration at build time?  I've been an avid IntelliJ IDEA user for years, and while I appreciate the great toolset you guys have put together for Eclipse / JBoss Developer Studio, the added benefit of the tooling is (in my humble opinion) not worth the added headache of having to develop in an Eclipse-based environment.  As a result I've been using the switchyard tools in a demo project to see what effect certain elements have on the xml, and then using that information to manipulate the switchyard.xml config file by hand in my real project through IntelliJ.  I was hoping the annotation scanners would give me the ability to ignore the switchyard.xml file altogether, but there seem to be some elements of configuration that can't be handled in this way.  Am I missing anything?

[kcbabo]

The original purpose of annotation scanning was to provide config generation.  That worked well at first, but then we discovered Forge and that made it easier to generate config behind the scenes while exposing basic, intuitive commands to the user.  Then our Eclipse tooling really took off, and we could keep the user out of the XML configuration completely.  All of this put a lot less emphasis on the role and importance of annotation scanning.  One drawback with evolving annotations to include things like binding and promotion is that it starts to bleed packaging and deployment concerns into the service implementation layer.  It does make things easier, but it can limit flexibility as well.

I'm totally open to expanding our toolset to non-Eclipse environments, as we recognize that not all people are Eclipse fans.  Eclipse will be our primary tools platform for the forseeable future, but that doesn't mean we can't accommodate other tools as well.  Some possibilities:

- Continue to evolve the Forge tooling and use that as a bridge.

- Investigate alternate serializations of the config model which are friendlier to edit directly - a DSL, for example.

- Look into a web-based editor, which is something on the radar for other concerns already.

cheers,

keith

[archsynthe]

Thanks for the quick reply Keith.  I certainly understand the lack of flexibility that might be imposed by applying deployment concerns at the compiled code level.  I suppose I was hoping it might be approached in the same way that CDI does interceptors and decorators.  Perhaps providing something like a @ServiceBinding annotation which could be applied to a custom annotation type used to link a service interface to a gateway type, and then requiring a line in the xml to enable it.  I look forward to seeing where you guys go with this, but in the meantime I'll probably just delegate the configuration tasks to someone on my team who prefers Eclipse