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

Re: [Webmacro-devel] 2.0 refactor done yet?

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

On Monday, June 30, 2003, at 11:39  AM, Marc Palmer wrote:

> I can't make out from CVS notifications if this has been done yet -  
> has it?

we have yet to agree on a package structure...

eric

>
> If not, was it Eric or Brian that volunteered?
>
> Marc
>
>
> --  
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/ 
> 01
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] 2.0 refactor done yet?

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

I can't make out from CVS notifications if this has been done yet - has it?

If not, was it Eric or Brian that volunteered?

Marc


-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] #templet directive

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

On Fri, 27 Jun 2003 16:33:48 -0400, Keats <ke...@ea...> wrote:

> So that leaves just:
>
> #eval $templet
>
> and
>
> #eval $templet using $map
>
> the first syntax is actually the same as just
>
> $templet
>
> so we might leave that out as well.  Simple is good.

That looks much better to me. #template plus direct eval of template (using 
current context) or #eval $template using $map to use another context. I 
assume #eval will work with any Macro object, thus making it possible to 
use it with Macros created by other directives in the future.

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] #templet directive

[Keats <ke...@ea...>]

I don't think the "to" option is worthwhile.  You can accomplish the same
thing with a simple #setblock:

#setblock $var { #eval $templet using $map }

So that leaves just:

#eval $templet

and

#eval $templet using $map

the first syntax is actually the same as just

$templet

so we might leave that out as well.  Simple is good.

Keats


----- Original Message -----
From: Lane Sharman
To: Keats
Cc: Sebastian Kanthak ; web...@li...
Sent: Thursday, June 26, 2003 12:34 AM
Subject: Re: [Webmacro-devel] #templet directive


Directives are just that. They provide direction and control over the flow.
A Directive is an intrinsic keyword for the WebMacro parser and evaluation
engine.

A property is an operator returning void, null, or an object. In the latter
case, the object's string representation is added to the stream unless we
are talking about assignment: #set $foo = $bar. A property is expanded. A
directive is interpreted.

As to the output directive, I agree that it complicates things. I think we
should stick with directives which enhance the language. Property tools are
the right place to do transformations and evaluations. I think we could use
some that are more utilitarian for those who are creating non-web text and
interacting with data flows as occurs in application integration.

Can we finalize #templet now?


#eval $template using { "foo":"a", "bar":"b" }
#eval $template to $variable using { "foo":"a", "bar":"b" }
#eval $template
#eval $template to $variable

Would be the #eval variations as I see them. The first two create an
explicit context and the last two use the current context. The using ...
option provides a nice way of creating a private context for the templet.
The using ... option implies that the templet cannot update the context of
the invoker.

-Lane





Keats wrote:

I think your inference is falacious.  Many directives write to the output
stream, some use block arguments and some don't.  The #include directive
writes to the stream without a block arg.  (And of course macros do this,
but that's another issue.)

I do think that a clear distinction between "expansion" -- putting something
into the output stream, and "evaluation" -- performing some computation,
would be helpful, but I can't think of a good way to do this without
radically changing the WM syntax.

It seems like the pattern that we've developed is that you use tools or
functions for basic value transformations -- HTMLEscape, URLEncode,
Math.mod, etc -- and directives for everything else.

Better documentation would probably help here.  Perhaps a taxonomy of
directives, like:

Control flow directives:

#if/#elseif/#else
#foreach
#count

Context altering directives (variable creation):

#set
#setblock
#const/#attribute/#param
#macro
#alternate
#bean
#templet

Text expansion directives:

#include
#eval
#text

Other:

#comment
#type
#profile

Keats

----- Original Message -----
From: "Sebastian Kanthak" <seb...@mu...>
To: "Keats" <ke...@ea...>
Cc: <web...@li...>
Sent: Wednesday, June 25, 2003 3:25 PM
Subject: Re: [Webmacro-devel] #templet directive



Hi,

On Monday 23 June 2003 16:37, Keats wrote:

You could still do this sort of thing with the $Template tool.  People
didn't seem to like the template tool syntax, so I came up with the
directive approach which seems a bit more user friendly.

My approach to the above would be to use a directive for the writer, say
#output

ok, let's forget about the output thing. I only used this as an example.

Like

Brian, I personally do not think think it is necessary, but if Lane has a
need for it, it's ok.

My problem with the #eval-directive is of a more general nature:

In WebMacro we basically have to possibilities to control the result of a
template evaluation:

1) We can insert something into the output stream. This is usually done by

a

property reference $foo.bar

2) We can interact with the template engine and tell it to iterate certain
blocks, chose one depending on a condition, set some properties and so on.

Intuitively I think, that writing something into the output-stream (point

1)

should be done via property references of the form $... and point 2 should

be

done via directives.

Or to put it the other way round: I believe, that directives should not

output

anything by themselves. Of course the "#foreach" directive outputs a lot,

but

that comes from the block inside the directive, not from the directive
itself. The same holds for "#if" and "#set" does not output anything at

all.

This is similar to the distinction between statements and expressions in

most

programming languages. I just realized, that this is how I thought about
directives and property-refernces until now.

In this picture a #templet directive would fit quite nice, because it just
declares a template. However, for evaluating, I would find a $... syntax
nicer.

However, I must admit, that there exists directives (like those declared

from

macros), that do not fit in my own schema, so it is probably broken.

But perhaps we can have some discussion about it: Do we have a consistent
guideline, when to use $... syntax (via tools or macros) and when to use
directives? I do not know of one and this is, where my confusion comes

from.

Sebastian

--
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] WM site (Eric?)

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

On Tuesday, June 24, 2003, at 11:54  AM, Eric B. Ridge wrote:

> On Tuesday, June 24, 2003, at 09:53  AM, Marc Palmer wrote:
>
>>
>> Guys,
>>
>> We need the top www.webmacro.org page to be a WM "news" page so that 
>> people know we are still alive. The "About WM" stuff should be on an 
>> "About" page.
>>
>> I can't do this because I don't have the required wiki permissions.
>
> Okay.  I'll commit to getting Wiki updated with the user admin stuff 
> this week (by Friday night).  All the code is in CVS and it works 
> correctly.

I haven't had an opportunity to do this.  I'll try to take care of it 
sometime this weekend.

eric

RE: [Webmacro-devel] Crazy solution . webmacro hungs in templates that use the 'as macro' directive

[<lib...@in...>]

Well,

I found a solution that works, but that does not give me any clue to =
what the hell is happening here. And then, I dont know for how much time =
it will work.

The solution is simple: I rename this turnos.wmm to something different, =
like turnos2.wmm and it works.

I really don't know why. And I am afraid it may happen again if I dont =
see a reason to be avoided.

I thought it perhaps has something to do with the accents used in =
spanish that appear there, like =E1, =E9...

the other wm files look like this:

[header.wmi]
#include as macro "turnos.wmm"
<HTML><BODY>

[footer.wmi]
</BODY></HTML>

[navbar.wm]
#include as macro "header.wmi"

hello, I am the navbar

#include "footer.wmi"

[main.wm]
#include as macro "header.wmi"

hello, I am the main window

#include "footer.wmi"

[END]
This is a simplified version, that also has the same problem. In =
reality, I use to include more wmm files at the header, and the header =
is more complex, as well as the other files. But this simple =
configuration still fails.

Well, that is all.=20

Is anything in webmacro serializable? I mean, can it be that the =
cachemanager of webmacro serializes things when the servlet runner =
restarts or stops, so to retake it when it starts?=20
In that case, perhaps an explanation would be that the part that =
corresponds to this file got corrupted, dont know how or why, forever, =
perhaps the file is saved with a different encoding or something.=20


I am not crazy, it is really happening this way. I hope you manage to =
reproduce the phenomenon if you try.
BTW, I only include this file in the header, so there are no cyclic =
#inclusions.=20


Best regards,
Dario.



