I am working on creating an internal library/starter for my team that will add support for creating native images, providing all of the hints that our currently unsupported dependencies will need. I really like providing the metadata via code (using RuntimeHintsRegistrar), but there are also certain classes that need to be initialized at build time for whatever reason.
Right now I'm passing the --initialize-at-build-time and the classes to the Spring Boot Maven Plugin via the BP_NATIVE_IMAGE_BUILD_ARGUMENTS, but ideally I'd like to avoid each consuming app having to include this in their own POM's plugin configuration.
I also understand that I can go more low-level and provide the argument inside of the META-INF/native-image directory in a native-image.properties file, but I'm not sure whether that will play nice with the Spring-provided RuntimeHintsRegistrar effectively creating that underneath the covers.
What is the best way to tell native-image the classes that should be initialized at build time without each consuming app having to pass it in their own POM? Also, if I use the GraalVM tracing agent to generate hints, will those hints play nicely with the ones that RuntimeHintsRegistrar generates?
Thanks in advance!
Related
We have a Quarkus project in production. It runs fine but testing is a nightmare because of high complexity of the data structure and business logic.
We would like to add property-based testing to our project. I have so far failed to find a Java PBT testing library that supports Quarkus though.
I have tried *jqwik *and junit-quickcheck. They both run technically but they cannot access our project code, i.e. access the injected beans (they remain NULL during the test run), due to different test engines.
See also: Inject returns NULL when activating jqwik in Quarkus test
I have tried to write an own quarkus-extension for jqwik. I got along with the jqwik part but failed for the lack of understanding the Quarkus Test Engine.
My question:
Is there working support property-based testing support in Quarkus?
If not, can anyone provide an in-depth guide about the Quarkus test engine? Writing an own extension will take a while but (given the referring PBT library owner approves) I could probably make the resulting extension public.
You may want to look at quicktheories: https://github.com/quicktheories/QuickTheories.
What differentiates it from both jqwik and junit-quickcheck is its independence from any test framework or test engine. The obvious advantage is that you can just add it to whatever you're already using for example-based testing your Quarkus app. The disadvantage is that you get no additional lifecycle support like instantiating objects provided by DI for each try of a property. Moreover, quicktheories seems to be orphaned. So it could be a short-term solution to get started with PBT within Quarkus, but you probably also want to continue the development of integrated support for the Quarkus test engine.
It's not clear for me if I'd like to add some jars to my projects should I make an extension for each one ?
Just read https://itnext.io/should-you-switch-to-quarkus-4b89eedfe5fe and it says gson is slower cause there's no extension and I guess maybe it was not compiled to native as it uses reflection
You can use any dependencies inside your application as with other frameworks, an extension allow a technology to be integrated into Quarkus (injection via CDI bean, configuration via application.properties, native image support, ...) but it's not mandatory.
Or course, if you use a dependency not integrated as an extension, you cannot be sure that it will works in native, so be careful if you deploy your application as a native image some steps would need to be done.
In the article you cited, the issue is on native executables, and it shows that JSON-B outperforme GSON in this situation on this particular test, not that it uses a custom serialization (not the serialization provided by Quarkus via its extensions).
You can also note that the exemple didn't reuse the Gson object so it may be the cause of the slowness, by creating a Gson object on each request it will allocate a lot and the GC included inside SubstraatVM is not the same as the one in JVM mode (as with other optimizaton).
My point of view is that an extension will not impact the runtime performance of a dependency.
I am creating a library using spring-boot (v2.1.6.RELEASE) as a starter project that will facilitate as base extension jar responsible for configuring and starting up some of the components based on client project properties file.
The issue I am facing is that if the client project's SpringBoot Application class contains the same package path as library everything works like charm! but when client project contains different package path and includes ComponentScan, it is not able to load or start components from the library.
Did anyone encounter this issue? how to make client application to auto-configure some of the components from library jar?
Note: I am following the library creation example from here: https://www.baeldung.com/spring-boot-custom-starter
There are many things that can go wrong here, without seeing relevant parts of actual code its hard to tell something concrete. Out of my head, here are a couple of points for consideration that can hopefully lead to the solution:
Since we use starters in our applications (and sometimes people use explicit component scanning in there spring applications) and this obviously works, probably the issue is with the starter module itself. Don't think that the fact that the component scan is used alone prevents the starter from being loaded ;)
Make sure the starter is a: regular library and not packaged as a spring boot application (read you don't use spring boot plugin) and have <packaging>jar</packaging> in your pom.xml or whatever you use to build.
Make sure you have: src/main/resources/META-INF/spring.factories file
(case sensitive and everything)
Make sure that this spring.factories file indeed contains a valid reference on your configuration (java class annotated with #Configuration). If you use component scanning in the same package, it will find and load this configuration even without spring factories, in this case, its just kind of another portion of your code just packaged as a separate jar. So this looks especially "suspicious" to me.
Make sure that #Configuration doesn't have #Conditional-something - maybe this condition is not obeyed and the configuration doesn't start. For debugging purposes maybe you even should remove these #Conditional annotations just to ensure that the Configuration starts. You can also provide some logging inside the #Configuration class, like: "loading my cool library".
Grails has amazing validation; is it possible to use it independent of the Grails framework?
We have a Java/Groovy Camel-based web application we can't convert to a Grails application. I'd love to use the Grails-style validation with the declarative constraints but have been unable to successfully configure the application to work with Grails libraries without converting the whole thing.
The validation provided by Grails is just a wrapper around Spring's bean validation framework. Since Grails is open source you can take a look at how it's done and adapt it to your own needs. The best place to start looking is the GrailsDomainClassValidator and DomainClassGrailsPlugin to get an idea of how it's done. Another point of interest would be the #Validateable AST annotation.
As far as I know, and from what I can see in the source, there isn't a stand alone way to do this outside of a Grails project without writing your own adaptation/implementation.
You can use a external validation without problem. It is possible, for example, using a external "jar" (that do a validation) file on the "lib" folder of your Grails project. Through this way, you can use the API of this jar file. It's a simple way that you can use.
I have a large spring project, using xml configuration. I'm looking for a quick way to verify changes to the xml configuration.
I can load the whole project locally - the problem is this takes more than 5 minutes, loads a huge amount of data.
My XML editor catches XML formatting errors.
I'm looking for something intermediate - to catch obvious problems like references to beans that aren't defined, or calling constructors with the wrong arguments. Is there a quick way to do this, without having to actually invoke all the constructors and bring up the whole environment?
I'm building with Maven and editing with Eclipse, although my question isn't specific to either.
Since you already use Eclipse, you could try Spring Tool Suite (comes either standalone or as an add-on). It's essentially Eclipse with extra Spring-specific features, like Beans Validator. I'm not sure how thorough the validation is, but it should catch most configuration problems.
It's maintained by SpringSource so its integration with Spring "just works" and it's guaranteed not be more or less in sync with Spring Framework's release cycle.
Beanoh :
http://beanoh.org/overview.html#Verify
this project does exactly what I'm looking for. Verify obvious problems with spring config, but without the overhead of initializing everything.
You can use a Spring testing support to integration test your Spring configuration. However if the loading of the context is taking 5 mins, then the tests will also take the same amount of time. Spring does cache the context so if you have multiple tests using the same set of Spring contexts, then once cached the tests should be very quick.
I can suggest a few ways to more efficiently test your configuration:
Organize your project in modules, with each module being responsible for its own Spring configuration - this way, each module can be independently developed and tested.
If you have a modular structure, the testing can be more localized by mocking out the dependent modules, again this is for speed.