alternative to local SLSB ejb

[fuzebest]

Sorry for bothering you again, but neither forum, not google search reveal any crear answer.

Is there alternative to local slsb. Namely:
- client and server are in the same jvm
- separate client-server classloaders (only service interface is shared)
- pass by reference not value (or very high performance pass-by-value)
- no any context propagation required
-(optionaly) service link reference refresh

Please, any idea!

Thank you!

[Andreas Senft]

If the client and server are in the same VM: Why bothering with a remoting layer? Just use a POJO directly (via interface).

Regards,
Andreas

[fuzebest]

direct method call is not an option, since i need decouple client and server code (place in different classloaders).
I'm looking not for remoting layer, but for kind of "separation" layer - share service interface, not implementation

[Andreas Senft]

Well, in order to bridge classloaders you need either remoting or serialization.
For the remoting options have a look at Springs RMI invoker support.
Why do you need different classloaders in the first place?

Regards,
Andreas

[fuzebest]

Yes, serialization is the option if there are not way to use local ejb like pass-by-reference.
Rmi invoker is not performant enough (actually i use this way right not and suffer great performance degration).

The main reason to to separate client from server are custom aspectj aspects that intercept with each other (yes, i can carefully review all aspects and remove all problems, but not sure if this is possible)
Another reason - similary named classes in client and server layers, but having different content (e.g - User (id, login,password) in client, User (id, account) in server), and obviously i do not want them intercept either

[Andreas Senft]

Did you try another another remoting protocol like http-invoker? Not sure about how performance relates to RMI but possibly it is faster.

Regards,
Andreas

[fuzebest]

Yes, spring http-invoker. Unfortunately the performance is getting worse.
caucho protocols and ws were not considered since i do not belive they outperform httpinvoker

[Andreas Senft]

Then I have currently no further idea except serialization...

[fuzebest]

yes, it seems the only solution for now. But HOW i can expose service, and access it?

[Andreas Senft]

Hmm. Good question.
Maybe you could have an "exporter" bean that serializes an object and places the byte array in a ThreadLocal and an accessing factory bean that takes the byte array and deserializes it.
Of course the classes have to be accessible for deserialization. Could that be a problem in your scenario?

Regards,
Andreas