-----Original Message-----
From: Dar=EDo Liberman=20
Sent: Thursday, June 26, 2003 11:23
To: Eric B. Ridge
Cc: web...@li...
Subject: RE: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates =
that use the 'as macro' directive

Eric, first of all, thanks a lot for your help.

I have also looked at the code for the include directive the other day, =
and it seems be ok to me too. I wonder if it is a problem in the cache =
manager (that is also the reason I tried to solve the problem forbidding =
the refresh in the cache). Perhaps the include directive asks the broker =
or something for the template to include, and the call never returns.

I have not defined any recursion. And as I said, it has nothing to do =
with execution of macros, just the inclusion of the file that defines =
the macros suffices to hung the request FOREVER.

One test I have made is AFTER the hung phenomenon occurred, I upload a =
new wm that says hello.
* It obviously works, because it does not include anything.
then I uploaded a second file with macro definitions and changed the =
hello to just include it.
* It works.
then I change the main file to execute a macro that was included.
* It works.
then I change the main file to just include the same macro definitions =
file that was in common for the 2 requests that made the thing hung.
* It gets hung!!!!

Does it give any clue to the point?

I will try to isolate the problem even more, so I can send you wms. =
right now I think they are too big for you to analyze, it will take you =
a lot of work to find the problem.

Thanks a lot,
Dario.

-----Original Message-----
From: Eric B. Ridge [mailto:eb...@tc...]=20
Sent: Wednesday, June 25, 2003 23:05
To: Dar=EDo Liberman
Cc: web...@li...
Subject: Re: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates =
that use the 'as macro' directive

Dario, I think it would be helpful if you sent us the main template and=20
the template being #included.

I've just looked at the sources and I see nothing in IncludeDirective=20
that would cause WM to hang... I did write IncludeDirective so I might=20
be blinded by my own ego here, but it all looks good.

Other bits of information such as how long your request hangs would be=20
useful.  Do you eventually get an OutOfMemory or StackOverflow error? =20
Right now, assuming #include is good, all I can think of that would=20
cause things to hang is if you have some kind of endless recursion or=20
self-referential thing going on in one of these templates.

eric

On Wednesday, June 25, 2003, at 04:57  PM, Dar=EDo Liberman wrote:

> Hi,
>
> I am still trying to tackle this problem, I think I am getting close.
>
> This is the phenomenon:
> 	When I request multiple pages at the same time with the same=20
> jsessionid, webmacro hungs if the requests use wm files that in turn=20
> include as macro a common file with macro definitions.
> It does not matter whether I use any macro at all or not. The fact of=20
> including as macro the same file breaks it.
>
> I updated the wm properties to have this:
>
> SMapCacheManager.*.ExpireTime: -1
> SMapCacheManager.*.ReloadOnChange: false
>
> And now, if I first call a single request that at the end includes as=20
> macro the common file with macro definitions (so that it gets cached), =

> then when I pass the test of multiple requests it works. (without the=20
> first request to let it "warm up", this same test manages to break=20
> webmacro)
>
> I emphasize that only those requests that use as macro the common file =

> that was included by the simultaneous test get hung. Other request=20
> that do not include as macro anything or that include as macro a new=20
> file get served correctly.
>
> finally, at development environment, putting a 5sec delay between each =

> request solves the problem (not needing to get the reloadOnChange to=20
> be annulated).
>
> Anyway I would like to know what is happening, and perhaps, despite=20
> all, the problem is not in webmacro, but somewhere else, and this=20
> changes only work because of faster performance.
>
>
> Any guess may enlight to see the problem. Please give this issue a=20
> glimpse.
> At least ask me anything.
>
>
> Thanking you all a lot,
> Dario.
>
>
>
>
>
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Tuesday, June 24, 2003 12:26
> To: web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> Does Any body have a clue why this is happening???
>
> It seems that it only happens at the sun server with Jrun3.0
> In the development environment with Jrun3.1 on Windows NT it is not=20
> happening.
>
> Thanks,
> Dario.
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Friday, June 20, 2003 18:45
> To: ma...@an...; web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> Thanks a lot for the prompt replay,
>
> I changed parse to include... but I don't think it has to do with it.
>
> I added the LogLevel=3DDEBUG
>
>
> What I managed to see is that I can reproduce the problem:
>
> I have an application that loads fisrt a login page. After login it=20
> creates 2 browsers and then sets the 2 urls to start with.
> Both urls lead to use webmacro for presentation. The wm files are=20
> different but include as macro the same files.
>
> The first time I login, everything goes ok.
> The second time, all cached wmm files seem to get corrupted or=20
> something.
> Any wm file that includes as macro any of the cached files leads to=20
> hung up.
> Wm files that include as macro new macro files (i.e. not cached) work=20
> well. Of course also wm files that do not include as macro any file at =

> all also keep working.
>
> I believe the problem is that since the 2 browsers get connected one=20
> right after the other, the request get to be processed at the same=20
> time, and then some critical section is not marked as synchronized and =

> boom!
> But I am not so sure now, since I have put now a delay between the 2=20
> requests and it seems to generate problems anyway.
>
> I send 2 logs, the first is after startup and it works well.
> The second is the continuation and it does not work well.
>
> Now that I have put the delay it is not working never... I don't=20
> understand.
> When I manually do the process with a navigator, it works, but when=20
> the program does it by itself, it breaks webmacro.
>
> Any guess is welcome.
>
> Salutations,
> Dario.
>
> -----Original Message-----
> From: Marc Palmer [mailto:ma...@an...]
> Sent: Friday, June 20, 2003 12:33
> To: web...@li...
> Subject: Re: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> On Fri, 20 Jun 2003 11:53:36 -0300, Dar=EDo Liberman =
<lib...@in...>
> wrote:
>
>> Hello!
>>
>>
>> Well, I am facing a big problem: Webmacro seems to hung up when=20
>> parsing
>> templates that use the 'parse as macro' directive. WM files =
containing
>> the parse directive but without the 'as macro' still keep working.
>> It occurs after a while of using it. I still don't find a particular
>> cause.
>
> First, use #include. That probably won't make a difference but #parse=20
> is
> deprecated.
>
>> Till now it always seems to happen at the first contact of the user. =
I
>> don't know if it has to be with the fact that the server is not asked =

>> for
>> request for many hours and some thread goes to sleep, or what. Or=20
>> perhaps
>> it has to be with the session handling (the first time I perform an
>> invalidation).
>> It is very difficult to track it, because it happens only at the
>> production server till now, and it does it at seldom times.
>>
>> I am using WM-VERSION-1.1final called from a servlet class that=20
>> extends
>> WMServlet and it all runs on Jrun version 3.0 with apache 1.3.14 on
>> Solaris.
>>
>> I hope someone can help me out.
>>
>> Is there any option to turn on some logging to see where it stops
>> processing?
>
> Yes. Edit your WebMacro.properties and add:
>
> LogLevel=3DDEBUG
>
>> PD: By the way, when I say it hungs up, I mean that it stays there=20
>> doing
>> nothing holding all the resources. every time I request a page, the
>> apache uses another process and it does never finish the processing=20
>> of it
>> (it does not show it on the access_log), it remains running there, =
and
>> every request opens yet another process.
>
> Do you have lots of memory and virtual memory? If so you might find it =

> is
> in an infinite loop and taking a long time to produce a stack =
overflow.
> Does your macro template do any recursive calls to macros?
>
> Marc
>
> --=20
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] Ignition on Resin...

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

FYI - Re-tested and Ignition works happily on Resin 2.1.10

It looks like the problems are only with 3.x - and therefore likely to be 
Resin bugs.

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

RE: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates that use the 'as macro' directive

[<lib...@in...>]

Eric, first of all, thanks a lot for your help.

I have also looked at the code for the include directive the other day, =
and it seems be ok to me too. I wonder if it is a problem in the cache =
manager (that is also the reason I tried to solve the problem forbidding =
the refresh in the cache). Perhaps the include directive asks the broker =
or something for the template to include, and the call never returns.

