[Design of POJO Server] - JBMICROCONT-288 - Invalid feature request and invalid protoc
by 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
17 years, 10 months
[Design the new POJO MicroContainer] - Re: Classloading and versioning
by adrian@jboss.org
"alesj" wrote :
| Even if it would, why would that be a problem?
| Shouldn't there be a way to tell that in-bundle usage is a black box, and scott's usage of ales is impl detail.
|
| Would then there be a way to get runtime CCE if something ales's was exposed through scott and used in foobar?
| Or how do you detect this at deployment, exposing the possible conflict?
The way to tell the classloader that they are shared and could conflict is by
expressing the export. Once the package is exported anything that imports it
could load it.
Think about it...
foo imports ales from acme1
foo imports scott from acme2
but acme1 also exports scott and acme2 exports ales
The classloader can't make the assumptions you are trying to make.
it doesn't know that ales and scott won't leak across the two different
deployments.
They are exported so it must assume that they will since importers
must need the classes for a reason.
If they are not exported, there's no consistency check required.
The modules are assume to only use the classes as private implementation detail.
Even if they were the same physical classes on disk (and defined as the same
version) you'd get a CCE since the classes are loaded by different classloaders.
The fundamental problem is caused by an incorrect modularisation.
You want to version ales and scott independently so foo
can choose them independently. But you've tied them into
the same bundle making this impossible.
There be no problem if there was an
acme1-ales:1.0.0
acme1-scott:1.0.0
acme2-ales:3.0.0
acme2-scott:4.0.0
foo could then choose acme1-ales:1.0.0 and acme1-scott-4.0.0
as long as acme1-scott-4.0.0 doesn't need to make an incompatible
decision on what version of ales to use (and vice versa).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151322#4151322
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4151322
17 years, 10 months