JSP files in the war
Cantor, Scott
cantor.2 at osu.edu
Sat May 17 12:06:14 EDT 2014
On 5/17/14, 12:36 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>As discussed yesterday, I did have to add a statement to the mvc-beans
>file
>
> <mvc:resources mapping="/resources/**" location="/resources/" />
>
>Which appears to be what makes things like logos and css files available
>from within the war file. IANA spring expert (but I'm learning) so if
>this
>is wrong, please let me know.
That seems very weird to me, we need to look into that more. I'll see what
the docs say on that element.
>That change made me realize that I do not know how we intend dealing with
>css for our velocity resolved pages. I would guess that our default
>velocity pages will reference the embedded css file and more complex cases
>can be left as an exercise for the deployer.
Pretty much. As I said on the call, my solution has been to use the root
webapp in Jetty to install files that I can edit because they're just
static, and the webapp reloads them when they change in the filesystem.
That keeps them out of the idp.war. But that's all manual on my part, not
anything we can automate.
>- Sometime we would end up issuing a SAML error statement
It is eventually going to be the case that this will be true. The way I
built the error handling, it uses some rules to determine what events
should be handled locally and what events should be handled with SAML if
they can be. Once the events themselves are cleaned up and appropriately
descriptive, that lets the deployer in advanced cases manipulate the rules
for when to keep errors from the SP, which was impossible to control in V2.
>- I have seen the expected error using the velocity template and I may
>have
>also seen it using the old jsp file. But I never have with the new one
>which makes me suspect that I have broken something there.
I'll take a look, but it does sound like something broke.
-- Scott
More information about the dev
mailing list