Thanks for your advice. I have took a closer look at the project at IBM
Research but it is quite cumbersome because their implementation is strictly
tied with the IBM specific OSGi implementation. It is not flexibel at all to be
used in a heterogenous computing environment.
>From your point of view, approach to extracting execution states a single OSGi
>components, for a sake of simplicity let's assumed that this componenent does
>not access any external OSGi service, is completely different from normal
>Java object, isn't it?
Would anyone tell me how we can use a callback mechanism provided by other
built-in OSGi services similar to the way provided by Configuration Admin
Service for class that implemements ManagedService interface?
Regards,
Vu.
BJ Hargrave <[EMAIL PROTECTED]> wrote: 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
Sent by: [EMAIL PROTECTED]
03/14/2007 08:55 AM
Please respond to
OSGi Developer Mail List
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
---------------------------------
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta._______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
