Open vlad-poskatcheev-tealium opened 7 years ago
Yes, that's a good point. Comsat classes should be instrumented AOT.
I agree but please consider that several Comsat modules also require instrumenting some methods in the 3rd-party libraries they integrate; this means that, if you can't use the agent at all, oftentimes having just Comsat AOT-instrumented is not going to help you anyway (unless of course you create and use your own AOT-instrumented builds of those 3rd-party libs).
On Fri, Dec 23, 2016 at 12:17 AM, pron notifications@github.com wrote:
Yes, that's a good point. Comsat classes should be instrumented AOT.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/puniverse/comsat/issues/90#issuecomment-268902982, or mute the thread https://github.com/notifications/unsubscribe-auth/AF1IECdBE2pIhqvcxNwObpJ252mj2Mjeks5rKvbvgaJpZM4LSQNs .
-- Fabio Tudone paralleluniverse.co @puniverseco https://twitter.com/puniverseco on Twitter
I'm running into an issue where it does not seem to be possible to instrument quasar-comsat classes ahead-of-time via a Maven Ant Task (as described in docs.paralleluniverse.co/quasar). Quasar Fibers log an instrumentation error and point to classes in quasar-comsat package.
General setup of my project:
It works when using a Java Agent, but fails with AOT Ant Task because quasar-comsat classes are in a jar and not in the class build directory. Unfortunately my project is constrained and not able to use Java Agents.
Is there a way to make it work with AOT? One alternative (although a bit hacky) solution came to mind of including quasar-comsat classes directly within the code base (I only need a handful) and hence bypassing the quasar-comsat dependency all together?