RE: Plugins and Modules (Sub-Apps)
if you can fix it ... cause it seems that you have a better understanding of the problem than I have :) just a question: is it a Plugin interface conception issue ? or just a plugin implementation issue ? -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: mercredi 2 octobre 2002 19:55 To: Struts Developers List Subject: Re: Plugins and Modules (Sub-Apps) There are a very limited number of places that would have to change to fix this. Please let me know if you intend to patch this. If not, I'll do it myself (going to need that working for sub-apps soon). Thanks :-) Eddie Eddie Bush wrote: Nasty ... I hadn't dug into the source yet on that issue, but I don't doubt you are correct. All sub-application configurations are stored in application scope and a reference given to them in the request when appropriate (under the same key the default-app gets in the application scope, I believe). The key used ends in config for the default sub-app and config/module for each module (module being the actual name of the module :-) I would think this same strategy should be followed by the plugins. If a plugin does not follow this strategy, I would consider it a bug - and file a report in Bugzilla. Of course, if you happen to have the time to put your heel down firmly on this certain bug, feel free to do so (and submit a cvs diff -u as a patch, please!). Bugzilla can be reached at: http://issues.apache.org/bugzilla (I believe) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Etudiant: Wanadoo t'offre le Pack eXtense Haut Dbit soit 150,92 euros d' conomies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant __ Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: org.apache.struts.util.AppException implementing an Interface
indeed, I did not pay a real attention to the name of the interface ! :) suggest anything you like and it will be great ! and what did you thnik of the opportunity to have an interface instead of a class for exceptions ? -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: mardi 1 octobre 2002 20:23 To: [EMAIL PROTECTED] Subject: Re: org.apache.struts.util.AppException implementing an Interface I don't think adding interfaces using hungarian notation (I prefix) is a very good idea. It decreases readability and makes the name nonsensical. It's especially not a good idea when none of the other interfaces used in struts have that notation. Dave From: phpsurf [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: org.apache.struts.util.AppException implementing an Interface Date: Tue, 1 Oct 2002 20:10:35 +0200 Well, that was a very smart suggestion ! So, what about creating this interface ? - this interface could be called org.apache.struts.util.IAppException - this interface would declare 2 methods: getError() and getProperty(). - this interface would be used by the default exception handler to recognize exceptions that carry an ActionError. - the AppException class would of course implement this interface. I would also suggest that an Exception can carry more than one ActionError: either an ActionErrors instance or an HashMap of ActionError instances ... Then we could have one more method in the IAppException: getErrors() Any idea about that ? I can prepare a patch if someone is interested ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: vendredi 20 septembre 2002 16:27 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 12819] - org.apache.struts.util.AppException should have protected properties instead of private properties 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=12819. 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=12819 org.apache.struts.util.AppException should have protected properties instead of private properties --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 14:26 --- Make private member protected and add constructor for arrays. This make it consistent with ActionMessage interface, and ActionError. I Smell an interface here :-) !!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: org.apache.struts.util.AppException implementing an Interface
indeed, when handling an AppException, instead of creating a new ActionError(key) with the key defined in the config and no args, the ExceptionHandler gets the ActionError from the AppException. This way, you can throw exceptions that build their own ActionError, using the ActionError(key, args) constructor ... A simple example, imagine you want to throw an InvalidLoginException(login) that has a 'login' property. If InvalidLoginException extends AppException, you can pass the 'login' property to the ActionError constructor, which is not possible with the fully-declarative way. So the 'login' property can be used to build an more customized error message in your jsp handling this error ... It's just a very simple example of what could be done ... -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: mercredi 2 octobre 2002 16:52 To: [EMAIL PROTECTED] Subject: RE: org.apache.struts.util.AppException implementing an Interface I don't understand the use of AppException in the first place. Looking at the code for ExceptionHandler, there is a check to see if the exception is an AppException but other types of Exceptions are handled in a similar way. It's not clear to me why I should subclass AppException when my business classes should be isolated from all Struts classes. Can anyone explain why I would want to use AppException? Dave From: phpsurf [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: org.apache.struts.util.AppException implementing an Interface Date: Wed, 2 Oct 2002 11:15:19 +0200 indeed, I did not pay a real attention to the name of the interface ! :) suggest anything you like and it will be great ! and what did you thnik of the opportunity to have an interface instead of a class for exceptions ? -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: mardi 1 octobre 2002 20:23 To: [EMAIL PROTECTED] Subject: Re: org.apache.struts.util.AppException implementing an Interface I don't think adding interfaces using hungarian notation (I prefix) is a very good idea. It decreases readability and makes the name nonsensical. It's especially not a good idea when none of the other interfaces used in struts have that notation. Dave From: phpsurf [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: org.apache.struts.util.AppException implementing an Interface Date: Tue, 1 Oct 2002 20:10:35 +0200 Well, that was a very smart suggestion ! So, what about creating this interface ? - this interface could be called org.apache.struts.util.IAppException - this interface would declare 2 methods: getError() and getProperty(). - this interface would be used by the default exception handler to recognize exceptions that carry an ActionError. - the AppException class would of course implement this interface. I would also suggest that an Exception can carry more than one ActionError: either an ActionErrors instance or an HashMap of ActionError instances ... Then we could have one more method in the IAppException: getErrors() Any idea about that ? I can prepare a patch if someone is interested ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: vendredi 20 septembre 2002 16:27 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 12819] - org.apache.struts.util.AppException should have protected properties instead of private properties 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=12819. 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=12819 org.apache.struts.util.AppException should have protected properties instead of private properties --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 14:26 --- Make private member protected and add constructor for arrays. This make it consistent with ActionMessage interface, and ActionError. I Smell an interface here :-) !!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc
Plugins and Modules (Sub-Apps)
Hi, looking at the code of the validator plugin (I needed an example to write a plugin), I saw that the plugin stores the validation resources into the servletContext, using the key 'org.apache.commons.validator.VALIDATOR_RESOURCES' the problem is that the validator configuration is specific to one module. so you have to add a plugin in the struts-config.xml of every module. but everytime the ValidatorPlugin.init() is called, it replaces the previous object in the context, because it uses the same key ... so I guess the key should be module dependant ? or is there a module-context where module-relative objects can be stored ? __ Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Possible bug or missing feature in ForwardAction
Hi the ForwardAction seems not to be compliant with sub-applications ... The path of the jsp passed as parameter to ForwardAction (in struts-config.xml) has to be context-relative, instead of module relative ... is that a bug or a desired feature ? :) Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Possible bug or missing feature in ForwardAction
Hi the ForwardAction seems not to be compliant with sub-applications ... The path of the jsp passed as parameter to ForwardAction (in=20 struts-config.xml) has to be context-relative, instead of module=20 relative ... is that a bug or a desired feature ? :) Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Possible bug or missing feature in ForwardAction
here is a patch that could solve this problem.
execute() method of org.apache.struts.actions.ForwardAction
if you have any comment about it ...
---
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
// Create a RequestDispatcher the corresponding resource
String path = mapping.getParameter();
if (path == null) {
response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
messages.getMessage(forward.path));
return (null);
}
// translate a context-relative path into a module-relative path
ForwardingActionForward fw = new ForwardingActionForward(path);
path = RequestUtils.forwardURL(request, fw);
// /translate a context-relative path into a module-relative path
RequestDispatcher rd =
servlet.getServletContext().getRequestDispatcher(path);
if (rd == null) {
response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
messages.getMessage(forward.rd, path));
return (null);
}
// Forward control to the specified resource
rd.forward(request, response);
// Tell the controller servlet that the response has been created
return (null);
}
---
-Original Message-
From: phpsurf [mailto:[EMAIL PROTECTED]]
Sent: mardi 1 octobre 2002 14:56
To: Struts-Developers
Subject: Possible bug or missing feature in ForwardAction
Hi
the ForwardAction seems not to be compliant with sub-applications ...
The path of the jsp passed as parameter to ForwardAction (in=20
struts-config.xml) has to be context-relative, instead of module=20
relative ...
is that a bug or a desired feature ? :)
Etudiant: Wanadoo t'offre le Pack eXtense Haut Dbit soit 150,92
euros d' conomies !
Et pour 1 euro de plus, reois le CD-ROM du jeu Dark Age of Camelot
+ 1 mois de jeu en r seau offert !
Clique ici : http://www.ifrance.com/_reloc/mail.etudiant
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies !
Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot
+ 1 mois de jeu en réseau offert !
Clique ici : http://www.ifrance.com/_reloc/mail.etudiant
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
org.apache.struts.util.AppException implementing an Interface
Well, that was a very smart suggestion ! So, what about creating this interface ? - this interface could be called org.apache.struts.util.IAppException - this interface would declare 2 methods: getError() and getProperty(). - this interface would be used by the default exception handler to recognize exceptions that carry an ActionError. - the AppException class would of course implement this interface. I would also suggest that an Exception can carry more than one ActionError: either an ActionErrors instance or an HashMap of ActionError instances ... Then we could have one more method in the IAppException: getErrors() Any idea about that ? I can prepare a patch if someone is interested ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: vendredi 20 septembre 2002 16:27 To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 12819] - org.apache.struts.util.AppException should have protected properties instead of private properties 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=12819. 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=12819 org.apache.struts.util.AppException should have protected properties instead of private properties --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 14:26 --- Make private member protected and add constructor for arrays. This make it consistent with ActionMessage interface, and ActionError. I Smell an interface here :-) !!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: VOTE: Behavior of Validator
+1 definitely I definitely agree with both: - The validation process should first iterate through all fields and then, for each field, iterate through its scpecific validation rules. - The validation process can stop (for each field) at the first unvalidated rule, but it should not stop at the first unvalidated field ... -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: jeudi 19 septembre 2002 19:41 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: VOTE: Behavior of Validator As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How to extend AppException
Hi when looking at the default ExceptionHandler implementation, I saw that there was a special behaviour when handling org.apache.struts.util.AppException. This allows to pass arguments to the Exception that will be used to build the error message. I would like to benefit from this in my project. So my first idea was to have all my applicative Exceptions extend this AppException. But the problem is that its properties are private instead of protected, so it's quite difficult to add some features to the class ... Would this need a patch ? Any idea ? Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
How to extend AppException
Hi when looking at the default ExceptionHandler implementation, I saw that there was a special behaviour when handling org.apache.struts.util.AppException. This allows to pass arguments to the Exception that will be used to build the error message. I would like to benefit from this in my project. So my first idea was to have all my applicative Exceptions extend this AppException. But the problem is that its properties are private instead of protected, so it's quite difficult to add some features to the class ... Would this need a patch ? Any idea ? Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros d'économies ! Et pour 1 euro de plus, reçois le CD-ROM du jeu Dark Age of Camelot + 1 mois de jeu en réseau offert ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
