> [mailto:[EMAIL PROTECTED]] > > Enviado el: martes 26 de marzo de 2002 0:37 > > Nice to hear that, one comment, there is a > jakarta-tomcat-jasper > repository with code Costin and Mel did some time > ago as an initial > effort to refactor the 3.3 Jasper, i dont know which > is the state of the > code there but maybe it's good idea to use it for > your effort.. >
Unfortunately, Mel has been COMPLETELY immersed in matters unrelated to Tomcat or Jasper for many months. You know, silly stuff like earning money with new job to pay for overpriced new house. :-| So the state of the Jasper refactoring has been pretty much frozen for ages. If someone wants to pick up the ball and run with it, don't worry about my ego. I'd just like to see SOMETHING done to fix Jasper! Kin-Man : If it helps, feel free to build on what we started. We did not get too far, unfortunately before my job situation changed (like a lot of folks last year, eh?). There were a few goals of the refactoring effort we started to keep in mind: 1) modularity (a) - able to use the result with various servlet engines. For example, it should be able to support a Jasper implementation as servlet, intercepter, command line or whatever. We did not want a Jasper that was tied to a particular Tomcat implementation or even to tomcat at all, except as barely required. It should be possible to plug Jasper into most any servlet container. Done correctly, this should STILL allow one to utilize optimizations provided by the particular engine. 1) modularity (b) - nearly ALL functionality of Jasper should be plug-replaceable in a clean, consistent fashion. This is necessary to support not just (1a), but also to make it easier to improve Jasper without proposing the annual rewrite from scratch. 2) able to support both jsp & servlet specs 3) able to support pre-jdk 1.2 systems My scheme for this was to heavily utilize the factory pattern via a highly extendable "Toolkit" metaphor. The toolkit would be driven by configurations in .properties file. The configurations would first of all allow the toolkit to generate an extention of itself appropriate for the particular container (for ex., TC3 or TC4). Then the toolkit would be used to generate all the requisite pieces of functionality required for Jasper such as class loaders, parsers, compilers, caches, etc. I had started with the base toolkit with providing some base utility functions (all replaceable through configuration properties). Basically, any identifiable functionality of Jasper that can be represented with a consistent interface could be implemented with a toolkit factory method. Because the pattern allowed for the toolkit to generate extentions of itself, there is no limit to the factory methods that can be supported. The utilization of this pattern is pretty straightforward. A particular jasper implementation would ask the toolkit to first generate an extention of itself appropriate for the implementation, then it would ask for the appropriate pieces needed to build the functionality of Jasper into that implementation. At the time, I thought the idea had a ton of merit and wish I could devote the cycles to finishing it. I simply do NOT have the time necessary to do so. Take a look at it. If you feel it is something you can use, great! If not, that's also great! I would just like to see SOME progress at improving Jasper once and for all. I would be a little sad if our modularity goals were lost along the way, though. You definitely should use the jakarta-tomcat-jasper repository, though. Cheers and good luck! Mel Dr. Mel Martinez Extreme Blue/Cambridge IBM __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
