Re: [GUMP] Build Failure - jakarta-struts

[Martin Cooper]

On Sun, 8 Jun 2003, Ted Husted wrote:

> I popped the release up in that directory, so it's available there at least.

I'm not sure where you mean by "that directory". Gump always starts from
scratch, based on what's at the HEAD of CVS, and builds everything.

Actually, the only place I've seen struts-legacy is in the nightlies
directory. Don't we need that to be in a "released" location, so that
people can pick it up and build Struts with it?

>
> The buildfile follows the same format as Struts and Struts-Faces, so it
> may just be matter of telling Sam, or whoever is managing Gump these
> days, to start building it.

We're responsible for our own Gump descriptor. ;-) So, I guess we need to
create a new descriptor for struts-legacy, since it needs to be listed as
a dependency for the regular Struts build. I'm not sure how this works
when they're both out of the same repo, but I can take this up with Sam et
al if nobody else has any ideas in the meantime.

>
> What do we do when a Commons package is added to the mix?

That's easy - we just add a dependency on that Commons package in the
Struts Gump descriptor. In this case, we need to create the descriptor for
struts-legacy, though. However, this gives me an idea - perhaps I can look
to the Commons descriptor for ideas on how to add struts-legacy to the
regular Struts descriptor.

--
Martin Cooper


>
> -T.
>
> Martin Cooper wrote:
> > We're going to have to find a way to get Gump to build struts-legacy. It
> > would be nice to get this working, given that the nightlies will be down for
> > a while. If anyone has any ideas, please speak up! ;-) Otherwise I'll try to
> > find some time to take a look, but it probably won't be today.
> >
> > --
> > Martin Cooper
> >
> >
> >
> >>-Original Message-
> >>From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> >>Sent: Sunday, June 08, 2003 2:34 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: [GUMP] Build Failure - jakarta-struts
> >>
> >>
> >>
> >>This email is autogenerated from the output from:
> >><http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html>
> >>
> >>
> >>Buildfile: build.xml
> >>
> >>init:
> >> [echo] - jakarta-struts 1.1-rc2 -
> >>
> >> [echo] java.class.path =
> >>/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.j
> >
> > ar:/home/rubys/jakarta/xml->
> > xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-x
> > erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xa
> > lan-> unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/jav
> >
> >>a/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/too
> >
> > ls.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist
> > /lib/> ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/ho
> > me/rubys/jakarta/ant/dist/lib/ant->
> > stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/
> > home/rubys/jakarta/ant/dist/lib/ant->
> > trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home
> > /rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0->
> > stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servle
> > t.jar:/home/rubys/jakarta/jakarta-commons/beanutils/dist/commons->
> > beanutils.jar:/home/rubys/jakarta/jakarta-commons/collections/
> >
> >>dist/commons-collections.jar:/home/rubys/jakarta/jakarta-commo
> >
> > ns/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta->
> > commons/digester/dist/commons-digester.jar:/home/rubys/jakarta
> >
> >>/jakarta-commons/fileupload/target/commons-fileupload-20030608
> >
> > .jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang->
> > 20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/
> >
> >>commons-logging.jar:/home/rubys/jakarta/jakarta-commons/loggin
> >>g/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-com
> >
> > mons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta->
> > commons/validator/dist/commons-validator.jar:/home/rubys/jakar
> >
> >>ta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/ja
> >>karta-struts/target/library/classes:/home/rubys/jakarta/jakart
> >>a-struts/target/tiles/library/classes
> >> [echo] java.home = /usr/java/j2sdk1.4.1_02/jre
> >> [echo] user.home = /

Final steps for RC2

[Martin Cooper]

I believe all that's left is the last of the testing, and then pushing the
release itself out the door. Ted, I know you're heading out on Monday
morning. In case you don't have time to finish up, it looks like I'll have
some time to do that, just in time for JavaOne.

Just in case, I've built a release and created signatures and digests, and
even have a site2 update ready to go. If you'd like me to pick this up, I
think all I need to know is which testing still needs to happen. (I'd like
to avoid doing all of it, if possible, for time reasons. ;)

--
Martin Cooper


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

DO NOT REPLY [Bug 20600] New: - Addition to hosting providers offering Struts support

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20600

Addition to hosting providers offering Struts support

   Summary: Addition to hosting providers offering Struts support
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

JCentric provides excellent hosting support for J2EE applications and Struts is 
an integral part of our suite of libraries available to developers.  Please add 
JCentric to the list of providers on the ISP page.

Link:  http://www.jcentric.com

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

RE: [VOTE] Convert RC2 to Beta 5

[James Turner]

Way to pull one out in the clinch, guys!

What's that I smell in the air?  Could it be... A release candidate?

James

> -Original Message-
> From: James Holmes [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, June 08, 2003 10:10 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> +1 to RC2
> 
> -James
> 
> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, June 08, 2003 8:57 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> 
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 5:26 PM
> > To: 'Struts Developers List'
> > Subject: RE: [VOTE] Convert RC2 to Beta 5
> > 
> > 
> > 
> > 
> > > -Original Message-
> > > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, June 08, 2003 4:56 PM
> > > To: 'Struts Developers List'
> > > Subject: RE: [VOTE] Convert RC2 to Beta 5
> > > 
> > > 
> > > I'm not going to vote right now, because I'm trying to work
> > > through the
> > > problems and see if I can get them fixed. Ted, how long do we 
> > > have to find
> > > fixes and still allow you enough time to get a release out?
> > > 
> > > If we take the 'name' row out of the bean-cookie.jsp 
> test, then the 
> > > remainder of that test works fine on Tomcat 3.3.1. I 
> propose to go 
> > > ahead and check that in unless I hear any objection.
> > > 
> > > Now I'm looking at the logic-compare.jsp problem.
> > 
> > OK, I have this one nailed. It has to do with the size of the
> > page being too
> > big for Tomcat 3.3.1 to handle. I've split the page into two 
> > by pulling out
> > the numeric tests into a separate page, and both pages now 
> > work. Again, I
> > propose to check this in unless I hear any objection.
> > 
> > Now for the Tiles problems...
> 
> Fixed. Time to release RC2! :-)
> 
> --
> Martin Cooper
> 
> 
> > 
> > --
> > Martin Cooper
> > 
> > 
> > > If anyone
> > > else has some
> > > time to look into the problems, might I suggest looking at 
> > > the Tiles-related
> > > ones that Ted mentioned?
> > > 
> > > --
> > > Martin Cooper
> > > 
> > > 
> > > > -Original Message-
> > > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > > Sent: Sunday, June 08, 2003 3:14 PM
> > > > To: Struts Developers List
> > > > Subject: [VOTE] Convert RC2 to Beta 5
> > > > 
> > > > 
> > > > In final testing of RC2, some compatibility issues have
> > been found
> > > > between Tomcat 3.3.1 and the struts-exercise-taglib
> > > > application as well 
> > > > as the tiles-documentation application.
> > > > 
> > > > Martin Cooper has been looking into the problems and has
> > > > found that for 
> > > > the struts-exercise-taglibs cookie test, it is the
> > > > 
> > > >
> > > > 
> > > > expression that is failing.
> > > > 
> > > > The  tags earlier on the page 
> succeeded. The only 
> > > > difference seems to be that the earlier ones all have 
> setters as 
> > > > well as getters in the Tomcat CookieFacade class, 
> whereas there is
> > > > only a getter 
> > > > for 'name'. So this actually looks like some kind of 
> > > > JSP/reflection bug, 
> > > > not related to Struts. (The  tag must have 
> > > > worked, because 
> > > > we know the  tag is trying to access a cookie!)
> > > > 
> > > > Also, the (rather complex) comparison test is killing the JVM
> > > > when run 
> > > > under TC3.
> > > > 
> > > > In the Tiles application, servlet exceptions are being 
> noted. One
> > > > example is the extendedDefinitionTag page, but there may 
> > be others.
> > > > 
> > > > Unless fixes to these problems are immediately forthcoming,
> > > I propose
> > > > that we document the issues and release Stuts 1.1 beta 5.
> > > > 
> > > > By getting this milestone out to the community, we would have
> > > > a better 
> > > > chance of resolving the remaining issues so that we can go 
> > > to Struts
> > > > 1.1. final as soon as possible
> > > > 
> > > > This proposal has my +1.
> > > > 
> > > > -Ted.
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> -
> > > > 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]
> > > 
> > > 
> > 
> > 
> > 
> -
> > 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]
> 
> 
> -
> To unsubscribe, e-mail: [E

RE: [VOTE] Convert RC2 to Beta 5

[James Holmes]

+1 to RC2

-James

-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 08, 2003 8:57 PM
To: 'Struts Developers List'
Subject: RE: [VOTE] Convert RC2 to Beta 5



> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 5:26 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> 
> 
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 4:56 PM
> > To: 'Struts Developers List'
> > Subject: RE: [VOTE] Convert RC2 to Beta 5
> > 
> > 
> > I'm not going to vote right now, because I'm trying to work 
> > through the
> > problems and see if I can get them fixed. Ted, how long do we 
> > have to find
> > fixes and still allow you enough time to get a release out?
> > 
> > If we take the 'name' row out of the bean-cookie.jsp test, then the
> > remainder of that test works fine on Tomcat 3.3.1. I propose 
> > to go ahead and
> > check that in unless I hear any objection.
> > 
> > Now I'm looking at the logic-compare.jsp problem.
> 
> OK, I have this one nailed. It has to do with the size of the 
> page being too
> big for Tomcat 3.3.1 to handle. I've split the page into two 
> by pulling out
> the numeric tests into a separate page, and both pages now 
> work. Again, I
> propose to check this in unless I hear any objection.
> 
> Now for the Tiles problems...

Fixed. Time to release RC2! :-)

--
Martin Cooper


