íf (esse objeto é um objeto Java && dentro dele só tem objeto java)

Tenho um Objecto X serializável…

Preciso saber se X é um objeto da linguagem Java.

java.lang.String é da linguagem Java
com.smartjava.Sergio não é da lingaugem Java

Preciso saber também se dentro do objeto X há apenas objetos Java.

Pra que essa maluquice!?

Estou mandando objetos quaisquer para um servidor que vai me dar um ClassNotFoundException se o objeto não for conhecido. Logo só posso mandar os objetos da API do Java. Para os que não são eu faço um “pulo-do-gato”: serializo num byte array e mando esse byte array.

Alguém sabe como detectar isso eficientemente ??? Tem que usar reflection recursiva ??? :cry:

Eu tenho uma solução: colocar um boolean na função sendMessage. Se o programador colocar true é para serializar, se o programador colocar false pode mandar do jeito que está. hehehe

O objetivo é colocar o sistema para decidir isso pelo programador…

Fui dormir… bye !!!

bom, se a classe for da API do java ja é obvio q dentro dele so tem objetos da API oficial … entao teu unico problema é ver a classe em questao.

entrao, é so pegar o pacote: obj.getClass().getName() e ve se começa com java.algumacoisa ou javax.algumacoisa e tal…

Mas tem o caso de Arrays, que são objetos do Java e podem conter algum outro não Java.

Sem falar nas Collections !!!

A coisa é mais complicada do que parece…

Ideias:

  • Faca todos os seus objetos nao pertencentes a API implementarem uma “marker interface”, como “NotSerializable” - entao voce apenas verifica se a classe NAO implementa essa interface e boas.

  • Mande os dois (objeto e bytes). Se do outro lado lancar Exception voce usa os bytes.

uehuehueue… estranho isso que voce quer, ainda nao entendi o porque. :smiley:

Marcio Kuchma

saoj, já imagino seus objetivos.
Não é melhor fazer ao contrário? O cliente do servidor, ao se conectar, envia uma lista dos plugins instalados? Aí o server já sabe o que e como mandar os dados pros clientes.

Use um trap classloader.

[quote=danieldestro]saoj, já imagino seus objetivos.
Não é melhor fazer ao contrário? O cliente do servidor, ao se conectar, envia uma lista dos plugins instalados? Aí o server já sabe o que e como mandar os dados pros clientes.[/quote]

Eu pensei nisso, mas teria que ter toda uma complexidade para organizar isso. Toda vez que alguem conectasse teria que perguntar para o servidor quais classes (Messages) ele já tem e enviar para ele as que eles não tem, etc, etc, etc,

Tenho um servidor que faz apenas broadcast de objetos.


public class Message {
    private int id;
    private Object content;
}

No servidor:

Message msg = (Message) in.readObject();
broadcast(msg);

Então se vc colocar um objeto com.guj.MyObject dentro de content da Message, o servidor vai dar um ClassNotFoundException na hora do readObject()

Minha solução:

Se o objeto é não-Java, transforme o seu objeto num byte array e coloque esse byte array no content. Aí funciona sem problemas…

O problema é como saber se o Objeto é Java ou não…

Vou fazer a seguinte regra básica:

Se não começa com java, não é do Java.
Se é um Array e o primeiro elemento não é Java, então não é Java.
Se é um Collection ou Map pego o primeiro elemento e analiso…
Esse será o check padrão, mas o cara pode tb ativar a serializacao na mao com um parametro.

Como eu uso um ObjectInputStream + custom ClassLoader para resolver isso ???

Não dá pra vc usar o mesmo esquema que RMI usa para carregar no cliente as classes que ele não tem?

Que dá, dá, mas há um custo alto de complexidade.

Acho que uma solução simples vai resolver em 99% dos casos.

Para 1% o cara mete o parametro true e força a serialização.

classloader trap, voce usa um classloader que te acesso somente as libs básicas do sistema. Moral da historia, iniciando de dentro dele vc pode tentar serializar sem medo de serem classes desconhecidas dos clientes.

A técnica é semelhante a usada para o container deserializar objetos com o classloader de uma aplicacão.

[quote=louds]classloader trap, voce usa um classloader que te acesso somente as libs básicas do sistema. Moral da historia, iniciando de dentro dele vc pode tentar serializar sem medo de serem classes desconhecidas dos clientes.

A técnica é semelhante a usada para o container deserializar objetos com o classloader de uma aplicacão.[/quote]

Mas aí como o servidor vai deserializar um objeto que ele não conhece ?

Esse classloader que vc esta falando fica no cliente ou no servidor ?

Ele não vai, esse é o ponto.