Importing domain classes from GORM-standalone module into Grails - mongodb

I have 2 pieces of my puzzle:
1) a no-Grails project named core-module with standalone GORM:
dependencies {
compile 'org.grails:grails-datastore-gorm-mongodb:6.0.4.RELEASE'
compile 'org.grails:grails-validation:3.2.3'
}
and domain classes like:
import grails.gorm.annotation.Entity
#Entity
class Module {
String id
String tags
}
the GORM-ing is initialized by
Map config = new Yaml().load this.class.getResource( '/application.yml' ).text
new MongoDatastore( config, Module, UserAccount )
and the domain classes are working as they would in a Grails app.
2) a Grails 3.2.3 app:
dependencies {
// default grails dependencies
compile project( ':core-module' )
compile 'org.grails.plugins:mongodb:6.0.4'
compile 'org.grails.plugins:spring-security-core:3.1.1'
// etc
}
the GORM is initialized so:
def config = config.grails.mongodb
log.info "using $config"
new MongoDatastore( config, Module, UserAccount )
and it prints out this into the log file:
g.app.init.com.mozaiq.Application - using [host:localhost, port:27017, databaseName:theDB, username:theUN, pooled:true, mongoOptions:[connectionsPerHost:100, autoConnectRetry:true, connectTimeout:3000]]
The problem is, that the property grailsApplication.domainClasses is empty, and even though the Module.collection is not-null, the Module.count() return 0 despite the collection being not empty.
Also in my mongo-client I see that upon app start a new database test is created with an empty collection, named by one of my domain classes. If I insert some documents into it, the .count() returns 0 and the CRUD list remains empty.

Grails only scans packages in the application by default for performance reasons. Override limitScanningToApplication() to return false in your Application class and define the packages you wish to scan by overriding packageNames() in your Application class.
Grails will then automatically discover the Mongo GORM classes

Related

Programmatically load openjpa javaagent - runtime optimization

I am writing unit test for testing JPA DAO and I would like to automatically load the javaagant (JPA class enhancer) without having to specify the -javaagent vm parameter.
To achieve this I implemented a #BeforeClass annotated method like this:
String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
String pid = nameOfRunningVM.substring(0, nameOfRunningVM.indexOf('#'));
VirtualMachine vm = VirtualMachine.attach(pid);
vm.loadAgent("openjpa-all-2.4.2.jar");
vm.detach();
emf = Persistence.createEntityManagerFactory("TEST_DB");
But I still get the error telling entity classes were not enhanced when creating the entity manager factory.
org.apache.openjpa.persistence.ArgumentException: This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a javaagent: ")
I can live with the -javaagent parameter but I am curious and would be pleased if anybody could share a solution or idea with us.
I am running my test with JUnit and Java 8

Setting DNS lookup's TimeToLive in Scala Play

I am trying to set the TimeToLive setting for DNS Lookup in my Scala-Play application. I use Play 2.5.9 and Scala 2.11.8 and follow the AWS guide. I tried the following ways:
in application.conf
// Set DNS lookup time-to-live to one minute
networkaddress.cache.ttl=1
networkaddress.cache.negative.ttl=1
in AppModule or EagerSingleton (the code would be similar)
class AppModule() extends AbstractModule {
Security.setProperty("networkaddress.cache.ttl", "1")
Security.setProperty("networkaddress.cache.negative.ttl", "1")
...
}
passing as environment variable:
sbt -Dsun.net.inetaddr.ttl=1 clean run
I have the following piece of test code in the application:
for (i <- 1 to 25) {
System.out.println(java.net.InetAddress.getByName("google.com").getHostAddress())
Thread.sleep(1000)
}
This always prints the same IP address, e.g. 216.58.212.206. To me it looks like none of the approaches specified above have any effect. However, maybe I am testing something else and not actually the value of TTL. Therefore, I have two questions:
what is the correct way to pass a security variable into a Play application?
how to test it?
To change the settings for DNS cache via java.security.Security you have to provide a custom application loader.
package modules
class ApplicationLoader extends GuiceApplicationLoader {
override protected def builder(context: Context): GuiceApplicationBuilder = {
java.security.Security.setProperty("networkaddress.cache.ttl", "1")
super.builder(context)
}
}
When you build this application loader you can enable it in your application.conf
play.application.loader = "modules.ApplicationLoader"
after that you could use your code above and check if the DNS cache is behaving like you set it up. But keep in mind that your system is accessing a DNS server which is caching itself so you wont see change then.
If you want to be sure that you get different addresses for google.com you should use an authority name server like ns1.google.com
If you want to write a test on that you could maybe write a test which requests the address and then waits for the specified amount of time until it resolves again. But with a DNS system out of your control like google.com this could be a problem, if you hit a DNS server with caching.
If you want to write such a check you could do it with
#RunWith(classOf[JUnitRunner])
class DnsTests extends FlatSpec with Matchers {
"DNS Cache ttl" should "refresh after 1 second"
in new WithApplicationLoader(new modules.ApplicationLoader) {
// put your test code here
}
}
As you can see you can put the custom application loader in the context of the application starting behind your test.

