-
1. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
wolfc May 16, 2008 11:01 AM (in response to adrian.brock)I agree, the test is wrong in the fact that it serializes a MC bean.
Yes there can be multiple kernels within one VM, that still does not preclude a serializable reference to one particular kernel.
In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus.
But I would still need a serializable kernel reference to be able to do that.
Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map? -
2. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
adrian.brock May 16, 2008 11:23 AM (in response to adrian.brock)"wolfc" wrote:
In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus.
But I would still need a serializable kernel reference to be able to do that.
Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map?
Because people will (ab)use it (see Al's post in the MC forum).
I don't understand why you need to "serialize" a reference to the KernelBus
so I can't explain what you are doing wrong.
One of my laws of programming/debugging;
"Don't confuse the user's chosen solution with the problem" -
3. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
wolfc May 20, 2008 7:50 AM (in response to adrian.brock)The use case is using a MC bean from a registry which is by nature not MC aware. For example JNDI and Remoting (ServerInvocationHandler).
Other use cases are passivation of objects which might contain references to MC beans. For example I might have a reference to a MC bean in a web session.
(I think this translates to being able to have a serialized reference to a MC bean itself. But to facilitate that the MC bean would need a serialized reference to the Kernel.) -
4. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
adrian.brock May 20, 2008 10:45 AM (in response to adrian.brock)"wolfc" wrote:
(I think this translates to being able to have a serialized reference to a MC bean itself. But to facilitate that the MC bean would need a serialized reference to the Kernel.)
No, that's the wrong place like I said above.
If the problem is passivation then it is the job of the container to remove implementation
details that are not serializable and re-instate them later. i.e. its EJB3's job
Equally, you can't put non-serializable stuff in a web session and expect it to be serializable
without extra work.
I don't see what the issue is really.
These must be internal implementation details so you know how to implement
this "externalization", you're just being lazy. i.e. you're expecting the MC
to do something that is not its job and will likely lead to other problems
when others don't want, expect this behaviour or want to do something else.
DON'T MIX IMPLEMENTATION AND POLICY