On 9/28/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
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.
See my response on your JIRA issue ... if the developer *does* include this context init parameter, then it seem that we would have to analyze *all* JARs in WEB-INF/lib, even those that are pretty much guaranteed *not* to have anytihing relevant (such as Hibernate and all of its dependencies).
From my viewpoint, implementing this approach seems like a net loss in
performance (for the normal use cases), rather than a gain.
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.
Doesn't matter ... the key to improving performance is minimizing the list of classes you ever look at in the first place (and therefore have to load into memory in the JVM). If you explicitly specify that any class in " com.mycompany.mypackage.mybeans" might include annotated beans, then you are implicitly requiring Shale to check for such classes in *all* jars included in the webapp ... even if they came from something like Hibernate.
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
Craig
