webmacro-devel — Discuss development issues related to the core of WebMacro

[Webmacro-devel] Re: [Fwd: Planning://November 1 - Map support bugs]

[Eric B. R. <eb...@tc...>]

On Oct 12, 2005, at 11:40 AM, Lane Sharman wrote:

> Keats, Eric:
>
> It is urgent that you guys fix the map bug:
>
> #set $foo = { }
> #set $foo = {}
> #set $foo = {             }
> should all resolve to a new empy map and according to marc, they do  
> not. See marc's comments below.

The whitespace handling issues have been fixed and some test cases  
(org/webmacro/tempalte/TestMap.java) have been added to CVS.  All  
existing test cases still pass.

However, I've been unable to reproduce Marc's report of #set $x = {}  
sometimes returning a previously created Map.  I've even tried the  
#include thing as he mentioned to no avail.  There's the start of a  
test case for this inside TestMap.java if anyone wants to expand upon  
it.

I did study the code and it looks like a *new* HashMap instance is  
being returned for every use of {}.  The MapBuilder is modeled after  
the long-existing ListBuilder.  I'm at a loss on this one.  Marc, do  
you think you can steal 45 minutes to try to come up with a re- 
produceable test case?

eric

>
> also, keats, this week is the last week to deposit ProperyDirective  
> or InversionDirective (since that it is what it would be used for).
>
> -Lane
>
>
> -------- Original Message --------
> Subject:     Planning://November 1 - Map support bugs
> Date:     Wed, 12 Oct 2005 12:15:59 +0100
> From:     Marc Palmer <ma...@an...>
> Reply-To:     ma...@an...
> To:     Lane Sharman <la...@op...>
> References:     <433...@op...>
>
>
>
> -----Original Message-----
> From: Lane Sharman <la...@op...>
> To: web...@li...
> Date: Sat, 01 Oct 2005 12:16:48 -0700
> Subject: [Webmacro-devel] Planning://November 1 Is Official Release  
> Date
> of WebMacro 2.0Final
>
>
>> Guys,
>> For planning purposes, Nov 1 is the official release of 2.0. For many
>> of you, this is a non-event. But, for me it is the culmination of  
>> a lot of
>> work.
>> How about one you rogering up and writing a press release and  
>> making contact with the zines and developing some new buzz for WM  
>> 2.0?
>>
>
> I can try to do the press release.
>
> HOWEVER I have found what I am pretty sure are some nasty bugs in  
> the map
> support - I believe we must fix these before release.
>
> Forgive me if these have already been fixed.
>
> ******** Problem #1 - the worst
>
> #set $myVar = {}  does not guarantee an empty map. In some  
> circumstances
> (I cannot ascertain which at the moment) values from a previous  
> usage of a
> Map remain in this new "empty" map. This is even between requests!
>
> You can prove this because the only workaround is:
>
> #set $myVar = {}
> $myVar.clear()
>
> That is the only way I can suppress this bug. Assigning null to the
> variable before assigning {} does not work.
> This implies to me that in some situations the "new" map used to  
> assign
> the {} value to a variable is in fact cached/reused.
>
> I repeat, I see the data persisting between separate WM render  
> cycles, not
> just in the same template.
>
> It may be related to using #set $x = {} within an included  
> template, as
> that is our scenario here. Unfortunately my curernt employer won't  
> afford
> me the time to pin this down, but I may try to nail it down more (and
> write unit test) soon if I have the time but you will probably have
> noticed I haven't been around much.
>
> ******** Problem #2
> The parser doesn't like whitespace when creating empy maps:
>
> #set $x = { }
>
> This throws a parser error. You must use #set $x = {}
>
> It just seems unnecessarily strict, and the error message is obtuse.
>
> Once again, very sorry I haven't come through with putting the JSP/ 
> Spring
> stuff into CVS yet. I just haven't had any time. I am using it however
> daily. In December I will have a little more time as I will not  
> have so
> much work on, and will be using WM+Spring in a new project, so  
> hopefully I
> can put this stuff into a WM 2.1 for release in early 2006?
>
> I must confess though that last night I was thinking of moving to
> Velocity, purely because of the cleaner programmatic configuration  
> and no
> FastWriter issues etc.
>
> You see I want my new project to be able to do this kind of thing:
>
> WebMacro wm = (WebMacro)springContext.getBean("webmacroEngine");
> wm.addDirective( "getCMSContent", new CMSRepositoryReadDirective() );
>
> ...at runtime.
>
> Also after doing quite a lot of PHP I am startnig to wish that WM
> supported relative filenames for templates, relative to the current
> template location. Has anybody got ideas about doing that using a  
> custom
> TemplateLoader?
>
>
> Cheers
>
>
>
>
> -- 
> Lane Sharman
> Providing Private and SPAM-Free Email
> http://www.opendoors.com
> 858-755-2868
>
>

[Webmacro-devel] Planning://November 1 Is Official Release Date of WebMacro 2.0Final

[Lane S. <la...@op...>]

Guys,

For planning purposes, Nov 1 is the official release of 2.0. For many of 
you, this is a non-event. But, for me it is the culmination of a lot of 
work.

How about one you rogering up and writing a press release and making 
contact with the zines and developing some new buzz for WM 2.0?

-- 
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868

[Webmacro-devel] Global Processing

[Lane S. <la...@op...>]

Can someone give me a concise description of new global processing added 
to WM 2.

I added some programmatic features in a servlet, TemplateServlet.

thanks,

-- 
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868

[Webmacro-devel] RethrowableException and URLEncoder patch/code for WebMacro

[<Web...@St...>]

I submitted some code; a suggestion of a better java 1.4 compliant 
"NestedException" that doesn't emit those annoying double stacktraces when 
running on JVM >=1.4, and an URLEncoder that takes an encoding, thus 
working (!).

This doesn't seem to be in the cvs. Is there any reason for this? Can I do 
anything to make that happen?

Regards,
Endre.

Re: [Webmacro-devel] So the 2.0 drive died again??

[<Web...@St...>]

On Tue, 21 Jun 2005, Lane Sharman wrote:

| > It ain't much to test, really, except that the StackTraces actually gets
| > nicer.
| >  
| ok. I will look at it.

The verdict?

And the 2.0?

Endre

Re: [Webmacro-devel] So the 2.0 drive died again??

[Lane S. <la...@op...>]

We will get a release 2.1 around June 30.

Endre: did you commit some code and test cases?

-Lane

Endre St=F8lsvik wrote:

>On Sat, 18 Jun 2005, Marc Palmer wrote:
>
>| Endre St=F8lsvik wrote:
>| > /me still eagerly awaiting 2.0
>|=20
>| Nope... but it's blocking on me getting the Spring and JSP stuff into =
it,
>| which hasn't been possible because of work pressures. I'm on away for =
a week
>| now, but when I'm back I will endeavour to get this stuff in ASAP.
>|=20
>| You could always put out 2.0 RC2 / full release with the minor new Bro=
ker
>| changes that I committed and the JDK 1.5 compatibility, and we could r=
oll a
>| 2.1 with the Spring and JSP stuff in.
>
>I would find that approach "the right thing to do" - don't let new=20
>features block this "old release".
>
>But what about the very small JDK 1.5 stacktrace "compat" stuff I=20
>submitted? And the URLEncoder taking the output encoding?
>
>Endre.
>

--=20
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868

Re: [Webmacro-devel] So the 2.0 drive died again??

[<En...@St...>]

On Tue, 21 Jun 2005, Lane Sharman wrote:

| We will get a release 2.1 around June 30.

Oh, where did the 2.0 go?! ;)

| 
| Endre: did you commit some code and test cases?

I don't have any commit karma. But I sent some code the mailinglist's way.

It ain't much to test, really, except that the StackTraces actually gets 
nicer.

Endre.

Re: [Webmacro-devel] So the 2.0 drive died again??

[Lane S. <la...@op...>]

Endre St=F8lsvik wrote:

>On Tue, 21 Jun 2005, Lane Sharman wrote:
>
>| We will get a release 2.1 around June 30.
>
>Oh, where did the 2.0 go?! ;)
> =20
>
there have been some additions (and promises, marc???) that justify=20
going to 2.1.


>|=20
>| Endre: did you commit some code and test cases?
>
>I don't have any commit karma. But I sent some code the mailinglist's wa=
y.
>
>It ain't much to test, really, except that the StackTraces actually gets=
=20
>nicer.
> =20
>
ok. I will look at it.

-Lane

>Endre.
>
> =20
>

--=20
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868

Re: [Webmacro-devel] So the 2.0 drive died again??

[<Web...@St...>]

On Sat, 18 Jun 2005, Marc Palmer wrote:

| Endre St=F8lsvik wrote:
| > /me still eagerly awaiting 2.0
|=20
| Nope... but it's blocking on me getting the Spring and JSP stuff into i=
t,
| which hasn't been possible because of work pressures. I'm on away for a=
 week
