ibiblio for jboss serialization

[dennisbyrne]

Some of the Apache MyFaces devs are debating over whether we can sneak this product into a "special" release for our BOF talk at J1. We recently moved to maven 2, and it would make things real easy if this were in ibiblio. What do ya say?

[clebert.suconic]

whether we can sneak this product into a "special" release for our BOF

Of course I can help, let me know what you would need.
But what you meant by "special" release?

about the maven 2 and ibiblio, I could add it to ibiblio, I don't think there is a problem.
Although I don't know how to submit a file yet, I will look how to do it. But if you (or anyone) have any URLs, it would help :-)

[starksm64]

http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

[dennisbyrne]

Hello Clebert,

The JSF spec requires (de)serialization for a *lot* of instances on each request. Jboss serialization for better IMO. By "some", I mean that you now know more about this now than many of them because me and a few others have not raised this on the mailing list yet. Should be an easy vote though.

"Special" has to do w/ the fact that any JSF 1.1 impl has to be 1.3 compliant, so we can't just compile it in there and release it. But I imagine there are lots of folks using 1.4+ who want more performance and who don't care as long as it is an official release from a "name you can trust", at least that's the kind of place I work in.

BTW, do you know why I wasn't notified of your reply? Is this forum like Hibernate's?

[clebert.suconic]

There isn't much I can do for JDK 1.3. I looked for hooks on changing final fields or creating instances using ghost contructors and I didn't find any. It would be too costly.

It would be possible but it would require native code. (The same way as JavaSerialization is native code on JDK 1.3). Assuming the risk on supporting native code with this would be pretty risky.

I think you should play with interfaces, and have an interface called PluggableSerialization.

 public interface PluggableSerialization
 {
 public ObjectInputStream createInputStream(InputStream input, ClassLoader sourceClassLoader);
 public ObjectOutputStream createOutputStream(OutputStream output);
 public IMarshalledValue createMarshalledValue (Object source);
 }

JBossRemoting has implemented the concept of PluggableSerialization, then we can configure what serialization you want to use:

http://fisheye.jboss.org/viewrep/JBoss/JBossRemoting/src/main/org/jboss/remoting/serialization


There are two advantages here:

I - Low coupling
II - It is compatible with JDK 1.3.

As for you not being notified, you can go to Watched Forums and subscribe this forum, than you would be notified.

http://www.jboss.com/index.html?module=bb&op=forum_watches

[clebert.suconic]

Also,

I will be releasing jboss-serialization final this or next week (for sure).

I will post it on iBiblio after that.

[dennisbyrne]

Excellent, your release is right on time. We haven't branched for a JSF 1.2 imlp yet but in the meantime, I'll try your interface idea as well as a dynamic class loading idea of mine as well.

I am getting the notifications now because I clicked on "Watch this topic".

Also, I am not a maven genius, but I think your binary just has to be here

http://www.ibiblio.org/maven2/jboss/

I also should learn more about the licensing issues, but I don't think there are problems as long as apache doesn't actually distribute the LGPL binary artifact ?

Don't worry about 1.3 compatibility, I kinda thought that would be too much ;)

[clebert.suconic]

I also should learn more about the licensing issues, but I don't think there are problems as long as apache doesn't actually distribute the LGPL binary artifact ?

Just an idea... Maybe we could have an implementation of your interface living on jboss-serialization.jar (or some other jar likst jboss-serializarion-myfaces.jar). or something like that.

This way you won't need even to worry about these licensing problems.


Well, as I said, this is just an idea.

[dennisbyrne]

Hi Clebert,

I looked into the legal issues and I am afraid the two licenses are simply incompatible ;( I'm just going to go with a factory patern similar to what you have suggested in this topic.

public class MyCustomSerialFactory implements SerialFactory{

 public ObjectInputStream getObjectInputStream(InputStream stream){
 return new JbossObjectInputStream(stream);
 }

 public ObjectOutputStream getObjectOutputStream(OutputStream stream){
 return new JbossObjectOutputStream(stream);
 }

}

There is less ooh and ahh but it is still a small amount of work to use such a superior solution. Good job on this project.

[dennisbyrne]

http://wiki.apache.org/myfaces/Performance#clientSide

[clebert.suconic]

Thanks...

There is only one problem,

I'm not using resolveClass at this moment.

One of the parameters you can have on JBossObjectInputStream's constructor is the classLoader is going to be used.

If you think this is important, I can add the feature.

I can test your code if I have to make the change.

[clebert.suconic]

Scratch that...

I'm implementing resolveClass, so... nothing to change here.

It will be available in 1.0.GA this week.

[dennisbyrne]

Ah ... MyFaces has to implement resolveClass() because out ClassUtils.classForName first tries Thread.currentThread().getContextClassLoader() and then ClassUtils.class.getClassLoader() . This allows a JSF application to dynamically instantiate from both isolation boundaries.

I don't think you have to implement this for us, but you might want to for other reasons.

[clebert.suconic]

done:

http://jira.jboss.org/jira/browse/JBSER-72