Serialize object

[Jim]

In POJO, I must define "public Object getBirthDate()" instead of
"public Date getBirthDate()" as in the following example:
public class Person implements Serializable {
private Object birthDate = null;
public Object getBirthDate() {
return birthDate;
}
public void setBirthDate(Date birthDate) {
this.birthDate = birthDate;
}
}.

It doesn't work in GWT RPC because Object is not serializable object
although I know birthDate is java.util.Date type. In order to make it
to work, I have to change class definition to implements
IsSerializable and create a new class "public class
Person_CustomFieldSerializer". For this class, it is ok to create this
new class. If I have many POJO classes such as Address, I need to
create each class for RPC although some methods return Object that are
concrete serializable objects such as Integer, Long, Timestamp.

What is a best way to handle this if I still want POJO classes to
return Object and don't want to create a new class for RPC. I want GWT
to provide this kind of solution when RPC find a unserializable object
such as java.lang.Object, GWT looks for Object_CustomFieldSerializer
class under entry point package to serialize Object.

Jim

[walden]

Jim,

Just curious, but why does getBirthDate have to return Object? It's
conceivable that the method might have to return something other than
Date (or null), but is there no way to constrain the return type
definintion at all? This seems like a general design problem.

Walden

[Jim]

I just used it as an example. In another thread, other users have the
same problems. They want to use Object although they know the concrete
objects. For instance, if I want to use third-party libraries that
contains a nonserializable object such as X, I have to create new
X_CustomFieldSerializer classes on the same package as I understand. I
think this isn't a good approach. If class Y also uses X and X is only
one that is nonserializable object, I have to create
Y__CustomFieldSerializer. If I am allowed to create
X_CustomFieldSerializer under entry point package, I just need to
create one class.

> > Jim- Hide quoted text -
>
> - Show quoted text -

[walden]

Jim,

Your original question was: "What is the best way to handle this
if..." where the "if" basically translates to "I don't follow the GWT-
RPC spec for serializable objects. The custom serializer option is
GWT giving you a tactic for handling your decision to deviate from the
spec. I don't think there is anything more than that. I think "best
way" = "bite the bullet". I need to see a concrete case where this is
unreasonable.

Walden

> > - Show quoted text -- Hide quoted text -

[Jim]

Should we ask this feature? It is reasonable because developer can
make more and fine control on RPC serialization. It is also easy to
implement this feature. GWT check this extension under entry point
package or .gwt.xml to find CustomFieldSerializer class before it
throws an exception.

[Sumit Chandel]

Hi Jim,

At first glance, I agree with you that it seems reasonable to expect support for Object as a transferable type through GWT RPC. However, although the implementation to allow Object through RPC would probably be trivial, it is by design that we currently aren't supporting this feature for two very good reasons.

The first reason has to do with application size. Consider the fact that for every type you want to serialize across the wire through RPC, the GWT compiler must generate that serialization code. The more specific the types you want to transfer, the more succinct the generated serialization code. If we were to support Object as a serializable type, that would mean that we would need to include serialization code that could handle all subtypes of Object, which means bloated JavaScript downloads for your users.

The second reason has to do with application security. If your application could serialize any Object subclass, that opens up a major security vulnerability in that an evildoer could exploit the serialization code and inject a type that could essentially be deserialized into any type that extends Object, which theoretically means they can now create anything they want on your server-side. The GWT compiler generates an <md5>.gwt.rpc serialization policy file for just this reason. The file contains a list of all the types that are allowed to be serialized across the wire, restricting evildoers from injecting and instantiating whatever objects they please on the server. If we were to support Object serialization over the wire, the serialization policy would essentially be obsolete and ineffective at preventing attacks.

All that said, your current approach seems like the right one to me. That is, unless you're able to further constrain your return types to a predefined type, like the JRE emulated Date class. Is there any reason why the provided Date class wouldn't work for you in this circumstance? In GWT 1.5 RC2, there is support for both java.util.Date and java.sql.Date types.