| now, but when I'm back I will endeavour to get this stuff in ASAP.
|=20
| You could always put out 2.0 RC2 / full release with the minor new Brok=
er
| changes that I committed and the JDK 1.5 compatibility, and we could ro=
ll a
| 2.1 with the Spring and JSP stuff in.

I would find that approach "the right thing to do" - don't let new=20
features block this "old release".

But what about the very small JDK 1.5 stacktrace "compat" stuff I=20
submitted? And the URLEncoder taking the output encoding?

Endre.

Re: [Webmacro-devel] So the 2.0 drive died again??

[Marc P. <ma...@an...>]

Endre St=F8lsvik wrote:
> /me still eagerly awaiting 2.0

Nope... but it's blocking on me getting the Spring and JSP stuff into=20
it, which hasn't been possible because of work pressures. I'm on away=20
for a week now, but when I'm back I will endeavour to get this stuff in=20
ASAP.

You could always put out 2.0 RC2 / full release with the minor new=20
Broker changes that I committed and the JDK 1.5 compatibility, and we=20
could roll a 2.1 with the Spring and JSP stuff in.

Cheers
--=20
Marc Palmer    wj...@wa...
		=09
Wangjammers - Java, J2ME and Web Consultants
   ~ http://www.wangjammers.org/

[Webmacro-devel] So the 2.0 drive died again??

[<Web...@St...>]

/me still eagerly awaiting 2.0

Endre

Re: [Webmacro-devel] New RethrowableException impl..

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

OK, I looked at the code briefly.  Here's one suggestion: The version 
test could be done once in a static block.  Granted it's not really 
important to optimize stacktrace dumping, but it makes the code a bit 
cleaner as well.

Keats

Sample code:

    final private static boolean IS_PRE_1_4;
    static {
        boolean pre14;
        try {
            // Check whether we find the 1.4 method 
Throwable.getStackTrace(), if so, use 1.4's built-in
            //  Exception chaining.
            Throwable.class.getDeclaredMethod("getStackTrace", new 
Class[] {});
            pre14 = false;
        }
        catch (NoSuchMethodException nsmE) {
           pre14 = true;
        }
        IS_PRE_1_4 = pre14;
    }


Endre Stølsvik wrote:

>On Wed, 25 May 2005, Keats Kirsch wrote:
>
>| I'll try to take a look at this soon -- though probably not for 2.0.
>
>why not?
>  
>

Re: [Webmacro-devel] New RethrowableException impl..

[<Web...@St...>]

|
| | I have actually done a similar introspection hack on the
| | URLEncode and URLDecode methods in the TextTool to get around the
| | annoying deprecation messages.  There is probably a slight amount of
| | overhead incurred by this, so I haven't decided whether to commit it or not.

The deprecation warning is warranted: it doesn't take charset into
account, which it definately should. We made a new tool for the
encoding-part, too, that works on all java versions (rather simple thing).
  Since WM knowns which encoding is in use, URLs should in general be
encoded using the same encoding.

A file is included.

Endre.

Re: [Webmacro-devel] New RethrowableException impl..

[<Web...@St...>]

On Thu, 26 May 2005, Endre St=F8lsvik wrote:

| On Wed, 25 May 2005, Keats Kirsch wrote:
|
| | I'll try to take a look at this soon -- though probably not for 2.0.
|
| why not?

And by the way: I included a file, which you can put in place of the
existing RethrowableException.java. (I didn't diff since a) It is only
this file, and b) the entire file is different, pretty much).
  You don't have to "take a look at it".  I did - or at least tried to.

Regards,
Endre

Re: [Webmacro-devel] New RethrowableException impl..

[<Web...@St...>]

On Wed, 25 May 2005, Keats Kirsch wrote:

| I'll try to take a look at this soon -- though probably not for 2.0.

why not?

|
| This is one of the few places where maintaining 1.3 compatibility is a
| pain.

I don't get it???

The whole point of my version is that it works with all java versions that
have the slightest amount of introspection abilities, which also
constitute the entire foundation on which WM is built. It fixes the
-direct- double-logging that the combo of WM and java 1.4 results in.


| I have actually done a similar introspection hack on the
| URLEncode and URLDecode methods in the TextTool to get around the
| annoying deprecation messages.  There is probably a slight amount of
| overhead incurred by this, so I haven't decided whether to commit it or not.

WM is _built entirely on introspection_. I don't get your concerns?

|
| At some point we should cut 1.3 loose.

I think that is a really bad idea. My mantra is to keep at least 2 "major"
versions back, and with Java, that means the minor-version (!). So when
1.6 comes (6.0), I'll start to look into the 1.4. This goes for
frameworks. WM is a framework. WM doesn't -need- any of the 1.4 features,
AT ALL. Why start to depend on any of that, because of a silly regexp?!

Regards,
Endre.

Re: [Webmacro-devel] New RethrowableException impl..

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

I'll try to take a look at this soon -- though probably not for 2.0.

This is one of the few places where maintaining 1.3 compatibility is a 
pain.  I have actually done a similar introspection hack on the 
URLEncode and URLDecode methods in the TextTool to get around the 
annoying deprecation messages.  There is probably a slight amount of 
overhead incurred by this, so I haven't decided whether to commit it or not.

At some point we should cut 1.3 loose.  Then we can start relying on 
some of the cool features of 1.4 like regex methods in the String 
class.  Or maybe we should just fork off a 1.5 version and get ahead of 
the curve ...

Keats

Endre Stølsvik wrote:

>The mix of RethrowableException's exception-chaining and java 1.4's
>exception chaining causes, at least on my setup, often extremely long
>stacktraces.
>
>The reason for this, is the "getCause()" implementation in the
>RethrowableException, or rather, that this "nested Exception" is
>retrofitted to make it "forward compatible" with java 1.4 by implementing
>getCause(), but that the rest of the class doesn't take this into
>consideration. The result is that one get -two- chaining mechanisms on
>top of each other: RethrowableException faithfully chains the exceptions,
>but then java 1.4 ALSO does this, seen by the "... 127 more" multiple
>croppings of the stacktraces.
>
>The included file is a quick adaption of my own implementation of the
>"NestedException" as I called this thing. It uses introspection to see if
>we're on a 1.4 platform, and if so, uses the native chaining support by
>invoking the corresponding super-methods, while if not, we do chaining
>ourself.
>  Btw; I simply included the entire file, since basically all lines are
>different and no other files are affected. Also, my editor reformats the
>entire file. I assume that if you chuck it into your editor (IDEA, is
>it?!), it is reformatted back to the WM-style?
>
>However, the Exception hierarchy in WebMacro was a bit too complicated for
>me to decipher within the small timeframe I had to submit this. Would it
>be possible for you folks to just -test- this thing and se if it behaves?
>(I must admit that I haven't got any projects using "WM2.0" at this time,
>since I can't use cvs-code in such projects..)
>  In particular, I didn't understand quite the "setContextLocation" method
>which is present a couple of places (The one in WebMacroException is
>weird: it checks the cause, and the root cause, but doesn't do anything
>with any Exceptions which happens to be inbetween), and also 4 Exceptions
>that inherit from Rethrowable overrides getMessage() - which seems to
>partly destroy the chaining mechanism for the message, and/or put the
>contextLocation info at the wrong place (typically at the end), instead of
>where it should have gone.
>  I believe that this could be redone quite nicely by instead -modifying-
>the message in the RethrowableException (which now is stored locally too,
>to handle the chaining), or drop the Rethrowable, and instead make
>WebMacroException nested, and let that one have a method
>"getContextLocation" which returns the value that was set previously, or
>null if none. This latter idea would be "correct" in my view.
>
>Well..
>
>It would have been nice to kill of the lenght of those stack traces, and
>get them more legible.
>
>Regrads,
>Endre.
>  
>

[Webmacro-devel] New RethrowableException impl..

[<Web...@St...>]

The mix of RethrowableException's exception-chaining and java 1.4's
exception chaining causes, at least on my setup, often extremely long
stacktraces.

The reason for this, is the "getCause()" implementation in the
RethrowableException, or rather, that this "nested Exception" is
retrofitted to make it "forward compatible" with java 1.4 by implementing
getCause(), but that the rest of the class doesn't take this into
consideration. The result is that one get -two- chaining mechanisms on
top of each other: RethrowableException faithfully chains the exceptions,
but then java 1.4 ALSO does this, seen by the "... 127 more" multiple
croppings of the stacktraces.

The included file is a quick adaption of my own implementation of the
"NestedException" as I called this thing. It uses introspection to see if
we're on a 1.4 platform, and if so, uses the native chaining support by
invoking the corresponding super-methods, while if not, we do chaining
ourself.
  Btw; I simply included the entire file, since basically all lines are
different and no other files are affected. Also, my editor reformats the
entire file. I assume that if you chuck it into your editor (IDEA, is
it?!), it is reformatted back to the WM-style?

However, the Exception hierarchy in WebMacro was a bit too complicated for
me to decipher within the small timeframe I had to submit this. Would it
be possible for you folks to just -test- this thing and se if it behaves?
(I must admit that I haven't got any projects using "WM2.0" at this time,
since I can't use cvs-code in such projects..)
  In particular, I didn't understand quite the "setContextLocation" method
which is present a couple of places (The one in WebMacroException is
weird: it checks the cause, and the root cause, but doesn't do anything
with any Exceptions which happens to be inbetween), and also 4 Exceptions
that inherit from Rethrowable overrides getMessage() - which seems to
partly destroy the chaining mechanism for the message, and/or put the
contextLocation info at the wrong place (typically at the end), instead of
where it should have gone.
  I believe that this could be redone quite nicely by instead -modifying-
the message in the RethrowableException (which now is stored locally too,
to handle the chaining), or drop the Rethrowable, and instead make
WebMacroException nested, and let that one have a method
"getContextLocation" which returns the value that was set previously, or
null if none. This latter idea would be "correct" in my view.

Well..

It would have been nice to kill of the lenght of those stack traces, and
get them more legible.

Regrads,
Endre.

Re: [Webmacro-devel] Broker changes and stuff

[Marc P. <ma...@an...>]

> >
> Cool.  What's the broken #macro issue?

Not an issue as such now. It was the #mymacro after a " problem. 

> It should be a very simple change.  I just need to get JavaCC set up on
> my box again.

It would be great if you could, but it really depends on whether there is
a new version yet that aviods use of the "enum" reserved word.
 
> 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.

new Broker... do you mean a WM 3 with horrible Broker dependencies removed
;-) 
 
> >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.

OK yes.
 
> >Thanks for all that Keats. Feels like we are the last guys in the WM
> >office ;-)
> >
> >  
> >
> :'(