> 
> --
> Martin Cooper
> 
> 
> > If anyone 
> > else has some
> > time to look into the problems, might I suggest looking at 
> > the Tiles-related
> > ones that Ted mentioned?
> > 
> > --
> > Martin Cooper
> > 
> > 
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, June 08, 2003 3:14 PM
> > > To: Struts Developers List
> > > Subject: [VOTE] Convert RC2 to Beta 5
> > > 
> > > 
> > > In final testing of RC2, some compatibility issues have 
> been found 
> > > between Tomcat 3.3.1 and the struts-exercise-taglib 
> > > application as well 
> > > as the tiles-documentation application.
> > > 
> > > Martin Cooper has been looking into the problems and has 
> > > found that for 
> > > the struts-exercise-taglibs cookie test, it is the
> > > 
> > >
> > > 
> > > expression that is failing.
> > > 
> > > The  tags earlier on the page succeeded. The only
> > > difference seems to be that the earlier ones all have setters 
> > > as well as 
> > > getters in the Tomcat CookieFacade class, whereas there is 
> > > only a getter 
> > > for 'name'. So this actually looks like some kind of 
> > > JSP/reflection bug, 
> > > not related to Struts. (The  tag must have 
> > > worked, because 
> > > we know the  tag is trying to access a cookie!)
> > > 
> > > Also, the (rather complex) comparison test is killing the JVM 
> > > when run 
> > > under TC3.
> > > 
> > > In the Tiles application, servlet exceptions are being noted. One 
> > > example is the extendedDefinitionTag page, but there may 
> be others.
> > > 
> > > Unless fixes to these problems are immediately forthcoming, 
> > I propose 
> > > that we document the issues and release Stuts 1.1 beta 5.
> > > 
> > > By getting this milestone out to the community, we would have 
> > > a better 
> > > chance of resolving the remaining issues so that we can go 
> > to Struts 
> > > 1.1. final as soon as possible
> > > 
> > > This proposal has my +1.
> > > 
> > > -Ted.
> > > 
> > > 
> > > 
> > > 
> > 
> -
> > > 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]
> > 
> > 
> 
> 
> -
> 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]


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

RE: [VOTE] Convert RC2 to Beta 5

[Brandon Goodin]

Yes, incredible jobs guys.

Brandon Goodin

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 8:06 PM
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] Convert RC2 to Beta 5


>Fixed. Time to release RC2! :-)

Then here's my -1 to beta 5 and my +1 to RC2.  A *huge* thank you to Ted and
Martin for making RC2 happen!

Thanks,
David

>
>--
>Martin Cooper
>
>
> >
> > --
> > Martin Cooper
> >
> >
> > > If anyone
> > > else has some
> > > time to look into the problems, might I suggest looking at
> > > the Tiles-related
> > > ones that Ted mentioned?
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > > -Original Message-
> > > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > > Sent: Sunday, June 08, 2003 3:14 PM
> > > > To: Struts Developers List
> > > > Subject: [VOTE] Convert RC2 to Beta 5
> > > >
> > > >
> > > > In final testing of RC2, some compatibility issues have
> > been found
> > > > between Tomcat 3.3.1 and the struts-exercise-taglib
> > > > application as well
> > > > as the tiles-documentation application.
> > > >
> > > > Martin Cooper has been looking into the problems and has
> > > > found that for
> > > > the struts-exercise-taglibs cookie test, it is the
> > > >
> > > >
> > > >
> > > > expression that is failing.
> > > >
> > > > The  tags earlier on the page succeeded. The only
> > > > difference seems to be that the earlier ones all have setters
> > > > as well as
> > > > getters in the Tomcat CookieFacade class, whereas there is
> > > > only a getter
> > > > for 'name'. So this actually looks like some kind of
> > > > JSP/reflection bug,
> > > > not related to Struts. (The  tag must have
> > > > worked, because
> > > > we know the  tag is trying to access a cookie!)
> > > >
> > > > Also, the (rather complex) comparison test is killing the JVM
> > > > when run
> > > > under TC3.
> > > >
> > > > In the Tiles application, servlet exceptions are being noted. One
> > > > example is the extendedDefinitionTag page, but there may
> > be others.
> > > >
> > > > Unless fixes to these problems are immediately forthcoming,
> > > I propose
> > > > that we document the issues and release Stuts 1.1 beta 5.
> > > >
> > > > By getting this milestone out to the community, we would have
> > > > a better
> > > > chance of resolving the remaining issues so that we can go
> > > to Struts
> > > > 1.1. final as soon as possible
> > > >
> > > > This proposal has my +1.
> > > >
> > > > -Ted.
> > > >
> > > >
> > > >
> > > >
> > >
> > -
> > > > 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]
> > >
> > >
> >
> >
> > -
> > 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]
>

_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail


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

RE: [VOTE] Convert RC2 to Beta 5

[David Graham]

Fixed. Time to release RC2! :-)
Then here's my -1 to beta 5 and my +1 to RC2.  A *huge* thank you to Ted and 
Martin for making RC2 happen!

Thanks,
David
--
Martin Cooper
>
> --
> Martin Cooper
>
>
> > If anyone
> > else has some
> > time to look into the problems, might I suggest looking at
> > the Tiles-related
> > ones that Ted mentioned?
> >
> > --
> > Martin Cooper
> >
> >
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, June 08, 2003 3:14 PM
> > > To: Struts Developers List
> > > Subject: [VOTE] Convert RC2 to Beta 5
> > >
> > >
> > > In final testing of RC2, some compatibility issues have
> been found
> > > between Tomcat 3.3.1 and the struts-exercise-taglib
> > > application as well
> > > as the tiles-documentation application.
> > >
> > > Martin Cooper has been looking into the problems and has
> > > found that for
> > > the struts-exercise-taglibs cookie test, it is the
> > >
> > >
> > >
> > > expression that is failing.
> > >
> > > The  tags earlier on the page succeeded. The only
> > > difference seems to be that the earlier ones all have setters
> > > as well as
> > > getters in the Tomcat CookieFacade class, whereas there is
> > > only a getter
> > > for 'name'. So this actually looks like some kind of
> > > JSP/reflection bug,
> > > not related to Struts. (The  tag must have
> > > worked, because
> > > we know the  tag is trying to access a cookie!)
> > >
> > > Also, the (rather complex) comparison test is killing the JVM
> > > when run
> > > under TC3.
> > >
> > > In the Tiles application, servlet exceptions are being noted. One
> > > example is the extendedDefinitionTag page, but there may
> be others.
> > >
> > > Unless fixes to these problems are immediately forthcoming,
> > I propose
> > > that we document the issues and release Stuts 1.1 beta 5.
> > >
> > > By getting this milestone out to the community, we would have
> > > a better
> > > chance of resolving the remaining issues so that we can go
> > to Struts
> > > 1.1. final as soon as possible
> > >
> > > This proposal has my +1.
> > >
> > > -Ted.
> > >
> > >
> > >
> > >
> >
> -
> > > 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]
> >
> >
>
>
> -
> 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]
_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

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

RE: [VOTE] Convert RC2 to Beta 5

[Brandon Goodin]

YOU DA MAN!!!

Brandon Goodin 

-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 7:57 PM
To: 'Struts Developers List'
Subject: RE: [VOTE] Convert RC2 to Beta 5




> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 5:26 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> 
> 
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 4:56 PM
> > To: 'Struts Developers List'
> > Subject: RE: [VOTE] Convert RC2 to Beta 5
> > 
> > 
> > I'm not going to vote right now, because I'm trying to work 
> > through the
> > problems and see if I can get them fixed. Ted, how long do we 
> > have to find
> > fixes and still allow you enough time to get a release out?
> > 
> > If we take the 'name' row out of the bean-cookie.jsp test, then the
> > remainder of that test works fine on Tomcat 3.3.1. I propose 
> > to go ahead and
> > check that in unless I hear any objection.
> > 
> > Now I'm looking at the logic-compare.jsp problem.
> 
> OK, I have this one nailed. It has to do with the size of the 
> page being too
> big for Tomcat 3.3.1 to handle. I've split the page into two 
> by pulling out
> the numeric tests into a separate page, and both pages now 
> work. Again, I
> propose to check this in unless I hear any objection.
> 
> Now for the Tiles problems...

Fixed. Time to release RC2! :-)

--
Martin Cooper


> 
> --
> Martin Cooper
> 
> 
> > If anyone 
> > else has some
> > time to look into the problems, might I suggest looking at 
> > the Tiles-related
> > ones that Ted mentioned?
> > 
> > --
> > Martin Cooper
> > 
> > 
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, June 08, 2003 3:14 PM
> > > To: Struts Developers List
> > > Subject: [VOTE] Convert RC2 to Beta 5
> > > 
> > > 
> > > In final testing of RC2, some compatibility issues have 
> been found 
> > > between Tomcat 3.3.1 and the struts-exercise-taglib 
> > > application as well 
> > > as the tiles-documentation application.
> > > 
> > > Martin Cooper has been looking into the problems and has 
> > > found that for 
> > > the struts-exercise-taglibs cookie test, it is the
> > > 
> > >
> > > 
> > > expression that is failing.
> > > 
> > > The  tags earlier on the page succeeded. The only
> > > difference seems to be that the earlier ones all have setters 
> > > as well as 
> > > getters in the Tomcat CookieFacade class, whereas there is 
> > > only a getter 
> > > for 'name'. So this actually looks like some kind of 
> > > JSP/reflection bug, 
> > > not related to Struts. (The  tag must have 
> > > worked, because 
> > > we know the  tag is trying to access a cookie!)
> > > 
> > > Also, the (rather complex) comparison test is killing the JVM 
> > > when run 
> > > under TC3.
> > > 
> > > In the Tiles application, servlet exceptions are being noted. One 
> > > example is the extendedDefinitionTag page, but there may 
> be others.
> > > 
> > > Unless fixes to these problems are immediately forthcoming, 
> > I propose 
> > > that we document the issues and release Stuts 1.1 beta 5.
> > > 
> > > By getting this milestone out to the community, we would have 
> > > a better 
> > > chance of resolving the remaining issues so that we can go 
> > to Struts 
> > > 1.1. final as soon as possible
> > > 
> > > This proposal has my +1.
> > > 
> > > -Ted.
> > > 
> > > 
> > > 
> > > 
> > 
> -
> > > 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]
> > 
> > 
> 
> 
> -
> 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]



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

RE: [VOTE] Convert RC2 to Beta 5

