I don't mean that. The thing is, this class(specific for ThreadPoolExecutor), could be introduced into the classloader by many things, we even don't know it is added.
> Or can we use different classloader when running agent core code? It is already, but think about this, who loads ThreadPoolExecutor? This isn't the SkyWalking classloader's responsibility. Sheng Wu 吴晟 Twitter, wusheng1108 Li BingLong(智能平台) <binglongli217...@sohu-inc.com> 于2021年1月4日周一 下午4:28写道： > The plugin developer should let core develop know what the problem they > are facing because this scene is scant. > And the booting sequence do not to be unexpected random. > > Or can we use different classloader when running agent core code? > > > > 在 2021/1/4 下午4:18，“Li BingLong(智能平台)”<binglongli217...@sohu-inc.com> 写入: > > So is it supported or valuable to add a ThreadPoolExecutor plugin? > I have tried this, some log not important will appear in stdout. > > > > 在 2021/1/4 下午3:15，“Sheng Wu”<wu.sheng.841...@gmail.com> 写入: > > True, we can't instrument the class the agent core is using > already. > This is a logic conflict. If we allow the instrumentation > activated before > the configuration initialization and core service booting, you > have a > chance to face runtime NPE or race condition. > The core developer and plugin developer would expect the booting > sequence > will be unexpected random, and determined by the monitored app > codes. > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > > > > >
