JRuby and Java serialization


#1

Hi,

I am trying to produce a small Ruby DSL above a Java library that
requires some objects to be Serializable.

However, I am facing problems when a JRuby class extends a Java
Serializable class.

For example:

#----

require ‘java’

class MyList < java.util.ArrayList
end

oos = java.io.ObjectOutputStream.new(java.lang.System.out)
oos.writeObject(MyList.new)

#----

Although ArrayList is Serializable, executing this little code fails
with :

java.io.NotSerializableException:
org.jruby.javasupport.proxy.JavaProxyConstructor$2 (NativeException)

I am using JRuby 1.1.6 (on Mac OS X jdk 1.6), but I have the same
exception using JRuby 1.2 RC1.

Does anyone have a clue about this ? Did I miss something ?

Thanks.


Greg


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#2

marabout wrote:

#----

Although ArrayList is Serializable, executing this little code fails with :

java.io.NotSerializableException: 

org.jruby.javasupport.proxy.JavaProxyConstructor$2 (NativeException)

Unfortunately this is not currently supported. In response to the Ruby
subclass of a Java class, we create a number of other structures used
for Ruby dispatching. And in general, this wouldn’t work even if those
structures weren’t present, since there’s going to be no way to identify
on the other side what actual class to use when deserializing. I think
your best bet would be to either create your own wrapper around
ArrayList that you can use inside Ruby, or reopen ArrayList to add some
utility methods.

This may work in the future when Java Integration gets its next
overhaul, since that should start to bring Ruby and Java types a bit
closer together.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

#3

Is there any way JRuby and Rails can leverage Jetty continuations for
Comet/long-polling type applications? One implementation I can think of
involves using different context roots for the Rails portion and the
Comet portion, but we’d lose out on access to Rails models.

For anyone that is curious: Jetty Continuations allow threads to be
suspended so that a client browser can open an XHR request and leave it
open until data returns without consuming a thread in its idle state:

http://ajaxian.com/archives/java-web-server-jetty-60-continuations-for-ajax-architectures

Ikai


#4

Hi Ikai. I know you posted this back in March, but thought I’d update
with
something I found recently. I just discovered the Atmosphere Framework
which is a portable ajax push/comet framework written in Java. One of
the
committers posted a tutorial on how to get this working on JRuby (
http://weblogs.java.net/blog/jfarcand/archive/2009/09/10/writing-comet-applications-using-jruby-and-atmosphere-framework
).

I’m trying it now. If it works… it looks like a promising solution
for
comet/long polling requirements on JRuby based apps.

Rich


#5

I found
http://www.igvita.com/2009/10/21/nginx-comet-low-latency-server-pushthe
other day.
Works like a charm.
Since I put nginx as frontend webserver anyway(load balancing, static
file
handling), this solution is great.
It has built-in (highly configurable) buffering (queue), so it can
handle
clients that get disconnected for a few minutes, and store messages they
missed.
It’s very easy to setup public listening channels, but it had a great
solution for private (per-user) updates too, without using some obscure
authentication mechanism.

Client requests some info that needs push-updates -> rails checks
permissions (by sessions) -> rails signals nginx to create a channel
(with a
one-time key url) -> rails responds to the client with the key-url ->
client
connects to nginx for long-poll.
Then every time you need to push something to a client (channel) you
just
post to the url.

Have fun with it.

Mathijs