Re: jakarta-site2

2001-03-15 Thread Sam Ruby

Jon Stevens wrote:

 now, if i can get some help with the encoding problem,
 that would be nice...

===
RCS file: /home/cvs/jakarta-site2/xdocs/site/whoweare.xml,v
retrieving revision 1.25
diff -u -r1.25 whoweare.xml
--- whoweare.xml2001/03/15 06:25:59 1.25
+++ whoweare.xml2001/03/15 09:28:09
@@ -213,10 +214,7 @@
 /p

 p
-!-- temporary disabled until encoding issues can be figured out
-bCeki G#252;lc#252;/b (ceki at apache.org)
---
-bCeki Gulcu/b (ceki at apache.org)
+b![CDATA[Ceki Guuml;lcuuml;]]/b (ceki at apache.org)
 br/
 Ceki is the founder of the log4j project. Time permitting, he also does
 custom development for clients. See a
===
RCS file: 
/home/cvs/jakarta-velocity/src/java/org/apache/velocity/anakia/OutputWrapper.java,v
retrieving revision 1.2
diff -u -r1.2 OutputWrapper.java
--- OutputWrapper.java  2001/03/15 04:02:35 1.2
+++ OutputWrapper.java  2001/03/15 09:29:42
@@ -59,6 +59,7 @@

 import org.jdom.Element;
 import org.jdom.output.XMLOutputter;
+import org.jdom.CDATA;

 /**
  * This class extends XMLOutputter in order to provide
@@ -102,4 +103,14 @@
 }
 return buff.toString();
 }
+
+/**
+ * Passthru CDATA content uninterpreted
+ */
+protected void printCDATASection(CDATA cdata, java.io.Writer out,
+ int indentLevel) throws IOException
+{
+out.write(cdata.getText());
+}
+
 }

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: encoding problems with Jakarta-site

2001-03-15 Thread Ceki Gülcü

At 22:12 14.03.2001 -0800, Jon Stevens wrote:
Ok,

I think this encoding stuff with Ceki's name is a bug in the OSX JVM that
I'm using, so we may have to revert back to using "u" for a bit until the
OSX GM is out and I can test/use that. :-( The weird thing is that I'm not
convinced that it is the OSX JVM though...here is why:

Here is the input file:

p
bCeki G#252;lc#252;/b (ceki at apache.org)
br/
Ceki is the founder of the log4j project. Time permitting, he also does
custom development for clients. See a
href="http://www.qos.ch"www.qos.ch/a for more info.
/p

Here is the little test program:

import java.io.*;
import java.lang.*;
import java.util.*;
import org.jdom.*;
import org.jdom.input.*;
import org.jdom.output.*;

public class Test
{
public static void main (String[] args)
{
try
{
Document d = new SAXBuilder().build(args[0]);
XMLOutputter outp = new XMLOutputter("", false);
outp.setEncoding("ISO-8859-1");
FileWriter fw = new FileWriter("test.html");
outp.output(d, fw);
fw.close();
}
catch (Exception e)
{
}
}
}

java Test input.txt

produces:

?xml version="1.0" encoding="ISO-8859-1"?
p
bCeki Glc/b (ceki at apache.org)
br /
Ceki is the founder of the
log4j project. Time permitting, he also does
custom development for clients.
See a href="http://www.qos.ch"www.qos.ch/a for more info.
/p

As you can see, Ceki's name is correctly shown. The weird thing is that if I
take the file and load it in my browser, the weird characters show up for
the "u"'s, not the correct ones...

Can you send file produced by "java Test input.txt "



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: encoding problems with Jakarta-site

2001-03-15 Thread Ceki Gülcü


Sorry, my previous note was incomplete. I've been bitten by Eudora's CTRL-E syndorome.

At 22:12 14.03.2001 -0800, Jon Stevens wrote:

java Test input.txt

produces:

?xml version="1.0" encoding="ISO-8859-1"?
p
bCeki Glc/b (ceki at apache.org)
br /
Ceki is the founder of the
log4j project. Time permitting, he also does
custom development for clients.
See a href="http://www.qos.ch"www.qos.ch/a for more info.
/p

As you can see, Ceki's name is correctly shown. The weird thing is that if I
take the file and load it in my browser, the weird characters show up for
the "u"'s, not the correct ones...

Could we look at the file produced by "java Test input.txt" as a binary? Could it be 
that your OS (not the JVM) is screwing things up? Cheers, Ceki



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: jakarta-site2

2001-03-15 Thread Geir Magnusson Jr.

Done and done. 

(this was my first site update, so if someone would give it a look-see
to make sure all is well, I would be much obliged...)

geir


Sam Ruby wrote:
 
 Jon Stevens wrote:
 
  now, if i can get some help with the encoding problem,
  that would be nice...
 
 ===
 RCS file: /home/cvs/jakarta-site2/xdocs/site/whoweare.xml,v
 retrieving revision 1.25
 diff -u -r1.25 whoweare.xml
 --- whoweare.xml2001/03/15 06:25:59 1.25
 +++ whoweare.xml2001/03/15 09:28:09
 @@ -213,10 +214,7 @@
  /p
 
  p
 -!-- temporary disabled until encoding issues can be figured out
 -bCeki G#252;lc#252;/b (ceki at apache.org)
 ---
 -bCeki Gulcu/b (ceki at apache.org)
 +b![CDATA[Ceki Guuml;lcuuml;]]/b (ceki at apache.org)
  br/
  Ceki is the founder of the log4j project. Time permitting, he also does
  custom development for clients. See a
 ===
 RCS file: 
/home/cvs/jakarta-velocity/src/java/org/apache/velocity/anakia/OutputWrapper.java,v
 retrieving revision 1.2
 diff -u -r1.2 OutputWrapper.java
 --- OutputWrapper.java  2001/03/15 04:02:35 1.2
 +++ OutputWrapper.java  2001/03/15 09:29:42
 @@ -59,6 +59,7 @@
 
  import org.jdom.Element;
  import org.jdom.output.XMLOutputter;
 +import org.jdom.CDATA;
 
  /**
   * This class extends XMLOutputter in order to provide
 @@ -102,4 +103,14 @@
  }
  return buff.toString();
  }
 +
 +/**
 + * Passthru CDATA content uninterpreted
 + */
 +protected void printCDATASection(CDATA cdata, java.io.Writer out,
 + int indentLevel) throws IOException
 +{
 +out.write(cdata.getText());
 +}
 +
  }
 
 - Sam Ruby
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Geir Magnusson Jr.   [EMAIL PROTECTED]
Developing for the web?  See http://jakarta.apache.org/velocity/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Ceki Gülcü


Conor,

At 11:02 15.03.2001 +1100, Conor MacNeill wrote:
Ceki,

I would like to give you some feedback on the common directory layout
http://jakarta.apache.org/site/dirlayout.html

This is mostly from my Ant perspective and somewhat from my impression of
some other common practices in the Jakarta sub-projects. I do realize that
these are just recommendations.

docs directory
=
I have noticed a trend to put the sub-project's web pages into this area. I
wonder is that is a good thing since the web pages and the user
documentation are two different things, IMHO. The web pages are potentially
much more ephemeral than the product documentation that accompanies a
release. When you build a release, it may not make much sense to include
that ephemeral information (such as sub-project news) with the project docs.

For Ant, I made a separate directory for the webpages (webpage). I had to do
this anyway since there was already an index.html file in the Ant docs
directory, although I have subsequently moved that.

As Jon pointed out earlier, I do not see the advantage for distinguishing between 
documentation and the web pages. It is quite pleasant to be able to browse a project 
web site locally on a file system without requiring a network connection.

build directory

Many of the Jakarta projects put the build files in the project's root
directory and use the build directory for build results, such as build
classes which will be jarred up into the distribution

So by build/ you actually mean the dist/ directory of the dirlayout.html document. As 
far as I can see there is nothing wrong with that except that if we make a choice 
regardless of what it is we should stick to it, a bit like indentation I guess.

build/lib
==
If this is a non-binding recommendation, I don't see why it supports two
locations to put the binary jars. It should either be lib or build/lib,
IMHO.

Jon, explained that the build/lib is for building (compiling) and lib/ for runtime. I 
confess that I don't really understand the difference... See also the last paragraph 
of this note.

dist
=
I believe this should be a distribution "image" and it is therefore not
really appropriate to place the distribution binaries (.zip, .gz files) in
this location. For Ant, I create the distributions into a directory called
distribution. It contains the source and binary distributions, the latter
being equivalent to the dist directory.

Why are you making a distinction? What's wrong putting the distribution images, src, 
birnary, documentation or otherwise in dist/ and the javac generated classes under 
dist/classes?  


dist/classes
=
I don't believe we want generally want raw classfiles in the dist directory.
Many projects put this into build/classes and place just jars in the dist
directory.

Why? What's the rationale? Moreover, in the classes directory there might be more 
classes than in the jars.

Other
==

I think that there should be a recommendation that any file/dir not under
CVS control should go into the .cvsignore file.

There is no need to adding any files to .cvsignore if you add files to CVS control 
individually as in

 cvs add x.java y.java

instead of

 cvs add *

or am I missing something? 

Do we want to make recommendations about the structure of the dist
directory? This is what end-users will actually use and there may be
benefits in a common approach here too. In Ant, for example, we create a
dist/bin directory to contain scripts and executables useful for running
Ant. we also place all generated jars in the dist/lib directory. Perhaps
they are similar or the same as these recommendations.

Restricting the dist/ directory to the binaries that the end-users will actually use 
is a nice abstraction imho. 

How about:

dist/lib   for generated jar files and extraneous libs
dist/bin/   for scripts (generated or not)
dist/image  for actual project distributions (tar.gz or zip files)


The project distribution files are for those that actually make releases not for the 
casual user Jon Doe.

As I understand it, there will be build/lib for libraries used only during build and 
not during runtime, and dist/lib  for libraries used in both build time or run time. 
(dist/lib is perhaps what Jon meant by lib/)

Is that reasonable? Cheers, Ceki
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Stefan Bodewig

Ceki Glc [EMAIL PROTECTED] wrote:

 At 11:02 15.03.2001 +1100, Conor MacNeill wrote:

I think that there should be a recommendation that any file/dir not
under CVS control should go into the .cvsignore file.
 
 There is no need to adding any files to .cvsignore if you add files
 to CVS control individually as in
 
 cvs add x.java y.java
 
 instead of
 
 cvs add *
 
 or am I missing something? 

yes, the annoying 

? dist 

in 

cvs update -d -P

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Peter Donald

At 03:10  15/3/01 +0100, Ceki Glc wrote:
For Ant, I made a separate directory for the webpages (webpage). I had to do
this anyway since there was already an index.html file in the Ant docs
directory, although I have subsequently moved that.

As Jon pointed out earlier, I do not see the advantage for distinguishing 
between documentation and the web pages. It is quite pleasant to be able to 
browse a project web site locally on a file system without requiring a
network 
connection.

depends on whats on the web-pages. If there is a lot of fluff/volatile
material then it can be confusing. Volatile/non-relevent stuff (ie
bug-reports/ news/ patches-to-apply/ branch statuses etc) should be left
out. Then again all the projects I work on have a www directory that is
identical to docs directory ;)

build directory

Many of the Jakarta projects put the build files in the project's root
directory and use the build directory for build results, such as build
classes which will be jarred up into the distribution

So by build/ you actually mean the dist/ directory of the dirlayout.html
document. As far as I can see there is nothing wrong with that except that if 
we make a choice regardless of what it is we should stick to it, a bit like 
indentation I guess.

Gonna have to disagree. You do whats best when there is no significant
advantage of doing it otherways. Standardizing on a crap standard because
someone decrees it a standard is near lunacy.

A lot of projects use dist/, in my personal projects I use out/ while some
projects use bin/. 

Jon, explained that the build/lib is for building (compiling) and lib/ for 
runtime. I confess that I don't really understand the difference... See also 
the last paragraph of this note.

