On 12/13/12 12:49 PM, Rick Mann wrote:
> Okay, so it sounds like I'll have to go back to pre-3.0 configuration for the
> foreseeable future.
> Hate to say it, because you guys do such great work, but it seems that as
> currently implemented, resin can't be used as a servlet 3.0 container.
> Let me ask this: the only URL I really need to run through Spring's
> DispatcherServet is /service/**. I had been running everything through it so
> my Spring controllers could handle everything, but I don't need that right
> now. Should I be able to register it for "/service" and get what I need?
Yep. You can use "/*" as well. It's only exact matches that are
rejected, and "/" exactly matches the default file servlet.
> Also, is resin creating that ContextLoaderListener on its own?
I'm not sure what you mean.
> Sent from my iPhone
> On Dec 13, 2012, at 12:36, Scott Ferguson <f...@caucho.com> wrote:
>> On 12/13/12 12:16 PM, Rick Mann wrote:
>>> On Dec 13, 2012, at 11:32 , Scott Ferguson <f...@caucho.com> wrote:
>>>> That behavior is part of the spec.
>>>> If the mapping already exists, the addMapping does nothing. It's not an
>>> Wait, really? In my web.xml, I used to have:
>>> And you're saying that the new hotness doesn't allow me to do that?
>> Yep, the new spec feature works backwards from Resin's configuration
>> behavior. (No, I don't know why they chose that definition.)
>>> Or is there a way to avoid the resin mapping?
>> That's what the bug report would be. We'd have to add some kind of
>> configuration or marker to let Resin's configuration be a lower priority.
>> -- Scott
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list