struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Sutton <al.sut...@alsutton.com>
Subject Re: UknownHandlers
Date Wed, 04 Jun 2008 17:11:10 GMT
Brian,

Dependencies can be reduced to simple ordered lists unless there is a 
requirement for two plugins to be run in parallel (which is pretty 
rare), or you have a circular dependency. Reduction of dependency graphs 
is something I've come accros dependency declaration handling several 
times in my last couple of decades of development, and in all that time 
I've not seen a dependency evaluation system which couldn't run as an 
ordered list as long as you state it can't have parallel tasks or 
circular dependencies.

Plugins will have to define their dependencies if they want to be 
handled correctly, so if G needs to be run after D then D is a 
dependancy, and if the author of G does not declare it as such then that 
is an bug in plugin G. Similarly if B needs to be run after G then B 
needs to declare G as a dependency.

If you are talking about optional tasks then you then enter the more 
complex world of mandatory and optional dependencies (e.g. G should be 
run after D if D is configured, but if D isn't configured then we don't 
need to put it in the list). That is something to be handled on either a 
second pass once all of the configured plugins and their dependencies 
are known and have an initial order. During the second pass the entries 
are shuffled if neccessary to satisfy the option dependencies.

I understand there are situations where the user may want to run G 
between D and B and they can't modify B to declare G as a dependency, 
but thats where the manual configuration options come in. If a user 
wants to specify an order they can do so and the core should only verify 
the order satisfies the dependency requirements.

I'm not suggesting we strictly determine the order in the core and 
override any user configuration, I'm suggesting that we use the code to 
generate an intelligent default, and we also use the dependency 
declarations to check the sanity of user configurations.

Al.


P.S.  Using the algorithm I give and your dependencies (i.e. A ->B being 
A depends on B) and plugins ordered in the way you've listed them I get 
the order;

B, C, A, D, E, F, G

which would seem to satisfy the needs of your dependencies. Let me know 
if you've found a bug with it.



Brian Pontarelli wrote:
> In most cases dependencies rarely fall into simple lists. They often 
> form graphs, which can still be traversed, but it is slightly more 
> complex. The reason for the graph is that two plugins might have the 
> same dependencies and there might be multiple root nodes forming a 
> graph like:
>
> A -> B -> C
>     |    ^
> F -> D    |
>     \----/
>
> That being said, this solution doesn't solve the issue with specific 
> ordering based on dependencies of the plugin because you might have 
> complex situations like:
>
> A -> B -> C
> D -> B
> E -> A
> F -> C
> G
>
> The trickiest part is when G doesn't have dependencies defined ahead 
> of time, but after all is said and done, G really needs to run before 
> B but after D. Therefore, the final order might be:
>
> E -> A -> G -> D -> B -> F -> C
>
> But there is some flexibility because some dependencies could be 
> swapped according to the limited knowledge of each plugin and the 
> final graph.
>
> -bp
>
>
> Al Sutton wrote:
>> With UnknownHandler each plugin can define an unknown handler which 
>> is suitable for it and the code scans the list of plugins in reverse 
>> order (i.e. last one first to ensure that plugins can be listed in 
>> order of growing dependency needs) and uses the first one it finds.
>>
>> As for the dependency graph construction, it's just a list. Basically 
>> it goes something like this;
>>
>> List<Plugin> orderDependencies(Plugin[] plugins) {
>>    List<Plugin> orderedList = new ArrayList<Plugin>();
>>    if( plugins.length > 0 ) {
>>        addPluginAndDependencies(orderedList, plugins[0]);
>>   }
>>    return  orderedList;
>> }
>>
>> void addPluginAndDependencies(List<Plugin> orderedList, Plugin plugin) {
>>    if( orderedList.contains(plugin) ) {
>>       return;
>>    }
>>
>>    for( Plugin thisPlugin : plugin.getDependencies() ) {
>>       addPluginAndDependencies(orderedList, plugin);
>>    }
>>
>>    orderedList.add(plugin);
>> }
>>
>> Al.
>>
>>
>>
>> Musachy Barroso wrote:
>>> 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 
>>> <brian@pontarelli.com> 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 
>>>>>> <brian@pontarelli.com>
>>>>>> 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 
>>>>>>>> <brian@pontarelli.com>
>>>>>>>> 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: dev-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>
>>>>>>>>             
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>>
>>>>>>         
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>       
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>     
>>>
>>>
>>>
>>>   
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message