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

Re: [Webmacro-devel] Release 2.0

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

On Tue, 03 Jun 2003 22:10:00 -0700, Lane Sharman <la...@op...> 
wrote:

> How does getting a release 2.0 beta look by, say, july 31st? I am really 
> excited about erics syntax changes and by the templet/eval directive. We 
> need a solid 2.0 release for marc's ignition. And, it is about time to 
> establish the next bar.

Please note: I am very grateful for Lane's support for my web-app to date, 
but I do not want anybody to think that I assume that it will automatically 
become part of the WM project. That is for all the active WM developers to 
decide - and if it's not part of WM, Wangjammers will release it. However I 
hope that people like it as I think it will be a real enabling technology 
for WebMacro users.

I don't know how much I'll be able to help with the 2.0 release precisely 
because of the webapp and other projects I have to complete. I've been 
working on the webapp almost solid for the last 2 months now and need to 
get back to finding some paid work soon, after finishing some other WM- 
based non-profit projects!

However, for me one of the biggest things I would like to see in 2.0 is the 
rationalisation of the entire WM package structure, plus a .jar of WM-dev 
approved optional helper classes and context tools.

Someone with IDEA or similar should do the package reorganisation. I 
suggest we start working on the list of renames/refactorings so that there 
is a "job sheet" for someone to do it. I'll start this off soon with a mail 
on this subject. I can probably do this refactoring if nobody else will 
take the bait - but it may take a while for me to find the time.

It may be "fun" to get working because of SF's insistence on SSH for CVS 
connections, but it should be do-able somehow. It will really save us a lot 
of time if we can use a tool like IDEA to manage the many changes to CVS 
that will be required.

We will also need some agreed guidelines for how changes to CVS should 
occur - such as will we start a new 2.0 source tree, based on a copy of the 
existing source and lose the history on files we moved between packages - 
knowing they will still have the old history in the 1.x source tree. This 
sounds like a good idea to me...

Bear in mind that I hate CVS, it is the spawn of the devil (in terms of 
usability with Java in particular), and I may completely screw up the 
source tree if IDEA isn't doing the changes for me automatically. :-)

Best wishes,
Marc
-- 
Marc Palmer
Contract Java Consultant/Developer

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

Re: [Webmacro-devel] The duplicate logging bug - found?

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

> I think you found it, Marc. Just create a Set for Servlet_Context 
> instances and then, like you suggested, only add a target if the current 
> Servlet_Context is not in the set.

That will keep servlet context instances from being garbage collected
when their web apps are unloaded.  These should be weak references.

Re: [Webmacro-devel] The duplicate logging bug - found?

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

Marc Palmer wrote:

>
> Hi,
>
> OK so Eric and Lane bitching at me on webmacro-user about fixing the 
> bug that's annoying me in WM where I have 4 WM instances and am 
> getting 4 copies of everything in the log! 

<snip>

>
> Eric + Lane, thanks for kicking my ass into this - if this is it, it 
> wasn't too hard. :-) 

I think you found it, Marc. Just create a Set for Servlet_Context 
instances and then, like you suggested, only add a target if the current 
Servlet_Context is not in the set.

-Lane

>
>
> Best wishes,
> Marc
>

[Webmacro-devel] Release 2.0

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

How does getting a release 2.0 beta look by, say, july 31st? I am really 
excited about erics syntax changes and by the templet/eval directive. We 
need a solid 2.0 release for marc's ignition. And, it is about time to 
establish the next bar.

-Lane

[Webmacro-devel] The duplicate logging bug - found?

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

Hi,

OK so Eric and Lane bitching at me on webmacro-user about fixing the bug 
that's annoying me in WM where I have 4 WM instances and am getting 4 
copies of everything in the log!

I think I've found it, but I may be wrong. I'm using a Servlet - and I have 
multiple WM instances each with their own WM properties, created using the 
same Servlet's ServletContext. So... here's the relevant bit of log init 
code from ServletBroker:

   public void initLog(Settings config) {
      String logFile = config.getSetting("LogFile");
      if ((logFile == null || logFile.equals(""))
            && _config.getBooleanSetting("LogUsingServletLog"))
         _ls.addTarget(new ServletLog(_servletContext, _config));
      else
         initLog();
   }

I think the issue here is that the LogSystem (_ls) which is provided by the 
inherited Broker code, is the same for every ServletBroker instance - 
because Broker requires a "name" parameter to its constructor, and with 
ServletBroker we always pass in the ServletContext.toString() - i.e. the 
same for every WM instance I create.

So my belief is that this leads to a single LogSystem instance being shared 
by all my WM instances, and they each add a new target to that LogSystem - 
hence every log line repeated once for every WM instance I have.

Sound correct?

Now the hard part. Any ideas for a solution? Shouldn't the correct 
behaviour be that there is only one log target per ServletContext?

In which case, we need a way to know that we have already added a target 
for our servlet context, and not add it again. A static Set of 
ServletContext's - and if current context not there we add a target and add 
our context to the set?

Suggestions welcome - especially if I'm missing something or am in danger 
of screwing up something else I don't understand.

Eric + Lane, thanks for kicking my ass into this - if this is it, it wasn't 
too hard. :-)

Best wishes,
Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

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

Re: Map Support (was: Re: [Webmacro-devel] #templet directive)

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

the : is being used in java 1.5 over the new iterator:

for (element : list) {
    System.out.println(element)
}
read "object element in list"

so I would definitely vote for :

-Lane

Eric B. Ridge wrote:

> On Tuesday, May 27, 2003, at 10:17  AM, Keats wrote:
>
>> From: "Endre Stølsvik" <web...@st...>
>>
>>> Alignment with Velocity?
>>
>>
>> Does anybody know what syntax Velocity ended up with?  I don't think 
>> it's
>> made it into their docs yet.
>
>
> I just IM'd Geir about it.  His response:  "I don't recall".  Plus, I 
> don't think this has made it into any of their recent beta releases.
>
> Maybe it's time for V to align with WM, and they can use { "key" : 
> "value" }  :)
>
> eric
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

I suppose you could argue this either way.  Ultimately we should probably=20
rename DefaultEEH to LaxEEH and change the configured default to Cranky or =

something.  Even better would be to have a setup wizard to manage these=20
basic settings.

Keats



On Tuesday, May 27, 2003, at 05:07  PM, Keats=5FK...@di...=20
wrote:

>
> Try this simple template to see what I'm saying:
>
> #set $obj=3Dnull
> #if ($obj.Prop=3D=3Dnull){ EQUAL }
> #else { NOT EQUAL }
>
> If you are using the DefaultEEH, you should see "EQUAL". =A0You *will*=20
> get error reported in the log.

hmm.  okay.  I see.  Is this good?  Shouldn't $obj.Prop throw here?=20
Even in DEEH?

eric

