>>>>> On Wed, 28 Sep 2005 11:08:07 -0700, Jayashri Visvanathan <Jayashri.Visvanathan_at_Sun.COM> said:
JV> Ed Burns wrote:
>> Hello Jayashri,
>>
>> I think we need to notify someone on the glassfish team that jsf-api.jar
>> still needs the special treatment it currently gets with respect to
>> classloading.
>>
>> This is very important because as we are developing the JSF impl itself,
>> we need to be able to have jsf-api.jar and jsf-impl.jar instead of
>> having it be bundled into javaee.jar during development. I've added
>> some targets to our top-level build.xml to strip the jsf-api classes out
>> of javaee.jar and then copy the jsf-api.jar and jsf-impl.jar from one's
>> tree into glassfish.
>>
>>
JV> Perhaps I am missing something here, but you shouldn't have to do
JV> this. did you do this because you had problems with
JV> debugging ? If so, you should bring this issue up with the Netbeans team
JV> and find out what they have to say.
You do have to do it when doing iterative development of features in
jsf-api.jar. Who wants to spend the time updating javaee.jar each time?
>> We need to make sure this continues to work. In other words,
>> glassfish can't take for granted that the jsf-api classes will always
>> be in javaee.jar. I fear a regression when someone mucks with the
>> classloader list to take jsf-api.jar away from being considered
>> specially. I want to prevent this regression from happening.
JV> If I understand your concern correctly, it is true for any component
JV> thats part of the shared chain and is part of javaee.jar. Glassfish
JV> does allow you to override the jars in shared class loader and if you
JV> override it right way, they should be picked up and I've verified that.
What's the right way to override it, then?
Ed
--
| ed.burns_at_sun.com | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: ed.burns_at_sun.com