Re: [Shale] subview component XML composition extension

[Matthias Wessendorf]

David,

No, I don't have anything JSF-specific. The extracted version is simply 
decoupled from Struts. Otherwise, it's just vanilla Tiles, except that I 
So you have no facility like a ViewHandler or something like that?
Have you looked at MyFaces' TilesViewHandler ?
-Matthias
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts-EL tags

[Nicolas De Loof]

Struts-el allow you to get a "preview" of struts tags used on a servlet 
2.4 container (that handle EL itself)
Using Struts-el will make the migration from servlet 2.3 to 2.4 easier 
(just update taglib URI).

EL adds also power to tags and JSP can skip scriptlets. JSP code looks 
more XML compliant (easier to read and maintain)

Nico.

Rajaneesh a écrit :
Hi,
 Is there any site that gives me the advantages and disadvantages of going
for Struts-EL taglibraries.
Regards
Rajaneesh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

This message contains information that may be privileged or confidential 
and is the property of the Capgemini Group. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient,  you are not 
authorized to read, print, retain, copy, disseminate,  distribute, or use this 
message or any part thereof. If you receive this  message in error, please 
notify the sender immediately and delete all  copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Rob Leland]

Joe Germuska wrote:
I wrote:
Yes... I'm sorry that that discussion has stalled.  Although I don't 
even know if that's an incremental step towards a POJO action -- it's 
practically all you need, plus a little more smarts in the 
CreateAction command.  I'll go post a ping.

OK, so I actually started looking at using POJOs for Actions, and it's 
a bit trickier than I'd thought, but I may want to use it on a current 
project, so if people want to talk about it, there's a chance I'll get 
it into Struts 1.3 sooner than later...

Sorry for Chiming in on this late.
In our web application which we inherited from another company they used 
nakedobjects(Google it) to create a generic framework that supposedly 
isolates the business objects  from both the upper and lower tear, which 
is only one small part of nakedobjects capabilities.

In theory it sounds like a silver bullet, but in our real working system 
it has been a real headache in maintaining and tracking down bugs (Like 
data loss under load) since it does allot of work under the covers.

The original developers of the web app I am told contributed heavily to 
the nakedobjects code base so they should have know how to use the 
library, assuming it was the right pattern at the right time.


The original developers of the web app also rolled their own supposedly 
MVC framework, workflow system, and XML parser. It is the most tightly 
coupled/fragile system I have worked with. The saying 'Too smart by 
half' really applies there.

I really miss Struts.


My point is if new approach is taken towards Actions that it should be 
easily understood by reading code, easy to debug, and easy to maintain 
for the users of the Framework.




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

Struts/HTTPS

[Rajaneesh]

Hi,

  Would there be any problem in using struts for HTTPS web application?


Regards
Rajaneesh

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

Re: Nightly builds

[James Mitchell]

Ok, I've modified the way I put together the (Mavenized) nightlies and 
tested the "remove after 7 days" piece.  Seems to be working fine, but I 
won't know for sure for another week.

I've included the current copy of the shell script that I run 
("maven-nightly.sh.current"), for when this gets moved onto Apache hardware.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "James Mitchell" <[EMAIL PROTECTED]>
To: "MyFaces Development" ; 
<[EMAIL PROTECTED]>
Cc: "Struts Developers List" 
Sent: Tuesday, March 15, 2005 2:44 PM
Subject: Re: Nightly builds


The only problem I am having with removing old files is that I don't put 
everything in one folder.  I have the nightlies tucked under a folder with 
the date (yyy-mm-dd) as the name.  I have struggled for the past week or 
so trying to figure out a way to "rm -fr" the old directories based on the 
formatted dateto no avail.

So, I have restructured where I put the nightly artifacts to be more 
inline with what Craig's nightly build does.  I'll send out a note later 
about the change.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "Craig McClanahan" <[EMAIL PROTECTED]>
To: "MyFaces Development" ; "Sean 
Schofield" <[EMAIL PROTECTED]>
Sent: Monday, March 14, 2005 5:01 PM
Subject: Re: Nightly builds


On Mon, 14 Mar 2005 16:55:57 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
That was the plan.  Do you mind if I take a look at your script (your
chron script, not your maven one.)?  Also, how do you handle the file
"rotation" issue?
For the nightly builds that I publish (Jakarta Commons, old-style
Struts ones that will likely go away), I have a cron job set up in my
home directory on the server to do the cleanups.  An example line (for
the Commons nightly builds) is:
03 04 * * * find /www/cvs.apache.org/builds/jakarta-commons/nightly
-mtime +7 -exec rm \{\} \; >/dev/null 2>&1
which runs every night and cleans out files older than seven days.
That can be set up for whomever is actually going to do the uploads.
Craig
PS to James:  we'll want this enabled on your Maven-based nightlies as
well, to avoid issues of undue disk consumption here.


sean
On Mon, 14 Mar 2005 16:47:56 -0500, James Mitchell 
<[EMAIL PROTECTED]> wrote:
> Why don't you just publish the nightlies to a known location
>
> (for example)
>
>  /www/incubator.apache.org/myfaces/nightlies
>
> I am currently building a set of nightlies for Struts (via Maven 
> instead of
> Ant).
> My script does a refresh from svn, then build, then scp (which pushes 
> them
> out to):
>
>  /www/cvs.apache.org/builds/struts/maven/dist/
>
>  http://svn.apache.org/builds/struts/maven/dist/
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> - Original Message -
> From: "Sean Schofield" <[EMAIL PROTECTED]>
> To: "MyFaces Development" 
> Sent: Monday, March 14, 2005 3:50 PM
> Subject: Nightly builds
>
> > Martin (Cooper),
> >
> > Have we made any progress on finding a build machine?  As we 
> > approach
> > release time I think it would be good for us to have nightlies.  The
> > Gump folks were unresponsive to my inquiries into using their 
> > machine.
> >
> > I'm going to suggest that we use Martin C's server to perform the
> > nightly builds in the meantime.  This way we can test the release
> > script, etc. and everyone can be working off the same nightly build
> > when testing before release time.
> >
> > My proposal is to host the bootstrap.xml build on Martin's server. 
> > (I
> > know this is not an ASF machine but we use his server for other 
> > things
> > already.)  We can push the nightlies up to CVS using scp (same as 
> > how
> > Struts does it).  We can then alert the infra people and have them
> > tweak their chron job (if necessary) that removes the files older 
> > than
> > five days.
> >
> > Martin M., can you test the latest bootstrap.xml I sent to the list 
> > a
> > few days ago?  I just want to make sure that it works on another
> > machine.
> >
> > Regards,
> > sean
> >
>
>



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


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

svn commit: r157706 - struts/build/trunk/maven-nightly.sh.current

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 22:32:29 2005
New Revision: 157706

URL: http://svn.apache.org/viewcvs?view=rev&rev=157706
Log:
This is the current nightly build script that builds and uploads the Mavenized 
nightlies

Added:
struts/build/trunk/maven-nightly.sh.current   (with props)

Added: struts/build/trunk/maven-nightly.sh.current
URL: 
http://svn.apache.org/viewcvs/struts/build/trunk/maven-nightly.sh.current?view=auto&rev=157706
==
--- struts/build/trunk/maven-nightly.sh.current (added)
+++ struts/build/trunk/maven-nightly.sh.current Tue Mar 15 22:32:29 2005
@@ -0,0 +1,20 @@
+#!/bin/sh
+# 
+# This bash shell script executes the necessary commands to 
+# build a nightly distribution and publish it to the Apache hardware.
+# 
+
+TODAY=`date +%Y%m%d`
+
+cd ../
+svn up > build/nightly/logs/svn-update-$TODAY.log
+cd build
+maven nightly > nightly/logs/maven-build-$TODAY.log
+
+scp -r nightly cvs.apache.org:/www/cvs.apache.org/builds/struts/maven/
+
+ssh cvs.apache.org find /www/cvs.apache.org/builds/struts/maven/nightly -mtime 
+7 -exec rm -fr {} \;
+
+
+
+

Propchange: struts/build/trunk/maven-nightly.sh.current
--
svn:executable = *



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

