I need to serialize object of uknown type(only JDBC types) in GWT. I have an object that holds list of uknown "jdbc" objects and i need it to be transfered from client to server and back. If this object is serializing to file not in gwt client environment I can hold those uknown objects in list of Object's. But GWT can't serialize objects of type Object. How can I achieve this? Any suggestions
You may be running into problems if those jdbc types are not being returned by any of your other RPC methods.
If, for instance, your class Foo isn't sent via RPC by any method other than one which returns List[Object], then GWT has no knowledge at compile time (when it generates the RPC whitelist) that Foo is a class that it should generate the code to serialize. This especially makes sense for the generated JavaScript, where avoiding code bloat from unused types is important.
You can work around this by manually adding your otherwise unreferenced classes (all possible return types from JDBC) in a dummy class that gets sent across RPC.
How do I add a type to GWT's Serialization Policy whitelist?
Alternately you can write a custom RemoteService generator to use which adds the types without a Dummy class being required.
http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsDeferred.html#generator
You can return them as
List<Serializable> serviceMethod();
If you guarantee that they are all Serializable. Just cast all of them to Serializable before returning from the service method.
See GWT JRE Emulation Reference, there is no Object class and GWT cannot serialize it, so you should create your own transfer object which implements IsSerializable marker interface.
Briefly, RPC can not serialize java.lang.Object. Check this links:
GWT Sending type OBJECT Via RPC and good thread here:
Serialize object and Why is GWT serialization so complicated?
Related
I would like to write test for a controller class. The controller class takes a service object as constructor parameter. Added the #Inject annotation to the constructor of the service class.
class AssociateService #Inject()(configuration: Configuation){...}
The constructor parameter of the service class is a custom configuration object also created for the application. I added the #Inject to the constructor of the config class as well. Now I'm getting these types of error messages:
No implementation for "className" was bound.
Could not find a suitable constructor in java.lang.Integer. Classes must have either one (and only one) constructor annotated with #Inject or a zero-argument constructor that is not private.
The configuration class has several constructor parameters, those are "basic" types (Int, Boolean) and one parameter is a custom class type (className).
How should I do this binding or is it just enough to annotate something else?
And why it says that constructor error message?
As far as I know, there are two ways with tests and guice, with trade offs:
Don't using field injections, using only constructor injections and fields assignment in constructor for injected parameters. This approach enables very simple solution for testing, just don't use dependency injection in tests. But all your classes must have ability to be created with new operator in test cases...
Ps. You can define optional constructor and use field injections, of course, but it is not very clear solution.
Creating correct module with injectable interfaces binding to its implementations for every test or group of similar tests. Sometimes this approach takes a lot of unnecessary working hours.
You must design your software to maintain testability. Sometimes not every line of code in project need to be tested, sometimes not every code is testable, you must separate it from important parts of your software, that requires testing. If you design your software with single responsibility principe so writing tests is much easer...
I'm trying to write a class to implement KryoSerializer so that I can serialize objects for use with Spark. The issue I'm having is that while all of the classes implement a public interface, all of the implementing classes are private. Kryo doesn't seem to want to allow me to define a serializer for either a private out-of-package class or an interface.
The way this issue manifests is that when I attempt to define the KryoSerializer class, I get an error that class [implementation] in package graph cannot be accessed in package [same package].
What I'm hoping someone can help with, is a strategy for solving this issue.
I understand the reasons why Kryo wants to serialize and deserialize concrete objects. But, in this case, since I am defining my own KryoSerializer anyway, it actually would make more sense to define serialization for the interface. Is there a way to trick Kryo into doing the right thing?
(The reason this will work, is that there is a related Object that has functions to take an instance with the interface and write or read from a stream. My serializer would essentially wrap those functions while adding some serialization format version information.)
One possibility I thought of is the reflection trick. When deserializing a class with private/final members, we sometimes use reflection to make the private member accessible and writable, set the value, then set it back to private/final. I'm not sure if its possible to do that for a private class in another packager, but even if it is, it seems rather ugly and inefficient.
Another possibility would be to define new classes that extend the private classes, along with a set of implicits to convert among them. That would also be rather ugly though, for a few reasons, and there are quite a few private classes at issue.
Can anyone suggest an approach? Advise regarding pitfalls I should avoid?
There are already a few questions regarding the fact that methods in GWT RPC should not return an interface like List, but rather a concrete class like ArrayList, because otherwise "GWT needs to include all possible implementations". See e.g. In GWT, why shouldn't a method return an interface?
Here's my question: is this limited to the return type itself? How about parameters of the method? And what if the return object contains an interface, e.g.
public class MyReturnObject implements IsSerializable {
List<String> listOfUnspecifiedType1;
List<Long> listOfUnspecifiedType2;
...
}
The examples I have seen all talk of the return type itself. I don't see why it would be a problem to return an interface, but not a problem to return an object which just wraps an interface; but maybe I am missing something?
It's clear from the linked question that it applies recursively (and as soon as you understand why you should use the most derived types as possible, it becomes obvious that it is recursive).
This is also true of method arguments, not only the return types and their fields: if you send a List<X> then GWT has to generate serialization code for all List classes: ArrayList, LinkedList, etc.
And of course the same applies to classes, not only interfaces: AbstractList is no different from List.
And because generation comes before optimization, all possible classes from the source path will be included, not only those that you use in your code; and then they come in the way of the optimization pass, as all those classes are now used by your app.
Therefore, the rule is: use the most specific types as possible. The corollary is: don't fear DTOs, don't try to send your business/domain objects at all cost.
I've written a Scala trait, named Cache[A,B], to provide a caching API. The Cache has the following methods, asyncGet(), asyncPut(), asyncPutIfAbsent(), asyncRemove().
I'm going to have a few static methods, such as getOrElseUpdate(key: A)(op: => B). I don't want methods like this as abstract defs in the Cache trait because I don't want each Cache implementation to have to provide an implementation for it, when it can be written once using the async*() methods.
In looking at Google Guava and parts of the Java library, they place public static functions in a class that is the plural of the interface name, so "Caches" would be the name I would use.
I like this naming scheme actually, even though I could use a Cache companion object. In looking at much of my code, many of my companion objects contain private val's or def's, so users of my API then need to look through the companion object to see what they can use from there, or anything for that matter.
By having a object named "Caches" is consistent with Java and also makes it clear that there's only public functions in there. I'm leaning towards using "object Caches" instead of "object Cache".
So what do people think?
Scala's traits are not just a different name for Java's interfaces. They may have concrete (implemented) members, both values (val and var) and methods. So if there's a unified / generalized / shared implementation of a method, it can be placed in a trait and need not be replicated or factored into a separate class.
I think the mistake starts with "going to have a few static methods". Why have static methods? If you explain why you need static methods, it will help figure out what the design should be.
More or less the same as this question but for DataContractSerializer rather than Serializable.
I explicitly do not want to be serializing parent references.
Also I would really rather the object's parent be bound before the children are constructed.
BTW: I'm using XML if that makes any difference
If you know the universe of child types, you can implement a surrogate to special-case the non-child types and essentially 'skip' the parent (i.e., non-child) types during serialization. As an example, see the http://msdn.microsoft.com/en-us/library/ms751540.aspx [Data Contract Surrogate] sample. Another option -- if you're using WCF 4 now -- is to use a DataContractResolver for type resolution and redirection. Again, see http://msdn.microsoft.com/en-us/library/dd807504.aspx [Data Contract Resolve Sample] for a reference!
Cheers.