Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Keats <ke...@ea...> - 2003-07-24 22:05:53
|
One thing that makes the context tools mechanism complicated is that it is optimized to allow unsynchronized access to the tools. We can do this because the list of tools is loaded at startup, before the multi-threaded requests start coming in. If we want to be able to deploy and undeploy tools on a running instance, we'll have to deal with thread-safety issues. So there is a trade-off here: fast, unsynchronized access to tools (aka lazily loaded objects), or dynamic deployment. This is the quintessential resource management challenge for server-side Java applications. These tools will be read frequently and deployed/undeployed infrequently, so it is a shame to have to obtain a monitor every time we want to merely look up a tool. One standard approach for mitigating this would be to use redundant copies of the tool list. Reads would acquire the monitor on one of the lists at random, thus reducing the amount of lock contention. Deploy/undeploy operations would acquire all the monitors, blocking all reads until completed. The question is, would such an approach reduce the cost of synchronization to the point where it is worth giving up the quick, unsynchronized lookups? Should we maintain a separate table for preconfigured, thread-safe tools? Or is hot deploy/undeploy really important? [Note: the mechanism I'm suggesting here does not support true undeploy or redeploy functionality. This would require a custom classloader.] Brian, I know you are expert in this area, so please chime in. Keats |
|
From: Keats <ke...@ea...> - 2003-07-24 21:44:18
|
> Is it in WM.defaults as a directive? If not, I think we can safely excise it. Nope, it's nowhere. I just killed it. Keats |
|
From: Brian G. <br...@qu...> - 2003-07-24 21:39:18
|
>>In other words, its OK to have "magic" stuff, but you want the magic to >>be put there by the application architect, not by WM. So what you want >>is a mechanism for adding your own magic. > >No, want the ability for *removing* the things that are magically placed >in the context. If this translates to "a more formal plug-in concept", >that's fine, but the idea is to eliminate magical stuff, not make it >easier to introduce more. I wasn't clear. I meant that you want _all_ the magic under the "applications" control. My concern is that this is basically assuming one kind of application model. I think enumerating the use cases first would shed a lot of light on the issue. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Eric B. R. <eb...@tc...> - 2003-07-24 21:35:36
|
On Thursday, July 24, 2003, at 05:20 PM, Brian Goetz wrote: > In other words, its OK to have "magic" stuff, but you want the magic > to be put there by the application architect, not by WM. So what you > want is a mechanism for adding your own magic. No, want the ability for *removing* the things that are magically placed in the context. If this translates to "a more formal plug-in concept", that's fine, but the idea is to eliminate magical stuff, not make it easier to introduce more. eric |
|
From: Brian G. <br...@qu...> - 2003-07-24 21:35:29
|
>I think you're thinking of #param. I don't know what #property does, but >nothing uses it. Could be. I'm pretty sure #property has something to do with communicating stuff back from the template to the servlet. It may well have been subsumed by #param / #attribute / #const. Is it in WM.defaults as a directive? If not, I think we can safely excise it. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Keats <ke...@ea...> - 2003-07-24 21:31:24
|
I think you're thinking of #param. I don't know what #property does, but nothing uses it. Keats ----- Original Message ----- From: "Brian Goetz" <br...@qu...> To: "Keats" <ke...@ea...> Cc: <web...@li...> Sent: Thursday, July 24, 2003 5:09 PM Subject: Re: [Webmacro-devel] PropertyDirective -- legacy garbage? > > >There's something called PropertyDirective that isn't used anywhere. Can I > >blow this away? > > I think #property and #attribute and #const are all the same. They put a > value in the build context where the servlet can see it, right? > > > -- > Brian Goetz > Quiotix Corporation > br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 > > http://www.quiotix.com > > |
|
From: Brian G. <br...@qu...> - 2003-07-24 21:21:27
|
>Actually there is a problem, but I obviously haven't elucidated it clearly. OK, between Eric and Marc, I now see what they're talking about. I don't think the problem is with context tools -- I think the problem is that we are basically schizoid about whether WM is a framework or a rendering engine, and what degree of framework and application support it has. Basically, what you want to be able to do is have one party (say, the architect) configure WM, embed it in the application or framework, and publish the WM service to another party (the developers/designers) and have some control over what directives, facilities, macros, policies, etc are available for the developers/designers to use. In other words, its OK to have "magic" stuff, but you want the magic to be put there by the application architect, not by WM. So what you want is a mechanism for adding your own magic. A more formal plug-in concept comes to mind, for directives, macros, tools, etc. Is this what you're talking about? -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Brian G. <br...@qu...> - 2003-07-24 21:10:54
|
>There's something called PropertyDirective that isn't used anywhere. Can I >blow this away? I think #property and #attribute and #const are all the same. They put a value in the build context where the servlet can see it, right? -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Brian G. <br...@qu...> - 2003-07-24 21:10:13
|
>Hmm, really? will #set auto detect that something is in the build context?
>If so... wow!
I'm not sure if the #set directive does this, but it certainly can. I know
that the #if directive does -- if you say #if (false) { blah } #else { gah
}, this will compile to { gah }. As does #include when the argument is
known at compile time.
Look at the TemplateDumper class -- you give it a template and it dumps a
representation of the compiled template, so you can see compile time
optimizations. There are quite a few of them.
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
|
|
From: Marc P. <ma...@an...> - 2003-07-24 16:31:00
|
On Thu, 24 Jul 2003 17:16:54 +0100, Marc Palmer <ma...@an...> wrote:
> It's all about optimisation and convenience, but there are big wins to be
> had here if we can come up with a solution that mortals can understand.
> We will make it easy for them to increase performance quite
> significantly.
ROFL. Didn't I tell you guys that we're immortal?
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-24 16:18:33
|
On Thu, 24 Jul 2003 12:05:19 -0400, Keats <ke...@ea...> wrote:
> After looking at the code, I see that #set does the actual assignment at
> runtime. You can't do what you want at build time because a constant has
> to
> be a SimpleVariable (i.e., no dots). I'm not sure what it would take to
> change this. Do you have a compelling need for this?
Well it's a "classic" templating issue, of setting up some data used for
rendering the view - but wanting to make this constant so that there is no
per-request overhead for no reason whatsoever.
I have a template that renders fields. This occurs in it:
#newobject $constants
#set $constants.DAYNUMBERSLIST = ["-None-
",1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]
#set $constants.MONTHNAMESLIST = ["-None-", "Jan", "Feb", "Mar", "Apr",
"May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]
Now, I just wondered if it was possible to stop this being done for every
request, as it is clearly an invariant.
I know that I can do it like this:
#const $DAYNUMBERSLIST = ["-None-
",1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]
#const $MONTHNAMESLIST = ["-None-", "Jan", "Feb", "Mar", "Apr", "May",
"Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]
...but I just wondered if I could do it in on an object I have created
(somehow) so that I can reduce namespace pollution and also possibly have
multiple sets of constants and switch between them by passing just the
outer object around - a stupid example:
#newobject $constantsA as constant
#const $constantsA.DAYNUMBERSLIST = [ ... ]
#const $constantsA.MONTHNAMESLIST = [ ... ]
#const $constantsA.THISYEAR = $dates.Now.Year
#newobject $constantsB as constant
#const $constantsB.DAYNUMBERSLIST = [ ... ]
#const $constantsB.MONTHNAMESLIST = [ ... ]
#const $constantsB.THISYEAR = $dates.Now.Year
#if ($user == "marc")
#render($constantsA)
#elseif ($user == "keats")
#render($constantsA)
#end
It's all about optimisation and convenience, but there are big wins to be
had here if we can come up with a solution that mortals can understand. We
will make it easy for them to increase performance quite significantly.
Cheers
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Keats <ke...@ea...> - 2003-07-24 16:10:40
|
There's something called PropertyDirective that isn't used anywhere. Can I blow this away? Keats |
|
From: Keats <ke...@ea...> - 2003-07-24 16:06:53
|
> > #newobject $x > > #set $x.SomeProp = [ 1, 2, 3, 4, 5, 6 ] > > > > I'm pretty sure Brian has made the parser smart enough to do all this at > > build time, since there are no runtime dependencies. > > Hmm, really? will #set auto detect that something is in the build context? > If so... wow! > > In which case I'd just need to add "as const" keywords to #newobject and > then people using #newobject don't even need to care if it is a const or > not (i.e. use #set as normal, not #const). > > Surely though, using #set would require WM to detect a non-build time right > hand assignment, which would result in an exception surely? After looking at the code, I see that #set does the actual assignment at runtime. You can't do what you want at build time because a constant has to be a SimpleVariable (i.e., no dots). I'm not sure what it would take to change this. Do you have a compelling need for this? Keats |
|
From: Marc P. <ma...@an...> - 2003-07-24 14:56:46
|
On Thu, 24 Jul 2003 10:29:04 -0400 (GMT), Keats <ke...@su...> wrote:
> I'm actually not sure if #bean can create a variable at build time. It's
> been a long time since I looked at the code, but I think I made it smart
> enough to do as much as possible during the build.
>
> It's certainly possible for a directive to do this (like #const does
> already), so you could probably make #newobject work this way. I.e.,
> make the #newobject directive do all its work in the build() method,
> then:
>
> #newobject $x
> #set $x.SomeProp = [ 1, 2, 3, 4, 5, 6 ]
>
> I'm pretty sure Brian has made the parser smart enough to do all this at
> build time, since there are no runtime dependencies.
Hmm, really? will #set auto detect that something is in the build context?
If so... wow!
In which case I'd just need to add "as const" keywords to #newobject and
then people using #newobject don't even need to care if it is a const or
not (i.e. use #set as normal, not #const).
Surely though, using #set would require WM to detect a non-build time right
hand assignment, which would result in an exception surely?
:)
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Keats <ke...@su...> - 2003-07-24 14:30:41
|
I'm actually not sure if #bean can create a variable at build time. It's been a long time since I looked at the code, but I think I made it smart enough to do as much as possible during the build.
It's certainly possible for a directive to do this (like #const does already), so you could probably make #newobject work this way. I.e., make the #newobject directive do all its work in the build() method, then:
#newobject $x
#set $x.SomeProp = [ 1, 2, 3, 4, 5, 6 ]
I'm pretty sure Brian has made the parser smart enough to do all this at build time, since there are no runtime dependencies.
Keats
-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 07/24/03 10:11 AM
To: web...@li...
Subject: Re: [Webmacro-devel] #const question
>
> On Thu, 24 Jul 2003 09:58:57 -0400 (GMT), Keats <ke...@su...> wrote:
> I think this could work if $MyHelper is also a #const. Otherwise
> $MyHelper doesn't exist at build time, so this will fail.
Ah yes I see that makes sense. Hmm. This is a good reason why directives
should not create objects - as they can't be used as the right hand side
of
an assignment. Maybe I will have to ditch #newobject after all and make it
a helper - but instantiating it as a #const is going to be tricky isn't
it?
How do we create an #const compatible object that isn't a simple WM type?
I suppose #bean has the ability to create build-time scoped objects
doesn't
it? ( :( don't make me use it!)
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
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/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
|
|
From: Marc P. <ma...@an...> - 2003-07-24 14:11:47
|
On Thu, 24 Jul 2003 09:58:57 -0400 (GMT), Keats <ke...@su...> wrote:
> I think this could work if $MyHelper is also a #const. Otherwise
> $MyHelper doesn't exist at build time, so this will fail.
Ah yes I see that makes sense. Hmm. This is a good reason why directives
should not create objects - as they can't be used as the right hand side of
an assignment. Maybe I will have to ditch #newobject after all and make it
a helper - but instantiating it as a #const is going to be tricky isn't it?
How do we create an #const compatible object that isn't a simple WM type?
I suppose #bean has the ability to create build-time scoped objects doesn't
it? ( :( don't make me use it!)
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Keats <ke...@su...> - 2003-07-24 13:59:07
|
I think this could work if $MyHelper is also a #const. Otherwise $MyHelper doesn't exist at build time, so this will fail. Keats -------Original Message------- From: Marc Palmer <ma...@an...> Sent: 07/24/03 07:19 AM To: web...@li... Subject: [Webmacro-devel] #const question > > Hey, Will #const work in this situation? #const $x = $MyHelper.newObject() #const $x.SomeProp = [ 1, 2, 3, 4, 5, 6 ] will all of that work, and only be done once at template build time, so that the list will not be constructed every time the template is evaluated? If so I will update the docs on wm.org TIA -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook 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/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Webmacro-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: Marc P. <ma...@an...> - 2003-07-24 11:33:47
|
Hi,
I've found another place where WM is reporting the error line+col from the
main template instead of the included (macro) file:
org.webmacro.PropertyException$NoSuchMethodWithArgumentsException: No
public method getFormFieldName(org.webmacro.engine.UndefinedMacro) in class
org.webmacro.ignition.core.templateobjects.IgnitionHelperImpl at
D:\projects\vegcensus\templates\page1.wmt:32.38
This error is in fact in an included macro file, but the line+col numbers
given are the correct location within the macro file, not page1.wmt
Cheers
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-24 11:21:26
|
Hey, Will #const work in this situation? #const $x = $MyHelper.newObject() #const $x.SomeProp = [ 1, 2, 3, 4, 5, 6 ] will all of that work, and only be done once at template build time, so that the list will not be constructed every time the template is evaluated? If so I will update the docs on wm.org TIA -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-07-24 11:12:57
|
http://www.webmacro.org/NextRelease Because there seem to be at least a few people into the following ideas I have added them to the "Agreed" list on the page: * the WM webapp reload issue * the full lazy impl of CTs that Brian has now done * the separate "WM optional" source branch and binary If I have jumped the gun at all on these please say so, but I don't think I have. But then, we haven't had votes for any of these so maybe I am. :( Marc -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-07-24 10:33:21
|
On Thu, 24 Jul 2003 11:56:29 +0200, Sebastian Kanthak
<seb...@mu...> wrote:
> I've tried to track this down the last two hours, but I have no clue. I
> did the following to get a minimal test case.
Sebastian, thanks for spending some time on it!
The error you get is different probably just because I am based on
WMServlet and you are based on Standalone.
This is very strange though, because we know for a fact that other JARs are
reloaded fine in Tomcat and Resin.
So there must be something specific to webmacro.jar that is different. It
does not look like some strange classloader usage issue -within- WM code
though, which was possible with my flavour of the problem, because yours is
a class loading (rather than resource) problem.
The "touch" working without problem sounds to me like there might be some
intelligence going on in the classloader, or because no code has actually
changed it continues to work with the previous code on the previous
classloader perhaps.
This is all speculation but that's all we have right now!
I'll see if I can see anything in the way the jar is built. I know, I must
be crazy... but maybe its a problem with reloading zipped JARs vs unzipped
jars for example.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-24 10:24:59
|
On Wed, 23 Jul 2003 20:24:09 -0400, Eric B. Ridge <eb...@tc...> wrote:
> On Wednesday, July 23, 2003, at 08:10 PM, Brian Goetz wrote:
>
>> But why do you need to suppress individual CTs at all? They don't have
>> any per-request overhead. And they don't have variable name capture
>> problems. So what's the problem? If you don't use them, they don't
>> cost you anything. No problem.
>
> Until a template designer decides to start using it... w/o your
> knowledge or permission. I don't think Marc is arguing performance
> here. He's arguing against WM doing magical things that you have little
> control over.
Yippeee! Right on the money!
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-24 10:01:59
|
On Wed, 23 Jul 2003 17:10:38 -0700, Brian Goetz <br...@qu...> wrote:
>
>> Well I wouldn't mind if we had a way to nicely "mute" settings in
>> WM.defaults. Actually I think we do don't we?
>>
>> LazyVariableFactory:
>
> I did something like that to let you remove directives and tools from the
> list, but I'm not sure if it works for arbitrary tags -- but it certainly
> could.
>
>> See the problem? Taking a shrink-wrapped WM jar how can my app reliably
>> suppress all CTs except $Form, for example? I don't think it's possibly
>> without me tracking what CTs are in any one WM release and explicitly
>> suppressing them in WM.properties.
>
> But why do you need to suppress individual CTs at all? They don't have
> any per-request overhead. And they don't have variable name capture
> problems. So what's the problem? If you don't use them, they don't cost
> you anything. No problem.
Actually there is a problem, but I obviously haven't elucidated it clearly.
Currently we view WM as a "system" or whatever you want to call it, but we
definitely see it as more than just a "template rendering library". Call it
a mini-framework if you will, because there are so many legacy add-ons that
take it beyond mere load template/populate context/render to output.
This has, at times, been a valid complaint against WM (vis Velocity).
We are so used to WM that it is hard to step back and see what it really
looks like to outsiders.
Now, with specific reference to the CT issue.
Imagine we are new to WM. We want to write a whizz-bang web framework that
uses WM for templating, and we have all these new high-level ideas for a
new paradigm of access to request/response/form fields that will prevent
people screwing things up, bypassing our request parameter naming
conventions etc.
Then we read the WM docs and find that all these ContextTools exist.
However we want our app to provide a completely different paradigm for
accessing these resources, so we want don't want all the existing CTs in
there because it could confuse our users if they read somewhere else about
these features of WM, and worse it could have them bypassing important
mechanisms of our application.
Besides, if our app hasn't put them there and they aren't part of our app
design, why should they remain? It's not the mythical overhead of them we
are concerned about, it's the fact that the user could start using them and
we have no control over it.
I'm trying to think of an analogy that works - ah this might.
Imagine if we were talking about writing a framework that used XSLT
instead, but we discovered that XSLT provides a whole bunch of template
rules by default (apart from the default handler) and we can't effectively
prevent them being used, even if they were completely irrelevant or perhaps
problematic for our application. It would suck!
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Sebastian K. <seb...@mu...> - 2003-07-24 09:57:23
|
Hi,
On Wednesday 23 July 2003 12:11, Marc Palmer wrote:
> Guys, I imagine a few of use are familiar with this message after trying to
> replace webmacro.jar and restarting/reloading the web application without
> restarting the servlet container:
>
> WebMacro Error:
>
> Could not initialize the broker!
> *** Check that WebMacro.properties was in your servlet
> *** classpath, in a similar place to webmacro.jar *** and that all values
> were set correctly.
> IO Error reading WebMacro.defaults
> java.io.FileNotFoundException: JAR entry WebMacro.defaults not found in
> E:\Program Files\Apache Group\Tomcat 4.1\webapps\ignition\WEB-
> INF\lib\webmacro.jar
> Please contact the server administrator
>
>
> Do we know why this is happening? It is hard to see how it can be a WM
> thing, as it looks more like a generic classloader issue.
I've tried to track this down the last two hours, but I have no clue. I did
the following to get a minimal test case.
I modified Standalone.java from our examples slightly, so that it worked as
expected:
- Passed a "this" reference in new WM()
- called super.init(sc) at the beginning of the overriden init method
I then created a simple web-app with the following files:
webapps/test/standalone.wm
webapps/WEB-INF/web.xml
webapps/WEB-INF/classes/Standalone.class
webapps/WEB-INF/lib/webmacro.jar
This works as expected. When I "touch" webmacro.jar the webapp gets reloaded
and everything works as expected. However, when I change a core WebMacro
class sligthly, so that the size of webmacro.jar changes and put this
modified webmacro.jar in place, things fails after reloading the webapp.
However, I'm getting another message than Marc which really hints at a
classloader issue:
avax.servlet.ServletException: Error instantiating servlet class Standalone
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:912)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:484)
----- Root Cause -----
java.lang.NoClassDefFoundError: org/webmacro/ContextException
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:903)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:484)
Notice the root cause:
"java.lang.NoClassDefFoundError: org/webmacro/ContextException"
Needless to say, that I did not do anything to ContextException.
I have no idea what's going on here, or how to track this down.
This all happens under tomcat-4.1.24
Sebastian
--
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html
|
|
From: Lane S. <la...@op...> - 2003-07-24 06:08:17
|
Marc Palmer wrote: > On Wed, 23 Jul 2003 19:08:08 -0400 (GMT), Keats <ke...@su...> > wrote: > > > I expect this to be greeted with the usual disagreement :) actually it is a pretty good plan because it does provide the best of both wolds. -lane > > |
237 messages has been excluded from this view by a project administrator.
