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

Re: [Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

Eric B. Ridge wrote:

> On Monday, December 2, 2002, at 04:14  PM, Eric B. Ridge wrote:
>
>>> That is my opinion. Now, if we got that straigthend out .. lets discuss
>>> whether it is a good idea.
>>
>>
>> Bad idea.  :)  If you want the sources, download the -src- distribution.
>
>
> I might be changing my mind.
>
> Here's the download stats for WM1.1b2 that SF provides:
>    -bin.tgz:  15 downloads
>    -bin.zip:  89 downloads
>    -src.tgz:  12 downloads
>    -src.zip:  50 downloads
>
> Makes me think that we should just provide 1 download package:  
> webmacro-everything.zip   Which includes all the sources, unit tests, 
> java docs, and binary .jar files, plus an ant target for making a 
> webmacro-src.zip file.
>
> thoughts? 

i think it would simplify the producer's life. In nc, he has a lot of 
other things to keep him busy just now :).

-lane

>
>
> eric
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

RE: [Webmacro-devel] unused Tools

[<kea...@na...>]

I basically agree with you -- and I went ahead and fixed this. =20

To put things in some perspective, performance is relative and the =
trade-off
are sometimes tricky.  ContextTools are instantiated once per new =
context
and contexts are pooled, so there's not a lot of overhead here.  =
Creating an
exception is relatively expensive, but since it's not being propagated =
up
the stack frame it shouldn't be too bad.  On the plus side, I guess it =
makes
to code a bit cleaner and faster in the "happy" cases.  Anyway, it's
definitely not something to do in a tight loop that's getting executed
thousands of times per second!

Keats=20

> -----Original Message-----
> From: Endre St=F8lsvik [mailto:web...@st...]
> Sent: Monday, December 09, 2002 9:02 AM
> To: kea...@na...
> Cc: gle...@av...; br...@qu...;
> web...@li...
> Subject: Re: [Webmacro-devel] unused Tools
>=20
>=20
> On Tue, 3 Dec 2002 kea...@na... wrote:
>=20
> | I've puzzled over this piece of code before.  Apparently=20
> there is the
> | ability to pass parameters from the configuration to the=20
> tools constructor,
> | but AFAIK noone has ever used this.  So it is kind of=20
> annoying that this
> | code always gets executed.
> |
> | I don't think there's a big hit with throwing and=20
> immediately catching the
> | exceptions, but all the diagnostic logging is annoying.  I=20
> suppose it would
> | be cleaner to just check for the constructors directly and=20
> avoid trying to
> | invoke them if they don't exist.  I could make this change=20
> if folks agree.
>=20
> Throwing an Exception is _expensive_. Filling in the stack-trace =
takes
> ages. One should _never_ use Exception-throwing in the normal=20
> code-path.
> Exceptions are for .. yes .. exceptions. It should only be used in =
the
> "rare-case", not the "common-case".
>=20
> The VM must also handle the Exception blocks, by going in and=20
> out of the
> try-blocks (there is a "machine-code" for doing this).
>=20
>=20
> --=20
> Mvh,
> Endre St=F8lsvik               M[+47 93054050] F[+47 51625182]
> Developer @ CoreTrek AS         -  http://www.coretrek.com/
> CoreTrek corporate portal / EIP -  http://www.corelets.com/
>=20

Re: [Webmacro-devel] unused Tools

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

On Tue, 3 Dec 2002 kea...@na... wrote:

| I've puzzled over this piece of code before.  Apparently there is the
| ability to pass parameters from the configuration to the tools constructor,
| but AFAIK noone has ever used this.  So it is kind of annoying that this
| code always gets executed.
|
| I don't think there's a big hit with throwing and immediately catching the
| exceptions, but all the diagnostic logging is annoying.  I suppose it would
| be cleaner to just check for the constructors directly and avoid trying to
| invoke them if they don't exist.  I could make this change if folks agree.

Throwing an Exception is _expensive_. Filling in the stack-trace takes
ages. One should _never_ use Exception-throwing in the normal code-path.
Exceptions are for .. yes .. exceptions. It should only be used in the
"rare-case", not the "common-case".

The VM must also handle the Exception blocks, by going in and out of the
try-blocks (there is a "machine-code" for doing this).


-- 
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] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

