struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: Should I announce SmartURLs or wait?
Date Tue, 11 Sep 2007 14:00:20 GMT
Well, the configuration provider is kinda a pain right now. I started a 
thread a while back about making configuration providers pluggable via 
the struts-plugin.xml file. I think it sorta died  because you can use 
init parameters to setup providers in web.xml.

In addition, if you want to use the extensionless support as well as all 
the index support of the plugin it requires a completely different 
filter, but it would be much nicer to have everything just plug-in and 
run with as little configuration as possible.

If we keep it a plugin then I would suggest removing zero-config from 
core so that they don't conflict. I'd probably also want to rework the 
DispatcherFilter to make it more pluggable so that the majority of the 
work is from injections and then it can be changed without modifying the 
web.xml. Lastly, the configuration providers need to be easier to setup. 
This would probably require a more robust configuration mechanism that 
would pre-inject configuration providers and then inject the rest of the 

However, all that said, I think this should be in core. The beauty of 
frameworks like Rails and Grails is that they give all the conventions 
right out of the box. I feel like Struts should try to strive to match 
the ease of these other frameworks. Otherwise, it requires the users to 
actually know that the plugin exists, go find it, install it and then 
learn it all.


Don Brown wrote:
> The reason the zero config stuff is in core is mainly because it
> requires a configuration provider, which cannot be plugged in via a
> struts plugin.  Is there any other technical reason that this should
> be in core?
> Don
> On 9/11/07, Musachy Barroso <> wrote:
>> IMO this should be a "core" feature of struts 2.
>> musachy
>> On 9/10/07, Don Brown <> wrote:
>>> Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
>>> other things, make OGNL pluggable and fully migrate the code to
>>> container injection (no statics!).  I should be done sometime this
>>> week.
>>> Don
>>> On 9/11/07, Ted Husted <> wrote:
>>>> Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>>>> could be out next week, or next month, or next year. There's really no
>>>> telling.
>>>> I'm not sure what "rolling it into the core" means. If it means
>>>> putting the source into the Struts-Core JAR, then I'd probably be
>>>> opposed. Personally, I'd like to keep rolling things out of the core
>>>> and distribute as much as possible in the form of plugins. Ultimately,
>>>> there should be nothing in the core that doesn't *need* to be in the
>>>> core. My thought would be to include SmartURLs in Struts 2.1.x as the
>>>> successor to the CodeBehind plugin.
>>>> -Ted.
>>>> On 9/10/07, Musachy Barroso <> wrote:
>>>>> +1 for waiting and rolling it into core, it could be available for 2.1
>>>>> musachy
>>>>> On 9/10/07, Brian Pontarelli <> wrote:
>>>>>> I was planning on release 1.0 of SmartURLs in the near future and
>>>>>> some announcements to the user lists and some other locations. However,
>>>>>> should I wait on that if favor of rolling this back into core, or
>>>>>> I go ahead?
>>>>>> Thoughts?
>>>>>> -bp
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message