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

[Ken Paulsen]

+1

I think this area needs more spec work to be done right.  The SPI Pete 
mentioned is probably a better approach to supporting libraries.  
Putting more effort into supporting the odd cases in an effort to 
circumvent the webapp classloader b/c it can't be used (b/c we have a 
funny automatic library version upgrade "feature"), is not worth the time.

While thinking about an SPI in the future, I would like us to ensure 
that the regular webapp classloader may be used.  OSGi bundles, shared 
lib jars, and other similar cases should work with this code (currently 
it does not).

Thanks!

Ken

Ryan Lubke wrote:
> 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.