The type must be known for instanced objects, not generic object
passing to methods.
In GWT, I can't do the following:
Object o = new Object ();
Instead, I can do this:
Object o = new ListBox (false); (altough I surely would typecast again
to ListBox so that I can do something with that object).

What is that thing about honoring JavaBean? :)

I don't know how, but we have solved the problem, but just by
coincidence. Up until now, I couldn't find a reasonable explanation
for what happened or what the problem was.

On Oct 3, 3:52 pm, "olivier nouguier" <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Since GWT 1.4, IsSerializable is not necessary, Serializable is enough.
>
> 1:) AFAIK the Type must be known at compile time so setObject(Object o) is
> out !
>      You should have a base Serializable class (know at compile time)
>
> 2:) The JavaBean contract must be honored : That getThat / setThat(That
> that).
>
>
>
> On Fri, Oct 3, 2008 at 1:07 PM, Alex D <[EMAIL PROTECTED]> wrote:
>
> > Hello everybody, I have encountered a very weird problem with shared
> > code between client and server.
>
> > The client is GWT compatible Java code and the server is pure Java.
>
> > We have created a serializable class, Request (public class Request
> > implements IsSerializable) which we want to use to exchange data
> > between client and server code. The class was included in the .rpc
> > file generated by the compiler, so it's indeed serializable. Moreover,
> > inside this class we have a method that sets the object for this
> > request; inside this method, an encoding protocol is obtained via
> > object's class name (if this is a list, we typecast it to List and get
> > the first element's class name - if the size is != 0). The code for
> > all protocols is compatible with GWT, since it compiles successfully,
> > the request object arrives at the servlet and the response back.
>
> > However, writing any of the following lines of code has no effect:
> > request.setObject (o)
> > or
> > request.getObject ()
>
> > It acts as if they don't exist, in either client/server code. I have
> > print-lined before and after the request in servlet, and all prints
> > BEFORE the request sets a list of objects work, BUT all after DON'T;
> > this would indicate that setting an object is a problem, BUT then, the
> > function exists successfully, since client code receives the request.
> > You would ask 'if you get a new request back, what's the problem?'
>
> > The problem is handling this request, since I have agents that handle
> > the object inside this request,
> > so ... request.getObject () - again, something breaks, because I used
> > Window.alert("...") just before getting the object and again one just
> > after. The second one doesn't get executed, but no errors, no
> > exceptions!!
>
> > I should mention that hosted mode works just fine and I am able to
> > display the object (so it's handled correctly).
>
> > Is there any problem if I use a shared package/classes (within same
> > project) for both client and server code? How would I detect this
> > problem since I don't get any errors?
>
> > Sorry for the long post, I hope you have the patience to read it :)
>
> --
> "Quand le dernier arbre sera abattu, la dernière rivière asséchée, le
> dernier poisson péché, l'homme va s'apercevoir que l'argent n'est pas
> comestible"
>      - proverbe indien Cri
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to