>
> The DefaultEEH is very lax about evaluating (as opposed to expanding)=20
> variables.
>
> Keats
>
>
>
> On Tuesday, May 27, 2003, at 04:32 =A0PM, Keats=5FK...@di...
> wrote:
>
> >
> > What's happening here is that an exception is getting thrown, but the
> > DefaultEEH ignores it during eval and just returns null. =A0So your
> > expression becomes
> >
> > #if (null > 0){
> >
> > A "not comparable" exception makes a bit more sense in this context.
> > =A0We could probably improve this to say "Cannot compare null to an
> > Integer" or something.
>
> $somethingThatIsNull.SomeProperty isn't null. =A0It won't evaluate in any
> other context...
>
> eric
>
> >
> > The good news is that a more informative message gets logged, and of
> > course you can use a stricter EEH.
> >
> > Keats
> >
> >
> >
> > This is totally unrelated I'm sure, but it's another incorrect =A0
> > exception I noticed today.
> >
> > #if ($document.PageCount > 0) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do stuff
> > }
> >
> > where .PageCount is:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public int getPageCount();
> >
> > The exception I got was:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Objects not comparable
> >
> > It turned out that $document was null. =A0So shouldn't WM have said =A0
> > something like "$document is null. =A0Cannot access .PageCount"?
> >
> > eric
> >
> > On Tuesday, May 27, 2003, at 02:22 =A0PM, Keats=5FK...@di... =
=A0
> > wrote:
> >
> > >
> > > I agree totally. =A0I'm just trying to tread lightly and reduce the =
=A0
> > > possibilities for regression errors. =A0I don't know if there is any =

> =A0
> > > reason why we would want to continue after an exception, but =A0
> > > apparently somebody thought there was at some point.
> > >
> > > If anybody wants to look at the code in question, it's:
> > >
> > >=20
> org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), =A0
> > > line 1185.
> > >
> > >=20
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/
> > > org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-
> > > type=3Dtext/vnd.viewcvs-markup
> > >
> > > Keats
> > >
> > >
> > >
> > > On Tue, 27 May 2003 12:48:05 -0400, <Keats=5FK...@di...>
> > wrote:
> > >
> > > > I've tracked this down and patched it locally, but I need to do=20
> a =A0
> > > bit of
> > > > regression testing before I commit it.
> > >
> > > Great work!
> > >
> > > > The problem is a bit esoteric. =A0It has to do with the fact that =
=A0
> > > there can
> > > > be multiple "set" methods for a primitive type. =A0The
> > PropertyOperator
> > > > just tries them all until one works, ignoring any exceptions=20
> along
> > =A0
> > > the
> > > > way. =A0So if you hit an exception in a primitive "set" operation,
> > WM =A0
> > > acts
> > > > as if there was no appropriate method found -- hence the
> > misleading =A0
> > > error
> > > > message.
> > > >
> > > > My patch just saves the exception and rethrows it if none of the=20
> =A0
> > > "set"
> > > > invocations were successful.
> > >
> > > Shouldn't "fail fast" be the real solution here? i.e. if any
> > exception
> > > occurs, kill it and don't look for more setters... more below...
> > >
> > > > One potential issue is that if you have both a "unary" setter and
> > a =A0
> > > "map"
> > > > setter, e.g.,
> > > >
> > > > public void setFoo(boolean val){ throw new RuntimeException(); }
> > > > public void set(String key, Object val){ map.put(key, val);
> > > > }
> > > > ...
> > > > #set $var.Foo=3Dtrue
> > > >
> > > > Under the current implementation if you get an exception in =A0
> > > setFoo(), WM
> > > > will blythely do something like:
> > > >
> > > > set("Foo", new Boolean(true));
> > > >
> > > > With the patch this would spew the RTE. =A0This seems more sensible
> > to =A0
> > > me,
> > > > it's possible some applications rely on this behavior.
> > >
> > > Personally this sounds a bit crazy to me. What is the reasoning,=20
> if =A0
> > > any,
> > > for WM to keep trying other setters compatible with the types=20
> being =A0
> > > used?
> > >
> > > This can have all kinds of weird repercussions, like=20
> half-completed =A0
> > > "set"
> > > mechanisms that throw an exception and then it rolls onto another
> > one =A0
> > > to do
> > > more damage.
> > >
> > > This seems like very bad logic to me. If an exception occurs using=20
> a
> > > compatible setter, it should be assumed that the value is bad or
> > there =A0
> > > is a
> > > bug, and the code shoud jump out and spew the exception.
> > >
> > > Hiding the error and carrying on to see if any other setters work =A0
> > > is... a
> > > little screwy - and could be hiding obscure bugs!
> > >
> > > Anyone know if it is it there for a specific reason?
> > >
> > > Marc
> > >
> >
>
>
>

Re: [Webmacro-devel] Incorrect exception reporting

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

On Tuesday, May 27, 2003, at 05:07  PM, Kea...@di...=20
wrote:

>
> Try this simple template to see what I'm saying:
>
> #set $obj=3Dnull
> #if ($obj.Prop=3D=3Dnull){ EQUAL }
> #else { NOT EQUAL }
>
> If you are using the DefaultEEH, you should see "EQUAL". =A0You *will*=20=

> get error reported in the log.

hmm.  okay.  I see.  Is this good?  Shouldn't $obj.Prop throw here? =20
Even in DEEH?

eric

>
> The DefaultEEH is very lax about evaluating (as opposed to expanding)=20=

> variables.
>
> Keats
>
>
>
> On Tuesday, May 27, 2003, at 04:32 =A0PM, Kea...@di...
> wrote:
>
> >
> > What's happening here is that an exception is getting thrown, but =
the
> > DefaultEEH ignores it during eval and just returns null. =A0So your
> > expression becomes
> >
> > #if (null > 0){
> >
> > A "not comparable" exception makes a bit more sense in this context.
> > =A0We could probably improve this to say "Cannot compare null to an
> > Integer" or something.
>
> $somethingThatIsNull.SomeProperty isn't null. =A0It won't evaluate in =
any
> other context...
>
> eric
>
> >
> > The good news is that a more informative message gets logged, and of
> > course you can use a stricter EEH.
> >
> > Keats
> >
> >
> >
> > This is totally unrelated I'm sure, but it's another incorrect =A0
> > exception I noticed today.
> >
> > #if ($document.PageCount > 0) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do stuff
> > }
> >
> > where .PageCount is:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public int getPageCount();
> >
> > The exception I got was:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Objects not comparable
> >
> > It turned out that $document was null. =A0So shouldn't WM have said =
=A0
> > something like "$document is null. =A0Cannot access .PageCount"?
> >
> > eric
> >
> > On Tuesday, May 27, 2003, at 02:22 =A0PM, Kea...@di... =
=A0
> > wrote:
> >
> > >
> > > I agree totally. =A0I'm just trying to tread lightly and reduce =
the =A0
> > > possibilities for regression errors. =A0I don't know if there is =
any=20
> =A0
> > > reason why we would want to continue after an exception, but =A0
> > > apparently somebody thought there was at some point.
> > >
> > > If anybody wants to look at the code in question, it's:
> > >
> > >=20
> org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), =A0
> > > line 1185.
> > >
> > >=20
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/
> > > org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-
> > > type=3Dtext/vnd.viewcvs-markup
> > >
> > > Keats
> > >
> > >
> > >
> > > On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...>
> > wrote:
> > >
> > > > I've tracked this down and patched it locally, but I need to do=20=