Struts-EL tags

[Rajaneesh]

Hi,

  Is there any site that gives me the advantages and disadvantages of going
for Struts-EL taglibraries.

Regards
Rajaneesh


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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Niall Pemberton]

I've looked at 1.3 and the Chain stuff, but not actually tried it out.
However the original RequestProcessor is still there and presumably still
works. The default RequestProcessor is now  the chain
ComposableRequestProcessor, so to use the original one would have to be
configured. No one (to my knowledge) has said it should be removed, so
theres nothing to stop it being maintained/enhanced and if Struts continues
to ship with both no need (IMO) for a fork. Having said that if
ComposbaleRequestProcessor does eveything the original one does and is
backwardly compatible then there probably won't be much motivation to
continue developing it.

Niall

- Original Message - 
From: "Dakota Jack" <[EMAIL PROTECTED]>
Sent: Wednesday, March 16, 2005 5:52 AM

> I do hope that if Struts v1.3 begins to tie more than the composable
> request processor to this Command/Chain business that a fork is
> allowed in Struts v1.2.  Once the problems with the Command/Chain idea
> begin to cause "hacks" that then enslave the framework to the
> Command/Chain pattern, things will become frozen rather than fluid, in
> my opinion.
>
>
> Jack



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

svn commit: r157699 - struts/apps/trunk/maven.xml

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 22:02:46 2005
New Revision: 157699

URL: http://svn.apache.org/viewcvs?view=rev&rev=157699
Log:
add a hack for overriding the copy-distribution goal since the Maven reactor 
won't allow multiple excludes (or I haven't figured out how ;)

Modified:
struts/apps/trunk/maven.xml

Modified: struts/apps/trunk/maven.xml
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/maven.xml?view=diff&r1=157698&r2=157699
==
--- struts/apps/trunk/maven.xml (original)
+++ struts/apps/trunk/maven.xml Tue Mar 15 22:02:46 2005
@@ -84,4 +84,8 @@
  


+   
+  
+   
+   
 



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

svn commit: r157697 - in struts/build/trunk: maven.xml project.xml

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 22:01:15 2005
New Revision: 157697

URL: http://svn.apache.org/viewcvs?view=rev&rev=157697
Log:
fix shared build so that nightlies are copied correctly

Modified:
struts/build/trunk/maven.xml
struts/build/trunk/project.xml

Modified: struts/build/trunk/maven.xml
URL: 
http://svn.apache.org/viewcvs/struts/build/trunk/maven.xml?view=diff&r1=157696&r2=157697
==
--- struts/build/trunk/maven.xml (original)
+++ struts/build/trunk/maven.xml Tue Mar 15 22:01:15 2005
@@ -6,31 +6,33 @@
 xmlns:maven="jelly:maven">
 

-   
+   

 

  
  
+ 
+ 
 
- 
+ 



  
-
- 
+ 
+ 



  
-
- 
+ 
+ 



  
-
+ 

 
 
@@ -67,7 +69,6 @@


 
-



@@ -81,33 +82,75 @@


 
-  
-
-
-  
-
-
-
-
-  
-
-
-
-
-  
-
-
-
-  
-
-  
+   
+   
+   
+   
+ 
+   
+   
+   
+   
+ 
+   
+
+   
+   
+ 
+   
+   
+   
+ 
+   
+   
+
+   
+
+   
+   
+   
 
-  
+   
+
+
+   
+
+   
+ 
+   
+ 
+   
+
+   
+ 
+   
+ 
+   
+
+   
+ 
+   
+ 
+   
+
+   
+ 
+   
+ 
+   
+
   
 
 

Modified: struts/build/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/struts/build/trunk/project.xml?view=diff&r1=157696&r2=157697
==
--- struts/build/trunk/project.xml (original)
+++ struts/build/trunk/project.xml Tue Mar 15 22:01:15 2005
@@ -270,7 +270,6 @@
   http://jakarta.apache.org/commons/beanutils/
   
 true
-true
   
 
 
@@ -281,7 +280,6 @@
   http://jakarta.apache.org/commons/chain/
   
 true
-true
   
 
   
@@ -292,7 +290,6 @@
   http://jakarta.apache.org/commons/digester/
   
 true
-true
   
 
 
@@ -303,7 +300,6 @@
   http://jakarta.apache.org/commons/fileupload/
   
 true
-true
   
 
 
@@ -314,7 +310,6 @@
   http://jakarta.apache.org/commons/logging/
   
 true
-true
   
 
 
@@ -325,7 +320,6 @@
   http://jakarta.apache.org/commons/validator/
   
 true
-true
   
 
 
@@ -336,7 +330,6 @@
   http://jakarta.apache.org/oro/
   
 true
-true
   
 
 
@@ -367,16 +360,13 @@
   
 
   
-struts-dev@jakarta.apache.org
+[EMAIL PROTECTED]
 src/java
-
-
 src/test
-
-
+
 
   
-**/Test*
+**/Test*.java
   
   
 
@@ -395,8 +385,10 @@
 
   
 
+
 
 
+
+
   
 
   



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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Dakota Jack]

On Wed, 16 Mar 2005 04:59:47 -, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
> - Original Message -
> From: "Dakota Jack" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 16, 2005 4:22 AM
> 
> > The idea, I thought, was to use the Commands to supplant the
> > RequestProcessor with a composable request processor.  Some of the
> > present suggestions are so radical as to provide some question whether
> > Struts is going to be Struts.  This is especially so of the suggestion
> > that we tie the ActionForm and the Action together.
> 
> I wasn't suggesting that we do it, just make it possible/simple to re-wire
> struts in that way (for example)  or any other way.


I am not against being able to "rewire" at all.  But, if you tie the
Action to the ActionForm, this inhibits rather than allowing for
"rewiring".



> > Might as well just go to JSF and Shale?
> 
> Maybe ;-)  but I don't think its that radical, still would be request based
> web framework, rather than page/component based.


If you tie Actions and ActionForms together, you essentially have a
page-centric idea in mind, I think.  I would personally just say
"goodbye" at that stage.  Page-centric is good for those that are a
bit OOP challenged, but other than that there is not a lot going for
it that I can see.

 
> > The whole command structure, remember, is only because you adapted the
> > Template Method pattern for the parts of the composable request
> > processor requiring the Command/Chain pattern to fix its difficulties.
> >  To decide for that reason that the Command/Chain structure is some
> > pattern Valhalla is a serious error, in my opinion.
> 
> You may be right about this. Making life too flexible could be a support
> nightmare. Anyway I was just throwing an idea into the ring. Its probably
> too late now anway and on the basis that contributions count and my
> contribution to Struts 1.3 has been zero, I doubt this will fly.


I do hope that if Struts v1.3 begins to tie more than the composable
request processor to this Command/Chain business that a fork is
allowed in Struts v1.2.  Once the problems with the Command/Chain idea
begin to cause "hacks" that then enslave the framework to the
Command/Chain pattern, things will become frozen rather than fluid, in
my opinion.

Command/Chain is a nice pattern, but it is getting way too much press:
way more than its merits can support, I think.

Jack

-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Niall Pemberton]

- Original Message - 
From: "Martin Cooper" <[EMAIL PROTECTED]>
Sent: Wednesday, March 16, 2005 4:48 AM


> I'm not sure I see the reasoning / benefit of POJOs as Actions. The
> implication is that some method that wasn't designed to be invoked as
> a command / action can do something useful without knowing about the
> request, mapping, form bean, etc. (If it has to know about those
> things, then it might as well be a Command or an Action anyway. It's
> certainly not a POJO at that point.) That seems so unlikely as to be
> not worthwhile supporting.

I find that most of  what goes into my actions is simply wiring up and most
of those actions fit one of a limited number of templates. All thats needed
is the data from the form and a method in the model. I rarely interact
directly with the Request/Session (most of thats in some "standard" code)
and the flavours of forwards associated with mappings is limited - (e.g.
sucess or failure). One scenario would be to have an IoC container create a
POJO and inject whatever resources it needed, populate it from the form data
and execute a method. The only thing remaining is having a mechanism to
determine where to forward.