Other projects use tools/lib/* for build/lib. This is where the jars are
stored for tools that run during build process. None of the jars are
included in compiling classpath or in final distribution.

dist
=
I believe this should be a distribution "image" and it is therefore not
really appropriate to place the distribution binaries (.zip, .gz files) in
this location. For Ant, I create the distributions into a directory called
distribution. It contains the source and binary distributions, the latter
being equivalent to the dist directory.

Why are you making a distinction? What's wrong putting the distribution 
images, src, birnary, documentation or otherwise in dist/ and the javac 
generated classes under dist/classes?  

Some projects actually want to run from dist target. So the dist target
should be identical to the one that is included in binary distributions. In
theory you should be able to go

 cd dist/bin
 run.sh

dist/classes
=
I don't believe we want generally want raw classfiles in the dist directory.
Many projects put this into build/classes and place just jars in the dist
directory.

Why? What's the rationale? Moreover, in the classes directory there might be 
more classes than in the jars.

Because dist is an image of binary distribution and it is very rare that
raw class files are included in binary distribution (and if they are the
developers should be shot).

Other
==

I think that there should be a recommendation that any file/dir not under
CVS control should go into the .cvsignore file.

There is no need to adding any files to .cvsignore if you add files to CVS
control individually as in

 cvs add x.java y.java

instead of

 cvs add *

or am I missing something? 

yep - .cvsignore is for removing annoying 
? blah
messages during update

How about:

dist/lib   for generated jar files and extraneous libs
dist/bin/   for scripts (generated or not)
dist/image  for actual project distributions (tar.gz or zip files)

You don't get what is being said. The dist directory is unzipped version of
binary distribution. So that would be liking distributing Log4j-1.0.zip
that contained image/Log4j-1.0.zip inside it. That is why it is good to
make distinction and place distributions in another directory (ie
distributions).

Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Ceki Gülcü

At 01:34 16.03.2001 +1100, Peter Donald wrote:

build directory

Many of the Jakarta projects put the build files in the project's root
directory and use the build directory for build results, such as build
classes which will be jarred up into the distribution

So by build/ you actually mean the dist/ directory of the dirlayout.html
document. As far as I can see there is nothing wrong with that except that if 
we make a choice regardless of what it is we should stick to it, a bit like 
indentation I guess.

Gonna have to disagree. You do whats best when there is no significant
advantage of doing it otherways. Standardizing on a crap standard because
someone decrees it a standard is near lunacy.

Sure, no one is suggesting that we standardize on jolt/ for jar files. :-) 

A lot of projects use dist/, in my personal projects I use out/ while some
projects use bin/. 

See, these names are like colors, blue, green, or yellow... At face value, they are 
all equivalent. That's what I meant by sticking to a name. It goes without saying that 
the chosen color has to be reasonable, unlike #A26F58 or SemiHuedVelvetBlue.

Jon, explained that the build/lib is for building (compiling) and lib/ for 
runtime. I confess that I don't really understand the difference... See also 
the last paragraph of this note.

Other projects use tools/lib/* for build/lib. This is where the jars are
stored for tools that run during build process. None of the jars are
included in compiling classpath or in final distribution.

dist
=
I believe this should be a distribution "image" and it is therefore not
really appropriate to place the distribution binaries (.zip, .gz files) in
this location. For Ant, I create the distributions into a directory called
distribution. It contains the source and binary distributions, the latter
being equivalent to the dist directory.

Why are you making a distinction? What's wrong putting the distribution 
images, src, birnary, documentation or otherwise in dist/ and the javac 
generated classes under dist/classes?  

Some projects actually want to run from dist target. So the dist target
should be identical to the one that is included in binary distributions. In
theory you should be able to go

 cd dist/bin
 run.sh

Sure. 

dist/classes
=
I don't believe we want generally want raw classfiles in the dist directory.
Many projects put this into build/classes and place just jars in the dist
directory.

Why? What's the rationale? Moreover, in the classes directory there might be 
more classes than in the jars.

Because dist is an image of binary distribution and it is very rare that
raw class files are included in binary distribution (and if they are the
developers should be shot).

Forgive my ignorance but what is so wrong with putting "raw" class files in the 
distrib along jar files? Is it the wasted disk space?

How about:

dist/lib   for generated jar files and extraneous libs
dist/bin/   for scripts (generated or not)
dist/image  for actual project distributions (tar.gz or zip files)

You don't get what is being said. The dist directory is unzipped version of
binary distribution. So that would be liking distributing Log4j-1.0.zip
that contained image/Log4j-1.0.zip inside it. That is why it is good to
make distinction and place distributions in another directory (ie
distributions).

I am not aware of the assumption that the dist directory is meant the unzipped version 
of the binary distribution. Not at all. 

If the files

xdocs/manual.xml
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  

are contained in the CVS module for project X, then after compiling, generating 
javadocs, jarring, and building a distribution image, one would get:

docs/manual.html
docs/api/
docs/api/x.html
docs/api/overview.html
docs/api/index.html
docs/api/etc...
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  
xdocs/manual.xml
dist/classes/x.class
dist/lib/X.jar

dist/images/X.tar.gz
dist/images/X.zip

where X.tar.gz and X.zip contain all the above files other than themselves. The images 
can be refined to contain only source code, documentation, or binaries. Does that make 
sense? Ceki 












-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Peter Donald

At 04:17  15/3/01 +0100, Ceki Glc wrote:
A lot of projects use dist/, in my personal projects I use out/ while some
projects use bin/. 

See, these names are like colors, blue, green, or yellow... At face value,
they are all equivalent. That's what I meant by sticking to a name. It goes
without saying that the chosen color has to be reasonable, unlike #A26F58
or SemiHuedVelvetBlue.

True but we tend to have some ... err .. strong willed individuals here who
we will find difficult to move from their pet structure. You can make a
standard all you want but we have to get people to follow it ;) 

Forgive my ignorance but what is so wrong with putting "raw" class files in 
the distrib along jar files? Is it the wasted disk space?

messy classpath, wasted diskspace, incredibly slow access on certain
filesystems (ie FAT) etc. Also much more likely to break the 100 char limit
in tar files etc.

I am not aware of the assumption that the dist directory is meant the
unzipped 
version of the binary distribution. Not at all. 

well theres the rub.


If the files

xdocs/manual.xml
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  

are contained in the CVS module for project X, then after compiling,
generating javadocs, jarring, and building a distribution image, one would
get:

docs/manual.html
docs/api/
docs/api/x.html
docs/api/overview.html
docs/api/index.html
docs/api/etc...
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  
xdocs/manual.xml
dist/classes/x.class
dist/lib/X.jar

dist/images/X.tar.gz
dist/images/X.zip

Maybe in *your* model ... 

where X.tar.gz and X.zip contain all the above files other than
themselves. The images can be refined to contain only source code,
documentation, or binaries. Does that make sense? Ceki 

It's one way of doing it but it requires developer sentience whilst
building distributions - something I try to avoid at all costs ;) Besides
that model only works for certain types of projects. Some projects build
particular types of images etc. Having everything below dist/* in binary
distribution is much easier and is a common practice that I believe
originated in java.apace.org projects and migrated to jakarta/xml groups.

Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Directory layout feedback

2001-03-15 Thread Ceki Gülcü

At 02:46 16.03.2001 +1100, Peter Donald wrote:
At 04:17  15/3/01 +0100, Ceki Glc wrote:
A lot of projects use dist/, in my personal projects I use out/ while some
projects use bin/. 

See, these names are like colors, blue, green, or yellow... At face value,
they are all equivalent. That's what I meant by sticking to a name. It goes
without saying that the chosen color has to be reasonable, unlike #A26F58
or SemiHuedVelvetBlue.

True but we tend to have some ... err .. strong willed individuals here who
we will find difficult to move from their pet structure. You can make a
standard all you want but we have to get people to follow it ;) 

I hear you. 

Forgive my ignorance but what is so wrong with putting "raw" class files in 
the distrib along jar files? Is it the wasted disk space?

messy classpath, wasted diskspace, incredibly slow access on certain
filesystems (ie FAT) etc. Also much more likely to break the 100 char limit
in tar files etc.

One is free to use jar files, using the class/ dir is an option. The tar char limit is 
broken by a class file then it is likely to be broken by that file's javadoc 
equivalent as well. How serious is this tar limitation anyway?

I am not aware of the assumption that the dist directory is meant the
unzipped 
version of the binary distribution. Not at all. 

well theres the rub.


If the files

xdocs/manual.xml
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  

are contained in the CVS module for project X, then after compiling,
generating javadocs, jarring, and building a distribution image, one would
get:

docs/manual.html
docs/api/
docs/api/x.html
docs/api/overview.html
docs/api/index.html
docs/api/etc...
build/build.xml
build/build.sh
build/build.bat
build/lib/ant.jar
build/lib/xerces.jar
src/x.java  
xdocs/manual.xml
dist/classes/x.class
dist/lib/X.jar

dist/images/X.tar.gz
dist/images/X.zip

Maybe in *your* model ... 

Yes, that's the model log4j uses although I am adapting the log4j directory structure 
to match the dirlayout document and this ongoing discussion.

where X.tar.gz and X.zip contain all the above files other than
themselves. The images can be refined to contain only source code,
documentation, or binaries. Does that make sense? Ceki 

It's one way of doing it but it requires developer sentience whilst
building distributions - something I try to avoid at all costs ;) Besides
that model only works for certain types of projects. Some projects build
particular types of images etc. Having everything below dist/* in binary
distribution is much easier and is a common practice that I believe
originated in java.apace.org projects and migrated to jakarta/xml groups.


OK but I don't see any big difference between the two approaches. In one you generate 
into dist/ + copy into dist/ and the other you tar/zip a set of files specified in a 
tar/zip target.  You have to be sentient in both cases or? Ceki 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Bug

2001-03-15 Thread Jon Stevens

on 3/13/01 5:04 PM, "Toran Kanazawa" [EMAIL PROTECTED] wrote:

 iCalendar link is not working at:
 http://jakarta.apache.org/jetspeed/site/index.html
 
 I need to have information regarding: how to use iCalendar !
 Thanks.
 
 Toran Kanazawa
 Software Engineer
 Talk City Marketing Group, Inc.

iCalendar is not an official project right now and therefore doesn't really
have full support of the Jakarta Project.

The CVS is available off the CVS page on the Jakarta site.

I'm not really sure what to do with it at this point. It has one barely part
time developer only which is not really enough to call it a Jakarta project.

thanks,

-jon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: session question

2001-03-15 Thread Peter Donald

This is not the list for that question - try tomcat-users
Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]