[Martin Cooper]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 5:26 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> 
> 
> > -Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 4:56 PM
> > To: 'Struts Developers List'
> > Subject: RE: [VOTE] Convert RC2 to Beta 5
> > 
> > 
> > I'm not going to vote right now, because I'm trying to work 
> > through the
> > problems and see if I can get them fixed. Ted, how long do we 
> > have to find
> > fixes and still allow you enough time to get a release out?
> > 
> > If we take the 'name' row out of the bean-cookie.jsp test, then the
> > remainder of that test works fine on Tomcat 3.3.1. I propose 
> > to go ahead and
> > check that in unless I hear any objection.
> > 
> > Now I'm looking at the logic-compare.jsp problem.
> 
> OK, I have this one nailed. It has to do with the size of the 
> page being too
> big for Tomcat 3.3.1 to handle. I've split the page into two 
> by pulling out
> the numeric tests into a separate page, and both pages now 
> work. Again, I
> propose to check this in unless I hear any objection.
> 
> Now for the Tiles problems...

Fixed. Time to release RC2! :-)

--
Martin Cooper


> 
> --
> Martin Cooper
> 
> 
> > If anyone 
> > else has some
> > time to look into the problems, might I suggest looking at 
> > the Tiles-related
> > ones that Ted mentioned?
> > 
> > --
> > Martin Cooper
> > 
> > 
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, June 08, 2003 3:14 PM
> > > To: Struts Developers List
> > > Subject: [VOTE] Convert RC2 to Beta 5
> > > 
> > > 
> > > In final testing of RC2, some compatibility issues have 
> been found 
> > > between Tomcat 3.3.1 and the struts-exercise-taglib 
> > > application as well 
> > > as the tiles-documentation application.
> > > 
> > > Martin Cooper has been looking into the problems and has 
> > > found that for 
> > > the struts-exercise-taglibs cookie test, it is the
> > > 
> > >
> > > 
> > > expression that is failing.
> > > 
> > > The  tags earlier on the page succeeded. The only
> > > difference seems to be that the earlier ones all have setters 
> > > as well as 
> > > getters in the Tomcat CookieFacade class, whereas there is 
> > > only a getter 
> > > for 'name'. So this actually looks like some kind of 
> > > JSP/reflection bug, 
> > > not related to Struts. (The  tag must have 
> > > worked, because 
> > > we know the  tag is trying to access a cookie!)
> > > 
> > > Also, the (rather complex) comparison test is killing the JVM 
> > > when run 
> > > under TC3.
> > > 
> > > In the Tiles application, servlet exceptions are being noted. One 
> > > example is the extendedDefinitionTag page, but there may 
> be others.
> > > 
> > > Unless fixes to these problems are immediately forthcoming, 
> > I propose 
> > > that we document the issues and release Stuts 1.1 beta 5.
> > > 
> > > By getting this milestone out to the community, we would have 
> > > a better 
> > > chance of resolving the remaining issues so that we can go 
> > to Struts 
> > > 1.1. final as soon as possible
> > > 
> > > This proposal has my +1.
> > > 
> > > -Ted.
> > > 
> > > 
> > > 
> > > 
> > 
> -
> > > 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]
> > 
> > 
> 
> 
> -
> 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]

cvs commit: jakarta-struts/web/tiles-documentation/tutorial/common/menu menuSrc.jsp

[martinc]

martinc 2003/06/08 18:54:46

  Modified:web/tiles-documentation/tutorial/common/menu menuSrc.jsp
  Log:
  Fix the path for the menuViewSrc.jsp page. This fixes a servlet exception
  thrown when attempting to render extendedDefinitionTag.jsp.
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-struts/web/tiles-documentation/tutorial/common/menu/menuSrc.jsp
  
  Index: menuSrc.jsp
  ===
  RCS file: 
/home/cvs/jakarta-struts/web/tiles-documentation/tutorial/common/menu/menuSrc.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- menuSrc.jsp   6 Jul 2002 01:13:53 -   1.1
  +++ menuSrc.jsp   9 Jun 2003 01:54:46 -   1.2
  @@ -1,6 +1,6 @@
   <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
   
  -
  +
 
   
   
  
  
  

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

cvs commit: jakarta-struts/web/exercise-taglib logic-compare-numeric.jsp index.jsp logic-compare.jsp

[martinc]

martinc 2003/06/08 18:51:48

  Modified:web/exercise-taglib index.jsp logic-compare.jsp
  Added:   web/exercise-taglib logic-compare-numeric.jsp
  Log:
  Split the logic comparison tests into two pages, since the one gigantic
  page causes problems with Tomcat 3.3.1. The boolean and string tests are
  on one page, and the numeric tests are on a separate page now.
  
  Revision  ChangesPath
  1.5   +1 -0  jakarta-struts/web/exercise-taglib/index.jsp
  
  Index: index.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/exercise-taglib/index.jsp,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.jsp 16 Jul 2002 04:56:42 -  1.4
  +++ index.jsp 9 Jun 2003 01:51:48 -   1.5
  @@ -32,6 +32,7 @@
   LOGIC Tags
   
   Comparison Tags
  +Comparison Tags (Numeric)
   Iterate Tag
   Match Tags
   Presence Tags
  
  
  
  1.6   +0 -489jakarta-struts/web/exercise-taglib/logic-compare.jsp
  
  Index: logic-compare.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/exercise-taglib/logic-compare.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- logic-compare.jsp 16 Mar 2002 03:00:44 -  1.5
  +++ logic-compare.jsp 9 Jun 2003 01:51:48 -   1.6
  @@ -15,15 +15,6 @@
   <%
 String bool1 = "true";
 String bool2 = "false";
  -  String doub1 = "321.0";
  -  String doub2 = "111.0";
  -  String doub3 = "333.0";
  -  String long1 = "321";
  -  String long2 = "111";
  -  String long3 = "333";
  -  String short1 = "987";
  -  String short2 = "654";
  -  String short3 = "999";
 String str1 = "This is a string";
 String str2 = "Less than";
 String str3 = "XYZ greater than";
  @@ -97,486 +88,6 @@
 
 
  -notEqual
  -  
  -
  -  
  -  
  -double / EQ
  -
  -<%= doub1 %>
  -equal greaterEqual lessEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -double / GT
  -
  -<%= doub2 %>
  -greaterEqual greaterThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -double / LT
  -
  -<%= doub3 %>
  -lessEqual lessThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -float / EQ
  -
  -<%= doub1 %>
  -lessEqual lessThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -float / GT
  -
  -<%= doub2 %>
  -greaterEqual greaterThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -float / LT
  -
  -<%= doub3 %>
  -lessEqual lessThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -int / EQ
  -
  -<%= long1 %>
  -lessEqual lessThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -int / GT
  -
  -<%= long2 %>
  -greaterEqual greaterThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -  
  -  
  -lessEqual
  -  
  -  
  -lessThan
  -  
  -  
  -notEqual
  -  
  -
  -  
  -  
  -int / LT
  -
  -<%= long3 %>
  -lessEqual lessThan notEqual
  -
  -  
  -equal
  -  
  -  
  -greaterEqual
  -  
  -  
  -greaterThan
  -   

cvs commit: jakarta-struts/web/exercise-taglib bean-cookie.jsp

[martinc]

martinc 2003/06/08 18:50:15

  Modified:web/exercise-taglib bean-cookie.jsp
  Log:
  Remove the row corresponding to the name of the cookie. It causes problems
  on Tomcat 3.3.1 because of some kind of reflection issue, and isn't really
  necessary to prove that the  tag works, anyway.
  
  Revision  ChangesPath
  1.2   +0 -5  jakarta-struts/web/exercise-taglib/bean-cookie.jsp
  
  Index: bean-cookie.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/exercise-taglib/bean-cookie.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- bean-cookie.jsp   7 Mar 2001 04:50:54 -   1.1
  +++ bean-cookie.jsp   9 Jun 2003 01:50:15 -   1.2
  @@ -37,11 +37,6 @@
   
 
 
  -name
  -
  -
  -  
  -  
   path
   
   
  
  
  

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

Re: [VOTE] Convert RC2 to Beta 5

[Gareth Andrew]

Hi,

I needed something to help me sleep, so I had a poke around the 
bean-cookie bug. 
Unfortunately I found nothing of real interest.  I can confirm that the 
bug can also be found in struts-1.1-RC1 and Struts-1.0.2 (Tomcat 3.3.1; 
j2sdk1.4.0_01)and manifests itself in both

and

however
<% Cookie cookie = (Cookie)pageContext.getAttribute("sess");
   out.println(sess.getName());   
%>
works fine, so the bug definitely seems reflection related.

Sorry I couldn't be of more use,

Gareth
  
PS.  IMO this bug can just be ignored since it doesn't seem struts 
related; its completely ancient and only affects people using an ancient 
container; and no-one has reported it before.  However I don't think the 
test should be modified so that it works, instead i think the 
documentation should should be modified to reflect that we expect it to 
fail.

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

RE: [VOTE] Convert RC2 to Beta 5

[dhay]

Go Martin!!!




"Martin Cooper" <[EMAIL PROTECTED]> on 08/06/2003 08:25:53 PM

Please respond to "Struts Developers List" <[EMAIL PROTECTED]>

To:"'Struts Developers List'" <[EMAIL PROTECTED]>
cc:
Subject:RE: [VOTE] Convert RC2 to Beta 5




> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:56 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
>
>
> I'm not going to vote right now, because I'm trying to work
> through the
> problems and see if I can get them fixed. Ted, how long do we
> have to find
> fixes and still allow you enough time to get a release out?
>
> If we take the 'name' row out of the bean-cookie.jsp test, then the
> remainder of that test works fine on Tomcat 3.3.1. I propose
> to go ahead and
> check that in unless I hear any objection.
>
> Now I'm looking at the logic-compare.jsp problem.

OK, I have this one nailed. It has to do with the size of the page being
too
big for Tomcat 3.3.1 to handle. I've split the page into two by pulling out
the numeric tests into a separate page, and both pages now work. Again, I
propose to check this in unless I hear any objection.

Now for the Tiles problems...

--
Martin Cooper