Getting server port and contextPath programmatically - springboot

How can i get the server port and contextPath at runtime?
In application.yml, i am setting these values:
server:
port: 9300
contextPath: '/apis'
In the code, i am building a JSONAPI response to include a reference back to the REST API and therefore the need to programmatically get
{
"relationships": {
"company": {
"links": {
"related": "/api/v1/users/1/company"
}
},
"pets": {
"links": {
"related": "/api/v1/users/1/pets"
}
}
}
}
Example,
String related = port? + contextPath? + "/users" + userId + "company";
The following is taken from http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html:
Spring Boot allows you to externalize your configuration so you can
work with the same application code in different environments. You can
use properties files, YAML files, environment variables and
command-line arguments to externalize configuration. Property values
can be injected directly into your beans using the #Value
annotation, accessed via Spring’s Environment abstraction or bound to
structured objects via #ConfigurationProperties.
Spring Boot uses a very particular PropertySource order that is
designed to allow sensible overriding of values. Properties are
considered in the following order:
Devtools global settings properties on your home directory
(~/.spring-boot-devtools.properties when devtools is active).
#TestPropertySource annotations on your tests.
#SpringBootTest#properties annotation attribute on your tests.
Command line arguments.
Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an
environment variable or system property)
ServletConfig init parameters.
ServletContext init parameters.
JNDI attributes from java:comp/env.
Java System properties (System.getProperties()).
OS environment variables.
A RandomValuePropertySource that only has properties in random.*.
Profile-specific application properties outside of your packaged
jar (application-{profile}.properties and YAML variants)
Profile-specific application properties packaged inside your jar
(application-{profile}.properties and YAML variants)
Application properties outside of your packaged jar
(application.properties and YAML variants).
Application properties packaged inside your jar
(application.properties and YAML variants).
#PropertySource annotations on your #Configuration classes.
Default properties (specified using
SpringApplication.setDefaultProperties).
To provide a concrete example, suppose you develop a #Component that
uses a name property:
import org.springframework.stereotype.*
import org.springframework.beans.factory.annotation.*
#Component
public class MyBean {
#Value("${name}")
private String name;
// ...
}
On your application classpath (e.g. inside your jar) you can have an
application.properties that provides a sensible default property value
for name. When running in a new environment, an
application.properties can be provided outside of your jar that
overrides the name; and for one-off testing, you can launch with a
specific command line switch (e.g. java -jar app.jar --name="Spring").
[Tip] The SPRING_APPLICATION_JSON properties can be supplied on the
command line with an environment variable. For example in a UN*X
shell:
$ SPRING_APPLICATION_JSON='{"foo":{"bar":"spam"}}' java -jar myapp.jar
In this example you will end up with foo.bar=spam in the Spring
Environment. You can also supply the JSON as spring.application.json
in a System variable:
$ java -Dspring.application.json='{"foo":"bar"}' -jar myapp.jar
or command line argument:
$ java -jar myapp.jar --spring.application.json='{"foo":"bar"}'
or as a JNDI variable java:comp/env/spring.application.json.
Inject Spring Boot properties
You can inject the values in your code this way:
#Value("${server.port}")
private int port;
#Value("${server.contextPath}")
private String contextPath;
Hateoas
Alternatively, you could take a look at the Hateoas project, which can generate the link section for you: http://docs.spring.io/spring-hateoas/docs/current/reference/html
Use #Value annotation to inject the properties into member variables of your class. You can do this:
#Component
public class Foo
{
#Value("${server.port}")
String serverPort;
#Value("${server.contextPath}")
String contextPath;
public void doSomething()
{
String str = "serverPort: " + serverPort + "; contextPath: " + contextPath;
}
}

