Re: [Webmacro-devel] Broker changes and stuff

[Keats K. <ke...@xa...>]

Marc Palmer wrote:

>>Thanks!  I don't suppose you'd like to do the Freshmeat.net
>>announcement 
>>as well?
>>    
>>
>
>I will try to get to that tomorrow. However I think it might be better for
>us to jump to an RC2 with the -src build with libs, Java 5 compatibility
>and a non-broken #macro ;-(
>  
>
Cool.  What's the broken #macro issue?

>However if Brian/Eric aren't available and we don't have time/confidence
>to solve the JavaCC stuff now I think we should stick with RC1 as is and
>slate this stuff for a rapid turnaround 2.1.
>  
>
It should be a very simple change.  I just need to get JavaCC set up on 
my box again.

>I have a contract now where I'm evangelising WM on-site so I can spend a
>little time on it here and there, but setting up commitable CVS here on
>this box would not be a smart thing for me to do ;-)
>
>  
>
>>>should put their templates in places like <webapp>/ or
>>><webapp>/WEB-INF/templates but not in <webapp>/WEB-INF/classes.
>>> 
>>>
>>>      
>>>
>>This approach does seem nice an clean, however some folks will have 
>>standard templates that they want to share across webapps.  Maybe we 
>>could have a configurable option, like 
>>ServletContextBroker.EnableSharedTemplates.
>>    
>>
>
>Won't WebMacro.properties allow them to do whatever they like for that?
>It's better to have a /apps/sharedtemplates directory somewhere on the
>filesystem surely for that kind of thing.
>  
>
I'm a bit hazy on all the details with the DelegatingTemplateProvider 
and what the default configuration is, but I believe the default is to 
use the ServletBroker to locate templates for web apps.  We'll have to 
sort all this out for the new Broker.

>I was thinking that I should change it to load from the ServletContext
>resource path, or from the -webmacro- classloader, so you (we - the
>authors) can put templates in the WebMacro jar that are accessible to all
>applications if WM is in a shared location. This would allow us to ship a
>"spring.wm" that is loaded from the cp.
>
>  
>
>>I agree.  I had the same frustration -- trying to dig up the ant 
>>libraries, etc. 
>>    
>>
>
>OK, so what version of servlet.jar should we ship? 2.3? We should name it
>so and update the build script to use servlet-api23.jar or similar.
>  
>
We might as well stick with the servlet22.jar, unless there is some 
reason to change.  It's really just for compiling anyway.

> 
>  
>
>>Sounds good.  I was hoping someone would do a Java 5 build.  If you 
>>can't commit you can send me the code and put it up there.  (I may also
>>be able to help with your boring problem if you'd like.  Are you using 
>>Windoze?)
>>    
>>
>
>Thanks for all that Keats. Feels like we are the last guys in the WM
>office ;-)
>
>  
>
:'(

>Status update for you:
>
>1. Java 5 build - all OK now except for the generated source so far.
>2. ServletContextBroker - working, but probably needs some semantic
>changes for classloader resource usage
>3. WebMacro taglib - working, needs to use new ServletContextBroker
>though, simple change.
>  
>
I finally got your taglib code working last night.  (It took me a while 
to realize that you had compiled with Java 5.)

I was playing around with adding a couple of attributes:

id - to use a label for diagnostic messages.  The setter/getter methods 
already exist in the superclass, so you just need to add it to the TLD.

handler - the name of a Handler class to process the template.  The 
taglib should look up this name to get the Handler implementation and 
then call it with the request, response, and tag body.  The handler can 
be a class name or a config lookup.  I haven't quite figured out what 
the best place to configure this.

What do you think?

>4. WebMacro Spring integration - working, including set of macros stolen
>from Velocity to give access to a bunch of Spring paradigm stuff. Not all
>macros tested, couple of tweaks I'm working on now.
>
>CVS - I can sort it out at home given the time, just that the SSH keys I
>used to use seem to be causing problems with WinCVS/OpenSSH. It's giving
>me some horrible warning that the SF server may be spoofing its IP and it
>sends a load of crap back to CVS.
>  
>
Sounds like you need to accept the servers fingerprint.  You can use 
PUTTY to connect to the server and accept the fingerprint.  Then 
everything should be cool.

Keats