[jboss-dev-forums] [Design of POJO Server] - JBMICROCONT-288 - Invalid feature request and invalid protoc

[adrian@jboss.org]

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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151436#4151436

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151436