On 9/28/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi! I would like to discuss two things which come in my mind during trying out shale-tiger: 1) Speedup of startup While shale-tiger already tries its best to parse only jars with specific markers I think we can further speedup the startup if we allow the user to configure which packages to parse. I think about a context parameter where the user can configure e.g. "org.my.app1.backings,org.my.app2.backings" etc. This will parse classes located within these packages and their sub-packages. There are tricks how to get the classes within an package, I already use such a trick, though, with help from VFS, but it should be backportable to plain java. I know, this is yet another context-param, but the speedup might be worth it.
Are you thinking that, if the list of packages was specified, that it would apply to *all* of the JAR files (and, presumably, when you scan /WEB-INF/classes for consistency)? If so, that seems like a pretty heavy usability burden, 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. Also, note that the impact we are talking about here is the fact that Shale has to load the class in order to analyze its runtime annotations. If the class is ultimately used later, one could argue that cost is worth the price, because it saves having to load the class later. The only time that Shale's loading of the class is "wasted effort" is if the class will never be used. BTW: Having such a configureable framework in commons might be great -
or as part of the "web commons" (sorry I've forgotten the name ;-) ) would be great. Any library can register to it and do not need to create all this traversing code itself, but well, we can easily refactor it later ....
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 :-). 2) extension to @View annotation
The ViewControllerMapper is responsible to map a view name to the corresponding backing name. Now, with the power of annotations it might be possible to use another approach to map a bean to its view. Say a bean has both annotations, the @View and @Bean, now, if we allow to setup the view name at the @View tag, e.g. @View(name="/to/my/faces/view.jsp") Shale has all informations required to map a view to the bean. "name" should be optional so one can still use the ViewControllerMapper.
This seems like a good idea. I presume we would want this to explicitly override any default mapping for this particular view id, but (if it were not specified) the standard implementation would be used. In terms of implementation, we'll also need to take care with configuration, since we can't guarantee that shale-tiger.jar will be configured after shale-core.jaris. Maybe something like the way that LifecycleListener transparently delegates toi LifecycleListener2 could be added to the default mapper implementation. What do you think?
I'll provide patches if you think its useful. Ciao, Mario Craig