Static resource reload with akka-http

In short: is it possible to reload static resources using akka-http?
A bit more:
I have Scala project.
I'm using App object to launch my Main
class.
I'm using getFromResourceDirectory to locate my resource
folder.
What I would like to have is to hot-swap my static resources during development.
For example, I have index.html or application.js, which I change and I want to see changes after I refresh my browser without restarting my server. What is the best practise of doing such thing?
I know that Play! allows that, but don't want to base my project on Play! only because of that.
Two options:
Easiest: use the getFromDirectory directive instead when running locally and point it to the path where your files you want to 'hotload' are, it serves them directly from the file system, so every time you change a file and load it through Akka HTTP it will be the latest version.
getFromResourceDirectory loads files from the classpath, the resources are available because SBT copies them into the class directory under target every time you build (copyResources). You could configure sbt using unmanagedClasspath to make it include the static resource directory in the classpath. If you want to package the resources in the artifact when running package however this would require some more sbt-trixery (if you just put src/resources in unmanagedClasspath it will depend on classpath ordering if the copied ones or the modified ones are used).
I couldn't get it to work by adding to unmanagedClasspath so I instead used getFromDirectory. You can use getFromDirectory as a fallback if getFromResourceDirectory fails like this.
val route =
pathSingleSlash {
getFromResource("static/index.html") ~
getFromFile("../website/static/index.html")
} ~
getFromResourceDirectory("static") ~
getFromDirectory("../website/static")
First it tries to look up the file in the static resource directory and if that fails, then checks if ../website/static has the file.
The below code try to find the file in the directory "staticContentDir". If the file is found, it is sent it back to the client. If it is not found, it tries by fetching the file from the directory "site" in the classpath.
The user url is: http://server:port/site/path/to/file.ext
/site/ comes from "staticPath"
val staticContentDir = calculateStaticPath()
val staticPath = "site"
val routes = pathPrefix(staticPath) {
entity(as[HttpRequest]) { requestData =>
val fullPath = requestData.uri.path
encodeResponse {
if (Files.exists(staticContentDir.resolve(fullPath.toString().replaceFirst(s"/$staticPath/", "")))) {
getFromBrowseableDirectory(staticContentDir.toString)
} else {
getFromResourceDirectory("site")
}
}
}
}
I hope it is clear.

Memory Leak in Grails with MongoDB

I've found a strange issue when saving or updating several objects in Grails with MongoDB. Currently I'm using Grails 2.2.3 and MongoDB plugin 1.3.0.
The problem seems to be that the instances of MiUsuario are never GC neither when I manually call the GC. In our main application we don't make batch updates, but when doing load tests (with JMeter and monitoring JVM with Java VisualVM) this problem causes memory filling and Tomcat stops responding.
I've created a small new application to show the problem.
A simple domain object:
class MiUsuario {
ObjectId id
String nickName
}
My controller:
import pruebasrendimiento.Prueba
class MiUsuarioController {
def doLogin(String privateKey, String id){
MiUsuario user = MiUsuario.get(id)
user.nickName = new Random().nextInt().toString()
user.save(failOnError:true)
render 'ok'
}
}
My BuildConfig (Just the dependencies and plugins part):
dependencies {
}
plugins {
// runtime ":hibernate:$grailsVersion"
runtime ":jquery:1.8.3"
runtime ":resources:1.2"
build ":tomcat:$grailsVersion"
// runtime ":database-migration:1.3.2"
// compile ':cache:1.0.1'
runtime ":mongodb:1.3.0"
}
I've also tried something that Burt said a long time ago (http://burtbeckwith.com/blog/?p=73), but DomainClassGrailsPlugin.PROPERTY_INSTANCE_MAP.get().clear() doesn't make any difference. And the other option that's said in that page, RequestContextHolder.resetRequestAttributes(), gives me an exception.
I had similar problem and it solves upgrading to grails 2.3.1. Try it.