> If anyone
> else has some
> time to look into the problems, might I suggest looking at
> the Tiles-related
> ones that Ted mentioned?
>
> --
> Martin Cooper
>
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 3:14 PM
> > To: Struts Developers List
> > Subject: [VOTE] Convert RC2 to Beta 5
> >
> >
> > In final testing of RC2, some compatibility issues have been found
> > between Tomcat 3.3.1 and the struts-exercise-taglib
> > application as well
> > as the tiles-documentation application.
> >
> > Martin Cooper has been looking into the problems and has
> > found that for
> > the struts-exercise-taglibs cookie test, it is the
> >
> >
> >
> > expression that is failing.
> >
> > The  tags earlier on the page succeeded. The only
> > difference seems to be that the earlier ones all have setters
> > as well as
> > getters in the Tomcat CookieFacade class, whereas there is
> > only a getter
> > for 'name'. So this actually looks like some kind of
> > JSP/reflection bug,
> > not related to Struts. (The  tag must have
> > worked, because
> > we know the  tag is trying to access a cookie!)
> >
> > Also, the (rather complex) comparison test is killing the JVM
> > when run
> > under TC3.
> >
> > In the Tiles application, servlet exceptions are being noted. One
> > example is the extendedDefinitionTag page, but there may be others.
> >
> > Unless fixes to these problems are immediately forthcoming,
> I propose
> > that we document the issues and release Stuts 1.1 beta 5.
> >
> > By getting this milestone out to the community, we would have
> > a better
> > chance of resolving the remaining issues so that we can go
> to Struts
> > 1.1. final as soon as possible
> >
> > This proposal has my +1.
> >
> > -Ted.
> >
> >
> >
> >
> -
> > 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]
>
>


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

RE: [VOTE] Convert RC2 to Beta 5

[Martin Cooper]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:56 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
> 
> 
> I'm not going to vote right now, because I'm trying to work 
> through the
> problems and see if I can get them fixed. Ted, how long do we 
> have to find
> fixes and still allow you enough time to get a release out?
> 
> If we take the 'name' row out of the bean-cookie.jsp test, then the
> remainder of that test works fine on Tomcat 3.3.1. I propose 
> to go ahead and
> check that in unless I hear any objection.
> 
> Now I'm looking at the logic-compare.jsp problem.

OK, I have this one nailed. It has to do with the size of the page being too
big for Tomcat 3.3.1 to handle. I've split the page into two by pulling out
the numeric tests into a separate page, and both pages now work. Again, I
propose to check this in unless I hear any objection.

Now for the Tiles problems...

--
Martin Cooper


> If anyone 
> else has some
> time to look into the problems, might I suggest looking at 
> the Tiles-related
> ones that Ted mentioned?
> 
> --
> Martin Cooper
> 
> 
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 3:14 PM
> > To: Struts Developers List
> > Subject: [VOTE] Convert RC2 to Beta 5
> > 
> > 
> > In final testing of RC2, some compatibility issues have been found 
> > between Tomcat 3.3.1 and the struts-exercise-taglib 
> > application as well 
> > as the tiles-documentation application.
> > 
> > Martin Cooper has been looking into the problems and has 
> > found that for 
> > the struts-exercise-taglibs cookie test, it is the
> > 
> >
> > 
> > expression that is failing.
> > 
> > The  tags earlier on the page succeeded. The only
> > difference seems to be that the earlier ones all have setters 
> > as well as 
> > getters in the Tomcat CookieFacade class, whereas there is 
> > only a getter 
> > for 'name'. So this actually looks like some kind of 
> > JSP/reflection bug, 
> > not related to Struts. (The  tag must have 
> > worked, because 
> > we know the  tag is trying to access a cookie!)
> > 
> > Also, the (rather complex) comparison test is killing the JVM 
> > when run 
> > under TC3.
> > 
> > In the Tiles application, servlet exceptions are being noted. One 
> > example is the extendedDefinitionTag page, but there may be others.
> > 
> > Unless fixes to these problems are immediately forthcoming, 
> I propose 
> > that we document the issues and release Stuts 1.1 beta 5.
> > 
> > By getting this milestone out to the community, we would have 
> > a better 
> > chance of resolving the remaining issues so that we can go 
> to Struts 
> > 1.1. final as soon as possible
> > 
> > This proposal has my +1.
> > 
> > -Ted.
> > 
> > 
> > 
> > 
> -
> > 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]
> 
> 


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

RE: [VOTE] Convert RC2 to Beta 5

[Martin Cooper]

I'm not going to vote right now, because I'm trying to work through the
problems and see if I can get them fixed. Ted, how long do we have to find
fixes and still allow you enough time to get a release out?

If we take the 'name' row out of the bean-cookie.jsp test, then the
remainder of that test works fine on Tomcat 3.3.1. I propose to go ahead and
check that in unless I hear any objection.

Now I'm looking at the logic-compare.jsp problem. If anyone else has some
time to look into the problems, might I suggest looking at the Tiles-related
ones that Ted mentioned?

--
Martin Cooper


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 3:14 PM
> To: Struts Developers List
> Subject: [VOTE] Convert RC2 to Beta 5
> 
> 
> In final testing of RC2, some compatibility issues have been found 
> between Tomcat 3.3.1 and the struts-exercise-taglib 
> application as well 
> as the tiles-documentation application.
> 
> Martin Cooper has been looking into the problems and has 
> found that for 
> the struts-exercise-taglibs cookie test, it is the
> 
>
> 
> expression that is failing.
> 
> The  tags earlier on the page succeeded. The only
> difference seems to be that the earlier ones all have setters 
> as well as 
> getters in the Tomcat CookieFacade class, whereas there is 
> only a getter 
> for 'name'. So this actually looks like some kind of 
> JSP/reflection bug, 
> not related to Struts. (The  tag must have 
> worked, because 
> we know the  tag is trying to access a cookie!)
> 
> Also, the (rather complex) comparison test is killing the JVM 
> when run 
> under TC3.
> 
> In the Tiles application, servlet exceptions are being noted. One 
> example is the extendedDefinitionTag page, but there may be others.
> 
> Unless fixes to these problems are immediately forthcoming, I propose 
> that we document the issues and release Stuts 1.1 beta 5.
> 
> By getting this milestone out to the community, we would have 
> a better 
> chance of resolving the remaining issues so that we can go to Struts 
> 1.1. final as soon as possible
> 
> This proposal has my +1.
> 
> -Ted.
> 
> 
> 
> -
> 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]

Re: [VOTE] Convert RC2 to Beta 5

[Ted Husted]

David Graham wrote:
> I'm confused why we would go from RC1 to Beta 5.  Is there a
> distinction  in the naming that I'm missing?  It seems like we're
> going backwards if  we label it "beta".
A release candidate means we sincerely believe we can release the 
distribution without further changes. If all tests, including play 
testing the application had passed, then we may have been able to 
release this just by swapping the FileUpload JAR from RC1 to the final 
release. (Since the only difference with the FU JAR would have been the 
labeling.)

Right now, we have TC3 issues with two of our sample applications. I 
don't know that the fix will be. Maybe our classes won't change, maybe 
they will. Since I don't know, I can't honestly say it's a RC.

If anyone here does know what the fix is, then we can apply it an 
proceed to RC2 again. If we don't know that the fix is, then one good 
way of "asking around" would be to distribute a milestone. We can't call 
it a RC because we know it can't be promoted to Final without some sort 
of undetermined change, but we can call it a beta.

Otherwise, our only alternatives to adopt a "wait and see" attitude 
while someone determines a fix -- or drop TC3 as a supported application.

It's important to remember that we don't *have* to distribute a RC 
before making a final release. We can make a final release whenever we 
want. We are the committers, we make the decisions. If the fix to beta 5 
were minor, we could fix it and vote to release the result as final, 
without any further red tape -- if that's what we decided to do. (Or, 
more likely, post a RC to one of our home directories and immediately 
vote that out the door.)

So, there's nothing to lose, and everything to gain. If we ship 
something this week, and work out the TC3 issue in the meantime, we 
could still go to 1.1 final this month. But, if we hestitate and don't 
ship something now, we will have to circulate another RC later. (Hello, 
July!)

Unfortunately, I have house guests tonight and am leaving for the week 
in the morning, so there isn't much more I can do about this myself this 
week. =:(

-Ted.



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

Re: ActionContext [WAS: RE: composable RequestProcessor]

[Vic Cekvenich]

I do the same thing in bP! One Context/Event object. Much simpler.

Also, the signature can then support TilesAction signature, , etc.
.V
Peter A. Pilgrim wrote:
Andrew Hill wrote:


I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).

Im doing this in my app - though the execute signature remains the same.
Most of my actions extend some abstract action classes, and most of the
hooks the subclass overrides are passed an ActionContext bean (which 
simply
has getters for the request,response, mapping etc...). Saves a lot of 
typing
and makes the code much more readable at the expense of one more tiny 
object
being created in the execute method. I later found it a good place to add
attributes as well - like the request attributes only scoped to the 
execute
method of the action (life of the ActionContext bean).

Ive been very tempted to overide my applications RPs 
processActrionPerform
and instantiate the action context there and pass it to the actions 
execute
but havent got around to it yet.

This is what I do when I extend the base Action and DispatchAction classes.
I created a context object to store the four parameter. It makes it very
simple to add extra bits and pass them to actions.
public AcmeActionContext extends ActionContext {

ActionMapping mapping;
ActionFormform;
HttpServletRequest request;
HttpServletResponse response;
...

LoginProfile loginProfile = SomeSecurityLayer.getInstance();

}






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

Re: ActionContext [WAS: RE: composable RequestProcessor]

[Peter A. Pilgrim]

Andrew Hill wrote:

I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).

Im doing this in my app - though the execute signature remains the same.
Most of my actions extend some abstract action classes, and most of the
hooks the subclass overrides are passed an ActionContext bean (which simply
has getters for the request,response, mapping etc...). Saves a lot of typing
and makes the code much more readable at the expense of one more tiny object
being created in the execute method. I later found it a good place to add
attributes as well - like the request attributes only scoped to the execute
method of the action (life of the ActionContext bean).
Ive been very tempted to overide my applications RPs processActrionPerform
and instantiate the action context there and pass it to the actions execute
but havent got around to it yet.
This is what I do when I extend the base Action and DispatchAction classes.
I created a context object to store the four parameter. It makes it very
simple to add extra bits and pass them to actions.
public AcmeActionContext extends ActionContext {

ActionMapping   mapping;
ActionForm  form;
HttpServletRequest request;
HttpServletResponse response;
	...

	LoginProfile 	loginProfile = SomeSecurityLayer.getInstance();

}