> Actually, this type of overloading already leads to hard-to-track-down
> problems in other parts of Struts. For example, we overload the 'path'
> attribute of s so that it can be a path or a tile. If, for
> some reason, your Tiles definitions don't get loaded at startup time,
> the first time Struts tries to use a  with a tile value, the
> user gets a weird error about illegal path syntax.
>
> In short, I'd discourage overloading attributes for multiple purposes,
> because it will make it hard to determine what goes wrong when there's
> a problem.

I agree this would be an issue, but could probably be resolved with better
error handling / diagnostics. Apparently Tapestry has customized digester to
report the position in a config file for an error - sounds like
errors/debugging is one of its strengths and maybe something we could
improve on.

> --
> Martin Cooper



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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Niall Pemberton]

- Original Message - 
From: "Dakota Jack" <[EMAIL PROTECTED]>
Sent: Wednesday, March 16, 2005 4:22 AM


> The idea, I thought, was to use the Commands to supplant the
> RequestProcessor with a composable request processor.  Some of the
> present suggestions are so radical as to provide some question whether
> Struts is going to be Struts.  This is especially so of the suggestion
> that we tie the ActionForm and the Action together.

I wasn't suggesting that we do it, just make it possible/simple to re-wire
struts in that way (for example)  or any other way.

> Might as well just go to JSF and Shale?

Maybe ;-)  but I don't think its that radical, still would be request based
web framework, rather than page/component based.

> If anything, I would tie the ActionForm and the Action less together.

> I don't care what you call an Action.  I do care if it handles the
> request and returns an ActionForward.  If you loose that, you loose
> Struts altogether in my opinion.

I agree, but handling this doesn't have to mean other scenarios can't be
easily handled.

> The whole command structure, remember, is only because you adapted the
> Template Method pattern for the parts of the composable request
> processor requiring the Command/Chain pattern to fix its difficulties.
>  To decide for that reason that the Command/Chain structure is some
> pattern Valhalla is a serious error, in my opinion.

You may be right about this. Making life too flexible could be a support
nightmare. Anyway I was just throwing an idea into the ring. Its probably
too late now anway and on the basis that contributions count and my
contribution to Struts 1.3 has been zero, I doubt this will fly.

Niall

> Jack



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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Martin Cooper]

On Tue, 15 Mar 2005 17:34:13 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> I wrote:
> >Yes... I'm sorry that that discussion has stalled.  Although I don't
> >even know if that's an incremental step towards a POJO action --
> >it's practically all you need, plus a little more smarts in the
> >CreateAction command.  I'll go post a ping.
> 
> OK, so I actually started looking at using POJOs for Actions, and
> it's a bit trickier than I'd thought, but I may want to use it on a
> current project, so if people want to talk about it, there's a chance
> I'll get it into Struts 1.3 sooner than later...

I'm not sure I see the reasoning / benefit of POJOs as Actions. The
implication is that some method that wasn't designed to be invoked as
a command / action can do something useful without knowing about the
request, mapping, form bean, etc. (If it has to know about those
things, then it might as well be a Command or an Action anyway. It's
certainly not a POJO at that point.) That seems so unlikely as to be
not worthwhile supporting.

> I like the general idea of saying that the "type" property can be an
> Action, a Command, or a pojo.  Perhaps there's no point in using
> Command when you can use a pojo too?

Actually, this type of overloading already leads to hard-to-track-down
problems in other parts of Struts. For example, we overload the 'path'
attribute of s so that it can be a path or a tile. If, for
some reason, your Tiles definitions don't get loaded at startup time,
the first time Struts tries to use a  with a tile value, the
user gets a weird error about illegal path syntax.

In short, I'd discourage overloading attributes for multiple purposes,
because it will make it hard to determine what goes wrong when there's
a problem.

--
Martin Cooper


> My thought is that CreateAction would just check the type instance
> and if it wasn't an instance of Action, it would wrap it in a new
> class, ActionWrapper, which would take an instance and a method and
> then do the invocation in its execute method.
> 
> Postulating something like ActionContextFactory.getCurrentInstance(),
> the ActionWrapper would look something like this:
> 
> public class ActionWrapper extends Action {
> public ActionWrapper(Object instance, String method) {
>this.instance = instance;
>this.method = method;
> }
> public ActionForward execute(m,f,r,r) {
>Object pojo = getInstance();
>// perform reflection and invocation
>return (ActionForward)
> ActionContextFactory.getCurrentInstance().getForwardConfig();
> }
> }
> 
> Does that seem like a workable approach?
> 
> Along the way I was also entertaining thoughts of getting
> ActionCommand in here, but then I kept thinking "why again didn't we
> change Action to have an 'execute(ActionContext)' method"?  But I
> guess if there's a way to execute POJOs then I have a ready way to
> get the current ActionContext, which is the real item of interest --
> especially if we are using a custom implementation of ActionContext
> with properties that reflect our application's request/session-scoped
> properties.
> 
> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

svn commit: r157663 - struts/taglib/trunk/src/conf/cactus-web.xml

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:25:46 2005
New Revision: 157663

URL: http://svn.apache.org/viewcvs?view=rev&rev=157663
Log:
add cactus-web.xml

Added:
struts/taglib/trunk/src/conf/cactus-web.xml   (with props)

Added: struts/taglib/trunk/src/conf/cactus-web.xml
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/conf/cactus-web.xml?view=auto&rev=157663
==
--- struts/taglib/trunk/src/conf/cactus-web.xml (added)
+++ struts/taglib/trunk/src/conf/cactus-web.xml Tue Mar 15 20:25:46 2005
@@ -0,0 +1,23 @@
+
+
+
+http://java.sun.com/dtd/web-app_2_3.dtd";>
+
+
+

Propchange: struts/taglib/trunk/src/conf/cactus-web.xml
--
svn:executable = *



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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Dakota Jack]

The idea, I thought, was to use the Commands to supplant the
RequestProcessor with a composable request processor.  Some of the
present suggestions are so radical as to provide some question whether
Struts is going to be Struts.  This is especially so of the suggestion
that we tie the ActionForm and the Action together.  Might as well
just go to JSF and Shale?

If anything, I would tie the ActionForm and the Action less together.

I don't care what you call an Action.  I do care if it handles the
request and returns an ActionForward.  If you loose that, you loose
Struts altogether in my opinion.

The whole command structure, remember, is only because you adapted the
Template Method pattern for the parts of the composable request
processor requiring the Command/Chain pattern to fix its difficulties.
 To decide for that reason that the Command/Chain structure is some
pattern Valhalla is a serious error, in my opinion.

Jack


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

svn commit: r157656 - struts/taglib/trunk/maven.xml

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:18:18 2005
New Revision: 157656

URL: http://svn.apache.org/viewcvs?view=rev&rev=157656
Log:
fix cactus config (see README.txt to get cactus to run)

Modified:
struts/taglib/trunk/maven.xml

Modified: struts/taglib/trunk/maven.xml
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/maven.xml?view=diff&r1=157655&r2=157656
==
--- struts/taglib/trunk/maven.xml (original)
+++ struts/taglib/trunk/maven.xml Tue Mar 15 20:18:18 2005
@@ -12,6 +12,11 @@
 
   
   
+
+  
+  
+  
+  
 
 
 
${systemScope.setProperty('javax.xml.transform.TransformerFactory','org.apache.xalan.processor.TransformerFactoryImpl')}
@@ -20,33 +25,14 @@
extension=".tld"
style="doc/stylesheets/tld.xsl"
includes="struts-*.xml"/>
-  
-
-
-
-
-  
-Copying files to ${webapp.root}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+   
+  
 
+   
+   
+   
+   
   
+
 
 



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

svn commit: r157653 - struts/taglib/trunk/project.xml

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:17:09 2005
New Revision: 157653

URL: http://svn.apache.org/viewcvs?view=rev&rev=157653
Log:
add necessary jars for cactus run

Modified:
struts/taglib/trunk/project.xml

Modified: struts/taglib/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/project.xml?view=diff&r1=157652&r2=157653
==
--- struts/taglib/trunk/project.xml (original)
+++ struts/taglib/trunk/project.xml Tue Mar 15 20:17:09 2005
@@ -56,23 +56,85 @@
  struts-core
  1.3.0-dev
  
