Hello,
I thank you both for answering so quickly.
setting configProps.put("org.osgi.framework.bundle.parent",
"app");
didn't
change something, same problem occurs.
setting configProps.put("felix.bootdelegation.implicit",
"false");
neither with nor without setting the ..bundle.parent=app
causes him to not find the Class MapView.
BUT: he doesn't hang (but crashes later)
Error is:
09-22 13:08:22.829: WARN/dalvikvm(726): Unable to resolve
superclass of
Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (20)
09-22 13:08:22.829: WARN/dalvikvm(726): Link of class
'Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;' failed
09-22 13:08:22.829: ERROR/dalvikvm(726): ERROR:
defineClass(0x43878790,
de.mnsoft.mapprovider.gmapsimpl.AutoRefreshMapView, 0x43854238,
0,
2691,
0x43838620)
09-22 13:08:22.839: WARN/dalvikvm(726): VFY: unable to find class
referenced in signature
(Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;)
09-22 13:08:23.829: WARN/dalvikvm(726): VFY: unable to find class
referenced in signature (Lcom/google/android/maps/MapActivity;)
09-22 13:08:24.709: ERROR/dalvikvm(726): Could not find class
'com.google.android.maps.MapActivity', referenced from method
de
.mnsoft
.mapprovider.gmapsimpl.MapProviderServiceImpl.__generateMapView
09-22 13:08:24.719: WARN/dalvikvm(726): VFY: unable to resolve
check-cast
19 (Lcom/google/android/maps/MapActivity;) in
Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;
09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejecting opcode
0x1f at
0x0008
09-22 13:08:24.719: WARN/dalvikvm(726): VFY: rejected
Lde/mnsoft/mapprovider/gmapsimpl/
MapProviderServiceImpl;.__generateMapView
()V
09-22 13:08:24.719: WARN/dalvikvm(726): Verifier rejected class
Lde/mnsoft/mapprovider/gmapsimpl/MapProviderServiceImpl;
09-22 13:08:24.799: WARN/System.err(726): [ERROR]
de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl :
[de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl-0]
createInstance ->
The POJO constructor invocation failed :
de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl
09-22 13:08:24.959: WARN/System.err(726): java.lang.VerifyError:
de.mnsoft.mapprovider.gmapsimpl.MapProviderServiceImpl
09-22 13:08:24.979: WARN/System.err(726): at
java.lang.Class.getDeclaredConstructors(Native Method)
09-22 13:08:24.989: WARN/System.err(726): at
java.lang.Class.getDeclaredConstructor(Class.java:602)
09-22 13:08:24.989: WARN/System.err(726): at
org
.apache
.felix.ipojo.InstanceManager.createObject(InstanceManager.java:
583)
...
I still can't get rid of the feeling that this all has to do
with the
warning I get every time
09-22 13:19:09.302: WARN/System.err(729): Problem creating boot
delegation
class loader: java.lang.reflect.InvocationTargetException
just because "boot delegation" is mentioned.
May it help to set the Android and Maps Bundles as Dynamic-
Import in
the
using Bundle instead of forcing the Bundle to not-import the
Package?
(while
keeping the configuration in Hostapplication as it is)
If still nessesary I will send you the 2 projects. I guess the
current
situation has to many bundle dependencies, so I should better
build an
easier Example-Bundle combined with my hostapplication to make
it more
compact and problem oriented.
regards
Matthias
Am 22.09.2009 um 12:00 schrieb Karl Pauls:
Wait a sec, can you place try to set the following property:
felix.bootdelegation.implicit=false
and see whether that makes your problem go away?
regards,
Karl
On Tue, Sep 22, 2009 at 11:52 AM, Richard S. Hall
<[email protected]>
wrote:
On 9/22/09 11:32, Matthias Neubert wrote:
Hello,
I guess I found a problem when using Bootdelegation. In the
same
situation
the problem does not occur when using ..system.extra to export
packages
from
System bundle.
Context: Android 1.6r1 (DalvikVM) Felix 2.0.0 is embedded.
iPOJO 1.4
is
used
After I ran into a Bug of DalvikVM which is known as
"Android Issue
2711"
, I tried to solve this using Boot delegation.(because 2711
an
classloader
problem in Dalvik VM)
(For me 2711 showed up, when trying to extend a Class in a
bundle
from
a
superclass which is imported via ..system.extra. The packge
which is
exported by hostapplication (embedding felix) is on
classpath of the
hostapplication (in this case: android.jar and maps.jar)
Maps.jar
contains
the class com.google.android.maps.MapView which is extended
in a
bundle
which is installed in the embedded felix.)
So I switched the project using bootdelegation for all the
packages
in
android.jar and maps.jar. Additional some packages of the
hostapplication
and some osgi packages are exported using system.extra.
These are:
"org.osgi.framework; version=1.5.0," +
"org.osgi.service.packageadmin; version=1.2.0," +
"org.osgi.service.startlevel; version=1.0.0," +
"org.osgi.service.url; version=1.0.0," +
"org.osgi.util.tracker," +
// local defined
"de.mnsoft.felixhostapp.activityservice,"+
"de.mnsoft.felixhostapp.appstarter,"+
"de.mnsoft.felixhostapp.global"
The bundle which extends the class now do NOT import android
and
maps
Packages, to force it to get them over bootdelegation
mechanism.
The Problem:
When running this configuration, as soon the Bundle gets
installed
the
following happens:
Application hangs for ever in one thread (which is started
when the
service tracker noticed the bundle in addingService() and
wants to
get
the
service)
This is running for ever (so absolutly no error message
arrive,
debug
level of felix is 4);
in ModuleImpl.findClassOrRessourceByDelegation() line 677 he
uses
searchDynamicImports() line 1443
that calls in libary maps.jar (integrated in android,
available on
classpath of hostapplication)
Class.getClassLoader() line 409 which uses
BootClassLoader.getInstance();
and System.getSecurityManager() line 505
finally it hang in
searchDynamicImports() in line 1443 and 1445 and switches
between
them.
This happens while com.google.android.maps.MapView is
processed
The array classes is filled with exactly 100 (remarkable
coincidence?)
classes from felix and ipojo. but no android.* or com.google.*
it seems that bootdelegation doesn't work with this libaries
what do you think about this issue and does it have
something to do
with
"org.osgi.framework.bundle.parent=app"
I found this to be a new config in R4.2, but Felix wiki
offers no
information about this, but I guess its very important
because I
suffer
here
from classloader-trouble in my VM.
But: Using the new key or not doesn't change the situation.
You can try to change this value and see if it has any
impact. Dalvik
is
a
little odd in this area, so we had to put some workarounds in
there
to
even
get it to work.
-> richard
regards
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