--
Peter Pilgrim
   __ _ _ _
  / //__  // ___// ___/   +  Serverside Java
 / /___/ // /__ / /__ +  Struts
/ // ___// ___// ___/ +  Expresso Committer
 __/ // /__ / /__ / /__   +  Independent Contractor
/___///////   +  Intrinsic Motivation
On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Convert RC2 to Beta 5

[Vic Cekvenich]

(Thanks Ted and others comitters CVSing fixes (David, Martin) for 
donating yet another weekend to Struts, either way).
My comprehension (not again Its not flamey this time) is this:

Ted can release today under Beta 5 beta as is (with the known failed 
test) with all the work he did. Plus for this side is... who knows when 
is the next time a release will come, and no release for Java One?, that 
was the motivation here. So it's a step sideways to go forward. +1 means 
release Today, that is how I read it. It's just a name.

Else... someone else (who has tech. skills/experience of Ted) has to 
step forward, at another time to fix and build and release.   So if you 
look at it as beta  vs RC 2... it seems RC2! But when, a week? A month? 
What about the work done last few days? So a - 1 means wait.

If you say, hey, lets release something! that works and passes most 
tests in how it's used, and lets move towards final then ... beta 5.

+0 for B5.

.V

James Turner wrote:
Frankly, since these seem to be problems in the tests and demo
applications, rather than in the base code, I'd be -1 on this.  Going to
a beta 5 seems to me to be a unnecessary step unless the problem is in
the actual core libraries themselves.  

James


-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 08, 2003 6:14 PM
To: Struts Developers List
Subject: [VOTE] Convert RC2 to Beta 5

In final testing of RC2, some compatibility issues have been found 
between Tomcat 3.3.1 and the struts-exercise-taglib 
application as well 
as the tiles-documentation application.

Martin Cooper has been looking into the problems and has 
found that for 
the struts-exercise-taglibs cookie test, it is the

  

expression that is failing.

The  tags earlier on the page succeeded. The 
only difference seems to be that the earlier ones all have 
setters as well as 
getters in the Tomcat CookieFacade class, whereas there is 
only a getter 
for 'name'. So this actually looks like some kind of 
JSP/reflection bug, 
not related to Struts. (The  tag must have 
worked, because 
we know the  tag is trying to access a cookie!)

Also, the (rather complex) comparison test is killing the JVM 
when run 
under TC3.

In the Tiles application, servlet exceptions are being noted. One 
example is the extendedDefinitionTag page, but there may be others.

Unless fixes to these problems are immediately forthcoming, I propose 
that we document the issues and release Stuts 1.1 beta 5.

By getting this milestone out to the community, we would have 
a better 
chance of resolving the remaining issues so that we can go to Struts 
1.1. final as soon as possible

This proposal has my +1.

-Ted.



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

Re: [VOTE] Convert RC2 to Beta 5

[David Graham]

I'm confused why we would go from RC1 to Beta 5.  Is there a distinction in 
the naming that I'm missing?  It seems like we're going backwards if we 
label it "beta".

David


From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: [VOTE] Convert RC2 to Beta 5
Date: Sun, 08 Jun 2003 18:13:43 -0400
In final testing of RC2, some compatibility issues have been found between 
Tomcat 3.3.1 and the struts-exercise-taglib application as well as the 
tiles-documentation application.

Martin Cooper has been looking into the problems and has found that for the 
struts-exercise-taglibs cookie test, it is the

  

expression that is failing.

The  tags earlier on the page succeeded. The only
difference seems to be that the earlier ones all have setters as well as 
getters in the Tomcat CookieFacade class, whereas there is only a getter 
for 'name'. So this actually looks like some kind of JSP/reflection bug, 
not related to Struts. (The  tag must have worked, because we 
know the  tag is trying to access a cookie!)

Also, the (rather complex) comparison test is killing the JVM when run 
under TC3.

In the Tiles application, servlet exceptions are being noted. One example 
is the extendedDefinitionTag page, but there may be others.

Unless fixes to these problems are immediately forthcoming, I propose that 
we document the issues and release Stuts 1.1 beta 5.

By getting this milestone out to the community, we would have a better 
chance of resolving the remaining issues so that we can go to Struts 1.1. 
final as soon as possible

This proposal has my +1.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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

RE: [VOTE] Convert RC2 to Beta 5

[James Turner]

Frankly, since these seem to be problems in the tests and demo
applications, rather than in the base code, I'd be -1 on this.  Going to
a beta 5 seems to me to be a unnecessary step unless the problem is in
the actual core libraries themselves.  

James

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, June 08, 2003 6:14 PM
> To: Struts Developers List
> Subject: [VOTE] Convert RC2 to Beta 5
> 
> 
> In final testing of RC2, some compatibility issues have been found 
> between Tomcat 3.3.1 and the struts-exercise-taglib 
> application as well 
> as the tiles-documentation application.
> 
> Martin Cooper has been looking into the problems and has 
> found that for 
> the struts-exercise-taglibs cookie test, it is the
> 
>
> 
> expression that is failing.
> 
> The  tags earlier on the page succeeded. The 
> only difference seems to be that the earlier ones all have 
> setters as well as 
> getters in the Tomcat CookieFacade class, whereas there is 
> only a getter 
> for 'name'. So this actually looks like some kind of 
> JSP/reflection bug, 
> not related to Struts. (The  tag must have 
> worked, because 
> we know the  tag is trying to access a cookie!)
> 
> Also, the (rather complex) comparison test is killing the JVM 
> when run 
> under TC3.
> 
> In the Tiles application, servlet exceptions are being noted. One 
> example is the extendedDefinitionTag page, but there may be others.
> 
> Unless fixes to these problems are immediately forthcoming, I propose 
> that we document the issues and release Stuts 1.1 beta 5.
> 
> By getting this milestone out to the community, we would have 
> a better 
> chance of resolving the remaining issues so that we can go to Struts 
> 1.1. final as soon as possible
> 
> This proposal has my +1.
> 
> -Ted.
> 
> 
> 
> -
> 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]

[VOTE] Convert RC2 to Beta 5

[Ted Husted]

In final testing of RC2, some compatibility issues have been found 
between Tomcat 3.3.1 and the struts-exercise-taglib application as well 
as the tiles-documentation application.

Martin Cooper has been looking into the problems and has found that for 
the struts-exercise-taglibs cookie test, it is the

  

expression that is failing.

The  tags earlier on the page succeeded. The only
difference seems to be that the earlier ones all have setters as well as 
getters in the Tomcat CookieFacade class, whereas there is only a getter 
for 'name'. So this actually looks like some kind of JSP/reflection bug, 
not related to Struts. (The  tag must have worked, because 
we know the  tag is trying to access a cookie!)

Also, the (rather complex) comparison test is killing the JVM when run 
under TC3.

In the Tiles application, servlet exceptions are being noted. One 
example is the extendedDefinitionTag page, but there may be others.

Unless fixes to these problems are immediately forthcoming, I propose 
that we document the issues and release Stuts 1.1 beta 5.

By getting this milestone out to the community, we would have a better 
chance of resolving the remaining issues so that we can go to Struts 
1.1. final as soon as possible

This proposal has my +1.

-Ted.



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

RE: What's next for Struts?

[James Holmes]

Yep, I'm definitely not abandoning Struts either.  I am in the middle of
some nice new features for Struts Console.

Stay tuned.

-James
http://www.jamesholmes.com/struts/

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 08, 2003 8:18 AM
To: Struts Developers List
Subject: Re: What's next for Struts?

Craig R. McClanahan wrote:
> No, Struts is definitely not dead.  

=:) Those rumors have been greatly exaggerated! The Struts Committers 
have been a bit busy the last year or so with parceling Struts into 
Commons components and all. But the Struts Community has been shipping, 
shipping, shipping.

For example, Don Brown is shipping extensions for using Struts with 
Cocoon and the Bean Scripting Framework, and as of today, Wildcard 
Actions. Mathias just released an update to his very useful workflow 
extension. James keeps bringing out Console after Console. Just to name 
a few. (Need to get that Resource page updated before final ships!)

And of course, there are the long-standing XLST, Velocity, SSL, and 
JUnit extension for Struts, doclet extensions for Struts, database 
extension for Struts, and surely many things I haven't heard of yet!

And, as Craig pointed out, Struts is not the only place where people are

developing MVC frameworks. WebWorks demonstrated the usefulness of a 
unified Controller (or "Action") objects. Other frameworks like Maverick

and JPublish are showing us how very different approaches to handling 
actions (as well as screens) can all be used within the same framework.

The point is that no matter how good JSF will be, or how good Struts is 
now, there will always be "more dreamed of" than what we happen to stuff

in our distributions! There will always be gaps where open-source 
developers, like us, can jump in and start sharing our solutions.

This is true not only of Java, but of any platform. For example, most of

us know that .NET lacks many of the high-level tools we all use and 
love. OSS, like nature, abhors a vacuum. So, OSS volunteers have been 
busily porting many of our favorite tools "to the dark side". Packages 
like Maverick, Velocity, and Log4*, again to name a few, are all now 
making life easier for our .NET brethen. OSS works because places like 
the ASF and SourceForge *let* it work. And it works everywhere, even on 
vendor "strangle-hold" platforms like .NET.

Over the past three years, the 40+ developers who have directly 
contributed to Struts -- and the thousands of others who helping out on 
Bugzilla, and the list, and the other support forums -- have proven 
(once again) that community-supported development does work, and that 
we'd all be poorer without it!

New specifications, like JSF, just give us fertile new ground where we 
can continue to do what we do best -- share the wealth!

Some things never change =:)

-Ted.




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

Re: [GUMP] Build Failure - jakarta-struts

[Ted Husted]

I popped the release up in that directory, so it's available there at least.

The buildfile follows the same format as Struts and Struts-Faces, so it 
may just be matter of telling Sam, or whoever is managing Gump these 
days, to start building it.

What do we do when a Commons package is added to the mix?

-T.

Martin Cooper wrote:
We're going to have to find a way to get Gump to build struts-legacy. It
would be nice to get this working, given that the nightlies will be down for
a while. If anyone has any ideas, please speak up! ;-) Otherwise I'll try to
find some time to take a look, but it probably won't be today.
--
Martin Cooper