Well I'm a die-hard :)

I'm seriously considering rewriting most/all of the WM docs, that is our
major failing. WM -is- a nicer product than Velocity, but we really need
to do the following:

1. Redo pretty much all the documentation, most of the wiki is terribly
out of date and not very helpful / disorganised (aren't all wikis!). The
Velocity documentation puts us to shame.

2. Make sure all the source has javadocs

3. Eliminate requirement for FastWriters. It's ridiculous that we can only
write to an OutputStream or a FastWriter but not a Writer.

4. Remove the dependency on the Broker implementation - we need to allow
WM to be configured from nice bean IoC / Dependency Injection container
APIs, from XML files or whatever. Forcing the old webmacro.properties
mechanism is very old fashioned.

5. Develop a "WM Tools" area on the website for people to submit tools,
and include all compatible Velocity tools in there too - if they're beans
it should all be fine. Perhaps even a Velocity tool adapter if needed. Why
not help people leverage their hard work :)

6. Get clean and simple, well-documented examples, especially for using WM
within other web frameworks such as JSP and Spring.

I know, it's not much is it ;-)

> I finally got your taglib code working last night.  (It took me a while
> to realize that you had compiled with Java 5.)

Ooops sorry, IDE setting. It doesn't need it.

> 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?

Sounds good - although I'm not sure what you mean by a handler and what it
would be used for.

I'll do the ID thing now.

> 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.

OK thanks, I'll try it soon.

Cheers

Re: [Webmacro-devel] Solution to the context/classpath problem?

[Marc P. <ma...@an...>]

> > Well:
> >
> > 1. is that always guaranteed to be the case
> 
> That's what the Java docs say.  (Although I admit I don't know why they
> return it as an Object.)

Actually I was thinking, it may be that getRequestDispatcher(
pageContext.getServletConfig().getServletName()) would give us a
dispatcher for the JSP that is loaded on the webapps classloader.

I've changed the JSP taglib code to use
pageContext().getPage().getClass().getClassLoader() for now.

> > 3. it doesn't work from Spring views.
> 
> I don't know Spring, but don't you have access to the pageContext
> anywhere?