JRE emulation (see java.util and java.sql packages):
http://code.google.com/docreader/#p(google-web-toolkit-doc-1-5)s(google-web-toolkit-doc-1-5)t(RefJreEmulation)

Hope that helps,
-Sumit Chandel

[Martin]

Hello

> The first reason has to do with application size. Consider the fact that for
> every type you want to serialize across the wire through RPC, the GWT
> compiler must generate that serialization code.

I don't understand this explanation much.

I would expect that every serializable type would have only one
serializer and deseliarizer generated. Types consisting of other types
would then reuse de/serializers of that types. There would be one
universal method for serializing any (serializable) object to stream
and one universal method for deserializing stream to object this
stream contains. Both methods would use the generated serializers I
described above. And I don't think there would be more JS as it is
now. We need to serialize primitive types, their object counterparts,
strings, arrays, lists, maps, sets (=various collections) and then
only all types implementing serializable. And I think users are making
types to implement Serializable only if they want them to be passed
over RPC.

> The second reason has to do with application security. If your application
> could serialize any Object subclass, that opens up a major security
> vulnerability in that an evildoer could exploit the serialization code and
> inject a type that could essentially be deserialized into any type that

> extends Object.

Once I expect object on the server side, I must be able to handle any
type. This is responsibility of the application and not serialization.
If I am testing that object wether it is int, double, string, date
else throw IllegalArgumentException then I see no security problem if
they will inject there FooObject. Or am I missing something? Do you
have some example where service expecting object could be "hacked" by
injecting some different object?

Thanks in advance for explanations.

[Sumit Chandel]

Hi Martin,

Please see replies inlined below:

I would expect that every serializable type would have only one
serializer and deseliarizer generated. Types consisting of other types
would then reuse de/serializers of that types. There would be one
universal method for serializing any (serializable) object to stream
and one universal method for deserializing stream to object this
stream contains. Both methods would use the generated serializers I
described above. And I don't think there would be more JS as it is
now. We need to serialize primitive types, their object counterparts,
strings, arrays, lists, maps, sets (=various collections) and then
only all types implementing serializable.

If GWT RPC does what I think it does (adding mmendez to double-check), this is essentially what is going on when it includes serialization code for the different types you are expecting to transfer over the wire. So, let's say I'm transferring 50 different serializable objects through RPC and they all consist of some combination of ints, Strings and HashMaps. The serialization code for the types of these fifty objects is essentially the same, so  I would imagine that the RPC serialization code would be generated in such a fashion to take advantage of that commonality to only generate serialization code for those types that are common to all these types.

If this isn't the case, the generated serialization code would be such that it could handle the serialization of these fifty objects and the types which compose them. In this case, the serialization could be custom tailored to each of those types, so this would still be tighter than including serialization code for all possible types for a given class, which would be the case if we were to support the general Object class as a serializable type. The serialization code would be reusable once downloaded by the client, but that would be one big wad of serialization code that could have been avoided with either of the two approaches described above.

I'll leave the exact details for Miguel to fill out as the exact inner workings of GWT RPC are somewhat of a grey area for me :-)

Once I expect object on the server side, I must be able to handle any
type. This is responsibility of the application and not serialization.
If I am testing that object wether it is int, double, string, date
else throw IllegalArgumentException then I see no security problem if
they will inject there FooObject. Or am I missing something? Do you
have some example where service expecting object could be "hacked" by
injecting some different object?

This is definitely true. Security is ultimately always up to the application developer and they must take care to ensure that their application is secure. However, security vulnerabilities aren't always easy to see, as demonstrated in Dan Morrill's article on "Security for GWT applications". So although security is something that a developer should have in mind when developing their application, we certainly don't want to leave the door wide open for non-obvious attacks that can become real threats to GWT applications using RPC. The .gwt.rpc file allows us to close this door, and the fact that Object isn't a supported serializable type through RPC also helps keep that door sealed.

"Security for GWT applications", by Dan Morrill:
http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications

Hope that helps,
-Sumit Chandel
 

[Martin]