-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 2:34 AM
To: [EMAIL PROTECTED]
Subject: [GUMP] Build Failure - jakarta-struts

This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html>

Buildfile: build.xml

init:
[echo] - jakarta-struts 1.1-rc2 -
[echo] java.class.path = 
/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.j
ar:/home/rubys/jakarta/xml->
xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-x
erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xa
lan-> unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/jav
a/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/too
ls.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist
/lib/> ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/ho
me/rubys/jakarta/ant/dist/lib/ant->
stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/
home/rubys/jakarta/ant/dist/lib/ant->
trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home
/rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0->
stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servle
t.jar:/home/rubys/jakarta/jakarta-commons/beanutils/dist/commons->
beanutils.jar:/home/rubys/jakarta/jakarta-commons/collections/
dist/commons-collections.jar:/home/rubys/jakarta/jakarta-commo
ns/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta->
commons/digester/dist/commons-digester.jar:/home/rubys/jakarta
/jakarta-commons/fileupload/target/commons-fileupload-20030608
.jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang->
20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/
commons-logging.jar:/home/rubys/jakarta/jakarta-commons/loggin
g/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-com
mons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta->
commons/validator/dist/commons-validator.jar:/home/rubys/jakar
ta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/ja
karta-struts/target/library/classes:/home/rubys/jakarta/jakart
a-struts/target/tiles/library/classes
[echo] java.home = /usr/java/j2sdk1.4.1_02/jre
[echo] user.home = /home/rubys
prepare.dist:
   [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist
   [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/lib
   [mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/dist/webapps

prepare.library:
   [mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
   [mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META
-INF/tlds
   [mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/org/
apache/struts/resources

[copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
[copy] Copying 8 files to 
/home/rubys/jakarta/jakarta-struts/target/library/classes/org/
apache/struts/resources

[copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-struts/target/library
[copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-struts/target/library

BUILD FAILED
/home/rubys/jakarta/jakarta-struts/build.xml:251: Warning: 
Could not find file 
/home/rubys/jakarta/jakarta-struts/${struts-legacy.jar} to copy.

Total time: 2 seconds

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



--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


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

RE: Status check? - Houston we have a problem

[Martin Cooper]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 10:24 AM
> To: 'Struts Developers List'
> Subject: RE: Status check? - Houston we have a problem
> 
> 
> 
> 
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 4:37 AM
> > To: Struts Developers List
> > Subject: Re: Status check? - Houston we have a problem
> > 
> > 
> > I'm still play-testing the web apps against all three, but 
> here's an 
> > early warning:
> > 
> > Running the exercise app under Tomcat 3.3.1a
> > 
> > The logic-compare test kills container - nothing in log to 
> > indicate why. 
> > This is a big test, so it may be rendering problem. (TC41 is OK)
> 
> Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK
> 1.4.1_01). I didn't see that before, but maybe I was using an 
> earlier JVM.
> If I have time, I'll try that.

I just tried Sun JDK 1.4.0, and it kills that too. ;-(

Don't know if I have any others lying around. I'll see...

--
Martin Cooper


> 
> > 
> > Same result under NN and IE for Windows XP. The Tomcat test 
> > memory usage 
> > is under 50%.
> > 
> > Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),
> > 
> > http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp
> > 
> > Error: 500
> > Location: /struts-exercise-taglib/bean-cookie.jsp
> > Internal Servlet Error:
> > 
> > org.apache.jasper.JasperException: Class 
> > org.apache.jasper.runtime.JspRuntimeLibrary can not access a 
> > member of 
> > class org.apache.tomcat.facade.CookieFacade with modifiers "public"
> 
> The part of the test that is failing is:
> 
>   
> 
> The  tags earlier on the page succeeded. The only
> difference I can see is that the earlier ones all have 
> setters as well as
> getters in the Tomcat CookieFacade class, whereas there is 
> only a getter for
> 'name'. So this actually looks like some kind of 
> JSP/reflection bug, not
> related to Struts. (The  tag must have worked, 
> because we know
> the  tag is trying to access a cookie!)
> 
> --
> Martin Cooper
> 
> 
> > at 
> > org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(
> > JspRuntimeLibrary.java:430)
> > at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
> > at 
> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> > at 
> > org.apache.tomcat.facade.ServletHandler.doService(ServletHandl
> > er.java:574)
> > at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
> > at org.apache.tomcat.core.Handler.service(Handler.java:235)
> > at 
> > org.apache.tomcat.facade.ServletHandler.service(ServletHandler
> > .java:485)
> > at 
> > org.apache.tomcat.core.ContextManager.internalService(ContextM
> > anager.java:917)
> > at 
> > 
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
> > at 
> > org.apache.tomcat.modules.server.Http10Interceptor.processConn
> > ection(Http10Interceptor.java:176)
> > at 
> > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> > nt.java:494)
> > at 
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> > ThreadPool.java:516)
> > at java.lang.Thread.run(Thread.java:536)
> > Root cause:
> > java.lang.IllegalAccessException: Class 
> > org.apache.jasper.runtime.JspRuntimeLibrary can not access a 
> > member of 
> > class org.apache.tomcat.facade.CookieFacade with modifiers "public"
> > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
> > at java.lang.reflect.Method.invoke(Method.java:317)
> > at 
> > org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(
> > JspRuntimeLibrary.java:428)
> > at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
> > at 
> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> > at 
> > org.apache.tomcat.facade.ServletHandler.doService(ServletHandl
> > er.java:574)
> > at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
> > at org.apache.tomcat.core.Handler.service(Handler.java:235)
> > at 
> > org.apache.tomcat.facade.ServletHandler.service(ServletHandler
> > .java:485)
> > at 
> > org.apache.tomcat.core.ContextManager.internalService(ContextM
> > anager.java:917)
> > at 
> > 
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
> > at 
> > org.apache.tomcat.modules.server.Http10Interceptor.processConn
> > ection(Http10Interceptor.java:176)
> > at 
> > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> > nt.java:494)
> > at 
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> > ThreadPool.java:516)
> > at java.lang.Thread.run(Thread.java:536)
> > 
> > 
> > 
> > 
> > 
> -
> > To un

RE: [GUMP] Build Failure - jakarta-struts

[Martin Cooper]

We're going to have to find a way to get Gump to build struts-legacy. It
would be nice to get this working, given that the nightlies will be down for
a while. If anyone has any ideas, please speak up! ;-) Otherwise I'll try to
find some time to take a look, but it probably won't be today.

--
Martin Cooper


> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 2:34 AM
> To: [EMAIL PROTECTED]
> Subject: [GUMP] Build Failure - jakarta-struts
> 
> 
> 
> This email is autogenerated from the output from:
> <http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html>
> 
> 
> Buildfile: build.xml
> 
> init:
>  [echo] - jakarta-struts 1.1-rc2 -
> 
>  [echo] java.class.path = 
> /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.j
ar:/home/rubys/jakarta/xml->
xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-x
erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xa
lan-> unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/jav
> a/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/too
ls.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist
/lib/> ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/ho
me/rubys/jakarta/ant/dist/lib/ant->
stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/
home/rubys/jakarta/ant/dist/lib/ant->
trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home
/rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0->
stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servle
t.jar:/home/rubys/jakarta/jakarta-commons/beanutils/dist/commons->
beanutils.jar:/home/rubys/jakarta/jakarta-commons/collections/
> dist/commons-collections.jar:/home/rubys/jakarta/jakarta-commo
ns/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta->
commons/digester/dist/commons-digester.jar:/home/rubys/jakarta
> /jakarta-commons/fileupload/target/commons-fileupload-20030608
.jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang->
20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/
> commons-logging.jar:/home/rubys/jakarta/jakarta-commons/loggin
> g/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-com
mons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta->
commons/validator/dist/commons-validator.jar:/home/rubys/jakar
> ta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/ja
> karta-struts/target/library/classes:/home/rubys/jakarta/jakart
> a-struts/target/tiles/library/classes
>  [echo] java.home = /usr/java/j2sdk1.4.1_02/jre
>  [echo] user.home = /home/rubys
> 
> prepare.dist:
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist
> [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/lib
> [mkdir] Created dir: 
> /home/rubys/jakarta/jakarta-struts/dist/webapps
> 
> prepare.library:
> [mkdir] Created dir: 
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
> [mkdir] Created dir: 
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META
> -INF/tlds
> [mkdir] Created dir: 
> /home/rubys/jakarta/jakarta-struts/target/library/classes/org/
apache/struts/resources
>  [copy] Copying 1 file to 
> /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
>  [copy] Copying 8 files to 
> /home/rubys/jakarta/jakarta-struts/target/library/classes/org/
apache/struts/resources
>  [copy] Copying 1 file to 
> /home/rubys/jakarta/jakarta-struts/target/library
>  [copy] Copying 1 file to 
> /home/rubys/jakarta/jakarta-struts/target/library
> 
> BUILD FAILED
> /home/rubys/jakarta/jakarta-struts/build.xml:251: Warning: 
> Could not find file 
> /home/rubys/jakarta/jakarta-struts/${struts-legacy.jar} to copy.
> 
> Total time: 2 seconds
> 
> -
> 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]

RE: Status check? - Houston we have a problem

[Martin Cooper]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:37 AM
> To: Struts Developers List
> Subject: Re: Status check? - Houston we have a problem
> 
> 
> I'm still play-testing the web apps against all three, but here's an 
> early warning:
> 
> Running the exercise app under Tomcat 3.3.1a
> 
> The logic-compare test kills container - nothing in log to 
> indicate why. 
> This is a big test, so it may be rendering problem. (TC41 is OK)

Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK
1.4.1_01). I didn't see that before, but maybe I was using an earlier JVM.
If I have time, I'll try that.

> 
> Same result under NN and IE for Windows XP. The Tomcat test 
> memory usage 
> is under 50%.
> 
> Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),
> 
> http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp
> 
> Error: 500
> Location: /struts-exercise-taglib/bean-cookie.jsp
> Internal Servlet Error:
> 
> org.apache.jasper.JasperException: Class 
> org.apache.jasper.runtime.JspRuntimeLibrary can not access a 
> member of 
> class org.apache.tomcat.facade.CookieFacade with modifiers "public"

The part of the test that is failing is:

  

The  tags earlier on the page succeeded. The only
difference I can see is that the earlier ones all have setters as well as
getters in the Tomcat CookieFacade class, whereas there is only a getter for
'name'. So this actually looks like some kind of JSP/reflection bug, not
related to Struts. (The  tag must have worked, because we know
the  tag is trying to access a cookie!)

--
Martin Cooper


>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(
> JspRuntimeLibrary.java:430)
>   at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
>   at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
>   at 
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandl
> er.java:574)
>   at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
>   at org.apache.tomcat.core.Handler.service(Handler.java:235)
>   at 
> org.apache.tomcat.facade.ServletHandler.service(ServletHandler
> .java:485)
>   at 
> org.apache.tomcat.core.ContextManager.internalService(ContextM
> anager.java:917)
>   at 
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
>   at 
> org.apache.tomcat.modules.server.Http10Interceptor.processConn
> ection(Http10Interceptor.java:176)
>   at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> nt.java:494)
>   at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:516)
>   at java.lang.Thread.run(Thread.java:536)
> Root cause:
> java.lang.IllegalAccessException: Class 
> org.apache.jasper.runtime.JspRuntimeLibrary can not access a 
> member of 
> class org.apache.tomcat.facade.CookieFacade with modifiers "public"
>   at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
>   at java.lang.reflect.Method.invoke(Method.java:317)
>   at 
> org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(
> JspRuntimeLibrary.java:428)
>   at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
>   at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
>   at 
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandl
> er.java:574)
>   at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
>   at org.apache.tomcat.core.Handler.service(Handler.java:235)
>   at 
> org.apache.tomcat.facade.ServletHandler.service(ServletHandler
> .java:485)
>   at 
> org.apache.tomcat.core.ContextManager.internalService(ContextM
> anager.java:917)
>   at 
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
>   at 
> org.apache.tomcat.modules.server.Http10Interceptor.processConn
> ection(Http10Interceptor.java:176)
>   at 
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi
> nt.java:494)
>   at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:516)
>   at java.lang.Thread.run(Thread.java:536)
> 
> 
> 
> 
> -
> 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]

