I need to import an external JAR file into my quarkus project, that contains a persistence.xml. Is there a way to ignore the embedded persistence.xml?
It should be, according to the comment in https://github.com/quarkusio/quarkus/blob/2d2124653d5115f85fc072ef6b5a55756039c940/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/PersistenceUnitsHolder.java#L36:
* The scanner may be null to use the default scanner, or a custom scanner can be
* used to stop Hibernate scanning. It is expected that the scanner will be
* provided by Quarkus via its hold of Jandex info.
I haven't found a way to provide a custom scanner, though.
I don't think you'll find a way to do that right now and my guess is that Quarkus will fail to start if you use both application.properties and this persistence.xml in a jar. Plus having the persistence.xml to work in Quarkus is a bit tricky as you have to set a few advanced settings manually to be on par with Quarkus behavior.
Could you open an issue in our tracker (https://github.com/quarkusio/quarkus/issues)? Thanks!
Related
I would like to generate a list of my application configuration values, with their description and default values. Just like quarkus has for the framework itself on https://quarkus.io/guides/all-config, but for my application properties.
Would it be possible to achieve this using the SmallRye Config or Quarkus APIs?
Quarkus does not have an official support for this. This has been discussed, and there is even an issue to add it properly at some point: https://github.com/quarkusio/quarkus/issues/19020
At your own risk, you can add the quarkus-extension-processor to your project and annotate the mappings with #ConfigRoot(phase = ConfigPhase.RUN_TIME)(it still requires the #ConfigMapping), which will generate the adoc files used by Quarkus for its own configuration.
I learning Spring boot and found that in some examples use the same properties with the prefix spring.jpa.properties while other do it without prefix.
For instance:
The article explains second level cahche https://www.baeldung.com/hibernate-second-level-cache and autor shows example of needed properties ( example on autor's gitHub):
hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
But it did not work for me, and I spent few hours loking for the reason, but then i noticed, someone use prefix spring.jpa.properties. to get it working (Exact moment from video lesson):
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
Which perfectly worked for me.
So my questions are:
why are they working in different way?
how to understand which properties in which cases requires this prefix?
is it probably something related to my project settings OR Spring Boot version?
any other suggestions are appreciated :)
Thank you in advance!
There are a couple of things in play here. First the tutorial you use is using plain Spring not Spring Boot. Which means a manually configured EntityManagerFactory on which you directly can set the provider specific properties. Like hibernate.cache.use_second_level_cache.
As you decided to use Spring Boot you don't have a manually configured EntityManagerFactory (although you could!). Which means you are using an autoconfigured EntityManagerFactory. Properties for this reside in the spring.jpa namespace for properties.
As it isn't feasible to specify properties for each and every extension for Hibernate (or other JPA providers) only some commonly used ones are exposed like spring.jpa.generate-ddl and a few provider specific ones in the spring.jpa.hibernate namespace. However to set all the other properties in an autoconfigured way there needed to be something else. Hence the spring.jpa.properties prefix. Anything specified in there will be passed on as is (without the said prefix ofcourse) to the EntityManagerFactory for configuration.
I'm planning to run our own Spring Initializr instance. Is there a way to have a set of application properties get written (to application.yml) when a certain option is chosen, ideally in a separate section for each of a set of predefined profiles? I've looked into customising the project-generation process in Initializr and at creating a custom starter. I've come across auto-configuration for starters, but that seems to be about what configuration to default to when this has not been provided by properties, whereas I am after generating the properties. I've also come across an example of a custom Spring Initializr instance generating files, but I need it to modify application.yml without clobbering any other modifications that may have been made to it.
Spring Initializr (the library behind start.spring.io) does not have yaml support and does not allow you to write such file automatically when the project is generated.
It's easy enough for you to add that feature though. The way it works is through a model that contributors would tune + a writer that transform the model into the target output. An analogy of this would be MavenBuild and MavenBuildWriter that generates Maven's pom.xml.
Auto-configuration is indeed completely unrelated to code/configuration generation so no need to look there.
I am looking at externalizing certain configuration parameters for ehcache in our Grails application and I am running into something not working that the documentation claims ought to.
Likely there is something I am missing.
I am using the grails ehcache plugin version 1.0.1 with Grails 2.4.0 and grails cache plugin 1.1.7. I am using hibernate plugin 3.6.10.16.
Here's what I have in my CacheConfig.groovy configuration...
...
cacheManagerPeerProviderFactory {
peerDiscovery 'automatic'
factoryType 'rmi'
multicastGroupAddress '${ehcacheMulticastGroupAddress}'
multicastGroupPort '${ehcacheMulticastGroupPort}'
timeToLive 'site'
}
I've turned on debug-level logging so I can see what XML it generates. Here's the relevant snippet:
<cacheManagerPeerProviderFactory class='net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory'
properties="peerDiscovery=automatic,multicastGroupAddress=${ehcacheMulticastGroupAddress},multicastGroupPort=${ehcacheMulticastGroupPort},timeToLive=32"
propertySeparator=','
/>
The grails ehcache plugin documentation has the following note, which I was hoping to "prove out"...
(note that ${ehcacheMulticastGroupAddress} and ${ehcacheMulticastGroupPort} are an Ehcache feature that lets you use system property names as variables to be resolved at runtime)
Great. Except that it doesn't work when I start the application. It fails to create CacheManagerPeerProvider due to the following
...
Caused by UnknownHostException: ${ehcacheMulticastGroupAddress}
->> 901 | lookupAllHostAddr in java.net.InetAddress$1
...
I have a myApplication-config.groovy file living in an accessible area that I point to when assigning a value to grails.config.locations in Config.groovy. But I am not sure it is making any effort to really interpolate that value at all.
I tried double quotes but they were a bad idea as well -- at the time of interpreting CacheConfig.groovy it doesn't see the configuration I put into myApplication-config.groovy. I do know it reads that file in successfully at some point because I successfully use it to drive some Quartz job logic, so the placement of that config file is probably not the issue.
The answer is that I need to set SYSTEM PROPERTIES for ehcache to find. Using Grails configuration files such as myApplication-config.groovy is completely incorrect.
The CacheConfig.groovy file is correct, as is the XML it generates. So the question becomes, how do the properties it looks for get set correctly in the first place?
I am deploying to Tomcat. For Tomcat, setting system properties makes the most sense in a setenv.bat file (or setenv.sh on *nix).
I created setenv.bat, put the following into it
set CATALINA_OPTS=%CATALINA_OPTS% -DehcacheMulticastGroupAddress=230.0.0.1 -DehcacheMulticastGroupPort=4446 -DehcachePeerListenerPort=40001
...And it worked. Ehcache was able to find the system properties and start everything appropriately.
tl;dr: system properties != grails application config
I have a Maven 3 project that uses Hibernate 3. In the Hibernate properties file, there is an entry for hibernate.connection.provider_class with the class corresponding to the C3P0 connection provider (org.hibernate.connection.C3P0ConnectionProvider). Obviously, this class is only used at runtime, so I don't need to add the corresponding dependency in my POM with the compile scope. Now, I want to give the possibility to use any connection pooling framework desired, so I also don't add a runtime dependency to the POM.
What is the best practice?
I thought about adding an entry to the classpath corresponding to the runtime dependency (in this case, hibernate-c3p0) when the application is run (for example, using the command line). But, I don't know if it's possible.
This is almost (maybe exactly) the same problem as with SLF4J. I don't know if Hibernate also uses the facade pattern for connection pooling.
Thanks
Since your code doesn't depend on the connection pooling (neither the main code nor the tests need it), there is no point to mention the dependency anywhere.
If anyone should mention it, then that would be Hibernate because Hibernate offers this feature in its config.
But you can add it to your POM with optional: true to indicate:
I support this feature
If you use it, then I recommend this framework and this version
That will make life slightly more simple for consumers of your project.
But overall, you should not mention features provided/needed by other projects unless they have some impact on your code (like when you offer a more simple way to configure connection pooling for Hibernate).
[EDIT] Your main concern is probably how to configure the project for QA. The technical term for this new movement is "DevOps" - instead of producing a dump WAR which the customer (QA) has to configure painstakingly, configuration is part of the development process just like everything else. What you pass on is a completely configured, ready-to-run setup.
To implement this, create another Maven module called "project-qa" which depends on your project and everything else you need to turn the dead code into a running application (so it will depend on DBCP plus it will contain all the necessary config files).
Maven supports overlayed WARs which will allow you to implement this painlessly.
You can mark your dependency as optional. In this case it will not be packaged into archives. In this case you have to ensure that your container provides required library.
You could use a different profile for each connection provider. In each profile you put the runtime dependency that correspond to the connection provider you want to use and change the hibernate.connection.provider_class property accordingly.
For more details about how to configure dependencies in profiles, see Different dependencies for different build profiles in maven.
To see how to change the value of the hibernate.connection.provider_class property see How can I change a .properties file in maven depending on my profile?