cloudstateio/cloudstate#227
Can we resolve this problem by using JSR330?
In this PR many times used reflections and it can be a problem for integration Cloudstate Java Support and GraalVM Native Images in the future :disappointed: With JSR330 we can try to use a compile-time DI and to avoid this problem.
Can we resolve this problem by using JSR330?
In this PR many times used reflections and it can be a problem for integration Cloudstate Java Support and GraalVM Native Images in the future :disappointed: With JSR330 we can try to use a compile-time DI and to avoid this problem.
Hi @ihostage, thanks for commenting.
I haven't tested it with the jsr330 annotations but I believe you can inject any bean available in the Spring injection container into a cloudstate entity with @Inject for example.
With regard to Graalvm, I must do some work on this later in the week. The intention now was to prove the concept, now we can make improvements and adjustments. Glad to receive contributions
I haven't tested it with the jsr330 annotations but I believe you can inject any bean available in the Spring injection container into a cloudstate entity with @Inject for example.
With regard to Graalvm, I must do some work on this later in the week. The intention now was to prove the concept, now we can make improvements and adjustments. Glad to receive contributions
@sleipnir :wink: I just think, that if we want to support DI, we should use a standard instead of custom factories. And the customer can choose any DI library (Guice/Dagger 2.0/etc) that it loving. :smiley:
And I think that language support libraries should be very small, simple and compatible with GraalVM Native Image. Because it does not look like serverless function when it starts some seconds (loading classes, runtime DI, JIT, ...) and uses 500Mb+ of memory :joy:
And I think that language support libraries should be very small, simple and compatible with GraalVM Native Image. Because it does not look like serverless function when it starts some seconds (loading classes, runtime DI, JIT, ...) and uses 500Mb+ of memory :joy:
But maybe the community and maintainers have another vision. It will be very cool if @viktorklang writes his thoughts about that
I agree. However, they are two different things, one thing is to offer time support for a specific runtime / framework like Springboot and another is to offer more general support for DI. Both are desirable and we will get there, in the discussion of the issue we have already made these comments and probably in the future there will be an extension module for any desired injection container. If you look at the implementation you will see that it makes use of Spring's injection mechanisms that can be used with jsr330 or not. Reflection is used only as a support mechanism for the discovery of certain characteristics of Cloudstate entities and is also used by Cloudstate itself, however it can be performed via GraalVM. Graalvm support is desired but not always possible to achieve in a simple way depending on the client's own code libraries outside the support libraries. Of course, our intention is to facilitate this support. As I said we will arrive I have no doubt that we will get there. If you look at the PR code you will see that nothing prevents you from implementing it with other frameworks like Quarkus or Guice. The Spring implementation uses the Spring tools since the Cloudstate java-support entity discovery mechanism does not take this environment into account. But the intention of the PR was to provide a mechanism that allows anyone to create the best tool for their use case.
I strongly believe in continuous evolution and to implement the use cases that appear and make sense to the community, GraalVM support is undoubtedly one of those desirable use cases and we will get there. That said, I am sure it is possible to run the example with GraalVM support and soon we will have that in future commits.
I strongly believe in continuous evolution and to implement the use cases that appear and make sense to the community, GraalVM support is undoubtedly one of those desirable use cases and we will get there. That said, I am sure it is possible to run the example with GraalVM support and soon we will have that in future commits.
@ihostage AKKA itself suffers from these problems and therefore created the akka-extensios module to facilitate the bind of ActorSystem with DI environments. The same happens here, I created a mechanism that allows anyone to be able to run Cloudstate in the environment that suits them with the tools and standards that suit them. For example you could use jsr330 and create a "Produces" class that adds the Cloudstate server and register your beans with the jsr330 discovery engine using the extension classes that were created in that PR. It would not be difficult to create such an example and I can take the trouble to do so in the future if desired.
Thanks @viktorklang I would love a little help \0/
@viktorklang If you like and have some time :) I have a question on protocol specifics pending here:
https://github.com/cloudstateio/cloudstate/pull/119#discussion_r403012794
https://github.com/cloudstateio/cloudstate/pull/119#discussion_r403012794
Hello guys, after some improvements I managed to gain some time and memory reduced in the implementation of Cloudstate Springboot support. Not bad for a Java + Spring application
;)
;)
For comparison, the first versions took almost 4 seconds and consumed > 600mb
very cool @marcellanz ... thanks
go for serverless 2.0
I mean in house one.
It built with k8s and grpc too