> a =A0
> > > bit of
> > > > regression testing before I commit it.
> > >
> > > Great work!
> > >
> > > > The problem is a bit esoteric. =A0It has to do with the fact =
that =A0
> > > there can
> > > > be multiple "set" methods for a primitive type. =A0The
> > PropertyOperator
> > > > just tries them all until one works, ignoring any exceptions=20
> along
> > =A0
> > > the
> > > > way. =A0So if you hit an exception in a primitive "set" =
operation,
> > WM =A0
> > > acts
> > > > as if there was no appropriate method found -- hence the
> > misleading =A0
> > > error
> > > > message.
> > > >
> > > > My patch just saves the exception and rethrows it if none of the=20=

> =A0
> > > "set"
> > > > invocations were successful.
> > >
> > > Shouldn't "fail fast" be the real solution here? i.e. if any
> > exception
> > > occurs, kill it and don't look for more setters... more below...
> > >
> > > > One potential issue is that if you have both a "unary" setter =
and
> > a =A0
> > > "map"
> > > > setter, e.g.,
> > > >
> > > > public void setFoo(boolean val){ throw new RuntimeException(); }
> > > > public void set(String key, Object val){ map.put(key, val);
> > > > }
> > > > ...
> > > > #set $var.Foo=3Dtrue
> > > >
> > > > Under the current implementation if you get an exception in =A0
> > > setFoo(), WM
> > > > will blythely do something like:
> > > >
> > > > set("Foo", new Boolean(true));
> > > >
> > > > With the patch this would spew the RTE. =A0This seems more =
sensible
> > to =A0
> > > me,
> > > > it's possible some applications rely on this behavior.
> > >
> > > Personally this sounds a bit crazy to me. What is the reasoning,=20=

> if =A0
> > > any,
> > > for WM to keep trying other setters compatible with the types=20
> being =A0
> > > used?
> > >
> > > This can have all kinds of weird repercussions, like=20
> half-completed =A0
> > > "set"
> > > mechanisms that throw an exception and then it rolls onto another
> > one =A0
> > > to do
> > > more damage.
> > >
> > > This seems like very bad logic to me. If an exception occurs using=20=

> a
> > > compatible setter, it should be assumed that the value is bad or
> > there =A0
> > > is a
> > > bug, and the code shoud jump out and spew the exception.
> > >
> > > Hiding the error and carrying on to see if any other setters work =
=A0
> > > is... a
> > > little screwy - and could be hiding obscure bugs!
> > >
> > > Anyone know if it is it there for a specific reason?
> > >
> > > Marc
> > >
> >
>
>
>

Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

Try this simple template to see what I'm saying:

#set $obj=3Dnull
#if ($obj.Prop=3D=3Dnull){ EQUAL }
#else { NOT EQUAL }

If you are using the DefaultEEH, you should see "EQUAL".  You *will* get=20
error reported in the log.

The DefaultEEH is very lax about evaluating (as opposed to expanding)=20
variables.

Keats



On Tuesday, May 27, 2003, at 04:32  PM, Keats=5FK...@di...=20
wrote:

>
> What's happening here is that an exception is getting thrown, but the=20
> DefaultEEH ignores it during eval and just returns null. =A0So your=20
> expression becomes
>
> #if (null > 0){
>
> A "not comparable" exception makes a bit more sense in this context.=20
> =A0We could probably improve this to say "Cannot compare null to an=20
> Integer" or something.

$somethingThatIsNull.SomeProperty isn't null.  It won't evaluate in any=20
other context...

eric

>
> The good news is that a more informative message gets logged, and of=20
> course you can use a stricter EEH.
>
> Keats
>
>
>
> This is totally unrelated I'm sure, but it's another incorrect =A0
> exception I noticed today.
>
> #if ($document.PageCount > 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do stuff
> }
>
> where .PageCount is:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public int getPageCount();
>
> The exception I got was:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Objects not comparable
>
> It turned out that $document was null. =A0So shouldn't WM have said =A0
> something like "$document is null. =A0Cannot access .PageCount"?
>
> eric
>
> On Tuesday, May 27, 2003, at 02:22 =A0PM, Keats=5FK...@di... =A0
> wrote:
>
> >
> > I agree totally. =A0I'm just trying to tread lightly and reduce the =A0
> > possibilities for regression errors. =A0I don't know if there is any =A0
> > reason why we would want to continue after an exception, but =A0
> > apparently somebody thought there was at some point.
> >
> > If anybody wants to look at the code in question, it's:
> >
> > org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), =A0
> > line 1185.
> >
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/
> > org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-
> > type=3Dtext/vnd.viewcvs-markup
> >
> > Keats
> >
> >
> >
> > On Tue, 27 May 2003 12:48:05 -0400, <Keats=5FK...@di...>=20
> wrote:
> >
> > > I've tracked this down and patched it locally, but I need to do a =A0
> > bit of
> > > regression testing before I commit it.
> >
> > Great work!
> >
> > > The problem is a bit esoteric. =A0It has to do with the fact that =A0
> > there can
> > > be multiple "set" methods for a primitive type. =A0The=20
> PropertyOperator
> > > just tries them all until one works, ignoring any exceptions along=20
> =A0
> > the
> > > way. =A0So if you hit an exception in a primitive "set" operation,=20
> WM =A0
> > acts
> > > as if there was no appropriate method found -- hence the=20
> misleading =A0
> > error
> > > message.
> > >
> > > My patch just saves the exception and rethrows it if none of the =A0
> > "set"
> > > invocations were successful.
> >
> > Shouldn't "fail fast" be the real solution here? i.e. if any=20
> exception
> > occurs, kill it and don't look for more setters... more below...
> >
> > > One potential issue is that if you have both a "unary" setter and=20
> a =A0
> > "map"
> > > setter, e.g.,
> > >
> > > public void setFoo(boolean val){ throw new RuntimeException(); }
> > > public void set(String key, Object val){ map.put(key, val);
> > > }
> > > ...
> > > #set $var.Foo=3Dtrue
> > >
> > > Under the current implementation if you get an exception in =A0
> > setFoo(), WM
> > > will blythely do something like:
> > >
> > > set("Foo", new Boolean(true));
> > >
> > > With the patch this would spew the RTE. =A0This seems more sensible=20
> to =A0
> > me,
> > > it's possible some applications rely on this behavior.
> >
> > Personally this sounds a bit crazy to me. What is the reasoning, if =A0
> > any,
> > for WM to keep trying other setters compatible with the types being =A0
> > used?
> >
> > This can have all kinds of weird repercussions, like half-completed =A0
> > "set"
> > mechanisms that throw an exception and then it rolls onto another=20
> one =A0
> > to do
> > more damage.
> >
> > This seems like very bad logic to me. If an exception occurs using a
> > compatible setter, it should be assumed that the value is bad or=20
> there =A0
> > is a
> > bug, and the code shoud jump out and spew the exception.
> >
> > Hiding the error and carrying on to see if any other setters work =A0
> > is... a
> > little screwy - and could be hiding obscure bugs!
> >
> > Anyone know if it is it there for a specific reason?
> >
> > Marc
> >
>

Re: [Webmacro-devel] Incorrect exception reporting

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

On Tuesday, May 27, 2003, at 04:32  PM, Kea...@di...=20
wrote:

>
> What's happening here is that an exception is getting thrown, but the=20=

> DefaultEEH ignores it during eval and just returns null. =A0So your=20
> expression becomes
>
> #if (null > 0){
>
> A "not comparable" exception makes a bit more sense in this context.=20=

> =A0We could probably improve this to say "Cannot compare null to an=20
> Integer" or something.

$somethingThatIsNull.SomeProperty isn't null.  It won't evaluate in any=20=

other context...

eric

>
> The good news is that a more informative message gets logged, and of=20=

> course you can use a stricter EEH.
>
> Keats
>
>
>
> This is totally unrelated I'm sure, but it's another incorrect =A0
> exception I noticed today.
>
> #if ($document.PageCount > 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do stuff
> }
>
> where .PageCount is:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public int getPageCount();
>
> The exception I got was:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Objects not comparable
>
> It turned out that $document was null. =A0So shouldn't WM have said =A0
> something like "$document is null. =A0Cannot access .PageCount"?
>
> eric
>
> On Tuesday, May 27, 2003, at 02:22 =A0PM, Kea...@di... =A0=

> wrote:
>
> >
> > I agree totally. =A0I'm just trying to tread lightly and reduce the =
=A0
> > possibilities for regression errors. =A0I don't know if there is any =
=A0
> > reason why we would want to continue after an exception, but =A0
> > apparently somebody thought there was at some point.
> >
> > If anybody wants to look at the code in question, it's:
> >
> > org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), =
=A0
> > line 1185.
> >
> > =
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/
> > org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-
> > type=3Dtext/vnd.viewcvs-markup
> >
> > Keats
> >
> >
> >
> > On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...>=20
> wrote:
> >
> > > I've tracked this down and patched it locally, but I need to do a =
=A0
> > bit of
> > > regression testing before I commit it.
> >
> > Great work!
> >
> > > The problem is a bit esoteric. =A0It has to do with the fact that =
=A0
> > there can
> > > be multiple "set" methods for a primitive type. =A0The=20
> PropertyOperator
> > > just tries them all until one works, ignoring any exceptions along=20=

> =A0
> > the
> > > way. =A0So if you hit an exception in a primitive "set" operation,=20=

> WM =A0
> > acts
> > > as if there was no appropriate method found -- hence the=20
> misleading =A0
> > error
> > > message.
> > >
> > > My patch just saves the exception and rethrows it if none of the =A0=

> > "set"
> > > invocations were successful.
> >
> > Shouldn't "fail fast" be the real solution here? i.e. if any=20
> exception
> > occurs, kill it and don't look for more setters... more below...
> >
> > > One potential issue is that if you have both a "unary" setter and=20=

> a =A0
> > "map"
> > > setter, e.g.,
> > >
> > > public void setFoo(boolean val){ throw new RuntimeException(); }
> > > public void set(String key, Object val){ map.put(key, val);
> > > }
> > > ...
> > > #set $var.Foo=3Dtrue
> > >
> > > Under the current implementation if you get an exception in =A0
> > setFoo(), WM
> > > will blythely do something like:
> > >
> > > set("Foo", new Boolean(true));
> > >
> > > With the patch this would spew the RTE. =A0This seems more =
sensible=20
> to =A0
> > me,
> > > it's possible some applications rely on this behavior.
> >
> > Personally this sounds a bit crazy to me. What is the reasoning, if =
=A0
> > any,
> > for WM to keep trying other setters compatible with the types being =
=A0
> > used?
> >
> > This can have all kinds of weird repercussions, like half-completed =
=A0
> > "set"
> > mechanisms that throw an exception and then it rolls onto another=20
> one =A0
> > to do
> > more damage.
> >
> > This seems like very bad logic to me. If an exception occurs using a
> > compatible setter, it should be assumed that the value is bad or=20
> there =A0
> > is a
> > bug, and the code shoud jump out and spew the exception.
> >
> > Hiding the error and carrying on to see if any other setters work =A0
> > is... a
> > little screwy - and could be hiding obscure bugs!
> >
> > Anyone know if it is it there for a specific reason?
> >
> > Marc
> >
> >
> >
> > --
> > Marc Palmer
> > Contract Java Consultant/Developer
> >
> > http://www.anyware.co.uk/marc/
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>

Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

What's happening here is that an exception is getting thrown, but the=20
DefaultEEH ignores it during eval and just returns null.  So your=20
expression becomes

#if (null > 0){

A "not comparable" exception makes a bit more sense in this context.  We=20
could probably improve this to say "Cannot compare null to an Integer" or=20
something.

The good news is that a more informative message gets logged, and of=20
course you can use a stricter EEH.

Keats



This is totally unrelated I'm sure, but it's another incorrect=20
exception I noticed today.

#if ($document.PageCount > 0) {
                 do stuff
}

where .PageCount is:
                 public int getPageCount();

The exception I got was:
                 Objects not comparable

It turned out that $document was null.  So shouldn't WM have said=20
something like "$document is null.  Cannot access .PageCount"?

eric

On Tuesday, May 27, 2003, at 02:22  PM, Keats=5FK...@di...=20
wrote:

>
> I agree totally. =A0I'm just trying to tread lightly and reduce the=20
> possibilities for regression errors. =A0I don't know if there is any=20
> reason why we would want to continue after an exception, but=20
> apparently somebody thought there was at some point.
>
> If anybody wants to look at the code in question, it's:
>
> org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(),=20
> line 1185.
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/=20
> org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-=20
> type=3Dtext/vnd.viewcvs-markup
>
> Keats
>
>
>
> On Tue, 27 May 2003 12:48:05 -0400, <Keats=5FK...@di...> wrote:
>
> > I've tracked this down and patched it locally, but I need to do a=20
> bit of
> > regression testing before I commit it.
>
> Great work!
>
> > The problem is a bit esoteric. =A0It has to do with the fact that=20
> there can
> > be multiple "set" methods for a primitive type. =A0The PropertyOperator
> > just tries them all until one works, ignoring any exceptions along=20
> the
> > way. =A0So if you hit an exception in a primitive "set" operation, WM=20
> acts
> > as if there was no appropriate method found -- hence the misleading=20
> error
> > message.
> >
> > My patch just saves the exception and rethrows it if none of the=20
> "set"
> > invocations were successful.
>
> Shouldn't "fail fast" be the real solution here? i.e. if any exception
> occurs, kill it and don't look for more setters... more below...
>
> > One potential issue is that if you have both a "unary" setter and a=20
> "map"
> > setter, e.g.,
> >
> > public void setFoo(boolean val){ throw new RuntimeException(); }
> > public void set(String key, Object val){ map.put(key, val);
> > }
> > ...
> > #set $var.Foo=3Dtrue
> >
> > Under the current implementation if you get an exception in=20
> setFoo(), WM
> > will blythely do something like:
> >
> > set("Foo", new Boolean(true));
> >
> > With the patch this would spew the RTE. =A0This seems more sensible to =

> me,
> > it's possible some applications rely on this behavior.
>
> Personally this sounds a bit crazy to me. What is the reasoning, if=20
> any,
> for WM to keep trying other setters compatible with the types being=20
> used?
>
> This can have all kinds of weird repercussions, like half-completed=20
> "set"
> mechanisms that throw an exception and then it rolls onto another one=20
> to do
> more damage.
>
> This seems like very bad logic to me. If an exception occurs using a
> compatible setter, it should be assumed that the value is bad or there=20
> is a
> bug, and the code shoud jump out and spew the exception.
>
> Hiding the error and carrying on to see if any other setters work=20
> is... a
> little screwy - and could be hiding obscure bugs!
>
> Anyone know if it is it there for a specific reason?
>
> Marc
>
>
>
> --
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Incorrect exception reporting

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

This is totally unrelated I'm sure, but it's another incorrect =20
exception I noticed today.

#if ($document.PageCount > 0) {
	do stuff
}

where .PageCount is:
	public int getPageCount();

The exception I got was:
	Objects not comparable

It turned out that $document was null.  So shouldn't WM have said =20
something like "$document is null.  Cannot access .PageCount"?

eric

On Tuesday, May 27, 2003, at 02:22  PM, Kea...@di... =20
wrote:

>
> I agree totally. =A0I'm just trying to tread lightly and reduce the =20=

> possibilities for regression errors. =A0I don't know if there is any =20=

> reason why we would want to continue after an exception, but =20
> apparently somebody thought there was at some point.
>
> If anybody wants to look at the code in question, it's:
>
> org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), =20=

> line 1185.
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/=20=

> org/webmacro/engine/PropertyOperatorCache.java?rev=3D1.17&content-=20
> type=3Dtext/vnd.viewcvs-markup
>
> Keats
>
>
>
> On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...> =
wrote:
>
> > I've tracked this down and patched it locally, but I need to do a =20=

> bit of
> > regression testing before I commit it.
>
> Great work!
>
> > The problem is a bit esoteric. =A0It has to do with the fact that =20=

> there can
> > be multiple "set" methods for a primitive type. =A0The =
PropertyOperator
> > just tries them all until one works, ignoring any exceptions along =20=

> the
> > way. =A0So if you hit an exception in a primitive "set" operation, =
WM =20
> acts
> > as if there was no appropriate method found -- hence the misleading =20=

> error
> > message.
> >
> > My patch just saves the exception and rethrows it if none of the =20
> "set"
> > invocations were successful.
>
> Shouldn't "fail fast" be the real solution here? i.e. if any exception
> occurs, kill it and don't look for more setters... more below...
>
> > One potential issue is that if you have both a "unary" setter and a =20=

> "map"
> > setter, e.g.,
> >
> > public void setFoo(boolean val){ throw new RuntimeException(); }
> > public void set(String key, Object val){ map.put(key, val);
> > }
> > ...
> > #set $var.Foo=3Dtrue
> >
> > Under the current implementation if you get an exception in =20
> setFoo(), WM
> > will blythely do something like:
> >
> > set("Foo", new Boolean(true));
> >
> > With the patch this would spew the RTE. =A0This seems more sensible =
to =20
> me,
> > it's possible some applications rely on this behavior.
>
> Personally this sounds a bit crazy to me. What is the reasoning, if =20=

> any,
> for WM to keep trying other setters compatible with the types being =20=

> used?
>
> This can have all kinds of weird repercussions, like half-completed =20=

> "set"
> mechanisms that throw an exception and then it rolls onto another one =20=

> to do
> more damage.
>
> This seems like very bad logic to me. If an exception occurs using a
> compatible setter, it should be assumed that the value is bad or there =
=20
> is a
> bug, and the code shoud jump out and spew the exception.
>
> Hiding the error and carrying on to see if any other setters work =20
> is... a
> little screwy - and could be hiding obscure bugs!
>
> Anyone know if it is it there for a specific reason?
>
> Marc
>
>
>
> --
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>

Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

I agree totally.  I'm just trying to tread lightly and reduce the 
possibilities for regression errors.  I don't know if there is any reason 
why we would want to continue after an exception, but apparently somebody 
thought there was at some point.

If anybody wants to look at the code in question, it's:

org.webmacro.engine.PropertyOperatorCache.MethodAccessor.setImpl(), line 
1185.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/webmacro/engine/PropertyOperatorCache.java?rev=1.17&content-type=text/vnd.viewcvs-markup

Keats



On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...> wrote:

> I've tracked this down and patched it locally, but I need to do a bit of 

> regression testing before I commit it.

Great work!

> The problem is a bit esoteric.  It has to do with the fact that there 
can 
> be multiple "set" methods for a primitive type.  The PropertyOperator 
> just tries them all until one works, ignoring any exceptions along the 
> way.  So if you hit an exception in a primitive "set" operation, WM acts 

> as if there was no appropriate method found -- hence the misleading 
error 
> message.
>
> My patch just saves the exception and rethrows it if none of the "set" 
> invocations were successful.

Shouldn't "fail fast" be the real solution here? i.e. if any exception 
occurs, kill it and don't look for more setters... more below...

> One potential issue is that if you have both a "unary" setter and a 
"map" 
> setter, e.g.,
>
> public void setFoo(boolean val){ throw new RuntimeException(); }
> public void set(String key, Object val){ map.put(key, val);
> }
> ...
> #set $var.Foo=true
>
> Under the current implementation if you get an exception in setFoo(), WM 

> will blythely do something like:
>
> set("Foo", new Boolean(true));
>
> With the patch this would spew the RTE.  This seems more sensible to me, 

> it's possible some applications rely on this behavior.

Personally this sounds a bit crazy to me. What is the reasoning, if any, 
for WM to keep trying other setters compatible with the types being used?

