RE: [Forward-Looking] Struts and JavaServer Faces
First of all, thanks for your comments on this mailing list and JDC JSF forum. I also made some comments below. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 1:09 AM To: IAS Cc: [EMAIL PROTECTED] Subject: RE: [Forward-Looking] Struts and JavaServer Faces On Mon, 14 Oct 2002, IAS wrote: Date: Mon, 14 Oct 2002 15:13:45 +0900 From: IAS [EMAIL PROTECTED] To: 'Craig R. McClanahan' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Forward-Looking] Struts and JavaServer Faces AS I posted some question on http://forum.java.sun.com/thread.jsp?forum=427thread=308727, I have been very curious about how Apache Jakarta Project will respond to JSF. According to your comments, struts-faces.jar seems like a JSF implementation provided by Struts project, therefore it is open source and subject to Apache Licensing. What interests me is whether struts-faces.jar will become (de facto) RI for JSF like Tomcat for SRV/JSP or not (meaning struts-faces.jar is just a component of struts for supporting JSF). The struts-faces.jar library is ***not*** an implementation of JSF -- it is simply an adapter layer that lets you use Struts with any JSF implementation, plus a couple of Struts-specific JSF components. Calling struts-faces.jar a JSF implementation is not only taking my words way out of context, it is also distorting the meaning of what I did say. Thanks in advance for your opinion. IAS Craig Indepedent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 3:10 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Forward-Looking] Struts and JavaServer Faces Many folks on both the STRUTS-DEV and STRUTS-USER mailing lists, have wondered at what the future holds for Struts, now that the initial early access release of JavaServer Faces has become available. Here is a snapshot of my current thinking on the subject. BACKGROUND: == JavaServer Faces (JSF) is being developed as JSR 127 under the Java Community Process, with the goal of creating a standard framework for user interface components to be used in web applications. Included will be the following basic features: * User interface component model * Event handling model * Validation framework * Flexible rendering model (plugin support for rendering different kinds of HTML, or different markup languages and technologies) * A standard RenderKit (and associated Renderers) for generating basic HTML/4.01 markup. This library is primarily for making JSF useful out of the box, and allow apps to be portable across JSF implementations. However, we expect a lot of innovation in this area among competing JSF implementations. All of the above functionality is available via standard Java APIs, and is thus not tied to JavaServer Pages (JSP). However, because a large majority of JSF users will also be using JSP, an additional set of requirements is included in the JSF specification, including: * A standard tag library for generic things that are independent of the specific RenderKit in use (such as adding a validator to a component). * A standard tag library for the basic HTML RenderKit, with a tag for each combination of a component type and a method of rendering that component type. An example will make this clearer -- consider the UISelectOne component, which represents a list of options, and allows only a single option from the list to be selected. Such a component can be rendered in three different ways (in the basic HTML RenderKit), each with a different Renderer and a corresponding custom tag: h:selectone_listbox Display a list of all the possible options (expanding the box to include all of them so that no scrollbar is required). h:selectone_menuDisplay as a combo box (the traditional HTML select element with size=1). h:selectone_radio Display as a set of radio buttons and corresponding labels. Note that the application developer doesn't know or care which mechanism was used to display this component -- that's up to the page author, who will pick the desired representation by virtue of which tag he or she selects (at the Java API level, you make this choice by setting the rendererType property on the component instance). This is one of the many advances that JSF provides over Struts tags, where there is one and only one way to render each
DO NOT REPLY [Bug 13686] New: - Struts 1.1 Beta 2 and Iplanet Web Server 6
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=13686. 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=13686 Struts 1.1 Beta 2 and Iplanet Web Server 6 Summary: Struts 1.1 Beta 2 and Iplanet Web Server 6 Product: Struts Version: 1.1 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Struts 1.1 Beta 2 does not seem to work under Iplanet 6. I tried running the Struts 1.1 example and blank web apps with Iplanet SP1, SP2, and SP4 ( which is the latest), with JDK 1.3.1_01 and 1.3.1_05 with no success. I deployed the blank application and example application and they all came back with the same problem. Eventually I got it working but I had to modify some of the struts code. I have included what I had to do in the bug report, and the lines of code that are causing the problem. The following are the problems I encountered with the blank application with Iplanet 6 SP4, and JDK 1.3.1_05, running on a Windows XP machine ( also on Windows NT). Note that I have no problems running the 1.0.2 struts examples on the same machine. In order to reproduce these problem simply install Iplanet 6 SP4 and deploy the blank application to it. Nothing else required. The first problem encountered is the commons-logging.jar problem. To solve this under Iplanet 6 you must use the commons-logging.jar library version 1.0.2. None of the other versions seem to work, they all come back with Null pointer Exceptions ( even if you configure logging as per the documentation ) : Internal error: Unexpected error condition thrown (unknown exception,no description), stack: java.lang.ExceptionInInitializerError: java.lang.NullPointerException at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:326) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:375) at org.apache.struts.action.ActionServlet.clinit(ActionServlet.java:375) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance (Class.java:232) at com.iplanet.server.http.servlet.WServletEntity.loadAndInitServlet (WServletEntity.java:71) at com.iplanet.server.http.servlet.WebApplication.init(WebApplication.java:315) at com.iplanet.server.http.servlet.VirtualServer.init (VirtualServer.java:181) at com.iplanet.server.http.servlet.NSServletRunner.VSInit (NSServletRunner.java:686) The distribution should be updated with commons-logging.jar version 1.0.2. After you use commons-logging.jar 1.0.2 you get the following error when trying to access the index.jsp page in the blank application: [15/Oct/2002:16:09:02] failure ( 3408): Internal error: servlet service function had thrown ServletException (uri=/blank11/pages/Welcome.jsp): javax.servlet.ServletException, stack: javax.servlet.ServletException at org.apache.jasper.runtime.PageContextImpl.handlePageException (PageContextImpl.java:453) at _jsps._pages._Welcome_jsp._jspService (_Welcome_jsp.java:226) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java:248) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.access$6 (JspServlet.java:238) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:519) at org.apache.jasper.servlet.JspServlet.service (JspServlet.java:588) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at com.iplanet.server.http.servlet.NSServletRunner.invokeServletService (NSServletRunner.java:897) at com.iplanet.server.http.servlet.WebApplication.service (WebApplication.java:1059) at com.iplanet.server.http.servlet.NSServletRunner.ServiceWebApp (NSServletRunner.java:959) at com.iplanet.server.http.servlet.NSServletSession.internalRedirect(Native Method) at com.iplanet.server.http.servlet.NSRequestDispatcher.forward (NSRequestDispatcher.java:48) at org.apache.struts.actions.ForwardAction.execute(ForwardAction.java:158) at org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:446) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:266) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1292) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.iplanet.server.http.servlet.NSServletRunner.invokeServletService
Re: Tiles Refactorings for 1.1 compatability
No reason, I think we (you ;-) ) can close this bug with the proposed solution. For the NoOpAction, we can deprecate it and maybe let it extends the ForwardAction. Cedric Eddie Bush wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. What are you thoughts to make Tiles more module aware ? Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
multiple front ontroller in struts
Hi all, is it possible to have one more front controller servlet other than Actionservlet in struts ...?? anjali -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Future Release Suggestion
If noone else is doing this, I've got a day or two to give to this Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638. 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=13638 add Config Factory --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 10:33 --- Created an attachment (id=3484) Java source file for class org.apache.struts.config.ConfigFactory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638.
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=13638
add Config Factory
--- Additional Comments From [EMAIL PROTECTED] 2002-10-16 10:44 ---
I attach a proposal :
the class org.apache.struts.config.ConfigFactory
I will release a patch for configRuleSet class. Here a sample :
(...)
protected ConfigFactory configFactory = new ConfigFactory();
/**
* Default constructor, use default factory.
*/
public ConfigRuleSet () {
}
/**
* Use the user factory.
* @param ConfigFactory configFactory
*/
public ConfigRuleSet (ConfigFactory configFactory) {
this.configFactory = configFactory;
}
(...)
digester.addObjectCreate
(struts-config/action-mappings/action/exception,
configFactory.getExceptionConfigClassName(),
className);
(...)
I think there is more work with ActionMapping class, actually,
ActionMappingClass can be setted in ApplicationConfig class...prehaps we should
remove (deprecate) these set/get and use the config factory ?
Other problem, the ConfigFactory must be configured before parsing struts-
config.xml so we can add an attribute in controller element (like the request
processor class). - in a web.xml, in a properties files ...
Or perhaps it is possible to use an attribute in struts-config element.
struts-config factory=MyFactory
...
/struts-config
And the first rule is :
digester.addRule
(struts-config,
new SetConfigFactoryClassRule(this));
-emmanuel
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Future Release Suggestion
A good way to go would be to open a ticket in Bugzilla with the notes from this thread, and mention that you are working on an implementation there. 10/16/2002 6:27:16 AM, Chanoch [EMAIL PROTECTED] wrote: If noone else is doing this, I've got a day or two to give to this Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David
Re: Future Release Suggestion
And should anyone have an itch to scratch. http://jakarta.apache.org/struts/helping.html Since this is a volunteer project, we are all our own customers. Many other products have people working on them as part of the paid jobs. ASFAIK, that's not happening with Struts right now. My sincere suggestion to the corporate teams that depend on Struts is that's it time to step up to the plate. If ~you~ need a release out the door, it's up to *you* to see that it happens. Craig tells a story of a time when he needed Tomcat out the door so his team could use it. His son (bless his soul) said Dad, you know Java, why don't you help. The rest, as they say, is history. http://jakarta.apache.org/site/getinvolved.html We've been putting more Comitters on the team, which should help put through the patches we already have, but we still need more developers submitting patches for other issues -- and especially *unit tests* to prove the issues are fixed. -Ted. 10/15/2002 7:53:44 PM, [EMAIL PROTECTED] wrote: To blatently steal words from my favorite book on development - The Cathedral and the Bazaar by Erik Raymond (http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/). In the section where he describes the rise of Linux and how Linus Torvolds help Linux achieve such wide adoption, he states his rule number 7 for open source: 7. Release early. Release often. And listen to your customers. For example, look at Tomcat release 4.0 v4.018-Sep-2001 v4.0.1 29-Apr-2002 v4.0.2 10-Feb-2002 v4.0.3 02-Mar-2002 v4.0.4 28-Mar-2002 v4.0.5 24-Sep-2002 v4.0.6 08-Oct-2002 (Some of the dates may be a bit off - I had to surf ViewCVS looking at old release notes) All these are stable releases. 7 releases in just over a year. I'd wager that accellerating the release process for Struts would accelerate its adoption by corporations - and provide a lot more clients to help put shoes on the kids. Plus the rest of us could use the cool new features as well. Ted Husted [EMAIL PROTECTED] on 10/15/2002 06:50:23 PM Please respond to Struts Developers List [EMAIL PROTECTED] To:Struts Developers List [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David Graham [EMAIL PROTECTED] wrote: I think the problem is that some very heavy hitters were added into 1.1. Validator, sub modules, map backed form attributes, tiles, RequestProcessor, Plugins, etc. are all new (AFAIK) to 1.1. This amount of change requires quite a while to accomplish. It may be beneficial in the future to address bug fixes and one big new item per release. This way, production releases are more frequent. What do the comitters think? David From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Struts 1.1 Release Date: Tue, 15 Oct 2002 23:25:40 +0100 I totally understand and agree with the release policy, but I think it's worth remembering that a lot of these questions are driven by the constraints of users' environments - e.g. in corporate environments like ours, there any many people like myself continually fighting to get great open source products like Struts into the organisation so that development teams can use them, and the latest versions of them. However, this has to be done within the processes and policies that apply to any third party software, commercial or otherwise. Specifically, in our case, I am the product owner of Struts here among other products from the Apache family of projects here and it is my responsibility to make the standard builds of Struts on our software distribution servers so that development can reference this for use by their applications, as must be done for all external software (it's an audit point). However, in order to do this, I must get the new version approved by a central department which is extremely difficult, if not impossible for software that
RE: multiple front ontroller in struts
I would guess that in alot of cases one could solve the need for multiple front servlets through the use of a custom RequestDispatcher? -daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 7:13 AM To: Struts Developers List Subject: Re: multiple front ontroller in struts Not at this time. There are a number of deep assumptions in the code that the ActionServlet is the one-and-only in the application. Although, I think re-examining that assumption post 1.1 would be worthwhile. There are some performance advantages to having a single servlet, but there are also many configuration advantages to having multiple controller servlets, each respnsible for its own URI pattern(s). -Ted. 10/16/2002 6:17:59 AM, Anjali Jain [EMAIL PROTECTED] wrote: Hi all, is it possible to have one more front controller servlet other than Actionservlet in struts ...?? anjali -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Cedric Dumoulin wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. Ok - thanks :-) I had to ask! I think I see where things are happening now. I feel I have a lot better understanding of it. Yesterday was the first time I'd really sat down and tried to make heads or tails of the Tiles source code. What are you thoughts to make Tiles more module aware ? Yes, I think they need to go through that phase with everything else. In fact, I would argue that we won't really know what modules mean until we fix everything to work on that basis. Once we have things cleanly seperated, we can look at how they can be further enhanced by maybe chaining the lookups like I was suggesting earlier - but that's in another release ;-) The worst issue I see in Tiles is that it uses the same key (talking application scope here) to load itself, no matter which module does the loading. With such a scenario, if you have Tiles plugged in to the default module, and also use it in a non-default module, you're going to wind up overwriting your config. Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Well, for now, as little as I like the lack of sharing that would exist (sharing between default/non-default modules), I think probably the best thing we could do is get modules cleanly seperated from each other. Since we're still finding our feet with respect to exactly what modules mean to folks (ie how are people *really* going to use them?), I think the best route is to get everything cleanly seperated this round - and save any further enhancement (the sharing) for later. Of course, like yourself, I too am open to suggestions :-) Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ok. Sorry about dragging my feet - I got ... well, my wife changed my mind about what my evening plans were :-) I'll get that in today at some point. Cedric Dumoulin wrote: No reason, I think we (you ;-) ) can close this bug with the proposed solution. For the NoOpAction, we can deprecate it and maybe let it extends the ForwardAction. Cedric Eddie Bush wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Constructing Binary Distribution
James == James Mitchell [EMAIL PROTECTED] writes: James Anyone else having trouble running the dist target? James Mine is failing on the struts-el stuff (not compile error, but ant task James errors due to path settings and such), and I am working through it, but James wondering if I missed an email somewhere ?!?!?!? What is happening? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Constructing Binary Distribution
Never mind, it's complaining about a property that I don't have set in the base properties file. There were changes made recently to the .sample that I looking-around-innocently *somehow* missed :P James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: David M. Karr [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Constructing Binary Distribution James == James Mitchell [EMAIL PROTECTED] writes: James Anyone else having trouble running the dist target? James Mine is failing on the struts-el stuff (not compile error, but ant task James errors due to path settings and such), and I am working through it, but James wondering if I missed an email somewhere ?!?!?!? What is happening? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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]
cvs commit: jakarta-struts build-all-clean.bat.sample
rleland 2002/10/16 08:04:47 Added: .build-all-clean.bat.sample Log: Add script to build struts, commons, commons-sandbox from scratch. -Rob Revision ChangesPath 1.1 jakarta-struts/build-all-clean.bat.sample Index: build-all-clean.bat.sample === @echo on rem This is an example build-all-clean.bat file, used to build struts from rem a clean commons. It uses Cygwin to remove build directories since rem commons doesn't have an ant clean target. (HINT for COMMONS COMITTERS!) rem Make any changes you need, and rename this file rem to build-all-clean.bat and in the same directory that contains the Struts rem build.xml file. rem assumes jakarta-commons, rem jakarta-commons-sandbox, rem jakarta-struts-current rem are checked out in the same directory. rem Also assumes uses of rem maven beta 7, rem ant 1.5.1 rem cactus v 1.2 v1.3 rem Because the commons (resources) use an old version rem of cactus for units test, that maven doesn't precompile rem anymore, you'll need to copy the cactus.jar into the rem maven repository directoty. I filed a bug report for this. rem rem rem $Id: build-all-clean.bat.sample,v 1.1 2002/10/16 15:04:47 rleland Exp $ cd .. rem rm -rf */*/dist rm -rf */*/target rm -rf */*/build rm -rf jakarta-struts-current/dist rm -rf jakarta-struts-current/target cd jakarta-commons cd logging call ant clean dist cd ..\collections call ant clean dist cd ..\beanutils call ant clean dist cd ..\lang call ant clean dist cd ..\pool call ant clean dist cd ..\dbcp call ant clean dist cd ..\digester call ant clean dist cd ..\validator call ant clean dist cd ..\..\jakarta-commons-sandbox cd fileupload call maven cd ..\resources call maven cd ..\services call ant clean dist cd ..\..\jakarta-struts-current call ant clean dist pause -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13698] New: - BaseFieldTag confuses cols and size
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=13698. 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=13698 BaseFieldTag confuses cols and size Summary: BaseFieldTag confuses cols and size Product: Struts Version: 1.1 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] if cols is specified size is output. This is not visible since textarea handles it directly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. It is a free package, not opensource but free. I have Rational Rose 98, and tried other open source tools but they all were either too slow or very buggy or both. I would be happy to update those documents. I could also check in the configuration file for that project but it is 4 MB. -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12309] - ForwardAction should return an ActionForward.
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=12309. 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=12309 ForwardAction should return an ActionForward. --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:27 --- Eddie, Did you deprecate NoOpAction as well? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE:Constructing Binary Distribution
Anyone else having trouble running the dist target? Mine is failing on the struts-el stuff (not compile error, but ant task errors due to path settings and such), and I am working through it, but wondering if I missed an email somewhere ?!?!?!? It's a bug. I emailed the list but David didn't respond. If the jstl.jar variable is not defined the struts-el stuff is supposed to be skilled. At home I use Tomcat 3.X, so that is where I hit the problem. At work I use tomcat 4.X and so I have no problem compiling the latest distribution as of 11:30 Eastern time -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13526] - validator-rules.xml shouldn't have required as a depends of all the tests
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=13526. 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=13526 validator-rules.xml shouldn't have required as a depends of all the tests --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:39 --- James, I am not ignoring this, the attached patch will create conditions where the JavaScript will fail like for the minValue. Not being a JavaScript programmer I am not sure what will happen and I haven't had time to do a test case to find out. -- 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/actions NoOpAction.java
ekbush 2002/10/16 08:52:49
Modified:src/share/org/apache/struts/tiles/actions NoOpAction.java
Log:
Marked as deprecated in favor of using the updated o.a.s.a.ForwardAction.
PR: 12309
Revision ChangesPath
1.3 +5 -4
jakarta-struts/src/share/org/apache/struts/tiles/actions/NoOpAction.java
Index: NoOpAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/actions/NoOpAction.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NoOpAction.java 11 Jul 2002 16:46:40 - 1.2
+++ NoOpAction.java 16 Oct 2002 15:52:49 - 1.3
@@ -86,6 +86,7 @@
*
* @author Cedric Dumoulin
* @version $Revision$ $Date$
+ * @deprecated Use o.a.s.a.ForwardAction instead
*/
public final class NoOpAction extends Action {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12309] - ForwardAction should return anActionForward.
Yes, sorry - I actually commited one and then deprecated the other. It'll pass through here in a sec ;-) [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 ForwardAction should return an ActionForward. --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:27 --- Eddie, Did you deprecate NoOpAction as well? -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638. 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=13638 add Config Factory --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:56 --- Created an attachment (id=3487) new class : ConfigFactory.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638. 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=13638 add Config Factory --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:57 --- Created an attachment (id=3488) new file : LocalStrings.properties -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638. 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=13638 add Config Factory --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:57 --- Created an attachment (id=3489) patch for ConfigRuleSet.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13638] - add Config Factory
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=13638. 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=13638 add Config Factory --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:57 --- Created an attachment (id=3490) patch for struts-config-1_1.dtd -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12309] - ForwardAction should return an ActionForward.
Thanks Eddie! Dave From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 12309] - ForwardAction should return an ActionForward. Date: Wed, 16 Oct 2002 10:56:04 -0500 Yes, sorry - I actually commited one and then deprecated the other. It'll pass through here in a sec ;-) [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 ForwardAction should return an ActionForward. --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:27 --- Eddie, Did you deprecate NoOpAction as well? -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12309] - ForwardAction should return an ActionForward.
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=12309. 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=12309 ForwardAction should return an ActionForward. --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:59 --- So it's documented in bugzilla - yes :-) I did. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?) but it was on the download page. Unfortunately that is not available in a Linux version. I grabbed it anyhoo - I have a Windoze install too. Eddie Bush wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. snip/ -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13701] New: - newline swallowed bei MultipartElement or MultipartIterator
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=13701.
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=13701
newline swallowed bei MultipartElement or MultipartIterator
Summary: newline swallowed bei MultipartElement or
MultipartIterator
Product: Struts
Version: 1.0.2 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Minor
Priority: Other
Component: File Upload
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I use tomcat 4.1.12 and struts 1.0.2 stable on a Pentium I/RedHat Linux.
My sourcecode looks like this:
public void doPost(HttpServletRequest request, HttpServletResponse response) {
MultipartIterator iterator = new MultipartIterator(request, 4096, 20);
while ((element = iterator.getNextElement()) != null) {
if (element.getName().equals(foo)) {
this.foo = element.getValue();
...
When I make a html-post multipart/form-data from a html-form with a textarea-
element that has more than one line, element.getValue() swallows the first
newline(only the first). When I make a tcpdump or when I use the InputStreams,
I see the newline.
I think, it´s a bug in MultipartElement or in MultipartIterator.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Testing struts on 3.3.1 [WAS] RE: Future Release Suggestion
Well, its done (test org.apache.struts.action.TestDynaActionForm failed btw.) Slight problem that this email account is currently not letting me receive emails so I don't know where things are at. I will work on getting the files to you tomorrow. chanoch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts 1.1-b2 performance issues???
I just upgraded an application using struts 1.0.2 to use the latest 1.1-b2 version, and was a bit taken aback at how much longer it takes the application to run basic unit tests. I don't have the exact numbers on how long it used to take, but it's something like increasing from 48 to 73 seconds which is quite a bit. Interestingly, I get a substantial performance boost when I upgraded from Tomcat 4.0.4 to 4.1.10. And upgrading to Struts 1.1-b2 put me back to pretty close to where we were before upgrading Tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Constructing Binary Distribution
Sorry if I missed one of your issues. I remember someone asking about whether the jstl.jar value had to be empty or nonexistent. I thought it was you. If you ensure that jstl.jar is not defined, it will not build the struts-el distribution. -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 8:32 AM To: Struts Developers List Subject: RE:Constructing Binary Distribution Anyone else having trouble running the dist target? Mine is failing on the struts-el stuff (not compile error, but ant task errors due to path settings and such), and I am working through it, but wondering if I missed an email somewhere ?!?!?!? It's a bug. I emailed the list but David didn't respond. If the jstl.jar variable is not defined the struts-el stuff is supposed to be skilled. At home I use Tomcat 3.X, so that is where I hit the problem. At work I use tomcat 4.X and so I have no problem compiling the latest distribution as of 11:30 Eastern time -Rob -- 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]
RE: multiple front ontroller in struts
On Wed, 16 Oct 2002, Daniel Honig wrote: Date: Wed, 16 Oct 2002 08:20:44 -0400 From: Daniel Honig [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: multiple front ontroller in struts I would guess that in alot of cases one could solve the need for multiple front servlets through the use of a custom RequestDispatcher? Or using the sub-application module facilities in 1.1 if what you really want is to combine multiple Struts-based applications into one webapp. Or subclassing and specializing RequestProcessor. Or using Filters on a Servlet 2.3 or later system. -daniel Craig -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 7:13 AM To: Struts Developers List Subject: Re: multiple front ontroller in struts Not at this time. There are a number of deep assumptions in the code that the ActionServlet is the one-and-only in the application. Although, I think re-examining that assumption post 1.1 would be worthwhile. There are some performance advantages to having a single servlet, but there are also many configuration advantages to having multiple controller servlets, each respnsible for its own URI pattern(s). -Ted. 10/16/2002 6:17:59 AM, Anjali Jain [EMAIL PROTECTED] wrote: Hi all, is it possible to have one more front controller servlet other than Actionservlet in struts ...?? anjali -- 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] -- 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]
RE: multiple front ontroller in struts
-Original Message- From: Anjali Jain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:18 AM To: Struts Developers List Subject: multiple front ontroller in struts Hi all, is it possible to have one more front controller servlet other than Actionservlet in struts ...?? You want a second front-controller that is *not* Struts? Yes, you can do that if you want to, although I'm not sure why you would want to. If you want a second Struts ActionServlet instance, you cannot do that. The new module (sub-app) architecture in Struts 1.1 was created in part to address this issue. Instead of using two separate front controllers, you simply create two separate modules. -- Martin Cooper anjali -- 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]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 7:25 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Cedric Dumoulin wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. Ok - thanks :-) I had to ask! I think I see where things are happening now. I feel I have a lot better understanding of it. Yesterday was the first time I'd really sat down and tried to make heads or tails of the Tiles source code. What are you thoughts to make Tiles more module aware ? Yes, I think they need to go through that phase with everything else. In fact, I would argue that we won't really know what modules mean until we fix everything to work on that basis. Once we have things cleanly seperated, we can look at how they can be further enhanced by maybe chaining the lookups like I was suggesting earlier - but that's in another release ;-) The worst issue I see in Tiles is that it uses the same key (talking application scope here) to load itself, no matter which module does the loading. With such a scenario, if you have Tiles plugged in to the default module, and also use it in a non-default module, you're going to wind up overwriting your config. Urck! (A technical term. :) That's not too cool. Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Well, for now, as little as I like the lack of sharing that would exist (sharing between default/non-default modules), I think probably the best thing we could do is get modules cleanly seperated from each other. Since we're still finding our feet with respect to exactly what modules mean to folks (ie how are people *really* going to use them?), I think the best route is to get everything cleanly seperated this round - and save any further enhancement (the sharing) for later. Yes, this is spot on. We need to present a consistent approach across the whole of Struts, for the 1.1 release (well, and later too!). Then we can come back and look at the whole sharing and/or hierarchy thing later. -- Martin Cooper Of course, like yourself, I too am open to suggestions :-) Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- Eddie Bush -- 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]
RE: Future Release Suggestion
-Original Message- From: Chanoch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:27 AM To: 'Struts Developers List' Subject: RE: Future Release Suggestion If noone else is doing this, I've got a day or two to give to this Awesome! Thanks! Since support for 3.2 is being dropped - shall I replace the 32 target with a 33 target when submitting the diff? You might as well leave the 3.2 tests there for now, just in case someone is sufficiently determined to figure out a way to get Struts 1.1 working with Tomcat 3.2.4. Both Craig and I looked at this before, and we decided it was probably a Tomcat class loader bug. But someone else might figure out a way to work around it. -- Martin Cooper chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 16 October 2002 00:22 To: 'Struts Developers List' Subject: RE: Future Release Suggestion If you, or someone else with some time on their hands, are a Tomcat user, there is one thing that would be a big help. We have a series of unit tests that are run against different Tomcat versions. At this time, we have configurations for Tomcat 3.2, 4.0 and 4.1. However, we know that Struts does not work with Tomcat 3.2, and have decided to drop support for 3.2 in favour of 3.3. However, at this time we don't have a test configuration for 3.3. I started messing with this a while ago, and discovered that 3.3 is different enough from both 3.2 and 4.0 that blindly hacking at one of these didn't work. ;-) However, I'm not a Tomcat user, so not really familiar with what I needed to do to get it working. If someone is up for this, the place to look is build-tests.xml, in the root of the Struts source tree. There, you'll find targets such as 'test.tomcat.nn' where 'nn' is 32, 40 or 41. All we need is a 'test.tomcat.33' that works against Tomcat 3.3.1. ;-) Seriously, though, it would be great to get this working. -- Martin Cooper -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:05 PM To: Struts Developers List Subject: RE: Future Release Suggestion Hello, With this in mind I'd like to announce that I've got some time on my hands. Probably too much. So I'd like to attempt to get out of lurker mode and start helping out the committers. Can someone give me some direction as to some bugs that might be good to look at. I'll probaby spend half a day getting up to speed on catctus and the test framework which is crucial for any patches I might suggest. But I'd love to have a few of the committers deputize me to go off and inspect some issues. I've been collaborating with a couple guys on a tag library for WML. They've had to do most of the work until now so part of my effort is going to be helping them validate it and get it ready for review by the larger community. -Daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 6:50 PM To: Struts Developers List Subject: Re: Future Release Suggestion As Craig pointed out recently, we all really do this for our own use, and if someone else can use it too, then that's icing on the cake. Most of the Committers are highly enough placed in their own organizations that they can use the nightly build if they have to. So, the pressure to make incremental releases has not been so great. But a good portion of my income now comes from working with teams that are prohibited from using betas or a nightly build. So, to keep shoes on the kids, I'm going to need to work toward more incremental releases, so that my clients can use it (and so they can in turn use me ;0) But, yes, I think that down the road we will need to start looking for reasons to cut a release. If we have several releases a year, then there will be less pressure to slip in one more gotta have it, since the next release won't be so far away. Of course, at this point the die is cast, and we need to debug the features already promised. -Ted. 10/15/2002 6:35:28 PM, David
RE: Tiles Refactorings for 1.1 compatability
Cactus versions What version of cactus should I be using for the latest Struts source from CVS? do I need to build cactus from source too? -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 12:06 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Odd - I didn't see it on the products page (overlooked?) but it was on the download page. Unfortunately that is not available in a Linux version. I grabbed it anyhoo - I have a Windoze install too. Eddie Bush wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. snip/ -Rob -- Eddie Bush -- 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]
update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?) but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: update:RE: Tiles Refactorings for 1.1 compatability
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 11:02 AM
To: Struts Developers List
Subject: update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get
the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
You must be building against a Servlets 2.3 API. The getResourcePaths()
method is new for Servlets 2.3. If you try building against a Servlets 2.2
API, you shouldn't have any problems.
--
Martin Cooper
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?)
but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of
the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
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]
--
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]
Official bug list
There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
Here's the query I use: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=Blockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+1version=1.1+Beta+2version=Nightly+Buildversion=Unknownshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time -james --- V. Cekvenich [EMAIL PROTECTED] wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: update:RE: Tiles Refactorings for 1.1 compatability
Thanks!
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 2:10 PM
To: 'Struts Developers List'
Subject: RE: update:RE: Tiles Refactorings for 1.1 compatability
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 11:02 AM
To: Struts Developers List
Subject: update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get
the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
You must be building against a Servlets 2.3 API. The getResourcePaths()
method is new for Servlets 2.3. If you try building against a Servlets 2.2
API, you shouldn't have any problems.
--
Martin Cooper
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?)
but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of
the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
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]
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
Would that be official? It does not have Validator (8787 for example, or other commons, but if is or even close than OK, let's see what we can do. (James are you a commiter? I just want to know how official this is) .V James Holmes wrote: Here's the query I use: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=Blockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+1version=1.1+Beta+2version=Nightly+Buildversion=Unknownshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time -james --- V. Cekvenich [EMAIL PROTECTED] wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
V. Cekvenich wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I don't believe there is an official query. What I do is select Struts as the product and the select 1.1b1 and 1.1b2 and the nightly build for versions. Other folks have looser criteria, but I generally have plenty to choose from in the list I get. I see 90 bugs, but if you can help us help you. Pick one :-) Please ensure the patch you submit is a cvs diff -u. That part *is* official. Other formats may be accepted too, but using that format will help expedite things. So a semi official list of real bugs, including commons dependencies. ? including commons dependencies? I'm not sure what you're asking, but you should be able to grab a nightly binary distribution to have the required JARs to build with, if that's your question. .V -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
It's as official as I know of (all I did was a query for open 1.1 bugs in bugzilla). 8787 is a Commons bug not a Struts bug. Are we counting bugs for dependent modules? I didn't know that we were. Yes, I am a committer. -james --- V. Cekvenich [EMAIL PROTECTED] wrote: Would that be official? It does not have Validator (8787 for example, or other commons, but if is or even close than OK, let's see what we can do. (James are you a commiter? I just want to know how official this is) .V James Holmes wrote: Here's the query I use: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=Blockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+1version=1.1+Beta+2version=Nightly+Buildversion=Unknownshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time -james --- V. Cekvenich [EMAIL PROTECTED] wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
Bugzilla is the official repository. Anything unresolved that is not marked LATER is still on the list for the next release. -Ted. 10/16/2002 2:22:24 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Would that be official? It does not have Validator (8787 for example, or other commons, but if is or even close than OK, let's see what we can do. (James are you a commiter? I just want to know how official this is) .V James Holmes wrote: Here's the query I use: http://nagoya.apache.org/bugzilla/buglist.cgi? bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=B lockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1 =substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1 bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1 +Beta+1version=1.1+Beta+2 version=Nightly+Buildversion=Unknownshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allw ordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0 =nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time -james --- V. Cekvenich [EMAIL PROTECTED] wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- 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]
[VOTE] David Graham as Struts Committer
David has been a very involved member of the Struts community for some time, and has been making steady contributions both to the mailing list and to Bugzilla. I think this would be a good time to bring David on as a Committer, He has my +1 -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Ted Husted wrote: From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the seperatism phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told post 1.1 on. Would it be best to, as I suggested, have Tiles be stupid this release (no chaining/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used? I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's own little world - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to fix things that are not 1.1 compliant. No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until later (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's beta status. It's a time/feature trade-off :-) I don't see it being necessary to rework the config instantiation/acquisition beyond 1.1. The thing that will have to change is how the lookups are done. I really think we can break these out into two releases without having to do rework, if that is the way it needs to go. We could go ahead and refactor the lookups now too, if that's the appropriate course, but there's obviously going to be additional delay for doing so. Do we need a proposal maybe? -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David Graham as Struts Committer
+1 --- Ted Husted [EMAIL PROTECTED] wrote: David has been a very involved member of the Struts community for some time, and has been making steady contributions both to the mailing list and to Bugzilla. I think this would be a good time to bring David on as a Committer, He has my +1 -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util StrutsValidator.java
rleland 2002/10/16 11:44:30
Modified:conf/share validator-rules.xml
doc/userGuide dev_validator.xml
src/share/org/apache/struts/util StrutsValidator.java
Log:
Bug#:13528 Apply patch to allow validator to conditionally
require fields. supplied by James Turner [EMAIL PROTECTED]
Also turn his comments into userguide material.
Revision ChangesPath
1.10 +15 -29jakarta-struts/conf/share/validator-rules.xml
Index: validator-rules.xml
===
RCS file: /home/cvs/jakarta-struts/conf/share/validator-rules.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- validator-rules.xml 11 Oct 2002 19:12:26 - 1.9
+++ validator-rules.xml 16 Oct 2002 18:44:30 - 1.10
@@ -81,6 +81,17 @@
/validator
+ validator name=requiredif
+ classname=org.apache.struts.util.StrutsValidator
+ method=validateRequiredIf
+ methodParams=java.lang.Object,
+ org.apache.commons.validator.ValidatorAction,
+ org.apache.commons.validator.Field,
+ org.apache.struts.action.ActionErrors,
+ org.apache.commons.validator.Validator,
+ javax.servlet.http.HttpServletRequest
+ msg=errors.required
+ /validator
validator name=minlength
classname=org.apache.struts.util.StrutsValidator
@@ -586,10 +597,10 @@
/validator
-
+!-- range is deprecated use rangeInt instead --
validator name=range
classname=org.apache.struts.util.StrutsValidator
- method=validateRange
+ method=validateIntRange
methodParams=java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
@@ -599,33 +610,8 @@
msg=errors.range
javascript![CDATA[
-function validateRange(form) {
-var bValid = true;
-var focusField = null;
-var i = 0;
-var fields = new Array();
-oRange = new range();
-for (x in oRange) {
-if ((form[oRange[x][0]].type == 'text' ||
- form[oRange[x][0]].type == 'textarea')
-(form[oRange[x][0]].value.length 0)) {
-var iMin = parseInt(oRange[x][2](min));
-var iMax = parseInt(oRange[x][2](max));
-var iValue = parseInt(form[oRange[x][0]].value);
-if (!(iValue = iMin iValue = iMax)) {
-if (i == 0) {
-focusField = form[oRange[x][0]];
-}
-fields[i++] = oRange[x][1];
-bValid = false;
-}
-}
-}
-if (fields.length 0) {
-focusField.focus();
-alert(fields.join('\n'));
-}
-return bValid;
+function validateRange(form) {
+return validIntRange(form);
}]]
/javascript
1.5 +99 -1 jakarta-struts/doc/userGuide/dev_validator.xml
Index: dev_validator.xml
===
RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- dev_validator.xml 31 Aug 2002 13:15:02 - 1.4
+++ dev_validator.xml 16 Oct 2002 18:44:30 - 1.5
@@ -2,15 +2,113 @@
document url=./resources.xml
properties
authorDavid Winterfeldt/author
+ authorJames Turner/author
+ authorRob Leland/author
titleThe Struts User's Guide - Validator Guide/title
/properties
body
chapter name=Struts Validator Guide
section href=validator name=Struts Validator
-p
+
[:TODO:]
+pCover basic functionality as documented on David's web site.
+a href=http://home.earthlink.net/~dwinterfeldt/;Validation Framework for Struts
/a
/p
+
+p Struts 1.1 has added additional functionality over the original validator
+contributed by David Winterfeldt/p
+ul
+li Conditionally required fields/li
+li intRange() amp; floatRange() methods in both JavaScript and Java/li
+li deprecation of range() methods in both JavaScript and Java/li
+/ul
+
+p
+The most fundamental change is the ability to conditionally
+require validator
DO NOT REPLY [Bug 13528] - Add requiredif rule
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=13528. 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=13528 Add requiredif rule [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 18:47 --- This depends on Bug 13526 being applied. Bug#:13528 Apply patch to allow validator to conditionally require fields. supplied by James Turner [EMAIL PROTECTED] Also turn his comments into userguide material. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David Graham as Struts Committer
+1 Craig On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 14:38:58 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [VOTE] David Graham as Struts Committer David has been a very involved member of the Struts community for some time, and has been making steady contributions both to the mailing list and to Bugzilla. I think this would be a good time to bring David on as a Committer, He has my +1 -Ted. -- 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]
Re: [VOTE] David Graham as Struts Committer
+1 Craig R. McClanahan wrote: +1 Craig On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 14:38:58 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [VOTE] David Graham as Struts Committer David has been a very involved member of the Struts community for some time, and has been making steady contributions both to the mailing list and to Bugzilla. I think this would be a good time to bring David on as a Committer, He has my +1 -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Official bug list
On Wed, 16 Oct 2002, V. Cekvenich wrote: Date: Wed, 16 Oct 2002 14:22:24 -0400 From: V. Cekvenich [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Official bug list Would that be official? It does not have Validator (8787 for example, or other commons, but if is or even close than OK, let's see what we can do. (James are you a commiter? I just want to know how official this is) It's definitely relevant for us to consider bugs in the Commons projects that Struts depends on. and assist in getting those fixed as well (plus, we need to ensure that each of the packages we depend on has a formal release that we can use in Struts 1.1 final). Just as a starting point for accumulating this, the following bugids look relevant and need to be at least investigated: BeanUtils: 12728, 13596 DBCP: 12047, 12400, 12733, 12869, 13155 Digester: 12534, 12997 (probably a WONTFIX), 13098 (probably LATER), Pool: 12841, 13649, 13705 Validator: 13030, 13472, 13539 It would be helpful if folks interested in Struts could evaluate these issues and post relevant patches, just like we do for Struts bugs. FYI, to select these, I have a saved query with the following criteria: Status: UNCONFIRMED, NEW, ASSIGNED, REOPENED Program: Commons You could be selective about the Component to use if you want, but I tend to be interested in how all the Commons packages are progressing. .V Craig James Holmes wrote: Here's the query I use: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=Blockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=1.1+Beta+1version=1.1+Beta+2version=Nightly+Buildversion=Unknownshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time -james --- V. Cekvenich [EMAIL PROTECTED] wrote: There are many ways to run bugzlia report list. Can someone post the developer official Struts 1.1 list for the people that want to help work on a bug and submit solution code to bugzila. I see 90 bugs, but if you can help us help you. So a semi official list of real bugs, including commons dependencies. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- 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]
Re: [VOTE] David Graham as Struts Committer
+1, Sorry Eddie, David got more votes but that doesn't mean we like him any better than you. ;-) ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David Graham as Struts Committer
LOL - no problem ;-) I voted for him too. Robert Leland wrote: +1, Sorry Eddie, David got more votes but that doesn't mean we like him any better than you. ;-) ! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: Do we need a proposal maybe? As a rule, we propose through code, since that's all we can really vote on anyway =:0) My only point is that if I patch the controller to support a delimited list of struts-configs, as we do with Tiles and the Validator, then we have the choice between the Chinese wall approach to modules, or just diving up elements between multiple files. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability]
Yeah I found it - just a Windoze install though :-/ I didn't care much for Argo either. That's way more horse-power than I want in such a tool. Having the ability to reverse engineer into diagrams is awesome - and being able to draw diagrams easily is awesome. I don't really want to go to the trouble to build a model that depicts my code so concisely it can be auto-generated though. That seems like a real PITA. Robert Leland wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I did a Google search: on 'SilverRun JD 1.1' http://download.com.com/3000-2417-8021135.html?legacy=cnet By the way avoid Argo, that was the open source UML builder that was big, buggy and slow. It has gone commercial and seems abondonded, no matter what the developers say. -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12776] - validation order is incorrect
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=12776. 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=12776 validation order is incorrect [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:23 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. -- Martin Cooper Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- 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]
Re: [VOTE] David Graham as Struts Committer
Don't worry Eddie, I like you better than me anyway :-). Dave From: Robert Leland [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [VOTE] David Graham as Struts Committer Date: Wed, 16 Oct 2002 15:04:54 -0400 +1, Sorry Eddie, David got more votes but that doesn't mean we like him any better than you. ;-) ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I believe that, by default, the application-relative paths would become module-relative paths, and I wouldn't be able to refer to a file outside of the module. The definitions essentially act as ActionForwards, so we might want the same type of contextRelative switch for the Tiles path attributes that we have the for ActionForward path attribute. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1compata bility)
What Eddie said (mostly). ;-) We've gone most of the way down the road with modules the way Craig originally envisioned them, and we're almost there. There are just a few more cleanup tasks to go, such as fixing Tiles to not trip over itself. I would really like to see us finish what we've started, as soon as we can, and then go back and look at the sharing thing once 1.1 is final. Maybe that comes in a 1.2 that doesn't take us so long to complete as 1.1 has taken us. But let's not try to squeeze it in to 1.1, and perhaps later regret that we didn't think through all the issues. -- Martin Cooper -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:44 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Ted Husted wrote: From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the seperatism phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told post 1.1 on. Would it be best to, as I suggested, have Tiles be stupid this release (no chaining/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used? I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's own little world - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to fix things that are not 1.1 compliant. No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until later (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's beta status. It's a time/feature trade-off :-) I don't see it being necessary to rework the config instantiation/acquisition beyond 1.1. The thing that will have to change is how the lookups are done. I really think we can break these out into two releases without having to do rework, if that is the way it needs to go. We could go ahead and refactor the lookups now too, if that's the appropriate course, but there's obviously going to be additional delay for doing so.
cvs commit: jakarta-struts/doc/userGuide building_controller.xml
jholmes 2002/10/16 12:39:07 Modified:doc/userGuide building_controller.xml Log: update Accessing Relational Databases section PR: Bugzilla #13177 Revision ChangesPath 1.34 +10 -0 jakarta-struts/doc/userGuide/building_controller.xml Index: building_controller.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/building_controller.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- building_controller.xml 13 Oct 2002 15:55:12 - 1.33 +++ building_controller.xml 16 Oct 2002 19:39:06 - 1.34 @@ -772,6 +772,16 @@ For information on how to retrieve the data source, see the a href=building_model.html#databasesAccessing Relational Databases/a section. /p + p +iNote: Since Struts is now using commons-dbcp for all it's + data-source needs, the query you provide for the pingQuery + attribute must return at least one row./ibr/ + br/ +bExample:/bcodeSELECT COUNT(*) FROM VALIDTABLE/codebr/ + br/ + Just be sure you to replace VALIDTABLE with the name of a valid table in your database. + /p + /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David Graham as Struts Committer
:-) I'm sure the feeling is mutual ;-) ...erm shuts-up/ David Graham wrote: Don't worry Eddie, I like you better than me anyway :-). Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
[ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [X] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12023] - The align attribute on html:image and html:img should be removed
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=12023. 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=12023 The align attribute on html:image and html:img should be removed [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 19:52 --- Fixed in nightly build 20021017. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html ImageTag.java
jholmes 2002/10/16 12:51:56
Modified:doc/userGuide struts-html.xml
src/share/org/apache/struts/taglib/html ImageTag.java
Log:
mark align attribute of html:image tag as deprecated
PR: Bugzilla #12023
Revision ChangesPath
1.28 +3 -0 jakarta-struts/doc/userGuide/struts-html.xml
Index: struts-html.xml
===
RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- struts-html.xml 12 Oct 2002 22:38:38 - 1.27
+++ struts-html.xml 16 Oct 2002 19:51:55 - 1.28
@@ -2275,6 +2275,9 @@
rtexprvaluetrue/rtexprvalue
info
pThe alignment option for this image./p
+pThe alignment option for this image. The align attribute is
+deprecated in HTML 4.x. The suggested alternative is to use CSS.
+Please see
http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.7.4 for more details./p
/info
/attribute
1.19 +10 -4
jakarta-struts/src/share/org/apache/struts/taglib/html/ImageTag.java
Index: ImageTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ImageTag.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ImageTag.java 23 Sep 2002 05:13:43 - 1.18
+++ ImageTag.java 16 Oct 2002 19:51:56 - 1.19
@@ -90,10 +90,16 @@
*/
protected String align = null;
+/**
+ * @deprecated Align attribute is deprecated in HTML 4.x.
+ */
public String getAlign() {
return (this.align);
}
+/**
+ * @deprecated Align attribute is deprecated in HTML 4.x.
+ */
public void setAlign(String align) {
this.align = align;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compatability)
On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 12:36:34 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compata bility) What Eddie said (mostly). ;-) We've gone most of the way down the road with modules the way Craig originally envisioned them, and we're almost there. There are just a few more cleanup tasks to go, such as fixing Tiles to not trip over itself. I would really like to see us finish what we've started, as soon as we can, and then go back and look at the sharing thing once 1.1 is final. Maybe that comes in a 1.2 that doesn't take us so long to complete as 1.1 has taken us. But let's not try to squeeze it in to 1.1, and perhaps later regret that we didn't think through all the issues. +1. I was about to write something pretty similar. -- Martin Cooper Craig -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:44 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Ted Husted wrote: From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. Yes - saw that coming. I want to share too, but is it appropriate to do so now and skip the seperatism phase? If each module is, in fact, it's own little world, then that should apply to everything. This goes along with previous arguments I've voiced and been told post 1.1 on. Would it be best to, as I suggested, have Tiles be stupid this release (no chaining/sharing), and then refactor for sharing once we have a better idea of how sub-apps will be used? I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. :-/ Well, there's nothing to stop you from referencing the same physical pages that I can think of - but the definitions would be duplicated I suppose. This could be solved by the same concatenation tricks used for previous versions of Struts. I know it's not ideal - but I don't think 1.1F *is* going to be (IMHO - because of the way I feel they should be implemented) ideal. 1.1.1 or 1.2 - that's where we'll whip it into shape. Is this not the direction we are headed? If not, I'd like to know now. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. Yeah - maybe so. You know (I think) where I stand on the duplication. I don't like it either. The idea I've had impressed upon me (by both Martin and Craig, I believe) is that we should implement 1.1 with each module being in it's own little world - and then follow up with discussions on how we can make them work more ideally. That is the exact impression guiding what I am doing to fix things that are not 1.1 compliant. No matter what we do in the future, we need to have each module not being trampled on by the others, so refactoring to allow each app the ability to use a plugin without affecting the others is (I think) a necessary step. Whether we go one further and implement chaining is an option I would certainly be open to, but I was under the impression this shouldn't be done until later (post 1.1). I hope others will share their feelings. Bear in mind there are folks looking heavily at 1.1 that can't use it because of it's beta status. It's a time/feature trade-off :-) I don't see it being necessary to
Re: [VOTE] How should Tiles be refactored?
All the configuration files for Struts core, Validator, and Tiles should work the same way. Tiles put and insert should support a contextRelative property, like the ActionForward. 10/16/2002 3:48:56 PM, Eddie Bush [EMAIL PROTECTED] wrote: There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- 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]
Re: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compatability)
Thank God someone has started throwing their votes around. Hop on the other thread please, Craig. I'd like to have everything in one spot. Craig R. McClanahan wrote: On Wed, 16 Oct 2002, Martin Cooper wrote: Date: Wed, 16 Oct 2002 12:36:34 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: Modules in Struts 1.1 (was RE: Tiles Refactorings for 1.1 compata bility) What Eddie said (mostly). ;-) We've gone most of the way down the road with modules the way Craig originally envisioned them, and we're almost there. There are just a few more cleanup tasks to go, such as fixing Tiles to not trip over itself. I would really like to see us finish what we've started, as soon as we can, and then go back and look at the sharing thing once 1.1 is final. Maybe that comes in a 1.2 that doesn't take us so long to complete as 1.1 has taken us. But let's not try to squeeze it in to 1.1, and perhaps later regret that we didn't think through all the issues. +1. I was about to write something pretty similar. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
Independent configuration files for 1.1, possible sharing in 1.2. So, I guess that's number 2. Dave From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [VOTE] How should Tiles be refactored? Date: Wed, 16 Oct 2002 14:48:56 -0500 There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] David Graham as Struts Committer
+1 (No offense, Eddie - if your vote had come up now, I'da +1'd it too. :) -- Martin Cooper -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:39 AM To: [EMAIL PROTECTED] Subject: [VOTE] David Graham as Struts Committer David has been a very involved member of the Struts community for some time, and has been making steady contributions both to the mailing list and to Bugzilla. I think this would be a good time to bring David on as a Committer, He has my +1 -Ted. -- 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]
Re: [VOTE] How should Tiles be refactored?
See if I draw little boxes for you guys anymore! Bah - none of you use them ;-) David Graham wrote: Independent configuration files for 1.1, possible sharing in 1.2. So, I guess that's number 2. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to decouple
Tiles and Validator from the core as an attempt to simplify the 1.1
release? It seems like there needs to be a middle-ground between
the contrib folder and the core where useful tools can be developed
and released without interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
+1 by a non committee on M.C. vetoing new features. Can you wait till 1.2 Ted? .V Martin Cooper wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 11:23 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability From an API perspective, a big issue may be being able to also refer to tile locations using both module- relative AND application-relative URIs. In a large application, we will want to share tiles between modules to establish a common look and feel. I have a beast in front of me now with 8 logical application segments that could become modules in 1.1. But, there is only one library of tiles, which they all happily share. Each module has its own set of pages, but being the same application, these pages all use the same layouts and tiles. I could use a separate tiles-def.xml for each but we need to also be able to share tiles and layouts somehow. In practice, all a lot of teams really want is multiple configuration files. Right now, the modules seem to be doing double-duty. You can subdivide a large application into modules to gain multiple configurations, but there is a corresponding gain in complication unless the modules are very loosely coupled. (The sharing world-view.) Now that we have modules in play, would anyone VETO adding the capability to have a delimited list of struts- configs (for each module) -- to match what we do with the tiles and validator configurations? If for no other reason, than because we should be providing a consistent approach across components. Would I veto adding new functionality in a second beta that everyone is waiting for a final release of? I'd have to seriously consider it. -- Martin Cooper Then, if there is something in the module implementation that classes with a team's world-view, they can simulate modules usng multiple configuration files. They would end up embedding the module directory in the URIs, but some people might consider that a fair trade-off to the sharing issues. -Ted. -- 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]
RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability]
I've got a personal relationship with the folks behind MagicDraw. While I doubt they would sponsor the whole Jakarta project, I might be able to bend their ears to working something out on licenses. Perhaps committers?...Something like that... If the project would like me to pursue this then let me know what our needs might be roughly. I can always ping them to see if they would want to sponsor us in some way. -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:24 PM To: Struts Developers List Subject: Re: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability] Yeah I found it - just a Windoze install though :-/ I didn't care much for Argo either. That's way more horse-power than I want in such a tool. Having the ability to reverse engineer into diagrams is awesome - and being able to draw diagrams easily is awesome. I don't really want to go to the trouble to build a model that depicts my code so concisely it can be auto-generated though. That seems like a real PITA. Robert Leland wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I did a Google search: on 'SilverRun JD 1.1' http://download.com.com/3000-2417-8021135.html?legacy=cnet By the way avoid Argo, that was the open source UML builder that was big, buggy and slow. It has gone commercial and seems abondonded, no matter what the developers say. -Rob -- Eddie Bush -- 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]
Re: [VOTE] David Graham as Struts Committer
Yeah, yeah ... ;-) Hey - I thought David already was a commiter before I even started raising a stink around here. I'm glad to have him join in :-) You'll have to do better than that if you're trying to offend me ;-) Martin Cooper wrote: +1 (No offense, Eddie - if your vote had come up now, I'da +1'd it too. :) -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to decouple Tiles and
Validator from the core as an attempt to simplify the 1.1 release? It
seems like there needs to be a middle-ground between the contrib folder
and the core where useful tools can be developed and released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get glazed,
they go white, their hands tremble As I watch them I often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tiles Refactorings for 1.1 compatability
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's non-trival, but not overly large. And, since we
have new, eager, smart committers with plenty of energy and motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
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]
RE: Tiles Refactorings for 1.1 compatability
I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- 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]
RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability]
Good one. I think that the only thing that should ever be committed is the standard xml files and everyone has to adhere to that standard. don't want to waste cycles on this either. -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 4:44 PM To: Struts Developers List Subject: RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability] I've got a personal relationship with the folks behind MagicDraw. Back in July http://marc.theaimsgroup.com/?l=jakarta-generalm=102750916312690w=3 Subject :Together ControlCenter for jakarta projects There was a fire storm about Rational Control Center for Jakrata Developers. The bottom line was we Jakarta Comitters would be 1) ok as using a free UML tool 2) Use would not = endorsement by Apache. 3) It would be optional, and we would only commit the project files if it talked the standard XML format. I am staying out of this one. -Rob -- 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]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html JavascriptValidatorTag.java
rleland 2002/10/16 13:55:07
Modified:src/share/org/apache/struts/taglib/html
JavascriptValidatorTag.java
Log:
Good catch
Bug #11950. patch suggested by
[EMAIL PROTECTED] (Balakrishna Shetty)
I also had to supply a closing /script !
Tested under TC 4.0.6
Revision ChangesPath
1.6 +265 -264
jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java
Index: JavascriptValidatorTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JavascriptValidatorTag.java 11 Oct 2002 22:17:50 - 1.5
+++ JavascriptValidatorTag.java 16 Oct 2002 20:55:07 - 1.6
@@ -80,7 +80,6 @@
import org.apache.struts.util.MessageResources;
import org.apache.struts.util.StrutsValidatorUtil;
import org.apache.struts.util.RequestUtils;
-import org.apache.struts.Globals;
import org.apache.struts.config.ApplicationConfig;
@@ -92,7 +91,7 @@
* @author David Winterfeldt
* @version $Revision$ $Date$
* @since Struts 1.1
-*/
+ */
public class JavascriptValidatorTag extends BodyTagSupport {
@@ -101,81 +100,81 @@
/**
* The servlet context attribute key for our resources.
-*/
+ */
protected String bundle = Action.MESSAGES_KEY;
/**
* The default locale on our server.
-*/
+ */
protected static Locale defaultLocale = Locale.getDefault();
/**
* The name of the form that corresponds with the action name
* in struts-config.xml.
-*/
+ */
protected String formName = null;
/**
* The current page number of a multi-part form.
-*/
+ */
protected int page = 0;
/**
* This will be used as is for the JavaScript validation method name if it has
a value. This is
* the method name of the main JavaScript method that the form calls to perform
validations.
-*/
+ */
protected String methodName = null;
/**
* The static JavaScript methods will only be printed if this is set to true.
-*/
+ */
protected String staticJavascript = true;
/**
* The dynamic JavaScript objects will only be generated if this is set to
true.
-*/
+ */
protected String dynamicJavascript = true;
/**
* The src attribute for html script element (used to include an external
script resource).
-*/
+ */
protected String src = null;
/**
* Gets the key (form name) that will be used
* to retrieve a set of validation rules to be
* performed on the bean passed in for validation.
-*/
+ */
public String getFormName() {
- return formName;
+return formName;
}
/**
* Sets the key (form name) that will be used
* to retrieve a set of validation rules to be
* performed on the bean passed in for validation.
-*/
+ */
public void setFormName(String formName) {
- this.formName = formName;
+this.formName = formName;
}
/**
* Gets the current page number of a multi-part form.
* Only field validations with a matching page numer
* will be generated that match the current page number.
-*/
+ */
public int getPage() {
- return page;
+return page;
}
/**
* Sets the current page number of a multi-part form.
* Only field validations with a matching page numer
* will be generated that match the current page number.
-*/
+ */
public void setPage(int page) {
- this.page = page;
+this.page = page;
}
/**
@@ -183,9 +182,9 @@
* validation method name if it has a value. This overrides
* the auto-generated method name based on the key (form name)
* passed in.
-*/
+ */
public String getMethod() {
- return methodName;
+return methodName;
}
/**
@@ -193,228 +192,229 @@
* validation method name if it has a value. This overrides
* the auto-generated method name based on the key (form name)
* passed in.
-*/
+ */
public void setMethod(String methodName) {
- this.methodName = methodName;
+this.methodName = methodName;
}
/**
* Gets whether or not to generate the static
* JavaScript. If this is set to 'true', which
* is the default, the static JavaScript will be generated.
-*/
+ */
public String getStaticJavascript() {
-
DO NOT REPLY [Bug 11950] - Missing script in generated javascipt
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=11950. 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=11950 Missing script in generated javascipt [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 20:56 --- Good catch Bug #11950. patch suggested by [EMAIL PROTECTED] (Balakrishna Shetty) I also had to supply a closing /script ! Tested under TC 4.0.6 using all combinations of dynamic/static booleans -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability)
I developed a system that handles the need for having multiple components of a Struts application (Struts, Tiles, Validator, etc) partitioned in a modular fashion, so that independent groups could work on their component parts without having to worry about what other groups were doing, and yet allow for seamless integration of these components at web application assembly time. It was a requirement that all of this be done without requiring modification to Struts proper, so this is an approach that can be layered on top of a basic Struts implementation. I had wanted to bring this up a week or so ago when Eddie was talking about this topic, but was too busy then. The basic approach is to define a mechanism which allows module authors to work on individual modules using fragments which are then assembled into the final Struts files by Ant. The fragments are XML files which are essentially well-formed versions of the corresponding Struts files. The Ant process uses some style sheet tricks to collect the set of fragments, coalesce the relevant portions of the files into the proper sections (action-mappings, form-beans, etc) in the target XML files (mostly struts-config.xml needed this coalescing). Identifier collisions were avoided by a identifier prefixing scheme where each module would have it's own prefix. If there's interest in examining this approach, I can go into more detail about its operation. It worked well for us, and seems to fit the bill for a way to address the need for modular but not totally independent web applications. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11950] - Missing script in generated javascipt
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=11950. 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=11950 Missing script in generated javascipt --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 20:59 --- Actually, it should read script type=text/javascript if it's to be xhtml compliant. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
Just of the box... Ted, others, what if we just delayed subapps till after?
.V
Byrne, Steven wrote:
Definitely a big part of what 1.1 is all about is integrating Tiles and
Validator into the main Struts distribution. Pulling them back into
pseudo-contrib status would not be a good thing.
Has anyone estimated the level of effort to make each of them be sub-app
aware? I imagine it's non-trival, but not overly large. And, since we
have new, eager, smart committers with plenty of energy and motivation,
I would think that these changes could be done in a reasonable
timeframe, perhaps with a little guidance from the original authors of
the respective components.
Steve
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
To me, validator and tiles are part of the core. Without
them, struts loses
much of its utility and importance.
David
From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED],
'[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: Tiles Refactorings for 1.1 compatability
Date: Wed, 16 Oct 2002 14:54:18 -0500
At 12:27 PM -0700 2002/10/16, Martin Cooper wrote:
Now that we have modules in play, would anyone VETO adding
the capability to have a delimited list of struts-
configs (for each module) -- to match what we do with the
tiles and validator configurations? If for no other
reason, than because we should be providing a consistent
approach across components.
Would I veto adding new functionality in a second beta that
everyone is
waiting for a final release of? I'd have to seriously consider it.
Would it seriously mess up the current release cycle to
decouple Tiles and
Validator from the core as an attempt to simplify the 1.1
release? It
seems like there needs to be a middle-ground between the
contrib folder
and the core where useful tools can be developed and
released without
interfering with the core.
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes
get glazed,
they go white, their hands tremble As I watch them I
often feel that a
dope peddler is a gentleman compared with the man who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
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]
Re: Tiles Refactorings for 1.1 compatability
I think I like your intent, but I fail to see how this would accomplish it. Ted Husted wrote: 10/16/2002 2:43:57 PM, Eddie Bush [EMAIL PROTECTED] wrote: Do we need a proposal maybe? As a rule, we propose through code, since that's all we can really vote on anyway =:0) My only point is that if I patch the controller to support a delimited list of struts-configs, as we do with Tiles and the Validator, then we have the choice between the Chinese wall approach to modules, or just diving up elements between multiple files. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
JSF is still a moving target, isn't it? Assuming we get the current outstanding issues cleared and cut 1.1F in a reasonable time-frame (tbd), I really don't think it would take long to implement the additional changes required to make modules communicate. It's really an insignificant change the way I view it right now. Maybe I'm being short-sighted. Byrne, Steven wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11950] - Missing script in generated javascipt
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=11950. 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=11950 Missing script in generated javascipt --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 21:21 --- IE 5.5 does, NS 6+ should as well. I'll have to check the others to be sure. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Multiple struts config files (was RE: Tiles Refactorings for 1.1 compatability)
+1 Choice is good, and this sounds like something we could offer through the Contrib folder or on Struts Sourceforge. 10/16/2002 5:00:58 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I developed a system that handles the need for having multiple components of a Struts application (Struts, Tiles, Validator, etc) partitioned in a modular fashion, so that independent groups could work on their component parts without having to worry about what other groups were doing, and yet allow for seamless integration of these components at web application assembly time. It was a requirement that all of this be done without requiring modification to Struts proper, so this is an approach that can be layered on top of a basic Struts implementation. I had wanted to bring this up a week or so ago when Eddie was talking about this topic, but was too busy then. The basic approach is to define a mechanism which allows module authors to work on individual modules using fragments which are then assembled into the final Struts files by Ant. The fragments are XML files which are essentially well-formed versions of the corresponding Struts files. The Ant process uses some style sheet tricks to collect the set of fragments, coalesce the relevant portions of the files into the proper sections (action-mappings, form-beans, etc) in the target XML files (mostly struts-config.xml needed this coalescing). Identifier collisions were avoided by a identifier prefixing scheme where each module would have it's own prefix. If there's interest in examining this approach, I can go into more detail about its operation. It worked well for us, and seems to fit the bill for a way to address the need for modular but not totally independent web applications. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. -- 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]
Re: RE: Tiles Refactorings for 1.1 compatability
If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1, 1.2, and 1.2+ (formerly 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML, I can take it off the list if that's what it takes. -T. 10/16/2002 4:47:29 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:13:19 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:01:55 PM, Eddie Bush [EMAIL PROTECTED] wrote: I think it's reasonable we would fix things to be independent now, as Martin and Craig have suggested, and then look at making modules cooperate next. I'm not talking about anyting to do with modules cooperating or not. I'm just saying that the supplemental Struts configuration files (for Validator and Tiles) can be specified as a list, but the main struts-config cannot be. In my experience, many teams just want multiple configuration files, period. This gives people what they want (multiple configs), without giving them something else they might not want (Chinese walls within the application). Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Craig Context-relative? Ok, but you have no sharing in that scenario. The contextRelative approach just says interpret this as relative to the application root path - I don't see how that makes sense here, but I'm surely missing something. The purpose of a Tiles Definition is utilimately to include tiles, which means we need to specify a path to the tile. If we can mark some of the paths to be application-relative, then the modules can share tiles. think) what is desirable (what I understood you were after) would be to say oh - this definition extends that one, but *that* one happens to be in a different module. Am I on the wrong page here? I know this is my goal - that's what I'm after. That would be cool, but it doesn't need to be in this release. Both the ActionMappings and the Definitions should support this type of extending in some future release (probably 1.2+). -Ted. -- 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 13239] - Validator Not accepting yyyy/MM
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=13239. 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=13239 Validator Not accepting /MM [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 21:24 --- Have you tried setting datePatternStrict in validation.xml ? You might also look into the mask validation type? /MM is not really a date per say, and is really out of the scope of the validator at least for Struts 1.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 16:53:48 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: RE: Tiles Refactorings for 1.1 compatability If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1, 1.2, and 1.2+ (formerly 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML, I can take it off the list if that's what it takes. IMHO, any rational roadmap for post-1.1 is going to have to lump proposed changes into at least two buckets: * Those that can be implemented on Servlet 2.2 / JSP 1.1, including refactoring of existing functionality (but with a continued emphasis on backwards compatibility). * Those that require updating the minimum platform to Servlet 2.3 / JSP 1.2 (JSTL and JavaServer Faces will both fall into this camp, as would any refactoring that depended on being able to use Filters). My personal interests are in the latter area, but I wouldn't be surprised to see many folks wanting to work on the former. Maybe we can colloquially think about categorizing things in the appropriate buckets, and think about calling them Struts 1.2.x and Struts 2.0.x (with the .x representing milestone releases like Tomcat 4.1 and Apache httpd do it)? -T. Craig 10/16/2002 4:47:29 PM, Byrne, Steven [EMAIL PROTECTED] wrote: I would think that before Ted or anyone can answer the question of whether to wait until 1.2, a clear roadmap of near term future releases, including features and functionality lists for each release, be published. Right now, saying that it's ok to wait until 1.2 is pretty much meaningless without a time estimate based on the amount of content going into 1.2 (or even a definition of what 1.2 is). When I talked with Craig a few months back, he was thinking that the next release of Struts would be focused on incorporating JSF related functionality; I don't know if that's still the case. If it is, that would make for a much more significantly challenging release, and thus would extend the time that people would have to wait for a fully working tiles/validator version of Struts. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:34 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 4:03:01 PM, V. Cekvenich [EMAIL PROTECTED] wrote: Can you wait till 1.2 Ted? All that I'm saying is that we should support specifying a list of struts-config files, as we do for the validator and tiles configs. This way people could split up the config files without buying into modules. Craig wanted to pursue modules to support URI-independance, but now that we done that I think we should support the obvious solution too. The only other thing I meant to say is that if we're going to call Tiles 1.1 compliant, it should have the same contextRelative property we see on the ActionForward. I didn't mean to say that there should be a gobal Tiles config or anything like that. In both cases, I'm just saying we should consistently complete what we started. Beta are for finding oversights and inconsistencies as well as malfunctions. But if everyone is on board for cutting a quick 1.2 release to catch issues we are postponing now, I'm willing to play along (again). My only concern is that post 1.1, we will also want to talk about things like servlet 2.3 support. My concern is that those discussions might become an excuse to postpone finishing what we (only) started here. But with more committers on board, perhaps we can afford to work on more than one code stream now. -Ted. -- 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] -- 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]
Re: Tiles Refactorings for 1.1 compatability
On Wed, 16 Oct 2002, Ted Husted wrote: Date: Wed, 16 Oct 2002 17:29:35 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Refactorings for 1.1 compatability 10/16/2002 5:22:13 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Don't have time to dive into the substantive technical details today, but in general I'm OK with a strategy of comma-delimited list of struts-config.xml resource files used to configure a single app module (consistent with the Tiles and Validators styles). I presume this just means running as many Digester.parse() calls as you need, and no other fundamental changes, right? Yes. Sorry if I was obtuse. I really should have just committed the change first, and talked about it afterwards. I guess that why we work by Lazy Consensus =:0) But I'll go ahead and do that next and see if anyone squawks. It's easier to ask for forgiveness than permission :-) -Ted. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
