contributor extension: actioncache
The neteye actioncache is an extension that provides a simple but powerful caching facility for struts. Sources and javadocs can be found at http://actioncache.neteye.de -felix -- Felix Gnass [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Update Validator version included with Struts
It looks like you're right. I just got the 20021210 build and the validator is fixed. Dave From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Update Validator version included with Struts Date: Mon, 9 Dec 2002 20:30:24 -0800 (PST) On Mon, 9 Dec 2002, David Graham wrote: Can we upgrade to a current nightly of the Validator in our Struts nightlies? I just spent several hours debugging a mysterious javascript error only to find that it was a validator bug that has been fixed since 12/3. I queried the bugs on validator and there's only one open that isn't very serious so it seems safe to upgrade. I believe Craig runs the builds so what do you think? Hmm, my understanding is that Craig's nightly build process always picks up the latest of everything. If you're sure the latest nightlies are not including the latest Validator code, that suggests there might be a glitch in the build process. -- Martin Cooper Thanks, David _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5286] - struts logic:redirect tag not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5286. 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=5286 struts logic:redirect tag not working [EMAIL PROTECTED] changed: What|Removed |Added Version|1.0 Final |1.1 Beta 2 --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 21:11 --- I encountered this behavior as well. The war file I used is: http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/jakarta-struts- 1.1-b2-blank.war The app server is Websphere 3.5.5 ptf50141.03 of 18 OCT 2001 on AIX 5.1 I had to make a copy of the web/WEB-INF dir and put it in the servelets dir and extract the DTDs from struts.jar and put them in the servelets dir (hierarchy intact) to resolve some classloader behavior differences with Websphere. Otherwise the war is as supplied. I don't really want to change the status because it very well could be a websphere issue. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Hello, all.
Hi guys, Normally I just lurk here, but I did want to comment on a stmt pertaining to Barraucda. Barracuda is an impressive framework. It also has quite a powerful event model which struts lacks. The rendering seems tied to XMLC however. Barracuda, as its currently implemented _is_ tied to XMLC in two specific places: it uses XMLC to load the DOMs, and it uses XMLC to actually render the processed DOMs. But that's it - everything else is specific to the DOM api; we designed it that way intentionally. So decoupling from XMLC is fairly straightforward - you provide something to load the DOM, and you provide a renderer to actually stream the processed DOM back to the client. That's it. Now, we don't have another loader/renderer currently in the project, but that is on the todo list (Q1 2003 hopefully). it must be said from this experience that struts certainly doesnt tie you down to a particular view technology. :-) Just to be clear, Barracuda doesn't tie you to a particular rendering technology either; it is possible to use just the event model and to skip the component stuff altogether. Heck, you could actually probably use Barracuda as your controller and JSPs to render if you really wanted to. What Barracuda _doesn't_ try to do is make it any easier to JSP related stuff...if you need to use JSPs, then there are plenty of frameworks out there to consider (and Struts is certainly among the best I've seen). Struts is exciting because it has such momentum. Barracuda is exciting because it is the most complete MVC framework I've seen. I think this is a fair assessment (of course I'm biased ;-) Struts does have momentum, but the question is why? After all, MS's .NET stuff has momentum too... My point here is simply that momentum does not _necessarily/automatically_ mean something is good; coporate interests on both sides of the isle regularly try their hardest to generate momentum as a means to achieving developer adoption. This is particularly true of MS, but Sun does it too...there are many reasons that they have hitched their horses to the JSP wagon, but one of the major ones has to do with positioning against MS's ASP (not the architectural pro's/con's of JSP over and against other alternatives). Now, please note that I'm _not_ suggesting that all of Struts momentum has been manufactured; if you're stuck with JSP, then Struts is a lifesaver. The great thing about a project like Struts (and other open-source efforts) is that most of the growth comes from the community, rather than the industry; its driven from the grassroots. What I _am_ saying however, is that Barracuda was not created for the purpose of generating momentum (well, maybe that's what Lutris wanted). The primary focus of the developers involved, however, was to step back and say let's try really rethinking this whole problem space and see if we can come up with a way to really do it right. And so we evaluated all the other approaches we could find, and tried to learn from them, and tried to apply lessons learned from client-server development in a stated environment. But the emphasis was on architecture, not momentum. I've always felt that if Barracuda could get the architecture right, then it would make it much easier to build the type of RAD tool integration that made client server development so much easier, and that in turn would take care of any momentum issues. What actually amazes me is the measure of adoption Barracuda has already achieved, given the fact that we've still been focusing on architecture rather than ease of use. At any rate, I've digressed. Sorry to take up Struts bandwidth talking about Barracuda, but I think that both projects have good ideas and figure a little intellectual cross-pollination never hurt anyone. Cheers! Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- Coffee? I could quit anytime, just not today -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/tiles/xmlDefinition XmlParser.java
martinc 2002/12/10 22:30:22
Modified:src/share/org/apache/struts/tiles/xmlDefinition
XmlParser.java
Log:
Allow the Digester to use the context class loader when parsing Tiles
definitions.
PR: 15035
Submitted by: Everett Toews (Thanks for the comprehensive explanation!)
Revision ChangesPath
1.6 +4 -4
jakarta-struts/src/share/org/apache/struts/tiles/xmlDefinition/XmlParser.java
Index: XmlParser.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/xmlDefinition/XmlParser.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- XmlParser.java16 Nov 2002 04:24:36 - 1.5
+++ XmlParser.java11 Dec 2002 06:30:21 - 1.6
@@ -119,7 +119,7 @@
digester.setDebug(digesterDebugLevel);
digester.setValidating(validating);
digester.setNamespaceAware(true);
- //digester.setUseContextClassLoader(true);
+ digester.setUseContextClassLoader(true);
// Register our local copy of the DTDs that we can find
for (int i = 0; i registrations.length; i += 2) {
URL url = this.getClass().getResource(registrations[i+1]);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15035] - Struts 1.1-b2 (using Tiles) with JBoss 3.0.3_Tomcat_4.1.12 non-existant ClassLoader problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15035. 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=15035 Struts 1.1-b2 (using Tiles) with JBoss 3.0.3_Tomcat_4.1.12 non-existant ClassLoader problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 06:32 --- Fixed in 20021211 nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Hello, all.
Christian, Glad to know your hear lurking! I think that was my original point when bringing up Barracuda. Struts can learn alot from Barracuda going forward. Each certainly has its' place of superiority but due to the focus of Barracuda being architecture which I've always thought it demonstratedThe intellectual mind share between the two projects can only be helpful for both! -Daniel -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 9:26 PM To: Struts Developers List Subject: RE: Hello, all. Hi guys, Normally I just lurk here, but I did want to comment on a stmt pertaining to Barraucda. Barracuda is an impressive framework. It also has quite a powerful event model which struts lacks. The rendering seems tied to XMLC however. Barracuda, as its currently implemented _is_ tied to XMLC in two specific places: it uses XMLC to load the DOMs, and it uses XMLC to actually render the processed DOMs. But that's it - everything else is specific to the DOM api; we designed it that way intentionally. So decoupling from XMLC is fairly straightforward - you provide something to load the DOM, and you provide a renderer to actually stream the processed DOM back to the client. That's it. Now, we don't have another loader/renderer currently in the project, but that is on the todo list (Q1 2003 hopefully). it must be said from this experience that struts certainly doesnt tie you down to a particular view technology. :-) Just to be clear, Barracuda doesn't tie you to a particular rendering technology either; it is possible to use just the event model and to skip the component stuff altogether. Heck, you could actually probably use Barracuda as your controller and JSPs to render if you really wanted to. What Barracuda _doesn't_ try to do is make it any easier to JSP related stuff...if you need to use JSPs, then there are plenty of frameworks out there to consider (and Struts is certainly among the best I've seen). Struts is exciting because it has such momentum. Barracuda is exciting because it is the most complete MVC framework I've seen. I think this is a fair assessment (of course I'm biased ;-) Struts does have momentum, but the question is why? After all, MS's .NET stuff has momentum too... My point here is simply that momentum does not _necessarily/automatically_ mean something is good; coporate interests on both sides of the isle regularly try their hardest to generate momentum as a means to achieving developer adoption. This is particularly true of MS, but Sun does it too...there are many reasons that they have hitched their horses to the JSP wagon, but one of the major ones has to do with positioning against MS's ASP (not the architectural pro's/con's of JSP over and against other alternatives). Now, please note that I'm _not_ suggesting that all of Struts momentum has been manufactured; if you're stuck with JSP, then Struts is a lifesaver. The great thing about a project like Struts (and other open-source efforts) is that most of the growth comes from the community, rather than the industry; its driven from the grassroots. What I _am_ saying however, is that Barracuda was not created for the purpose of generating momentum (well, maybe that's what Lutris wanted). The primary focus of the developers involved, however, was to step back and say let's try really rethinking this whole problem space and see if we can come up with a way to really do it right. And so we evaluated all the other approaches we could find, and tried to learn from them, and tried to apply lessons learned from client-server development in a stated environment. But the emphasis was on architecture, not momentum. I've always felt that if Barracuda could get the architecture right, then it would make it much easier to build the type of RAD tool integration that made client server development so much easier, and that in turn would take care of any momentum issues. What actually amazes me is the measure of adoption Barracuda has already achieved, given the fact that we've still been focusing on architecture rather than ease of use. At any rate, I've digressed. Sorry to take up Struts bandwidth talking about Barracuda, but I think that both projects have good ideas and figure a little intellectual cross-pollination never hurt anyone. Cheers! Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- Coffee? I could quit anytime, just not today -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15192] - Property Descriptor Utility Cache needs a way to clear it.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192. 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=15192 Property Descriptor Utility Cache needs a way to clear it. [EMAIL PROTECTED] changed: What|Removed |Added Component|Utilities |Bean Utilities Product|Struts |Commons Version|1.0.2 Final |unspecified -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15192] - Property Descriptor Utility Cache needs a way to clear it.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192. 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=15192 Property Descriptor Utility Cache needs a way to clear it. [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |commons- |[EMAIL PROTECTED] |[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14800] - Fix initialization bug and add size parameter to form-property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14800. 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=14800 Fix initialization bug and add size parameter to form-property [EMAIL PROTECTED] changed: What|Removed |Added Component|Standard Actions|Utilities -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
