JBMICROCONT-288 - Invalid feature request and invalid protoc

[adrian.brock]

PROTOCOL

I don't know how you manage your projects, but in mine
things get discussed and decided on BEFORE JIRA issues get raised.
That way we can decide what is the best way to implement it (if it all)
and which project it should be in.

We certainly don't break the build with bogus tests that fail
especially when there is no way we are going support the feature
because it doesn't make sense.

DO ONE THING WELL

Basic facts:
* The Microcontaner kernel is NOT serializable.
* There can be many kernels liviing in the same JVM at the same time.
* The MC couldn't care less about serialization, it isn't its job.
* Serialization is not injection

To make JBMICROCONT-288 work (which it can't do in general)
would require two processes.
1) Some mechanism to regain the reference to the relevant MC kernel
instance. i.e. probably some singleton mechanism or in general something
more complicated
2) A hook to (re)inject references during deserialization

This cannot work in general
* As above, how do you know which kernel to use? In the appserver
there's certainly a singleton you access by doing ServiceController.getKernel();
but that is a property of the host environment not a feature of the MC.
* After deserialization you have two instances of the same bean.
One registered and managed with the MC, the other not.
Deserialization creates a whole new object
* Beans will do things with the objects injected, e.g. register themselves in the injected object

public void setRegistry(Registry registry)
{
 this.registry = registry;
}

public void create()
{
 registry.register(this);
}

In general they can do arbitrary things which would mean serialization/deserialzation
would have to invoke the entire lifecyle. i.e. it would become like ejb passivation
Which almost certainly isn't what you want. You don't want the service
torn down because somebody wants to serailze the state.
It's ok to do that for pooled EJB instances, but not for singleton services.

My conclusion from this request would be;
YOU'RE DOING SOMETHING WRONG
What that is depends upon what your real feature request/requirements are,
rather than what you wrongly think they are in JBMICROCONT-288

[wolfc]

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?

[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"

[wolfc]

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.)

[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