Konstantin Kolinko wrote:
>2013/9/13 Mark Thomas :
>> I started to look at Bug 52489 [1] which is requesting code signing
>> support for WARs. I decided to work with an unpacked version of the
>> examples application. During testing, I noticed that WEB-INF/classes
>and
>> WEB-INF/lib were always b
Hi Mark,
2013/9/13 Mark Thomas
>
> a) Unpack JAR resources to the work dir and return a URL to the unpacked
> location
-1
>
> In trying to decide between b) and c) I came to the conclusion that it
> would be better to keep the war:// url scheme and generic tomcat:// url
> schemes separated even
2013/9/13 Mark Thomas :
> I started to look at Bug 52489 [1] which is requesting code signing
> support for WARs. I decided to work with an unpacked version of the
> examples application. During testing, I noticed that WEB-INF/classes and
> WEB-INF/lib were always being unpacked to the work directo
On 13/09/2013 17:23, Christopher Schultz wrote:
> Mark,
>
> On 9/13/13 9:16 AM, Mark Thomas wrote:
>> The Javadoc for ServletContext#getResource() [3] is clear. The
>> container must provide a URL for every resource and that URL must
>> be usable.
>
> Usable by whom? (Sounds like a dumb question,
Mark,
On 9/13/13 9:16 AM, Mark Thomas wrote:
> The Javadoc for ServletContext#getResource() [3] is clear. The container
> must provide a URL for every resource and that URL must be usable.
Usable by whom? (Sounds like a dumb question, but please see below)
> There
> is an immediate issue with re
I started to look at Bug 52489 [1] which is requesting code signing
support for WARs. I decided to work with an unpacked version of the
examples application. During testing, I noticed that WEB-INF/classes and
WEB-INF/lib were always being unpacked to the work directory.
As well as looking to be un
