Subject: RE: Groovlets with .gdo mapping won't work anymore - msg#00457

Previous Message by Date: click to view message preview

Re: Groovy in Groovy

Hi Joerg, On 29/07/05, Joerg Plewe <plewe-CugtsGaplSQb1SvskN2V4Q@xxxxxxxxxxxxxxxx> wrote: > Before doing this, please have performance in mind. Compiled groovy code is > slower than Java code (significantly I think). So don't please give away > performance without a BIG win somewhere else. Sure, don't worry ;-) Once 1.0 is out, we'll integrate some new features obviously, but a major aspect of 2.0 will be performance and bytecode optimization, such as that our generated bytecode is almost as fast as Java in most situations. Currently, that's not the case. Some reported that the average performance could range from 20% to 90% of raw Java equivalent code. As I said, perhaps Groovy 3.0 will be a rewrite in pure Groovy. But that's not carved in marble, it's just a possibility, since we're not there yet!!! One last point, the fact that Groovy be written in Groovy doesn't mean that the performance may be worse: in fact, a big part of the equation is the bytecode we generate and the other big part is the runtime (ie. our groovy.lang.* and org.codehaus.groovy.runtime.* classes). If we generate the exact same bytecode with a Groovy class or a Java class, the bytecode will still be the same! So the performance too! The big parts that'd need more optimizations are our runtime classes, such as Closure, Invoker, etc... -- Guillaume Laforge http://glaforge.free.fr/weblog/?catid=2

Next Message by Date: click to view message preview

Re: Use of final in variable definitions

HI, I think in this case: >>>final PI = 3.14159 PI has the int type implicitly, use instead: final float PI -- best regards, v1tja mailto:vitja-CmXoYKhtxCk9N05kXDq99ya99n5gTZ5g@xxxxxxxxxxxxxxxx Friday, July 29, 2005, 12:09:35 AM, you wrote: SC> Is the final keyword supported in veriable definitions? SC> I tried: SC> final PI = 3.14159 SC> PI = 3 SC> println("pi=" + PI) SC> and I got the answer 3. I'm using JSR 2 and Mac OS X 10.3.9 with Java SC> 1.4.2 if that helps. SC> Is there a recommended way to declare constants instead of trying to SC> use the Java final keyword? SC> Simon

Previous Message by Thread: click to view message preview

Re: Groovlets with .gdo mapping won't work anymore

Dierk Koenig wrote: Hm, not sure I understand the concerns. What scenario cannot be handled or lacks intuitivity with the match/replace functionality in jsr03-snap ? This question is a good example/scenario for the confusion generated by arbitrary extension support. :) Not only to new Groovians - I've to remind myself everytime of the two sorts of "mappings": #1 Servlet container mapping, the outer or top-level mapping. [web.xml] Here you define, what servlet serves which resource type. This could be a "*.xyz" file pattern or start with "/" and let all paths handled by the specified servlet. Note: Being a servlet, you can *NOT* figure out the reason why the container decided to pass the user request to you. You're called, do serve. #2 Groovy resource connection mapping, the inner mapping. [getResourceConnection()] Here you can control the search path for resources needed by some Groovy class/script/template. Your match/replace code modifies the mapping #2 - compensating the removal of the hard-coded replace work done in mapping #1 in an old revision of GroovyServlet only. Thinking about it, why not have both? Keep current matcher for #2 and re-install the #1 extension-magic as a (configurable) fall-back? Cheers, Christian PS - [OT] And mind the two paths of serving Groovy through servlets: GroovyServlet != TemplateServlet

Next Message by Thread: click to view message preview

Re: Groovlets with .gdo mapping won't work anymore

Dierk Koenig wrote: Hi, Your match/replace code modifies the mapping #2 - compensating the removal of the hard-coded replace work done in mapping #1 in an old revision of GroovyServlet only. Yes, it's a two stage process. #1 determines which request should be served by which Servlet If that happens to be GroovyServlet, #2 optionally determines how to find your Script for the requested Url. Not exactly - not exactly the way it's implemented atm: #2 is used *only* for nested/referenced resource needed by the "Script". So there is a ... call it #1.5 ... step that resolves the "real" path for the requested URL to a local URI. That's done by getScriptUri(HttpServletRequest). Here, after handling all request options like FORWARD et al, the "Script" is loaded and passed to the template engine. Guillaume, author of the old "srtip-away-any-none-.groovy-extension-and-append-.groovy" code, used to do that hard-coded magic *before* loading the "Script". In short, *every* URL containing at least one '.' was (will be) modified. Examples assuming all URLs are served by GroovyServlet: http://a.b.cc/index.groovy --> [as is] http://a.b.cc/index.gdo --> index.groovy http://a.b.cc/do.it --> do.groovy Its totally local to the GroovyServlet (and may better be an init param of the Servlet rather than a context param). It is an init-param in my local revision. I'll commit soon for review - after my local Jetty/Tomcat setups do say "green". :) I'm certainly biased, but for me this is fairly clear. #2 doesn't /modify/ #1. It's two different things. True. #2 cannot be used as a fallback of #1 since #1 determines whether #2 is used at all :-) True. But we had have (and will have?) a fall-back inside of #1. Cheers, Christian