|
From: Watkins, D. <dav...@fa...> - 2004-11-15 19:14:53
|
Hi, I've been having a (slow) think about this and haven't really=20 come up with any good options :( My current thinking.....Problem markers should be split into=20 two broad categories: 1) Definate problems/errors - property doesn't exist/class not found etc. 2) Context warnings/information - referenced/parent bean not found in 'this' config file. =20 These are the only markers attached to the resource. =20 A second level of problem 'markers' (though not really markers) would operate on the config sets (only visible in the bean view)=20 which indicate that a config set is incomplete (i.e. a bean ref=20 is unresolvable) - this works only if we assume that there are=20 no 'partial' config sets - which implies that a config set=20 is roughly equivalent to a standard Spring Context. =20 If this isn't acceptable then a flag could be included in the config set definition which indicates "I should be complete" - this flag would basically be a manual way of saying this=20 config set is equivalent to a context. In this scenario the=20 validation steps in the above paragraph would only be applied=20 if the flag is set. If we adopt the config set =3D~ context approach it gets us=20 someway towards the idea put forward by Andreas Oberhack=20 (some weeks ago - 4 Oct) that we could add a 'launch context'=20 extension. Perhaps a simpler option would be to add a=20 'Generate Spring Boot Class' action by resolving the=20 config set into an array of classpath resources and=20 feeding them into a spring ClassPathXmlApplicationContext. Anyway, just thought I'd chip in now before the question gets forgotten about! Cheers, dw P.S. Speaking of validation, the problem marker on 'anonymous'=20 inner beans doesn't give enough information to pinpoint the bean=20 without relying on line number hacks. It would be nice to come up with a 'path' for beans i.e.=20 outerBean/middleInnerBean/innerInnerBean=20 Though, we'd have to be carefull on the seperator (/ is not a good=20 one!) |