2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 18/02/2014 10:50, Romain Manni-Bucau wrote: >> 2014-02-18 11:44 GMT+01:00 Mark Thomas <ma...@apache.org>: >>> On 18/02/2014 10:14, Romain Manni-Bucau wrote: > > <snip/> > >>>> It was working fine before and it was convenient. By default you don't >>>> add jars in tomcat system loader so the behavior of tomcat was fine + >>>> in unit test of embedded mode it was convenient so I dont get the >>>> point changing it. >>> >>> The point of changing it was: >>> >>> - fixing the reported bug >>> - have the actual behaviour align with the documented / spec required >>> behaviour >>> >>> There was nothing in either the spec or the docs that required Tomcat to >>> prevent web applications overridding a class on the system class path. >>> >> >> Nothing forces it to be done so IMO it should be configurable and not >> the default behavior for backward compatibility (spoken of v7). > > That is a fair point about making it configurable for Tomcat 7. It is > likely that making it configurable for 8 would be useful to. > >>> Switching to using the endorsed dir looks like the simplest solution to >>> me and it should work for Tomcat versions before and after the BZ 55943 >>> change. >>> >>> Other possible solutions include: >>> - removing the final from j2seClassLoader / always accessing it via an >>> over-ridable getter() (I'd recommend checking that that will work for >>> you as the other related changes may also cause problems) >> >> >> I set by reflection j2seClassLoader it solved this particular issue. > > We can certainly make that easier. Making it non-final, using an > over-ridable protected getter(), adding protected getter and setter etc. > Does TomEE have a preference? >
not really while we can change it, we were used to protected field but protected getter would be nice too. >>> - making it possible to add to the packages used to define the filter >>> for container classes >> >> Not enough since user classes should get this bahavior too in embedded >> case (I don't say that's good but common, convenient and done so we >> need to leave with it). > > That I disagree with. Just because Tomcat is being used in embedded > mode, that is no reason to ignore the direction of the Servlet spec on > the topic of class loading priority. > Not really, if you put a class in jvm loader you don't want it to be overrided by a webapp in general (saw it often for technical libs) even if the lib is in the webapps so since servlet spec is not clear on it it should just be a config. The other point I'm not sure (sorry didnt get time to test) is doesn't it break javaagent which add libs to system classloader and not bootstrap for classloader constraints? > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
