|
From: Torsten J. <tor...@on...> - 2004-12-02 01:47:56
|
> 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 > config set is equivalent to a context. In this scenario the > validation steps in the above paragraph would only be applied > if the flag is set. In CVS head you can find an implementation of the suggested "incomplete config set" feature (additional checkbox in config set properties dialog). Incomplete config sets are validated differently (undefined parent beans or bean references are ignored). The head version also provides a few bugfixes and enhancements: - Cyclic Dependencies not supported in BeansGraph -> http://opensource.atlassian.com/projects/spring/browse/IDE-26 - Inner public class not recoginized -> http://opensource.atlassian.com/projects/spring/browse/IDE-27 - for complete config sets the validator checks bean references (including parent beans) too Cheers, Torsten On 15.11.2004, at 20:14, Watkins, David wrote: > Hi, > I've been having a (slow) think about this and haven't really > come up with any good options :( > > My current thinking.....Problem markers should be split into > 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. > > These are the only markers attached to the resource. > > A second level of problem 'markers' (though not really markers) > would operate on the config sets (only visible in the bean view) > which indicate that a config set is incomplete (i.e. a bean ref > is unresolvable) - this works only if we assume that there are > no 'partial' config sets - which implies that a config set > is roughly equivalent to a standard Spring Context. > > 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 > config set is equivalent to a context. In this scenario the > validation steps in the above paragraph would only be applied > if the flag is set. > > If we adopt the config set =~ context approach it gets us > someway towards the idea put forward by Andreas Oberhack > (some weeks ago - 4 Oct) that we could add a 'launch context' > extension. Perhaps a simpler option would be to add a > 'Generate Spring Boot Class' action by resolving the > config set into an array of classpath resources and > 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' > inner beans doesn't give enough information to pinpoint the bean > without relying on line number hacks. It would be nice to come > up with a 'path' for beans i.e. > > outerBean/middleInnerBean/innerInnerBean > > Though, we'd have to be carefull on the seperator (/ is not a good > one!) > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springide-eclip-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springide-eclip-developer > |