[jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature

[Ryan Lubke]

On 9/9/09 8:35 AM, Ed Burns wrote:
>>>>>> On Wed, 09 Sep 2009 11:57:44 +0100, Pete Muir<pmuir at 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 at 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.