Re: [jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature
On 9/9/09 8:35 AM, Ed Burns wrote:
>>>>> On Wed, 09 Sep 2009 11:57:44 +0100, Pete
Muir<pmuir(a)redhat.com> said:
>>>>>
PM> On 8 Sep 2009, at 21:48, Dan Allen wrote:
>> On Sun, Sep 6, 2009 at 9:46 AM, Pete Muir<pmuir(a)redhat.com> wrote:
>> Why don't we specify that only bundled resources are required to be
>> supported, and that a container may portably support installed
>> libraries?
>>
>> That's precisely what I had in mind.
>>
>>
>> Mojarra and other implementations would be able to provide this
>> support via a vendor specific SPI.
>>
>> Should the SPI be part of the spec or something the implementation
>> provides? Perhaps Mojarra can introduce an SPI that we later promote
>> in an MR?
>>
PM> This would be the approach I would take.
I'm not fond of reducing the flexibility that we already have. Ryan has
implemented something that he's satisfied with. Ryan, can you please
share the details so we can further discuss the options for ammending
the specification?
Ed
Here's where I am currently with this issue.
Implementation wise, I changed the logic to support classpath resources
only within the context
of the web application. This requires the use of
ServletContext.getResourcePaths() in order to
obtain all of the included JAR files as well as any potential content under
/WEB-INF/classes/META-INF/resources and storing the paths that were
discovered in some structure
for lookup purposes.
This worked fine in GFv2/3 and JBoss 5.1.0. However, we've run into an
issue where this falls apart
in embedded situations (mvn jetty:run as an example). We can't be
guaranteed that /WEB-INF/lib
or /WEB-INF/classes will exist in embedded scenarios. Sure, there are
workarounds, but it's going
to surprise developers in this situation and I don't think that's what
we want.
I've tried some other potential fixes and they tended to work in some
cases and then failed in others.
At this point, I'm thinking we should punt on trying to support
versioned classpath resources and address
the issue proper in 2.1.