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.
>
>
Perhaps I am missing something here, but you shouldn't have to do
this. did you do this because you had problems with
debugging ? If so, you should bring this issue up with the Netbeans team
and find out what they have to say.
>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.
>
>
If I understand your concern correctly, it is true for any component
thats part of the shared chain and is part of javaee.jar. Glassfish
does allow you to override the jars in shared class loader and if you
override it right way, they should be picked up and I've verified that.
Thanks
-Jayashri
>Thanks,
>
>Ed
>
>