On Mon, 2 Dec 2002, Eric B.Ridge wrote:

| <snip>
|
| > earlier post), but even SUN use a source-zip. So go ahead. Source-zip
| > then. BUT INCLUDE IT IN THE BINARY DISTRIBUTION.
|
| > That is my opinion. Now, if we got that straigthend out .. lets discuss
| > whether it is a good idea.
|
| Bad idea.  :)  If you want the sources, download the -src- distribution.

Hehe!

Listen, I am not talking about the _source distribution_, but about the
source-zip. This is simply all the .java files PACKED pretty good. The
reason for this, is that _all_ reasonable IDEs use this for
code-completion (to fill inn the argument names), AND for "in-editor
javadoc lookup". You _do_ need the sources to do any real programming.
Hence, the binary _distribution_ will need the source files to be of any
use. When I distribute my application, I won't include the src.zip-file,
but I won't include the RELEASE-NOTES of the binary distribution either.

Following your logic, there's no need for any .tgz or .zip distributions
at all. You'd only need src.zip and webmacro-1.1b2.jar, only including,
respectively, the .java and the .class files.

<topic change>if you'll change the types of files, _include_ one more:
bz2. THAT's a good compression.

-- 
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] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

On Monday, December 2, 2002, at 04:14  PM, Eric B. Ridge wrote:
>> That is my opinion. Now, if we got that straigthend out .. lets 
>> discuss
>> whether it is a good idea.
>
> Bad idea.  :)  If you want the sources, download the -src- 
> distribution.

I might be changing my mind.

Here's the download stats for WM1.1b2 that SF provides:
    -bin.tgz:  15 downloads
    -bin.zip:  89 downloads
    -src.tgz:  12 downloads
    -src.zip:  50 downloads

Makes me think that we should just provide 1 download package:  
webmacro-everything.zip   Which includes all the sources, unit tests, 
java docs, and binary .jar files, plus an ant target for making a 
webmacro-src.zip file.

thoughts?

eric

Re: [Webmacro-devel] Hardcoded sizes of 1001

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

Glenn,

I think the proper place for the list of "feature improvements" is in 
Bugzilla. See http://webmacro.org. This will make it a little easier to 
prioritize.

-lane

Glenn Shute wrote:

>There are a number of places where hardcoded defaults sizes are set to 1001,
>since we have up to 50 runtime webmacro instances on a box these values take
>up a lot more memory and so we want to reduce these values if possible.
>
>We would like a config parameter to control these values so that the we do
>not have to modify the source files.
>
>Note: our change was to reduce the 1001 values to 101.
>
>      this(encoding,1001);
>./util/EncodingCache.java
>    public final static int DEFAULT_SIZE=101; // was 1001
>./util/ScalableIdentityMap.java
>    public final static int DEFAULT_SIZE=101; // was 1001
>./util/ScalableMap.java
>  private static final int DEFAULT_SIZE = 101; // was 1001
>./util/SimpleHashMap.java
>    private static final int DEFAULT_SIZE = 101; // was 1001
>./util/SimpleIdentityMap.java
>   private int _count2 = 1001;
>./util/UPool.java
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Microsoft Visual Studio.NET 
>comprehensive development tool, built to increase your 
>productivity. Try a free online hosted session at:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

Re: [Webmacro-devel] Re: Another Beta / TODO List?

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

Hi Glenn,

yes this is the right forum. And, would you like to contribute some PR 
in kind for WebMacro at Alta Vista as well as some other stuff we could 
use???

thanks,

Lane

Glenn Shute wrote:

>We (Altavista) could come up with a list of things we would like to get on
>the TODO list for a future WebMacro Release.
>
>Is this the right forum?
>
>Glenn Shute
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Microsoft Visual Studio.NET 
>comprehensive development tool, built to increase your 
>productivity. Try a free online hosted session at:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

RE: [Webmacro-devel] PropertyOperatorCache.java NullPointer Excep tion

[<kea...@na...>]

This change looks fine to me.  

Justin (or somebody way back when) had a propensity for catching NPEs
instead of checking for nulls.  I guess the theory was that if the nulls
happen very infrequently it's cheaper to catch the NPE than to add a test
for null.  

