What is the idiomatic Groovy and Grails way of casting to a Domain Model class? - grails

Given the Grails Domain Classes "Apple.groovy" and "Orange.groovy", not strictly related, and the following Grails Service invoked from the Controllers:
package test
import grails.transaction.Transactional
import javax.servlet.http.HttpServletRequest
#Transactional
class UploadService {
def uploadApple(HttpServletRequest request, Apple o) {
def file = request.getFile('payload')
o.payload = file.getBytes()
o.filename = file.originalFilename
o.contentType = file.contentType
o.save(flush:true)
}
def uploadOrange(HttpServletRequest request, Orange o) {
def file = request.getFile('payload')
o.payload = file.getBytes()
o.filename = file.originalFilename
o.contentType = file.contentType
o.save(flush:true)
}
}
How would one go about unifying this code under a common method? I was hoping Groovy's optional types would handle this for me, but I can't seem to be able invoke .save() successfully if I remove the types from the method signature.
Thanks in advance

Avoid passing request to service and pass File to service. Did you try it this way?
def upload(file, obj) {
obj.payload = file.getBytes()
obj.filename = file.originalFilename
obj.contentType = file.contentType
obj.save(flush:true)
}
Unlike Java, Groovy does duck typing. Typing is concerned with assigning a type to any object. Duck typing is concerned with establishing the suitability of an object for some purpose.
Now you have to be careful because this will not work for every object. The reason that it works for Apple and Orange is because both have exactly the same set of attributes and attribute types.
One would wonder, why you would have two different domain that behave exactly the same, but that's obviously is a different discussion.

In Grails 3, domain classes implement the GormEntity trait, which is where the save() method comes from. But that doesn't solve the issue with the payload, filename, and contentType properties.
What you can do is create an interface which declares the methods and properties common to both domain classes and also implements org.grails.datastore.gorm.GormEntity. Then, have the domain classes implement the interface:
interface Uploadable extends GormEntity {
byte [] payload
String filename
String contentType
}
class Apple implements Uploadable {
byte [] payload
String filename
String contentType
}
Then, you can use the interface in your service.
#Transactional
class UploadService {
def upload(HttpServletRequest request, Uploadable o) {
def file = request.getFile('payload')
o.payload = file.getBytes()
o.filename = file.originalFilename
o.contentType = file.contentType
o.save(flush:true)
}
}
Note: Since Grails injects the GormEntity trait into the domain classes automatically, I don't know what happens if you use it explicitly as shown.

Related

Jenkins Shared Library Immutable Singleton

I have a Singleton patter class in my Jenkins shared library:
public class Configuration {
private static final INSTANCE = new Configuration()
static getInstance() { return INSTANCE }
private Configuration() {
}
def initialize(env, params) {
Foo = params.FOO;
}
public String Foo = ''
}
Later I can call this from elsewhere using something like this:
Configuration.instance.initialize(env, params);
config = Configuration.instance;
println 'FOO: ' + config.Foo
Ideally, I want the benefit of the Singleton pattern, but I don't want some fields to be overridden by consumers.
First Attempt:
On first thought, I would think this would work:
public class Configuration {
private static final INSTANCE = new Configuration()
static getInstance() { return INSTANCE }
private Configuration() {
}
def initialize(env, params) {
INSTANCE.#Foo = params.FOO;
}
public final String Foo = ''
}
Error:
groovy.lang.GroovyRuntimeException: Cannot set the property 'Foo' because the backing field is final.
Second Attempt:
On Second thought, I would think initializing in the constructor would work, however I don't seem to have access to params and env, unless these are passed in from the vars function, via the initialize() method.
How can I make this Singleton class immutable, or its fields read only?
I think you Could:
Define your class with "implements Serializable", as documentation advices.
Implement the constructor that would accept 1 parameter of type BaseScript, and pass this to it upon instantiation, relative to that this (which you could call internal script) you can refer to script.params, script.env, etc. and I mean you don't HAVE to use initialize, you can do all you want in the c'tor.
But wait, please tell more:
why does CI/CD code need to have a Singleton?
You're passing its data as parameters [so it's not really an immutable entity :)]
Maybe you could "simply" create an immutable map out of your parameters....
Configuration as singleton feels as if you can delegate configuration management to ... configuration management service (consul, etcd, or others).
Please elaborate, it's very curious!
Also you referred to something as "consumers". are these library consumers? or people running the jobs?
Thank you!

