I am currently struggling with this issue here..
In our system, we use Java beans and Scala case classes, and they often contains one another.
So, i am looking for a good solution for how to map these objects to mongoObjects, so i can save/load them from the database.
For this, i tried Morphia, but unfortunately it won't serialize back from json to object because it cannot construct a case class.
So I tried Salat, but this one only works with case classes and not java beans :(
Do anyone have an idea about how to do this?
Salat developer here.
If you want to use Salat, you could convert your Java beans to Scala case classes and annotate the constructor params with #scala.reflect.BeanProperty for interoperability with Java (if this is really necessary).
Related
Rookie question here.
I have 2 apps that utilize Hazelcast, one is in Typescript and the other is in Scala.
The Typescript app stores all the data and the Scala one interacts with it.
I need an easy way to parse items inside of a map to a case class, this is easy if the HazelCast data is saved within Scala because it can be cast but when I attempt to do this with data stored from Typescript I get the following
java.lang.ClassCastException: com.hazelcast.core.HazelcastJsonValue cannot be cast to TheCaseClass
I'm using circe and finch in the rest of the application, not sure if circe can be used here to parse it.
tl;dr Is there an easy way to convert HazelCast data stored in Typescript to a Scala case class.
Thanks
You cannot just take one arbitrary class and cast it to another class. You have to parse them. If you use Hazelcast then probably Hanzelcast Scala is what you should use.
Wiki suggest that you would have to do at least:
import com.hazelcast.Scala._
serialization.Defaults.register(conf.getSerializationConfig)
though it might require you to write your own custom serialization.
I just realized I cannot have annotations in scala, that are preserved and analyzed at runtime. I also checked this question, but I didn't quite get it what are the alternatives.
DI - an answer mentions that there is no need for DI framework in scala. While that might be the case on a basic level (although I didn't quite like that example; what's the idiomatic way of handling DI?), Java DI frameworks like spring are pretty advanced and handle many things like scheduled jobs, caching, managed persistence, etc, all through annotations, and sometimes - custom ones.
ORM - I'll admit I haven't tried any native scala ORM, but from what I see in squeryl, it also makes some use of annotations, meaning they are unavoidable?
any serialization tool - how do you idiomatically customize serialization output to JSON/XML/...?
Web service frameworks - how do you define (in code) the mappings, headers, etc. for RESTful or SOAP services?
Scala users need to have a hybrid scala/java (for the annotations) project in order to use these facilities that are coming from Java?
And are the native scala alternatives for meta-data nicer than annotations? I'm not yet fully into the scala mode of thinking, and therefore most of the examples look ugly to me, compared to using annotations, so please try to be extra convincing :)
Actually, Scala does have runtime-retained annotations. The difference is that they are not stored as Java annotations but are instead encoded inside the contents of binary ScalaSignature annotation (which, by itself, is a runtime-retained Java annotation).
So, Scala annotations can be retrieved at runtime, but instead of using Java reflection, one must use Scala reflection:
class Awesome extends StaticAnnotation
#Awesome
class AwesomeClass
import scala.reflect.runtime.universe._
val clazz = classOf[AwesomeClass]
val mirror = runtimeMirror(clazz.getClassLoader)
val symbol = mirror.classSymbol(clazz)
println(symbol.annotations) // prints 'List(Awesome)'
Unfortunately, Scala reflection is still marked as experimental and is actually unstable at this point (SI-6240 or SI-6826 are examples of quite serious issues). Nevertheless, it seems like the most straightforward replacement for Java reflection and annotations in the long term.
As for now, one has to use Java annotations which I think is still a nice solution.
Regarding frameworks and libraries for DI/ORM/WS/serialization - Scala still doesn't seem to be mature in this area, at least not as Java is. There are plenty of ongoing projects targeting these problems, some of them are already really nice, others are still in development. To name a few that come to my mind: Squeryl, Slick, Spray, Pickling.
Also, Scala has some advanced features that often make annotations unneccessary. Typeclasses (implemented with implicit parameters) are probably good example of that.
It seems only the casbah we can use in scala, but I hope there is a orm-like library for scala, like morphia for java, or something else.
Is there any? I don't want to use morphia in scala because I have to convert java collections to scala
UPDATE
I've tried some of them, but still not find a proper one. Some are hard for scala newbies to get started.
FINALLY
Finally, I chose mongo-scala-driver, its awesome. Thanks to everybody.
There are two solid options:
Salat, which is designed to integrate with Casbah using case classes and scalasig - https://github.com/novus/salat/
Lift (liftweb.net) also has an activerecord ttype library for Mongo which Foursquare has built a DSL, Rogue, for. http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/
Spring Data is releasing Morphia-like mapping capabilities in the M2 of the MongoDB support. We've talked about doing some native Scala support for this but we haven't had anyone ask for it directly, so its hard to gauge interest. It should be usable as-is from Scala--though there are things I'd like to see us make more Scala-ish.
https://github.com/springsource/spring-data-document
I don't want to use morphia in scala because I have to convert java collections to scala
If this is the only reason, I suggest you to use scala.collection.JavaConversions It contains implicit conversions from Java to Scalca collections and vice verse.
I would prefer using constructor injection over JavaBean property injection if I could utilize the named and default arguments feature of Scala 2.8. Any IoC-containers exists that supports that or could be easily extended to do so? (The required information is there on runtime in the scala.reflect.ScalaSignature annotation of the class.)
I also have some basic(?) expectations from the IoC container:
Auto-wiring (by target class/trait or annotation, both one-to-one and one-to-many)
Explicit injection (explicit wiring) without much hassle (like Guice is weak there). Like user is injected that way in new ConnectionPool(user="test").
Life-cycle callback for cleanup on shutdown (in the proper order)
Spring can do these, obviosuly, but it doesn't support named parameters. I have considered using FactoryBean-s to bridge Scala and Spring, but that would mean too much hassle (boilerplate or code generation), as far as I see.
PART A
I have a work-in-progress reflection library that parses the Scala signature and is currently able to resolve named parameters: https://github.com/scalaj/scalaj-reflect
Unfortunately, I haven't yet tied it back into Java reflection to be able to invoke methods, nor have I added the logic to resolve default values (though this should be trivial). Both features are very high on my to-do list :)
This isn't an IoC container per-se, but it's a pre-requisite for another project of mine: https://github.com/scalaj/scalaj-spring. Work on scalaj-spring stopped when it became blindingly obvious that I wouldn't be able to make any worthwhile further progress until I had signature-based reflection in place.
PART B
All of that stuff is intended for big enterprisey people anyway. Those with no choice but to integrate their shiny new Scala code into some hulking legacy system... If that's not your use case, then you can just do Scala DI directly inside Scala.
There's DI support provided under the Lift banner: http://www.assembla.com/wiki/show/liftweb/Dependency_Injection
You should also hunt around for references to the cake pattern
Another dependency injection framework in Scala is subcut
I have considered using FactoryBean-s to bridge Scala and Spring, but that would mean too much hassle
I am not sure I understand the complexity. Its actually quite simple to implement Spring FactoryBeans in Scala. Check this little write-up http://olegzk.blogspot.com/2011/07/implementing-springs-factorybean-in.html
I've just released Sindi, an IoC container for the Scala programming language.
http://aloiscochard.github.com/sindi/
To all -- I'm probably at best a new guy here, trying to wrap my head around scala, and I find I need to do the following:
Assume I have a scala class on disk somehwere referenced in my classpath.
I have a scala application that wants to dynamically load this class and call its constructor
Once I have that class reference, I can use it to set up values in other classes and objects.
In Java, I'd use the Java class loader and create a new instance whereupon I'd call its constructor. What is the right way to do this in Scala?
Scala classes are Java classes, so just do what you'd do in Java. The Scala Java Interoperability FAQ doesn't talk about classloaders specifically, but it might be helpful as you figure things out.
I have written a blog entry quite a long time ago on this. Unfortunately I haven't found the time to update it for Scala 2.8 .
Essentially it boils down to
do it like you would in Java
use Scala features to improve the user interface