DO NOT REPLY [Bug 20586] - [PATCH] Add neteye ActionCache to extensions

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20586

[PATCH] Add neteye ActionCache to extensions

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 20586] - [PATCH] Add neteye ActionCache to extensions

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20586

[PATCH] Add neteye ActionCache to extensions





--- Additional Comments From [EMAIL PROTECTED]  2003-06-08 15:37 ---
Created an attachment (id=6693)
See description above

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

DO NOT REPLY [Bug 20586] New: - [PATCH] Add neteye ActionCache to extensions

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20586

[PATCH] Add neteye ActionCache to extensions

   Summary: [PATCH] Add neteye ActionCache to extensions
   Product: Struts
   Version: Nightly Build
  Platform: Other
   URL: http://jakarta.apache.org/struts/resources/extensions.ht
ml
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Patch below:

Add neteye ActionCache (http://actioncache.neteye.de) to resources and fix 
formatting for link to JDeveloper

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

Re: Status check?

[Ted Husted]

Martin Cooper wrote:
You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o.
I've created the .asc signature files, and the .md5 digest files, but only
for the .tar.gz and .zip files, since we don't usually release the .tar
files. (They're only needed to produce the .tar.gz files.)
OK, got 'em. Thanks!

-T.



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

Bug report for Struts [2003/06/08]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application|
|16296|Opn|Enh|2003-01-21|Add "action" attribute to   |
|16565|New|Enh|2003-01-29|Incorrect path returned by getActionMappingName du|
|16634|New|Enh|2003-01-31|reuiredif ignores missing property|
|16774|New|Enh|2003-02-04|Standard actions should throw exceptions instead o|
|16776|Opn|Enh|2003-02-04|Add paramValue attribute to  tag   |
|16792|Ass|Enh|2003-02-05|Migrate to commons-resources for message resources|
|16804|New|Enh|2003-02-05|html:text tag has no filter attribute |
|16814|New|Enh|2003-02-05|Add a generalized utililty class to expose informa|
|16971|New|Enh|2003-02-11|"multiple" attribute on select tag should not rend|
|17117|New|Enh|2003-02-17|Add a DispatchAction that is configurable via Acti|
|17234|New|Enh|2003-02-20|language attr for html:form's and html:javascript'|
|17276|New|Enh|2003-02-21|processRoles returns 400 (Bad request)|
|17281|New|Enh|2003-02-21|Add validateLongRange to Validator|
|17418|New|Enh|2003-02-26| should not render newlines  |
|17449|New|Enh|2003-02-26|Allow relative URL in action attribute of  tag |
|18002|Ass|Enh|2003-03-14|[RFE] LookupDispatchAction doesn't handle Cancel o|
|18022|New|Enh|2003-03-14|HttpSessionBindingListener.valueUnbound() called o|
|18032|Opn|Enh|2003-03-16| tag appending session doesn't work with|
|18107|New|Enh|2003-03-18|contextRelative enhancement to  tag  |
|18111|New|Enh|2003-03-18|contextRelative enhancement to  t|
|18127|New|Enh|2003-03-18|Add DigestingPlugIn   |
|18142|New|Enh|2003-03-19|LabelValueBean default constructor|
|18221|New|Enh|2003-03-21|Move custom taglibs into their own jar/distributio|
|18255|New|Enh|2003-03-23|Japanese Message Resorces for struts-example  |
|18289|New|Enh|2003-03-24|Dynamic Message Resources |
|18293|New|Enh|2003-03-24|Loading language files does not use Resource Bundl|
|18370|New|Enh|2003-03-26|generate MANIFEST.MF with ant task|
|18426|New|Enh|2003-03-27|Add Tiles Support to  tag. |
|18583|New|Enh|2003-04-01| creates exceptions in normal flow  |
|18788|New|Enh|2003-04-07|Multiple input hook for multipage forms in process|
|18798|New|Enh|2003-04-08|Configure ActionServlet DataSource logging|
|18873|New|Enh|2003-04-09|Style deprecation messages during build   |
|18904|New|Enh|2003-04-10|Producing P3P header and in particular Compact Pol|
|18981|New|Enh|2003-04-13|File upload maximum size validator|
|18993|New|Enh|2003-04-14|required JavaScript validation doesn't work with m|
|19022|New|Enh|2003-04-15|Add execute()-method to o.a.s.tiles.Controller|
|19161|New|Enh|2003-04-18|validateDate javascript validation doesn't handle |
|19256|New|Enh|2003-04-23|Enhancement for dynamic link creation |
|19299|New|Enh|2003-04-24| locale function should specify the cou|
|19346|New|Enh|2003-04-26|Errors and Messages should be easier to manage|
|19360|New|Enh|2003-04-27|Misleading tests for (form == null)   |
|19420|New|Enh|2003-04-29|BaseHandlerTag should use its getter methods  |
|19539|New|Enh|2003-05-02|Add checks for List and Map-backed properties in D|
|19625|New|Enh|2003-05-03|DynaActionForm with LazyList support and WrapDynaA|
|19631|New|Enh|2003-05-04|Enhancements to RequestUtils tests|
|19780|Opn|Enh|2003-05-08| does not seem to support java.uti|
|19802|New|Enh|2003-05-09|Configurable processPopulate()|
|19809|New|Enh|2003-05-09|[Patch] Update stxx URL and description   |
|19812|New|Enh|2003-05-10|BaseFieldTag don't use ConvertUtils as String outp|
|19891|New|Enh|2003-05-13|Provide a pointer to the WML tag libraries in the |
|19901|New|Enh|2003-05-13|Validator can't handle null page value in DynaVali|
|19903|New|Enh|2003-05-13|Field considered valid i

Re: What's next for Struts?

[Ted Husted]

Craig R. McClanahan wrote:
No, Struts is definitely not dead.  
=:) Those rumors have been greatly exaggerated! The Struts Committers 
have been a bit busy the last year or so with parceling Struts into 
Commons components and all. But the Struts Community has been shipping, 
shipping, shipping.

For example, Don Brown is shipping extensions for using Struts with 
Cocoon and the Bean Scripting Framework, and as of today, Wildcard 
Actions. Mathias just released an update to his very useful workflow 
extension. James keeps bringing out Console after Console. Just to name 
a few. (Need to get that Resource page updated before final ships!)

And of course, there are the long-standing XLST, Velocity, SSL, and 
JUnit extension for Struts, doclet extensions for Struts, database 
extension for Struts, and surely many things I haven't heard of yet!

And, as Craig pointed out, Struts is not the only place where people are 
developing MVC frameworks. WebWorks demonstrated the usefulness of a 
unified Controller (or "Action") objects. Other frameworks like Maverick 
and JPublish are showing us how very different approaches to handling 
actions (as well as screens) can all be used within the same framework.

The point is that no matter how good JSF will be, or how good Struts is 
now, there will always be "more dreamed of" than what we happen to stuff 
in our distributions! There will always be gaps where open-source 
developers, like us, can jump in and start sharing our solutions.

This is true not only of Java, but of any platform. For example, most of 
us know that .NET lacks many of the high-level tools we all use and 
love. OSS, like nature, abhors a vacuum. So, OSS volunteers have been 
busily porting many of our favorite tools "to the dark side". Packages 
like Maverick, Velocity, and Log4*, again to name a few, are all now 
making life easier for our .NET brethen. OSS works because places like 
the ASF and SourceForge *let* it work. And it works everywhere, even on 
vendor "strangle-hold" platforms like .NET.

Over the past three years, the 40+ developers who have directly 
contributed to Struts -- and the thousands of others who helping out on 
Bugzilla, and the list, and the other support forums -- have proven 
(once again) that community-supported development does work, and that 
we'd all be poorer without it!

New specifications, like JSF, just give us fertile new ground where we 
can continue to do what we do best -- share the wealth!

Some things never change =:)

-Ted.



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

Re: Status check?

[Ted Husted]

Craig R. McClanahan wrote:
The nightly directories get any file older than five days cleaned out --
and, because I'm not able to deal with getting them published in the time
I'm at JavaOne, that means a "somewhere else or nothing" policy is
important.
Understood and agreed. Making the s-f distruibution available to the 
community is more important that observing the letter of our procecures. 
(Apache was made for developers, not developers for Apache.)

