Dear all,
I would like to consult you all about the correctness and completeness of my
arguments about concept of supporting strong migration of OSGi bundles. Strong
migration can be understood as we migrate not only code segments, states(like
private datas, references) but also execution states(program pointer, frame
stack,...). In my point of view, we can not support strong migration of OSGi
bundles based on the existing well-known following techniques: instrumenting
source code of Java objects with preprocessor, modification of JVM in order to
capture whole JVM stacks,..., or , JIT recompilation, or Byte-Code
instrumentation. Because OSGi orginally targetted for embebbed devices,
therefore Byte-Code Instrumentation is the most appropriate approach to obtain
strong migration of OSGi bundles. However, we can obviously see that in OSGi
environment, OSGi services can be used by another services, therefore, capture
execution states of OSGi bundle not only regarding its own execution
states but also execution states of other used OSGi services and I believe
that it is absolutely impossible. Is it right? Another aspects is that we move
OSGi bundles to remote target host, OSGi bundle will be restarted to run again
by OSGi environement by invoking Start(Bundlecontext...) function and
intituively, OSGi bundles will loss all its states. Even assumed that we can
capture execution states of OSGi bundle previously in the most simplest case
that OSGi bundle contain only one OSGi service and this OSGi service not using
any other external services, we have no way to rerun OSGi service from the
suspended point of its execution flow due to the start(Bundlecontext...) must
be called. Authors of project Javaflow claimed that he already succesfully
implemented an Java Mobile Agent infrastructure that support strong migration
of Java agents thanks to Continuation concept. The authors basically use
techniques of Byte-code instrumention in order to capture/reinstantiate
execution states of Java objects. They instrument byte-code statically by
using the Ant Javaflow Task or dynamically by using JavaFlow's
ContinuationClassloader. The syntax can be described:ContinuationClassLoader
classLoader = new ContinuationClassLoader (new URL[]{url},
ClassLoader.getSystemClassLoader());
I do believe that OSGi Classloader(even with R4) is not a subclass of
ContinuationClassloader or URLClassloader, therefore it is impossible to get
class loaded in OSGi enviroment using any particular Classloading mechanism.
Am I right?
I highly appreciate any other arguements or advices to show me that my
arguements is still not correct and incomplete since we can apply some other
approaches in order to acquire strong migration of OSGi component. Many thanks
in advance.
Kind Regards,
Vu.
instru
2
---------------------------------
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