This can have all kinds of weird repercussions, like half-completed "set" 
mechanisms that throw an exception and then it rolls onto another one to 
do 
more damage.

This seems like very bad logic to me. If an exception occurs using a 
compatible setter, it should be assumed that the value is bad or there is 
a 
bug, and the code shoud jump out and spew the exception.

Hiding the error and carrying on to see if any other setters work is... a 
little screwy - and could be hiding obscure bugs!

Anyone know if it is it there for a specific reason?

Marc



-- 
Marc Palmer
Contract Java Consultant/Developer

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



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Incorrect exception reporting

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

On Tue, 27 May 2003 12:48:05 -0400, <Kea...@di...> wrote:

> I've tracked this down and patched it locally, but I need to do a bit of 
> regression testing before I commit it.

Great work!

> The problem is a bit esoteric.  It has to do with the fact that there can 
> be multiple "set" methods for a primitive type.  The PropertyOperator 
> just tries them all until one works, ignoring any exceptions along the 
> way.  So if you hit an exception in a primitive "set" operation, WM acts 
> as if there was no appropriate method found -- hence the misleading error 
> message.
>
> My patch just saves the exception and rethrows it if none of the "set" 
> invocations were successful.

Shouldn't "fail fast" be the real solution here? i.e. if any exception 
occurs, kill it and don't look for more setters... more below...

> One potential issue is that if you have both a "unary" setter and a "map" 
> setter, e.g.,
>
> public void setFoo(boolean val){ throw new RuntimeException(); }
> public void set(String key, Object val){ map.put(key, val);
> }
> ...
> #set $var.Foo=true
>
> Under the current implementation if you get an exception in setFoo(), WM 
> will blythely do something like:
>
> set("Foo", new Boolean(true));
>
> With the patch this would spew the RTE.  This seems more sensible to me, 
> it's possible some applications rely on this behavior.

Personally this sounds a bit crazy to me. What is the reasoning, if any, 
for WM to keep trying other setters compatible with the types being used?

This can have all kinds of weird repercussions, like half-completed "set" 
mechanisms that throw an exception and then it rolls onto another one to do 
more damage.

This seems like very bad logic to me. If an exception occurs using a 
compatible setter, it should be assumed that the value is bad or there is a 
bug, and the code shoud jump out and spew the exception.

Hiding the error and carrying on to see if any other setters work is... a 
little screwy - and could be hiding obscure bugs!

Anyone know if it is it there for a specific reason?

Marc



-- 
Marc Palmer
Contract Java Consultant/Developer

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

Re: [Webmacro-devel] Incorrect exception reporting

[<Kea...@di...>]

I've tracked this down and patched it locally, but I need to do a bit of 
regression testing before I commit it.

The problem is a bit esoteric.  It has to do with the fact that there can 
be multiple "set" methods for a primitive type.  The PropertyOperator just 
tries them all until one works, ignoring any exceptions along the way.  So 
if you hit an exception in a primitive "set" operation, WM acts as if 
there was no appropriate method found -- hence the misleading error 
message.

My patch just saves the exception and rethrows it if none of the "set" 
invocations were successful.

One potential issue is that if you have both a "unary" setter and a "map" 
setter, e.g.,

  public void setFoo(boolean val){ 
     throw new RuntimeException(); 
  }
  public void set(String key, Object val){ 
     map.put(key, val);
  }
...
  #set $var.Foo=true

Under the current implementation if you get an exception in setFoo(), WM 
will blythely do something like:

  set("Foo", new Boolean(true));

With the patch this would spew the RTE.  This seems more sensible to me, 
it's possible some applications rely on this behavior.

Keats



Hi,

Anyone with experience of PropertyOperator stuff (I think that's where 
this 
lies) fancy tackling a simple snafu?

I got this:

org.webmacro.PropertyException: No method to set "xmlCV.Advanced" to type 
class java.lang.Boolean in supplied context (class 
org.webmacro.servlet.WebContext) at 
jndi:/localhost/ignition/marc/portholes/blurb.wmt:4.2

...but the method DOES exist. However it was throwing a RuntimeException 
in 
its implementation. This is incorrectly being caught and reported as "No 
method" instead of reporting the real exception.

Marc

Re: Map Support (was: Re: [Webmacro-devel] #templet directive)

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

On Tuesday, May 27, 2003, at 10:17  AM, Keats wrote:
> From: "Endre St=F8lsvik" <web...@st...>
>> Alignment with Velocity?
>
> Does anybody know what syntax Velocity ended up with?  I don't think=20=

> it's
> made it into their docs yet.

I just IM'd Geir about it.  His response:  "I don't recall".  Plus, I=20
don't think this has made it into any of their recent beta releases.

Maybe it's time for V to align with WM, and they can use { "key" :=20
"value" }  :)

eric

