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
<[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]
---------------------------------------------------------------------
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]