I don't know what the equation would be to determine what frequency of nulls
tips the balance, and I'm sure it probably varies from JVM to JVM.  In
general I think exceptions should be for "exceptional" cases, e.g., cases
you don't normally expect to encounter.  This doesn't seem to be such a
case, as passing null args to methods is a pretty normal thing to do.  

Maybe Brian (who knows a lot more about such things than me) can elucidate
us further.

Keats




> -----Original Message-----
> From: Glenn Shute [mailto:gle...@av...]
> Sent: Tuesday, December 03, 2002 7:01 PM
> To: web...@li...
> Subject: [Webmacro-devel] PropertyOperatorCache.java NullPointer
> Exception
> 
> 
> 
> This code in engine/PropertyOperatorCache.java was modified 
> as below to
> avoid the NullPointerException. This could happen a large 
> number of times
> when evaluating an template. I can't see any bad side effects 
> and we have
> been running with this code for some time now.
> 
> 
> ORIGINAL
> 			final Object get(Object instance, Object[] args)
> 			      throws PropertyException,
> NoSuchMethodException
> 			   {
> 			      Class[] types = new Class[ args.length ];
> 			      for (int i = 0; i < args.length; i++) {
> 			         try {
> 			            types[i] = args[i].getClass();
> 
> 
> 
> 
> 			         } catch (NullPointerException e) {
> 			            types[i] = null;
> 			         }
> 			      }
> 
> MODIFIED
> 			final Object get(Object instance, Object[] args)
> 			      throws PropertyException,
> NoSuchMethodException
> 			   {
> 			      Class[] types = new Class[ args.length ];
> 			      for (int i = 0; i < args.length; i++) {
> 			         try {
> 			         >>   if (args[i] == null) {
> 			         >>       types[i] = null;
> 			         >>   } else {
> 			         >>       types[i] = args[i].getClass();
> 			         >>   }
> 			         } catch (NullPointerException e) {
> 			            types[i] = null;
> 			         }
> 			      }
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET 
> comprehensive development tool, built to increase your 
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 

[Webmacro-devel] PropertyOperatorCache.java NullPointer Exception

[Glenn S. <gle...@av...>]

This code in engine/PropertyOperatorCache.java was modified as below to
avoid the NullPointerException. This could happen a large number of times
when evaluating an template. I can't see any bad side effects and we have
been running with this code for some time now.


ORIGINAL
			final Object get(Object instance, Object[] args)
			      throws PropertyException,
NoSuchMethodException
			   {
			      Class[] types = new Class[ args.length ];
			      for (int i = 0; i < args.length; i++) {
			         try {
			            types[i] = args[i].getClass();




			         } catch (NullPointerException e) {
			            types[i] = null;
			         }
			      }

MODIFIED
			final Object get(Object instance, Object[] args)
			      throws PropertyException,
NoSuchMethodException
			   {
			      Class[] types = new Class[ args.length ];
			      for (int i = 0; i < args.length; i++) {
			         try {
			         >>   if (args[i] == null) {
			         >>       types[i] = null;
			         >>   } else {
			         >>       types[i] = args[i].getClass();
			         >>   }
			         } catch (NullPointerException e) {
			            types[i] = null;
			         }
			      }

[Webmacro-devel] Hardcoded sizes of 1001

[Glenn S. <gle...@av...>]

There are a number of places where hardcoded defaults sizes are set to 1001,
since we have up to 50 runtime webmacro instances on a box these values take
up a lot more memory and so we want to reduce these values if possible.

We would like a config parameter to control these values so that the we do
not have to modify the source files.

Note: our change was to reduce the 1001 values to 101.

      this(encoding,1001);
./util/EncodingCache.java
    public final static int DEFAULT_SIZE=101; // was 1001
./util/ScalableIdentityMap.java
    public final static int DEFAULT_SIZE=101; // was 1001
./util/ScalableMap.java
  private static final int DEFAULT_SIZE = 101; // was 1001
./util/SimpleHashMap.java
    private static final int DEFAULT_SIZE = 101; // was 1001
./util/SimpleIdentityMap.java
   private int _count2 = 1001;
./util/UPool.java

RE: [Webmacro-devel] Re: Another Beta / TODO List?

[<kea...@na...>]

> /avmnt/3rdparty/java/src/org/webmacro/servlet/CGI_Impersonator
> .java:122:
> warning: getRealPath(java.lang.String) in javax.servlet.Ser
> vletRequest has been deprecated
>       { return requst_.getRealPath("/"); }                       ^
> /avmnt/3rdparty/java/src/org/webmacro/engine/EncodeFilter.java
> :46: warning:
> encode(java.lang.String) in java.net.URLEncoder has been
>  deprecated

This was deprecated with JSDK 2.1.  I don't believe the replacement method
in the ServletContext exists in JSDK 2.0, so as long as we continue to
support 2.0 I suppose we're stuck with this.

>       return (o != null) ? 
> java.net.URLEncoder.encode(o.toString()) : "";
>                                               ^
> /avmnt/3rdparty/java/src/org/webmacro/servlet/TextTool.java:15
> 1: warning:
> encode(java.lang.String) in java.net.URLEncoder has been d
> eprecated
>         return input == null ? null : 
> java.net.URLEncoder.encode (input);
>                                                          ^
> /avmnt/3rdparty/java/src/org/webmacro/servlet/TextTool.java:16
> 5: warning:
> decode(java.lang.String) in java.net.URLDecoder has been d
> eprecated
>         return input == null ? null : 
> java.net.URLDecoder.decode (input);
>                                                       

The replacement for this is was introduced in JDK 1.4.0.  I don't think
we're ready to jettison JDK 1.3.x yet.

   ^
> /avmnt/3rdparty/java/src/org/webmacro/servlet/ServletLog.java:
> 70: warning:
> log(java.lang.Exception,java.lang.String) in javax.servle
> t.ServletContext has been deprecated
>          _servletContext.log(e, _mf.format(_args));
>                         ^

Again, the replacement relies on JSDK 2.1+.

I think we just need to live with these for the time being.

Keats

RE: [Webmacro-devel] unused Tools

[<kea...@na...>]

I've puzzled over this piece of code before.  Apparently there is the
ability to pass parameters from the configuration to the tools constructor,
but AFAIK noone has ever used this.  So it is kind of annoying that this
code always gets executed.  

I don't think there's a big hit with throwing and immediately catching the
exceptions, but all the diagnostic logging is annoying.  I suppose it would
be cleaner to just check for the constructors directly and avoid trying to
invoke them if they don't exist.  I could make this change if folks agree.

Keats



> -----Original Message-----
> From: Glenn Shute [mailto:gle...@av...]
> Sent: Tuesday, December 03, 2002 6:08 PM
> To: 'Brian Goetz'
> Cc: 'web...@li...'
> Subject: RE: [Webmacro-devel] unused Tools
> 
> 
> 
> The code that causes an exception is here. I have a list of 
> other places
> where exceptions are caught and thrown which could be avoided 
> which I will
> list in another message.
> 
> webmacro/Context.java
> 
> addTool()
> ...
>       if (instance == null) {
>          try {
> exception>> Constructor ctor = c.getConstructor(_ctorArgs2);
>             Object[] args = new Object[1];
>             args[0] = key;
>             instance = ctor.newInstance(args);
>          } catch (Exception e) { 
> caught >>>  log.append("Trying 1-argument constructor: ");
>             log.append(e.toString());
>             log.append("\n");
>          }
>       }
> ...
> 
> 
> -----Original Message-----
> From: Brian Goetz [mailto:br...@qu...]
> Sent: Tuesday, December 03, 2002 2:52 PM
> To: Glenn Shute
> Cc: 'web...@li...'
> Subject: Re: [Webmacro-devel] unused Tools
> 
> 
> > There are a number of standard tools placed into the context in the
> > WebMacro.defaults file. Can I safely remove these tools 
> from the config so
> > they are not placed in the context. When and where are 
> these tools used?
> Are
> > they used internally for webmacro? Where should I look for 
> this type of
> > documentation? As far as I can tell we do not use these 
> tools and have our
> > own for similar features.
> 
> These tools are for use in templates.  WM does not rely on them (or
> shouldn't!)  You can remove them in your configuration.  
> 
> Don't remove them in WM.defaults; that'll only make it a pain 
> for you to
> merge with each version.  Instead, if you want to remove tool 
> X defined
> in WM.defaults, put this in your app config:
>   ContextTools.X: 
> 
> and this will negate the definition in WM.defaults.  
> 
> > The reason I ask is that when running in the debugger I notice that
> > when adding each of these tools into the context an exception is
> > thrown. It is caught and seems to be handled but we would like to
> > avoid this and all other unneccessary expections if possible.
> 
> This is probably a bug; can you post more info on these exceptions?
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET 
> comprehensive development tool, built to increase your 
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 

[Webmacro-devel] FastWriter Buffer Size

[Glenn S. <gle...@av...>]

The default size for the FastWriter buffer is hard coded at 4K. The main
page that we server is more like 60K and this means that this buffer is
reallocated and an arraycopy is done 4 times before shipping out the page.
When this buffer is returned it is reset back to 4K size and so we do
expensive operation for every single page that we ship.

We would like a way to set this default value in a config file and also a
new getInstance method that includes a size argument since sometime we want
a 25K buffer and sometimes we want a 64K buffer.


   final public static int DEFAULT_BUFFER_SIZE = 4096;

  public static FastWriter getInstance(Broker broker, OutputStream out,
String encoding) 

RE: [Webmacro-devel] unused Tools

[Glenn S. <gle...@av...>]

The code that causes an exception is here. I have a list of other places
where exceptions are caught and thrown which could be avoided which I will
list in another message.

webmacro/Context.java

addTool()
...
      if (instance == null) {
         try {
exception>> Constructor ctor = c.getConstructor(_ctorArgs2);
            Object[] args = new Object[1];
            args[0] = key;
            instance = ctor.newInstance(args);
         } catch (Exception e) { 
caught >>>  log.append("Trying 1-argument constructor: ");
            log.append(e.toString());
            log.append("\n");
         }
      }
...


-----Original Message-----
From: Brian Goetz [mailto:br...@qu...]
Sent: Tuesday, December 03, 2002 2:52 PM
To: Glenn Shute
Cc: 'web...@li...'
Subject: Re: [Webmacro-devel] unused Tools


> There are a number of standard tools placed into the context in the
> WebMacro.defaults file. Can I safely remove these tools from the config so
> they are not placed in the context. When and where are these tools used?
Are
> they used internally for webmacro? Where should I look for this type of
> documentation? As far as I can tell we do not use these tools and have our
> own for similar features.

These tools are for use in templates.  WM does not rely on them (or
shouldn't!)  You can remove them in your configuration.  

Don't remove them in WM.defaults; that'll only make it a pain for you to
merge with each version.  Instead, if you want to remove tool X defined
in WM.defaults, put this in your app config:
  ContextTools.X: 

and this will negate the definition in WM.defaults.  

> The reason I ask is that when running in the debugger I notice that
> when adding each of these tools into the context an exception is
> thrown. It is caught and seems to be handled but we would like to
> avoid this and all other unneccessary expections if possible.

This is probably a bug; can you post more info on these exceptions?

Re: [Webmacro-devel] unused Tools

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

> There are a number of standard tools placed into the context in the
> WebMacro.defaults file. Can I safely remove these tools from the config so
> they are not placed in the context. When and where are these tools used? Are
> they used internally for webmacro? Where should I look for this type of
> documentation? As far as I can tell we do not use these tools and have our
> own for similar features.

These tools are for use in templates.  WM does not rely on them (or
shouldn't!)  You can remove them in your configuration.  

Don't remove them in WM.defaults; that'll only make it a pain for you to
merge with each version.  Instead, if you want to remove tool X defined
in WM.defaults, put this in your app config:
  ContextTools.X: 

and this will negate the definition in WM.defaults.  

> The reason I ask is that when running in the debugger I notice that
> when adding each of these tools into the context an exception is
> thrown. It is caught and seems to be handled but we would like to
> avoid this and all other unneccessary expections if possible.

This is probably a bug; can you post more info on these exceptions?

[Webmacro-devel] unused Tools

[Glenn S. <gle...@av...>]

There are a number of standard tools placed into the context in the
WebMacro.defaults file. Can I safely remove these tools from the config so
they are not placed in the context. When and where are these tools used? Are
they used internally for webmacro? Where should I look for this type of
documentation? As far as I can tell we do not use these tools and have our
own for similar features.

ContextTools.Math: org.webmacro.servlet.MathTool
ContextTools.Text: org.webmacro.servlet.TextTool
ContextTools.Type: org.webmacro.servlet.TypeTool
ContextTools.Variable: org.webmacro.servlet.VariableTool
ContextTools.List: org.webmacro.servlet.ListTool

The reason I ask is that when running in the debugger I notice that when
adding each of these tools into the context an exception is thrown. It is
caught and seems to be handled but we would like to avoid this and all other
unneccessary expections if possible.

Glenn

RE: [Webmacro-devel] Re: Another Beta / TODO List?

[Glenn S. <gle...@av...>]

OK. This looks like the right forum. Here goes. We have a number of small
items we would like to discuss about getting into webmacro for our future
installations.

This is really trivial, but just to start things off I'm wondering if these
deprecated methods have been or will be fixed in future release:


/avmnt/3rdparty/java/src/org/webmacro/servlet/CGI_Impersonator.java:122:
warning: getRealPath(java.lang.String) in javax.servlet.Ser
vletRequest has been deprecated
      { return requst_.getRealPath("/"); }
                      ^
/avmnt/3rdparty/java/src/org/webmacro/engine/EncodeFilter.java:46: warning:
encode(java.lang.String) in java.net.URLEncoder has been
 deprecated
      return (o != null) ? java.net.URLEncoder.encode(o.toString()) : "";
                                              ^
/avmnt/3rdparty/java/src/org/webmacro/servlet/TextTool.java:151: warning:
encode(java.lang.String) in java.net.URLEncoder has been d
eprecated
        return input == null ? null : java.net.URLEncoder.encode (input);
                                                         ^
/avmnt/3rdparty/java/src/org/webmacro/servlet/TextTool.java:165: warning:
decode(java.lang.String) in java.net.URLDecoder has been d
eprecated
        return input == null ? null : java.net.URLDecoder.decode (input);
                                                         ^
/avmnt/3rdparty/java/src/org/webmacro/servlet/ServletLog.java:70: warning:
log(java.lang.Exception,java.lang.String) in javax.servle
t.ServletContext has been deprecated
         _servletContext.log(e, _mf.format(_args));
                        ^
5 warnings
EncodeFilter.java:46: warning: encode(java.lang.String) in
java.net.URLEncoder has been deprecated
      return (o != null) ? java.net.URLEncoder.encode(o.toString()) : "";
                                              ^
1 warning
CGI_Impersonator.java:122: warning: getRealPath(java.lang.String) in
javax.servlet.ServletRequest has been deprecated
      { return requst_.getRealPath("/"); }
                      ^
ServletLog.java:70: warning: log(java.lang.Exception,java.lang.String) in
javax.servlet.ServletContext has been deprecated
         _servletContext.log(e, _mf.format(_args));
                        ^
TextTool.java:151: warning: encode(java.lang.String) in java.net.URLEncoder
has been deprecated
        return input == null ? null : java.net.URLEncoder.encode (input);
                                                         ^
TextTool.java:165: warning: decode(java.lang.String) in java.net.URLDecoder
has been deprecated
        return input == null ? null : java.net.URLDecoder.decode (input);
                   

Re: [Webmacro-devel] Re: Another Beta / TODO List?

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

On Tuesday, December 3, 2002, at 03:33  PM, Glenn Shute wrote:
> We (Altavista) could come up with a list of things we would like to 
> get on
> the TODO list for a future WebMacro Release.
>
> Is this the right forum?

Absolutely!

eric

>
> Glenn Shute
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET
> comprehensive development tool, built to increase your
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] Re: Another Beta / TODO List?

[Glenn S. <gle...@av...>]

We (Altavista) could come up with a list of things we would like to get on
the TODO list for a future WebMacro Release.

Is this the right forum?

Glenn Shute

[Webmacro-devel] Another Beta / TODO List?

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

What's our TODO list at this point for WM 1.1?  We haven't committed 
any code changes since b2 (I did fix some build.xml issues).  What's 
left?

My list is pretty small:
    - clean up #macro error messages.
    - clean up $Variable.returnNull().doSomething() error message
    - clean up stack trace output.  I really hate the double stack 
traces output by RethrowableException.  Anyone else?  As a user of WM, 
I could care less where in WM's code the exception occurred, I want to 
see where in *my* code it happened.  I'm thinking some kind of 
configuration setting: VerboseStackTrace=true | false
    - get website wiki documents converted from serialized objects to 
XML, and integrate iText with Wiki so we can distribute the website as 
a PDF document.
    - make a decision about this #include recursion warning.  Just log a 
DEBUG message?  Some kind of recursion depth limit (yuck)?  Nothing at 
all?
    - make a decision about the -bin- and -src- distribution files

Anyone else?

eric

Re: [Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

<snip>

> earlier post), but even SUN use a source-zip. So go ahead. Source-zip
> then. BUT INCLUDE IT IN THE BINARY DISTRIBUTION.

> That is my opinion. Now, if we got that straigthend out .. lets discuss
> whether it is a good idea.

Bad idea.  :)  If you want the sources, download the -src- distribution.

This is no different than the jakarta folks, and no different than most 
of the projects on SourceForge.

I suppose we could make a third distribution:  -everything- (or 
-endre-) that includes all sources, .jars, and src.zip files + javadocs.

But then that's 6 files I gotta upload everytime I cut a release (.zip 
and .tgz of all 3 distros).
<topic change> Hey, let's just nuke .zip and only go with .tgz.  WinZip 
and Stuffit understand .tgz files.</topic change>

eric

Re: [Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

On Mon, 2 Dec 2002, Marc Palmer wrote:

| > Because the idea about jars is that _they_ are self-contained. Why make
| > the _distribution_ "as small as possible"? I'd rather like LOTS of
| > documentation (And the .src.zip file IS documentation, actually, it is
| the
| > most important part of the docs of them all), than a small distro. When I
| > distribute may _finshed app_, I'll only include the binary jar. That's
| why
| > "micro-jars" and such ideas are good; make a couple of different binary
| > jars, so that if I don't use that special feature, then I can make _my_
| > application distribution smaller. But when I, as a developer, download
| the
| > distribution, I'd like to have all docs available, please.
|
| I definitely -1 this. The binary release jar should not contain source.
|
| Sun put their src.zip and docs separate from rt.jar
|
| All the Apache projects I know have the src and docs separate, although
| you may download them in one ZIP.
|
| It would be extremely annoying to have to remove the source from every
| new WM jar in order to distribute it.

Did I write this that confusing?! Very strange. Probably used wrong
words.. Let's try to sort this OUT:

The _binary jar_ should of course not include the source. There should be
two jars. One called webmacro-1.1b2.jar, and then one
webmacro-1.1b2-src.[jar|zip] (I personally don't give a flying f...).
THIS IS ABOUT THE DISTRIBUTION. The -distribution-. The package. The
tarball. The tar.gz. The Zip-file that you uncompress somwhere. The
deliverance. What do you call it?

The -distro- should have a source-jar. And if you don't like a source-jar,
then use a source-zip. That is so totally completely irrelevant that I
could not care less. I thought that it was "normal" with a jar (ref. some
earlier post), but even SUN use a source-zip. So go ahead. Source-zip
then. BUT INCLUDE IT IN THE BINARY DISTRIBUTION.

That is my opinion. Now, if we got that straigthend out .. lets discuss
whether it is a good idea.




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

[Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

> Because the idea about jars is that _they_ are self-contained. Why make
> the _distribution_ "as small as possible"? I'd rather like LOTS of
> documentation (And the .src.zip file IS documentation, actually, it is 
> the

If we ever get lots of documentation, we'll include it.  Unless I 
screwed up, the javadocs should have been included in the binary 
release.  In the source release, you gotta "ant javadoc" yourself.

> most important part of the docs of them all), than a small distro. 
> When I
> distribute may _finshed app_, I'll only include the binary jar. That's 
> why
> "micro-jars" and such ideas are good; make a couple of different binary
> jars, so that if I don't use that special feature, then I can make _my_
> application distribution smaller. But when I, as a developer, download 
> the
> distribution, I'd like to have all docs available, please.
>
> Why not include the entire website too? I'm serious.

Because the website isn't (yet) in a form that can be redistributed.  
And when it is (I'm making progress on this now), it will be another 
download:  webmacro-docs-x.x.tgz.  There's megabytes of .html on the 
site now.  Again, no point in making everyone download stuff they might 
not need.

> | > as e.g. CodeGuide from Omnicore.com does (man, I just love that
> | > program!).
> | > The OS project Eclipse (from IBM) is also cool and does this. Which
> | > means
> | > that I'd like to have the source in a jar, yes, please!
> |
> | IDEA (www.intellij.com) is better than both of 'em.  :)
>
> Price? CodeGuide is cheap-ish, while Eclipse is bleedin' Open Source! 
> Man,
> that is cool!

Sometimes you get what you pay for.  With Idea, this is true.  :)

eric

Re: [Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

> Because the idea about jars is that _they_ are self-contained. Why mak=
e
> the _distribution_ "as small as possible"? I'd rather like LOTS of
> documentation (And the .src.zip file IS documentation, actually, it is=
=20
the
> most important part of the docs of them all), than a small distro. Whe=
n I
> distribute may _finshed app_, I'll only include the binary jar. That's=
=20
why
> "micro-jars" and such ideas are good; make a couple of different binar=
y
> jars, so that if I don't use that special feature, then I can make _my=
_
> application distribution smaller. But when I, as a developer, download=
=20
the
> distribution, I'd like to have all docs available, please.

I definitely -1 this. The binary release jar should not contain source.=


Sun put their src.zip and docs separate from rt.jar

All the Apache projects I know have the src and docs separate, although =

you may download them in one ZIP.

It would be extremely annoying to have to remove the source from every=20=

new WM jar in order to distribute it.

There's nothing wrong with the way the rest of the world works at the=20=

moment, on this front.

Jars are not meant to contain source or docs as far as I know, they are =

the archive format of choice for java binary redistributables. Please=20=

show me any Sun docs that say that Jars are the correct place to put you=
r=20
source and/or javadocs. I've never seen such a doc, and if it exists I'd=
=20
like to know.

Surely jars are only (mis)used for other non-binary/runtime file purpose=
s=20
because they are basically ZIP compatible and it's possible to do it, if=
=20
you're lazy ;-)

Imagine if you downloaded a web-app from someone and they'd put all the =

javadocs and src inside it, that would be pretty annoying if you just=20=

wanted to deploy the app without 20MB of docs/src with it.

What are you guys quarrelling over here anyway? Just have this:

webmacro10.jar      - binary code only, ready to run
webmacro10-docs.zip =96 Docs only
webmacro10-src.zip  =96 Src only
webmacro10-all.zip  - contains all docs files, source, and jar

This way, everybody can get what they want. If Endre wants to have=20
everything in one jar he can just rename webmacro10-all.zip to a .jar!=20=

Then he has the choice to waste server space and bandwidth if he wants=20=

;-)

Marc

[Webmacro-devel] Re: [WebMacro-user] ANNOUNCE: WebMacro 1.1b2 is out!

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

On Fri, 29 Nov 2002, Eric B.Ridge wrote:

| On Thursday, November 28, 2002, at 07:39  AM, Endre Stølsvik wrote:
| > However, THAT isn't too cool. This because I'll probably need to _use_
| > the
| > library, especially program to it. That means that I'll load the
| > source-jar into the IDE to get parameter naming and Javadoc
| > integration,
|
| hmm.  This is something I never considered.  My goal was to make the
| binary distribution download size *smaller*.  Including
| webmacro-src.zip increases the size by 400k to 700k depending of which
| format you download (.tgz or .zip).
|
| I don't think it's unusual for a project to only provide sources in a
| separate download.  I realize for you it adds an extra step, but for
| the majority of people that don't use the sources, why make them
| download stuff they don't need?

Because the idea about jars is that _they_ are self-contained. Why make
the _distribution_ "as small as possible"? I'd rather like LOTS of
documentation (And the .src.zip file IS documentation, actually, it is the
most important part of the docs of them all), than a small distro. When I
distribute may _finshed app_, I'll only include the binary jar. That's why
"micro-jars" and such ideas are good; make a couple of different binary
jars, so that if I don't use that special feature, then I can make _my_
application distribution smaller. But when I, as a developer, download the
distribution, I'd like to have all docs available, please.

Why not include the entire website too? I'm serious.

| > as e.g. CodeGuide from Omnicore.com does (man, I just love that
| > program!).
| > The OS project Eclipse (from IBM) is also cool and does this. Which
| > means
| > that I'd like to have the source in a jar, yes, please!
|
| IDEA (www.intellij.com) is better than both of 'em.  :)

Price? CodeGuide is cheap-ish, while Eclipse is bleedin' Open Source! Man,
that is cool!


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