User development, A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/527267#527267 Author : Kabir Khan Profile : http://community.jboss.org/people/[email protected] Message: -------------------------------------------------------------- > mailto:[email protected] wrote: > > While working with Kabir to fix the AOP tests for AS, he pointed out that > > there could be an issue related to my fix. It seemed obviously right to me > > to look in the classes cache (a cache declared in ScopedClassPool that > > contains all classes created by the current class pool) before doing > > anything else. To me, if we have a hit in the cache, it means that the > > current pool is the one that is supposed to load the class, and that there > > is no need to look further by calling super.get method. But Kabir raised > > the following possibility. What if the class pool scenario (a reflection of > > the class loader/domain scenario) changes after the current class pool > > loaded the class, in a way that this class pool is no longer the one > > responsible for loading that class? In that case, looking for the class in > > the classes cache would be a serious mistake. Is this scenario possible? > Does anybody know the answer to this question? I can't commit it without > knowing the answer. Unless Adrian or Ales can give you an answer, you can see how this works in the classloaders themselves and make the pools behave the same -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527267#527267
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