Is generated serialization code really that big? I would expect to
need only 2 commans to serialize one field (1. calling getter, 2.
calling serializer with obtained object). If I have eg. 30 model
objects and each of them has 10 fields, then it would be cca 600
commands. And for me it doesn't seem to be big for complete
serialization code in comparasion to the GUI logic.

> I'll leave the exact details for Miguel to fill out as the exact inner
> workings of GWT RPC are somewhat of a grey area for me :-)

Could he be so kind and share his opinion here? Thanks.

> although security is something that a developer should have in mind when
> developing their application, we certainly don't want to leave the door wide
> open for non-obvious attacks that can become real threats to GWT
> applications using RPC.

I accept this, but there should also be mechanism to explicitly let
that door wide open for some objects. In such cases I am aware of this
and I would really handle the security on my server explicitly.

I've also commented
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8b2f2df7f9931504/936711ed3d20ea36
- but we should continue our talk only in one thread :-)

Thanks for the discussion :-)

[Miguel Méndez]

There is only one generated serializer per type.  The side is not in the serializers themselves, but in the fact that having these unnecessary serializers severely restricts the compiler's ability to prune unused types, etc.

Just to be clear, to make polymorphic RPC work, without a lot of additional control levers, Object cannot be allowed.  Allowing Object pulls in any type that qualifies for serialization whether your application uses it over RPC or not.  Keep in mind that RPC is a Generator, it is not part of the compiler proper so it has no idea of what types your program actually uses; it only knows about he possible set of types that are assignable to a given type.  So, the generated serializers end up being much bigger which totally breaks the compiler's ability to prune types etc -- read bigger code.

Okay, so maybe you are willing to tolerate that or we can design some control levers to deal with it.  The next problem to consider is that int[], int[][], and int[][][] are all assignable to Object.  This means that having Object also implies an unbounded set of array types.  Currently, the client side code cannot create array types on the fly so it cannot safely deal with this condition either.

--
Miguel

[Martin]

Thanks for yout reply, Miguel.

Now I understand that the only problem would be generated code size.
Therefore I'd like to have something to tell which concrete objects
can be contained in the object property as described in
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4
. I don't want to introduce new hacky-wrapper types for that. I'd like
to say that property "value" is for example of type Object which can
be only any of the primitive types, their object counterparts, String,
String[], Map<String, Object (which can contain again only list of
specified types)>.

Or even better, If I could specify eg. in Module.gwt.xml a list of all
types I really want to be serializable, when my property will be of
type Object (or Object collection). This would be wonderful superb.
Any chance to have something like this?

Thanks in advance.

[Jim]

I request this feature. During GWT compilation, when Object is found,
compiler looks for a concrete object through Module.gwt.xml. During
RPC, Object is really a concrete object instead of Object I am sure in
application. RPC can not serialize java.lang.Object. That is OK.
However, RPC power should not be restrained by looking at Java source
code.

On Aug 20, 9:18 am, Martin <m.zd...@gmail.com> wrote:
> Thanks for yout reply, Miguel.
>
> Now I understand that the only problem would be generated code size.
> Therefore I'd like to have something to tell which concrete objects

> can be contained in the object property as described inhttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...

[Sumit Chandel]

Whoops, the link I meant was:

http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4

Cheers,
-Sumit Chandel

On Fri, Aug 22, 2008 at 11:01 AM, Sumit Chandel <sumitc...@google.com> wrote:

Hey everyone,

So I'm not the GWT RPC expert, but this does sound like a workable idea. The place to keep discussing about this should now be on the GWT Contributors list that Martin pointed at (link below):

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8b2f2df7f9931504/936711ed3d20ea36

Cheers,
-Sumit Chandel

[Sumit Chandel]

Hey everyone,

So I'm not the GWT RPC expert, but this does sound like a workable idea. The place to keep discussing about this should now be on the GWT Contributors list that Martin pointed at (link below):

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8b2f2df7f9931504/936711ed3d20ea36

Cheers,
-Sumit Chandel

On Wed, Aug 20, 2008 at 6:51 AM, Jim <jim....@gmail.com> wrote: