I think plugin dependencies are a no-go. We don't want to reinvent yet another plugin mechanism with dependency resolution and all. If there is something I like about S2 plugins it is how easy they are so write/use, lets not complicate it much. I think the UnknowHandler problem calls for an easy solution, and over-architecturing the whole thing would be bad. BTW, specifying the order in which plugins will be loaded wouldn't solved the UnknowHandler problem.
my 2 pesos :) musachy On Tue, Jun 3, 2008 at 11:37 AM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > I thought about a dependency list of JCatapult workflows and it can become > complex if a plugin doesn't know the entire set of other plugins that might > need to be invoked before it. In some cases what would happen is that 90% of > the plugins wouldn't list any dependencies but there might be some type of > underlying order that the application needs. > > I think it is better to just force the configuration on the users if they > have conflicting plugins. But if you could hash out the algorithm for the > dependency graph and ordering we could see if it would work. > > -bp > > > Al Sutton wrote: >> >> Why not expand it out and allow users to specify a plugin processing >> order?, that way any potential conflict of plugin handling method could be >> resolved by specifying an order. >> >> If we also introduced a dependency list in struts-plugin.xml the core code >> could not only take a stab at the right order if the user doesn't specify >> one, it could also verify that if a user specifies a plugin order the order >> given is valid and satisfies the dependencies. >> >> I know plugins are ideally not suppose to know or rely on other plugins, >> but there are some situations (such as this one) where it's useful to be >> able to specify an order. >> >> Al. >> >> >> Musachy Barroso wrote: >>> >>> I like Dusty's suggestion, or something like it: >>> >>> <unknown-handlers> >>> <unknown-handler name="UH1" /> >>> <unknown-handler name="UH2" /> >>> </unknown-handlers> >>> >>> musachy >>> >>> On Mon, Jun 2, 2008 at 2:36 PM, Brian Pontarelli <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>>> Not yet. Just thinking about how I'm going to pull it off. >>>> >>>> I'm using Guice for all the injection in JCatapult and we have this same >>>> situation in our Filter. There are a number of Workflow implementations >>>> that >>>> need to be called in order such as: JPA (open-session-in-view), >>>> static-resource, security, etc. Right now we are just managing the order >>>> in >>>> code. However, as I've been building out the MVC for JCatapult, I've run >>>> into the situation that these workflows are pluggable and still have a >>>> specific order. >>>> >>>> I've considered using a dependency graph to figure it out dynamically or >>>> some type of integer based indexing for each Workflow, but these all >>>> seem >>>> pretty lame. >>>> >>>> -bp >>>> >>>> >>>> Musachy Barroso wrote: >>>> >>>>> >>>>> Do you have an implementation of this already? >>>>> >>>>> musachy >>>>> >>>>> On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> Musachy Barroso wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> For those of you ignoring the spam on the Convention vote thread :). >>>>>>> I >>>>>>> mentioned that the framework should support more than one >>>>>>> UnknownHandler, which would eventually make Convention and Codebehind >>>>>>> compatible, as well as other plugins in the future. The bad side >>>>>>> effect is that some configuration would be needed for the order of >>>>>>> evaluation of the UnknownHandlers, as well as a default(first UH that >>>>>>> can handle the request will be the one used). Comment away. >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This is a large problem that I have been trying to solve for >>>>>> JCatapult. >>>>>> How >>>>>> do you allow plugins to be dropped in but somehow organize themselves >>>>>> correctly? The only solution I can think of is to have a configuration >>>>>> parameter that is a ordered list of named beans to use. If someone is >>>>>> going >>>>>> to be using both plugins, but will need to set this property by hand. >>>>>> If >>>>>> they only use one, then XWork can ignore the property because there >>>>>> aren't >>>>>> multiple UnknownHandlers in the container. >>>>>> >>>>>> If someone has other cool ideas that don't require configuration, let >>>>>> me >>>>>> know! >>>>>> >>>>>> -bp >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
