Re: Problem when exporting system packages from Android to bundles
This could have something to do with the way you instantiate your framework, _or_ with the way your bundle is packaged. Could you post (a) your framework instantiation code, and (b) the manifest of your bundle? Angelo On Apr 2, 2012, at 10:18 AM, M. van Ree wrote: Hello all, I have a problem when trying to make the Android lib available to my OSGi bundles. The error I'm getting is: 04-02 08:03:00.351: W/dalvikvm(18531): Method mismatch: onDraw in Lcom/osgi/integration/drawbundle/DrawView; (cl=0x4067bb40) and super Landroid/view/View; (cl=0x0) 04-02 08:03:00.391: W/System.err(18531): Caused by: java.lang.LinkageError: Classes resolve differently in superclass Off course I can see the cl=0x0, so that must be the culprit, but I have no idea on how to get it fixed... I'm exporting the packages as following in a properties class: private static final String ANDROID_PACKAGES_FOR_EXPORT = (android; + android.app; + android.content; + android.database; + etc. etc. ); I'm really drawing a blank here on what could be wrong, I would expect to receive an error on exporting/importing something empty that would point me in the right direction, but it doesn't seem to be the case. Who can tell me what I'm doing wrong here? Regards, Maurice - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Problem when exporting system packages from Android to bundles
Hello Angelo,
Thank you for your fast response!
Here is some more info:
a:
public FelixManager(String rootPath)
{
this.rootPath = rootPath;
felixProperties = new FelixProperties(this.rootPath);
bundlesDir = new File(rootPath+/felix/bundle);
if (!bundlesDir.exists()) {
if (!bundlesDir.mkdirs()) {
throw new IllegalStateException(Unable to create bundles dir);
}
}
cacheDir = new File(rootPath+/felix/cache);
if (!cacheDir.exists()) {
if (!cacheDir.mkdirs()) {
throw new IllegalStateException(Unable to create felixcache dir);
}
}
try
{
felix = new Felix(felixProperties);
felix.start();
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
The felix properties are defined as following:
private String m_felixAbsolutePath;
public FelixProperties(String rootpath)
{
m_felixAbsolutePath = rootpath;
put(org.osgi.framework.storage, m_felixAbsolutePath+/felix/cache);
put(felix.cache.rootdir,m_felixAbsolutePath+/felix);
put(felix.log.level, 4);
put(felix.startlevel.bundle, 1);
put(org.osgi.framework.system.packages.extra,
ANDROID_PACKAGES_FOR_EXPORT);
}
private final String ANDROID_PACKAGES_FOR_EXPORT=
android; +
android.app; +
android.content; +
android.database; + etc. etc.
and b:
Manifest-Version: 1.0
Bundle-Name: drawbundle
Bundle-Activator: com.osgi.integration.drawbundle.Activator
Bundle-SymbolicName: com.osgi.integration.drawbundle
Bundle-Version: 0.0.1
Import-Package: org.osgi.framework,
DynamicImport-Package: android.*
I first, to no avail, tried including the Android packages manually in the
Import-Package statement, like so:
Import-Package: org.osgi.framework,
android.view.LayoutInflater,
android.view.View,
android.widget.LinearLayout,
android.app.Activity,
android.app.TextView
I've also tried including the Android jarfile in another bundle, and
exporting the packages from there, and then importing that bundle in the
above manifest.
Maurice
On Mon, Apr 2, 2012 at 10:39 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
This could have something to do with the way you instantiate your
framework, _or_ with the way your bundle is packaged.
Could you post (a) your framework instantiation code, and (b) the manifest
of your bundle?
Angelo
On Apr 2, 2012, at 10:18 AM, M. van Ree wrote:
Hello all,
I have a problem when trying to make the Android lib available to my OSGi
bundles.
The error I'm getting is:
04-02 08:03:00.351: W/dalvikvm(18531): Method mismatch: onDraw in
Lcom/osgi/integration/drawbundle/DrawView; (cl=0x4067bb40) and super
Landroid/view/View; (cl=0x0)
04-02 08:03:00.391: W/System.err(18531): Caused by:
java.lang.LinkageError:
Classes resolve differently in superclass
Off course I can see the cl=0x0, so that must be the culprit, but I have
no
idea on how to get it fixed...
I'm exporting the packages as following in a properties class:
private static final String ANDROID_PACKAGES_FOR_EXPORT =
(android; +
android.app; +
android.content; +
android.database; +
etc. etc. );
I'm really drawing a blank here on what could be wrong, I would expect to
receive an error on exporting/importing something empty that would point
me
in the right direction, but it doesn't seem to be the case.
Who can tell me what I'm doing wrong here?
Regards,
Maurice
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Met vriendelijke groet,
Maurice van Ree
Re: Problem when exporting system packages from Android to bundles
Right.
I'm not entirely sure what's up, but some things come to mind,
- in stead of building the manifest by hand, you should consider using
something like BND (perhaps with BNDTools, if you're an Eclipse user) to handle
that for you. If you don't need to use DynamicImport, stick with 'regular'
imports: that way, the framework can inform you better about what's wrong.
- your bundle should have a Bundle-ManifestVersion: 2 to state that it is an
R4 bundle (again, BND will do that for you).
- your Import-Package statement seems to have a comma after org.osgi.framework
. I'm not sure whether that is a copy-paste error, or whether it is actually
relevant. (insert-bnd-notice/)
- what tools do you use for building your project? Is it possible that the
Android API ends up _inside_ your bundle?
Angelo
On Apr 2, 2012, at 10:59 AM, M. van Ree wrote:
Hello Angelo,
Thank you for your fast response!
Here is some more info:
a:
public FelixManager(String rootPath)
{
this.rootPath = rootPath;
felixProperties = new FelixProperties(this.rootPath);
bundlesDir = new File(rootPath+/felix/bundle);
if (!bundlesDir.exists()) {
if (!bundlesDir.mkdirs()) {
throw new IllegalStateException(Unable to create bundles dir);
}
}
cacheDir = new File(rootPath+/felix/cache);
if (!cacheDir.exists()) {
if (!cacheDir.mkdirs()) {
throw new IllegalStateException(Unable to create felixcache dir);
}
}
try
{
felix = new Felix(felixProperties);
felix.start();
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
The felix properties are defined as following:
private String m_felixAbsolutePath;
public FelixProperties(String rootpath)
{
m_felixAbsolutePath = rootpath;
put(org.osgi.framework.storage, m_felixAbsolutePath+/felix/cache);
put(felix.cache.rootdir,m_felixAbsolutePath+/felix);
put(felix.log.level, 4);
put(felix.startlevel.bundle, 1);
put(org.osgi.framework.system.packages.extra,
ANDROID_PACKAGES_FOR_EXPORT);
}
private final String ANDROID_PACKAGES_FOR_EXPORT=
android; +
android.app; +
android.content; +
android.database; + etc. etc.
and b:
Manifest-Version: 1.0
Bundle-Name: drawbundle
Bundle-Activator: com.osgi.integration.drawbundle.Activator
Bundle-SymbolicName: com.osgi.integration.drawbundle
Bundle-Version: 0.0.1
Import-Package: org.osgi.framework,
DynamicImport-Package: android.*
I first, to no avail, tried including the Android packages manually in the
Import-Package statement, like so:
Import-Package: org.osgi.framework,
android.view.LayoutInflater,
android.view.View,
android.widget.LinearLayout,
android.app.Activity,
android.app.TextView
I've also tried including the Android jarfile in another bundle, and
exporting the packages from there, and then importing that bundle in the
above manifest.
Maurice
On Mon, Apr 2, 2012 at 10:39 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
This could have something to do with the way you instantiate your
framework, _or_ with the way your bundle is packaged.
Could you post (a) your framework instantiation code, and (b) the manifest
of your bundle?
Angelo
On Apr 2, 2012, at 10:18 AM, M. van Ree wrote:
Hello all,
I have a problem when trying to make the Android lib available to my OSGi
bundles.
The error I'm getting is:
04-02 08:03:00.351: W/dalvikvm(18531): Method mismatch: onDraw in
Lcom/osgi/integration/drawbundle/DrawView; (cl=0x4067bb40) and super
Landroid/view/View; (cl=0x0)
04-02 08:03:00.391: W/System.err(18531): Caused by:
java.lang.LinkageError:
Classes resolve differently in superclass
Off course I can see the cl=0x0, so that must be the culprit, but I have
no
idea on how to get it fixed...
I'm exporting the packages as following in a properties class:
private static final String ANDROID_PACKAGES_FOR_EXPORT =
(android; +
android.app; +
android.content; +
android.database; +
etc. etc. );
I'm really drawing a blank here on what could be wrong, I would expect to
receive an error on exporting/importing something empty that would point
me
in the right direction, but it doesn't seem to be the case.
Who can tell me what I'm doing wrong here?
Regards,
Maurice
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Met vriendelijke groet,
Maurice van Ree
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Problem when exporting system packages from Android to bundles
I was considering the use of BNDTools indeed, and will look into that for
sure now.
I didn't know about the Bundle-ManifestVersion, will look into that too!
The comma is indeed a copy-paste error, as you can see in the bottom import
statement, I closed the last one without a comma. But, sharp to notice!
As far as tools go, I'm just using Eclipse Indigo and the latest Android
SDK, dexing and packaging jars with the tools (dx and aapt) from the SDK.
When opening the bundle jarfile, the API isn't in there, I don't know what
happens after installing and starting the bundle on Felix though...I can
actually install a bundle and print something to the console or use Log.d
to show a message in Logcat, so the bundle (without using Android
libraries) does seem to be packaged in the right way I guess?
I'll report back here how things work out after trying BNDTools.
Maurice
On Mon, Apr 2, 2012 at 11:18 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
Right.
I'm not entirely sure what's up, but some things come to mind,
- in stead of building the manifest by hand, you should consider using
something like BND (perhaps with BNDTools, if you're an Eclipse user) to
handle that for you. If you don't need to use DynamicImport, stick with
'regular' imports: that way, the framework can inform you better about
what's wrong.
- your bundle should have a Bundle-ManifestVersion: 2 to state that it
is an R4 bundle (again, BND will do that for you).
- your Import-Package statement seems to have a comma after
org.osgi.framework . I'm not sure whether that is a copy-paste error, or
whether it is actually relevant. (insert-bnd-notice/)
- what tools do you use for building your project? Is it possible that the
Android API ends up _inside_ your bundle?
Angelo
On Apr 2, 2012, at 10:59 AM, M. van Ree wrote:
Hello Angelo,
Thank you for your fast response!
Here is some more info:
a:
public FelixManager(String rootPath)
{
this.rootPath = rootPath;
felixProperties = new FelixProperties(this.rootPath);
bundlesDir = new File(rootPath+/felix/bundle);
if (!bundlesDir.exists()) {
if (!bundlesDir.mkdirs()) {
throw new IllegalStateException(Unable to create bundles dir);
}
}
cacheDir = new File(rootPath+/felix/cache);
if (!cacheDir.exists()) {
if (!cacheDir.mkdirs()) {
throw new IllegalStateException(Unable to create felixcache
dir);
}
}
try
{
felix = new Felix(felixProperties);
felix.start();
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
The felix properties are defined as following:
private String m_felixAbsolutePath;
public FelixProperties(String rootpath)
{
m_felixAbsolutePath = rootpath;
put(org.osgi.framework.storage, m_felixAbsolutePath+/felix/cache);
put(felix.cache.rootdir,m_felixAbsolutePath+/felix);
put(felix.log.level, 4);
put(felix.startlevel.bundle, 1);
put(org.osgi.framework.system.packages.extra,
ANDROID_PACKAGES_FOR_EXPORT);
}
private final String ANDROID_PACKAGES_FOR_EXPORT=
android; +
android.app; +
android.content; +
android.database; + etc. etc.
and b:
Manifest-Version: 1.0
Bundle-Name: drawbundle
Bundle-Activator: com.osgi.integration.drawbundle.Activator
Bundle-SymbolicName: com.osgi.integration.drawbundle
Bundle-Version: 0.0.1
Import-Package: org.osgi.framework,
DynamicImport-Package: android.*
I first, to no avail, tried including the Android packages manually in
the
Import-Package statement, like so:
Import-Package: org.osgi.framework,
android.view.LayoutInflater,
android.view.View,
android.widget.LinearLayout,
android.app.Activity,
android.app.TextView
I've also tried including the Android jarfile in another bundle, and
exporting the packages from there, and then importing that bundle in the
above manifest.
Maurice
On Mon, Apr 2, 2012 at 10:39 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
This could have something to do with the way you instantiate your
framework, _or_ with the way your bundle is packaged.
Could you post (a) your framework instantiation code, and (b) the
manifest
of your bundle?
Angelo
On Apr 2, 2012, at 10:18 AM, M. van Ree wrote:
Hello all,
I have a problem when trying to make the Android lib available to my
OSGi
bundles.
The error I'm getting is:
04-02 08:03:00.351: W/dalvikvm(18531): Method mismatch: onDraw in
Lcom/osgi/integration/drawbundle/DrawView; (cl=0x4067bb40) and super
Landroid/view/View; (cl=0x0)
04-02 08:03:00.391: W/System.err(18531): Caused by:
java.lang.LinkageError:
Classes resolve differently in superclass
Off course I can see the cl=0x0, so that must be the culprit, but I
have
no
idea on how to get it fixed...
Re: Problem when exporting system packages from Android to bundles
Hi Maurice,
See inline.
On Apr 2, 2012, at 11:51 AM, M. van Ree wrote:
I was considering the use of BNDTools indeed, and will look into that for
sure now.
I didn't know about the Bundle-ManifestVersion, will look into that too!
The comma is indeed a copy-paste error, as you can see in the bottom import
statement, I closed the last one without a comma. But, sharp to notice!
Well, it's important to have a good view of what actually is going on in your
code (it could be a simple typo).
As far as tools go, I'm just using Eclipse Indigo and the latest Android
SDK, dexing and packaging jars with the tools (dx and aapt) from the SDK.
When opening the bundle jarfile, the API isn't in there, I don't know what
happens after installing and starting the bundle on Felix though...I can
actually install a bundle and print something to the console or use Log.d
to show a message in Logcat, so the bundle (without using Android
libraries) does seem to be packaged in the right way I guess?
You can use dexdump to inspect the (dalvik-)contents of a bundle.
I'll report back here how things work out after trying BNDTools.
Good luck!
Maurice
Angelo
On Mon, Apr 2, 2012 at 11:18 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
Right.
I'm not entirely sure what's up, but some things come to mind,
- in stead of building the manifest by hand, you should consider using
something like BND (perhaps with BNDTools, if you're an Eclipse user) to
handle that for you. If you don't need to use DynamicImport, stick with
'regular' imports: that way, the framework can inform you better about
what's wrong.
- your bundle should have a Bundle-ManifestVersion: 2 to state that it
is an R4 bundle (again, BND will do that for you).
- your Import-Package statement seems to have a comma after
org.osgi.framework . I'm not sure whether that is a copy-paste error, or
whether it is actually relevant. (insert-bnd-notice/)
- what tools do you use for building your project? Is it possible that the
Android API ends up _inside_ your bundle?
Angelo
On Apr 2, 2012, at 10:59 AM, M. van Ree wrote:
Hello Angelo,
Thank you for your fast response!
Here is some more info:
a:
public FelixManager(String rootPath)
{
this.rootPath = rootPath;
felixProperties = new FelixProperties(this.rootPath);
bundlesDir = new File(rootPath+/felix/bundle);
if (!bundlesDir.exists()) {
if (!bundlesDir.mkdirs()) {
throw new IllegalStateException(Unable to create bundles dir);
}
}
cacheDir = new File(rootPath+/felix/cache);
if (!cacheDir.exists()) {
if (!cacheDir.mkdirs()) {
throw new IllegalStateException(Unable to create felixcache
dir);
}
}
try
{
felix = new Felix(felixProperties);
felix.start();
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
The felix properties are defined as following:
private String m_felixAbsolutePath;
public FelixProperties(String rootpath)
{
m_felixAbsolutePath = rootpath;
put(org.osgi.framework.storage, m_felixAbsolutePath+/felix/cache);
put(felix.cache.rootdir,m_felixAbsolutePath+/felix);
put(felix.log.level, 4);
put(felix.startlevel.bundle, 1);
put(org.osgi.framework.system.packages.extra,
ANDROID_PACKAGES_FOR_EXPORT);
}
private final String ANDROID_PACKAGES_FOR_EXPORT=
android; +
android.app; +
android.content; +
android.database; + etc. etc.
and b:
Manifest-Version: 1.0
Bundle-Name: drawbundle
Bundle-Activator: com.osgi.integration.drawbundle.Activator
Bundle-SymbolicName: com.osgi.integration.drawbundle
Bundle-Version: 0.0.1
Import-Package: org.osgi.framework,
DynamicImport-Package: android.*
I first, to no avail, tried including the Android packages manually in
the
Import-Package statement, like so:
Import-Package: org.osgi.framework,
android.view.LayoutInflater,
android.view.View,
android.widget.LinearLayout,
android.app.Activity,
android.app.TextView
I've also tried including the Android jarfile in another bundle, and
exporting the packages from there, and then importing that bundle in the
above manifest.
Maurice
On Mon, Apr 2, 2012 at 10:39 AM, Angelo van der Sijpt
angelo.vandersi...@luminis.eu wrote:
This could have something to do with the way you instantiate your
framework, _or_ with the way your bundle is packaged.
Could you post (a) your framework instantiation code, and (b) the
manifest
of your bundle?
Angelo
On Apr 2, 2012, at 10:18 AM, M. van Ree wrote:
Hello all,
I have a problem when trying to make the Android lib available to my
OSGi
bundles.
The error I'm getting is:
04-02 08:03:00.351: W/dalvikvm(18531): Method mismatch: onDraw in
Lcom/osgi/integration/drawbundle/DrawView; (cl=0x4067bb40) and super
Landroid/view/View; (cl=0x0)
04-02 08:03:00.391: W/System.err(18531):
Re: OBR and automatic bundle update
On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that collaboration among them becomes limited to little islands of bundles that happen to be using the same same providers. Note that while I'm using the shell to run my tests, my intention is to use the OBR API in my code. So the solution may be available only in the API. Sorry the mail got so long but I wanted to state my problem as clear as possible. Thank you for taking the time to read and to answer! Still not clear to me what the actual issue is or the solution, but at a minimum OBR should probably refresh after update. - richard Kind regards [1] http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Blocked Thread while shutting down Felix / IPojo
Hi, I'm currently have a problem with Felix and or IPojo. Basically the problem is when Felix is starting up and services are still registering while and in the meantime a stop Felix is request. The code to stop is simple : getBundle(0).stop(); If I have a look at the thread dump on JVisualVM, I have (full thread dump in attachement) : FelixStartLevel daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for monitor entry [0x07fbf000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) - waiting to lock 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) at org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) at org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Unknown Source) Locked ownable synchronizers: - None And Thread-2 daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() [0x084bd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc029d238 (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) - locked 0xc029d238 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.registerService(Felix.java:3206) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) - locked 0xeafc8ea0 (a org.apache.felix.ipojo.handlers.providedservice.ProvidedService) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301) - locked 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238) at org.apache.felix.ipojo.Factory$$Proxy.createComponentInstance(Unknown Source) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__createAndStart(ComponentDefinition.java:147) at com.axway.cmp.ume.ui.internal.ComponentDefinition.createAndStart(ComponentDefinition.java) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__validate(ComponentDefinition.java:85) at com.axway.cmp.ume.ui.internal.ComponentDefinition.validate(ComponentDefinition.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.felix.ipojo.util.Callback.call(Callback.java:237) at org.apache.felix.ipojo.util.Callback.call(Callback.java:193) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86) at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged(LifecycleCallbackHandler.java:162) at
[ANN] Java Application Architecture: Modularity Patterns with Examples Using OSGi
Apologies for the blatant advertisement, but want to let you all know that my book, Java Application Architecture: Modularity Patterns with Examples Using OSGi is now available. The book's homepage is http://modularity.kirkk.com. Ironically, the book may not be an ideal fit for those of you already highly proficient with OSGi. It's sweet spot is in helping you articulate the benefits of modularity and designing software applications with a modular architecture in the absence of a good module framework like OSGi. Once folks experience the benefits of modular architecture, their increase in a module framework will hopefully increase too. If you experience this type of adoption hurdle, or know others that do, you may find the book interesting. thanx. Kirk Knoernschild http://www.kirkk.com http://techdistrict.kirkk.com http://planet.kirkk.com twitter: pragkirk
Re: OBR and automatic bundle update
Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that collaboration among them becomes limited to little islands of bundles that happen to be using the same same providers. I understand. But updating the bundles may lead to the problem I presented, where a bundle can't be resolved despite all necessary resources are available. I know that this behavior is not defined by OBR but OSGi in general. But I don't understand why once a bundle is updated, an older version of it can't be re-installed so a bundle depending on it can be successfully resolved. I think that allowing this may help to avoid problems like the one presented (note that I have almost no experience with OSGi so maybe I'm talking nonsenses). Do you know the reason to forbid the installation of an old version of an updated bundle? Note that while I'm using the shell to run my tests, my intention is to use the OBR API in my code. So the solution may be available only in the API. Sorry the mail got so long but I wanted to state my problem as clear as possible. Thank you for taking the time to read and to answer! Still not clear to me what the actual issue is or the solution, but at a minimum OBR should probably refresh after update. The issue is that the DexA
Re: Blocked Thread while shutting down Felix / IPojo
I don't know if that may be your issue but in the book OSGi in action [1] they recommend that if a bundle want to stop itself, it should do so in a different thread. This is to avoid possible deadlocks if as part of the bundle finalization there is any waiting for the calls to finish. You can refer to the book's source code examples [2]. HTH, Regards [1] http://www.manning.com/hall/ [2] http://code.google.com/p/osgi-in-action/source/browse/trunk/chapter03/shell-example/org.foo.shell/src/org/foo/shell/StopCommand.java On 02/04/12 14:46, Gay David (Annecy) wrote: Hi, I'm currently have a problem with Felix and or IPojo. Basically the problem is when Felix is starting up and services are still registering while and in the meantime a stop Felix is request. The code to stop is simple : getBundle(0).stop(); If I have a look at the thread dump on JVisualVM, I have (full thread dump in attachement) : FelixStartLevel daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for monitor entry [0x07fbf000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) - waiting to lock 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) at org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) at org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Unknown Source) Locked ownable synchronizers: - None And Thread-2 daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() [0x084bd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc029d238 (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) - locked 0xc029d238 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.registerService(Felix.java:3206) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) - locked 0xeafc8ea0 (a org.apache.felix.ipojo.handlers.providedservice.ProvidedService) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301) - locked 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238) at org.apache.felix.ipojo.Factory$$Proxy.createComponentInstance(Unknown Source) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__createAndStart(ComponentDefinition.java:147) at com.axway.cmp.ume.ui.internal.ComponentDefinition.createAndStart(ComponentDefinition.java) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__validate(ComponentDefinition.java:85) at com.axway.cmp.ume.ui.internal.ComponentDefinition.validate(ComponentDefinition.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: OBR and automatic bundle update
On 4/2/12 15:42, Matias SM wrote: Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. Still seems like it should be possible for OBR to deploy DexA by updating 1.0.0.1 to 1.0.0.2. --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. Ok, I see your point now. No, the one doesn't necessarily follow the other. The reason to favor updating existing bundles is the reason I gave below. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that collaboration among them becomes limited to little islands of bundles that happen to be using the same same providers. I understand. But updating the bundles may lead to the problem I presented, where a bundle can't be resolved despite all necessary resources are available. I know that this behavior is not defined by OBR but OSGi in general. But I don't understand why once a bundle is updated, an older version of it can't be re-installed so a bundle depending on it can be successfully resolved. I think that allowing this may help to avoid problems like the one presented (note that I have almost no experience with OSGi so maybe I'm talking nonsenses). Do you know the reason to forbid the installation of an old version of an updated bundle? You can re-install older versions. OBR will *only* update an existing bundle if it still satisfies all existing constraints. If not, then it will install
Re: Blocked Thread while shutting down Felix / IPojo
This is not related to FELIX-3393, although it appears related to the Aries Blueprint comment on FELIX-3393, which is also unrelated to FELIX-3393. It appears in both situations the component framework (Aries Blueprint and/or iPOJO) is synchronously dealing with a bundle being stopped while at the same time trying to register a service for that bundle. Since the component framework is holding and/or needs its own internal lock when dealing with the stopped bundle and registering the service, we get into a deadlock situation, since both threads also need the bundle lock too. Perhaps just open an issue against the framework to track this. - richard On 4/2/12 13:46, Gay David (Annecy) wrote: Hi, I'm currently have a problem with Felix and or IPojo. Basically the problem is when Felix is starting up and services are still registering while and in the meantime a stop Felix is request. The code to stop is simple : getBundle(0).stop(); If I have a look at the thread dump on JVisualVM, I have (full thread dump in attachement) : FelixStartLevel daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for monitor entry [0x07fbf000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) - waiting to lock 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) at org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) at org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Unknown Source) Locked ownable synchronizers: - None And Thread-2 daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() [0x084bd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc029d238 (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) - locked 0xc029d238 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.registerService(Felix.java:3206) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) - locked 0xeafc8ea0 (a org.apache.felix.ipojo.handlers.providedservice.ProvidedService) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301) - locked 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238) at org.apache.felix.ipojo.Factory$$Proxy.createComponentInstance(Unknown Source) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__createAndStart(ComponentDefinition.java:147) at com.axway.cmp.ume.ui.internal.ComponentDefinition.createAndStart(ComponentDefinition.java) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__validate(ComponentDefinition.java:85) at com.axway.cmp.ume.ui.internal.ComponentDefinition.validate(ComponentDefinition.java)
Re: OBR and automatic bundle update
On 02/04/12 17:31, Richard S. Hall wrote: On 4/2/12 15:42, Matias SM wrote: Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. Still seems like it should be possible for OBR to deploy DexA by updating 1.0.0.1 to 1.0.0.2. Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step 2 in test)? --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. Ok, I see your point now. No, the one doesn't necessarily follow the other. The reason to favor updating existing bundles is the reason I gave below. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that collaboration among them becomes limited to little islands of bundles that happen to be using the same same providers. I understand. But updating the bundles may lead to the problem I presented, where a bundle can't be resolved despite all necessary resources are available. I know that this behavior is not defined by OBR but OSGi in general. But I don't understand why once a bundle is updated, an older version of it can't be re-installed so a bundle depending on it can be successfully resolved. I think that allowing this may help to avoid problems like the one presented (note that I have almost no experience with OSGi so maybe I'm talking nonsenses). Do you know the reason to forbid the installation of an old version of an updated bundle? You can re-install
Re: OBR and automatic bundle update
On 4/2/12 17:05, Matias SM wrote: On 02/04/12 17:31, Richard S. Hall wrote: On 4/2/12 15:42, Matias SM wrote: Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. Still seems like it should be possible for OBR to deploy DexA by updating 1.0.0.1 to 1.0.0.2. Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step 2 in test)? No. OBR doesn't keep some set of desired deployed bundles or anything like that...it isn't that sophisticated. It simply tries to deploy bundles given the current context of the framework. So, the fact that you told OBR to deploy foo in some previous request has no bearing on subsequent requests other than the fact that it impacts the set of installed bundles from which it starts to perform its operation...but that is no different than if you installed a given bundle manually and didn't use OBR at all. --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. Ok, I see your point now. No, the one doesn't necessarily follow the other. The reason to favor updating existing bundles is the reason I gave below. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that collaboration among them becomes limited to little islands of bundles that happen to be using the same same providers. I understand. But updating the bundles may lead to the problem I presented, where a bundle can't be resolved
Re: OBR and automatic bundle update
On 02/04/12 18:32, Richard S. Hall wrote: On 4/2/12 17:05, Matias SM wrote: On 02/04/12 17:31, Richard S. Hall wrote: On 4/2/12 15:42, Matias SM wrote: Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. Still seems like it should be possible for OBR to deploy DexA by updating 1.0.0.1 to 1.0.0.2. Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step 2 in test)? No. OBR doesn't keep some set of desired deployed bundles or anything like that...it isn't that sophisticated. It simply tries to deploy bundles given the current context of the framework. So, the fact that you told OBR to deploy foo in some previous request has no bearing on subsequent requests other than the fact that it impacts the set of installed bundles from which it starts to perform its operation...but that is no different than if you installed a given bundle manually and didn't use OBR at all. Ok, now I understand your point. Though I can see that this behavior may lead to some issues if bundle A@1.0.0.1 has some kind of functionality other than defining classes to export. --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. Ok, I see your point now. No, the one doesn't necessarily follow the other. The reason to favor updating existing bundles is the reason I gave below. My questions are: 1- Is there a way to force the installation of different bundle versions (instead of the update of older ones) when deploying through OBR? No, I don't think so. 2- What kind of issues may this behavior (installation of different versions) rise? (this is not considering the problem of having a lot of bundles installed) Lots of providers is generally a bad thing since it creates many partitions in the overall class spaces of the bundles, meaning that
Issues while updating gogo bundles
Hi, It looks like there are some issues while refreshing gogo bundles This is what you get when updating gogo runtime Welcome to Apache Felix Gogo g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.2) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) g! update 3 g! Welcome to Apache Felix Gogo g! lb gosh: java.lang.IllegalStateException: session is closed gosh: stopping framework [here, the framework stops] And this is when updating gogo shell Welcome to Apache Felix Gogo g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.2) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) g! update 4 g! Welcome to Apache Felix Gogo g! lb gogo: CommandNotFoundException: Command not found: l g! gogo: CommandNotFoundException: Command not found: b g! [here the shell is very close to unusable] Are these bundles meant to ever be refreshed? Regards, Lucas - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR and automatic bundle update
Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time. As I suggest you need to have two different paths. However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before. Matias SM matias...@yahoo.com.ar wrote: On 02/04/12 18:32, Richard S. Hall wrote: On 4/2/12 17:05, Matias SM wrote: On 02/04/12 17:31, Richard S. Hall wrote: On 4/2/12 15:42, Matias SM wrote: Thank you for your answer Richard, please see my comments inline: On 02/04/12 14:40, Richard S. Hall wrote: On 4/1/12 12:32, Matias SM wrote: Hi everybody, I'm using OBR to help me resolve bundle deployment. Everything works great and as expected but I'm facing a situation I don't know how to solve. --- Here is my test scenario: I have the following bundles in an OBR repository: * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: p.a version: 1) * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: p.a version: 1) * SymbolicName: DA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) * SymbolicName: DexA | Bundle-Version: 1| depends: (package: p.a version: [1 , 2) ) and (bundle: A version: [1.0.0.2, 1.0.0.2] ) Then my test runs as follows: g! deploy -s DA == this also deploys A version 1.0.0.2 (I guess because it is the newer bundle that exports pa version 1) g! deploy -s A@1.0.0.1 == this __updates__ the previously deployed A (version 1.0.0.2) First issue, if I run: g!deploy -s A@1.0.0.2 == then OBR executes successfully but A@1.0.0.2 is not installed (since there is an updated version of it already resolved). I know this is the expected behavior, but I would like to be able to deploy A@1.0.0.2 It seems like OBR should probably be performing a refresh after it does an update, so there isn't an older version hanging around. Second (and worse) issue, if I now run: g!refresh == so A@1.0.0.2 is completely uninstalled from the framework And then: g!deploy -s DexA == this deployment __fails__ because A@1.0.0.2 can't be reinstalled in the framework!! Not sure why that would be. Are you seeing some sort of error? I think that the problem here is that to be able to update the dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was deployed in step 2). I don't think this should be a valid thing to do. Still seems like it should be possible for OBR to deploy DexA by updating 1.0.0.1 to 1.0.0.2. Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step 2 in test)? No. OBR doesn't keep some set of desired deployed bundles or anything like that...it isn't that sophisticated. It simply tries to deploy bundles given the current context of the framework. So, the fact that you told OBR to deploy foo in some previous request has no bearing on subsequent requests other than the fact that it impacts the set of installed bundles from which it starts to perform its operation...but that is no different than if you installed a given bundle manually and didn't use OBR at all. Ok, now I understand your point. Though I can see that this behavior may lead to some issues if bundle A@1.0.0.1 has some kind of functionality other than defining classes to export. --- In the OBR project web page [1] can be read: OBR's deployment algorithm appears simple at first glance, but it is actually somewhat complex due to the nature of deploying independently developed bundles. For example, in an ideal world, if an update for a bundle is made available, then updates for all of the bundles satisfying its dependencies are also made available. Unfortunately, this may not be the case, thus the deployment algorithm might have to install new bundles during an update to satisfy either new dependencies or updated dependencies that can no longer be satisfied by existing local bundles. In response to this type of scenario, ___the OBR deployment algorithm tries to favor updating existing bundles, if possible, as opposed to installing new bundles to satisfy dependencies. I don't fully understand this explanation but I get that the described behavior is as intended. Not sure which part you don't understand. What I don't understand is how the need to favor updating existing bundles is concluded from the problem stated in the previous sentences. It is not clear to me the relation between the need to install new bundles during an update and the algorithm that tries to favor updating existing bundles instead of installing new ones. Ok, I see your
Re: OBR and automatic bundle update
Ok, I see. Shouldn't the location string be replaced (with the updated version location) when the bundle is updated? It seems a little confusing. Thank you very much for the clarification, I will do some more experimentation keeping in mind what we discussed. On 02/04/12 19:25, Richard S. Hall wrote: Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time. As I suggest you need to have two different paths. However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR and automatic bundle update
The location string is a deployer assigned persistent identifier, so it cannot change. Your confusion arises because frameworks use the URL as the default location string for simple installs, but the two are unrelated in reality. Matias SM matias...@yahoo.com.ar wrote: Ok, I see. Shouldn't the location string be replaced (with the updated version location) when the bundle is updated? It seems a little confusing. Thank you very much for the clarification, I will do some more experimentation keeping in mind what we discussed. On 02/04/12 19:25, Richard S. Hall wrote: Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time. As I suggest you need to have two different paths. However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Sent from my phone, excuse my brevity.