That being said, we definitely need to figure out a strategy for stuff not
in Struts core but having "releases" by whatever definition is
appropriate.
+1. All the optional components, the original struts-tags, struts-el, 
tiles, validator, struts-faces, should all have their own release 
cycles. We need to emphasize  the fact that Strut is (and always has 
been) pluggable, and everyone's favorite flavor of the day will work 
just fine. The only thing that really needs to be in the struts-core is 
the Action package and its direct dependencies.

For Struts-faces, I think if you just call for a [VOTE] when you get 
back, we can just release it as a milestone, like anything else. So long 
as it's a positive vote, and we get the minimum three binding +1s, we 
could just leave them there.

-T.



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

Re: Status check? - Houston we have a problem

[Ted Husted]

So, I tried it under Tomcat 3.3.1 (no a), with the same result. =:(

I had compiled the release under servlet 2.3, but I redid it under 
servlet 2.2 with the same result.

I don't use cookies much, and off-hand I don't know if it's a problem 
with the test, Tomcat, or Jasper. The other cats are happy, though. And 
everything else for TC3 is nominal

I suspect that the comparison test would pass, but that Jasper is 
running out of resources. If there's a way to reconfigure TC3 so this 
one will run, let me know.

I'm also seeing some Servlet Exceptions in the tiles example for TC3 
that don't appear for the TC4s. For example,

http://localhost:8080/tiles-documentation/tutorial/extendedDefinitionTag.jsp

throws

[ServletException in:/common/menuViewSrc.jsp] 
TOMCAT/JSP/common/menuViewSrc.jsp'

but only in TC3.

So, pending advice from the other committers, the release seems to be 
stalled, since our exercise-taglib tests and some of our 
tiles-documentation pages do not seem to run successfully against one of 
our "supported" containers.

Tiles is an optional component, so I could live with there being TC3 
issues for that (if we document them). But I'm not sure what to think 
about the cookies error.

-T.

Ted Husted wrote:
I'm still play-testing the web apps against all three, but here's an 
early warning:

Running the exercise app under Tomcat 3.3.1a

The logic-compare test kills container - nothing in log to indicate why. 
This is a big test, so it may be rendering problem. (TC41 is OK)

Same result under NN and IE for Windows XP. The Tomcat test memory usage 
is under 50%.

Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),

http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp

Error: 500
Location: /struts-exercise-taglib/bean-cookie.jsp
Internal Servlet Error:
org.apache.jasper.JasperException: Class 
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of 
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
at 
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430) 

at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at 
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) 

at 
org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) 

at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) 

at java.lang.Thread.run(Thread.java:536)
Root cause:
java.lang.IllegalAccessException: Class 
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of 
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
at java.lang.reflect.Method.invoke(Method.java:317)
at 
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428) 

at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at 
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) 

at 
org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176) 

at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) 

at java.lang.Thread.run(Thread.java:536)



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



--
Ted Husted,
Struts in Action 


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

Re: Status check?

[Max Cooper]

I have been struggling with this for another project, too. Ideally, it would
be great to have a "continuous integration" build that would also deploy and
test the app(s) in a bunch of containers automatically. You'd still have to
install and configure some deployment details, of course, but it would be
nice to have a machine with a bunch of containers on it that would run and
test builds in all of them automatically. I imagine the same system could be
used to deploy to a developer's favorite container or containers for local
testing on a much smaller scale.

Are there any projects out there intended to make it easier to test the same
app(s) in a variety of containers?

-Max

- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, June 06, 2003 3:39 PM
Subject: Re: Status check?


> Martin Cooper wrote:
> > For the main Struts release, the most time-consuming part is just
testing
> > that everything works with all the supported containers (including all
the
> > web apps).
>
> So, I take it we would be satisfied with testing our sample applications
>   against the binary distribution (rather than against all the
> permutations of Java 1.2, 1.3, 1.4, and Servlet 2.2 and 2.3).
>
> And then for Cactus, I take it we would run TC 3.3 against Servlet 2.2,
> and TC 4.x against Servlet 2.3, as that would be the expected use.
>
> -Ted.
>
>
>
> -
> 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]

Re: Status check?

[Max Cooper]

I've gotten some requests for a list of library file versions for my
SecurityFilter project, so I've been looking into automatically creating a
file that lists the library file versions as part of my build. The idea was
to use the version information from the manifest files from the jars.
However, many projects do not provide this information in their jars, or at
least not the correct info.

The commons projects are pretty good compared to the other dependencies I
have, but commons-beanutils reports 1.6 for the 1.6.1 release, and
commons-digester has "1.5" (with the quotes) for the 1.5 release. The quotes
aren't a big deal since anyone reading it would correctly recognize it as
the 1.5 release. But commons-beanutils would mislead you to think you had
1.6 when it was really 1.6.1.

commons-logging has good version info
commons-codec has a good Implementation-Version number (which is what I
would use anyway)
commons-collections has good version info
jakarta-oro is pretty good, but adds a date and time to the
Implementation-Version in additon to the correct version number, which might
be confusing
I'm not sure about other commons (oops, I mean jakarta-commons ;-))
projects.

I think it is ideal to set things up so you can just do a cvs checkout or
update with a tag to get all the files you need to build a particular
release. It seems weird to tag another project's tree with your release,
though, if the current setup would require tagging commons project trees
when there is a Struts release. This is perhaps a good reason to commit the
library jars in the struts CVS tree, or do something Maven-like where your
project specifies what versions of external dependencies you need and it
retrieves them into a shared local repository. I think there is an Ant
extension that will do retrieval like Maven.

I don't know if you guys ever do this, but I have in the past moved some
files CVS repositories by moving the repository file (ends in ,v) itself.
After doing that a few times, I have given up the practice since it screws
up the history -- the file will be in the wrong place if you do a checkout
based on a tag that existed before the move. It's better to just remove the
old file and add it in the new location with a CVS client rather than
mucking with the repository files, but you get a discontinuity in the
history that way. I am hopeful that Subversion will support real moves, and
will catch on enough to displace CVS some day.

-Max

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 06, 2003 1:48 PM
Subject: Re: Status check?


> It makes more sense to me to *not* tag the commons files with Struts.  The
> commons doesn't need to be notified every time Struts cuts a release.  The
> commons jars contain version information in their manifests so it would be
> very easy to recreate an old Struts build by looking there.
>
> David



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

Re: Status check? - Houston we have a problem

[Ted Husted]

I'm still play-testing the web apps against all three, but here's an 
early warning:

Running the exercise app under Tomcat 3.3.1a

The logic-compare test kills container - nothing in log to indicate why. 
This is a big test, so it may be rendering problem. (TC41 is OK)

Same result under NN and IE for Windows XP. The Tomcat test memory usage 
is under 50%.

Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),

http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp

Error: 500
Location: /struts-exercise-taglib/bean-cookie.jsp
Internal Servlet Error:
org.apache.jasper.JasperException: Class 
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of 
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
	at 
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430)
	at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java)
	at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
	at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
	at org.apache.tomcat.core.Handler.service(Handler.java:235)
	at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
	at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
	at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
	at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
	at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
	at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
	at java.lang.Thread.run(Thread.java:536)
Root cause:
java.lang.IllegalAccessException: Class 
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of 
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
	at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
	at java.lang.reflect.Method.invoke(Method.java:317)
	at 
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428)
	at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java)
	at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
	at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
	at org.apache.tomcat.core.Handler.service(Handler.java:235)
	at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
	at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
	at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
	at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
	at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
	at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
	at java.lang.Thread.run(Thread.java:536)



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

[GUMP] Build Failure - jakarta-struts

[Craig McClanahan]

This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html>


Buildfile: build.xml

init:
 [echo] - jakarta-struts 1.1-rc2 -

 [echo] java.class.path = 
/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xalan-unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/java/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist/lib/ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/home/rubys/jakarta/ant/dist/lib/ant-stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/home/rubys/jakarta/ant/dist/lib/ant-trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home/rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0-stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servlet.jar:/home/rubys/jakarta/jakarta-commons/beanutils/dist/commons-beanutils.jar:/home/rubys/jakarta/jakarta-commons/collections/dist/commons-collections.jar:/home/rubys/jakarta/jakarta-commons/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta-commons/digester/dist/commons-digester.jar:/home/rubys/jakarta/jakarta-commons/fileupload/target/commons-fileupload-20030608.jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang-20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-commons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta-commons/validator/dist/commons-validator.jar:/home/rubys/jakarta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/jakarta-struts/target/library/classes:/home/rubys/jakarta/jakarta-struts/target/tiles/library/classes
 [echo] java.home = /usr/java/j2sdk1.4.1_02/jre
 [echo] user.home = /home/rubys

prepare.dist:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist
[mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/webapps

prepare.library:
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF/tlds
[mkdir] Created dir: 
/home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/struts/resources
 [copy] Copying 1 file to 
/home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF
 [copy] Copying 8 files to 
/home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/struts/resources
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library

BUILD FAILED
/home/rubys/jakarta/jakarta-struts/build.xml:251: Warning: Could not find file 
/home/rubys/jakarta/jakarta-struts/${struts-legacy.jar} to copy.

Total time: 2 seconds

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

Re: Status check?

[Ted Husted]

Vic Cekvenich wrote:
> I downloaded and it apears to work with a sample app of mine, just
> FYI.
Phil Steitz wrote:
Ted,

Don't know if this is useful, but I did the following successfully:

1. Hack build.xml to remove "compile.library" depends for tomcat, junit 
test targets.

2. Replace contents of /target/library with 
jararta-struts-1.1-rc2-lib

3. execute test.tomcat.all and test.junit targets using the hacked 
build.xml.  All tests ran clean and no compile targets were executed.

I do not have tc 3 installed, so only the 40 and 41 tc tests ran, 
hitting tc 4.04 and 4.1.24 resp.  I ran once using (Sun Linux) JDK 
1.4.1_01 and once using JDK 1.3.1_03.
Thanks, guys. More eyes always help. =:)

I'll have some (liquid) java and run through the standard suite now, and 
then we can ship this puppy!

-Ted.



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