Hi Craig! >> 1) Speedup of startup > ... because it expects the developer to have a fairly complete > understanding of all the classes in every jar, even if you got it from a > third party. oh yes, right you are ....
So the syntax of the configuration should be somehow different: classes=org.any.faces.beans,super-3rdparty.jar=*,myapp.jar=com.company.faces.backings,com.company.faces2.backings,mapp2.jar=.... etc That way you do not need to know much about super-3rdparty.jar, just that it might contain beans. And notice, you do not need to configure it, if there is no configuration you do not need to take this burden, just the current behavior apply. > If the > class is ultimately used later, one could argue that cost is worth the > price, But you might have only a handful beans compared to the number of classes you find in the jars. If you know the package you can decrease the number of scanned classes. > It might well be a nice addition to a commons project, but I'm getting > allergic to increasing the number of dependencies. Indeed, I'd rather > focus > on decreasing them :-). Yea, same old story ... all the time ... we create reusable code, but don't want to depend on it :-( > 2) extension to @View annotation > > This seems like a good idea. ... > Maybe something like the way that LifecycleListener > transparently > delegates toi LifecycleListener2 could be added to the default mapper > implementation. Ok, I'll have a look at it that way. Ciao, Mario