WebSocket.acceptWithActor and #Inject() in the Actor (Play 2.5)

WebSocket.acceptWithActor instantiates a new Akka actor without making use of Guice.
With Play 2.4, using the injector for my actor was still possible by importing play.api.Play.current.
Snippet from ReactiveMongo documentation:
import scala.concurrent.Future
import play.api.Play.current // should be deprecated in favor of DI
import play.api.libs.concurrent.Execution.Implicits.defaultContext
import play.modules.reactivemongo.ReactiveMongoApi
import play.modules.reactivemongo.json.collection.JSONCollection
object Foo {
lazy val reactiveMongoApi = current.injector.instanceOf[ReactiveMongoApi]
def collection(name: String): Future[JSONCollection] =
reactiveMongoApi.database.map(_.collection[JSONCollection](name))
}
But in Play 2.5, play.api.Play.current is deprecated. How can I still inject ReactiveMongoApi in my actor? What is the recommended way of using an instance of ReactiveMongoApi in my actor?
Here is my code which works with Play 2.4 because my custom actor class ClientActor has access to ReactiveMongoApi through current.injector.instanceOf[ReactiveMongoApi]:
#Singleton
class Application #Inject() (system: ActorSystem) extends Controller {
val midiDiscoveryActor = system.actorOf(MidiDiscoveryActor.props, "midi-discovery-actor")
val midiActor = system.actorOf(MidiActor.props(midiDiscoveryActor), "midi-actor")
def index(page: String) = Action {
Ok(views.html.index(page))
}
def bidirectional = WebSocket.acceptWithActor[JsValue, JsValue] { request => out =>
ClientActor.props(out, midiActor, midiDiscoveryActor)
}
}
I don't think this is possible. Quoting James Roper:
The helpers that Play provides for dependency injecting actors are suited for a limited number of use cases. Though, the helpers are really just very thin wrappers over some common requirements - they're not needed at all. In the case Play's WebSocket actor support, the thing is, generally you want to manually instantiate the actor since you have to somehow pass it the out ActorRef. So, you can either do this using Guice assisted inject, and define a factor interface that takes the out actor ref (and whatever other arguments you want to pass to it), or simply instantiate it manually, passing dependencies from the controller to the actor, for example:
class MyController #Inject() (myDep: MyDep) extends Controller {
def socket = WebSocket.acceptWithActor[String, String] { request => out =>
MyWebSocketActor.props(out, myDep)
}
}
Play 2.5 has built in support for DI.
MidiActor signature needs to be modified as said below.
class MidiActor#Inject() (configuration: Configuration, #Named("midi-discovery-actor") midiDiscoveryActor: ActorRef) extends Actor with InjectedActorSupport{
.......
}
Create new Module and enable in application.conf
play.modules.enabled += MyModule
class MyModule extends AbstractModule with AkkaGuiceSupport {
def configure = {
bindActor[MidiDiscoveryActor]("midi-discovery-actor")
bindActor[MidiActor]("midi-actor")
}
}
Change your controller as below
#Singleton
class Application #Inject() (system: ActorSystem,#Named("midi-actor") midiActor: ActorRef,
#Named("midi-discovery-actor") midiDiscoveryActor: ActorRef) (implicit ec: ExecutionContext) extends Controller {
def index(page: String) = Action {
Ok(views.html.index(page))
}
def bidirectional = WebSocket.acceptWithActor[JsValue, JsValue] { request => out =>
ClientActor.props(out, midiActor, midiDiscoveryActor)
}
}

Grails: How to mock properties for domain object with non-domain abstract base class