I have not defined any recursion. And as I said, it has nothing to do =
with execution of macros, just the inclusion of the file that defines =
the macros suffices to hung the request FOREVER.

One test I have made is AFTER the hung phenomenon occurred, I upload a =
new wm that says hello.
* It obviously works, because it does not include anything.
then I uploaded a second file with macro definitions and changed the =
hello to just include it.
* It works.
then I change the main file to execute a macro that was included.
* It works.
then I change the main file to just include the same macro definitions =
file that was in common for the 2 requests that made the thing hung.
* It gets hung!!!!

Does it give any clue to the point?

I will try to isolate the problem even more, so I can send you wms. =
right now I think they are too big for you to analyze, it will take you =
a lot of work to find the problem.

Thanks a lot,
Dario.

-----Original Message-----
From: Eric B. Ridge [mailto:eb...@tc...]=20
Sent: Wednesday, June 25, 2003 23:05
To: Dar=EDo Liberman
Cc: web...@li...
Subject: Re: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates =
that use the 'as macro' directive

Dario, I think it would be helpful if you sent us the main template and=20
the template being #included.

I've just looked at the sources and I see nothing in IncludeDirective=20
that would cause WM to hang... I did write IncludeDirective so I might=20
be blinded by my own ego here, but it all looks good.

Other bits of information such as how long your request hangs would be=20
useful.  Do you eventually get an OutOfMemory or StackOverflow error? =20
Right now, assuming #include is good, all I can think of that would=20
cause things to hang is if you have some kind of endless recursion or=20
self-referential thing going on in one of these templates.

eric

On Wednesday, June 25, 2003, at 04:57  PM, Dar=EDo Liberman wrote:

> Hi,
>
> I am still trying to tackle this problem, I think I am getting close.
>
> This is the phenomenon:
> 	When I request multiple pages at the same time with the same=20
> jsessionid, webmacro hungs if the requests use wm files that in turn=20
> include as macro a common file with macro definitions.
> It does not matter whether I use any macro at all or not. The fact of=20
> including as macro the same file breaks it.
>
> I updated the wm properties to have this:
>
> SMapCacheManager.*.ExpireTime: -1
> SMapCacheManager.*.ReloadOnChange: false
>
> And now, if I first call a single request that at the end includes as=20
> macro the common file with macro definitions (so that it gets cached), =

> then when I pass the test of multiple requests it works. (without the=20
> first request to let it "warm up", this same test manages to break=20
> webmacro)
>
> I emphasize that only those requests that use as macro the common file =

> that was included by the simultaneous test get hung. Other request=20
> that do not include as macro anything or that include as macro a new=20
> file get served correctly.
>
> finally, at development environment, putting a 5sec delay between each =

> request solves the problem (not needing to get the reloadOnChange to=20
> be annulated).
>
> Anyway I would like to know what is happening, and perhaps, despite=20
> all, the problem is not in webmacro, but somewhere else, and this=20
> changes only work because of faster performance.
>
>
> Any guess may enlight to see the problem. Please give this issue a=20
> glimpse.
> At least ask me anything.
>
>
> Thanking you all a lot,
> Dario.
>
>
>
>
>
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Tuesday, June 24, 2003 12:26
> To: web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> Does Any body have a clue why this is happening???
>
> It seems that it only happens at the sun server with Jrun3.0
> In the development environment with Jrun3.1 on Windows NT it is not=20
> happening.
>
> Thanks,
> Dario.
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Friday, June 20, 2003 18:45
> To: ma...@an...; web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> Thanks a lot for the prompt replay,
>
> I changed parse to include... but I don't think it has to do with it.
>
> I added the LogLevel=3DDEBUG
>
>
> What I managed to see is that I can reproduce the problem:
>
> I have an application that loads fisrt a login page. After login it=20
> creates 2 browsers and then sets the 2 urls to start with.
> Both urls lead to use webmacro for presentation. The wm files are=20
> different but include as macro the same files.
>
> The first time I login, everything goes ok.
> The second time, all cached wmm files seem to get corrupted or=20
> something.
> Any wm file that includes as macro any of the cached files leads to=20
> hung up.
> Wm files that include as macro new macro files (i.e. not cached) work=20
> well. Of course also wm files that do not include as macro any file at =

> all also keep working.
>
> I believe the problem is that since the 2 browsers get connected one=20
> right after the other, the request get to be processed at the same=20
> time, and then some critical section is not marked as synchronized and =

> boom!
> But I am not so sure now, since I have put now a delay between the 2=20
> requests and it seems to generate problems anyway.
>
> I send 2 logs, the first is after startup and it works well.
> The second is the continuation and it does not work well.
>
> Now that I have put the delay it is not working never... I don't=20
> understand.
> When I manually do the process with a navigator, it works, but when=20
> the program does it by itself, it breaks webmacro.
>
> Any guess is welcome.
>
> Salutations,
> Dario.
>
> -----Original Message-----
> From: Marc Palmer [mailto:ma...@an...]
> Sent: Friday, June 20, 2003 12:33
> To: web...@li...
> Subject: Re: [Webmacro-devel] webmacro hungs in templates that use the =

> 'as macro' directive
>
> On Fri, 20 Jun 2003 11:53:36 -0300, Dar=EDo Liberman =
<lib...@in...>
> wrote:
>
>> Hello!
>>
>>
>> Well, I am facing a big problem: Webmacro seems to hung up when=20
>> parsing
>> templates that use the 'parse as macro' directive. WM files =
containing
>> the parse directive but without the 'as macro' still keep working.
>> It occurs after a while of using it. I still don't find a particular
>> cause.
>
> First, use #include. That probably won't make a difference but #parse=20
> is
> deprecated.
>
>> Till now it always seems to happen at the first contact of the user. =
I
>> don't know if it has to be with the fact that the server is not asked =

>> for
>> request for many hours and some thread goes to sleep, or what. Or=20
>> perhaps
>> it has to be with the session handling (the first time I perform an
>> invalidation).
>> It is very difficult to track it, because it happens only at the
>> production server till now, and it does it at seldom times.
>>
>> I am using WM-VERSION-1.1final called from a servlet class that=20
>> extends
>> WMServlet and it all runs on Jrun version 3.0 with apache 1.3.14 on
>> Solaris.
>>
>> I hope someone can help me out.
>>
>> Is there any option to turn on some logging to see where it stops
>> processing?
>
> Yes. Edit your WebMacro.properties and add:
>
> LogLevel=3DDEBUG
>
>> PD: By the way, when I say it hungs up, I mean that it stays there=20
>> doing
>> nothing holding all the resources. every time I request a page, the
>> apache uses another process and it does never finish the processing=20
>> of it
>> (it does not show it on the access_log), it remains running there, =
and
>> every request opens yet another process.
>
> Do you have lots of memory and virtual memory? If so you might find it =

> is
> in an infinite loop and taking a long time to produce a stack =
overflow.
> Does your macro template do any recursive calls to macros?
>
> Marc
>
> --=20
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] #templet directive

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

Directives are just that. They provide direction and control over the 
flow. A Directive is an intrinsic keyword for the WebMacro parser and 
evaluation engine.

A property is an operator returning void, null, or an object. In the 
latter case, the object's string representation is added to the stream 
unless we are talking about assignment: #set $foo = $bar. A property is 
expanded. A directive is interpreted.

As to the output directive, I agree that it complicates things. I think 
we should stick with directives which enhance the language. Property 
tools are the right place to do transformations and evaluations. I think 
we could use some that are more utilitarian for those who are creating 
non-web text and interacting with data flows as occurs in application 
integration.

Can we finalize #templet now?

#eval $template using { "foo":"a", "bar":"b" }
#eval $template to $variable using { "foo":"a", "bar":"b" }
#eval $template
#eval $template to $variable

Would be the #eval variations as I see them. The first two create an explicit context and the last two use the current context. The using ... option provides a nice way of creating a private context for the templet. The using ... option implies that the templet cannot update the context of the invoker.