-   true
+true
  
   http://struts.apache.org/

+   
+
+  strutstestcase
+  strutstestcase
+  2.1-1.1-2.3
+  
+true
+  
+
+
+
+
+  xdoclet
+  1.2
+
+
+
+  xdoclet
+  xdoclet-web-module
+  1.2
+  http://xdoclet.sf.net/
+
+
+
+  xdoclet
+  xdoclet-ejb-module
+  1.2
+  http://xdoclet.sf.net/
+
 
 
-  aspectj
-  aspectjrt
-  1.1.1
-  http://eclipse.org/aspectj/
+  xdoclet
+  xdoclet-apache-module
+  1.2
+  http://xdoclet.sf.net/
 
 
+
+  xdoclet
+  xjavadoc
+  1.0.2
+  http://xdoclet.sf.net/
+
+
+
+  xdoclet
+  maven-xdoclet-plugin
+  1.2
+  plugin
+  http://xdoclet.sf.net/
+ 
+
+
+   
+  httpunit
+  httpunit
+  1.5.4
+  
+true
+  
+
+
+
+  jtidy
+  jtidy
+  4aug2000r7-dev
+  
+true
+  
+
+
   
 
   
 
-src/java
 
   
 



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

svn commit: r157652 - struts/taglib/trunk/project.properties

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:16:10 2005
New Revision: 157652

URL: http://svn.apache.org/viewcvs?view=rev&rev=157652
Log:
add project.properties for cactus stuff

Added:
struts/taglib/trunk/project.properties   (with props)

Added: struts/taglib/trunk/project.properties
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/project.properties?view=auto&rev=157652
==
--- struts/taglib/trunk/project.properties (added)
+++ struts/taglib/trunk/project.properties Tue Mar 15 20:16:10 2005
@@ -0,0 +1,18 @@
+
+maven.xdoc.date=left
+maven.war.webapp.dir=${maven.build.dir}/xdoclet/webdoclet
+maven.xdoclet.webdoclet.0=true
+maven.xdoclet.webdoclet.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
+maven.xdoclet.webdoclet.0.mergeDir=src/conf/merge
+maven.xdoclet.webdoclet.strutsconfigxml.0=true
+maven.xdoclet.webdoclet.strutsconfigxml.0.validateXML=true
+maven.xdoclet.webdoclet.strutsconfigxml.0.Version=1.1
+maven.xdoclet.webdoclet.strutsconfigxml.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
+maven.xdoclet.webdoclet.strutsconfigxml.0.mergeDir=src/conf/merge
+maven.xdoclet.webdoclet.strutsvalidationxml.0=true
+maven.xdoclet.webdoclet.strutsvalidationxml.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
+maven.xdoclet.webdoclet.deploymentdescriptor.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
+maven.xdoclet.webdoclet.deploymentdescriptor.0.mergeDir=src/conf/merge
+
+
+cactus.src.mergewebxml = src/conf/cactus-web.xml

Propchange: struts/taglib/trunk/project.properties
--
svn:executable = *



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

svn commit: r157649 - struts/taglib/trunk/README.txt

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:12:47 2005
New Revision: 157649

URL: http://svn.apache.org/viewcvs?view=rev&rev=157649
Log:
add README.txt for running cactus

Added:
struts/taglib/trunk/README.txt   (with props)

Added: struts/taglib/trunk/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/README.txt?view=auto&rev=157649
==
--- struts/taglib/trunk/README.txt (added)
+++ struts/taglib/trunk/README.txt Tue Mar 15 20:12:47 2005
@@ -0,0 +1,20 @@
+
+To build and run the Cactus tests:
+
+   1.  Create a file called build.properties (or reuse the one you 
have) 
+   in the top level of Struts Taglibs.
+   
+   2.  Add a line (as shown below) that points to your local install of
+   any supported server.
+   
+   See http://jakarta.apache.org/cactus/integration/maven/ for more
+   details.
+   
+   build.properties
+   
+   cactus.home.tomcat5x = 
D:/home/jmitchell/apache_home/jakarta-tomcat-5.0.28
+
+
+   3.  Execute the following:  (this assumes you have Maven installed)
+   
+   $ maven cactus:test

Propchange: struts/taglib/trunk/README.txt
--
svn:executable = *



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

svn commit: r157648 - struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:08:32 2005
New Revision: 157648

URL: http://svn.apache.org/viewcvs?view=rev&rev=157648
Log:
fix taglib uri

Modified:

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestCookieTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestDefineTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestHeaderTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestMessageTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestMessageTag1.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestMessageTag2.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestMessageTag3.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestMessageTag4.jsp
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestPageTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestParameterTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestResourceTag.jsp
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestSizeTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestStrutsTag.jsp

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestWriteTag.jsp

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestCookieTag.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestCookieTag.jsp?view=diff&r1=157647&r2=157648
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestCookieTag.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestCookieTag.jsp 
Tue Mar 15 20:08:32 2005
@@ -1,6 +1,6 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
 
 
 

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestDefineTag.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestDefineTag.jsp?view=diff&r1=157647&r2=157648
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestDefineTag.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestDefineTag.jsp 
Tue Mar 15 20:08:32 2005
@@ -1,6 +1,6 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
 
 


Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestHeaderTag.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestHeaderTag.jsp?view=diff&r1=157647&r2=157648
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestHeaderTag.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestHeaderTag.jsp 
Tue Mar 15 20:08:32 2005
@@ -1,6 +1,6 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
 
 
 

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp?view=diff&r1=157647&r2=157648
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp 
Tue Mar 15 20:08:32 2005
@@ -1,8 +1,8 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <[EMAIL PROTECTED] import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
-<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http:

svn commit: r157647 [2/2] - struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html

[jmitchell]

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag1.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag1.jsp?view=diff&r1=157646&r2=157647
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag1.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag1.jsp 
Tue Mar 15 20:07:41 2005
@@ -1,8 +1,8 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <[EMAIL PROTECTED] import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
-<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-html"; prefix="html" %>
 
 


Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag2.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag2.jsp?view=diff&r1=157646&r2=157647
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag2.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestRadioTag2.jsp 
Tue Mar 15 20:07:41 2005
@@ -4,9 +4,9 @@
 <[EMAIL PROTECTED] import="org.apache.struts.action.ActionMessage"%>
 <[EMAIL PROTECTED] import="org.apache.struts.action.ActionMessages"%>
 
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
-<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-html"; prefix="html" %>
 
 
 

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag1.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag1.jsp?view=diff&r1=157646&r2=157647
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag1.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag1.jsp 
Tue Mar 15 20:07:41 2005
@@ -1,8 +1,8 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <[EMAIL PROTECTED] import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
-<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-html"; prefix="html" %>
 
 


Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag2.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag2.jsp?view=diff&r1=157646&r2=157647
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag2.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestResetTag2.jsp 
Tue Mar 15 20:07:41 2005
@@ -1,8 +1,8 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <[EMAIL PROTECTED] import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
-<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-html"; prefix="html" %>
 
 
 

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestSelectTag1.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestSelectTag1.jsp?view=diff&r1=157646&r2=157647
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestSelectTag1.jsp 
(original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/html/TestSelectTag1.jsp 
Tue Mar 15 20:07:41 2005
@@ -1,8 +1,8 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <[EMAIL PROTECTED] import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"

svn commit: r157642 - struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 20:04:44 2005
New Revision: 157642

URL: http://svn.apache.org/viewcvs?view=rev&rev=157642
Log:
fix taglib uri

Modified:

struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp

Modified: 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp?view=diff&r1=157641&r2=157642
==
--- 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp
 (original)
+++ 
struts/taglib/trunk/src/webapp/org/apache/struts/taglib/logic/TestIterateTag.jsp
 Tue Mar 15 20:04:44 2005
@@ -1,7 +1,7 @@
 <%@ page contentType="text/html;charset=UTF-8" language="java" %>
 <%@ page import="junit.framework.Assert"%>
-<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
-<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
+<%@ taglib uri="http://struts.apache.org/tags-logic"; prefix="logic" %>
+<%@ taglib uri="http://struts.apache.org/tags-bean"; prefix="bean" %>
 
 
   



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

svn commit: r157641 [2/2] - in struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib: bean/ html/

[jmitchell]

Modified: 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag5a.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag5a.java?view=diff&r1=157640&r2=157641
==
--- 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag5a.java
 (original)
+++ 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag5a.java
 Tue Mar 15 20:03:47 2005
@@ -67,7 +67,7 @@
 pageContext.setAttribute(Globals.LOCALE_KEY, new Locale(locale, 
locale), PageContext.SESSION_SCOPE);
 pageContext.setAttribute(Constants.BEAN_KEY, new 
SimpleBeanForTesting("Test Value"), PageContext.REQUEST_SCOPE);
 request.setAttribute("runTest", whichTest);
-
pageContext.forward("/test/org/apache/struts/taglib/html/TestImgTag5a.jsp");
+pageContext.forward("/org/apache/struts/taglib/html/TestImgTag5a.jsp");
 }
 
 /*

Modified: 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag6.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag6.java?view=diff&r1=157640&r2=157641
==
--- 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag6.java
 (original)
+++ 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag6.java
 Tue Mar 15 20:03:47 2005
@@ -66,7 +66,7 @@
 pageContext.setAttribute(Globals.LOCALE_KEY, new Locale(locale, 
locale), PageContext.SESSION_SCOPE);
 pageContext.setAttribute(Constants.BEAN_KEY, new 
SimpleBeanForTesting("Test Value"), PageContext.REQUEST_SCOPE);
 request.setAttribute("runTest", whichTest);
-
pageContext.forward("/test/org/apache/struts/taglib/html/TestImgTag6.jsp");
+pageContext.forward("/org/apache/struts/taglib/html/TestImgTag6.jsp");
 }
 
 /*

Modified: 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7.java?view=diff&r1=157640&r2=157641
==
--- 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7.java
 (original)
+++ 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7.java
 Tue Mar 15 20:03:47 2005
@@ -66,7 +66,7 @@
 pageContext.setAttribute(Globals.LOCALE_KEY, new Locale(locale, 
locale), PageContext.SESSION_SCOPE);
 pageContext.setAttribute(Constants.BEAN_KEY, new 
SimpleBeanForTesting("Test Value"), PageContext.REQUEST_SCOPE);
 request.setAttribute("runTest", whichTest);
-
pageContext.forward("/test/org/apache/struts/taglib/html/TestImgTag7.jsp");
+pageContext.forward("/org/apache/struts/taglib/html/TestImgTag7.jsp");
 }
 
 /*

Modified: 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7a.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7a.java?view=diff&r1=157640&r2=157641
==
--- 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7a.java
 (original)
+++ 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag7a.java
 Tue Mar 15 20:03:47 2005
@@ -67,7 +67,7 @@
 pageContext.setAttribute(Globals.LOCALE_KEY, new Locale(locale, 
locale), PageContext.SESSION_SCOPE);
 pageContext.setAttribute(Constants.BEAN_KEY, new 
SimpleBeanForTesting("Test Value"), PageContext.REQUEST_SCOPE);
 request.setAttribute("runTest", whichTest);
-
pageContext.forward("/test/org/apache/struts/taglib/html/TestImgTag7a.jsp");
+pageContext.forward("/org/apache/struts/taglib/html/TestImgTag7a.jsp");
 }
 
 /*

Modified: 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag8.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag8.java?view=diff&r1=157640&r2=157641
==
--- 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag8.java
 (original)
+++ 
struts/taglib/trunk/src/test-cactus/org/apache/struts/taglib/html/TestImgTag8.java
 Tue Mar 15 20:03:47 2005
@@ -66,7 +66,7 @@
 pageContext.setAttribute(Globals.LOCALE_KEY, new Locale(locale, 
locale), PageContext.SESSION_SCOPE);
 pageContext.setAttribute(Constants.BEAN_KEY, new 
SimpleBeanForTesting("Test Value"), PageContext.REQUEST_SCOPE);
 request.setAttribute("runTest", whichTest);
-
pageContext.forward("/test/org/apach

svn commit: r157637 - in struts/taglib/trunk/src/webapp: org/ test/test/org/

[jmitchell]

Author: jmitchell
Date: Tue Mar 15 19:50:09 2005
New Revision: 157637

URL: http://svn.apache.org/viewcvs?view=rev&rev=157637
Log:
remove useless nesting of JSPs

Added:
struts/taglib/trunk/src/webapp/org/
  - copied from r157626, struts/taglib/trunk/src/webapp/test/test/org/
Removed:
struts/taglib/trunk/src/webapp/test/test/org/


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

svn commit: r157634 - struts/core/trunk/src/share/org/apache/struts/chain/commands

[germuska]

Author: germuska
Date: Tue Mar 15 18:57:04 2005
New Revision: 157634

URL: http://svn.apache.org/viewcvs?view=rev&rev=157634
Log:
Introduce ActionCommand interface and ActionCommandBase class, and adapt all 
relevant command implementations to extend ActionCommandBase.

Added:

struts/core/trunk/src/share/org/apache/struts/chain/commands/ActionCommand.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/ActionCommandBase.java
Modified:

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractAuthorizeAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateActionForm.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractPerformForward.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractPerformInclude.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractPopulateActionForm.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractRequestNoCache.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectForward.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectInput.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectLocale.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectModule.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSetContentType.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractValidateActionForm.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/ExceptionCatcher.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/ExecuteCommand.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/SelectInclude.java

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractAuthorizeAction.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractAuthorizeAction.java?view=diff&r1=157633&r2=157634
==
--- 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractAuthorizeAction.java
 (original)
+++ 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractAuthorizeAction.java
 Tue Mar 15 18:57:04 2005
@@ -17,8 +17,6 @@
 package org.apache.struts.chain.commands;
 
 
-import org.apache.commons.chain.Command;
-import org.apache.commons.chain.Context;
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 import org.apache.struts.chain.contexts.ActionContext;
@@ -34,7 +32,7 @@
  * @version $Rev$ $Date$
  */
 