PageContext is a JSP thing. The Spring view I have is native WM for
Spring, although you can also (and I have) use the WM JSP taglib with
Spring using the default JSP view.

> > 4. it requires a lazy init of the single-instance of WM. I have added
> > this to the taglib code already, so that it can use
> ServletContextBroker.
> 
> Or we could add a new constructor to WM ...

I'll do it. I'm also refactoring my changes to make it so we can retain
the detection of Servlet20/22 and still have this functionality to specify
the classloader instead of the servlet.
 
> > The problem is you can't get WM to load context tools etc from the 
> > webapp classpath if you don't have the servlet classpath.
> 
> Unless you add a new getBroker method ... or a new Broker.

Well you still can't do that unless you can reference the webapp's
ClassLoader from somewhere reliably. 

> I don't like either, but I can't say exactly why.  It just seems to 
> violate the KISS principle.  It's a kludge that doesn't seem necessary.

Well we'll need to see how this pans out. I'm still not sure how we can
get access to the webapp classloader reliably (even with shared WM and/or
Spring JARs) in Spring. RequestDispatcher might do it but again I'm not
confident because you typically use Spring's generic DispatcherServlet
(which delegates to controller classes) which could be loaded from a
shared JAR so you probably wouldn't get the right classloader from it.

Unless anyone else has any insights I think a servletContext attribute for
the classloader is about the only option.

...hmmm although it might be possible to get a known bean application from
the Spring bean factory, or the classloader used by the bean factory. Ugh
this is all so ugly!

The trouble is there's big scope to break existing classloading mechanisms
if this isn't done right.

Re: [Webmacro-devel] Broker changes and stuff

[<Web...@St...>]

On Tue, 24 May 2005, Keats Kirsch wrote:

| Marc Palmer wrote:
|
| >Hi all,
| >
| >FYI I added a 2.0 RC1 release announcement to the SF news feed for WM,
| >nobody else seems to have done it. I know there is at least 1 site that
| >takes the SF WM RSS feed :-)
| >
| >
| Thanks!  I don't suppose you'd like to do the Freshmeat.net announcement
| as well?
|
| >I'm working on this new ServletContextBroker implementation. My plan is
| >that templates will never be loaded from a ClassLoader, only by
| >ServletContext.getResource. I think this is a cleaner model, i.e. people
| >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.

"Standard templates" that are shared sounds -really bad- to me: the same
goes for those libraries that are put in "shared" folders and whatnot.
Simply really bad, as writing to files within the webapp etc. One violate
the intention of the spec - a .war should be self-contained.

But anyway, I actually need to be able to load templates from the jars
within WEB-INF/lib (these jars, with their templates, are like contained
applications in our portal system) - I was thinking of doing this by
"manually" reading within the jars - you have access to the jar-files (if
I understand correctly) from the ResourceLoader. This way you wouldn't be
violating any limits from the SecMgr..
  I realize that this is way to much to ask for of WM by now, so I'll do
that myself.

Btw: ant is required for webmacro to build (!!) - no, really, some of the
java-files require it. But I assume you may say that since the entire
build system needs ant, you don't need to bundle that jar..

Regards,
Endre

Re: [Webmacro-devel] Broker changes and stuff

[<Web...@St...>]

| >
| 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?)

You might know this real good, but I'll just comment anyway: When doing a
java 5 build, set the (source and) target prop(s) of javac to 1.2, and
preferrably set the rt.jar (bootclasspath) to a 1.2 installation, so that
you ensure that one isn't using 1.3-1.5 stuff, and that it can be run on
all VMs from then to now (it is a byte in the class-file that old vm's
stall on, as intended).
  The source flag, come to think about it, might "fix" the problem with
enum? Hacky, ugly fix, but you might be able to compile it, at least?


--=20
Endre St=F8lsvik -  Endre@CoreTrek.[no|com]
   Work[+47 23100271] Mobile[+47 93054050] Fax[+47 23100299]

Re: [Webmacro-devel] Solution to the context/classpath problem?

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

Marc Palmer wrote:

> Keats Kirsch wrote:
>
>> I don't like the "smell" of this.  Why do you need it anyway?  If you 
>> need the Servlet instance you can just use:
>>
>> (Servlet)pageContext.getPage()
>
>
> Well:
>
> 1. is that always guaranteed to be the case

That's what the Java docs say.  (Although I admit I don't know why they 
return it as an Object.)