-Lane





Keats wrote:

>I think your inference is falacious.  Many directives write to the output
>stream, some use block arguments and some don't.  The #include directive
>writes to the stream without a block arg.  (And of course macros do this,
>but that's another issue.)
>
>I do think that a clear distinction between "expansion" -- putting something
>into the output stream, and "evaluation" -- performing some computation,
>would be helpful, but I can't think of a good way to do this without
>radically changing the WM syntax.
>
>It seems like the pattern that we've developed is that you use tools or
>functions for basic value transformations -- HTMLEscape, URLEncode,
>Math.mod, etc -- and directives for everything else.
>
>Better documentation would probably help here.  Perhaps a taxonomy of
>directives, like:
>
>Control flow directives:
>
>#if/#elseif/#else
>#foreach
>#count
>
>Context altering directives (variable creation):
>
>#set
>#setblock
>#const/#attribute/#param
>#macro
>#alternate
>#bean
>#templet
>
>Text expansion directives:
>
>#include
>#eval
>#text
>
>Other:
>
>#comment
>#type
>#profile
>
>Keats
>
>----- Original Message -----
>From: "Sebastian Kanthak" <seb...@mu...>
>To: "Keats" <ke...@ea...>
>Cc: <web...@li...>
>Sent: Wednesday, June 25, 2003 3:25 PM
>Subject: Re: [Webmacro-devel] #templet directive
>
>
>  
>
>>Hi,
>>
>>On Monday 23 June 2003 16:37, Keats wrote:
>>    
>>
>>>You could still do this sort of thing with the $Template tool.  People
>>>didn't seem to like the template tool syntax, so I came up with the
>>>directive approach which seems a bit more user friendly.
>>>
>>>My approach to the above would be to use a directive for the writer, say
>>>#output
>>>      
>>>
>>ok, let's forget about the output thing. I only used this as an example.
>>    
>>
>Like
>  
>
>>Brian, I personally do not think think it is necessary, but if Lane has a
>>need for it, it's ok.
>>
>>My problem with the #eval-directive is of a more general nature:
>>
>>In WebMacro we basically have to possibilities to control the result of a
>>template evaluation:
>>
>>1) We can insert something into the output stream. This is usually done by
>>    
>>
>a
>  
>
>>property reference $foo.bar
>>
>>2) We can interact with the template engine and tell it to iterate certain
>>blocks, chose one depending on a condition, set some properties and so on.
>>
>>Intuitively I think, that writing something into the output-stream (point
>>    
>>
>1)
>  
>
>>should be done via property references of the form $... and point 2 should
>>    
>>
>be
>  
>
>>done via directives.
>>
>>Or to put it the other way round: I believe, that directives should not
>>    
>>
>output
>  
>
>>anything by themselves. Of course the "#foreach" directive outputs a lot,
>>    
>>
>but
>  
>
>>that comes from the block inside the directive, not from the directive
>>itself. The same holds for "#if" and "#set" does not output anything at
>>    
>>
>all.
>  
>
>>This is similar to the distinction between statements and expressions in
>>    
>>
>most
>  
>
>>programming languages. I just realized, that this is how I thought about
>>directives and property-refernces until now.
>>
>>In this picture a #templet directive would fit quite nice, because it just
>>declares a template. However, for evaluating, I would find a $... syntax
>>nicer.
>>
>>However, I must admit, that there exists directives (like those declared
>>    
>>
>from
>  
>
>>macros), that do not fit in my own schema, so it is probably broken.
>>
>>But perhaps we can have some discussion about it: Do we have a consistent
>>guideline, when to use $... syntax (via tools or macros) and when to use
>>directives? I do not know of one and this is, where my confusion comes
>>    
>>
>from.
>  
>
>>Sebastian
>>
>>--
>>Sebastian Kanthak
>>PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: INetU
>>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>>_______________________________________________
>>Webmacro-devel mailing list
>>Web...@li...
>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

Re: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates that use the 'as macro' directive

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

Dario, I think it would be helpful if you sent us the main template and=20=

the template being #included.

I've just looked at the sources and I see nothing in IncludeDirective=20
that would cause WM to hang... I did write IncludeDirective so I might=20=

be blinded by my own ego here, but it all looks good.

Other bits of information such as how long your request hangs would be=20=

useful.  Do you eventually get an OutOfMemory or StackOverflow error? =20=

Right now, assuming #include is good, all I can think of that would=20
cause things to hang is if you have some kind of endless recursion or=20
self-referential thing going on in one of these templates.

eric

On Wednesday, June 25, 2003, at 04:57  PM, Dar=EDo Liberman wrote:

> Hi,
>
> I am still trying to tackle this problem, I think I am getting close.
>
> This is the phenomenon:
> 	When I request multiple pages at the same time with the same=20
> jsessionid, webmacro hungs if the requests use wm files that in turn=20=

> include as macro a common file with macro definitions.
> It does not matter whether I use any macro at all or not. The fact of=20=

> including as macro the same file breaks it.
>
> I updated the wm properties to have this:
>
> SMapCacheManager.*.ExpireTime: -1
> SMapCacheManager.*.ReloadOnChange: false
>
> And now, if I first call a single request that at the end includes as=20=

> macro the common file with macro definitions (so that it gets cached),=20=

> then when I pass the test of multiple requests it works. (without the=20=

> first request to let it "warm up", this same test manages to break=20
> webmacro)
>
> I emphasize that only those requests that use as macro the common file=20=

> that was included by the simultaneous test get hung. Other request=20
> that do not include as macro anything or that include as macro a new=20=

> file get served correctly.
>
> finally, at development environment, putting a 5sec delay between each=20=

> request solves the problem (not needing to get the reloadOnChange to=20=

> be annulated).
>
> Anyway I would like to know what is happening, and perhaps, despite=20
> all, the problem is not in webmacro, but somewhere else, and this=20
> changes only work because of faster performance.
>
>
> Any guess may enlight to see the problem. Please give this issue a=20
> glimpse.
> At least ask me anything.
>
>
> Thanking you all a lot,
> Dario.
>
>
>
>
>
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Tuesday, June 24, 2003 12:26
> To: web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the=20=

> 'as macro' directive
>
> Does Any body have a clue why this is happening???
>
> It seems that it only happens at the sun server with Jrun3.0
> In the development environment with Jrun3.1 on Windows NT it is not=20
> happening.
>
> Thanks,
> Dario.
>
>
> -----Original Message-----
> From: Dar=EDo Liberman
> Sent: Friday, June 20, 2003 18:45
> To: ma...@an...; web...@li...
> Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the=20=

> 'as macro' directive
>
> Thanks a lot for the prompt replay,
>
> I changed parse to include... but I don't think it has to do with it.
>
> I added the LogLevel=3DDEBUG
>
>
> What I managed to see is that I can reproduce the problem:
>
> I have an application that loads fisrt a login page. After login it=20
> creates 2 browsers and then sets the 2 urls to start with.
> Both urls lead to use webmacro for presentation. The wm files are=20
> different but include as macro the same files.
>
> The first time I login, everything goes ok.
> The second time, all cached wmm files seem to get corrupted or=20
> something.
> Any wm file that includes as macro any of the cached files leads to=20
> hung up.
> Wm files that include as macro new macro files (i.e. not cached) work=20=

> well. Of course also wm files that do not include as macro any file at=20=

> all also keep working.
>
> I believe the problem is that since the 2 browsers get connected one=20=

> right after the other, the request get to be processed at the same=20
> time, and then some critical section is not marked as synchronized and=20=

> boom!
> But I am not so sure now, since I have put now a delay between the 2=20=

