Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Akka Graal native tooling #8

Open
jroper opened this issue Aug 29, 2019 · 3 comments
Open

Akka Graal native tooling #8

jroper opened this issue Aug 29, 2019 · 3 comments

Comments

@jroper
Copy link

jroper commented Aug 29, 2019

I'm creating this issue just to start a discussion - not because I think this project should provide this feature, but I thought this is probably the right place to start the discussion since this is where everyone that has done work on Akka and Graal native has come together.

While Graal does provide some tooling to help generate config, it misses a lot of things. For example, the self/context fields in an actor are reflected on not just when watching, but also when the actor is restarted. That only occurs when the actor fails, and it's highly unlikely that in the environment where you run your Graal tooling that you're going to trigger all the failure possibilities, more likely, it'll happen some day in production, and your system will have big problems because an actor couldn't be restarted. Likewise, a lot of things relating to clustering may not be triggered in the environment where you run your Graal tooling, eg, a lot of reflection config is needed to run kubernetes based cluster bootstrap, and that can only run inside a kubernetes cluster.

So, we need something better. The idea is that we could automate much of the generation of reflection config, both for Akka itself, as well as for end user libraries. Such a tool would work with one "artifact" at a time, for Akka libraries, an artifact would be a jar, for an end user library, an artifact would be all the class files and resources on disk that are about to be packaged into a jar. It would do the following:

  • Inspect all the classes, looking for anything that implements akka.actor.Actor, and generate config to allow writable access to self and context.
  • Find all uses of Props.apply that use reflection, and generate the necessary config for that.
  • Load all HOCON configuration files, look for known Akka configuration that passes an FQCN, and determine and generate the necessary reflection config to construct that class - this would obviously be done for classes in the jar, but may also need to be done for classes in other jars, since a class may be declared in another shared jar, but not used, and then it gets instantiated in this jar. We could inspect existing reflection config on the classpath to determine if it's needed.
  • Find all usages of spray reflection based formats (eg, used by cluster bootstrap for json messages sent through akka-management-http) and generate the necessary config.
  • Find all protobuf/ScalaPB messages and generate a reflection config compatible with Akkas protobuf serializer.

The above is all the things that I can think of off the top of my head, there's likely more.

@jroper
Copy link
Author

jroper commented Aug 29, 2019

Given the above tooling, we could run it against all the Akka artifacts to assist in producing the artifacts that this project currently provides. It could also some day be incorporated into Akka itself, so that Akka provides it's own graal reflection config.

@jroper
Copy link
Author

jroper commented Aug 29, 2019

I just realised I probably should have created this issue here:

https://github.com/vmencik/akka-graal-config

@shafqatevo
Copy link

Hi @jroper, has there been any progress on this? What do you recommend to do in order to compile latest Akka artifacts with Graal?

Is following the configs and method of these two repos here still the best approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants