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: Marc P. <ma...@an...> - 2003-07-10 16:12:16
|
Hi, This is mostly to reassure Brian - I'm using the latest WM source without FastWriter in my development version of Ignition and everything seems absolutely fine. Hooray! I'm working on "the most trivial example of using WM" to put on the website once this source is available. I think it will also act as a standard for us to work against in terms of trying to whittle down the "noise" in using WM so that it is really easy to use. Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-07-10 14:06:56
|
On Thu, 10 Jul 2003 09:15:19 -0400, Eric B. Ridge <eb...@tc...> wrote: > > I get the *exact* error with Resin when I replace webmacro.jar. > Restarting Resin always works. Yes, restarting Tomcat works too. However the fact that both Tomcat and Resin exhibit this problem makes me wonder if WM is partly to blame here. Any clues? -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-07-10 14:06:56
|
On Thu, 10 Jul 2003 14:31:50 +0200 (CEST), Endre Stølsvik <web...@st...> wrote: > On Thu, 10 Jul 2003, Marc Palmer wrote: > > | > | Hi, > | > | Just rolling along with Brian's new WM mods. I noticed something odd. > | > | I replaced my webapps webmacro.jar with the new one, and told Tomcat > (4.1) > | to reload my app. This normally works fine. > > I always restart tomcat (take it -down-and then start it again) if I > change the jars, as I haven't been very lucky with reloading when jars > are > changed... Using the Tomcat Manager web ui to reload my app works all the time after replacing my app's jars, without issue. It's only replacing webmacro.jar that has caused a problem. Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Eric B. R. <eb...@tc...> - 2003-07-10 13:15:30
|
On Thursday, July 10, 2003, at 07:11 AM, Marc Palmer wrote: > What I got was an error from WM saying it couldn't find > WebMacro.defaults in the jar, even though it is there! > > 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 I get the *exact* error with Resin when I replace webmacro.jar. Restarting Resin always works. eric > > Now... that sounds like a Tomcat classloader bug to me, or I am doing > something obscure without realising it that is stopping reload > occurring properly (can that really be true?!) > > Marc > > -- > Marc Palmer > Contract Java Consultant/Developer > > * Available For Hire * > > See my CV at http://www.anyware.co.uk/marc/ > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: <web...@st...> - 2003-07-10 12:31:55
|
On Thu, 10 Jul 2003, Marc Palmer wrote: | | Hi, | | Just rolling along with Brian's new WM mods. I noticed something odd. | | I replaced my webapps webmacro.jar with the new one, and told Tomcat (4.1) | to reload my app. This normally works fine. I always restart tomcat (take it -down- and then start it again) if I change the jars, as I haven't been very lucky with reloading when jars are changed... Tc4.1.24 -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Marc P. <ma...@an...> - 2003-07-10 11:13:22
|
Hi, Just rolling along with Brian's new WM mods. I noticed something odd. I replaced my webapps webmacro.jar with the new one, and told Tomcat (4.1) to reload my app. This normally works fine. However, I do not normally replace WM. What I got was an error from WM saying it couldn't find WebMacro.defaults in the jar, even though it is there! 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 Now... that sounds like a Tomcat classloader bug to me, or I am doing something obscure without realising it that is stopping reload occurring properly (can that really be true?!) Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: <web...@st...> - 2003-07-10 07:40:48
|
On Wed, 9 Jul 2003, Marc Palmer wrote: | On Wed, 9 Jul 2003 14:32:10 -0700, Brian Goetz <br...@qu...> wrote: | | >> This is brilliant Brian. Just porting Ignition to use this new WM code. | > | > And it was easy! | > | > Probably going to change the names of those template functions soon, | > since I don't think getString and getBytes are the most clear names. | > | >> ...shouldn't close() be in a finally block? We don't want dangling | >> streams, especially if they are files. Or am I missing something? | > | > The FW's will get garbage collected, so if they are attached to real | > files (much more likely they are attached to socket output streams) | > they'll get closed when the underlying file gets finalized, but in the | > case | > of sockets, will get closed earlier. | > | > What you point out is in general true, and probably a better practice, | > but in this case really isn't unsafe. | | OK, but it could be a potentially long time before the GC occurs, couldn't | it. | | I think we should have finally in there. If an exception occurs we don't | want file-based systems to be unable to delete the file because it is still | open awaiting GC. | | There's no reason -not-to have it in a finally block. Based on my understanding on the subject, I also agree on this. GC'ing can be postponed potentially for a very long time, and the OS (underlying system) can -potentially- run out of resources because the JVM is holding e.g. 8000 sockets awaiting GC'ing. | | >> Also, and unrelated trivia, will fw.close() close the underlying | >> HTTP stream? It probably shouldn't if keepalives are on. | > | > Well, FW is only used in the context of Template.write now, and | > Template.write certainly shouldn't close the stream. We probably | > shouldn't ever call FW.close, and FW.close should probably not do | > anything but flush. | | This is what I was thinking. We need to be 1000% sure that FW.close() is | not going to kill the HTTP client's connection to us. That can lead to all | kinds of weird messages from browsers (connection reset by peer etc.) in | addition to putting performance through the floor where HTTP 1.1 keepalive | sockets would be used. I wouldn't think closing the Servlet's output stream will close the connection. This is most probably taken care of by the Servlet engine, not by us mere Servlet coders. At least -I'd- design it like that, on first thought..! -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Marc P. <ma...@an...> - 2003-07-09 22:02:40
|
On Wed, 9 Jul 2003 14:32:10 -0700, Brian Goetz <br...@qu...> wrote: >> This is brilliant Brian. Just porting Ignition to use this new WM code. > > And it was easy! > > Probably going to change the names of those template functions soon, > since I don't think getString and getBytes are the most clear names. > >> ...shouldn't close() be in a finally block? We don't want dangling >> streams, especially if they are files. Or am I missing something? > > The FW's will get garbage collected, so if they are attached to real > files (much more likely they are attached to socket output streams) > they'll get closed when the underlying file gets finalized, but in the > case > of sockets, will get closed earlier. > > What you point out is in general true, and probably a better practice, > but in this case really isn't unsafe. OK, but it could be a potentially long time before the GC occurs, couldn't it. I think we should have finally in there. If an exception occurs we don't want file-based systems to be unable to delete the file because it is still open awaiting GC. There's no reason -not-to have it in a finally block. >> Also, and unrelated trivia, will fw.close() close the underlying >> HTTP stream? It probably shouldn't if keepalives are on. > > Well, FW is only used in the context of Template.write now, and > Template.write certainly shouldn't close the stream. We probably > shouldn't ever call FW.close, and FW.close should probably not do > anything but flush. This is what I was thinking. We need to be 1000% sure that FW.close() is not going to kill the HTTP client's connection to us. That can lead to all kinds of weird messages from browsers (connection reset by peer etc.) in addition to putting performance through the floor where HTTP 1.1 keepalive sockets would be used. Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Brian G. <br...@qu...> - 2003-07-09 21:32:28
|
> This is brilliant Brian. Just porting Ignition to use this new WM code. And it was easy! Probably going to change the names of those template functions soon, since I don't think getString and getBytes are the most clear names. > ...shouldn't close() be in a finally block? We don't want dangling streams, > especially if they are files. Or am I missing something? The FW's will get garbage collected, so if they are attached to real files (much more likely they are attached to socket output streams) they'll get closed when the underlying file gets finalized, but in the case of sockets, will get closed earlier. What you point out is in general true, and probably a better practice, but in this case really isn't unsafe. > Also, and unrelated trivia, will fw.close() close the underlying > HTTP stream? It probably shouldn't if keepalives are on. Well, FW is only used in the context of Template.write now, and Template.write certainly shouldn't close the stream. We probably shouldn't ever call FW.close, and FW.close should probably not do anything but flush. |
|
From: Marc P. <ma...@an...> - 2003-07-09 21:27:11
|
On Tue, 8 Jul 2003 12:39:28 -0700, Brian Goetz <br...@qu...> wrote:
> I am about to check in some changes which start the process of hiding
> FastWriter from the external interface.
>
> 1. Deprecate all the "get me a fastwriter" methods.
>
> 2. Eliminate Template.write(fastWriter), replacing it with four
> evaluation
> methods:
> - write(outputStream, context)
> - write(outputStream, encoding, context)
> - getString(context)
> - getBytes(encoding, context)
This is brilliant Brian. Just porting Ignition to use this new WM code.
One thing - you have in several places:
public void write(OutputStream out, String encoding, Context context)
throws PropertyException, IOException {
FastWriter fw = FastWriter.getInstance(_broker, out, encoding);
write(fw, context);
fw.flush();
fw.close();
}
...shouldn't close() be in a finally block? We don't want dangling streams,
especially if they are files. Or am I missing something?
Also, and unrelated trivia, will fw.close() close the underlying HTTP
stream? It probably shouldn't if keepalives are on.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
* Available For Hire *
See my CV at http://www.anyware.co.uk/marc/
|
|
From: Marc P. <ma...@an...> - 2003-07-09 19:24:07
|
On Wed, 9 Jul 2003 13:33:10 -0400, Eric B. Ridge <eb...@tc...> wrote: > Hey! Is there any value to teaching #foreach to iterate over JDBC > ResultSet's? Or perhaps another directive dedicated to this? Nooooooooooooooooooooooooooooooooooooooooooooooo! Surely not?! Wrap 'em up! It's trivial, safer, and allows you to cache results later, without changes to templates. We have this in Ignition. Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Eric B. R. <eb...@tc...> - 2003-07-09 17:33:21
|
Hey! Is there any value to teaching #foreach to iterate over JDBC ResultSet's? Or perhaps another directive dedicated to this? eric |
|
From: Brian G. <br...@qu...> - 2003-07-08 21:37:10
|
> > I'm not sure if it uses the "safe" encoding or the default encoding. > > which should it use? Probably the default encoding from WM.props... Probably. I was just guessing. |
|
From: Eric B. R. <eb...@tc...> - 2003-07-08 21:31:23
|
On Tuesday, July 8, 2003, at 04:49 PM, Brian Goetz wrote: >> This will be really really great! I assume .write(outputStream >> context) uses whatever WM's default encoding is set to? > > I'm not sure if it uses the "safe" encoding or the default encoding. which should it use? Probably the default encoding from WM.props... eric |
|
From: Brian G. <br...@qu...> - 2003-07-08 20:50:14
|
> This will be really really great! I assume .write(outputStream > context) uses whatever WM's default encoding is set to? I'm not sure if it uses the "safe" encoding or the default encoding. > should WMServlet go ahead and do this by default? It does. |
|
From: Eric B. R. <eb...@tc...> - 2003-07-08 20:17:24
|
On Tuesday, July 8, 2003, at 03:39 PM, Brian Goetz wrote: > I am about to check in some changes which start the process of hiding > FastWriter from the external interface. > > 1. Deprecate all the "get me a fastwriter" methods. > > 2. Eliminate Template.write(fastWriter), replacing it with four > evaluation > methods: > - write(outputStream, context) > - write(outputStream, encoding, context) > - getString(context) > - getBytes(encoding, context) This will be really really great! I assume .write(outputStream context) uses whatever WM's default encoding is set to? > The names are open for discussion; probably should change getString > and getBytes to evaluateToString and evaluateToBytes, to make it clear > that evaluation/expansion is going on. evaluateToString/Bytes works for me. > I noted somewhere in the comments that you can't call setEncoding > after you call getOutputStream, so if your template does that, you > have to do this: > > Template t = (get your template somehow); > byte[] bytes = t.getBytes(response.getCharacterEncoding(), ctx); > response.getOutputStream.write(bytes); should WMServlet go ahead and do this by default? eric |
|
From: Brian G. <br...@qu...> - 2003-07-08 19:39:42
|
I am about to check in some changes which start the process of hiding
FastWriter from the external interface.
1. Deprecate all the "get me a fastwriter" methods.
2. Eliminate Template.write(fastWriter), replacing it with four evaluation
methods:
- write(outputStream, context)
- write(outputStream, encoding, context)
- getString(context)
- getBytes(encoding, context)
The names are open for discussion; probably should change getString
and getBytes to evaluateToString and evaluateToBytes, to make it clear
that evaluation/expansion is going on.
These _internally_ use FastWriter (currently), which should probably
be renamed to something else (ByteWriter?) to reflect its ability to
write raw bytes. I've not done this yet as this will break
third-party directives and context tools, so I wanted to do this in
stages.
It passes the unit test suite, with the exception of TestInclude,
which failed when I checked it out.
The recommended usage in servlets is:
Template t = (get your template somehow);
t.write(response.getOutputStream(), response.getCharacterEncoding, ctx);
and that's it.
I noted somewhere in the comments that you can't call setEncoding
after you call getOutputStream, so if your template does that, you
have to do this:
Template t = (get your template somehow);
byte[] bytes = t.getBytes(response.getCharacterEncoding(), ctx);
response.getOutputStream.write(bytes);
Next step: eliminate pooling. The pooling came out of (a)
misconceptions about garbage collection, (b) slower garbage collector
in 1.1, (c) premature optimization, and (d) unnecessarily heavyweight
Context and FastWriter objects. I'm going to first slim them down,
then get rid of the pooling. This will probably not change the API at
all, but will simplify a lot of other things (and probably improve
performance.)
Checking in, feedback requested.
|
|
From: Marc P. <ma...@an...> - 2003-07-08 16:27:05
|
On Tue, 8 Jul 2003 08:36:13 -0700 (PDT), <har...@ko...> wrote: > ----- Original Message ----- > From: "Eric B. Ridge" <eb...@tc...> > Sent: Jul 8, 10:11 AM > >> On Tuesday, July 8, 2003, at 08:57 AM, Marc Palmer wrote: >> > Why should/how could this bring down the VM/exit tomcat? >> >> VM Bug? > > I used to get this on 1.4.1, but not on 1.4.2 beta or 1.3.x > > Is your VM 1.4.1 ? You could be right there! Thanks I'll upgrade. -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: <har...@ko...> - 2003-07-08 15:38:49
|
----- Original Message ----- From: "Eric B. Ridge" <eb...@tc...> Sent: Jul 8, 10:11 AM > On Tuesday, July 8, 2003, at 08:57 AM, Marc Palmer wrote: > > Why should/how could this bring down the VM/exit tomcat? > > VM Bug? I used to get this on 1.4.1, but not on 1.4.2 beta or 1.3.x Is your VM 1.4.1 ? Harmeet |
|
From: Eric B. R. <eb...@tc...> - 2003-07-08 14:11:28
|
On Tuesday, July 8, 2003, at 08:57 AM, Marc Palmer wrote: > Why should/how could this bring down the VM/exit tomcat? VM Bug? I see this on OS X (with Apple's JDK 1.3.1) almost every time I create a stack overflow. The JVM dies, I get a core file, one of those hs_xxx.log files, and the words "Bus Error" on console running java. eric |
|
From: Marc P. <ma...@an...> - 2003-07-08 12:57:42
|
Hi, I am developing a feature for Ignition, and while doing it I managed to create a stack overflow / infinite recursion using templates. This is, of course, my own stupid fault (tm). However what is very strange indeed is that Tomcat shuts down when this happens! There is nothing in the log except lots of my log output where my loop is occurring. I've had stack overflows before in Tomcat where templates are calling #macros in an infinite loop. However they did not kill Tomcat, I just got an error page back. Any ideas how this might be bringing Tomcat down? Basically what's happening is: ## This is my template, say "index.wmt" $SomeObject.callAMethod() ...and callAMethod is using the same WebMacro instance to render another template and return the results. The only problem is that it is rendering "index.wmt", which is where the infinite recursion occurs. Why should/how could this bring down the VM/exit tomcat? Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-07-07 15:28:05
|
Hi,
Something that has been a source of annoyance in the past with WM is that
passing arrays around, where WM has created the array from a list of
elements, you always need to implement your methods to take and Object[]
parameter instead of the specific type. i.e:
public class MyHelper
{
public void doSomethingWithList( Object[] objs)
{
}
}
Now even if in your template you call this with a list of MyObject(s) you
cannot write the method as:
public void doSomethingWithList( MyObject[] objs)
{
}
It is completely understandable that WM does not call this method, in
introspection and semantic terms.
However couldn't we make this a bit more intelligent?
We could make WM do this:
1) Before assembling a list from the [ n1, n2, n3, ... ] syntax, check the
getClass() value of all elements
2) If all getClass() return the same, create a new array of that type, else
create an Object[]
3) Copy all values into the array.
4) Call the method that matches the array type.
This wouldn't solve the problem for all situations, such as using and
interface name for the array type in your method - that wouldn't work.
However for "concrete" types such as java.lang.String, Integer, Float, Byte
etc this will work and work nicely, in addition to any concrete
utility/wrapper classes you use.
It is certainly nicer than writing lots of code to read the Object[],
create a new array and copy the elements into it. Sure it's easy, but WM
could be doing it for you.
What do you think?
There's also the possibility we should examine, of adding a WebMacroList
interface and have WM wrap an instance of this around the underlying list
type from the template (iterator, enumeration, Object[], List etc) and look
for methods with that in the signature - i.e. public void
myMethod(WebMacroList list)
This might give us some performance wins and also make it easier to support
any kind of list in methods. Currently we have to make our signature public
void myMethod(Object) and then use a utility function to convert it from
whatever list type it is.
Again, WM could be doing this for us.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
* Available For Hire *
See my CV at http://www.anyware.co.uk/marc/
|
|
From: <web...@st...> - 2003-07-07 09:31:05
|
On Sun, 6 Jul 2003, Brian Goetz wrote: | > I really, truly, think we should be able to find a way to replace all | > internal uses of FastWriter with Writer. | > | > Then the caller has the option of passing in a (slow) Writer of their own, | > or getting a FastWriter from WM and using that. | > | > Most of all, it should be trivial. | | It is. Stop worrying about it. It'll be fine. Slightly "I'm The Coder of the Universe"-ish remark, though. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: <web...@st...> - 2003-07-07 09:23:46
|
On Sat, 5 Jul 2003, Marc Palmer wrote: | This is just one reason why exposing FastWriter is bad news. Why should it | even be exposed at all anyway?! Just make it delegate to a normal Writer | and have no "public API" methods that use it. YES! I HATE FASTWRITER! I can't see no reason at all to expose internal "performance hacks". Gimme a Writer, and write to it the normal Writer-methods. OR, do a "instanceof" on the crucial places, and do the performance magic there. And how much performance gain is it anyways? -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Lane S. <la...@op...> - 2003-07-07 06:52:57
|
Brian Goetz wrote: >It is. Stop worrying about it. It'll be fine. > will you be committing something to look at in the next few days? -l |
237 messages has been excluded from this view by a project administrator.