> requests and it seems to generate problems anyway.
>
> I send 2 logs, the first is after startup and it works well.
> The second is the continuation and it does not work well.
>
> Now that I have put the delay it is not working never... I don't=20
> understand.
> When I manually do the process with a navigator, it works, but when=20
> the program does it by itself, it breaks webmacro.
>
> Any guess is welcome.
>
> Salutations,
> Dario.
>
> -----Original Message-----
> From: Marc Palmer [mailto:ma...@an...]
> Sent: Friday, June 20, 2003 12:33
> To: web...@li...
> Subject: Re: [Webmacro-devel] webmacro hungs in templates that use the=20=

> 'as macro' directive
>
> On Fri, 20 Jun 2003 11:53:36 -0300, Dar=EDo Liberman =
<lib...@in...>
> wrote:
>
>> Hello!
>>
>>
>> Well, I am facing a big problem: Webmacro seems to hung up when=20
>> parsing
>> templates that use the 'parse as macro' directive. WM files =
containing
>> the parse directive but without the 'as macro' still keep working.
>> It occurs after a while of using it. I still don't find a particular
>> cause.
>
> First, use #include. That probably won't make a difference but #parse=20=

> is
> deprecated.
>
>> Till now it always seems to happen at the first contact of the user. =
I
>> don't know if it has to be with the fact that the server is not asked=20=

>> for
>> request for many hours and some thread goes to sleep, or what. Or=20
>> perhaps
>> it has to be with the session handling (the first time I perform an
>> invalidation).
>> It is very difficult to track it, because it happens only at the
>> production server till now, and it does it at seldom times.
>>
>> I am using WM-VERSION-1.1final called from a servlet class that=20
>> extends
>> WMServlet and it all runs on Jrun version 3.0 with apache 1.3.14 on
>> Solaris.
>>
>> I hope someone can help me out.
>>
>> Is there any option to turn on some logging to see where it stops
>> processing?
>
> Yes. Edit your WebMacro.properties and add:
>
> LogLevel=3DDEBUG
>
>> PD: By the way, when I say it hungs up, I mean that it stays there=20
>> doing
>> nothing holding all the resources. every time I request a page, the
>> apache uses another process and it does never finish the processing=20=

>> of it
>> (it does not show it on the access_log), it remains running there, =
and
>> every request opens yet another process.
>
> Do you have lots of memory and virtual memory? If so you might find it=20=

> is
> in an infinite loop and taking a long time to produce a stack =
overflow.
> Does your macro template do any recursive calls to macros?
>
> Marc
>
> --=20
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting=20
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] #templet directive

[Keats <ke...@ea...>]

I think your inference is falacious.  Many directives write to the output
stream, some use block arguments and some don't.  The #include directive
writes to the stream without a block arg.  (And of course macros do this,
but that's another issue.)

I do think that a clear distinction between "expansion" -- putting something
into the output stream, and "evaluation" -- performing some computation,
would be helpful, but I can't think of a good way to do this without
radically changing the WM syntax.

It seems like the pattern that we've developed is that you use tools or
functions for basic value transformations -- HTMLEscape, URLEncode,
Math.mod, etc -- and directives for everything else.

Better documentation would probably help here.  Perhaps a taxonomy of
directives, like:

Control flow directives:

#if/#elseif/#else
#foreach
#count

Context altering directives (variable creation):

#set
#setblock
#const/#attribute/#param
#macro
#alternate
#bean
#templet

Text expansion directives:

#include
#eval
#text

Other:

#comment
#type
#profile

Keats

----- Original Message -----
From: "Sebastian Kanthak" <seb...@mu...>
To: "Keats" <ke...@ea...>
Cc: <web...@li...>
Sent: Wednesday, June 25, 2003 3:25 PM
Subject: Re: [Webmacro-devel] #templet directive


> Hi,
>
> On Monday 23 June 2003 16:37, Keats wrote:
> > You could still do this sort of thing with the $Template tool.  People
> > didn't seem to like the template tool syntax, so I came up with the
> > directive approach which seems a bit more user friendly.
> >
> > My approach to the above would be to use a directive for the writer, say
> > #output
>
> ok, let's forget about the output thing. I only used this as an example.
Like
> Brian, I personally do not think think it is necessary, but if Lane has a
> need for it, it's ok.
>
> My problem with the #eval-directive is of a more general nature:
>
> In WebMacro we basically have to possibilities to control the result of a
> template evaluation:
>
> 1) We can insert something into the output stream. This is usually done by
a
> property reference $foo.bar
>
> 2) We can interact with the template engine and tell it to iterate certain
> blocks, chose one depending on a condition, set some properties and so on.
>
> Intuitively I think, that writing something into the output-stream (point
1)
> should be done via property references of the form $... and point 2 should
be
> done via directives.
>
> Or to put it the other way round: I believe, that directives should not
output
> anything by themselves. Of course the "#foreach" directive outputs a lot,
but
> that comes from the block inside the directive, not from the directive
> itself. The same holds for "#if" and "#set" does not output anything at
all.
>
> This is similar to the distinction between statements and expressions in
most
> programming languages. I just realized, that this is how I thought about
> directives and property-refernces until now.
>
> In this picture a #templet directive would fit quite nice, because it just
> declares a template. However, for evaluating, I would find a $... syntax
> nicer.
>
> However, I must admit, that there exists directives (like those declared
from
> macros), that do not fit in my own schema, so it is probably broken.
>
> But perhaps we can have some discussion about it: Do we have a consistent
> guideline, when to use $... syntax (via tools or macros) and when to use
> directives? I do not know of one and this is, where my confusion comes
from.
>
> Sebastian
>
> --
> Sebastian Kanthak
> PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

RE: [Webmacro-devel] HELP PLEASE!!! webmacro hungs in templates that use the 'as macro' directive

[<lib...@in...>]

Hi,=20

I am still trying to tackle this problem, I think I am getting close.

This is the phenomenon:
	When I request multiple pages at the same time with the same =
jsessionid, webmacro hungs if the requests use wm files that in turn =
include as macro a common file with macro definitions.=20
It does not matter whether I use any macro at all or not. The fact of =
including as macro the same file breaks it.

I updated the wm properties to have this:

SMapCacheManager.*.ExpireTime: -1
SMapCacheManager.*.ReloadOnChange: false

And now, if I first call a single request that at the end includes as =
macro the common file with macro definitions (so that it gets cached), =
then when I pass the test of multiple requests it works. (without the =
first request to let it "warm up", this same test manages to break =
webmacro)

I emphasize that only those requests that use as macro the common file =
that was included by the simultaneous test get hung. Other request that =
do not include as macro anything or that include as macro a new file get =
served correctly.

finally, at development environment, putting a 5sec delay between each =
request solves the problem (not needing to get the reloadOnChange to be =
annulated).

Anyway I would like to know what is happening, and perhaps, despite all, =
the problem is not in webmacro, but somewhere else, and this changes =
only work because of faster performance.

=20
Any guess may enlight to see the problem. Please give this issue a =
glimpse.
At least ask me anything.


Thanking you all a lot,
Dario.



=20



-----Original Message-----
From: Dar=EDo Liberman=20
Sent: Tuesday, June 24, 2003 12:26
To: web...@li...
Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =
'as macro' directive

Does Any body have a clue why this is happening???

It seems that it only happens at the sun server with Jrun3.0
In the development environment with Jrun3.1 on Windows NT it is not =
happening.

Thanks,
Dario.


-----Original Message-----
From: Dar=EDo Liberman=20
Sent: Friday, June 20, 2003 18:45
To: ma...@an...; web...@li...
Subject: RE: [Webmacro-devel] webmacro hungs in templates that use the =
'as macro' directive

Thanks a lot for the prompt replay,

I changed parse to include... but I don't think it has to do with it.

I added the LogLevel=3DDEBUG


What I managed to see is that I can reproduce the problem:

I have an application that loads fisrt a login page. After login it =
creates 2 browsers and then sets the 2 urls to start with.
Both urls lead to use webmacro for presentation. The wm files are =
different but include as macro the same files.