Re: Map Support (was: Re: [Webmacro-devel] #templet directive)

[Keats <kea...@di...>]

RnJvbTogIkVuZHJlIFN0+GxzdmlrIiA8d2VibWFjcm9Ac3RvbHN2aWsuY29tPg0KPiBBbGlnbm1l
bnQgd2l0aCBWZWxvY2l0eT8NCg0KRG9lcyBhbnlib2R5IGtub3cgd2hhdCBzeW50YXggVmVsb2Np
dHkgZW5kZWQgdXAgd2l0aD8gIEkgZG9uJ3QgdGhpbmsgaXQncw0KbWFkZSBpdCBpbnRvIHRoZWly
IGRvY3MgeWV0Lg0KDQpLZWF0cw0KDQoNCg==

Re: Map Support (was: Re: [Webmacro-devel] #templet directive)

[<web...@st...>]

On Tue, 13 May 2003, Keats wrote:

| Eric,
|
| This is way cool!  Personally I'd vote for colons, but I can live with the
| "=>" if there is some advantage to this.
|
| You rock.
|

Alignment with Velocity?


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

Re: [Webmacro-devel] Request for help/advice on the WM app

[<web...@st...>]

| That sounds like security through obscurity ;-)  (which doesn't work).
|
| If you have anything sensitive in your templates you should re-examine why
| and look at moving it out!

Listen, I couldn't agree more.

BUT.

The default setting should be as safe as possible, to hinder people from
fucking themselves up. And people -does not- make sane, secure code.
"They" code really, really bad. And if it is possible to include some
security sensitive snacks within a template, then that -will- be done at
some point in time.

|
| > It is bad that misconfiguration from a user of your webapp might reveal
| > his entire source. And if the user doesn't understand the implication, he
| > could use other extensions for his templates -that he usually includes-
| > from other templates. These templates would not be catched by your
| > Servlet
| > mappings, and would always be accessible directly if I know their name.
| >
| > Similar bugs have had to been fixed with plenty of other systems, e.g.
| > Tomcat that served JSP's "static" if you accessed them this way and that,
| > or PHP that had the same problem etc.
|
| Yes but those are not the same as what I'm writing. The idea is to use WM
| just for presentation and simple stuff. There really shouldn't be anything
| sensitive in scripts if they are purely for presentation.

Again: do you think all the developers that use your stuff are that smart?
If your stuff gets really good, then it will "evolve" like PHP has done,
into something very useful, very nice and very dangerous.

|
| I agree with you on the security issue, but it's really not a big deal if
| you use templates for what they are designed.

No. That goes for lots of problems with computers.

|
| JSP is a completely different problem. Badly written JSPs could have all
| kinds of horrible private stuff in there.

Exactly. As with PHP pages. As with your snacks-pages, after a while.

|
| > But of course, if you misconfigure Apache's PHP config, start it, then
| > your PHP files are of course available as source.
|
| Indeed.


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

Re: [Webmacro-devel] Guys!

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

On Fri, 16 May 2003 17:45:43 -0700, Lane Sharman <la...@sa...> wrote:

> I feel ignition will be an excellent addition to WM as a complimentary
> app like WM Wiki. A lot of good work has gone into it and I would
> like to be able to work on the source once it has become a bit
> more stable.

Thanks Lane. It's actually very stable at the moment, but I am considering 
the first release to WM developers as "first draft" and will be very 
interested in suggestions and contributions on the framework itself from WM 
developers.

It's the kind of thing that takes a few hours to get a grip on. It's very 
simple but it introduces some possibly new high-level concepts and a 
slightly different way of working for most.

> marc: did you get my url for the Visitor System?

Yes, check your OpenDoors account. There are some mails waiting for you...

-- 
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/

RE: [Webmacro-devel] Guys!

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

I feel ignition will be an excellent addition to WM as a complimentary
app like WM Wiki. A lot of good work has gone into it and I would
like to be able to work on the source once it has become a bit
more stable.

marc: did you get my url for the Visitor System?

-Lane
>--- Original Message ---
>From: Marc Palmer <ma...@an...>
>To: web...@li...
>Date: 5/15/03 4:55:14 AM
>

>Has anyone noticed that SourceForge now provide RSS news feeds
for every 
>project?
>
>I only just discovered this. Now I have WebMacro project news
coming up on 
>my site, using the new WebMacro webapp:
>
>If you want to see this in action, go to the following URL (this
is not 
>blatant self-promotion - just the nicest way to show it to you)
and look on 
>the right hand side, down under the BBC news feed.
>
>http://www.anyware.co.uk/ignition/marc/
>
>The layout's a little ugly with the huge description in there
from SF, but 
>you get the idea. I'm also using a helper to "summarise" text
to a max 
>length. Unfortunately some of the news items have HTML markup
in them such 
>as a href=.... The RSS 2 feeds from SF do not have a doctype
and are 
therefore not validated, which allows them to put crap HTML in
there. As a 
result I have had to HTML escape it all, as I am truncating the
news items 
to a maximum length as some can be very long.

That is our fault though - the RSS news items come from the project
news so 
if we refrain from using HTML in the news releases then we will
get much 
better results.

You can get project stats too - the raw XML is here:

http://sourceforge.net/export/rss2_projsummary.php?group_id=64597

This is kind of cool, I have to say. It would be nice to work
RSS into 
webmacro.org so we can have a single point where we update our
release news 
- i.e. SF. Then the WM site can feed off that, saving us all
time.

We should be able to do this easily using the XML helper we have
written, 
and the RSS display templates (handle RSS 0.91, 1.0 and 2.0).
I wouldn't 
know how to modify the Wiki app to do this though.

One annoying thing, due to the way Wiki URLs work, is that I
don't think it 
would be possible to run Wiki over the WebMacro webapp. Maybe
I'm wrong... 
we'll see later.

I'm hoping to release Alpha 1 of the webapp to you wm-dev guys
either this 
weekend or Monday(ish). Just polishing up docs and some "must
fix" issues, 
some refactoring in the XML helper and hopefully a rudimentary
SQL query 
action by then.

The plan is that I will show this to you guys and you can decide
whether or 
not this should become part of the whole WebMacro project. If
so, that is 
great. However if you guys don't like it, or the fact that I've
just 
designed and written this all myself so far, then I am happy
to just 
release it myself from our wangjammers.org site.

I was just thinking, now I am using the project on a live server
myself and 
how cool it is, that this project is too big to sit in WM's /contrib

gathering dust.

Best wishes,
Marc

-- 
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
Clara
The only event dedicated to issues related to Linux enterprise
solutions
www.enterpriselinuxforum.com

_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-deve>

Re: [Webmacro-devel] Request for help/advice on the WM app

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

On Mon, 19 May 2003 18:11:26 +0200 (CEST), Endre Stølsvik 
<web...@st...> wrote:

> I think you might have misunderstood WAR files a bit. Or, of course, I
> have..!
[snip]
> The deal is that a WAR file could be run -in place-from a CD-ROM. The
> unpacking "feature" for Tomcat is simly an implementation detail, it's
> more of a bug than a feature.

I'm sure many other servlet containers do it. Also, ISPs that host servlets 
usually only allow you access to a pre-expanded webapp dir so that you can 
edit your servlets and content without sending up a new .WAR all the time.

The trouble is the usage of servlets/WARs is not well defined.

I always hoped that WARs were for shrink-wrapped applications you can just 
drop in and run, but the reality of this seems very different.

> |
> | Are there any other solutions you guys can think of?
>
> Drop the WAR file thing, and do the following:
>
> Give users a jar-file (or two), -with-the version number in the filename
> (!!), and a text-README file that explains the Servlet definitions and 
> URL
> mappings that he must make to get the stuff up and running.

Hmm, I don't think this will be necessary. After all Tomcat and Apache (for 
example) still include server.xml and httpd.conf in their distros. It's up 
to the user to backup their existing stuff and port it across I suppose.

> When this is done, you may add the templates.
>
> Then, when the user's application is finished, -he-could pack it into a
> WAR file for deployment at a customer's server.

Yes, but that is for developer usage. One of the main usages for this 
webapp is for non-developers who just want to use WM for cool websites. 
This means just editing templates.

I am sure the best solution is to have a separate template path setting, 
outside of the webapps tree.

> |
> | It is highly desirable to have the WebMacro templates in exactly the 
> same
> | place existing HTML or other content will be stored.
>
> As mentioned, I don't think so, as revealing your source is bad bad
> security-wise. Better let those hackers try to figure out your logic by
> themselves than give them the entire source.

That sounds like security through obscurity ;-)  (which doesn't work).

If you have anything sensitive in your templates you should re-examine why 
and look at moving it out!

> It is bad that misconfiguration from a user of your webapp might reveal
> his entire source. And if the user doesn't understand the implication, he
> could use other extensions for his templates -that he usually includes-
> from other templates. These templates would not be catched by your 
> Servlet
> mappings, and would always be accessible directly if I know their name.
>
> Similar bugs have had to been fixed with plenty of other systems, e.g.
> Tomcat that served JSP's "static" if you accessed them this way and that,
> or PHP that had the same problem etc.

Yes but those are not the same as what I'm writing. The idea is to use WM 
just for presentation and simple stuff. There really shouldn't be anything 
sensitive in scripts if they are purely for presentation.

I agree with you on the security issue, but it's really not a big deal if 
you use templates for what they are designed.

JSP is a completely different problem. Badly written JSPs could have all 
kinds of horrible private stuff in there.

> But of course, if you misconfigure Apache's PHP config, start it, then
> your PHP files are of course available as source.

Indeed.

Thanks,
Marc

-- 
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/

Re: [Webmacro-devel] (no subject)

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

On Monday, May 19, 2003, at 01:23  PM, Marc Palmer wrote:
> On Mon, 19 May 2003 17:56:46 +0200 (CEST), Endre St=F8lsvik=20
> <web...@st...> wrote:
>>
>> A WAR file is a jar that includes everything, including the doc-root?=20=

>> So
>> how are you going to put templates in there as well afterwards?
>
> No - this does not have to be the case.

On a somewhat related note, does the jsdk spec provide ability to have=20=

multiple document roots?

eric

>
> The idea is that you can install the webapp on your own machine and=20
> then add your own docs to a directory, either the expanded webapp dir,=20=

> webapps' WEB-INF, or to another path althogether.
>
> But, as a Java developer you can produce your own WAR including the=20
> app and your docs, for a "shrink-wrapped" application.
>
>> | The file-mapping scheme is nicer, but only works if the templates=20=

>> are under
>> | the webapp's document root (not WEB-INF) but that is no big deal=20
>> unless you
>> | accidentally delete your web.xml in which case all your templates=20=

>> are
>> | downloaded as text (oh yes, I did it by mistake).
>>
>> That is a very bad security problem. I've mentioned this tons of=20
>> times,
>> and I can't understand that this isn't OBVIOUS to people!!! ;)
>
> I know. It is a problem, but it is not such a huge problem as far as I=20=