I have a grails 2.2.4 app with a domain class Monster:
class Monster {
int aggression
}
I can mock and test it like so:
import spock.lang.*
class MonsterSpec extends Specification {
def "property mocks work"() {
given:
def m = Mock(Monster)
m.aggression >> 5
expect:
m.aggression == 10
}
}
Recently I decided to give it an abstract base class (not a domain object itself) so that I could share method implementations among my many Monster-like classes:
abstract class Entity {} // Not under /domain
class RefactoredMonster extends Entity {
int aggression
}
But then a thousand simple tests all broke, like so:
import spock.lang.*
class MonsterSpec extends Specification {
def "property mocks work"() {
given:
def m = Mock(RefactoredMonster)
m.aggression >> 10
expect:
m.getAggression() == 10 // This works
and:
m.aggression == 10 // This fails! m.aggression is null!
}
}
What on Earth is going on? The problem goes away if I make Entity concrete, but then of course I can't hydrate any Monster objects since Hibernate doesn't know what to do with Entity (and I don't want to make Entity a domain object, though I suppose I will if I really must).
What am I missing?
The problem is GORM expects the super class to be a domain class.
With Groovy 2.0, which is what Grails 2.2.4 has, you can use compile-time mixins to add methods to a class. This allows for method reuse without inheritance.
The Entity can remain as not a domain class, but it must be a concrete class. Then, instead of subclassing, use it as a mixin.
#Mixin(Entity)
class RefactoredMonster {
int aggression
}
An alternative
Since you need the ability to override methods, as you said, Mixins are out.
Looking at this from a higher level, a potential issue is the architecture/design. Inheritance is meant to represent is-a relationships (ex. a Dog is an Animal). But when inheritance is used primarily as a way to reuse methods, it can lead to... a mess.
It may be better to forgo inheritance and choose has-a (delegation) instead. This would allow you to reuse behaviour and override it when needed. Unfortunately, Groovy 2.0 doesn't support #Delegate. So the following example is going to have more boilerplate code than the same thing coded in Groovy 2.4 would:
interface Flier {
def fly();
}
class FlierImp {
def fly() { "I'm fying! WOOT!" }
}
class RealDuck implements Flier {
def flier
RealDuck() {
flier = new FlierImp() // Purposely not using injection
}
def fly() {
flier.fly()
}
}
class RubberDuck implements Flier {
def fly() { "I don't fly" }
}
def duck = new RealDuck()
def rubberDuck = new RubberDuck()
assert duck.fly() == "I'm fying! WOOT!"
assert rubberDuck.fly() == "I don't fly"
In the example above RealDuck and RubberDuck represent domain classes (which is why I'm not injecting the flier). The flying behaviour is demanded by an interface and implemented either via a class which only implements the behaviour (FlierImp), or by implementing it directly, as shown in RubberDuck.

Grails: why would this service class be null?

Given this grossly simplified rendition of the setup:
package net.myexample.plugin
class MyExampleService {
Map doMunge(Map m) {
// do stuff to 'm'
return m
}
}
/****************************** BREAK: NEXT FILE ******************************/
package net.myexample.plugin
class MyTagLib {
static namespace = 'p'
def myExampleService
def tag = { attrs, body ->
def m = doMungeAndFilter(attrs.remove('m'))
out << g.render(template: '/template', plugin: 'my-example-plugin', model: m)
}
Map doMungeAndFilter(def m) {
def mm = myExampleService.doMunge(m)
// do stuff to 'm'
return mm
}
}
/****************************** BREAK: NEXT FILE ******************************/
package net.myexample.app
import net.myexample.plugin.MyExampleService
class MyExampleService extends net.myexample.plugin.MyExampleService {
def doMunge(def m) {
def mm = super.doMunge(m)
// do more stuff to 'mm'
return mm
}
}
/****************************** BREAK: NEXT FILE ******************************/
package net.myexample.app
import net.myexample.plugin.MyTagLib
class MyTagLib extends net.myexample.plugin.MyTagLib {
static namespace = 'a'
def myExampleService
def tag = { attrs, body ->
def m = doMungeAndFilter(attrs.remove('m'))
out << g.render(template: '/template', plugin: 'my-example-plugin', model: m)
}
Map doMungeAndFilter(def m) {
def mm = super.doMungeAndFilter(m)
// do more stuff to 'mm'
return mm
}
}
/**
* But we get an exception that cites that it cannot call 'doMunge' on a null
* object -- which could only be 'myExampleService'
*/
Why would the service appear to be null when the method on the app's taglib calls its superclass (the taglib on the plugin), which in turn calls the method on the service?
The best theory I could come up with is that the service is not actually being instantiated in the app's taglib class because there are no explicit references to it aside from the def. I presume that this is the case because if I move all the logic from service class's method into the taglib's method, it works as expected.
(For the sake of painting a complete picture: MyExampleService.doMunge is called in other places, whereas the subsequent filtering (in MyTagLib.doMungeAndFilter) is only needed for the taglib.)
Alternatively: if I move doMungeAndFilter into another service class, creating the base version in the plugin and extending it in the app, that works fine. Which I suppose is an acceptable conclusion, though it feels like bloat to create another service class just to support the taglib like that.
Thoughts? Tips? Glaring errors or omissions?
Remove the def myExampleService from the subclass taglib. A property like that in Groovy compiles to a private field plus a public getter and setter, so in the superclass taglib you have implicitly
private Object myExampleService;
public void setMyExampleService(Object svc) {
this.myExampleService = svc;
}
// getter similar
When you declare myExampleService again in the subclass the subclass gets its own private field (with the same name) and the setter gets overridden to store the supplied value in this subclass field instead of the superclass one. Spring calls the setter to inject the service, so the end result is that the superclass private myExampleService never gets set, hence the null pointer exception when trying to call myExampleService.doMunge in the superclass.
The subclass has access to the superclass property via the inherited getter and setter so it doesn't need to re-declare it.
This is just a quick guess, but is you taglib class file located under /grails-app/taglib, or somewhere in your /src directory? I've noticed I can't get services to inject (automatically, at least) into classes located outside the /grails-app folder.

How To Call A Taglib As A Function In A Domain Class

I need to call the Static Resources Plugin (http://www.grails.org/Static+Resources+Plugin) from my domain class.
This works perfectly in a controller:
def tstLink = resourceLinkTo(dir:"docs/${identifier}",file:originalFileName)
but in a domain class I get
Exception Message: No signature of method: static org.maflt.ibidem.Item.resourceLinkTo() is applicable for argument types: (java.util.LinkedHashMap) values: [[dir:docs/19e9ea9d-5fae-4a35-80a2-daedfbc7c2c2, file:2009-11-12_1552.png]]
I assume this is a general problem.
So how do you call a taglib as a function in a domain class?
I encountered this problem a while ago for an app I was working on. What I ended up doing was putting a call to the tag in a service method:
class MyService {
def grailsApplication //autowired by spring
def methodThatUsesATag(identifier, originalFileName) {
//This is the default grails tag library
def g = grailsApplication.mainContext.getBean('org.codehaus.groovy.grails.plugins.web.taglib.ApplicationTagLib')
g.resourceLinkTo(dir:"docs/${identifier}",file:originalFileName)
}
}
Then in my domain class, I could get to the service via spring autowiring as well:
class MyDomain {
String originalFileName
def myService //autowired
static transients = ['myService'] //Necessary so that GORM doesn't try to persist the service instance.
//You can create a method at this point that uses your
//service to return what you need from the domain instance.
def myMethod() {
myService.methodThatUsesATag(id, originalFileName)
}
}
Most taglibs rely on data from the controller so it's often not possible to reuse them while others concern view logic so often it's not something you would want to put in a domain class.
That said, I'm sure you have your reasons so maybe the source of the taglib will help:
class ResourceTagLib {
def externalResourceServerService
def resourceLinkTo = { attrs ->
out << externalResourceServerService.uri
out << '/'
if(attrs['dir']) {
out << "${attrs['dir']}/"
}
if(attrs['file']) {
out << "${attrs['file']}"
}
}
}
ie inject the externalResourceServerService into your domain class and the rest should be simple.

Resources