The first time I login, everything goes ok.
The second time, all cached wmm files seem to get corrupted or =
something.
Any wm file that includes as macro any of the cached files leads to hung =
up.
Wm files that include as macro new macro files (i.e. not cached) work =
well. Of course also wm files that do not include as macro any file at =
all also keep working.

I believe the problem is that since the 2 browsers get connected one =
right after the other, the request get to be processed at the same time, =
and then some critical section is not marked as synchronized and boom!=20
But I am not so sure now, since I have put now a delay between the 2 =
requests and it seems to generate problems anyway.

I send 2 logs, the first is after startup and it works well.
The second is the continuation and it does not work well.

Now that I have put the delay it is not working never... I don't =
understand.
When I manually do the process with a navigator, it works, but when the =
program does it by itself, it breaks webmacro.

Any guess is welcome.

Salutations,
Dario.

-----Original Message-----
From: Marc Palmer [mailto:ma...@an...]=20
Sent: Friday, June 20, 2003 12:33
To: web...@li...
Subject: Re: [Webmacro-devel] webmacro hungs in templates that use the =
'as macro' directive

On Fri, 20 Jun 2003 11:53:36 -0300, Dar=EDo Liberman =
<lib...@in...>=20
wrote:

> Hello!
>
>
> Well, I am facing a big problem: Webmacro seems to hung up when =
parsing=20
> templates that use the 'parse as macro' directive. WM files containing =

> the parse directive but without the 'as macro' still keep working.
> It occurs after a while of using it. I still don't find a particular=20
> cause.

First, use #include. That probably won't make a difference but #parse is =

deprecated.

> Till now it always seems to happen at the first contact of the user. I =

> don't know if it has to be with the fact that the server is not asked =
for=20
> request for many hours and some thread goes to sleep, or what. Or =
perhaps=20
> it has to be with the session handling (the first time I perform an=20
> invalidation).
> It is very difficult to track it, because it happens only at the=20
> production server till now, and it does it at seldom times.
>
> I am using WM-VERSION-1.1final called from a servlet class that =
extends=20
> WMServlet and it all runs on Jrun version 3.0 with apache 1.3.14 on=20
> Solaris.
>
> I hope someone can help me out.
>
> Is there any option to turn on some logging to see where it stops=20
> processing?

Yes. Edit your WebMacro.properties and add:

LogLevel=3DDEBUG

> PD: By the way, when I say it hungs up, I mean that it stays there =
doing=20
> nothing holding all the resources. every time I request a page, the=20
> apache uses another process and it does never finish the processing of =
it=20
> (it does not show it on the access_log), it remains running there, and =

> every request opens yet another process.

Do you have lots of memory and virtual memory? If so you might find it =
is=20
in an infinite loop and taking a long time to produce a stack overflow.=20
Does your macro template do any recursive calls to macros?

Marc

--=20
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] #templet directive

[Brian G. <br...@qu...>]

> Intuitively I think, that writing something into the output-stream
> (point 1) should be done via property references of the form
> $... and point 2 should be done via directives.

How about:

#eval $template using $map -> to output stream
#eval $template to $variable using $map -> like a #setblock

Or, alterantely

#setblock $varible { #eval $templet using $map }

Re: [Webmacro-devel] #templet directive

[Sebastian K. <seb...@mu...>]

Hi,

On Monday 23 June 2003 16:37, Keats wrote:
> You could still do this sort of thing with the $Template tool.  People
> didn't seem to like the template tool syntax, so I came up with the
> directive approach which seems a bit more user friendly.
>
> My approach to the above would be to use a directive for the writer, say
> #output

ok, let's forget about the output thing. I only used this as an example. Like 
Brian, I personally do not think think it is necessary, but if Lane has a 
need for it, it's ok.

My problem with the #eval-directive is of a more general nature:

In WebMacro we basically have to possibilities to control the result of a 
template evaluation:

1) We can insert something into the output stream. This is usually done by a 
property reference $foo.bar

2) We can interact with the template engine and tell it to iterate certain 
blocks, chose one depending on a condition, set some properties and so on.

Intuitively I think, that writing something into the output-stream (point 1) 
should be done via property references of the form $... and point 2 should be 
done via directives.

Or to put it the other way round: I believe, that directives should not output 
anything by themselves. Of course the "#foreach" directive outputs a lot, but 
that comes from the block inside the directive, not from the directive 
itself. The same holds for "#if" and "#set" does not output anything at all.

This is similar to the distinction between statements and expressions in most 
programming languages. I just realized, that this is how I thought about 
directives and property-refernces until now.

In this picture a #templet directive would fit quite nice, because it just 
declares a template. However, for evaluating, I would find a $... syntax 
nicer.

However, I must admit, that there exists directives (like those declared from 
macros), that do not fit in my own schema, so it is probably broken.

But perhaps we can have some discussion about it: Do we have a consistent 
guideline, when to use $... syntax (via tools or macros) and when to use 
directives? I do not know of one and this is, where my confusion comes from.

Sebastian

-- 
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html

Re: [Webmacro-devel] Fwd: Re: Update to velocity "You make the decision" doc

[Brian G. <br...@qu...>]

> Hey guys, look at the wonderfully helpful response I got from Jon. (not)

Well, if you look beyond the curt tone, what he's actually saying is
"go ahead and rewrite the page."  So I would follow his advice -- take
the HTML (or whatever the source of that page is) and edit it, and
then generate a patch.  He might very well apply it.  

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

Oh look. Another version.properties on the classpath.

Oh look, Resin won't find my own one either!!!


Servlet Classloader: EnvironmentClassLoader[web- 
app:http://localhost:8080/ignition]

this.getClass().getClassLoader():
EnvironmentClassLoader[web-app:http://localhost:8080/ignition]

Servlet Classloader's URL for resource: jar:file:/E:/resin-3.0.1- 
beta/lib/isorelax.jar!/version.properties

^^^^^^ wrong jar of course.

this.getClass().getClassLoader() URL for resource: null

^^^^^^ WTF? This should definitely work from what Eric and others have been 
saying.



-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tuesday, June 24, 2003, at 04:17  PM, Marc Palmer wrote:

> I have not used the classpath env var for at least 2 years because it 
> sucks.

I couldn't agree more.

>> % echo $CLASSPATH
>
> D:\jdk1.2.2\lib - a directory which does not exist.

hmm.

>> I don't know which version of Resin you're using, but I'm very sure 
>> that the 2.0.x series does not do this.  It would make no sense...
>
> 3.0.1 beta. Also occurs with 2.0.x series.

never used 3.0.1.  Until we get it phased out, we're still running 2.0.5

> Really. Trust me on this Eric.

okay.

> Shrug harder damnit!

I can't!

> Nope. Resin sucks, Tomcat "rules" in the current scenario.
>
> This also occurs for Lane remember - that's why I am debugging this on 
> resin. Lane gets different, but possibly related problems under Tomcat 
> however.
>
> I experience no problems at all on 3 different servers running 
> different versions of tomcat on Win XP and Win 98.

have you checked your .jar files just to make sure you don't have an 
empty version of this .properties file in it?  Something created by 
accident, or early in your development, that has somehow managed to 
survive?

>> How 'bout some system debug statements to output the .toString() of 
>> the ClassLoader that loaded that IgnitionPropertiesVersionInfo() 
>> class v/s the .toString() of what you believe to be the Servlet class 
>> loader (should be the same object!) and the .toString() of the system 
>> classloader...
>
> Ah, now that is of course a good plan. I just hoped it was me doing 
> bad things.

it'll be interesting to see how many classloaders Resin is actually 
using per webapp... although I still think it's only 1.

eric

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tue, 24 Jun 2003 14:25:10 -0400, Eric B. Ridge <eb...@tc...> wrote:

>>> Resin is bad at a lot of things.  :)  But again, you're not wanting to 
>>> do something weird... I just think your CLASSPATH is messed up.
>>
>> That is the one thing I am sure isn't messed up :(
>
> I hope it is messed up, b/c that will explain what's going on here.
>
> How 'bout some system debug statements to output the .toString() of the 
> ClassLoader that loaded that IgnitionPropertiesVersionInfo() class v/s 
> the .toString() of what you believe to be the Servlet class loader 
> (should be the same object!) and the .toString() of the system 
> classloader...

Classloader passed in (Servlet's.getClass().getClassLoader()):  
EnvironmentClassLoader[web-app:http://localhost:8080/ignition]

My Class's Classloader: EnvironmentClassLoader[web- 
app:http://localhost:8080/ignition]


So they look the same. Neither of them will correctly load 
/version.properties or version.properties.

Help?!

Marc
-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tue, 24 Jun 2003 14:25:10 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Tuesday, June 24, 2003, at 02:16  PM, Marc Palmer wrote:
>
>> On Tue, 24 Jun 2003 14:04:51 -0400, Eric B. Ridge <eb...@tc...> wrote:
>>> Resin uses 1 classloader per webapp that always defers to the system 
>>> classloader first.  Is your system CLASSPATH correct (and correct 
>>> should probably mean "empty").
>>
>> I am 100000% sure. I never use system CLASSPATH. The .jar is only in 
>> WEB-INF/lib, version.properties is only in WEB-INF/classes.
>
> famous last words....  I can't count the number of times this has bitten 
> me.

I have not used the classpath env var for at least 2 years because it 
sucks.

> % echo $CLASSPATH

D:\jdk1.2.2\lib - a directory which does not exist.

>> You see my point though? It really looks like Resin is using separate 
>> (and unlinked) ClassLoader(s) for the jar and WEB-INF/classes
>
> I don't know which version of Resin you're using, but I'm very sure that 
> the 2.0.x series does not do this.  It would make no sense...

3.0.1 beta. Also occurs with 2.0.x series.

>>> Not sure about this null business, but are you sure this .jar file 
>>> isn't also in your system classpath?
>>
>> As above, very sure.
>
> really?

Really. Trust me on this Eric.

>>> It really is the end of the world.  ClassLoaders are supposed to be 
>>> transparent in almost all situations... and you're NOT trying to do 
>>> anything out of the ordinary here.
>>
>> Oh OK. Why is this borked then?
>
> *shrug*

Shrug harder damnit!

>>> Resin is bad at a lot of things.  :)  But again, you're not wanting to 
>>> do something weird... I just think your CLASSPATH is messed up.
>>
>> That is the one thing I am sure isn't messed up :(
>
> I hope it is messed up, b/c that will explain what's going on here.

Nope. Resin sucks, Tomcat "rules" in the current scenario.

This also occurs for Lane remember - that's why I am debugging this on 
resin. Lane gets different, but possibly related problems under Tomcat 
however.

I experience no problems at all on 3 different servers running different 
versions of tomcat on Win XP and Win 98.

> How 'bout some system debug statements to output the .toString() of the 
> ClassLoader that loaded that IgnitionPropertiesVersionInfo() class v/s 
> the .toString() of what you believe to be the Servlet class loader 
> (should be the same object!) and the .toString() of the system 
> classloader...

Ah, now that is of course a good plan. I just hoped it was me doing bad 
things.

Cheers for the help

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] Help! (AKA: I hate resin)

[Keats <ke...@ea...>]

I think I ran into a similar problem trying to run Ignition under
ServletExec.  I think the spec gives Servlet containers some leeway in how
they implement class loaders, and specifically in how they are chained.
However, returning a non-null if the resource wasn't found, sounds like it
could be a serious Resin bug.

If you are trying to load from WEB-INF/classes you obviously need to have a
Servlet-aware ClassLoader .  The good news is that you don't have to wait
for your first request to get the ServletContext -- you can get it during
the init() of your Servlet.

If you have a WM Broker instance around, you can call getResourceAsStream(),
or getResource(), on the Broker.  No need to reinvent the wheel.

Hope this helps.

Keats


----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: <web...@li...>
Sent: Tuesday, June 24, 2003 1:37 PM
Subject: [Webmacro-devel] Help! (AKA: I hate resin)


>
> Guys I'd appreciate a hand here -
>
> Ignition runs fine in Tomcat (for me) but won't start under Resin.
>
> The problem is that Ignition cannot load resources it requires, namely
> properties files, which are in WEB-INF/classes. This may also be the
> problem the problem Lane is experiencing with Tomcat on a unix box -
though
> we can't see why tomcat (or the VM) would vary on this on different
> platforms without breaking a lot of stuff.
>
> Here is an example of my code, which works perfectly under many versions
of
> Tomcat:
>
>     public PropertiesIgnitionVersionInfo()
>     {
>         Properties p = new Properties();
>         try
>         {
>             p.load( getClass().getResourceAsStream(
"/version.properties") )
> ;
>         }
>         catch (IOException e)
>         {
>             throw new RuntimeException(
>                     "Unable to load version info from classpath:
> "+RESOURCE_VERSIONINFO);
>         }
>         major = Integer.parseInt( p.getProperty(PROPERTY_MAJORVERSION));
>         minor = Integer.parseInt( p.getProperty(PROPERTY_MINORVERSION));
>         buildDate = p.getProperty(PROPERTY_BUILD_DATE);
>         buildName = p.getProperty(PROPERTY_BUILD_NAME);
>     }
>
> Now here's the thing. Under resin this fails not because
> getResourceAsStream returns null - because it doesn't.
>
> Resin returns a valid InputStream pointing to ... ? nothing it seems. The
> Properties is empty after the call to load.
>
> Then the parseInt calls die because the property is null.
>
> Yes I have tried with/without the "/". "/" is the correct thing to do, and
> both cases produce the same results in Resin.
>
> Now I think I have tracked down the problem. Resin is probably using a
> classloader that does not defer to the classloader used to load the webapp
> resources.
>
> Stay with me here... in the .WAR the code shown above lives in WEB-
> INF/lib/ignition-core.jar but the version.properties file lives in WEB-
> INF/classes.
>
> As a result getClass() is using the classloader used to load the JAR, and
> in Resin this means it cannot find anything in WEB-INF/classes - and
> erroneously creates an empty input stream instead of null.
>
> Anyway, the solution to this seems to be to use either the ServletContext
> classloader and/or the Servlet classloader to call getResourceAsStream.
>
> This is not very nice as it means passing ClassLoaders around but is not
> the end of the world.
>
> It just baffles me that Resin is so "bad" like this, but then I suppose I
> am doing something a little weird because the files are in different
> locations.
>
> Using ServletContext.getResource is not an option because we're not in a
> request yet... and prefixing with WEB-INF/classes would be nasty :)
>
> Any thoughts gratefully received.
>
> --
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tuesday, June 24, 2003, at 02:16  PM, Marc Palmer wrote:

> On Tue, 24 Jun 2003 14:04:51 -0400, Eric B. Ridge <eb...@tc...> wrote:
>> Resin uses 1 classloader per webapp that always defers to the system 
>> classloader first.  Is your system CLASSPATH correct (and correct 
>> should probably mean "empty").
>
> I am 100000% sure. I never use system CLASSPATH. The .jar is only in 
> WEB- INF/lib, version.properties is only in WEB-INF/classes.

famous last words....  I can't count the number of times this has 
bitten me.

% echo $CLASSPATH

> You see my point though? It really looks like Resin is using separate 
> (and unlinked) ClassLoader(s) for the jar and WEB-INF/classes

I don't know which version of Resin you're using, but I'm very sure 
that the 2.0.x series does not do this.  It would make no sense...

>> Not sure about this null business, but are you sure this .jar file 
>> isn't also in your system classpath?
>
> As above, very sure.

really?

>> It really is the end of the world.  ClassLoaders are supposed to be 
>> transparent in almost all situations... and you're NOT trying to do 
>> anything out of the ordinary here.
>
> Oh OK. Why is this borked then?

*shrug*

>> Resin is bad at a lot of things.  :)  But again, you're not wanting 
>> to do something weird... I just think your CLASSPATH is messed up.
>
> That is the one thing I am sure isn't messed up :(

