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]