-public abstract class AbstractAuthorizeAction implements Command {
+public abstract class AbstractAuthorizeAction extends ActionCommandBase {
 
 
 // -- Instance 
Variables
@@ -55,9 +53,7 @@
  * @return false if the user is authorized for the selected
  * action, else true to abort processing.
  */
-public boolean execute(Context context) throws Exception {
-
-ActionContext actionCtx = (ActionContext) context;
+public boolean execute(ActionContext actionCtx) throws Exception {
 
 // Retrieve ActionConfig
 ActionConfig actionConfig = actionCtx.getActionConfig();

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateAction.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateAction.java?view=diff&r1=157633&r2=157634
==
--- 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateAction.java
 (original)
+++ 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractCreateAction.java
 Tue Mar 15 18:57:04 2005
@@ -17,8 +17,6 @@
 package org.apache.struts.chain.commands;
 
 
-import org.apache.commons.chain.Command;
-import org.apache.commons.chain.Context;
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 import org.apache.struts.action.Action;
@@ -34,7 +32,7 @@
  * @version $Rev$ $Date$
  */
 
-public abstract class AbstractCreateAction implements Command {
+public abstract class AbstractCreateAction extends ActionCommandBase {
 
 
 // -- Instance 
Variables
@@ -51,8 +49,7 @@
  *
  * @return false so that processing continues
  */
-p

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Niall Pemberton]

- Original Message - 
From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
Sent: Wednesday, March 16, 2005 1:52 AM


> I was one of the proponents of POJOs as Actions a week or so ago, but
> upon further reflection I have to ask the question... what does this
> really get anyone?  I'm not really sure I see the benefit to it any
> more.  In fact, it would seem that keeping Actions as Actions makes it a
> little safer in that you can be sure the class being called is actually
> an Action.

I think we should make Struts as flexible as possible so that its simple to
develop "a la Carte" Commands that can be plugged in to replace the default
behaviour. What about an implementation where you have a POJO that replaces
the ActionForm and Action? You get a new instance every time so its thread
safe, it gets populated with the form data and then *some" method on that
POJO gets executed. Whether this is a good idea or not, why put any more
constraints than necessary. IMO the only point we need to know its actually
an Action (or Command) is when the method is being invoked. Before that -
configuring, creating, storing in the Context it could be any object type.

> Also, it seems odd to be talking about Actions *or* Commands (or
> POJOs)... Making them Commands makes some sense to me, but it feels
> wrong to allow both.  I would personally say one or the other, with a
> lean towards Commands.

For the deafult behaviour, it would be simple to cater for both, without
having to wrap anything.

> Now, that of course raises compatibility issues, so talking about
> something like an ActionCommandWrapper that presents an Action like a
> Command makes sense to me.



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

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Frank W. Zammetti]

I was one of the proponents of POJOs as Actions a week or so ago, but 
upon further reflection I have to ask the question... what does this 
really get anyone?  I'm not really sure I see the benefit to it any 
more.  In fact, it would seem that keeping Actions as Actions makes it a 
little safer in that you can be sure the class being called is actually 
an Action.

Also, it seems odd to be talking about Actions *or* Commands (or 
POJOs)... Making them Commands makes some sense to me, but it feels 
wrong to allow both.  I would personally say one or the other, with a 
lean towards Commands.

Now, that of course raises compatibility issues, so talking about 
something like an ActionCommandWrapper that presents an Action like a 
Command makes sense to me.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Joe Germuska wrote:
I wrote:
Yes... I'm sorry that that discussion has stalled.  Although I don't 
even know if that's an incremental step towards a POJO action -- it's 
practically all you need, plus a little more smarts in the 
CreateAction command.  I'll go post a ping.

OK, so I actually started looking at using POJOs for Actions, and it's a 
bit trickier than I'd thought, but I may want to use it on a current 
project, so if people want to talk about it, there's a chance I'll get 
it into Struts 1.3 sooner than later...

I like the general idea of saying that the "type" property can be an 
Action, a Command, or a pojo.  Perhaps there's no point in using Command 
when you can use a pojo too?

My thought is that CreateAction would just check the type instance and 
if it wasn't an instance of Action, it would wrap it in a new class, 
ActionWrapper, which would take an instance and a method and then do the 
invocation in its execute method.

Postulating something like ActionContextFactory.getCurrentInstance(), 
the ActionWrapper would look something like this:

public class ActionWrapper extends Action {
public ActionWrapper(Object instance, String method) {
  this.instance = instance;
  this.method = method;
}
public ActionForward execute(m,f,r,r) {
  Object pojo = getInstance();
  // perform reflection and invocation
  return (ActionForward) 
ActionContextFactory.getCurrentInstance().getForwardConfig();
}
}

Does that seem like a workable approach?
Along the way I was also entertaining thoughts of getting ActionCommand 
in here, but then I kept thinking "why again didn't we change Action to 
have an 'execute(ActionContext)' method"?  But I guess if there's a way 
to execute POJOs then I have a ready way to get the current 
ActionContext, which is the real item of interest -- especially if we 
are using a custom implementation of ActionContext with properties that 
reflect our application's request/session-scoped properties.

Joe


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

POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

[Joe Germuska]

I wrote:
Yes... I'm sorry that that discussion has stalled.  Although I don't 
even know if that's an incremental step towards a POJO action -- 
it's practically all you need, plus a little more smarts in the 
CreateAction command.  I'll go post a ping.
OK, so I actually started looking at using POJOs for Actions, and 
it's a bit trickier than I'd thought, but I may want to use it on a 
current project, so if people want to talk about it, there's a chance 
I'll get it into Struts 1.3 sooner than later...

I like the general idea of saying that the "type" property can be an 
Action, a Command, or a pojo.  Perhaps there's no point in using 
Command when you can use a pojo too?

My thought is that CreateAction would just check the type instance 
and if it wasn't an instance of Action, it would wrap it in a new 
class, ActionWrapper, which would take an instance and a method and 
then do the invocation in its execute method.

Postulating something like ActionContextFactory.getCurrentInstance(), 
the ActionWrapper would look something like this:

public class ActionWrapper extends Action {
public ActionWrapper(Object instance, String method) {
  this.instance = instance;
  this.method = method;
}
public ActionForward execute(m,f,r,r) {
  Object pojo = getInstance();
  // perform reflection and invocation
  return (ActionForward) 
ActionContextFactory.getCurrentInstance().getForwardConfig();
}
}

Does that seem like a workable approach?
Along the way I was also entertaining thoughts of getting 
ActionCommand in here, but then I kept thinking "why again didn't we 
change Action to have an 'execute(ActionContext)' method"?  But I 
guess if there's a way to execute POJOs then I have a ready way to 
get the current ActionContext, which is the real item of interest -- 
especially if we are using a custom implementation of ActionContext 
with properties that reflect our application's request/session-scoped 
properties.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

DO NOT REPLY [Bug 34027] - org.apache.struts.taglib.FormTag.java does not render XHTML-Strict valid output when in XHTML mode

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34027





--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 00:17 ---
Created an attachment (id=14494)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14494&action=view)
Prevents the name attribute of a form tag from being render when in an XHTML
rendering mode

Patches FormTag to conditionally output the name attribute only when not in
XHTML rendering mode, as determined by FormTag.isXHTML().

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 34027] New: - org.apache.struts.taglib.FormTag.java does not render XHTML-Strict valid output when in XHTML mode

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34027

   Summary: org.apache.struts.taglib.FormTag.java does not render
XHTML-Strict valid output when in XHTML mode
   Product: Struts
   Version: 1.2.6 Beta
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Custom Tags
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


FormTag.renderFormStartElement does not check isXhtml() before outputting a 
'name' attribute, which 
is not a valid tag in XHTML-Strict.

Patch:

--- FormTag.java.orig2005-03-15 17:39:55.246044246 -0500
+++ FormTag.java2005-03-15 17:41:04.177935225 -0500
@@ -475,7 +475,9 @@
 StringBuffer results = new StringBuffer("http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Best Way to use Custom ActionContext/Storing ActionContext in ThreadLocal

[Joe Germuska]

Trying to unify these two threads:
"How to provide custom impl of ActionContext" 
http://thread.gmane.org/gmane.comp.jakarta.struts.devel/25876

"Storing current ActionContext in ThreadLocal" 
http://thread.gmane.org/gmane.comp.jakarta.struts.devel/25868

It would be great to get some ideas from people about the right way 
to allow users to use an alternate implementation of the 
ActionContext class.  I am generally ill-disposed to a factory class 
since it seems like so often factories also need configuration which 
makes discovery tedious, but having a factory class which was an 
Abstract class would also give us a convenient place to plug a static 
"currentActionContext" method.

If no configuration is necessary, we could simply stipulate 
"actionContextFactoryClass" as a String Property of ControllerConfig 
and at least move forward with that.  To be honest, for this specific 
case I'm not thinking of any configuration use cases, so maybe I 
shouldn't get hung up on it.

(Defining implementation classes and configuring them all in one 
place is the solution that Spring provides which I think makes so 
many people get so gung-ho about it.)

I think in writing this I've convinced myself to do it this way. 
Will give it a little time for responses but I'm likely to try to do 
this in the next couple of days.

Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Configuration inheritance, module init code

[Joe Germuska]

At 1:16 PM -0600 3/15/05, Hubert Rabago wrote:
On Tue, 15 Mar 2005 11:23:09 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
 >Joe had mentioned wanting to move module init code to the
 > >ModuleConfigFactory.
...
It wasn't really discussed, just mentioned.  :)  The point was to move
the code out of ActionServlet more than to move it into
ModuleConfigFactory.
http://marc.theaimsgroup.com/?l=struts-dev&m=110908681127847&w=2
I wrote:
From a purely conceptual standpoint, I almost
think that everything inside initModuleConfig() should be moved into
the ModuleConfigFactory.
in the sense that modules are useless as pure beans, so both 
instantiation and configuration should be the responsibility of the 
factory.

 >From a Struts perspective, this would be like writing an Action class
and specifying in struts-config whether that Action class supports
servlets, web services, JMS, or all of them or any combination of
these and others.  A protocol-specific object would accept requests,
populate the ActionContext, then send it to a module's
RequestProcessor for processing.  After the request is processed, the
RP sends it back to the protocol-specific object to send back the
response in an appropriate way.
Or did I just venture too far from what you were trying to picture?
I think this is a good description of a general use 
case/"to-be-desired" scenario for Struts.  As it is now, the chain 
commands themselves are too dependent on the Servlet API, and 
consideration of the case you describe might help think of solutions 
to that.  As it is now, you'd really need an entirely different chain 
if you weren't using Servlet, because so many of the implementation 
classes are critically depending on the Servlet API.  This is 
pragmatic, but its something we should be consciously working on 
fixing.  But this is long term strategy.  (Referring back to 
our"project management" discussion, maybe we should come up with some 
simple searchable string that we could include in emails when we talk 
about "long term strategy" so that we can find them easily again ;-)

Well, moving what we can from ActionServlet to ModuleConfigFactory
doesn't really help testability that much right now.  It's just to
reduce the size of ActionServlet and move code that doesn't need to be
there.  It doesn't have to be the ModuleConfigFactory either, though
right now, that's the best fit.
No -- but getting to a scenario where you don't really need the 
ModuleConfig for many operations would help testability.  But if we 
also keep dependencies on the ModuleConfig itself to a minimum, 
preferring situations where elements from it are passed in as 
arguments,

This is how I felt about putting ActionContext in a ThreadLocal
variable -- an incremental steps towards POJO Actions.  :)
Yes... I'm sorry that that discussion has stalled.  Although I don't 
even know if that's an incremental step towards a POJO action -- it's 
practically all you need, plus a little more smarts in the 
CreateAction command.  I'll go post a ping.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: Nightly builds

[James Mitchell]

The only problem I am having with removing old files is that I don't put 
everything in one folder.  I have the nightlies tucked under a folder with 
the date (yyy-mm-dd) as the name.  I have struggled for the past week or so 
trying to figure out a way to "rm -fr" the old directories based on the 
formatted dateto no avail.

So, I have restructured where I put the nightly artifacts to be more inline 
with what Craig's nightly build does.  I'll send out a note later about the 
change.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "Craig McClanahan" <[EMAIL PROTECTED]>
To: "MyFaces Development" ; "Sean 
Schofield" <[EMAIL PROTECTED]>
Sent: Monday, March 14, 2005 5:01 PM
Subject: Re: Nightly builds


On Mon, 14 Mar 2005 16:55:57 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
That was the plan.  Do you mind if I take a look at your script (your
chron script, not your maven one.)?  Also, how do you handle the file
"rotation" issue?
For the nightly builds that I publish (Jakarta Commons, old-style
Struts ones that will likely go away), I have a cron job set up in my
home directory on the server to do the cleanups.  An example line (for
the Commons nightly builds) is:
03 04 * * * find /www/cvs.apache.org/builds/jakarta-commons/nightly
-mtime +7 -exec rm \{\} \; >/dev/null 2>&1
which runs every night and cleans out files older than seven days.
That can be set up for whomever is actually going to do the uploads.
Craig
PS to James:  we'll want this enabled on your Maven-based nightlies as
well, to avoid issues of undue disk consumption here.


sean
On Mon, 14 Mar 2005 16:47:56 -0500, James Mitchell <[EMAIL PROTECTED]> 
wrote:
> Why don't you just publish the nightlies to a known location
>
> (for example)
>
>  /www/incubator.apache.org/myfaces/nightlies
>
> I am currently building a set of nightlies for Struts (via Maven 
> instead of
> Ant).
> My script does a refresh from svn, then build, then scp (which pushes 
> them
> out to):
>
>  /www/cvs.apache.org/builds/struts/maven/dist/
>
>  http://svn.apache.org/builds/struts/maven/dist/
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> - Original Message -
> From: "Sean Schofield" <[EMAIL PROTECTED]>
> To: "MyFaces Development" 
> Sent: Monday, March 14, 2005 3:50 PM
> Subject: Nightly builds
>
> > Martin (Cooper),
> >
> > Have we made any progress on finding a build machine?  As we approach
> > release time I think it would be good for us to have nightlies.  The
> > Gump folks were unresponsive to my inquiries into using their 
> > machine.
> >
> > I'm going to suggest that we use Martin C's server to perform the
> > nightly builds in the meantime.  This way we can test the release
> > script, etc. and everyone can be working off the same nightly build
> > when testing before release time.
> >
> > My proposal is to host the bootstrap.xml build on Martin's server. 
> > (I
> > know this is not an ASF machine but we use his server for other 
> > things
> > already.)  We can push the nightlies up to CVS using scp (same as how
> > Struts does it).  We can then alert the infra people and have them
> > tweak their chron job (if necessary) that removes the files older 
> > than
> > five days.
> >
> > Martin M., can you test the latest bootstrap.xml I sent to the list a
> > few days ago?  I just want to make sure that it works on another
> > machine.
> >
> > Regards,
> > sean
> >
>
>



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

Re: Configuration inheritance, module init code

[Hubert Rabago]

On Tue, 15 Mar 2005 11:23:09 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> >Joe had mentioned wanting to move module init code to the
> >ModuleConfigFactory.
> 
> I did?  ;-)
> 
> Seriously, though, I don't quite remember the details of that
> discussion -- do you happen to have any pointers to the archives?
> 

It wasn't really discussed, just mentioned.  :)  The point was to move
the code out of ActionServlet more than to move it into
ModuleConfigFactory.
http://marc.theaimsgroup.com/?l=struts-dev&m=110908681127847&w=2


> I think in general, the idea is to make ActionServlet do little more
> than receive requests and broker them off, with the more general idea
> of making Struts clean of unnecessary dependencies on the Servlet
> API.  Thus, moving as much setup as possible out of there seems
> theoretically good, although I don't know if it needs to be the first
> step -- considering how Action and ActionForm have direct
> dependencies on that API, it may be a lot of ceremony for relatively
> little payoff.
> 

I agree with the idea.  In my work, there exists an SOA-like framework
and different teams have been using different ways to get to the
services.  Some used HTTP, some had custom protocols, some used JMS,
some used custom JMS frameworks.  Testing client apps was tricky, so I
came up with a mock framework where you could plug in a mock service
and configure how it would interface with clients - HTTP, JMS,
in-house protocols, etc.

>From a Struts perspective, this would be like writing an Action class
and specifying in struts-config whether that Action class supports
servlets, web services, JMS, or all of them or any combination of
these and others.  A protocol-specific object would accept requests,
populate the ActionContext, then send it to a module's
RequestProcessor for processing.  After the request is processed, the
RP sends it back to the protocol-specific object to send back the
response in an appropriate way.

Or did I just venture too far from what you were trying to picture?


> As a general strategy, I think stuff in ActionServlet now should move
> off to a "StrutsApplication" which would deal with bootstrapping and
> with assigning requests to modules for processing.  (As today, the
> per-module request processor would do the bulk of the work, referring
> to its own ModuleConfig for necessary information and resources.)
> 
> Was there some detail that I'm forgetting now which makes the factory
> the right place for it?  But assuming I was harping on the same old
> riffs, I was probably somehow trying to get at "reduce direct
> dependencies on Servlet API".
> 
> But most importantly, I think it would be best to get decent working
> code in place; we will be continually refactoring, so adding/changing
> stuff where it already is would be no great sin.  And if we don't
> have many use cases in mind for non-Servlet Struts usage, we may make
> some errors in generalizing certain things, so no need to rush.
> (Always remember, though, that unit testing is a non-Servlet Struts
> use case, so just thinking about how to make things more testable may
> help reach a good generalization.)
> 

Well, moving what we can from ActionServlet to ModuleConfigFactory
doesn't really help testability that much right now.  It's just to
reduce the size of ActionServlet and move code that doesn't need to be
there.  It doesn't have to be the ModuleConfigFactory either, though
right now, that's the best fit.


> On the other hand, if it seems easy and straightforward to make an
> incremental improvement as part of this process, great!
> 

This is how I felt about putting ActionContext in a ThreadLocal
variable -- an incremental steps towards POJO Actions.  :)

Hubert

> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex

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

DO NOT REPLY [Bug 33996] - ChainAction does not support non-default catalogs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33996





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 20:09 ---
For releasing chain, are there any parameters for a signing key?  I don't have
an Apache signing key, and when I went to make one, I realized that I didn't
know if there were any specific settings required or even expected.

I'll also try to review the discussion we had on commons-dev about ways in which
the chain.servlet classes are also in need of updating to work with
CatalogFactory.  If we make that work, we may also earn a 1.1 version number.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33996] - ChainAction does not support non-default catalogs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33996





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 19:18 ---
I'd be +1 on (a) as well. I can help with the mechanics of getting the release 
out, but I'd defer to others on getting the content nailed down and polished up.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33996] - ChainAction does not support non-default catalogs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33996





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 18:51 ---
I'd be supportive of option (a) ... a dot-dot release of Chain ... but don't
have time to do anything other than test it out a bit.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Configuration inheritance, module init code

[Joe Germuska]

Joe had mentioned wanting to move module init code to the
ModuleConfigFactory.
I did?  ;-)
Seriously, though, I don't quite remember the details of that 
discussion -- do you happen to have any pointers to the archives?

I think in general, the idea is to make ActionServlet do little more 
than receive requests and broker them off, with the more general idea 
of making Struts clean of unnecessary dependencies on the Servlet 
API.  Thus, moving as much setup as possible out of there seems 
theoretically good, although I don't know if it needs to be the first 
step -- considering how Action and ActionForm have direct 
dependencies on that API, it may be a lot of ceremony for relatively 
little payoff.

