struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dusty <>
Subject Re: UknownHandlers
Date Fri, 06 Jun 2008 16:34:09 GMT

The high priority goal is to get a single RESTful action invocation and
configuration convention stack for Struts2.  The reason for this particular
discussion is the Convention plugin is generally accepted as being a better
option than Codebehind.  There are still Codebehind-based apps out there and
so if a move was made to favor Convention, then Convention should at least
provide some backward compatibility for existing Codebehind apps.  

In my opinion, there should never have been a Convention and Smart-URLs
plugin to start with.  These new features would have been added/merged to
the general S2 configuration system.  90+% of S2 developers are not going to
implement their own ActionMapper, Dispatcher, etc.  They just want to know,
"How do I do REST with S2?"  or "How do I build S2 apps with no XML
config?".  S2 is awesome because it gives you knobs for just about anything
you want to tweak, but we have got to start hiding these knobs from the
masses with "The Way".

I am really not familiar with the Apache process and how Road Maps get
decided and code gets accepted into the trunk, but it feels like S2 is kind
of stuck and it seems like the process lends itself to all these branched
approaches.  I say, implement the proposed change to how UnknownHandlers are
processed so that legacy Codebehind apps are supported and move on to more
important issues on the Road Map.  Put declarative plugin dependency on the
list Road Map and prioritize.

Al Sutton wrote:
> 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 run after G 
>>> then B needs to declare G as a dependency.
>> Right. That's my main point. Otherwise, they end up being root nodes 
>> in the graph and traversal is based on parse order and that means it 
>> could be different each time if the parse order changes. When you have 
>> four root nodes, which goes first? That's a tough question to answer 
>> and guessing means it could be right during one pass and wrong during 
>> another, especially as you introduce other root nodes.
> If they are all root nodes then it does not matter which is processed 
> first. If one of the nodes has a dependency on another being processed 
> before it then it needs to declare it (and thus can't be a root node), 
> or the plugin implementation has a bug, if they do not depend on each 
> other then they are four separate plugins whose order of execution does 
> not matter, and therefore there is no right or wrong solution. Therefore 
> if A,B,C and D and they are all truely root nodes it does not matter if 
> the order is ABCD or DCBA, because are non-dependant.
>>> 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.
>> Nope, I'm assuming everything is mandatory. I'm just assuming 
>> incomplete graph knowledge up front and having to make choices in a 
>> sort of fuzzy manner.
> And the "fuzzyness" is eliminated by the declare or die rule. If the 
> plugin implementor does not declare it's dependencies correctly then 
> failure by the core code to create the correct set of pre-conditions is 
> actually a bug in the plugins dependency declarations.
>>> 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.
>> Agreed. But the trade off of complexity here isn't worth it it seems. 
>> The configuration is minimal and the complexity of a dependency 
>> management graph and traversal seems to be too much. Furthermore, it 
>> adds a bit of "magic" that users might find disconcerting. Savant on 
>> the other hand is based purely on this "magic" and integral to the 
>> system. This means users need to fully understand it to use Savant. 
>> Struts on the other hand would probably suffer from this to some 
>> degree. I would think it would be like the JBoss infrastructure. Some 
>> folks would love it because of all its dependency management coolness 
>> but most folks would hate it for the complexity and inability to 
>> quickly figure out what the heck is going on.
> I don't see the magic or the complexity. Plugins declare their 
> dependencies, the core code orders the execution list, and all is good. 
> If they want to use conflicting plugins which require a specific order 
> they can add some configuration information, but in most cases this will 
> most likley not be neccessary.
> Still, it looks like the plugin dependency idea is a non-starter anyway, 
> so I guess it's on to other things.
> Al.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View this message in context:
Sent from the Struts - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message