Non-Netty client - Any help please, nearly there!

[Trustin Lee]

Hi, 

Sorry for a belated resolution, but I found a major bug in
ObjectDecoderInputStream, and it's fixed now.  Please check out the latest
revision from the trunk and give it a try:

  * https://jira.jboss.org/jira/browse/NETTY-101

BTW, I had to change the hard coded constant '300' to '196' to make the
application work.  Perhaps hard-coding the expected number of bytes is not a
good idea?

HTH,
Trustin


skhalid wrote:
> 
> Hi Trustin,
> 
> Apologies for the delay in getting back to you - we need to get this
> resolved as soon as possible for our project delivery. Thanks for
> resolving the mystery of the magic header not coming in due to
> compatibleencoder just sending it once - that's probably the issue. We are
> dropping serialization/object communications support in favour of
> JSON/String based communications because it is more compact as compared to
> binary/serialized bytes (also since Android has it's own jvm called
> dalvik, objects serialised in that environment may/may not deserialise
> properly in another environment). But just to continue problem resolution
> of the serialisation stuff:
> 
> We've now changed the code to :
> 
> 
> ByteArrayInputStream bais = new ByteArrayInputStream(ary);
>         ObjectDecoderInputStream ois = new ObjectDecoderInputStream(bais);
>         User c = null;
>         try {
> 			Object myObject = ois.readObject();
> 			System.out.println("Object of class is " +
> myObject.getClass().toString());
> 			c = (User)myObject;
> 		} catch (ClassNotFoundException e) {
> 			e.printStackTrace();
> 		}
> 
> 
> 
> And also used the ObjectEncoder/ObjectDecoder on server - but here is what
> we are getting now in client :
> 
> Exception in thread "main" java.io.StreamCorruptedException: Unsupported
> version: 0
> 	at
> org.jboss.netty.handler.codec.serialization.CompactObjectInputStream.readStreamHeader(CompactObjectInputStream.java:57)
> 
> Have no idea why this is occurring...
> 
> 
> 
> The reason we can't use Netty classes (or more importantly, the Netty
> Client code)  is because the dalvik jvm does not fully support all JDK
> classes/packages - so far we've discovered the java.lang.management.*
> package. We can't proceed beyond the point where the netty client code in
> Android tries to reference the TimeBasedUuidGenerator class/creation.
> There *might* be other classes not working with Android, but we need a
> solution on how to avoid the problem in TimeBasedUuidGenerator (maybe
> somehow provide another version of TimeBasedUuidGenerator - so this is not
> essentially recompiling, but extending/adding more code at runtime). For a
> list of what is available in android jvm:
> 
> http://code.google.com/android/reference/
> 
> http://code.google.com/android/reference/packages.html
> 
> http://code.google.com/android/reference/classes.html
> 
> 


-----
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
-- 
View this message in context: http://n2.nabble.com/Non-Netty-client-tp1771503p2115980.html
Sent from the Netty User Group mailing list archive at Nabble.com.