As a general strategy, I think stuff in ActionServlet now should move 
off to a "StrutsApplication" which would deal with bootstrapping and 
with assigning requests to modules for processing.  (As today, the 
per-module request processor would do the bulk of the work, referring 
to its own ModuleConfig for necessary information and resources.)

Was there some detail that I'm forgetting now which makes the factory 
the right place for it?  But assuming I was harping on the same old 
riffs, I was probably somehow trying to get at "reduce direct 
dependencies on Servlet API".

But most importantly, I think it would be best to get decent working 
code in place; we will be continually refactoring, so adding/changing 
stuff where it already is would be no great sin.  And if we don't 
have many use cases in mind for non-Servlet Struts usage, we may make 
some errors in generalizing certain things, so no need to rush. 
(Always remember, though, that unit testing is a non-Servlet Struts 
use case, so just thinking about how to make things more testable may 
help reach a good generalization.)

On the other hand, if it seems easy and straightforward to make an 
incremental improvement as part of this process, great!

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

[Apache Struts Wiki] Updated: StrutsJobJar

[dev]

   Date: 2005-03-15T09:22:20
   Editor: RenaudTarnec
   Wiki: Apache Struts Wiki
   Page: StrutsJobJar
   URL: http://wiki.apache.org/struts/StrutsJobJar

   Changed the link to the tickets page: there was a typo as 
order=%27Importance%27

Change Log:

--
@@ -4,6 +4,6 @@
  *  Review the Bugzilla tickets with patches and let us know if the patch work 
for you 
  *  Vote for Bugzilla tickets that apply to your own work. Provide or test the 
patch for these, if you can
  *  Help develop more unit tests for Struts classes and submit your tests 
through Bugzilla
- *  Review the tickets marked 
[http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&resolution=REMIND&product=Struts&order=%27Importance%27
 REMIND or LATER], and add a note to any that you think are redundant or 
obsolete. This will make it easier for a Committer to determine whether to 
reopen the ticket as an enhancement or to resolve it as invalid or won't fix. 
+ *  Review the tickets marked 
[http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&resolution=REMIND&product=Struts&order=Importance
 REMIND or LATER], and add a note to any that you think are redundant or 
obsolete. This will make it easier for a Committer to determine whether to 
reopen the ticket as an enhancement or to resolve it as invalid or won't fix. 
 
  *  ''' A  maintainer for the conventional Struts taglibs package is 
needed.''' If you are motivated, self-starting developer who is actively using 
these tags, groks the Apache Way, and can spare the time, please take a look at 
the outstanding reports for the taglibs components, and start submitting 
patches for our consideration.

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

Configuration inheritance, module init code

[Hubert Rabago]

My plan is to support configuration inheritance for form beans,
forwards, exception handlers, and actions.  Should I finish them all
up, present them all, then check them in, or should I check in code as
they become ready?

At the moment, form beans are done.  Exceptions, forwards, and actions
have supporting code done in the config objects; the wiring code is up
next.

So far, all the wiring is in the ActionServlet class because this is
where the module startup code is.

Joe had mentioned wanting to move module init code to the
ModuleConfigFactory.  Right now, ModuleConfigFactory is an abstract
class with support for overriding the module config factory class and
an abstract method declaration for "createModuleConfig(String
prefix)".  ( 
http://svn.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/config/ModuleConfigFactory.java?rev=57589&view=markup
)  Init code would have to be moved here instead of the "concrete"
DefaultModuleConfigFactory or it will cause compatibility issues. 
This can be done at a later date, of course, but in the meantime,
about half of the ActionServlet code would be dedicated to
initializing modules.


Hubert

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

DO NOT REPLY [Bug 33996] - ChainAction does not support non-default catalogs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33996





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 13:10 ---
The weird thing is that struts-chain on 1.2.x was never really released either.
   And the annoying thing is that to support catalog/name lookups, either need
two properties or an unreleased version of chain which has a syntax for
splitting a single string ("catalog:command").

I'd rather not write a custom ActionMapping class for this, so then we could
either (a) get a minor release of commons-chain out and use it of (b) apply the
changes which support an arbitrary map of properties on ActionMapping back to
Struts 1.2.x.

I like (a) myself, since I'd like for Struts 1.3 to be able to use that syntax
too.  I wouldn't mind doing a commons-chain release, but I need to set up a
signing key and just practice it since I've never done it.  (Or if someone else
wants to do that release...)  I could pretty easily be persuaded to backport the
property-map stuff if people think that's a good route.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

[Stefan Bodewig]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-taglib has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP


Full details are available at:
http://brutus.apache.org/gump/public/struts/struts-taglib/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts-taglib-15032005.jar] identifier set to project name
 -DEBUG- Dependency on jakarta-cactus-framework-12 exists, no need to add for 
property maven.jar.cactus-12.
 -DEBUG- Dependency on jakarta-cactus-integration-ant-12 exists, no need to add 
for property maven.jar.cactus-ant-12.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/struts/taglib/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/struts/taglib/project.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html
Work Name: build_struts_struts-taglib (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/struts/taglib]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/taglib/target/classes:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjrt.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjtools.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjweaver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-cactus/framework/dist-12/lib/cactus-15032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-15032005/checkstyle-15032005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-15032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15032005.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-15032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-15032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-15032005.jar:/usr/local/gump/public/workspace/jakarta-cactus/integration/ant/dist-12/lib/cactus-ant-15032005.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-15032005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/struts/core/dist/lib/struts.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

The build cannot continue because 

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

[Stefan Bodewig]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-taglib has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP


Full details are available at:
http://brutus.apache.org/gump/public/struts/struts-taglib/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts-taglib-15032005.jar] identifier set to project name
 -DEBUG- Dependency on jakarta-cactus-framework-12 exists, no need to add for 
property maven.jar.cactus-12.
 -DEBUG- Dependency on jakarta-cactus-integration-ant-12 exists, no need to add 
for property maven.jar.cactus-ant-12.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/struts/taglib/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/struts/taglib/project.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html
Work Name: build_struts_struts-taglib (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/struts/taglib]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/taglib/target/classes:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjrt.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjtools.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjweaver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-cactus/framework/dist-12/lib/cactus-15032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-15032005/checkstyle-15032005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-15032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-15032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15032005.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-15032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-15032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-15032005.jar:/usr/local/gump/public/workspace/jakarta-cactus/integration/ant/dist-12/lib/cactus-ant-15032005.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-15032005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/struts/core/dist/lib/struts.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

The build cannot continue because