> 2. will it definitely be the same classloader as a servlet in the same 
> webapp, and the same for all JSPs that use the taglib in that webapp?

It is the servlet that the page gets compiled into, so it should be fine.

> 3. it doesn't work from Spring views.

I don't know Spring, but don't you have access to the pageContext anywhere?

> 4. it requires a lazy init of the single-instance of WM. I have added 
> this to the taglib code already, so that it can use ServletContextBroker.

Or we could add a new constructor to WM ...

>> Anyway, I thought you didn't need to use the Servlet instance if you 
>> use the new Broker -- wasn't that the point?
>
>
> True, but you were the one who said there should be an option to load 
> things from the servlet classpath :)
>
> The problem is you can't get WM to load context tools etc from the 
> webapp classpath if you don't have the servlet classpath.

Unless you add a new getBroker method ... or a new Broker.

> I think my solution is neat, in an ugly way :(
>
> It's a quick and easy way to solve the problem, without violating any 
> particular rules I know of.
>
> The other option would be to put the Servlet or its ClassLoader into a 
> predefined JNDI naming context. Do you like that less, or more ;-(
>
I don't like either, but I can't say exactly why.  It just seems to 
violate the KISS principle.  It's a kludge that doesn't seem necessary.

Keats

Re: [Webmacro-devel] Solution to the context/classpath problem?

[Marc P. <ma...@an...>]

Keats Kirsch wrote:
> I don't like the "smell" of this.  Why do you need it anyway?  If you 
> need the Servlet instance you can just use:
> 
> (Servlet)pageContext.getPage()

Well:

1. is that always guaranteed to be the case
2. will it definitely be the same classloader as a servlet in the same 
webapp, and the same for all JSPs that use the taglib in that webapp?
3. it doesn't work from Spring views.
4. it requires a lazy init of the single-instance of WM. I have added 
this to the taglib code already, so that it can use ServletContextBroker.

> Anyway, I thought you didn't need to use the Servlet instance if you use 
> the new Broker -- wasn't that the point?

True, but you were the one who said there should be an option to load 
things from the servlet classpath :)

The problem is you can't get WM to load context tools etc from the 
webapp classpath if you don't have the servlet classpath.

I think my solution is neat, in an ugly way :(

It's a quick and easy way to solve the problem, without violating any 
particular rules I know of.

The other option would be to put the Servlet or its ClassLoader into a 
predefined JNDI naming context. Do you like that less, or more ;-(

-- 
Marc Palmer    wj...@wa...
			
Wangjammers - Java, J2ME and Web Consultants
   ~ http://www.wangjammers.org/

Re: [Webmacro-devel] Solution to the context/classpath problem?

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

I don't like the "smell" of this.  Why do you need it anyway?  If you 
need the Servlet instance you can just use:

(Servlet)pageContext.getPage()

Anyway, I thought you didn't need to use the Servlet instance if you use 
the new Broker -- wasn't that the point?

Keats

Marc Palmer wrote:

>I'm off home now from work but I just had an idea I need to get down...
>
>The problem with both the Spring view implementation for WM and the WM JSP
>Taglib is that they can only access the ServletContext, and all the
>methods to access individual servlets are deprecated. Therefore we cannot
>be sure we can get to the servlets' classloader.
>
>However... we can access context attributes. So we could define a special
>WM context attribute such as "webmacro.template.classloader" - and anybody
>who wants to use these the taglib or Spring view can just make their
>servlet set this context attribute at startup to the servlet's ClassLoader.
>
>I can then make ServletContextBroker look for this magic value and use it
>if  it is found, or default to the classloader that loaded WM if not.
>
>What do you think?
>
>Cheers
>
>
>  
>

[Webmacro-devel] Solution to the context/classpath problem?

[Marc P. <ma...@an...>]

I'm off home now from work but I just had an idea I need to get down...

The problem with both the Spring view implementation for WM and the WM JSP
Taglib is that they can only access the ServletContext, and all the
methods to access individual servlets are deprecated. Therefore we cannot
be sure we can get to the servlets' classloader.

However... we can access context attributes. So we could define a special
WM context attribute such as "webmacro.template.classloader" - and anybody
who wants to use these the taglib or Spring view can just make their
servlet set this context attribute at startup to the servlet's ClassLoader.

I can then make ServletContextBroker look for this magic value and use it
if  it is found, or default to the classloader that loaded WM if not.

What do you think?

Cheers