PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/UknownHandlers-tp17605029p17696523.html
Sent from the Struts - Dev mailing list archive at Nabble.com
Al Sutton wrote:
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
Brian Pontarelli wrote:
Al Sutton wrote:
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
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 -
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
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
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
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
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
Quick correction;
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, plugin);
}
should be;
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, thisPlugin);
}
Al Sutton wrote:
With
And;
if( plugins.length 0 ) {
addPluginAndDependencies(orderedList, plugins[0]);
}
should be;
for(Plugin thisPlugin : plugins) {
addPluginAndDependencies(orderedList, thisPlugin);
}
(Jeeze, it's one of those days :)).
Al.
Al Sutton wrote:
Quick correction;
for(
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
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
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
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,
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.
16 matches
Mail list logo
