You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Gordon Maclean <ma...@atd.ucar.edu> on 2001/02/16 18:29:14 UTC
PATCH for netscape 4.7x and sessions
As I reported on the struts-users mailing list, netscape 4.7x apparently
treats these
two URLs as distinct:
http://xxx.yyy.zzz
http://xxx.yyy.zzz:80
and does not send cookies accepted from one when sending requests to the
other.
This problem appears when testing struts-example, using struts nightly
build
of Feb 12, and Tomcat 3.2.1.
The html taglib adds the port number when creating links, whereas
ActionServlet does not add the port number when doing forwards or
redirects.
The fix that works for me is to change
org.apache.struts.utils.RequestUtil.absoluteURL
so that it does not put the port number in the URL if it is the default
80.
(I've appended the patch.)
I'm still a mystified about why I haven't seen other reports
of this problem. Unless other webservers do something similar to
my patch within request.getServerPort(), then I believe the problem
should
have shown up in other servers besides tomcat 3.2.1. ????
Here's the diff -c:
*** /tmp/RequestUtils.java Sat Feb 17 09:30:00 2001
--- RequestUtils.java Sat Feb 17 09:32:00 2001
***************
*** 121,129 ****
try {
URL url = new URL(request.getScheme(),
! request.getServerName(),
! request.getServerPort(),
! request.getContextPath() + path);
return (url.toString());
} catch (MalformedURLException e) {
return (null);
--- 121,129 ----
try {
URL url = new URL(request.getScheme(),
! request.getServerName(),
! request.getServerPort() == 80 ? -1 : request.getServerPort(),
! request.getContextPath() + path);
return (url.toString());
} catch (MalformedURLException e) {
return (null);
Gordon
Re: PROPOSAL - Testing Framework
Posted by Rob Leland <Ro...@freetocreate.org>.
On the contact info for testing could you change the
contact email address
from: Robert@freetocreate.org
to : struts-test@freetocreate.org
That way I can sort out email easier.
-Rob
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Rob Leland wrote:
> I would like to add some additional Unit tests to the struts
> framework.
> These would be tests for struts itself, not end user code.
> My thoughts are that as struts evolves and new functionality
> is added we want to verify that other functionality is not
> broken, as code is changed and refactored.
>
I think a unit testing framework would be a wonderful addition to Struts,
and would like to encourage this effort. As an implementation thought, I
note that Ant already has an optional task to support junit, and would like
to see unit tests for Struts running in some sort of a similar framework
(including contributing a j2eeunit to Ant if that would be useful).
>
> I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
> J2EEUnit (J2eeunit.sourceforge.org). I am going to force
> myself to do this in an upcoming project at work, and believe it
> makes sense to do it in struts also.
>
> I am targeting the 1.1 release time period. If Unit
> testing is approved, some small set of tests may make it into
> the struts 1.0 release, again assuming people here vote for its
> inclusion.
>
> My initial thoughts for providing testing is to start with the
> private methods of struts starting with the
> struts.action package,
> then later develop tests for the public methods of struts.action.
> I didn't want to start another package until I finished the majority
> of the private methods, only because I would need to debug
> my unit tests, and only by developing tests for some of the private
> methods the public could I do this.
>
Doing org.apache.struts.action first makes sense, because it is pretty
central to everything that is Struts, and changes/bugs/regressions/problems
here would have the most impact on users.
>
> Then other packages would follow :
> struts.upload,
> struts.util,
> struts.digester,
> struts.actions,
> struts.taglib.X
>
Others who wanted to start writing tests could, of course, start on other
packages in the order that they preferred.
>
> In about that order, only because that would be a usefull order for me
> in the project I am working on. Infact, I only have plans to do
> struts.upload, and
> struts.util, and doubt I would have the time to produce tests for the
> other packages.
>
>
> Thoughts ?
>
I'll add a section to the 1.1 TODO list related to this -- I think it is a
great idea.
>
> -Rob
Craig
Re: PROPOSAL - Testing Framework
Posted by Ted Husted <ne...@husted.com>.
Vincent,
Some of have been talking about create a generalized component library
for Jakarta. One of the proposed components is a testing suite or
framework. The proposal is in early stages of development, details are
currently at < http://husted.com/about/jakarta/library.html >, in case
you are interested.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
Ok Here are some pointers to get started :
- In order to be able to automatically start the tests using Ant, you need a
custom ant task. Ant is not able to start a task in parallel for the moment
and then join it with the parent thread on some conditions. This is why I
have developped an Ant task (it's only a few lines) that does this. I am
going to propose it to the Ant mailing list and try to include it in their
optional tasks. Otherwise, it will be bundled with J2EEUnit 0.7. You can
check it at
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/j2eeunit/src/ant/org/apache/to
ols/ant/taskdefs/optional/j2eeunit/J2EEUnitStartServerTask.java?rev=1.1&cont
ent-type=text/x-cvsweb-markup&cvsroot=j2eeunit (that's on the CVS web-based
interface from Sourceforge : http://sourceforge.net/projects/j2eeunit)
- Integrate tasks in the build.xml to start the servlet engine, run the
tests and stop the tests (As some server do not provide a way to shutdown
their server, I'll include a watchdog deamon like feature in my custom Ant
task to kill the server). I have this in the J2EEUnit build.xml script :
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/j2eeunit/src/ant/org/apache/to
ols/ant/taskdefs/optional/j2eeunit/J2EEUnitStartServerTask.java?rev=1.1&cont
ent-type=text/x-cvsweb-markup&cvsroot=j2eeunit
- Do you have any directory structure yet where you'll put the tests ?
- Naming rules for the tests ? (like TestXXX, where XXX is the name of the
class under test)
- Do you put the suite of tests in a separate directory from the main
sources ? But under the same package names (so that we can test protected
methods) ?
- Do you plan to have 2 build.xml, one for the main struts build and another
for the tests or just one (I tend to prefer one and run the tests all the
time) ?
- Do you have a tool (it can be a set of shell scripts and some Ant script)
to do continous builds and run the tests at the same time ? Which sends an
email when there is a build failure ? Actually I am going to write such a
script for J2EEUnit and I can contribute it if you like it. Do you have a
machine where to run this script in a crontab mode ? The answer to all these
are probably yes as you are already doing nighlty builds. The thing left to
do is then to integrate running the tests as part of the nighlty builds,
don't you think so ?
- I guess a page on the Struts web site named something like "Struts Unit
Testing Strategy" and containing the above mentionned issues and answers
could be a good idea ?
What do you think ?
Thanks.
Vincent Massol.
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Vincent Massol wrote:
> +1
>
> Great idea ! :)
>
> I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm
> committed to help you implement this suite of tests.
That is great news, Vincent!
> I have already been
> implementing such a suite of tests for J2EEUnit itself and thus I know very
> well how to integrate it with Ant (actually I already have the build.xml
> that starts J2EEUnit tests). I have successfully created a build.xml file
> that run the tests on several servlet engines : Tomcat 3.1.1, Tomcat 3.2.1,
> Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ... That may be a
> good idea for Struts to run its unit tests on several Servlet engines. It is
> very easy to do ! I also have an Ant task that let you start any servlet
> engine in another thread, waits until it is finished starting and run the
> unit tests (it is still in CVS for the moment but I'll release a new 0.7
> version this coming week end).
>
I agree ... we should set up testing on as many platforms as is feasible, to
ensure that hard fought efforts for cross-platform compatibility come to
fruition.
>
> Let me know where I can help. Also if you have any trouble to use J2EEUnit
> on any subject feel free to contact me and I'll help.
> Thanks.
>
> Note: You should use the 0.7 version as much as possible as in the previous
> version it was not possible to test any method that wrote in the Servlet
> output stream. It now works fine in version 0.7 (in CVS).
>
> Vincent Massol.
>
Craig McClanahan
Re: Request go ahead for structural changes in CVS
Posted by Rob Leland <Ro...@freetocreate.org>.
Vincent Massol wrote:
> Yes, I noticed but the test webapp was left as is and I need to work on
> J2EEUnit integration.
It is ok to delete 'test'. I left it there until I was sure I had
moved every thing correctly. Since exercise-taglib builds ok,
the 'test' directory can now be used for unit tests.
>
> Vincent.
-Rob
Re: Request go ahead for structural changes in CVS
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Robert Leland" <Ro...@free2create.org>
To: <st...@jakarta.apache.org>
Sent: Sunday, March 18, 2001 3:23 PM
Subject: Re: Request go ahead for structural changes in CVS
>
>
> Vincent Massol wrote:
> >
> > I'd like to have the go ahead for making the changes to the struts
directory
>
> I think it is OK to commit those changes as long as they are tested
> and the distribution builds.
>
> > Namely, I'd like to commit the following changes that I have locally on
my
> > computer (step 1) :
> > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > - Move jakarta-struts/src/conf to jakarta-struts/conf
>
> I am sure this is ok.
>
> > - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> > directory
>
> There seems to be some disagreement on this. In an email that Craig sent
> Thursday, I believe he again stated that the jakarta-struts/build
directory
> was to only exist in the distribution that is created but not in CVS. I
> created the jakarta-struts/build directory in CVS about 2 weeks ago.
> So perhaps we should delete it ?? Perhaps the build scripts
> could stay in jakarta-struts/, what is the reason for moving them ?
>
because there are about 20 files in total. I could limit it to about 10
files but then it is very convenient to have one batch per target on
windows, so that you can just click on the batch file to run the target and
you don't have to go to the ugly DOS ... :) So the goal is just to gather
the files together in a single location so that they are not mixed with
other files.
>
> > - Modified build.xml and build-webapps to support the above changes
> >
> > This will leave all the build output as it was before (except the test
> > webapp which is no longer generated for the moment till I finish the
> > integration with J2EEUnit).
>
> Recall that the test webapp is now renamed to exercise-taglib
>
Yes, I noticed but the test webapp was left as is and I need to work on
J2EEUnit integration.
> > Vincent.
>
> -Rob
>
Vincent.
Re: Request go ahead for structural changes in CVS
Posted by Robert Leland <Ro...@free2create.org>.
Vincent Massol wrote:
>
> I'd like to have the go ahead for making the changes to the struts directory
I think it is OK to commit those changes as long as they are tested
and the distribution builds.
> Namely, I'd like to commit the following changes that I have locally on my
> computer (step 1) :
> - Move jakarta-struts/src/doc to jakarta-struts/doc
> - Move jakarta-struts/src/conf to jakarta-struts/conf
I am sure this is ok.
> - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> directory
There seems to be some disagreement on this. In an email that Craig sent
Thursday, I believe he again stated that the jakarta-struts/build directory
was to only exist in the distribution that is created but not in CVS. I
created the jakarta-struts/build directory in CVS about 2 weeks ago.
So perhaps we should delete it ?? Perhaps the build scripts
could stay in jakarta-struts/, what is the reason for moving them ?
> - Modified build.xml and build-webapps to support the above changes
>
> This will leave all the build output as it was before (except the test
> webapp which is no longer generated for the moment till I finish the
> integration with J2EEUnit).
Recall that the test webapp is now renamed to exercise-taglib
> Vincent.
-Rob
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 20 Mar 2001, Incze Lajos wrote:
> > If we impose on the developer only that he has the right "ant" or
> > "ant.bat" script available in his or her PATH, do we care anything about
> > Ant's internal organization? It seems to me that the Ant environment
> > should take care of finding its own pieces.
> >
> > Craig
> >
>
> Everything used to work seemlessly until somebody comes up
> with some dependent ant tasks and supposes a "normal" ant
> dist environment. This can be avoided but there is a pretty
> strong coherence in the apache group and sometimes these
> dependencies remain in the scripts. E.g. the current build
> script contains the servlet.jar at it's usual jakarta project
> place and if you don't have this jar at that place, the build
> will fail (as the target compile.library does not include
> the system classpath. (I routinely issued - almost every day -
> an 'ant clean; ant dist' command with my preset classpath, and
> experianced that the clean build fail. Ok, I could override
> the servlet.jar with ant -D) Build.sh contains the usual _HOME
> dirs and places things at their usual relative places.
>
> So, I wholehartedly support the bare ant command, just wanted
> to raise the exclam mark that in general these properties can't
> suppose the "normal" HOME dir layout. Users can gather their
> common parsers, jars etc. (I used to fail - now have 15 xalan.jars
> 23 xerces.jars, 17 parser.jars, etc.) We should have classpath
> properties independent form .home properties, etc. incze
>
It seems to me this is what "build.properties" will take care of for
you. For example, a "build.properties" for Struts would include my local
definitions for "catalina.home", "servlet.jar", "tomcat.home", and
"xerces.home". If my directory structure happens to match the default
value for or more of these, I could omit them (or, more likely leave my
own copy in place, in case the default changed later).
The only restriction would be where the Struts build.xml looked for
build.properties. My proposal would be that it should be in the same
directory that build.xml is (but, as mentioned earlier, *not* checked in
to CVS). That way, you can have different sets of build properties for
your different projects without having to continually modify environment
variables.
Essentially, "build.properties" replaces having to set all the environment
variables required by the current "build.sh" and "build.bat" scripts, but
gives you the same flexibility to use whichever components *you* want to,
without impacting which ones *I* am using (and vice versa). Am I missing
something?
Craig
Re: Request go ahead for structural changes in CVS
Posted by Incze Lajos <in...@mail.matav.hu>.
> If we impose on the developer only that he has the right "ant" or
> "ant.bat" script available in his or her PATH, do we care anything about
> Ant's internal organization? It seems to me that the Ant environment
> should take care of finding its own pieces.
>
> Craig
>
Everything used to work seemlessly until somebody comes up
with some dependent ant tasks and supposes a "normal" ant
dist environment. This can be avoided but there is a pretty
strong coherence in the apache group and sometimes these
dependencies remain in the scripts. E.g. the current build
script contains the servlet.jar at it's usual jakarta project
place and if you don't have this jar at that place, the build
will fail (as the target compile.library does not include
the system classpath. (I routinely issued - almost every day -
an 'ant clean; ant dist' command with my preset classpath, and
experianced that the clean build fail. Ok, I could override
the servlet.jar with ant -D) Build.sh contains the usual _HOME
dirs and places things at their usual relative places.
So, I wholehartedly support the bare ant command, just wanted
to raise the exclam mark that in general these properties can't
suppose the "normal" HOME dir layout. Users can gather their
common parsers, jars etc. (I used to fail - now have 15 xalan.jars
23 xerces.jars, 17 parser.jars, etc.) We should have classpath
properties independent form .home properties, etc. incze
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 19 Mar 2001, Incze Lajos wrote:
> On Mon, Mar 19, 2001 at 08:16:46PM +0100, Incze Lajos wrote:
>
> > I can cause some difficulties to ant's RPM-distribution-linux-users as it's
> > directory scheme follows the some Linux file system standards, not the
> > original ant distribution. (On the other hand it can be repaired with some
> > symlinks. So, at least a warning would be nice. E.g. the ant binary structure
> > is this one:
> >
>
> Terrible copy/paste (1st line is missing):
> /usr/bin/ant
> > /usr/doc/ant-1.2
> > /usr/doc/ant-1.2/LICENSE
> > /usr/doc/ant-1.2/README
> > /usr/doc/ant-1.2/TODO
> > /usr/doc/ant-1.2/WHATSNEW
> > /usr/share/ant/bin/antRun
> > /usr/share/java/ant.jar
> > /usr/share/java/jaxp.jar
> > /usr/share/java/optional.jar
> > /usr/share/java/parser.jar)
> > incze
>
If we impose on the developer only that he has the right "ant" or
"ant.bat" script available in his or her PATH, do we care anything about
Ant's internal organization? It seems to me that the Ant environment
should take care of finding its own pieces.
Craig
Re: Request go ahead for structural changes in CVS
Posted by Incze Lajos <in...@mail.matav.hu>.
On Mon, Mar 19, 2001 at 08:16:46PM +0100, Incze Lajos wrote:
> I can cause some difficulties to ant's RPM-distribution-linux-users as it's
> directory scheme follows the some Linux file system standards, not the
> original ant distribution. (On the other hand it can be repaired with some
> symlinks. So, at least a warning would be nice. E.g. the ant binary structure
> is this one:
>
Terrible copy/paste (1st line is missing):
/usr/bin/ant
> /usr/doc/ant-1.2
> /usr/doc/ant-1.2/LICENSE
> /usr/doc/ant-1.2/README
> /usr/doc/ant-1.2/TODO
> /usr/doc/ant-1.2/WHATSNEW
> /usr/share/ant/bin/antRun
> /usr/share/java/ant.jar
> /usr/share/java/jaxp.jar
> /usr/share/java/optional.jar
> /usr/share/java/parser.jar)
> incze
Re: Request go ahead for structural changes in CVS
Posted by Incze Lajos <in...@mail.matav.hu>.
On Sun, Mar 18, 2001 at 02:30:55PM -0800, Craig R. McClanahan wrote:
>
>
> On Sun, 18 Mar 2001, Vincent Massol wrote:
>
> > Here follows the status (inline in the mail below). Please tell me if I have
> > made any blunder and I'll correct it. Also, I have made some changes that
> > are against standards/issues that have been approved/agreed upon (like
> > formatting of Ant build files, ...), please tell me and I'll correct it.
> > Thanks.
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <vm...@octo.fr>
> > To: <st...@jakarta.apache.org>
> > Sent: Sunday, March 18, 2001 1:11 PM
> > Subject: Request go ahead for structural changes in CVS
> >
> >
> > > I'd like to have the go ahead for making the changes to the struts
> > directory
> > > structure, as mentionned in the thread "[PROPOSAL] Struts Source Directory
> > > Structure".
> > >
> > > Namely, I'd like to commit the following changes that I have locally on my
> > > computer (step 1) :
> > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> >
> > done
> >
> Fine.
>
> > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> >
> > done
> >
> Also fine.
>
> > > - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> > > directory
> >
> > waiting for approval
> >
>
> I'm fine with the organizational change, and I modified the output of all
> the build processes to go to "target" instead of "build" now.
>
> One thing I've been toying with is how we can get out of having
> "build.sh" and "build.bat" scripts completely, and just use the
> "ant" script (from $ANT_HOME/bin) directly to run our builds. In order to
> set local environment variables, how about this:
>
> * If there is a "build.properties" file in the directory you are
> running the build from (this will be "build" after the scripts
> are moved), load it at the top of build.xml.
> Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> your PATH in order to execute the builds by typing things like:
>
> ant compile.javadoc
>
> instead of saying
>
> ./build.sh compile.javadoc
>
> What do you think?
I can cause some difficulties to ant's RPM-distribution-linux-users as it's
directory scheme follows the some Linux file system standards, not the
original ant distribution. (On the other hand it can be repaired with some
symlinks. So, at least a warning would be nice. E.g. the ant binary structure
is this one:
/usr/doc/ant-1.2
/usr/doc/ant-1.2/LICENSE
/usr/doc/ant-1.2/README
/usr/doc/ant-1.2/TODO
/usr/doc/ant-1.2/WHATSNEW
/usr/share/ant/bin/antRun
/usr/share/java/ant.jar
/usr/share/java/jaxp.jar
/usr/share/java/optional.jar
/usr/share/java/parser.jar)
incze
Re: Request go ahead for structural changes in CVS
Posted by Martin Cooper <ma...@tumbleweed.com>.
At 08:58 AM 3/19/01, Craig R. McClanahan wrote:
>On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <cr...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Sunday, March 18, 2001 11:30 PM
> > Subject: Re: Request go ahead for structural changes in CVS
> >
> >
> > >
> > >
> > > On Sun, 18 Mar 2001, Vincent Massol wrote:
> > >
> > > > Here follows the status (inline in the mail below). Please tell me if I
> > have
> > > > made any blunder and I'll correct it. Also, I have made some changes
> > that
> > > > are against standards/issues that have been approved/agreed upon (like
> > > > formatting of Ant build files, ...), please tell me and I'll
> correct it.
> > > > Thanks.
> > > >
> > > > ----- Original Message -----
> > > > From: "Vincent Massol" <vm...@octo.fr>
> > > > To: <st...@jakarta.apache.org>
> > > > Sent: Sunday, March 18, 2001 1:11 PM
> > > > Subject: Request go ahead for structural changes in CVS
> > > >
> > > >
> > > > > I'd like to have the go ahead for making the changes to the struts
> > > > directory
> > > > > structure, as mentionned in the thread "[PROPOSAL] Struts Source
> > Directory
> > > > > Structure".
> > > > >
> > > > > Namely, I'd like to commit the following changes that I have locally
> > on my
> > > > > computer (step 1) :
> > > > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > > >
> > > > done
> > > >
> > > Fine.
> > >
> > > > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> > > >
> > > > done
> > > >
> > > Also fine.
> > >
> > > > > - Move build.xml, build.bat and build.sh to the new
> > jakarta-struts/build
> > > > > directory
> > > >
> > > > waiting for approval
> > > >
> > >
> > > I'm fine with the organizational change, and I modified the output of all
> > > the build processes to go to "target" instead of "build" now.
> > >
> > > One thing I've been toying with is how we can get out of having
> > > "build.sh" and "build.bat" scripts completely, and just use the
> > > "ant" script (from $ANT_HOME/bin) directly to run our builds. In
> order to
> > > set local environment variables, how about this:
> > >
> >
> > Yes, it would be nice to get rid as much as possible of batch files and
> > shell scripts.
> >
> > > * If there is a "build.properties" file in the directory you are
> > > running the build from (this will be "build" after the scripts
> > > are moved), load it at the top of build.xml.
> > >
> >
> > Is it possible to specify the java.class.path property in this file ? (I'd
> > like to have a different CLASSPATH for each project)
> >
>
>It ought to work (I've never tried it), but Ant 1.2 and 1.3 have very nice
>capabilities to build classpaths up dynamically, so that you can use
>different classpaths for different compilations if you need to.
I think the Ant approach would be preferable. That way, the
build.properties file just defines the locations of various things, and the
build file takes care of building the appropriate classpath for each target.
>On the more general point, however, I'd like to get to the point where we
>do not depend on anything in the developer's original CLASSPATH.
Absolutely. I see reliance on the user's classpath as one of the most
frequent causes of build problems.
> > > * The "build.properties" file would be unique to each developer's
> > > environment (mine will even be different on Linux and Windows :-),
> > > so it is *not* checked in to CVS.
> > >
> >
> > Fine, but we should provide a sample one to help know what to put
> inside. It
> > means we should also use lots of available tasks in the build.xml to verify
> > that all needed properties related to directories are set to correct paths.
> >
>
>Absolutely. IMHO the best place to document this is near the top of the
>build.xml file itself (which is where this file will be read if it
>exists). I've tried to be pretty copious in documenting what external
>properties that build-webapps.xml and build-webapp.xml depend on, for
>example. We'll also need to describe the (simple) syntax requirements.
>
>If we added a pointer to this in the README file, do you think that would
>be sufficient.
>
> > > * To avoid "?" messages from CVS, add "build.properties" to the
> > > appropriate ".cvsignore" file.
> > >
> > > Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> > > your PATH in order to execute the builds by typing things like:
> > >
> > > ant compile.javadoc
> > >
> > > instead of saying
> > >
> > > ./build.sh compile.javadoc
> > >
> > > What do you think?
> >
> > fine. I'll try it on my computer. Although I hate going to DOS ... :) I
> > usually prefer having several batch files, even with a single line in
> it ...
> > This is actually what I have done for running the Struts build : one
> > directory above jakarta-struts, I have put the needed libraries and some
> > batch files ... :) I guess I'll have to change my way of doing things
> ... :)
> >
>
>I also look forward to trying out Antidote (GUI that is being developed
>inside the Ant project) and an Ant mode for emacs, so I can do these kinds
>of things directly.
>
> > >
> > > > > - Modified build.xml and build-webapps to support the above changes
> > > > >
> > > >
> > > > done
> > > >
> > > OK
> > >
> > > > > This will leave all the build output as it was before (except the
> test
> > > > > webapp which is no longer generated for the moment till I finish the
> > > > > integration with J2EEUnit).
> > > > >
> > > > > In a second step, I will add :
> > > > > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > > > > - new build-tests.xml and associated batch files in
> > jakarta-struts/build
> > > > > - new servlet engine configuration files in jakarta-struts/conf/test
> > to
> > > > > support automated J2EEUnit unit testing with several servlet engines
> > > > > - new environment variables to support testing with several servlet
> > > > engines
> > > > > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> > > > >
> > >
> > > Can we make a practice of defining the corresponding properties in a
> > > build.properties file, as in the discussion above?
> > >
> > > tomcat.home=xxxx
> > > catalina.home=yyyy
> > > resin.home=zzzz
> > >
> >
> > Yes.
> >
> > > > > Thanks for telling me quickly if I should go ahead or not (at least
> > for
> > > > step
> > > > > 1).
> > > > >
> > > > > Also I have noticed that when editing the build*.xml files in my
> > UltraEdit
> > > > > all spaces and tabs are disorganized and make the text difficult to
> > read.
> > > > I
> > > > > think we should standardize on a tab value of 4 (for example) and in
> > our
> > > > > editors replace tabs by spaces.
> > > > >
> > > >
> > > > done. Tell me if I have done something wrong
> > > >
> > >
> > > Looks good so far.
> > >
> > thanks.
> >
> > > > > Thanks.
> > > > > Vincent.
> > > >
> > > > Vincent.
> > > >
> > > >
> > >
> > > Craig
> > >
> >
> > Vincent
> >
> >
>
>Craig
--
Martin Cooper
Tumbleweed Communications
**** from 0.5 to 1.0, how?? ****
Posted by Siping Liu <sl...@egenera.com>.
Hi,
I've been using 0.5 and moving to 1.0 is more difficult than I thought.
Is there any instructions to help on this task? I changed action.xml to
struts-config.xml
and updated the tags. Get my first page shown but it never gets to the next
(netscape gives me "document contained no data" error).
Thanks,
S Liu
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 19 Mar 2001, Vincent Massol wrote:
> [snip]
> I think it would be fine but we also need to provide a
> build.properties.sample file that gives an example (the same way it is done
> in the jakarta-ant sources;they provide a ant.properties.sample file)
+1
Craig
Re: Request go ahead for structural changes in CVS
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Monday, March 19, 2001 5:58 PM
Subject: Re: Request go ahead for structural changes in CVS
>
>
> On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <cr...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Sunday, March 18, 2001 11:30 PM
> > Subject: Re: Request go ahead for structural changes in CVS
> >
> >
> > >
> > >
> > > On Sun, 18 Mar 2001, Vincent Massol wrote:
> > >
> > > > Here follows the status (inline in the mail below). Please tell me
if I
> > have
> > > > made any blunder and I'll correct it. Also, I have made some changes
> > that
> > > > are against standards/issues that have been approved/agreed upon
(like
> > > > formatting of Ant build files, ...), please tell me and I'll correct
it.
> > > > Thanks.
> > > >
> > > > ----- Original Message -----
> > > > From: "Vincent Massol" <vm...@octo.fr>
> > > > To: <st...@jakarta.apache.org>
> > > > Sent: Sunday, March 18, 2001 1:11 PM
> > > > Subject: Request go ahead for structural changes in CVS
> > > >
> > > >
> > > > > I'd like to have the go ahead for making the changes to the struts
> > > > directory
> > > > > structure, as mentionned in the thread "[PROPOSAL] Struts Source
> > Directory
> > > > > Structure".
> > > > >
> > > > > Namely, I'd like to commit the following changes that I have
locally
> > on my
> > > > > computer (step 1) :
> > > > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > > >
> > > > done
> > > >
> > > Fine.
> > >
> > > > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> > > >
> > > > done
> > > >
> > > Also fine.
> > >
> > > > > - Move build.xml, build.bat and build.sh to the new
> > jakarta-struts/build
> > > > > directory
> > > >
> > > > waiting for approval
> > > >
> > >
> > > I'm fine with the organizational change, and I modified the output of
all
> > > the build processes to go to "target" instead of "build" now.
> > >
> > > One thing I've been toying with is how we can get out of having
> > > "build.sh" and "build.bat" scripts completely, and just use the
> > > "ant" script (from $ANT_HOME/bin) directly to run our builds. In
order to
> > > set local environment variables, how about this:
> > >
> >
> > Yes, it would be nice to get rid as much as possible of batch files and
> > shell scripts.
> >
> > > * If there is a "build.properties" file in the directory you are
> > > running the build from (this will be "build" after the scripts
> > > are moved), load it at the top of build.xml.
> > >
> >
> > Is it possible to specify the java.class.path property in this file ?
(I'd
> > like to have a different CLASSPATH for each project)
> >
>
> It ought to work (I've never tried it), but Ant 1.2 and 1.3 have very nice
> capabilities to build classpaths up dynamically, so that you can use
> different classpaths for different compilations if you need to.
>
> On the more general point, however, I'd like to get to the point where we
> do not depend on anything in the developer's original CLASSPATH.
>
I completely agree. I have spent the day today changing the way I was using
Ant for J2EEUnit itself. Your suggestion works very well so far :
- I use a build.properties file
- I have installed Ant and have put all jars needed for it's core and
optional tasks in %ANT_HOME%/lib
- I have properties for the other jar files defined in my build.properties
file
> > > * The "build.properties" file would be unique to each developer's
> > > environment (mine will even be different on Linux and Windows :-),
> > > so it is *not* checked in to CVS.
> > >
> >
> > Fine, but we should provide a sample one to help know what to put
inside. It
> > means we should also use lots of available tasks in the build.xml to
verify
> > that all needed properties related to directories are set to correct
paths.
> >
>
> Absolutely. IMHO the best place to document this is near the top of the
> build.xml file itself (which is where this file will be read if it
> exists). I've tried to be pretty copious in documenting what external
> properties that build-webapps.xml and build-webapp.xml depend on, for
> example. We'll also need to describe the (simple) syntax requirements.
>
> If we added a pointer to this in the README file, do you think that would
> be sufficient.
>
I think it would be fine but we also need to provide a
build.properties.sample file that gives an example (the same way it is done
in the jakarta-ant sources;they provide a ant.properties.sample file)
> > > * To avoid "?" messages from CVS, add "build.properties" to the
> > > appropriate ".cvsignore" file.
> > >
> > > Note that the dependency on Ant would be that you have $ANT_HOME/bin
on
> > > your PATH in order to execute the builds by typing things like:
> > >
> > > ant compile.javadoc
> > >
> > > instead of saying
> > >
> > > ./build.sh compile.javadoc
> > >
> > > What do you think?
> >
> > fine. I'll try it on my computer. Although I hate going to DOS ... :) I
> > usually prefer having several batch files, even with a single line in it
...
> > This is actually what I have done for running the Struts build : one
> > directory above jakarta-struts, I have put the needed libraries and some
> > batch files ... :) I guess I'll have to change my way of doing things
... :)
> >
>
> I also look forward to trying out Antidote (GUI that is being developed
> inside the Ant project) and an Ant mode for emacs, so I can do these kinds
> of things directly.
>
> > >
> > > > > - Modified build.xml and build-webapps to support the above
changes
> > > > >
> > > >
> > > > done
> > > >
> > > OK
> > >
> > > > > This will leave all the build output as it was before (except the
test
> > > > > webapp which is no longer generated for the moment till I finish
the
> > > > > integration with J2EEUnit).
> > > > >
> > > > > In a second step, I will add :
> > > > > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > > > > - new build-tests.xml and associated batch files in
> > jakarta-struts/build
> > > > > - new servlet engine configuration files in
jakarta-struts/conf/test
> > to
> > > > > support automated J2EEUnit unit testing with several servlet
engines
> > > > > - new environment variables to support testing with several
servlet
> > > > engines
> > > > > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> > > > >
> > >
> > > Can we make a practice of defining the corresponding properties in a
> > > build.properties file, as in the discussion above?
> > >
> > > tomcat.home=xxxx
> > > catalina.home=yyyy
> > > resin.home=zzzz
> > >
> >
> > Yes.
> >
> > > > > Thanks for telling me quickly if I should go ahead or not (at
least
> > for
> > > > step
> > > > > 1).
> > > > >
> > > > > Also I have noticed that when editing the build*.xml files in my
> > UltraEdit
> > > > > all spaces and tabs are disorganized and make the text difficult
to
> > read.
> > > > I
> > > > > think we should standardize on a tab value of 4 (for example) and
in
> > our
> > > > > editors replace tabs by spaces.
> > > > >
> > > >
> > > > done. Tell me if I have done something wrong
> > > >
> > >
> > > Looks good so far.
> > >
> > thanks.
> >
> > > > > Thanks.
> > > > > Vincent.
> > > >
> > > > Vincent.
> > > >
> > > >
> > >
> > > Craig
> > >
> >
> > Vincent
> >
> >
>
> Craig
>
Vincent
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Sunday, March 18, 2001 11:30 PM
> Subject: Re: Request go ahead for structural changes in CVS
>
>
> >
> >
> > On Sun, 18 Mar 2001, Vincent Massol wrote:
> >
> > > Here follows the status (inline in the mail below). Please tell me if I
> have
> > > made any blunder and I'll correct it. Also, I have made some changes
> that
> > > are against standards/issues that have been approved/agreed upon (like
> > > formatting of Ant build files, ...), please tell me and I'll correct it.
> > > Thanks.
> > >
> > > ----- Original Message -----
> > > From: "Vincent Massol" <vm...@octo.fr>
> > > To: <st...@jakarta.apache.org>
> > > Sent: Sunday, March 18, 2001 1:11 PM
> > > Subject: Request go ahead for structural changes in CVS
> > >
> > >
> > > > I'd like to have the go ahead for making the changes to the struts
> > > directory
> > > > structure, as mentionned in the thread "[PROPOSAL] Struts Source
> Directory
> > > > Structure".
> > > >
> > > > Namely, I'd like to commit the following changes that I have locally
> on my
> > > > computer (step 1) :
> > > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > >
> > > done
> > >
> > Fine.
> >
> > > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> > >
> > > done
> > >
> > Also fine.
> >
> > > > - Move build.xml, build.bat and build.sh to the new
> jakarta-struts/build
> > > > directory
> > >
> > > waiting for approval
> > >
> >
> > I'm fine with the organizational change, and I modified the output of all
> > the build processes to go to "target" instead of "build" now.
> >
> > One thing I've been toying with is how we can get out of having
> > "build.sh" and "build.bat" scripts completely, and just use the
> > "ant" script (from $ANT_HOME/bin) directly to run our builds. In order to
> > set local environment variables, how about this:
> >
>
> Yes, it would be nice to get rid as much as possible of batch files and
> shell scripts.
>
> > * If there is a "build.properties" file in the directory you are
> > running the build from (this will be "build" after the scripts
> > are moved), load it at the top of build.xml.
> >
>
> Is it possible to specify the java.class.path property in this file ? (I'd
> like to have a different CLASSPATH for each project)
>
It ought to work (I've never tried it), but Ant 1.2 and 1.3 have very nice
capabilities to build classpaths up dynamically, so that you can use
different classpaths for different compilations if you need to.
On the more general point, however, I'd like to get to the point where we
do not depend on anything in the developer's original CLASSPATH.
> > * The "build.properties" file would be unique to each developer's
> > environment (mine will even be different on Linux and Windows :-),
> > so it is *not* checked in to CVS.
> >
>
> Fine, but we should provide a sample one to help know what to put inside. It
> means we should also use lots of available tasks in the build.xml to verify
> that all needed properties related to directories are set to correct paths.
>
Absolutely. IMHO the best place to document this is near the top of the
build.xml file itself (which is where this file will be read if it
exists). I've tried to be pretty copious in documenting what external
properties that build-webapps.xml and build-webapp.xml depend on, for
example. We'll also need to describe the (simple) syntax requirements.
If we added a pointer to this in the README file, do you think that would
be sufficient.
> > * To avoid "?" messages from CVS, add "build.properties" to the
> > appropriate ".cvsignore" file.
> >
> > Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> > your PATH in order to execute the builds by typing things like:
> >
> > ant compile.javadoc
> >
> > instead of saying
> >
> > ./build.sh compile.javadoc
> >
> > What do you think?
>
> fine. I'll try it on my computer. Although I hate going to DOS ... :) I
> usually prefer having several batch files, even with a single line in it ...
> This is actually what I have done for running the Struts build : one
> directory above jakarta-struts, I have put the needed libraries and some
> batch files ... :) I guess I'll have to change my way of doing things ... :)
>
I also look forward to trying out Antidote (GUI that is being developed
inside the Ant project) and an Ant mode for emacs, so I can do these kinds
of things directly.
> >
> > > > - Modified build.xml and build-webapps to support the above changes
> > > >
> > >
> > > done
> > >
> > OK
> >
> > > > This will leave all the build output as it was before (except the test
> > > > webapp which is no longer generated for the moment till I finish the
> > > > integration with J2EEUnit).
> > > >
> > > > In a second step, I will add :
> > > > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > > > - new build-tests.xml and associated batch files in
> jakarta-struts/build
> > > > - new servlet engine configuration files in jakarta-struts/conf/test
> to
> > > > support automated J2EEUnit unit testing with several servlet engines
> > > > - new environment variables to support testing with several servlet
> > > engines
> > > > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> > > >
> >
> > Can we make a practice of defining the corresponding properties in a
> > build.properties file, as in the discussion above?
> >
> > tomcat.home=xxxx
> > catalina.home=yyyy
> > resin.home=zzzz
> >
>
> Yes.
>
> > > > Thanks for telling me quickly if I should go ahead or not (at least
> for
> > > step
> > > > 1).
> > > >
> > > > Also I have noticed that when editing the build*.xml files in my
> UltraEdit
> > > > all spaces and tabs are disorganized and make the text difficult to
> read.
> > > I
> > > > think we should standardize on a tab value of 4 (for example) and in
> our
> > > > editors replace tabs by spaces.
> > > >
> > >
> > > done. Tell me if I have done something wrong
> > >
> >
> > Looks good so far.
> >
> thanks.
>
> > > > Thanks.
> > > > Vincent.
> > >
> > > Vincent.
> > >
> > >
> >
> > Craig
> >
>
> Vincent
>
>
Craig
RE: Request go ahead for structural changes in CVS
Posted by Michael Hackett <mh...@pictorius.com>.
> From: Vincent Massol <vm...@octo.fr>
>
> From: "Craig R. McClanahan" <cr...@apache.org>
> > * The "build.properties" file would be unique to each developer's
> > environment (mine will even be different on Linux and Windows :-),
> > so it is *not* checked in to CVS.
>
> Fine, but we should provide a sample one to help know what to
> put inside.
I was just going to suggest the same thing. :-) If it's workable, that
sounds better than using the .sh/.bat files.
--
Michael Hackett
Developer, Pictorius Inc.
Re: Request go ahead for structural changes in CVS
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Sunday, March 18, 2001 11:30 PM
Subject: Re: Request go ahead for structural changes in CVS
>
>
> On Sun, 18 Mar 2001, Vincent Massol wrote:
>
> > Here follows the status (inline in the mail below). Please tell me if I
have
> > made any blunder and I'll correct it. Also, I have made some changes
that
> > are against standards/issues that have been approved/agreed upon (like
> > formatting of Ant build files, ...), please tell me and I'll correct it.
> > Thanks.
> >
> > ----- Original Message -----
> > From: "Vincent Massol" <vm...@octo.fr>
> > To: <st...@jakarta.apache.org>
> > Sent: Sunday, March 18, 2001 1:11 PM
> > Subject: Request go ahead for structural changes in CVS
> >
> >
> > > I'd like to have the go ahead for making the changes to the struts
> > directory
> > > structure, as mentionned in the thread "[PROPOSAL] Struts Source
Directory
> > > Structure".
> > >
> > > Namely, I'd like to commit the following changes that I have locally
on my
> > > computer (step 1) :
> > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> >
> > done
> >
> Fine.
>
> > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> >
> > done
> >
> Also fine.
>
> > > - Move build.xml, build.bat and build.sh to the new
jakarta-struts/build
> > > directory
> >
> > waiting for approval
> >
>
> I'm fine with the organizational change, and I modified the output of all
> the build processes to go to "target" instead of "build" now.
>
> One thing I've been toying with is how we can get out of having
> "build.sh" and "build.bat" scripts completely, and just use the
> "ant" script (from $ANT_HOME/bin) directly to run our builds. In order to
> set local environment variables, how about this:
>
Yes, it would be nice to get rid as much as possible of batch files and
shell scripts.
> * If there is a "build.properties" file in the directory you are
> running the build from (this will be "build" after the scripts
> are moved), load it at the top of build.xml.
>
Is it possible to specify the java.class.path property in this file ? (I'd
like to have a different CLASSPATH for each project)
> * The "build.properties" file would be unique to each developer's
> environment (mine will even be different on Linux and Windows :-),
> so it is *not* checked in to CVS.
>
Fine, but we should provide a sample one to help know what to put inside. It
means we should also use lots of available tasks in the build.xml to verify
that all needed properties related to directories are set to correct paths.
> * To avoid "?" messages from CVS, add "build.properties" to the
> appropriate ".cvsignore" file.
>
> Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> your PATH in order to execute the builds by typing things like:
>
> ant compile.javadoc
>
> instead of saying
>
> ./build.sh compile.javadoc
>
> What do you think?
fine. I'll try it on my computer. Although I hate going to DOS ... :) I
usually prefer having several batch files, even with a single line in it ...
This is actually what I have done for running the Struts build : one
directory above jakarta-struts, I have put the needed libraries and some
batch files ... :) I guess I'll have to change my way of doing things ... :)
>
> > > - Modified build.xml and build-webapps to support the above changes
> > >
> >
> > done
> >
> OK
>
> > > This will leave all the build output as it was before (except the test
> > > webapp which is no longer generated for the moment till I finish the
> > > integration with J2EEUnit).
> > >
> > > In a second step, I will add :
> > > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > > - new build-tests.xml and associated batch files in
jakarta-struts/build
> > > - new servlet engine configuration files in jakarta-struts/conf/test
to
> > > support automated J2EEUnit unit testing with several servlet engines
> > > - new environment variables to support testing with several servlet
> > engines
> > > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> > >
>
> Can we make a practice of defining the corresponding properties in a
> build.properties file, as in the discussion above?
>
> tomcat.home=xxxx
> catalina.home=yyyy
> resin.home=zzzz
>
Yes.
> > > Thanks for telling me quickly if I should go ahead or not (at least
for
> > step
> > > 1).
> > >
> > > Also I have noticed that when editing the build*.xml files in my
UltraEdit
> > > all spaces and tabs are disorganized and make the text difficult to
read.
> > I
> > > think we should standardize on a tab value of 4 (for example) and in
our
> > > editors replace tabs by spaces.
> > >
> >
> > done. Tell me if I have done something wrong
> >
>
> Looks good so far.
>
thanks.
> > > Thanks.
> > > Vincent.
> >
> > Vincent.
> >
> >
>
> Craig
>
Vincent
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 18 Mar 2001, Vincent Massol wrote:
> Here follows the status (inline in the mail below). Please tell me if I have
> made any blunder and I'll correct it. Also, I have made some changes that
> are against standards/issues that have been approved/agreed upon (like
> formatting of Ant build files, ...), please tell me and I'll correct it.
> Thanks.
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.fr>
> To: <st...@jakarta.apache.org>
> Sent: Sunday, March 18, 2001 1:11 PM
> Subject: Request go ahead for structural changes in CVS
>
>
> > I'd like to have the go ahead for making the changes to the struts
> directory
> > structure, as mentionned in the thread "[PROPOSAL] Struts Source Directory
> > Structure".
> >
> > Namely, I'd like to commit the following changes that I have locally on my
> > computer (step 1) :
> > - Move jakarta-struts/src/doc to jakarta-struts/doc
>
> done
>
Fine.
> > - Move jakarta-struts/src/conf to jakarta-struts/conf
>
> done
>
Also fine.
> > - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> > directory
>
> waiting for approval
>
I'm fine with the organizational change, and I modified the output of all
the build processes to go to "target" instead of "build" now.
One thing I've been toying with is how we can get out of having
"build.sh" and "build.bat" scripts completely, and just use the
"ant" script (from $ANT_HOME/bin) directly to run our builds. In order to
set local environment variables, how about this:
* If there is a "build.properties" file in the directory you are
running the build from (this will be "build" after the scripts
are moved), load it at the top of build.xml.
* The "build.properties" file would be unique to each developer's
environment (mine will even be different on Linux and Windows :-),
so it is *not* checked in to CVS.
* To avoid "?" messages from CVS, add "build.properties" to the
appropriate ".cvsignore" file.
Note that the dependency on Ant would be that you have $ANT_HOME/bin on
your PATH in order to execute the builds by typing things like:
ant compile.javadoc
instead of saying
./build.sh compile.javadoc
What do you think?
> > - Modified build.xml and build-webapps to support the above changes
> >
>
> done
>
OK
> > This will leave all the build output as it was before (except the test
> > webapp which is no longer generated for the moment till I finish the
> > integration with J2EEUnit).
> >
> > In a second step, I will add :
> > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > - new build-tests.xml and associated batch files in jakarta-struts/build
> > - new servlet engine configuration files in jakarta-struts/conf/test to
> > support automated J2EEUnit unit testing with several servlet engines
> > - new environment variables to support testing with several servlet
> engines
> > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> >
Can we make a practice of defining the corresponding properties in a
build.properties file, as in the discussion above?
tomcat.home=xxxx
catalina.home=yyyy
resin.home=zzzz
> > Thanks for telling me quickly if I should go ahead or not (at least for
> step
> > 1).
> >
> > Also I have noticed that when editing the build*.xml files in my UltraEdit
> > all spaces and tabs are disorganized and make the text difficult to read.
> I
> > think we should standardize on a tab value of 4 (for example) and in our
> > editors replace tabs by spaces.
> >
>
> done. Tell me if I have done something wrong
>
Looks good so far.
> > Thanks.
> > Vincent.
>
> Vincent.
>
>
Craig
Re: Request go ahead for structural changes in CVS
Posted by Vincent Massol <vm...@octo.fr>.
Here follows the status (inline in the mail below). Please tell me if I have
made any blunder and I'll correct it. Also, I have made some changes that
are against standards/issues that have been approved/agreed upon (like
formatting of Ant build files, ...), please tell me and I'll correct it.
Thanks.
----- Original Message -----
From: "Vincent Massol" <vm...@octo.fr>
To: <st...@jakarta.apache.org>
Sent: Sunday, March 18, 2001 1:11 PM
Subject: Request go ahead for structural changes in CVS
> I'd like to have the go ahead for making the changes to the struts
directory
> structure, as mentionned in the thread "[PROPOSAL] Struts Source Directory
> Structure".
>
> Namely, I'd like to commit the following changes that I have locally on my
> computer (step 1) :
> - Move jakarta-struts/src/doc to jakarta-struts/doc
done
> - Move jakarta-struts/src/conf to jakarta-struts/conf
done
> - Move build.xml, build.bat and build.sh to the new jakarta-struts/build
> directory
waiting for approval
> - Modified build.xml and build-webapps to support the above changes
>
done
> This will leave all the build output as it was before (except the test
> webapp which is no longer generated for the moment till I finish the
> integration with J2EEUnit).
>
> In a second step, I will add :
> - Some J2EEUnit test classes in src/test/org/apache/struts/action
> - new build-tests.xml and associated batch files in jakarta-struts/build
> - new servlet engine configuration files in jakarta-struts/conf/test to
> support automated J2EEUnit unit testing with several servlet engines
> - new environment variables to support testing with several servlet
engines
> (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
>
> Thanks for telling me quickly if I should go ahead or not (at least for
step
> 1).
>
> Also I have noticed that when editing the build*.xml files in my UltraEdit
> all spaces and tabs are disorganized and make the text difficult to read.
I
> think we should standardize on a tab value of 4 (for example) and in our
> editors replace tabs by spaces.
>
done. Tell me if I have done something wrong
> Thanks.
> Vincent.
Vincent.
Re: Request go ahead for structural changes in CVS
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 18 Mar 2001, Robert Leland wrote:
> I would like to propose one change to the example
> webapps package names:
>
> Their package names begin with:
> org.apache.struts.webapp.<example name>
>
+1
> This avoids naming conflicts, by reserving a name
> space for the webapps.
>
> -Rob
>
Craig
Re: Request go ahead for structural changes in CVS
Posted by Robert Leland <Ro...@free2create.org>.
I would like to propose one change to the example
webapps package names:
Their package names begin with:
org.apache.struts.webapp.<example name>
This avoids naming conflicts, by reserving a name
space for the webapps.
-Rob
Request go ahead for structural changes in CVS
Posted by Vincent Massol <vm...@octo.fr>.
I'd like to have the go ahead for making the changes to the struts directory
structure, as mentionned in the thread "[PROPOSAL] Struts Source Directory
Structure".
Namely, I'd like to commit the following changes that I have locally on my
computer (step 1) :
- Move jakarta-struts/src/doc to jakarta-struts/doc
- Move jakarta-struts/src/conf to jakarta-struts/conf
- Move build.xml, build.bat and build.sh to the new jakarta-struts/build
directory
- Modified build.xml and build-webapps to support the above changes
This will leave all the build output as it was before (except the test
webapp which is no longer generated for the moment till I finish the
integration with J2EEUnit).
In a second step, I will add :
- Some J2EEUnit test classes in src/test/org/apache/struts/action
- new build-tests.xml and associated batch files in jakarta-struts/build
- new servlet engine configuration files in jakarta-struts/conf/test to
support automated J2EEUnit unit testing with several servlet engines
- new environment variables to support testing with several servlet engines
(TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
Thanks for telling me quickly if I should go ahead or not (at least for step
1).
Also I have noticed that when editing the build*.xml files in my UltraEdit
all spaces and tabs are disorganized and make the text difficult to read. I
think we should standardize on a tab value of 4 (for example) and in our
editors replace tabs by spaces.
Thanks.
Vincent.
Re: [PROPOSAL] Struts Unit Test Guidelines
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Monday, March 19, 2001 7:52 AM
Subject: Re: [PROPOSAL] Struts Unit Test Guidelines
> Please see comments inline.
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@octo.fr>
> To: <st...@jakarta.apache.org>
> Sent: Saturday, March 17, 2001 11:51 PM
> Subject: [PROPOSAL] Struts Unit Test Guidelines
>
>
> > I think we need to give some guidelines for anyone who would like to
> > participate in writing unit tests for Struts. I'd like to start this
> process
> > by giving you my views on the subject and discuss it. When we have a
final
> > agreement, we can put a web page on the struts web site.
> >
> > Here are some of the rules/guidelines that I can see so far :
> >
> > 1) Put the test sources in jakarta-struts/src/test. For example if you
> want
> > to write a unit test for class org.apache.struts.action.ServletAction,
you
> > woud put the test class in
> jakarta-struts/src/test/org/apache/struts/action
>
> I had been thinking of a "sub-package" for tests (e.g.
> <original-package-name>.test), but now that I think about it, it makes
sense
> to put the tests in the same package, for access reasons.
>
> > 2) Name of the test class. For any XXX class to test, the associated
test
> > class should be named TestXXX. I'm sure others will prefer XXXTest. I
> don't
> > really care, we just need to standardize on one.
>
> I would prefer TestXXX, for two reasons:
>
> 1) It matches the way I think about unit tests ;-) (i.e. "test this,
> please")
> 2) It is consistent with JUnit's automatic identification of tests using
> testXXX() methods.
>
> > 3) Any helper class and resources for the test should be put in the same
> > directory as the test class. For example, if my test class accepts
several
> > xml files, I would put them where I put my TestXXX class and I would use
> > Class.getResourceAsStream() to load them (thus removing the need to hard
> > code the path of the resource). Again, this is a proposition. Another
> > solution would be to put them in the jakara-struts/conf/test directory.
>
> When I was thinking about "sub-packages" for testing, I had been thinking
> about a ".testdata" sub-package. I still think a separate package for test
> data would be useful. It would help isolate data used as input to the
tests
> from data required by the test code itself, and isolate both of those from
> data in the package under test.
>
Why not, but then it must be unique enough so that this package does not
exist in the src packages ? Or put the helper classes in the same dir and
helper config files in conf/test ?
> My thinking is that test data for the
org.apache.struts.action.ServletAction
> class would be found in
> jakarta-struts/src/test/org/apache/struts/action/testdata/.
>
> I agree completely with using Class.getResourceAsStream() to access the
test
> data. That's what I'm doing now. :-)
>
> > 4) All test suites should be gathered in a single TestAll.java (or
> > AllTest.java) test class that will located in
> > jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> > tests will use this file to run all the tests.
>
> To the extent that this can be done automatically, I agree. However, I
think
> we should do as much as possible to minimize the effort required to add a
> new test.
>
> For example, with JUnit, you can add a test just by adding a method named
> "testXXX" to your class derived from TestCase. If we can define a Struts
> test suite in a similar way, perhaps using JUnit constructs or perhaps
using
> Ant build files (which are probably more flexible), that would be great.
>
yes I agree. See my response to Craig's email on the same subject
> > And then general good practice rules (See this article for more details
> > http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
> >
> > 5) Test cases should be completely independent from one another. Don't
> > assume the order in which your test cases will run.
> > 6) Avoid hard coding paths in your test cases
> > 7) do not use the test case constructor to set up a test case
> > 8) Avoid writing test cases with side-effects
> > 9) Keep tests small and fast
> > 10) Name test cases properly
> > 11) Ensure that tests are time independent
> > 12) Consider locale when writing tests
> > 13) Always test for error conditions
> > 14) Utilize properly assert/fails and exception mechanism (i.e. don't
put
> a
> > ty/catch around a test case for which you don't expect an exception)
> > 15) Document tests in javadoc. This is very important as unit tests are
a
> > very good way to document the code.
>
> These seem like good guidelines to me!
>
> > Vincent.
>
> --
> Martin Cooper
>
>
>
>
Vincent
Re: [PROPOSAL] Struts Unit Test Guidelines
Posted by Martin Cooper <ma...@tumbleweed.com>.
Please see comments inline.
----- Original Message -----
From: "Vincent Massol" <vm...@octo.fr>
To: <st...@jakarta.apache.org>
Sent: Saturday, March 17, 2001 11:51 PM
Subject: [PROPOSAL] Struts Unit Test Guidelines
> I think we need to give some guidelines for anyone who would like to
> participate in writing unit tests for Struts. I'd like to start this
process
> by giving you my views on the subject and discuss it. When we have a final
> agreement, we can put a web page on the struts web site.
>
> Here are some of the rules/guidelines that I can see so far :
>
> 1) Put the test sources in jakarta-struts/src/test. For example if you
want
> to write a unit test for class org.apache.struts.action.ServletAction, you
> woud put the test class in
jakarta-struts/src/test/org/apache/struts/action
I had been thinking of a "sub-package" for tests (e.g.
<original-package-name>.test), but now that I think about it, it makes sense
to put the tests in the same package, for access reasons.
> 2) Name of the test class. For any XXX class to test, the associated test
> class should be named TestXXX. I'm sure others will prefer XXXTest. I
don't
> really care, we just need to standardize on one.
I would prefer TestXXX, for two reasons:
1) It matches the way I think about unit tests ;-) (i.e. "test this,
please")
2) It is consistent with JUnit's automatic identification of tests using
testXXX() methods.
> 3) Any helper class and resources for the test should be put in the same
> directory as the test class. For example, if my test class accepts several
> xml files, I would put them where I put my TestXXX class and I would use
> Class.getResourceAsStream() to load them (thus removing the need to hard
> code the path of the resource). Again, this is a proposition. Another
> solution would be to put them in the jakara-struts/conf/test directory.
When I was thinking about "sub-packages" for testing, I had been thinking
about a ".testdata" sub-package. I still think a separate package for test
data would be useful. It would help isolate data used as input to the tests
from data required by the test code itself, and isolate both of those from
data in the package under test.
My thinking is that test data for the org.apache.struts.action.ServletAction
class would be found in
jakarta-struts/src/test/org/apache/struts/action/testdata/.
I agree completely with using Class.getResourceAsStream() to access the test
data. That's what I'm doing now. :-)
> 4) All test suites should be gathered in a single TestAll.java (or
> AllTest.java) test class that will located in
> jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> tests will use this file to run all the tests.
To the extent that this can be done automatically, I agree. However, I think
we should do as much as possible to minimize the effort required to add a
new test.
For example, with JUnit, you can add a test just by adding a method named
"testXXX" to your class derived from TestCase. If we can define a Struts
test suite in a similar way, perhaps using JUnit constructs or perhaps using
Ant build files (which are probably more flexible), that would be great.
> And then general good practice rules (See this article for more details
> http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
>
> 5) Test cases should be completely independent from one another. Don't
> assume the order in which your test cases will run.
> 6) Avoid hard coding paths in your test cases
> 7) do not use the test case constructor to set up a test case
> 8) Avoid writing test cases with side-effects
> 9) Keep tests small and fast
> 10) Name test cases properly
> 11) Ensure that tests are time independent
> 12) Consider locale when writing tests
> 13) Always test for error conditions
> 14) Utilize properly assert/fails and exception mechanism (i.e. don't put
a
> ty/catch around a test case for which you don't expect an exception)
> 15) Document tests in javadoc. This is very important as unit tests are a
> very good way to document the code.
These seem like good guidelines to me!
> Vincent.
--
Martin Cooper
Re: [PROPOSAL] Struts Unit Test Guidelines
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <cr...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Sunday, March 18, 2001 11:39 PM
> Subject: Re: [PROPOSAL] Struts Unit Test Guidelines
>
>
> >
> >
> > On Sun, 18 Mar 2001, Vincent Massol wrote:
> >
> > > I think we need to give some guidelines for anyone who would like to
> > > participate in writing unit tests for Struts. I'd like to start this
> process
> > > by giving you my views on the subject and discuss it. When we have a
> final
> > > agreement, we can put a web page on the struts web site.
> > >
> > > Here are some of the rules/guidelines that I can see so far :
> > >
> > > 1) Put the test sources in jakarta-struts/src/test. For example if you
> want
> > > to write a unit test for class org.apache.struts.action.ServletAction,
> you
> > > woud put the test class in
> jakarta-struts/src/test/org/apache/struts/action
> > >
> >
> > An implication of this is that the package would be
> > "org.apache.struts.action", the same as the package you are testing, which
> > allows access to package private methods. We might want to state that
> > explicitly as a guideline.
> >
>
> sure
>
> > > 2) Name of the test class. For any XXX class to test, the associated
> test
> > > class should be named TestXXX. I'm sure others will prefer XXXTest. I
> don't
> > > really care, we just need to standardize on one.
> > >
> >
> > I have a mild preference for "TextXxxxx" -- I think of the word test as a
> > "verb", and that is what "test xxxxx" would mean (at least in English :-).
>
> What do you propose ?
>
TestActionServlet for the tests that exercise ActionServlet, and so on.
> >
> > I also like naming the test methods "testThisCase()" or
> > "testThatMethod()" as well.
>
> yes, but testThatMethod() is not enough. For a given method there are
> several test cases : one with such bad argument, another with a bad
> environment set up, ... So, I 'd rather state it as in 10) below (see
> http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) like :
> testThatMethodNullPath()
>
You're right, of course. The individual test names should include both
the method being tested and some indication of what you are testing for.
> >
> > > 3) Any helper class and resources for the test should be put in the same
> > > directory as the test class. For example, if my test class accepts
> several
> > > xml files, I would put them where I put my TestXXX class and I would use
> > > Class.getResourceAsStream() to load them (thus removing the need to hard
> > > code the path of the resource). Again, this is a proposition. Another
> > > solution would be to put them in the jakara-struts/conf/test directory.
> > >
> >
> > +1. This concept should be familiar to Struts developers anyway, because
> > that is how application resources (message bundles) are accessed.
> >
>
> fine. What about locations of helper classes and resources ? Do we want to
> standardize on their naming also. What I do on my projects is to prefix all
> of them with the name of the test class that need them. For example :
> TestXXX_Helper.class, TestXXX_BadConfiguration.xml, ... But I understand
> that you might not like this. The problem is you don't do that you might
> find yourselves with tens or hundreds or resources files and classes and you
> don' know who is using them. This is especially true if the class to test
> use a properties or an xml file. You might want to test your class against
> several bad formatted config files to verify that you handle correctly
> exceptions cases. Another solution as Martin suggested is to put them
> somewhere in conf/test/
>
I'm fine with TestXXX_Helper.java, TestXXX_BadConfiguration.xml, and so on
being in the same directory as the test classes themselves, for the
following reasons:
* I have a harder time finding dependent things if they are not
all in the same directory. Because of the common name prefix
(TestXXX), I can tell that all of these things belong together.
* If they are in the same directory, the sorted listing even puts
them all together in a nice order.
> > > 4) All test suites should be gathered in a single TestAll.java (or
> > > AllTest.java) test class that will located in
> > > jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> > > tests will use this file to run all the tests.
> > >
> >
> > (I'm assuming a missing guideline that the tests will be run from an Ant
> > script of some sort - if that assumption is wrong, the following will not
> > make much sense.)
> >
> > Do we really need a TestAll class if we're using Ant to run the tests? We
> > can easily create targets for each suite of tests you might want to run
> > together, and have an "all" target that causes all of them to be executed
> > through appropriate dependencies.
> >
> > Given that you have to update the Ant testing script anyway as new tests
> > are added, it seems redundant to also have to modify TestAll.
>
> yes I agree. Let's forget the TestAll java class. Also, the junit ant task
> has a <batch> nested tag to automatically look for classes that extend
> TestCase and run them ...
Cool.
> >
> > > And then general good practice rules (See this article for more details
> > > http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
> > >
> > > 5) Test cases should be completely independent from one another. Don't
> > > assume the order in which your test cases will run.
> > > 6) Avoid hard coding paths in your test cases
> > > 7) do not use the test case constructor to set up a test case
> > > 8) Avoid writing test cases with side-effects
> > > 9) Keep tests small and fast
> > > 10) Name test cases properly
> > > 11) Ensure that tests are time independent
> > > 12) Consider locale when writing tests
> > > 13) Always test for error conditions
> > > 14) Utilize properly assert/fails and exception mechanism (i.e. don't
> put a
> > > ty/catch around a test case for which you don't expect an exception)
> > > 15) Document tests in javadoc. This is very important as unit tests are
> a
> > > very good way to document the code.
> > >
> > > Comments ? (I'm sure I'll get plenty ... :)
> > >
> > > Vincent.
> > >
> > >
> >
> > Craig
> >
> >
> >
> Vincent
>
>
Craig
Re: [PROPOSAL] Struts Unit Test Guidelines
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Sunday, March 18, 2001 11:39 PM
Subject: Re: [PROPOSAL] Struts Unit Test Guidelines
>
>
> On Sun, 18 Mar 2001, Vincent Massol wrote:
>
> > I think we need to give some guidelines for anyone who would like to
> > participate in writing unit tests for Struts. I'd like to start this
process
> > by giving you my views on the subject and discuss it. When we have a
final
> > agreement, we can put a web page on the struts web site.
> >
> > Here are some of the rules/guidelines that I can see so far :
> >
> > 1) Put the test sources in jakarta-struts/src/test. For example if you
want
> > to write a unit test for class org.apache.struts.action.ServletAction,
you
> > woud put the test class in
jakarta-struts/src/test/org/apache/struts/action
> >
>
> An implication of this is that the package would be
> "org.apache.struts.action", the same as the package you are testing, which
> allows access to package private methods. We might want to state that
> explicitly as a guideline.
>
sure
> > 2) Name of the test class. For any XXX class to test, the associated
test
> > class should be named TestXXX. I'm sure others will prefer XXXTest. I
don't
> > really care, we just need to standardize on one.
> >
>
> I have a mild preference for "TextXxxxx" -- I think of the word test as a
> "verb", and that is what "test xxxxx" would mean (at least in English :-).
What do you propose ?
>
> I also like naming the test methods "testThisCase()" or
> "testThatMethod()" as well.
yes, but testThatMethod() is not enough. For a given method there are
several test cases : one with such bad argument, another with a bad
environment set up, ... So, I 'd rather state it as in 10) below (see
http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) like :
testThatMethodNullPath()
>
> > 3) Any helper class and resources for the test should be put in the same
> > directory as the test class. For example, if my test class accepts
several
> > xml files, I would put them where I put my TestXXX class and I would use
> > Class.getResourceAsStream() to load them (thus removing the need to hard
> > code the path of the resource). Again, this is a proposition. Another
> > solution would be to put them in the jakara-struts/conf/test directory.
> >
>
> +1. This concept should be familiar to Struts developers anyway, because
> that is how application resources (message bundles) are accessed.
>
fine. What about locations of helper classes and resources ? Do we want to
standardize on their naming also. What I do on my projects is to prefix all
of them with the name of the test class that need them. For example :
TestXXX_Helper.class, TestXXX_BadConfiguration.xml, ... But I understand
that you might not like this. The problem is you don't do that you might
find yourselves with tens or hundreds or resources files and classes and you
don' know who is using them. This is especially true if the class to test
use a properties or an xml file. You might want to test your class against
several bad formatted config files to verify that you handle correctly
exceptions cases. Another solution as Martin suggested is to put them
somewhere in conf/test/
> > 4) All test suites should be gathered in a single TestAll.java (or
> > AllTest.java) test class that will located in
> > jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> > tests will use this file to run all the tests.
> >
>
> (I'm assuming a missing guideline that the tests will be run from an Ant
> script of some sort - if that assumption is wrong, the following will not
> make much sense.)
>
> Do we really need a TestAll class if we're using Ant to run the tests? We
> can easily create targets for each suite of tests you might want to run
> together, and have an "all" target that causes all of them to be executed
> through appropriate dependencies.
>
> Given that you have to update the Ant testing script anyway as new tests
> are added, it seems redundant to also have to modify TestAll.
yes I agree. Let's forget the TestAll java class. Also, the junit ant task
has a <batch> nested tag to automatically look for classes that extend
TestCase and run them ...
>
> > And then general good practice rules (See this article for more details
> > http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
> >
> > 5) Test cases should be completely independent from one another. Don't
> > assume the order in which your test cases will run.
> > 6) Avoid hard coding paths in your test cases
> > 7) do not use the test case constructor to set up a test case
> > 8) Avoid writing test cases with side-effects
> > 9) Keep tests small and fast
> > 10) Name test cases properly
> > 11) Ensure that tests are time independent
> > 12) Consider locale when writing tests
> > 13) Always test for error conditions
> > 14) Utilize properly assert/fails and exception mechanism (i.e. don't
put a
> > ty/catch around a test case for which you don't expect an exception)
> > 15) Document tests in javadoc. This is very important as unit tests are
a
> > very good way to document the code.
> >
> > Comments ? (I'm sure I'll get plenty ... :)
> >
> > Vincent.
> >
> >
>
> Craig
>
>
>
Vincent
RE: [PROPOSAL] Struts Unit Test Guidelines
Posted by Michael Hackett <mh...@pictorius.com>.
> From: Craig R. McClanahan <cr...@apache.org>
> I have a mild preference for "TextXxxxx" -- I think of the
> word test as a
> "verb", and that is what "test xxxxx" would mean (at least in
> English :-).
The word "test" is just as likely to be a noun. Didn't you take any
"tests" in school? :-) Also, class names are supposed to be nouns,
although it seems the usual convention for JUnit is to use Test as a
prefix. (Probably the most correct form would be XxxTester, but the
convention is established now and will be hard to break.)
--
Michael Hackett
Developer, Pictorius Inc.
Re: [PROPOSAL] Struts Unit Test Guidelines
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 18 Mar 2001, Vincent Massol wrote:
> I think we need to give some guidelines for anyone who would like to
> participate in writing unit tests for Struts. I'd like to start this process
> by giving you my views on the subject and discuss it. When we have a final
> agreement, we can put a web page on the struts web site.
>
> Here are some of the rules/guidelines that I can see so far :
>
> 1) Put the test sources in jakarta-struts/src/test. For example if you want
> to write a unit test for class org.apache.struts.action.ServletAction, you
> woud put the test class in jakarta-struts/src/test/org/apache/struts/action
>
An implication of this is that the package would be
"org.apache.struts.action", the same as the package you are testing, which
allows access to package private methods. We might want to state that
explicitly as a guideline.
> 2) Name of the test class. For any XXX class to test, the associated test
> class should be named TestXXX. I'm sure others will prefer XXXTest. I don't
> really care, we just need to standardize on one.
>
I have a mild preference for "TextXxxxx" -- I think of the word test as a
"verb", and that is what "test xxxxx" would mean (at least in English :-).
I also like naming the test methods "testThisCase()" or
"testThatMethod()" as well.
> 3) Any helper class and resources for the test should be put in the same
> directory as the test class. For example, if my test class accepts several
> xml files, I would put them where I put my TestXXX class and I would use
> Class.getResourceAsStream() to load them (thus removing the need to hard
> code the path of the resource). Again, this is a proposition. Another
> solution would be to put them in the jakara-struts/conf/test directory.
>
+1. This concept should be familiar to Struts developers anyway, because
that is how application resources (message bundles) are accessed.
> 4) All test suites should be gathered in a single TestAll.java (or
> AllTest.java) test class that will located in
> jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
> tests will use this file to run all the tests.
>
(I'm assuming a missing guideline that the tests will be run from an Ant
script of some sort - if that assumption is wrong, the following will not
make much sense.)
Do we really need a TestAll class if we're using Ant to run the tests? We
can easily create targets for each suite of tests you might want to run
together, and have an "all" target that causes all of them to be executed
through appropriate dependencies.
Given that you have to update the Ant testing script anyway as new tests
are added, it seems redundant to also have to modify TestAll.
> And then general good practice rules (See this article for more details
> http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
>
> 5) Test cases should be completely independent from one another. Don't
> assume the order in which your test cases will run.
> 6) Avoid hard coding paths in your test cases
> 7) do not use the test case constructor to set up a test case
> 8) Avoid writing test cases with side-effects
> 9) Keep tests small and fast
> 10) Name test cases properly
> 11) Ensure that tests are time independent
> 12) Consider locale when writing tests
> 13) Always test for error conditions
> 14) Utilize properly assert/fails and exception mechanism (i.e. don't put a
> ty/catch around a test case for which you don't expect an exception)
> 15) Document tests in javadoc. This is very important as unit tests are a
> very good way to document the code.
>
> Comments ? (I'm sure I'll get plenty ... :)
>
> Vincent.
>
>
Craig
[PROPOSAL] Struts Unit Test Guidelines
Posted by Vincent Massol <vm...@octo.fr>.
I think we need to give some guidelines for anyone who would like to
participate in writing unit tests for Struts. I'd like to start this process
by giving you my views on the subject and discuss it. When we have a final
agreement, we can put a web page on the struts web site.
Here are some of the rules/guidelines that I can see so far :
1) Put the test sources in jakarta-struts/src/test. For example if you want
to write a unit test for class org.apache.struts.action.ServletAction, you
woud put the test class in jakarta-struts/src/test/org/apache/struts/action
2) Name of the test class. For any XXX class to test, the associated test
class should be named TestXXX. I'm sure others will prefer XXXTest. I don't
really care, we just need to standardize on one.
3) Any helper class and resources for the test should be put in the same
directory as the test class. For example, if my test class accepts several
xml files, I would put them where I put my TestXXX class and I would use
Class.getResourceAsStream() to load them (thus removing the need to hard
code the path of the resource). Again, this is a proposition. Another
solution would be to put them in the jakara-struts/conf/test directory.
4) All test suites should be gathered in a single TestAll.java (or
AllTest.java) test class that will located in
jakarta-struts/src/test/org/apache/struts. The build.xml target for unit
tests will use this file to run all the tests.
And then general good practice rules (See this article for more details
http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html) :
5) Test cases should be completely independent from one another. Don't
assume the order in which your test cases will run.
6) Avoid hard coding paths in your test cases
7) do not use the test case constructor to set up a test case
8) Avoid writing test cases with side-effects
9) Keep tests small and fast
10) Name test cases properly
11) Ensure that tests are time independent
12) Consider locale when writing tests
13) Always test for error conditions
14) Utilize properly assert/fails and exception mechanism (i.e. don't put a
ty/catch around a test case for which you don't expect an exception)
15) Document tests in javadoc. This is very important as unit tests are a
very good way to document the code.
Comments ? (I'm sure I'll get plenty ... :)
Vincent.
RE: Applets and Struts
Posted by Christian Cryder <ch...@lutris.com>.
> It still seems that Struts is a few realeases away from anything
> like this. I guess I need to look at Barracuda again. Barracuda
> seems more applet-friendly, but I would guess that I am still out
> of luck.
Well, in terms of applets, I don't really think of either Struts or
Barracuda (or any other server-side technology) as being "non-applet
friendly"...you just write the applet, place it on the server, and reference
it in the browser markup and it will run in the browser (well, maybe, but
that's another issue).
Now, perhaps you're looking for something that's pre-written; that's
certainly a long-term goal within Barracuda. We'd like to have the developer
on the server just use a BTree component, and not have to worry about
whether its rendered as an applet or as javascript markup. Its not there yet
though.
Part of the problem is that there are so many different ways to simulate
tree controls in markup, and the particular approach you use will vary
depending on your particular requirements. Applets make the task a lot
easier, but there's all kinds of ancillary issues involved. I wrote
client-server apps for 2 years and we deployed them as applets...we were
able to do some pretty cool things, but the process was very painful because
of browser compatibility issues. From my perspective, the only hope for
applets is Java Plugin, and as much as I'd like to say that technology is
finally mature, I still don't think it is (although it has been a while
since I've looked at it, so maybe things have changed).
Keep in mind though, if Applets ever become viable, then the real question
becomes "Why write web-apps at all?" I think there will probably always be a
place for webapps, but its just so much easier to deliver advanced
functionality in the stated client-server paradigm. The thing that kills
applets is the JVM compatibility issues...
Anyway, I digress. The answer to your question is: Barracuda hopes to
address this at some point, but it's not there yet. Before you can abstract
something into a reusable component, you first have to figure out a reusable
process that works for the majority of scenarios, and for tree controls that
has proven elusive in the web-app paradigm.
Just my .02...
Christian
------------------------------------------------
Christian Cryder
christianc@enhydra.org
Barracuda - Open-source MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
>
> > -----Original Message-----
> > From: Dan Connelly [mailto:dsconnelly@adelphia.net]
> > Sent: Sunday, May 06, 2001 9:32 AM
> > To: struts-dev@jakarta.apache.org
> > Subject: Applets and Struts
> >
> >
> > Forgive me for being lazy about trying out applets with Struts.
> > I haven't "worked" it. Struts may be a few releases from
> > supporting applets in general. But my requirements are more
> > limited, as follows:
> >
> > I want to run a tree viewer applet with dynamic tree expansion
> > (and collapsing). "Dynamic" because the node expansion info will
> > gathered on the fly and fed to the live applet for display. This
> > is unlike DHTML techniques (like HierMenus) which are fully
> > populated in the JavaScript to begin with.
> >
> > There seem to be many such dynamic applets for trees about. They
> > are pretty cheap, pretty quick and pretty pretty. The "Tree
> > Navigation System" from Sirius Computer Consultants
> > www.jpowered.com is a good example, but any I'm not locked into
> > any particular component software.
> >
> > One of the advantages of a tree display, rather than a path walk,
> > is that you can see as much (or as little) of any sub-tree as you
> > want in one "page" display.
> >
> > In Struts you can use cascading sets of <html:select> option
> > lists to implement an "uncle" tree, a more limited form of tree
> > display. You see your uncles, but none of your cousins. At
> > least with the MVC in Struts you can navigate to an off-tree
> > action and then use the "Back" button to recover the current
> > state of the "uncle" tree.
> >
> > The Sirius Tree Navigation System doesn't support "Back". If
> > you go back, the tree has collapsed to its orignal, tight state.
> > This is not what I want. I want what Struts does, leave the
> > tree as it was before I navigated off-tree.
> >
> > So, I have these three criteria:
> > 1.. Dynamic "refresh" (from a shared database) each time a node
> > is expanded to sub-nodes.
> > 2.. Can see your cousins if you wish to.
> > 3.. Can use the "Back" button to recover the tree display after
> > following a link off-tree. (No dynamic update.)
> > How do I get there?
> >
> > I'm out of luck.
> >
> > It still seems that Struts is a few realeases away from anything
> > like this. I guess I need to look at Barracuda again. Barracuda
> > seems more applet-friendly, but I would guess that I am still out
> > of luck.
RE: Applets and Struts
Posted by Christian Cryder <ch...@enhydra.org>.
> It still seems that Struts is a few realeases away from anything
> like this. I guess I need to look at Barracuda again. Barracuda
> seems more applet-friendly, but I would guess that I am still out
> of luck.
Well, in terms of applets, I don't really think of either Struts or
Barracuda (or any other server-side technology) as being "non-applet
friendly"...you just write the applet, place it on the server, and reference
it in the browser markup and it will run in the browser (well, maybe, but
that's another issue).
Now, perhaps you're looking for something that's pre-written; that's
certainly a long-term goal within Barracuda. We'd like to have the developer
on the server just use a BTree component, and not have to worry about
whether its rendered as an applet or as javascript markup. Its not there yet
though.
Part of the problem is that there are so many different ways to simulate
tree controls in markup, and the particular approach you use will vary
depending on your particular requirements. Applets make the task a lot
easier, but there's all kinds of ancillary issues involved. I wrote
client-server apps for 2 years and we deployed them as applets...we were
able to do some pretty cool things, but the process was very painful because
of browser compatibility issues. From my perspective, the only hope for
applets is Java Plugin, and as much as I'd like to say that technology is
finally mature, I still don't think it is (although it has been a while
since I've looked at it, so maybe things have changed).
Keep in mind though, if Applets ever become viable, then the real question
becomes "Why write web-apps at all?" I think there will probably always be a
place for webapps, but its just so much easier to deliver advanced
functionality in the stated client-server paradigm. The thing that kills
applets is the JVM compatibility issues...
Anyway, I digress. The answer to your question is: Barracuda hopes to
address this at some point, but it's not there yet. Before you can abstract
something into a reusable component, you first have to figure out a reusable
process that works for the majority of scenarios, and for tree controls that
has proven elusive in the web-app paradigm.
Just my .02...
Christian
------------------------------------------------
Christian Cryder
christianc@enhydra.org
Barracuda - Open-source MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Dan Connelly [mailto:dsconnelly@adelphia.net]
> Sent: Sunday, May 06, 2001 9:32 AM
> To: struts-dev@jakarta.apache.org
> Subject: Applets and Struts
>
>
> Forgive me for being lazy about trying out applets with Struts.
> I haven't "worked" it. Struts may be a few releases from
> supporting applets in general. But my requirements are more
> limited, as follows:
>
> I want to run a tree viewer applet with dynamic tree expansion
> (and collapsing). "Dynamic" because the node expansion info will
> gathered on the fly and fed to the live applet for display. This
> is unlike DHTML techniques (like HierMenus) which are fully
> populated in the JavaScript to begin with.
>
> There seem to be many such dynamic applets for trees about. They
> are pretty cheap, pretty quick and pretty pretty. The "Tree
> Navigation System" from Sirius Computer Consultants
> www.jpowered.com is a good example, but any I'm not locked into
> any particular component software.
>
> One of the advantages of a tree display, rather than a path walk,
> is that you can see as much (or as little) of any sub-tree as you
> want in one "page" display.
>
> In Struts you can use cascading sets of <html:select> option
> lists to implement an "uncle" tree, a more limited form of tree
> display. You see your uncles, but none of your cousins. At
> least with the MVC in Struts you can navigate to an off-tree
> action and then use the "Back" button to recover the current
> state of the "uncle" tree.
>
> The Sirius Tree Navigation System doesn't support "Back". If
> you go back, the tree has collapsed to its orignal, tight state.
> This is not what I want. I want what Struts does, leave the
> tree as it was before I navigated off-tree.
>
> So, I have these three criteria:
> 1.. Dynamic "refresh" (from a shared database) each time a node
> is expanded to sub-nodes.
> 2.. Can see your cousins if you wish to.
> 3.. Can use the "Back" button to recover the tree display after
> following a link off-tree. (No dynamic update.)
> How do I get there?
>
> I'm out of luck.
>
> It still seems that Struts is a few realeases away from anything
> like this. I guess I need to look at Barracuda again. Barracuda
> seems more applet-friendly, but I would guess that I am still out
> of luck.
Applets and Struts
Posted by Dan Connelly <ds...@adelphia.net>.
Forgive me for being lazy about trying out applets with Struts. I haven't "worked" it. Struts may be a few releases from supporting applets in general. But my requirements are more limited, as follows:
I want to run a tree viewer applet with dynamic tree expansion (and collapsing). "Dynamic" because the node expansion info will gathered on the fly and fed to the live applet for display. This is unlike DHTML techniques (like HierMenus) which are fully populated in the JavaScript to begin with.
There seem to be many such dynamic applets for trees about. They are pretty cheap, pretty quick and pretty pretty. The "Tree Navigation System" from Sirius Computer Consultants www.jpowered.com is a good example, but any I'm not locked into any particular component software.
One of the advantages of a tree display, rather than a path walk, is that you can see as much (or as little) of any sub-tree as you want in one "page" display.
In Struts you can use cascading sets of <html:select> option lists to implement an "uncle" tree, a more limited form of tree display. You see your uncles, but none of your cousins. At least with the MVC in Struts you can navigate to an off-tree action and then use the "Back" button to recover the current state of the "uncle" tree.
The Sirius Tree Navigation System doesn't support "Back". If you go back, the tree has collapsed to its orignal, tight state. This is not what I want. I want what Struts does, leave the tree as it was before I navigated off-tree.
So, I have these three criteria:
1.. Dynamic "refresh" (from a shared database) each time a node is expanded to sub-nodes.
2.. Can see your cousins if you wish to.
3.. Can use the "Back" button to recover the tree display after following a link off-tree. (No dynamic update.)
How do I get there?
I'm out of luck.
It still seems that Struts is a few realeases away from anything like this. I guess I need to look at Barracuda again. Barracuda seems more applet-friendly, but I would guess that I am still out of luck.
.
Cactus suite of tests for Struts - Done
Posted by Vincent Massol <vm...@octo.com>.
Ok, here it is !
I have committed the changes to enable running cactus unit tests within
Struts. Please have a look and tell me what you think. Please note that
although I have committed the changes, David Winterfeldt was the one who
initially wrote this Cactus integration with Struts and sent it to me by
email. I have only slightly modified his scripts (Is that ok David ?).
I have only put a very simple test class (which is not even finished !). The
goal was to set up the build mechanism.
In order to run the unit tests :
- modify your build.properties, looking at the build.properties.sample for
additional properties required for unit testing
- simply type "ant test.all" to run the unit tests on all servlet engines or
"ant test.tomcat.32" for Tomcat 3.2 or "ant test.tomcat.40" for Tomcat 4.0
Now, the next step, for which we need as much help as possible is to write
test classes for existing Struts classes.
Here is the final directory structure :
Here is the directory structure proposal (I have put a + in front of new
items and * in front of modified existing items) :
jakarta-struts
|_ * build.xml
|_ + build-tests.xml
|_ * build.properties.sample
|_ conf
|_ share
|_ + test
|_ + tomcat32
|_ + server.xml
|_ + tomcat40
|_ + server.xml
|_ + web.xml
|_ + cactus.properties
|_ + struts-config.xml
|_ src
|_ share
|_ [...]
|_ + test
|_ + org
|_ + ... test classes
|_ target (output directory)
|_ library
|_ [...]
|_ + test
|_ test.war
|_ + classes
|_ + lib
|_ + servers
|_ + tomcat32
|_ + conf
|_ + server.xml
|_ + webapps
|_ + test.war
|_ + test
|_ (see below for details)
|_ + tomcat40
|_ + conf
|_ + server.xml
|_ + webapps
|_ + test.war
|_ + test
|_ (see below for details)
The expanded test.war will contain :
test
|_ WEB-INF
|_ classes
|_ <test classes>
|_ lib
|_ struts.jar
|_ junit.jar
|_ commons-cactus.jar (the one for the correct servlet API)
|_ web.xml
Thanks.
Vincent.
Re: Cactus suite of tests for Struts
Posted by Martin Cooper <ma...@tumbleweed.com>.
A "Struts 1.0 Beta 2" release would be great! As you said, there are many
bug fixes, and I'm working with "nightly-build-averse" management... :-}
--
Martin Cooper
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>; "Vincent Massol" <vm...@octo.com>
Cc: <dw...@yahoo.com>
Sent: Saturday, May 05, 2001 8:17 PM
Subject: Re: Cactus suite of tests for Struts
> +1. I like it!
>
> After you're done, I want to declare a "Struts 1.0 beta 2" release,
> because I've been knocking off a bunch of the Bugzilla bug reports, and
> it is time to let the world know about the progress that has been made.
>
> Craig
>
>
> On Sat, 5 May 2001, Vincent Massol wrote:
>
> > I have been working with David Winterfeldt on adding Cactus tests to
Struts.
> > The plan is to add all build-related stuff tomorrow (Sunday) in Struts
CVS
> > with a very simple test class. The second step will be to gather all
> > available help to write some other unit tests and ensuring that all new
> > submitted code has it's own test classes.
> >
> > Here is the directory structure proposal (I have put a + in front of new
> > items and * in front of modified existing items) :
> >
> > jakarta-struts
> > |_ * build.xml
> > |_ + build-tests.xml
> > |_ * build.properties.sample
> > |_ conf
> > |_ share
> > |_ + test
> > |_ + tomcat32
> > |_ + server.xml
> > |_ + tomcat40
> > |_ + server.xml
> > |_ + web.xml
> > |_ + cactus.properties
> > |_ src
> > |_ share
> > |_ [...]
> > |_ + test
> > |_ + org
> > |_ + ... test classes
> > |_ target (output directory)
> > |_ library
> > |_ [...]
> > |_ + test
> > |_ + classes
> > |_ + servers
> > |_ + tomcat32
> > |_ + test.war
> > |_ + conf
> > |_ + server.xml
> > |_ + webapps
> > |_ + test
> > |_ (see below for details)
> > |_ + tomcat40
> > |_ + test.war
> > |_ + conf
> > |_ + server.xml
> > |_ + webapps
> > |_ + test
> > |_ (see below for details)
> >
> > The expanded test.war will contain :
> >
> > test
> > |_ WEB-INF
> > |_ classes
> > |_ <test classes>
> > |_ lib
> > |_ struts.jar
> > |_ junit.jar
> > |_ commons-cactus.jar (the one for the correct servlet API)
> > |_ web.xml
> >
> > Note: One option is to put the jars in lib/ in the global classpath of
> > Tomcat so that they are shared by all webapps
> >
> > 3 new targets will be added to build.xml : test_all, test_tomcat_32 and
> > test_tomcat40
> >
> > The structure will probably slightly change as we implement it.
> >
> > We will probably commit this around tomorrow night. So, if you have some
> > questions/modifications to submit please do so ASAP ... :)
> >
> > Thanks
> > Vincent.
> >
> >
>
Re: Change J2EEUnit to Cactus in the web site TODO list for version
1.1
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 7 May 2001, Vincent Massol wrote:
> I have changed J2EEUnit to Cactus in the CVS xml file but have not published
> it on the web site. As I don't want to break something, can someone who has
> had experience with publishing the struts web site please update the TODO
> page.
>
> Thanks.
> Vincent.
>
>
Guess I should document this process now ... :-)
Updating the Struts web site consists of:
- Download and build the latest Struts from CVS
- From your system, copy the struts-documentation.war file to daedalus:
scp struts-documentation.war \
xxxxx@daedalus.apache.org:/www/jakarta.apache.org/struts
- Log on to daedalus and unpack:
cd /www/jakarta.apache.org/struts
jar xvf struts-documentation.war
Vincent, you can go ahead and do this if everything is up to date, or I
can.
Craig
Change J2EEUnit to Cactus in the web site TODO list for version 1.1
Posted by Vincent Massol <vm...@octo.com>.
I have changed J2EEUnit to Cactus in the CVS xml file but have not published
it on the web site. As I don't want to break something, can someone who has
had experience with publishing the struts web site please update the TODO
page.
Thanks.
Vincent.
Re: Cactus suite of tests for Struts
Posted by "Craig R. McClanahan" <cr...@apache.org>.
+1. I like it!
After you're done, I want to declare a "Struts 1.0 beta 2" release,
because I've been knocking off a bunch of the Bugzilla bug reports, and
it is time to let the world know about the progress that has been made.
Craig
On Sat, 5 May 2001, Vincent Massol wrote:
> I have been working with David Winterfeldt on adding Cactus tests to Struts.
> The plan is to add all build-related stuff tomorrow (Sunday) in Struts CVS
> with a very simple test class. The second step will be to gather all
> available help to write some other unit tests and ensuring that all new
> submitted code has it's own test classes.
>
> Here is the directory structure proposal (I have put a + in front of new
> items and * in front of modified existing items) :
>
> jakarta-struts
> |_ * build.xml
> |_ + build-tests.xml
> |_ * build.properties.sample
> |_ conf
> |_ share
> |_ + test
> |_ + tomcat32
> |_ + server.xml
> |_ + tomcat40
> |_ + server.xml
> |_ + web.xml
> |_ + cactus.properties
> |_ src
> |_ share
> |_ [...]
> |_ + test
> |_ + org
> |_ + ... test classes
> |_ target (output directory)
> |_ library
> |_ [...]
> |_ + test
> |_ + classes
> |_ + servers
> |_ + tomcat32
> |_ + test.war
> |_ + conf
> |_ + server.xml
> |_ + webapps
> |_ + test
> |_ (see below for details)
> |_ + tomcat40
> |_ + test.war
> |_ + conf
> |_ + server.xml
> |_ + webapps
> |_ + test
> |_ (see below for details)
>
> The expanded test.war will contain :
>
> test
> |_ WEB-INF
> |_ classes
> |_ <test classes>
> |_ lib
> |_ struts.jar
> |_ junit.jar
> |_ commons-cactus.jar (the one for the correct servlet API)
> |_ web.xml
>
> Note: One option is to put the jars in lib/ in the global classpath of
> Tomcat so that they are shared by all webapps
>
> 3 new targets will be added to build.xml : test_all, test_tomcat_32 and
> test_tomcat40
>
> The structure will probably slightly change as we implement it.
>
> We will probably commit this around tomorrow night. So, if you have some
> questions/modifications to submit please do so ASAP ... :)
>
> Thanks
> Vincent.
>
>
Cactus suite of tests for Struts
Posted by Vincent Massol <vm...@octo.com>.
I have been working with David Winterfeldt on adding Cactus tests to Struts.
The plan is to add all build-related stuff tomorrow (Sunday) in Struts CVS
with a very simple test class. The second step will be to gather all
available help to write some other unit tests and ensuring that all new
submitted code has it's own test classes.
Here is the directory structure proposal (I have put a + in front of new
items and * in front of modified existing items) :
jakarta-struts
|_ * build.xml
|_ + build-tests.xml
|_ * build.properties.sample
|_ conf
|_ share
|_ + test
|_ + tomcat32
|_ + server.xml
|_ + tomcat40
|_ + server.xml
|_ + web.xml
|_ + cactus.properties
|_ src
|_ share
|_ [...]
|_ + test
|_ + org
|_ + ... test classes
|_ target (output directory)
|_ library
|_ [...]
|_ + test
|_ + classes
|_ + servers
|_ + tomcat32
|_ + test.war
|_ + conf
|_ + server.xml
|_ + webapps
|_ + test
|_ (see below for details)
|_ + tomcat40
|_ + test.war
|_ + conf
|_ + server.xml
|_ + webapps
|_ + test
|_ (see below for details)
The expanded test.war will contain :
test
|_ WEB-INF
|_ classes
|_ <test classes>
|_ lib
|_ struts.jar
|_ junit.jar
|_ commons-cactus.jar (the one for the correct servlet API)
|_ web.xml
Note: One option is to put the jars in lib/ in the global classpath of
Tomcat so that they are shared by all webapps
3 new targets will be added to build.xml : test_all, test_tomcat_32 and
test_tomcat40
The structure will probably slightly change as we implement it.
We will probably commit this around tomorrow night. So, if you have some
questions/modifications to submit please do so ASAP ... :)
Thanks
Vincent.
Re: J2EEUnit suite of tests for Struts
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Friday, April 06, 2001 8:34 PM
Subject: RE: J2EEUnit suite of tests for Struts
>
>
> On Thu, 5 Apr 2001, RPower wrote:
>
> > Hi,
> > I'm very keen to get involved with the J2EEUnit suite of tests for
Struts.
> > Is there any code available to play around with?
> > I've down loaded J2EEUnit 0.9 but haven't found any J2EEUnit specific
code
> > in the Struts/cvs repository?
> >
> > Any pointers would be much appreciated.
> >
>
> The J2EEUnit software itself is being contributed to the new "Jakarta
> Commons" project, because it's going to be useful for more than just
> Struts. For participating in the development of the test suite itself,
> you might want to subscribe to the jakarta-commons mailing list.
>
Great to hear someone is interested in participating ! :)
Welcome !
> You are correct in observing that we don't have any Struts-specific tests
> in the repository yet -- it would be great if you wanted to propose
> some. There was a discussion on STRUTS-DEV a few weeks ago about where in
> the directory structure these things should go -- you will want to review
> the list archives for the details.
>
Yes, that's my fault mainly. I'm late on my schedule. I am actually working
on the migration from J2EEUnit hosted on SourceForge to Jakarta Commons. I
hope to have finish sometime this week end or early next week ... :)
However, if you're willing to help, I can explain to you exactly where we
are and what you can do to help (Send me an email personally to
vmassol@octo.com).
> Craig
>
Thanks
Vincent
RE: J2EEUnit suite of tests for Struts
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 5 Apr 2001, RPower wrote:
> Hi,
> I'm very keen to get involved with the J2EEUnit suite of tests for Struts.
> Is there any code available to play around with?
> I've down loaded J2EEUnit 0.9 but haven't found any J2EEUnit specific code
> in the Struts/cvs repository?
>
> Any pointers would be much appreciated.
>
The J2EEUnit software itself is being contributed to the new "Jakarta
Commons" project, because it's going to be useful for more than just
Struts. For participating in the development of the test suite itself,
you might want to subscribe to the jakarta-commons mailing list.
You are correct in observing that we don't have any Struts-specific tests
in the repository yet -- it would be great if you wanted to propose
some. There was a discussion on STRUTS-DEV a few weeks ago about where in
the directory structure these things should go -- you will want to review
the list archives for the details.
Craig
>
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.fr]
> > Sent: 17 March 2001 21:56
> > To: struts-dev@jakarta.apache.org
> > Subject: J2EEUnit suite of tests for Struts
> >
> >
> > Just to let you know that I am currently working on integrating
> > the J2EEUnit
> > framework to provide a suite of unit tests for Struts. I am working on the
> > directory/build files (as dicussed in previous emails. Thread :
> > "[PROPOSAL]
> > Struts Source Directory Structure"). I'll try to post the changes on next
> > monday. It will contain some unit tests for ServletAction, then goal being
> > to do the integration and automatic testing using Ant. Then, once this is
> > done, all volunteers can participate to improve the suite of tests.
> >
> > Thanks.
> > Vincent Massol.
> >
>
>
RE: J2EEUnit suite of tests for Struts
Posted by RPower <RP...@spc75.demon.co.uk>.
Hi,
I'm very keen to get involved with the J2EEUnit suite of tests for Struts.
Is there any code available to play around with?
I've down loaded J2EEUnit 0.9 but haven't found any J2EEUnit specific code
in the Struts/cvs repository?
Any pointers would be much appreciated.
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.fr]
> Sent: 17 March 2001 21:56
> To: struts-dev@jakarta.apache.org
> Subject: J2EEUnit suite of tests for Struts
>
>
> Just to let you know that I am currently working on integrating
> the J2EEUnit
> framework to provide a suite of unit tests for Struts. I am working on the
> directory/build files (as dicussed in previous emails. Thread :
> "[PROPOSAL]
> Struts Source Directory Structure"). I'll try to post the changes on next
> monday. It will contain some unit tests for ServletAction, then goal being
> to do the integration and automatic testing using Ant. Then, once this is
> done, all volunteers can participate to improve the suite of tests.
>
> Thanks.
> Vincent Massol.
>
J2EEUnit suite of tests for Struts
Posted by Vincent Massol <vm...@octo.fr>.
Just to let you know that I am currently working on integrating the J2EEUnit
framework to provide a suite of unit tests for Struts. I am working on the
directory/build files (as dicussed in previous emails. Thread : "[PROPOSAL]
Struts Source Directory Structure"). I'll try to post the changes on next
monday. It will contain some unit tests for ServletAction, then goal being
to do the integration and automatic testing using Ant. Then, once this is
done, all volunteers can participate to improve the suite of tests.
Thanks.
Vincent Massol.
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
Hi,
I will do this shortly. However, I am right now wrapping version 0.8 of
J2EEUnit which adds new nice features that will help a lot testing Struts
(see the J2EEUnit changelog in CVS if you wish to know the list of changes
so far for version 0.8).
To tell the truth, I have looked at Struts ActionServlet class to see if
J2EEUnit 0.7 would be able to unit test it ... and found that it had some
shortcomings and that one would need to modify the ActionServlet code to be
able to unit test it ... which is of course not acceptable ... So, I found
solutions and added these in version 0.8 of J2EEUnit. I have also added
limited support for testing custom JSP tags but this is still beta (I am
still not sure if unit tests are relevant for tag libraries. It seems to me
that functional tests are much better suited for that) .
Action plan :
- Release version 0.8 I hope today (7/3) or tomorrow (8/3),
- Go on holiday (I'm leaving today for a week) ! I'll work on some Struts
unit tests during that time (I'll try to do a comprehensive test suite for
ActionServlet and some others). I won't have access to internet so I'll work
locally on my laptop
- On my return (14/03), I'll put in CVS my work and will work with Rob to
finalize the directory structure and Ant build script to run the tests for
several servlet engines
- Then it will be up to anyone to help write other test cases using the one
written as sample on how to do it.
How does that sound ?
Thanks a lot.
P.S.: Sorry for not doing this faster but I can only work during parts of
the weekends (the other part I have to devote to my wife and kids ... :) ).
However, I'll try my best not to slow you guys down :)
Best regards,
Vincent
----- Original Message -----
From: "RAP" <RA...@spc75.demon.co.uk>
To: <st...@jakarta.apache.org>
Sent: Tuesday, March 06, 2001 10:58 PM
Subject: RE: PROPOSAL - Testing Framework
> Hi Vincent,
>
> Any further news on Struts unit testing with J2EEUnit? Would you post a
> sample?
> I would like to see J2EEUnit in action testing the example that ships with
> Struts.
>
> Thanks for your time,
>
> RAP
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.fr]
> > Sent: 20 February 2001 09:45
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: PROPOSAL - Testing Framework
> >
> >
> > +1
> >
> > Great idea ! :)
> >
> > I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm
> > committed to help you implement this suite of tests. I have already been
> > implementing such a suite of tests for J2EEUnit itself and thus I
> > know very
> > well how to integrate it with Ant (actually I already have the build.xml
> > that starts J2EEUnit tests). I have successfully created a build.xml
file
> > that run the tests on several servlet engines : Tomcat 3.1.1,
> > Tomcat 3.2.1,
> > Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ...
> > That may be a
> > good idea for Struts to run its unit tests on several Servlet
> > engines. It is
> > very easy to do ! I also have an Ant task that let you start any servlet
> > engine in another thread, waits until it is finished starting and run
the
> > unit tests (it is still in CVS for the moment but I'll release a new 0.7
> > version this coming week end).
> >
> > Let me know where I can help. Also if you have any trouble to use
J2EEUnit
> > on any subject feel free to contact me and I'll help.
> > Thanks.
> >
> > Note: You should use the 0.7 version as much as possible as in
> > the previous
> > version it was not possible to test any method that wrote in the Servlet
> > output stream. It now works fine in version 0.7 (in CVS).
> >
> > Vincent Massol.
> >
> > ----- Original Message -----
> > From: "Rob Leland" <Ro...@freetocreate.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Monday, February 19, 2001 7:36 PM
> > Subject: PROPOSAL - Testing Framework
> >
> >
> > >
> > > I would like to add some additional Unit tests to the struts
> > > framework.
> > > These would be tests for struts itself, not end user code.
> > > My thoughts are that as struts evolves and new functionality
> > > is added we want to verify that other functionality is not
> > > broken, as code is changed and refactored.
> > >
> > > I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
> > > J2EEUnit (J2eeunit.sourceforge.org). I am going to force
> > > myself to do this in an upcoming project at work, and believe it
> > > makes sense to do it in struts also.
> > >
> > > I am targeting the 1.1 release time period. If Unit
> > > testing is approved, some small set of tests may make it into
> > > the struts 1.0 release, again assuming people here vote for its
> > > inclusion.
> > >
> > > My initial thoughts for providing testing is to start with the
> > > private methods of struts starting with the
> > > struts.action package,
> > > then later develop tests for the public methods of struts.action.
> > > I didn't want to start another package until I finished the majority
> > > of the private methods, only because I would need to debug
> > > my unit tests, and only by developing tests for some of the private
> > > methods the public could I do this.
> > >
> > >
> > > Then other packages would follow :
> > > struts.upload,
> > > struts.util,
> > > struts.digester,
> > > struts.actions,
> > > struts.taglib.X
> > >
> > > In about that order, only because that would be a usefull order for
me
> > > in the project I am working on. Infact, I only have plans to do
> > > struts.upload, and
> > > struts.util, and doubt I would have the time to produce tests for
the
> > > other packages.
> > >
> > >
> > > Thoughts ?
> > >
> > >
> > > -Rob
> > >
> > >
> >
>
>
>
RE: PROPOSAL - Testing Framework
Posted by RAP <RA...@spc75.demon.co.uk>.
Hi Vincent,
Any further news on Struts unit testing with J2EEUnit? Would you post a
sample?
I would like to see J2EEUnit in action testing the example that ships with
Struts.
Thanks for your time,
RAP
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.fr]
> Sent: 20 February 2001 09:45
> To: struts-dev@jakarta.apache.org
> Subject: Re: PROPOSAL - Testing Framework
>
>
> +1
>
> Great idea ! :)
>
> I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm
> committed to help you implement this suite of tests. I have already been
> implementing such a suite of tests for J2EEUnit itself and thus I
> know very
> well how to integrate it with Ant (actually I already have the build.xml
> that starts J2EEUnit tests). I have successfully created a build.xml file
> that run the tests on several servlet engines : Tomcat 3.1.1,
> Tomcat 3.2.1,
> Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ...
> That may be a
> good idea for Struts to run its unit tests on several Servlet
> engines. It is
> very easy to do ! I also have an Ant task that let you start any servlet
> engine in another thread, waits until it is finished starting and run the
> unit tests (it is still in CVS for the moment but I'll release a new 0.7
> version this coming week end).
>
> Let me know where I can help. Also if you have any trouble to use J2EEUnit
> on any subject feel free to contact me and I'll help.
> Thanks.
>
> Note: You should use the 0.7 version as much as possible as in
> the previous
> version it was not possible to test any method that wrote in the Servlet
> output stream. It now works fine in version 0.7 (in CVS).
>
> Vincent Massol.
>
> ----- Original Message -----
> From: "Rob Leland" <Ro...@freetocreate.org>
> To: <st...@jakarta.apache.org>
> Sent: Monday, February 19, 2001 7:36 PM
> Subject: PROPOSAL - Testing Framework
>
>
> >
> > I would like to add some additional Unit tests to the struts
> > framework.
> > These would be tests for struts itself, not end user code.
> > My thoughts are that as struts evolves and new functionality
> > is added we want to verify that other functionality is not
> > broken, as code is changed and refactored.
> >
> > I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
> > J2EEUnit (J2eeunit.sourceforge.org). I am going to force
> > myself to do this in an upcoming project at work, and believe it
> > makes sense to do it in struts also.
> >
> > I am targeting the 1.1 release time period. If Unit
> > testing is approved, some small set of tests may make it into
> > the struts 1.0 release, again assuming people here vote for its
> > inclusion.
> >
> > My initial thoughts for providing testing is to start with the
> > private methods of struts starting with the
> > struts.action package,
> > then later develop tests for the public methods of struts.action.
> > I didn't want to start another package until I finished the majority
> > of the private methods, only because I would need to debug
> > my unit tests, and only by developing tests for some of the private
> > methods the public could I do this.
> >
> >
> > Then other packages would follow :
> > struts.upload,
> > struts.util,
> > struts.digester,
> > struts.actions,
> > struts.taglib.X
> >
> > In about that order, only because that would be a usefull order for me
> > in the project I am working on. Infact, I only have plans to do
> > struts.upload, and
> > struts.util, and doubt I would have the time to produce tests for the
> > other packages.
> >
> >
> > Thoughts ?
> >
> >
> > -Rob
> >
> >
>
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
+1
Great idea ! :)
I am the author of J2EEUnit (http://j2eeunit.sourceforge.net) and I'm
committed to help you implement this suite of tests. I have already been
implementing such a suite of tests for J2EEUnit itself and thus I know very
well how to integrate it with Ant (actually I already have the build.xml
that starts J2EEUnit tests). I have successfully created a build.xml file
that run the tests on several servlet engines : Tomcat 3.1.1, Tomcat 3.2.1,
Tomcat 4.0, Resin 1.2, Resin 1.3, Orion 1.4, WebLogic 5.1 ... That may be a
good idea for Struts to run its unit tests on several Servlet engines. It is
very easy to do ! I also have an Ant task that let you start any servlet
engine in another thread, waits until it is finished starting and run the
unit tests (it is still in CVS for the moment but I'll release a new 0.7
version this coming week end).
Let me know where I can help. Also if you have any trouble to use J2EEUnit
on any subject feel free to contact me and I'll help.
Thanks.
Note: You should use the 0.7 version as much as possible as in the previous
version it was not possible to test any method that wrote in the Servlet
output stream. It now works fine in version 0.7 (in CVS).
Vincent Massol.
----- Original Message -----
From: "Rob Leland" <Ro...@freetocreate.org>
To: <st...@jakarta.apache.org>
Sent: Monday, February 19, 2001 7:36 PM
Subject: PROPOSAL - Testing Framework
>
> I would like to add some additional Unit tests to the struts
> framework.
> These would be tests for struts itself, not end user code.
> My thoughts are that as struts evolves and new functionality
> is added we want to verify that other functionality is not
> broken, as code is changed and refactored.
>
> I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
> J2EEUnit (J2eeunit.sourceforge.org). I am going to force
> myself to do this in an upcoming project at work, and believe it
> makes sense to do it in struts also.
>
> I am targeting the 1.1 release time period. If Unit
> testing is approved, some small set of tests may make it into
> the struts 1.0 release, again assuming people here vote for its
> inclusion.
>
> My initial thoughts for providing testing is to start with the
> private methods of struts starting with the
> struts.action package,
> then later develop tests for the public methods of struts.action.
> I didn't want to start another package until I finished the majority
> of the private methods, only because I would need to debug
> my unit tests, and only by developing tests for some of the private
> methods the public could I do this.
>
>
> Then other packages would follow :
> struts.upload,
> struts.util,
> struts.digester,
> struts.actions,
> struts.taglib.X
>
> In about that order, only because that would be a usefull order for me
> in the project I am working on. Infact, I only have plans to do
> struts.upload, and
> struts.util, and doubt I would have the time to produce tests for the
> other packages.
>
>
> Thoughts ?
>
>
> -Rob
>
>
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
Give me until tomorrow and I'll come up with a structure, organization, and
some tests proposals ... :)
Thanks.
Vincent.
----- Original Message -----
From: "Rob Leland" <Ro...@freetocreate.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, February 22, 2001 9:47 PM
Subject: Re: PROPOSAL - Testing Framework
>
>
> "Craig R. McClanahan" wrote:
> > Rob Leland has volunteered to take the lead on this, but I don't know if
> > anything specific has happened yet.
>
>
> Not only am I willing to Lead but to follow, since Vince obviously
> has MUCH more experience with J2EEUnit testing than me.
> I have a handle on JUnit, but not J2EEUnit , ... Yet :).
>
> Nothing has been put in place, I have started looking at the action
> classes had hoped to get a few tests in by version 1.0, with the bulk
> of the tests for version 1.1.
>
>
> So Vince what would you propose for directory structures, organizing
> tests ?
> It looked like you had some good suggestions yesterday.
>
> -Rob
>
>
Re: PROPOSAL - Testing Framework
Posted by Rob Leland <Ro...@freetocreate.org>.
"Craig R. McClanahan" wrote:
> Rob Leland has volunteered to take the lead on this, but I don't know if
> anything specific has happened yet.
Not only am I willing to Lead but to follow, since Vince obviously
has MUCH more experience with J2EEUnit testing than me.
I have a handle on JUnit, but not J2EEUnit , ... Yet :).
Nothing has been put in place, I have started looking at the action
classes had hoped to get a few tests in by version 1.0, with the bulk
of the tests for version 1.1.
So Vince what would you propose for directory structures, organizing
tests ?
It looked like you had some good suggestions yesterday.
-Rob
PROPOSAL loosely coupled events execution and personalization.
Posted by Mike Oliver <mi...@MorningStarSystems.com>.
We are incorporating Struts into our product plans because the MVC design
pattern and use of servlets and JSP are so similar to what we were already
designing that it would be foolish to re-invent the wheel.
However our requirements exceed the Struts requirements in the area of the
ActionServlet controller and we will be designing our own to add an
eventsDispatcher and a personalization Subsystem which we need for our
Collaborative Knowledge Management System (our product).
We would be willing to open source our more complex CKMActionServlet
subclass and donate it to the Struts project, how do we do that? Also
what do we need to do to use the "Powered by Struts" logo?
Michael Oliver
Chief Architect
MorningStar Systems, Inc.
7391 S. Bullrider Ave.
Tucson, AZ 85747
520.574.1150 Voice
520.447.2736 Fax
443.277.0629 Mobile
Plaatsen ter Software Ontwikkeling
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Vincent Massol wrote:
> Hi,
>
> Do you know who is deciding what tool will be used to build that struts test
> suite ? I am very eager to use J2EEUnit of course ... ! Has anyone begun
> implementing that test suite already ? Or do we have to wait for someone to
> say ok. Has there been a vote yet ? How can I help ? Is the decision taken
> on the tool ? How can I help ? Is the decision linked to the ongoing
> discussion on the library-dev mailing list ?
>
Rob Leland has volunteered to take the lead on this, but I don't know if
anything specific has happened yet.
I'm personally in favor of using J2EEUnit (and JUnit, as appropriate) for Struts
unit tests. Waiting for the shared infrastructure discussions to complete would
needlessly slow us down, although it is likely we will need to adapt to whatever
comes out of that effort (including the migration of a few pieces of Struts
technology that are easily shareable into the shared library environment
instead).
For those of us not as familiar with testing frameworks, it would be helpful to
describe how adding the test suite might affect the organization of the Struts
source code, what kinds of tests you feel we should start with, and how they
would be run. Then, it's just a matter of getting started. (Once you've got
some code ready to contribute, I can check it in ... but from there on it's best
to nominate those writing tests as committers so they can update the code base
directly.)
Although Struts features for 1.0 are frozen (I just licked the last bug reported
in the bug tracking system, so the beta will be cut today :-), I would very much
like to have at least an initial testing infrastructure and some basic tests
implemented in time for the final release.
>
> So many questions ....
> Thanks.
>
> Vincent Massol
> (Author of J2EEUnit)
Craig
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
Hi,
Do you know who is deciding what tool will be used to build that struts test
suite ? I am very eager to use J2EEUnit of course ... ! Has anyone begun
implementing that test suite already ? Or do we have to wait for someone to
say ok. Has there been a vote yet ? How can I help ? Is the decision taken
on the tool ? How can I help ? Is the decision linked to the ongoing
discussion on the library-dev mailing list ?
So many questions ....
Thanks.
Vincent Massol
(Author of J2EEUnit)
PROPOSAL - Testing Framework
Posted by Rob Leland <Ro...@freetocreate.org>.
I would like to add some additional Unit tests to the struts
framework.
These would be tests for struts itself, not end user code.
My thoughts are that as struts evolves and new functionality
is added we want to verify that other functionality is not
broken, as code is changed and refactored.
I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and
J2EEUnit (J2eeunit.sourceforge.org). I am going to force
myself to do this in an upcoming project at work, and believe it
makes sense to do it in struts also.
I am targeting the 1.1 release time period. If Unit
testing is approved, some small set of tests may make it into
the struts 1.0 release, again assuming people here vote for its
inclusion.
My initial thoughts for providing testing is to start with the
private methods of struts starting with the
struts.action package,
then later develop tests for the public methods of struts.action.
I didn't want to start another package until I finished the majority
of the private methods, only because I would need to debug
my unit tests, and only by developing tests for some of the private
methods the public could I do this.
Then other packages would follow :
struts.upload,
struts.util,
struts.digester,
struts.actions,
struts.taglib.X
In about that order, only because that would be a usefull order for me
in the project I am working on. Infact, I only have plans to do
struts.upload, and
struts.util, and doubt I would have the time to produce tests for the
other packages.
Thoughts ?
-Rob