> can see. If there is really private dangerous stuff in your templates,=20=

> then in general you are writing your templates wrong! i.e. SQL user=20
> names and passwords.
>
>> Put your templates where the dangerous hackah' web-user out there=20
>> can't
>> find them, that is, beneath WEB-INF.
>
> Or somewhere else completely, like /home/me/mytemplates :)
>
> --=20
> Marc Palmer
> AnyWare Ltd.
> http://www.anyware.co.uk/marc/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is painful,=20=

> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] (no subject)

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

On Mon, 19 May 2003 17:56:46 +0200 (CEST), Endre Stølsvik 
<web...@st...> wrote:

> |
> | Hiya,
> |
> | I was wondering if you guys can share some thoughts on a deployment 
> issue
> | with the forthcoming "WM app".
> |
> | The problem is with the WAR web-application concept really.
>
> A WAR file is a jar that includes everything, including the doc-root? So
> how are you going to put templates in there as well afterwards?

No - this does not have to be the case.

The idea is that you can install the webapp on your own machine and then 
add your own docs to a directory, either the expanded webapp dir, webapps' 
WEB-INF, or to another path althogether.

But, as a Java developer you can produce your own WAR including the app and 
your docs, for a "shrink-wrapped" application.

> | The file-mapping scheme is nicer, but only works if the templates are 
> under
> | the webapp's document root (not WEB-INF) but that is no big deal unless 
> you
> | accidentally delete your web.xml in which case all your templates are
> | downloaded as text (oh yes, I did it by mistake).
>
> That is a very bad security problem. I've mentioned this tons of times,
> and I can't understand that this isn't OBVIOUS to people!!! ;)

I know. It is a problem, but it is not such a huge problem as far as I can 
see. If there is really private dangerous stuff in your templates, then in 
general you are writing your templates wrong! i.e. SQL user names and 
passwords.

> Put your templates where the dangerous hackah' web-user out there can't
> find them, that is, beneath WEB-INF.

Or somewhere else completely, like /home/me/mytemplates :)

-- 
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/

Re: [Webmacro-devel] Request for help/advice on the WM app

[<web...@st...>]

I think you might have misunderstood WAR files a bit. Or, of course, I
have..!

| If you have a .WAR to upgrade with, you can't (well I can't) get Tomcat 4.x
| to overwrite the existing webapps/ignition directory when doing an auto-
| deploy. You have to delete the directory and then restart tomcat with the
| new .WAR in place ready for auto-deploy.
|
| Now this totally sucks because it makes upgrading complete hell. Not only
| do you have to stop Tomcat, you also have to copy all your document files
| back over the new upgraded auto-deployed webapps/ignition directory.

The deal is that a WAR file could be run -in place- from a CD-ROM. The
unpacking "feature" for Tomcat is simly an implementation detail, it's
more of a bug than a feature.

|
| This is a bit like having to reinstall your entire httpd doc root just to
| upgrade apache. It's a nightmare.

Weeeell..

|
| Are there any other solutions you guys can think of?

Drop the WAR file thing, and do the following:

Give users a jar-file (or two), -with- the version number in the filename
(!!), and a text-README file that explains the Servlet definitions and URL
mappings that he must make to get the stuff up and running.

When this is done, you may add the templates.

Then, when the user's application is finished, -he- could pack it into a
WAR file for deployment at a customer's server.

|
| It is highly desirable to have the WebMacro templates in exactly the same
| place existing HTML or other content will be stored.

As mentioned, I don't think so, as revealing your source is bad bad
security-wise. Better let those hackers try to figure out your logic by
themselves than give them the entire source.

It is bad that misconfiguration from a user of your webapp might reveal
his entire source. And if the user doesn't understand the implication, he
could use other extensions for his templates -that he usually includes-
from other templates. These templates would not be catched by your Servlet
mappings, and would always be accessible directly if I know their name.

Similar bugs have had to been fixed with plenty of other systems, e.g.
Tomcat that served JSP's "static" if you accessed them this way and that,
or PHP that had the same problem etc.

But of course, if you misconfigure Apache's PHP config, start it, then
your PHP files are of course available as source.

|
| We can't have people losing their content when they upgrade - and we
| shouldn't expect them to have to manually unzip the .WAR file over their
| existing webapps directory.
|
| ...why won't Tomcat just redeploy a .WAR? It's very annoying. All the
| options are on. Is this a problem peculiar to Tomcat 4.1 - do other servlet
| containers happily redeploy a .WAR without requiring a restart or the
| deletion of the webapp directory?

A "redeploy" does anywhichway seem to me like "get the old crap outta
there, and this new stuff in" -> Which would imply deleting the old
directory - and the new template files.. Maybe tomcat doesn't want to do
this -because- it sees that there are some unaccountable files in that
directory? PROBABLY not, but that would be a good safety precaution that
I'd try to build in!

Endre.