10:35 a.m.
>>>> 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
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
1:18 p.m.
New subject: [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.
1:27 p.m.
New subject: [jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature
+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(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.
5586
days inactive
5588
days old
jsr-314-open-mirror@lists.jboss.org
2 comments
3 participants
participants (3)
-
Ed Burns -
Ken Paulsen -
Ryan Lubke