I hope it is messed up, b/c that will explain what's going on here.

How 'bout some system debug statements to output the .toString() of the 
ClassLoader that loaded that IgnitionPropertiesVersionInfo() class v/s 
the .toString() of what you believe to be the Servlet class loader 
(should be the same object!) and the .toString() of the system 
classloader...

eric

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tue, 24 Jun 2003 14:04:51 -0400, Eric B. Ridge <eb...@tc...> wrote:
> Resin uses 1 classloader per webapp that always defers to the system 
> classloader first.  Is your system CLASSPATH correct (and correct should 
> probably mean "empty").

I am 100000% sure. I never use system CLASSPATH. The .jar is only in WEB- 
INF/lib, version.properties is only in WEB-INF/classes.

You see my point though? It really looks like Resin is using separate (and 
unlinked) ClassLoader(s) for the jar and WEB-INF/classes

> Not sure about this null business, but are you sure this .jar file isn't 
> also in your system classpath?

As above, very sure.

>> Anyway, the solution to this seems to be to use either the 
>> ServletContext classloader and/or the Servlet classloader to call 
>> getResourceAsStream.
>
> I think you're just hiding the problem by doing this.

Oh ok. I just thought maybe I was doing the wrong thing.

>> This is not very nice as it means passing ClassLoaders around but is not 
>> the end of the world.
>
> It really is the end of the world.  ClassLoaders are supposed to be 
> transparent in almost all situations... and you're NOT trying to do 
> anything out of the ordinary here.

Oh OK. Why is this borked then?

>> It just baffles me that Resin is so "bad" like this, but then I suppose 
>> I am doing something a little weird because the files are in different 
>> locations.
>
> Resin is bad at a lot of things.  :)  But again, you're not wanting to do 
> something weird... I just think your CLASSPATH is messed up.

That is the one thing I am sure isn't messed up :(

Marc
-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tue, 24 Jun 2003 18:37:33 +0100, Marc Palmer <ma...@an...> wrote:

> Using ServletContext.getResource is not an option because we're not in a 
> request yet... and prefixing with WEB-INF/classes would be nasty :)

Of course that is wrong - I wasn't thinking straight (it's ServletName you 
can't get unless in a request).

> Any thoughts gratefully received.

Still applies :)

WM's brokers seem to try:

ServletContext classloader
Servlet classloader
default classloader

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org

Re: [Webmacro-devel] Help! (AKA: I hate resin)

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

On Tuesday, June 24, 2003, at 01:37  PM, Marc Palmer wrote:

> Guys I'd appreciate a hand here -
>
> Ignition runs fine in Tomcat (for me) but won't start under Resin.
>
> The problem is that Ignition cannot load resources it requires, namely 
> properties files, which are in WEB-INF/classes. This may also be the 
> problem the problem Lane is experiencing with Tomcat on a unix box - 
> though we can't see why tomcat (or the VM) would vary on this on 
> different platforms without breaking a lot of stuff.
>
> Here is an example of my code, which works perfectly under many 
> versions of Tomcat:
>
>    public PropertiesIgnitionVersionInfo()
>    {
>        Properties p = new Properties();
>        try
>        {
>            p.load( getClass().getResourceAsStream( 
> "/version.properties") ) ;

Who loaded this class (PropertiesIgnitionVersionInfo)?  The java system 
classloader (ie, the .jar is in your CLASSPATH), or Resin's classloader 
(ie, the .jar is in your WEB-INF/lib directory)?

Remember, if it's in both, the system classloader wins...
<snip>

> Now I think I have tracked down the problem. Resin is probably using a 
> classloader that does not defer to the classloader used to load the 
> webapp resources.

Resin uses 1 classloader per webapp that always defers to the system 
classloader first.  Is your system CLASSPATH correct (and correct 
should probably mean "empty").

>
> Stay with me here... in the .WAR the code shown above lives in WEB- 
> INF/lib/ignition-core.jar but the version.properties file lives in 
> WEB- INF/classes.

Is there also a version.properties file in the ignition-core.jar file?  
I do not know Resin's classpath search order when loading stuff out of 
WEB-INF/*.  If you want to dictate the search order, you need to 
specify <classpath> entries for your <webapp>

> As a result getClass() is using the classloader used to load the JAR, 
> and in Resin this means it cannot find anything in WEB-INF/classes - 
> and erroneously creates an empty input stream instead of null.

Not sure about this null business, but are you sure this .jar file 
isn't also in your system classpath?

> Anyway, the solution to this seems to be to use either the 
> ServletContext classloader and/or the Servlet classloader to call 
> getResourceAsStream.

I think you're just hiding the problem by doing this.

> This is not very nice as it means passing ClassLoaders around but is 
> not the end of the world.

It really is the end of the world.  ClassLoaders are supposed to be 
transparent in almost all situations... and you're NOT trying to do 
anything out of the ordinary here.

> It just baffles me that Resin is so "bad" like this, but then I 
> suppose I am doing something a little weird because the files are in 
> different locations.

Resin is bad at a lot of things.  :)  But again, you're not wanting to 
do something weird... I just think your CLASSPATH is messed up.

eric

>
> Using ServletContext.getResource is not an option because we're not in 
> a request yet... and prefixing with WEB-INF/classes would be nasty :)
>
> Any thoughts gratefully received.
>
> -- 
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting 
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly 
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] Help! (AKA: I hate resin)

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

Guys I'd appreciate a hand here -

Ignition runs fine in Tomcat (for me) but won't start under Resin.

The problem is that Ignition cannot load resources it requires, namely 
properties files, which are in WEB-INF/classes. This may also be the 
problem the problem Lane is experiencing with Tomcat on a unix box - though 
we can't see why tomcat (or the VM) would vary on this on different 
platforms without breaking a lot of stuff.

Here is an example of my code, which works perfectly under many versions of 
Tomcat:

    public PropertiesIgnitionVersionInfo()
    {
        Properties p = new Properties();
        try
        {
            p.load( getClass().getResourceAsStream( "/version.properties") ) 
;
        }
        catch (IOException e)
        {
            throw new RuntimeException(
                    "Unable to load version info from classpath: 
"+RESOURCE_VERSIONINFO);
        }
        major = Integer.parseInt( p.getProperty(PROPERTY_MAJORVERSION));
        minor = Integer.parseInt( p.getProperty(PROPERTY_MINORVERSION));
        buildDate = p.getProperty(PROPERTY_BUILD_DATE);
        buildName = p.getProperty(PROPERTY_BUILD_NAME);
    }

Now here's the thing. Under resin this fails not because 
getResourceAsStream returns null - because it doesn't.

Resin returns a valid InputStream pointing to ... ? nothing it seems. The 
Properties is empty after the call to load.

Then the parseInt calls die because the property is null.

Yes I have tried with/without the "/". "/" is the correct thing to do, and 
both cases produce the same results in Resin.

Now I think I have tracked down the problem. Resin is probably using a 
classloader that does not defer to the classloader used to load the webapp 
resources.

Stay with me here... in the .WAR the code shown above lives in WEB- 
INF/lib/ignition-core.jar but the version.properties file lives in WEB- 
INF/classes.

As a result getClass() is using the classloader used to load the JAR, and 
in Resin this means it cannot find anything in WEB-INF/classes - and 
erroneously creates an empty input stream instead of null.

Anyway, the solution to this seems to be to use either the ServletContext 
classloader and/or the Servlet classloader to call getResourceAsStream.

This is not very nice as it means passing ClassLoaders around but is not 
the end of the world.

It just baffles me that Resin is so "bad" like this, but then I suppose I 
am doing something a little weird because the files are in different 
locations.

Using ServletContext.getResource is not an option because we're not in a 
request yet... and prefixing with WEB-INF/classes would be nasty :)

Any thoughts gratefully received.

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org