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( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, plugin);
}
should be;
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, thisPlugin);
}
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]
