Hi! Thank you for the information! The post is great and super useful!
Yes, I can give you some more details about my case.
- WebSphere ND 188.8.131.52 (I know it is not in list of supported tech)
- Oracle 12c
- the app is a bpmn platform - lets call it just platform
- all the software and work activity is in company's closed network segment without internet connection
I've chosen elastic apm attach artifact for 2 reasons:
- would like to avoid app server java agent configuration
- facing some issues with OSGi and class loading (NoClassDefFoundErrors), when java agent is configured in app server.
Fortunately, everything works great if agent attaches to jvm after server startup during kinda platform startup task. So, at the moment agent attaches - app server is started, platform is started, a lot of classes apm agent instruments are loaded (for example, jdbc and stuff).
At this point everything is cool!
So, then I have some thoughts about custom build of agent with my plugin.
I see some disadvantages of having such a fork. I think, the main is codebase sync.
With the official release I can rely on your official release cycle, bugfixes, tests, benchmarks, improvements, and I hope, I could ask elastic-java-apm-agent-team for support here ) and you could reproduce some case using the official build. I'm happy with all of that )
On the other hand, I have my plugin with it's release cycle, tests, coverage, benchmarks and other stuff.
That is why I think it would be great feature to have an official build of agent and custom plugin alongside.
I'm not deep into classloading stuff, maybe I offer wrong things, but I have 2 probable options:
- user could specify which classloader should attacher use to load agent jar
- user could specify which classloader should ServiceLoader use to find ElasticApmInstrumentation implementations
The default behavior should stay as it is now.