DO NOT REPLY [Bug 14082] - minlength of DynaValidatorForm fails to validate Password field
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=14082. 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=14082 minlength of DynaValidatorForm fails to validate Password field [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 08:10 --- *** This bug has been marked as a duplicate of 12473 *** -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 12473] - password fields are not validated using javscript (lengths)
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=12473. 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=12473 password fields are not validated using javscript (lengths) [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 08:10 --- *** Bug 14082 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14042] - Memory leaks with JBoss 3.x +(Tomcat/Jetty)
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=14042. 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=14042 Memory leaks with JBoss 3.x +(Tomcat/Jetty) --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 09:10 --- Okay, the problem is not JBoss specific. With a plain Tomcat 4.0.6 I added in server.xml a reloadable context: Context path=/jakarta-struts-1.1-b2-blank docBase=jakarta-struts-1.1-b2-blank reloadable=true/ Then I forced reloads every 15 seconds with: while true do touch webapps/jakarta-struts-1.1-b2-blank/WEB-INF/lib/struts.jar sleep 15 ps -p tomcat.pid -h -o rss done and the memory usage increased step by step from 30M to 155M, where the JVM began to throw OutOfMemoryExceptions. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
ResourceProperties in database
Hello, Is it possible to add a feature that can load messages from database. All the message resources are in a text file, it is not easy to manage if there are so many. Best regards, Eric == If you know what you are doing, it is not called RESEARCH! ==
Re: ResourceProperties in database
check it out at http://www.mail-archive.com/struts-user;jakarta.apache.org/msg44742.html Regards, Adolfo. From: Eric Chow [EMAIL PROTECTED] Reply-To: Eric Chow [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ResourceProperties in database Date: Wed, 30 Oct 2002 17:30:18 +0800 Hello, Is it possible to add a feature that can load messages from database. All the message resources are in a text file, it is not easy to manage if there are so many. Best regards, Eric == If you know what you are doing, it is not called RESEARCH! = _ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: ResourceProperties in database
Quite possible! And already done (custom) in our application, as well as Jame's OJB implementation. His implementation is far more robust than ours, but I just wanted to add our experience. It is actually quite trivial to implement a custom MessageResources subclass to do this. Erik Eric Chow wrote: Hello, Is it possible to add a feature that can load messages from database. All the message resources are in a text file, it is not easy to manage if there are so many. Best regards, Eric == If you know what you are doing, it is not called RESEARCH! == -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14042] - Memory leaks with JBoss 3.x +(Tomcat/Jetty)
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=14042. 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=14042 Memory leaks with JBoss 3.x +(Tomcat/Jetty) --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 13:25 --- In a recent nightly build I fixed a bug where the web.xml file was not being closed. Could you try the build from 20021029 to see if the same memory usage occurs ? -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14054] - Rename Application components to Module
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=14054. 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=14054 Rename Application components to Module --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 14:19 --- The superclass approach isn't a good approach, since it doesn't let me create ApplicationConfig objects from ModuleConfig. I looked through martin Fowlers Refactoring book, but it didn't help. The best way to go is using composition, the original plan, which will do this. It lets a ModuleConfig object be created from a ApplicationConfig object and a ApplicationConfig object from a ModuleConfig object. However, I am asking for --- ONE BIG EXCEPTION --- to the deprecation rule. To use composition I would like to delete the protected fields in the ApplicationConfig object. I see now why Craig likes to make fields private first and if someone has a good reason why not! Also I would like to make all the fields in ModuleConfig private ! If we ever go to other schemes for implementing ModuleConfigs this will make life much easier. We may want to use interfaces then (2.0) and going from a class with all private fields will be much easier ! This apporach will even allow all the protected fields in ActionConfig and other classes to remain unchanged. Is there a better suggestion, other than waiting till 2.0 ;-) ! -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14042] - Memory leaks with JBoss 3.x +(Tomcat/Jetty)
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=14042. 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=14042 Memory leaks with JBoss 3.x +(Tomcat/Jetty) --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 15:10 --- Tried build 20021030 and found the same as before. I also saw execption NoRouteToHostException 'cause some dtd resolver wants to connect to the internet. Don't know if that affects the phenomenon. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14054] - Rename Application components to Module
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=14054. 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=14054 Rename Application components to Module --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 15:14 --- I don't understand why the inheritance idea won't work. Why do you want to make an ApplicationConfig object from a ModuleConfig and vice versa? If you make ModuleConfig the parent then people subclassing ApplicationConfig can still pass that into methods that take a ModuleConfig object. If that works, you can just move the protected fields into ModuleConfig and people won't know the difference. I agree that we need to use interfaces but not for 1.1. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14054] - Rename Application components to Module
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=14054. 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=14054 Rename Application components to Module --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 15:32 --- The problem comes when constructing the new ModuleConfig in the constructor method there is a ActionConfig.setApplicationConfig(ApplicationConfig) which is public, so it MUST be supported but deprecated. If we created a ActionConfig.setModuleConfig(ModuleConfig) instead we would still need to support ActionConfig.setApplicationConfig(ApplicationConfig) So how do we do that ? Composition will work but inheritance,superclass, doesn't. Also we only want to store a ModuleConfig in the request scope, from which we can also create a ApplicationConfig. If we continued to store an ApplicationConfig in the request instead then that would probably force struts internally to continue to use the ApplicationConfig, which defeats the whole purpose of changing the Class/method names in the first place. Using inheritance there is no way, I know of to, to make a ApplicationConfig from a ModuleConfig, w/o copying or cloning pointers or datastructures, yuck. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application components
+1 on your proposed approach, including not doing the deprecated thing for stuff that was added after 1.1b2. Craig Bugzilla, Please :-) ! -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Nightly build issue
Eddie and others - that change did the trick. I'm now back in business
with Cactus tests! Many thanks. I'll keep the issue open with the
Cactus folks and I very well could be doing something strange in my test
case configuration as well, but at least Struts is still happy and now
I'm happy!
Erik
Erik Hatcher wrote:
I'm still not having any luck with this issue (now at the 20021029
build). I've been toying with the request.setURL call in a Cactus
beginXXX method, but that has no effect at all on this even though I can
tell my setting of the servlet path is working (in my testXXX I println
request.getServletPath()).
Very strange. I wonder if it has to do with the request value of
RequestProcessor.INCLUDE_SERVLET_PATH being blank instead?
Anyone have thoughts on this?
Would you mind making the than change, Eddie? I can try it on the
next build to see if my tests then start working.
Thanks,
Erik
Eddie Bush wrote:
Can you verify your assumption with the logging output? It should say
what the value of matchPath is. This would be a debug-level logging
statment indicated by a line stating:
Selecting module for path matchPath
You may have to turn up the volume on your logging output to see it.
I'd be most interested in what's going on here.
If there is a case where the first character of matchPath may not be a
/ then that condition needs to change to a instead of !=. I was
of the impression that the first element of that string would always
be a /.
Erik Hatcher wrote:
More information after digging a bit. The change to RequestUtils (in
version 1.61) has this log:
Revision : 1.61
Date : 2002/10/15 17:37:25
Author : 'ekbush'
State : 'Exp'
Lines : +33 -11
Description :
Change RequestUtils.selectApplication so that it looks for an exact
match
rather than using the startsWith criteria.This fixes a problem where
an incorrect module would be selected that either became aparant when
the application had modules where the name of one could be used as the
root
of the other.The bug also manifests itself when an action is invoked
from
the default module, which has a path that could be interpreted as a
root of
a non-default module.
Ex:modules /foo and /foobar
module /foo and action /foo in the default module
PR: 12702
And here is the relevant change:
while (prefix.equals()
((lastSlash = matchPath.lastIndexOf(/)) != 0)) {
// We may be in a non-default module. Try to get it's
prefix.
matchPath = matchPath.substring(0, lastSlash);
// Match against the list of module prefixes
for (int i = 0; i prefixes.length; i++) {
if (matchPath.equals(prefixes[i])) {
prefix = prefixes[i];
break;
}
}
}
lastIndexOf is obviously returning -1 meaning that there is no / in
matchPath. My application works fine deployed, so this seems like an
interaction with StrutsTestCase or Cactus with the servlet path being
null.
If anyone has ideas on where to dig further to see where a fix is
needed then I'd happily take it the extra distance and give it a shot
to fix it.
Erik
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14092] New: - RequestUtils.present() is looking for resources in wrong scope.
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=14092. 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=14092 RequestUtils.present() is looking for resources in wrong scope. Summary: RequestUtils.present() is looking for resources in wrong scope. Product: Struts Version: 1.1 Beta 2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Within struts, MessageResources is found by searching for it as request scoped attribute and then an application scoped attribute under the key Action.MESSAGES. This pattern holds true except for the present() method on RequestUtils. It search for it in page scoped, and then in application scoped. This causes issues because of the inconsistency. A patch file will follow. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14092] - RequestUtils.present() is looking for resources in wrong scope.
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=14092. 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=14092 RequestUtils.present() is looking for resources in wrong scope. --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 16:02 --- Created an attachment (id=3660) RequestUtils_Resource.txt -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14054] - Rename Application components to Module
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=14054. 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=14054 Rename Application components to Module --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 16:06 --- Why can't you change ActionConfig.setApplicationConfig(ApplicationConfig) to ActionConfig.setApplicationConfig(ModuleConfig) and have it call ActionConfig.setModuleConfig(ModuleConfig)? Because all ApplicationConfig objects are children of ModuleConfig the calls will still work (you can pass ApplicationConfig objects into methods taking ModuleConfig). I haven't looked too much at the code but I still don't see any reason you can't store ModuleConfig objects in the request instead of ApplicationConfig. Once ApplicationConfig is a child of ModuleConfig it doesn't matter which one we put in the request. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14094] New: - use of Attribute limits types of content, bloats code
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=14094.
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=14094
use of Attribute limits types of content, bloats code
Summary: use of Attribute limits types of content, bloats code
Product: Struts
Version: 1.1 Beta 2
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Tiles framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
low low priority
This came up because I was writing my own templating system, that groks
dreamweaver templates, with custom bits done as jsps (this lets us track the
work of the web designer more faithfully). The way I'd started writing it I had
four distinct subsystems: a parser, a templating engine (with no custom taggery)
in the middle, a servlet to render the templates, and some custom tags for
customisation jsps (they put content into the templates prior to rendering).
It occurred to me that I'd like to be able to use the tiles or template tags
instead of my own, to increase the amount of documentation available to our jsp
developers, and rely on many eyes for less bugs in the custom tags. The
abstractions I'd used for the template engine were reasonable enough and I
assumed this could be done; so, I read the code looking for an integration point.
Bottom line is I couldnt do it, because there was no way to pass the knowledge
that, for example 'this is an URL which needs the context path added' through
tiles, without editing the code of tiles itself. The types of content it
supports are hardcoded everywhere using 'instanceof'. Eg (from InsertTag):
public TagHandler processTypedAttribute(AttributeDefinition value)
throws JspException
{
if( value instanceof DirectStringAttribute )
return new DirectStringHandler( (String)value.getValue() );
else if( value instanceof DefinitionAttribute )
return processDefinition( (ComponentDefinition)value.getValue() );
else if( value instanceof DefinitionNameAttribute )
{
return processDefinitionName( (String)value.getValue() );
}
}
ew... this code would clearly make more sense (and be more extensible)
refactored to:
public TagHandler processTypedAttribute(AttributeDefinition value)
throws JspException {
return value.getTagHandler();
}
..., with appropriate getTagHandler() methods, and then removing the method
entirely. Big switches are clearly useful creating Attribute objects, since you
only have the string arguments of the Put tag as a guide, but it doesnt make
sense to limit yourself at output time to only objects you can define via the
Put tag.
A concrete example: you can include content from Beans using tiles, but only by
calling 'toString'. If you have a large chunk of text behind this (eg from a
content management system) the bean may be more efficiently written if it can
stream the content.
I realise adding an abstraction like this may be a non-goal, especially for
getting struts 1.1 out the door, but I'm just going to add some notes on the api
I ended up with in case this proves useful later. I'm sure you'd have better ideas!
My parse tree from the templates is built mainly from Content objects, like so:
public interface Content {
public void service(PageContext context,ContentMap[] stack)
throws ServletException, IOException;
// named (replaceable) content in a template is distinguished
// from anonymous content simply by having a non-null name.
public String getName();
}
(nb the names of some of the classes here may resemble those in tiles/templates,
but the apis are often different).
The PageContext passed in is similar to the JSP page context, and for similar
reasons - it gives Content access to beans in all the scopes. (I dropped a
couple of methods from JSP's PageContext - the ones to do with the 'body'). This
allows me to implement includes like so:
public void service(PageContext context, ContentMap[] stack) throws
ServletException, IOException {
context.include(value);
}
The relevance to tiles would be having the Put tag create PathAttribute objects
with this method, so they know how to render /themselves/.
The ContentMap[] passed is the equivalent of ContentMapStack in the 'templates'
library. The implementation of the service method of a Template, which uses
this, looks like:
public void service(PageContext context,ContentMap[] stack) throws
ServletException, IOException {
if (this.template!=null) {
context.getPage().service(context,template);
return;
}
Iterator iter=contentList.iterator();
Content
RE: Accessing DynaActionForm objects in JSTL tags?
At end.
-Original Message-
From: Craig R. McClanahan [mailto:craigmcc;apache.org]
Sent: Tuesday, October 29, 2002 11:44 PM
David == David Karr Karr writes:
David Presently JSTL tags can't easily access
DynaActionForm objects. I haven't
David used these much, but I would assume they're
reasonably widely used. How
David important do you think it is for JSTL tags to be
able to access properties
David of these objects?
As a proof of concept, I've verified that just by adding
the following to the
DynaActionForm class:
public Map getMap() {
return (dynaValues);
}
along with the following pre-Action code:
dynaActionForm.set(foo, alpha);
dynaActionForm.set(bar, beta);
The following JSP code:
c:out value=${dynabean.map.foo}//c:out
value=${dynabean.map.bar}/
prints out alpha/beta.
Therefore, I'm +1 to adding a getMap() method to
ActionDynaForm in Struts,
to make it possible for DynaBeans to interoperate with *standard* JSTL
tags (and, by the same token, with the standard capabilities
of JSP 2.0
containers). This won't be invisible, because the expression
will have to
be different, but at least it will be possible.
However, I don't believe this change should be done in the underlying
commons-beanutils APIs, because if you are using commons-beanutils
already, you have transparent access (via BeanUtils and
PropertyUtils) out
of the box, and need nothing more. And there might well be
environments
where DynaBean is implemented using techniques other than an
internal Map
-- it is not fair to constrain those possible implementations
by requiring
them to implement a potentially costly getMap() method.
This is one of the few times I've wondered whether multiple class
inheritance would be useful. Oh, well.
Does anyone else want to chime in on this?
If I commit this, I plan on also adding something to the paragraphs in the
user guide, along with something in the Struts-EL top-level package.html
description.
With respect to the user guide information on DynaActionForm, I noticed that
section 4.2.1 is titled DynaActionForm Classes, and 4.2.2 is titled
Map-backed ActionForms. Adding this new map information will require a
little clarification of those different map dimensions.
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14054] - Rename Application components to Module
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=14054. 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=14054 Rename Application components to Module --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 17:23 --- How about ApplicationConfig ActionConfig.getApplicationConfig() ? We still need to create a ApplicationConfig object, we aren't allowed to change the return type if we are to support recompile compatability. Since the method is public we have to assume that other people could be extending it, or using it in some way. It would be nice if Java had the equalivent of a friend class. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module
On 30 Oct 2002 [EMAIL PROTECTED] wrote: Rename Application components to Module It would probably be more convenient to have this conversation directly on STRUTS-DEV while we hash out the details :-). Regarding Rob's basic issue, it might be worthwhile to see how I treated essentially the same problem in the 1.0-1.1 transition. For example, the concept of ActionMapping (1.0) is now called ActionConfig (1.1). In that case, I did: * Put all the functionality that used to be in ActionMapping into ActionConfig (tweaking for new properties as needed, of course). * Made ActionMapping extend ActionConfig, and added the few extra method signatures needed for backwards compatibility to the old ActionMapping API. * In this case, I chose not to deprecate ActionMapping because it is part of the fundamental application APIs (i.e. we pass one to the Action, so changing that would have a *lot* of impact on existing applications). I don't think that argument applies to things like ApplicationConfig, which would be deprecated in favor of ModuleConfig. This approach is *not* binary backwards compatible (because the underlying inheritance hierarchy of ActionMapping changed), but it *is* source backwards compatible - a recompile against the new struts.jar makes everything work. So, this is a long-winded case of asking why can't we do this? * Move all the functionality of ApplicationConfig to ModuleConfig. * Make ApplicaitonConfig a subclass of ModuleConfig with no extra methods of its own. * Deprecate the ApplicationConfig class itself. * Modify all source references from ApplicationConfig to ModuleConfig (which is a fairly large, but fairly mechanical, exercise) -- and don't forget the unit tests :-). Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application components
So, this is a long-winded case of asking why can't we do this? The method public ApplicationConfig ActionConfig.getApplicationConfig() though this is only used 4 times in struts itself, it is public. Which means we assume that others extending struts may rely on it. So to remain recompile friendly we would have to create and return a ApplicationConfig object. To do this we have to internally contine to use it a ApplicationConfig object which is just messy. If we can just ignore this method and delete it then yes the superclass will be a clean way to go. In struts 1.0 methods like ActionMappings.getUnknown(), findMapping() are what required struts to continue to use ActionMappings internally. Is what prevented its removing/deprecation internally because the superclass method was used. Composition would have allowed the removal of this class internally. Composition will allow us to satisy BOTH requirements: 1) deprecate the class, 2) STOP using it internally. To continue to use both internally would cause more confusion. Craig Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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=11932. 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=11932 (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 22:07 --- This is a duplicate of #14092, which has a propsed patch, so I'm setting this one (even though it was logged first) *** This bug has been marked as a duplicate of 14092 *** -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14092] - RequestUtils.present() is looking for resources in wrong scope.
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=14092. 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=14092 RequestUtils.present() is looking for resources in wrong scope. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 22:07 --- *** Bug 11932 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13574] - taglib tld URIs need updating
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=13574. 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=13574 taglib tld URIs need updating --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 22:46 --- The JSTL tags don't include version number: http://java.sun.com/jstl/core instead of http://java.sun.com/jstl/core_1_0 so maybe we shouldn't either. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14107] New: - Request for addition to your 'Powered By Struts' section
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=14107. 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=14107 Request for addition to your 'Powered By Struts' section Summary: Request for addition to your 'Powered By Struts' section Product: Struts Version: 1.0.2 Final Platform: All URL: http://www.juliannegiffin.com OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Dear Sir/Madam, Please consider my Web site for your 'Powered By Struts' resources section at... http://jakarta.apache.org/struts/resources/powered.html ...my site uses Struts, JSPs, log4J, JDBC, regular servlets and applets to deliver an on-line site for learning and playing the card game Five Hundred (500) against friends or the computer! I also proudly display your logo :) on my opening page at... http://www.juliannegiffin.com Many thanks for your time. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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=11932. 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=11932 (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2002-10-31 00:15 --- Reopening because I believe they are different problems. Bug #14092 is about a problem with RequestUtils.present(), where it is looking in the wrong scope for the message bundle. Bug #11932 (this bug) is about a problem with RequestUtils.message(), where the module prefix is not being taken into account when looking for the bundle. One other point to note is that the code in these two methods is very similar, and the common part - including the fix for the module prefix - should probably be factored out into a separate private method. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Powered By Page
I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. Have I missed anything? How many pages do you have to put the logo on? Some of the sites listed need a review because I couldn't find the logo or the statement anywhere on the site. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
cvs commit: jakarta-struts/doc/resources powered.xml
dgraham 2002/10/30 18:10:31 Modified:doc/resources powered.xml Log: added juliannegiffin.com Revision ChangesPath 1.7 +1 -0 jakarta-struts/doc/resources/powered.xml Index: powered.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/powered.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- powered.xml 9 Oct 2002 06:25:29 - 1.6 +++ powered.xml 31 Oct 2002 02:10:31 - 1.7 -47,6 +47,7 pa href=http://www.webappwriter.com/;bwebAppWriter/b/a - write and deploy a J2EE app in 15 minutes./p pa href=http://www.windsurfpassion.com/;bWindSurfPassion/b/a - Dedicated to windsurfing./p !-- MISSING CREDIT 6/25/02 --pa href=http://wxxi.org/;bWXXI Spring MarketPlace 2001/b/a - Online auction for Public Television station./p +pa href=http://www.juliannegiffin.com/;bJulianneGiffin.com/b/a/p /section /chapter/body/document -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14107] - Request for addition to your 'Powered By Struts' section
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=14107. 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=14107 Request for addition to your 'Powered By Struts' section [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Newsletter - Request for content
Guess not. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: James Mitchell [mailto:jmitchtx;telocity.com] Sent: Wednesday, October 30, 2002 2:25 AM To: Struts Developers List Subject: RE: Newsletter - Request for content Any takers? James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: Rob Oxspring [mailto:roxspring;apache.org] Sent: Tuesday, October 29, 2002 7:12 PM To: 'Jakarta General List' Cc: 'Leo Simons'; 'Thomas Mahler'; 'John Keyes'; 'Stephane Bailliez'; 'Rob Oxspring'; 'Otis Gospodnetic'; 'Danny Angus'; 'Nicola Ken Barozzi'; 'Martin Cooper'; 'Andrew C. Oliver'; 'David Sean Taylor' Subject: Newsletter - Request for content Hi all, After a lapse last month its approaching time to put together another newsletter. As usual, I've cc'd those that submitted content last month in the hope that they will either submit something again, or try to persuade someone else to take over writing for the Sep-Oct issue. If anybody else fancies doing a write up of the progress in some Jakarta project it then please send it in. For a inspiration on content and style you can review previous entries at http://jakarta.apache.org/site/news/, although new styles and ideas are welcome too. Planned timescale: Submissions sent to me by midnight Sunday 3-Nov-2002. Drafts will be posted on Monday and Tuesday as needed for alterations and last minuters. Final copy sent out on [EMAIL PROTECTED] midday 6-Nov-2002 All times GMT. Thanks, Rob -- To unsubscribe, e-mail: mailto:general-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:general-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Powered By Page
Most were posted before the criteria came into effect. It would be good to clean house sometime, and then enforce the criteria proactively. -Ted. 10/30/2002 9:06:59 PM, David Graham [EMAIL PROTECTED] wrote: I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. Have I missed anything? How many pages do you have to put the logo on? Some of the sites listed need a review because I couldn't find the logo or the statement anywhere on the site. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Powered By Page
Why don't we remove the ones posted before the criteria? It seems like a reasonable requirement to display the powered by logo to be listed on the powered by page. David From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Powered By Page Date: Wed, 30 Oct 2002 22:21:16 -0500 Most were posted before the criteria came into effect. It would be good to clean house sometime, and then enforce the criteria proactively. -Ted. 10/30/2002 9:06:59 PM, David Graham [EMAIL PROTECTED] wrote: I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. Have I missed anything? How many pages do you have to put the logo on? Some of the sites listed need a review because I couldn't find the logo or the statement anywhere on the site. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application components
10/30/2002 1:29:38 PM, Robert Leland [EMAIL PROTECTED] wrote: So, this is a long-winded case of asking why can't we do this? The method public ApplicationConfig ActionConfig.getApplicationConfig() though this is only used 4 times in struts itself, it is public. Which means we assume that others extending struts may rely on it. It may be worthwhile to note that none of this has appeared in an action Release, only the beta. The number of people affected may be vanishingly small, or even non-existant. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: RE: Accessing DynaActionForm objects in JSTL tags?
10/30/2002 11:49:13 AM, Karr, David [EMAIL PROTECTED] wrote: Does anyone else want to chime in on this? If you want to make the change, broadening the use of DynaActionForms sounds like a worthwhile feature to me. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: RE: Newsletter - Request for content
I set aside some quality time on Sunday morning for volunteer work, and so I might be able to put something together then (unless Joe wants to step up again). -Ted. 10/30/2002 9:23:30 PM, James Mitchell [EMAIL PROTECTED] wrote: Guess not. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: James Mitchell [mailto:jmitchtx;telocity.com] Sent: Wednesday, October 30, 2002 2:25 AM To: Struts Developers List Subject: RE: Newsletter - Request for content Any takers? James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: Rob Oxspring [mailto:roxspring;apache.org] Sent: Tuesday, October 29, 2002 7:12 PM To: 'Jakarta General List' Cc: 'Leo Simons'; 'Thomas Mahler'; 'John Keyes'; 'Stephane Bailliez'; 'Rob Oxspring'; 'Otis Gospodnetic'; 'Danny Angus'; 'Nicola Ken Barozzi'; 'Martin Cooper'; 'Andrew C. Oliver'; 'David Sean Taylor' Subject: Newsletter - Request for content Hi all, After a lapse last month its approaching time to put together another newsletter. As usual, I've cc'd those that submitted content last month in the hope that they will either submit something again, or try to persuade someone else to take over writing for the Sep-Oct issue. If anybody else fancies doing a write up of the progress in some Jakarta project it then please send it in. For a inspiration on content and style you can review previous entries at http://jakarta.apache.org/site/news/, although new styles and ideas are welcome too. Planned timescale: Submissions sent to me by midnight Sunday 3-Nov-2002. Drafts will be posted on Monday and Tuesday as needed for alterations and last minuters. Final copy sent out on [EMAIL PROTECTED] midday 6-Nov-2002 All times GMT. Thanks, Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Powered By Page
Yes, now that the deadline has passed, someone could do that. 10/30/2002 10:23:35 PM, David Graham [EMAIL PROTECTED] wrote: Why don't we remove the ones posted before the criteria? It seems like a reasonable requirement to display the powered by logo to be listed on the powered by page. David From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List struts- [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Powered By Page Date: Wed, 30 Oct 2002 22:21:16 -0500 Most were posted before the criteria came into effect. It would be good to clean house sometime, and then enforce the criteria proactively. -Ted. 10/30/2002 9:06:59 PM, David Graham [EMAIL PROTECTED] wrote: I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. Have I missed anything? How many pages do you have to put the logo on? Some of the sites listed need a review because I couldn't find the logo or the statement anywhere on the site. David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Building Struts
I'm starting to work on source patches so I'm setting up my build environment for testing purposes. I've found this exercise both mundane and time consuming. Would it be worthwhile to post a zipped up build environment with a build.properties that's ready to go? Getting all the appropriate jars and setting the paths is the main problem. This would get new developers up and running immediately and maybe promote more involvement. If I'm the only one that feels this way, then it's not worthwhile (and maybe I'm going about it wrong). David _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Building Struts
I wholeheatedly agree. Just had to redo my environment on a new machine. +1. -james --- David Graham [EMAIL PROTECTED] wrote: I'm starting to work on source patches so I'm setting up my build environment for testing purposes. I've found this exercise both mundane and time consuming. Would it be worthwhile to post a zipped up build environment with a build.properties that's ready to go? Getting all the appropriate jars and setting the paths is the main problem. This would get new developers up and running immediately and maybe promote more involvement. If I'm the only one that feels this way, then it's not worthwhile (and maybe I'm going about it wrong). David _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Building Struts
Ok, When I get this working I'll clean it up and we can decide where to post it. David From: James Holmes [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Building Struts Date: Wed, 30 Oct 2002 19:40:21 -0800 (PST) I wholeheatedly agree. Just had to redo my environment on a new machine. +1. -james --- David Graham [EMAIL PROTECTED] wrote: I'm starting to work on source patches so I'm setting up my build environment for testing purposes. I've found this exercise both mundane and time consuming. Would it be worthwhile to post a zipped up build environment with a build.properties that's ready to go? Getting all the appropriate jars and setting the paths is the main problem. This would get new developers up and running immediately and maybe promote more involvement. If I'm the only one that feels this way, then it's not worthwhile (and maybe I'm going about it wrong). David _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Powered By Page
David Graham wrote: I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. I believe the criteria was not Struts specific. Just that they mention the Apache Foundation. I am not sure there was a mention of how accessable the credit had to be, but it would seem that somewhere within one click of the main page would be nice. You could always search the archives. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application components
Ted Husted wrote: 10/30/2002 1:29:38 PM, Robert Leland wrote: So, this is a long-winded case of asking why can't we do this? The method public ApplicationConfig ActionConfig.getApplicationConfig() though this is only used 4 times in struts itself, it is public. Which means we assume that others extending struts may rely on it. It may be worthwhile to note that none of this has appeared in an action Release, only the beta. The number of people affected may be vanishingly small, or even non-existant. I agree I would rather just do a global replace and be done with it, using IntelliJ of course. We could always put it up a notice on the USERS/DEVELOPERS LIST and evaluate any negative reactions. Sort of a JCP process. If we do deprecate, then Composition is still the cleanest way to go for struts internally. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Programmers Manual, Desing Documents.
Hi, I wanted to know about the programmers manual and architecture document. Additionally if there are documents on design etc on struts, it would be great. I wanted to know if they are in place, where can I download them from. Thanks. Regards, Rakesh +--+ Rakesh Malpani. R [EMAIL PROTECTED] Sr. Software Engg.,[EMAIL PROTECTED] Mentorix Ltd. [EMAIL PROTECTED] +--+ __ Outgrown your current e-mail service? Get 25MB Storage, POP3 Access, Advanced Spam protection with LYCOS MAIL PLUS. http://login.mail.lycos.com/brandPage.shtml?pageId=plusref=lmtplus -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module
Craig R. McClanahan wrote: So, this is a long-winded case of asking why can't we do this? * Move all the functionality of ApplicationConfig to ModuleConfig. * Make ApplicaitonConfig a subclass of ModuleConfig with no extra methods of its own. * Deprecate the ApplicationConfig class itself. * Modify all source references from ApplicationConfig to ModuleConfig (which is a fairly large, but fairly mechanical, exercise) -- and don't forget the unit tests :-). Craig I should also mention that last night when I was looking over the code I told IntelliJ to do the refactoring for just the above actions, 'extract super class'. I then reviewed what it intended to do, in about 30 instances. I told it not to change the return signatures on the methods. Based on that I realized that composition offered a clearer solution. Composition is more work because there isn't a refactoring button for 'replace object with facade'. I don't want to repeat myself but at the same time I feel like there is some key piece of information I am leaving out that would help you see that composition is the way to go. I'll wait until others have the chance to look it over more. You can always download a 30 trial of IntelliJ at www.intelliJ.net. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14116] New: - Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms
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=14116.
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=14116
Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms
Summary: Add getMap() method to DynaActionForm to let JSTL EL
reference DynaActionForms
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Standard Actions
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Presently, DynaActionForm properties cannot be referenced in JSTL tags, or in EL
references in Struts-EL tags (normal name/property references in Struts-EL can
still reference them).
If JSTL EL syntax could reference DynaActionForm properties, it would enhance
developer's ability to integrate Struts and Struts-EL tags with JSTL tags.
Fortunately, one simple change will provide this, although it will result in a
slightly different syntax.
By adding a single method to the DynaActionForm class, called getMap(), which
returns the HashMap of values, this allows EL references like
${bean.map.prop}, which references the prop property of the DynaActionForm.
There is some question whether it would be better to make this change in the
BeanUtils library itself, by changing the DynaBean interface. However, this is
not a good idea, as DynaBeans do not have to be implemented with a Map. Adding
a getMap() method to the interface would force all the inheriting classes to
not only define the method, but use that particular implementation.
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14116] New: - Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms
bugzilla == bugzilla [EMAIL PROTECTED] writes: bugzilla DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bugzilla RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14116. bugzilla ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bugzilla INSERTED IN THE BUG DATABASE. bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14116 bugzilla Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms bugzillaSummary: Add getMap() method to DynaActionForm to let JSTL EL bugzilla reference DynaActionForms bugzillaProduct: Struts bugzillaVersion: Nightly Build bugzilla Platform: Other bugzilla OS/Version: Other bugzilla Status: NEW bugzilla Severity: Enhancement bugzilla Priority: Other bugzilla Component: Standard Actions bugzilla AssignedTo: [EMAIL PROTECTED] bugzilla ReportedBy: [EMAIL PROTECTED] I'll commit this in a day or so when I can finish the doc changes and additions to the strutsel-exercise-taglib. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
