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]
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]
Re: Plugins and Modules (Sub-Apps)
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) phpsurf wrote: 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 ? -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
Re: Plugins and Modules (Sub-Apps)
The bug report was already filed on this - you can find it at: http://issues.apache.org/bugzilla/show_bug.cgi?id=10348 -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Plugins and Modules (Sub-Apps)
Compiling 1 source file to /home/eddie/dvel/projects/jakarta-struts/target/library/classes Note: /home/eddie/dvel/projects/jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details. Transforming into /home/eddie/dvel/projects/jakarta-struts/target/library Manifest is invalid: The attribute Class-Path may not occur more than once in the same section build.xml [341] Invalid Manifest: /home/eddie/dvel/projects/jakarta-struts/conf/share/MANIFEST.MF BUILD FAILED I've been arranging a Netbeans project around the distribution - still using ant to build though :-) - because I wanted the convenience of completion Netbeans provides. Ant (I'm guessing just the version included with Netbeans? I've never seen this) doesn't seem to like the multiple Classpath: lines in the manifest. Is this because of the version of ant included with Netbeans (1.4.1)? How else could I represent this information (on a single line? seperated by colons?) so that the build will succeed? I'm not familiar with manifests. I've started in on the Validator patch, since nobody else has claimed ownership. If someone else is currently working on this, please speak up! (I seem to recall someone being added to the committer team for ... commons was it? ... to address deficiencies in the Validator. Is this something that is currently in the works by that person? Should I, then, even address [prepare a patch for] this?) Eddie Bush wrote: The bug report was already filed on this - you can find it at: http://issues.apache.org/bugzilla/show_bug.cgi?id=10348 -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Plugins and Modules (Sub-Apps)
I put them all on a single line - colon-delimited - and it builds fine. Since I won't ever be committing, it really doesn't matter what *my* manifest looks like - it just has to work! -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Plugins and Modules (Sub-Apps)
On Wed, 2 Oct 2002, Eddie Bush wrote: Date: Wed, 02 Oct 2002 14:32:43 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Plugins and Modules (Sub-Apps) Compiling 1 source file to /home/eddie/dvel/projects/jakarta-struts/target/library/classes Note: /home/eddie/dvel/projects/jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details. Transforming into /home/eddie/dvel/projects/jakarta-struts/target/library Manifest is invalid: The attribute Class-Path may not occur more than once in the same section build.xml [341] Invalid Manifest: /home/eddie/dvel/projects/jakarta-struts/conf/share/MANIFEST.MF BUILD FAILED Sigh ... I wish product vendors would get this kind of thing right ... :-( The spec for MANIFEST.MF files *explicitly* allows more than one Class-Path entry, so the above error message is probably a bug in NetBeans. You might recall that we split up the initial (very long) classpath line because WebLogic's JVM croaked on it, even though that is lega as well. Sheesh. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Plugins and Modules (Sub-Apps)
When I have had problems with a Class-Path entry in the manifest.mf of a weblogic ejb jar file, I have always been able to fix the problem by adding a space at the end of the line. Not sure if that would always fix it but it's worth a try. I can't recall for sure if the problem was with Weblogic or with the Ant EJB task but changing the length of the line has made the problem go away on several occasions that I know of. There must be a weird parsing error that manifests itself in some cases. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 6:21 PM To: Struts Developers List Subject: Re: Plugins and Modules (Sub-Apps) On Wed, 2 Oct 2002, Eddie Bush wrote: Date: Wed, 02 Oct 2002 14:32:43 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Plugins and Modules (Sub-Apps) Compiling 1 source file to /home/eddie/dvel/projects/jakarta-struts/target/library/classes Note: /home/eddie/dvel/projects/jakarta-struts/src/share/org/apache/ struts/taglib/html/JavascriptValidatorTag.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details. Transforming into /home/eddie/dvel/projects/jakarta-struts/target/library Manifest is invalid: The attribute Class-Path may not occur more than once in the same section build.xml [341] Invalid Manifest: /home/eddie/dvel/projects/jakarta-struts/conf/share/MANIFEST.MF BUILD FAILED Sigh ... I wish product vendors would get this kind of thing right ... :-( The spec for MANIFEST.MF files *explicitly* allows more than one Class-Path entry, so the above error message is probably a bug in NetBeans. You might recall that we split up the initial (very long) classpath line because WebLogic's JVM croaked on it, even though that is lega as well. Sheesh. Craig -- 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: Plugins and Modules (Sub-Apps)
Odd - Craig's post hasn't hit here yet. I'll reply below - I'm not running WebLogic so this isn't an issue to me at all. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 6:21 PM To: Struts Developers List Subject: Re: Plugins and Modules (Sub-Apps) On Wed, 2 Oct 2002, Eddie Bush wrote: Date: Wed, 02 Oct 2002 14:32:43 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Plugins and Modules (Sub-Apps) Compiling 1 source file to /home/eddie/dvel/projects/jakarta-struts/target/library/classes Note: /home/eddie/dvel/projects/jakarta-struts/src/share/org/apache/ struts/taglib/html/JavascriptValidatorTag.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details. Transforming into /home/eddie/dvel/projects/jakarta-struts/target/library Manifest is invalid: The attribute Class-Path may not occur more than once in the same section build.xml [341] Invalid Manifest: /home/eddie/dvel/projects/jakarta-struts/conf/share/MANIFEST.MF BUILD FAILED Sigh ... I wish product vendors would get this kind of thing right ... :-( You and me too, bud - you and me too :-/ The spec for MANIFEST.MF files *explicitly* allows more than one Class-Path entry, so the above error message is probably a bug in NetBeans. Well, I'm using the integrated ant to build. Netbeans actually calls it, but it's ant that does it -- Netbeans just ... well I prefer to let ant do my building :-) (I'm not going to bad-mouth netbeans, because I don't like the way other IDEs do it either) Was this a bug in ant 1.4.1 maybe? It's really insignificant, I suppose. As I said, it's doubtful I'll be committing and my container (Tomcat :-) doesn't seem to give me any fits, so joining the entries with colons onto a single line is how I've solved this. You might recall that we split up the initial (very long) classpath line because WebLogic's JVM croaked on it, even though that is lega as well. Nope - not being on WebLogic I don't follow their issues especially close. Sheesh. Craig LOL - no, it's not funny, but I can actually see the disgust on your face ... :-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Plugins and Modules (Sub-Apps)
problem go away on several occasions that I know of. There must be a weird parsing error that manifests itself in some cases. Nice pun! Oh wait, it isn't Friday yet, sorry. -Max -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
