In general what you propose is almost impossible given the highly connected nature of OSGi bundles. If the model was siloed model (e.g. bundle A and bundle B cannot access each other's classes and call each other), then you might have a chance of freeze drying a bundle and thawing it out on another VM. But with OSGi, the graph of interconnected bundles can be quite large.
You may also want to look at http://www.alphaworks.ibm.com/tech/resmf BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Duc Lam Vu <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/14/2007 08:55 AM Please respond to OSGi Developer Mail List <[email protected]> To [email protected] cc Subject [osgi-dev] Ability to support strong migration of OSGi component? 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 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
