You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matthias Neubert <su...@onlinehome.de> on 2009/09/22 11:32:28 UTC
Problem with Bootdelegation using Felix 2.0.0
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.
regards
Matthias
Re: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
By analyzing more deeply your stack trace, it seems that during the
pojo object creation, the service is unregistered. Do you have any
explication of such behavior. For sure, this kind of sequence may
annoy the Service Factories.
The immediate should not impact the instance creation. However, it is
possible that something really wrong arrives during the object
creation of SerialRxTx. In such case, iPOJO stops the instance... That
may explain the stack trace. The question is now : why the SerialRxtx
POJO objects cannot be created correctly. Could you try to create them
independently and see if you have an error ?
Regards,
Clement
On 23.09.2009, at 19:02, Joel Schuster wrote:
> Clement,
>
> I have an rxtx bundle. I use cfg files to create one or more ipojo
> instances of my rxtx service. These cfg files have stuff like baud,
> parity, com port name, etc.
>
> I have another bundle that uses just one of those, I get the list of
> all of them and then pick one based on a property within the rxtx
> service also configured by the cfg files.
>
> So:
>
> KNClient (instance from cfg file)
> |
> V
> <uses one of x number based on property set in rxtx cfg file>
> |
> V
> SerialRxTx (instances from cfg files)
>
> I tried putting immediate=true on the RxTx service, however the cfg
> files no longer were setting the properties and the arch command no
> longer showed any instances being created even though the
> constructor for the service was being called. As the KNClient is not
> a service, just a component, it is automatically immediate.
>
> Thanks for your help!
>
> - Joel
>
>> -----Original Message-----
>> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
>> Sent: Wednesday, September 23, 2009 12:53 AM
>> To: users@felix.apache.org
>> Subject: Re: @Requires : ServiceFactory.getService() resulted in a
>> cycle.
>>
>> Hi,
>>
>> It sounds like a cycle during object creation. iPOJO object are
>> created when needed by default (if your component provides a
>> service).
>> To handle that iPOJO uses OSGi service factories.
>>
>> The problem sounds to be the following:
>> - a service is going to be used
>> - iPOJO creates the pojo object (because, we need it)
>> - this object can also depending on a service, which may use the one
>> of the previous ones.... Cycle
>>
>> To break the cycle, you can set one component to immediate. In that
>> case, the object will be created eagerly. the big question is : Which
>> ones.
>>
>> If you gives me more detail on your system, I can figure out how to
>> break the cycle.
>>
>> Regards,
>>
>> Clement
>>
>> On 22.09.2009, at 23:21, Joel Schuster wrote:
>>
>>>
>>>
>>> I hate sending stack traces but I'm running into a real nasty issue.
>>> I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
>>> tried various forms of the @Requires annotation.
>>>
>>> This problem is sometimes reproducible on two systems but not on the
>>> third so I'm beginning to suspect a race condition of some sort as
>>> it only manifests some of the time and is sometimes dependant upon
>>> the order of the bundle loading.
>>>
>>> I have one bundle that @Requires a collection of instances from
>>> another bundle that implements two different interfaces, also each
>>> in their own bundles. I've created a test set of bundles to see if
>>> the problem comes from the inheritance model, but I can't reproduce
>>> in a smaller example. Yet another reason it feels like a race
>>> condition.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>> -> ERROR: EventDispatcher: Error during dispatch.
>>> (java.lang.IllegalStateException: ServiceFactory.getService()
>>> resulted in a cycle.)
>>> java.lang.IllegalStateException: ServiceFactory.getService()
>>> resulted in a cycle.
>>> at
>>> org
>>> .apache
>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>> 261)
>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>> 357)
>>> at
>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>> 260)
>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
>>> 917)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:
>>> 435)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
>>> at org.apache.felix.ipojo.util.Tracker
>>> $Tracked.untrack(Tracker.java:
>>> 736)
>>> at org.apache.felix.ipojo.util.Tracker
>>> $Tracked.serviceChanged(Tracker.java:636)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .util
>>> .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
>>> 878)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
>>> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
>>> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:
>>> 624)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:
>>> 117)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:
>>> 128)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .providedservice
>>> .ProvidedService.unregisterService(ProvidedService.java:298)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .providedservice
>>> .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
>>> 435)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .providedservice
>>> .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
>>> at
>>> org
>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>> 451)
>>> at
>>> org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
>>> 340)
>>> at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .configuration
>>> .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .configuration
>>> .ConfigurationHandler.onCreation(ConfigurationHandler.java)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
>>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
>>> $SingletonStrategy.getService(ProvidedService.java:438)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .providedservice.ProvidedService.getService(ProvidedService.java:
>>> 263)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .ServiceRegistrationImpl
>>> .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework
>>> .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:
>>> 207)
>>> at
>>> org
>>> .apache
>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>> 307)
>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>> 357)
>>> at
>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>> 260)
>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:
>>> 901)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers.dependency.Dependency.createServiceObject(Dependency.java:
>>> 481)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:
>>> 456)
>>> at
>>> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:
>>> 944)
>>> at
>>> com
>>> .navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
>>> at
>>> com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:
>>> 49)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeConstructorAccessorImpl
>>> .newInstance(NativeConstructorAccessorImpl.java:39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingConstructorAccessorImpl
>>> .newInstance(DelegatingConstructorAccessorImpl.java:27)
>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .lifecycle
>>> .callback
>>> .LifecycleCallbackHandler
>>> .__stateChanged(LifecycleCallbackHandler.java:156)
>>> at
>>> org
>>> .apache
>>> .felix
>>> .ipojo
>>> .handlers
>>> .lifecycle
>>> .callback
>>> .LifecycleCallbackHandler
>>> .stateChanged(LifecycleCallbackHandler.java)
>>> at
>>> org
>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>> 440)
>>> at
>>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:
>>> 321)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
>>> 155)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>> 298)
>>> at
>>> org
>>> .apache
>>> .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>> 235)
>>> at
>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
>>> at org.apache.felix.cm.impl.ConfigurationManager
>>> $UpdateConfiguration.run(ConfigurationManager.java:1460)
>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Bundle-NativeCode:
Posted by Joel Schuster <jo...@Navsys.com>.
NP, thanks all.
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Monday, September 28, 2009 1:34 PM
> To: users@felix.apache.org
> Subject: Re: Bundle-NativeCode:
>
> Yes, forgot about that bug. In short, if you have a bundle with more
> than one native library, then you will run into the issue below...the
> 2.0.1 release will include this fix.
>
> Sorry.
>
> -> richard
>
>
> On 9/28/09 16:47, Holger Hoffstätte wrote:
> > Sorry for the late reply, catching up..
> >
> > Joel Schuster wrote:
> > > In 2.0 native libraries don't seem to be loading at all. I get
> >
> >> java.lang.ExceptionInInitializerError trying to get to the native
> >> library.
> >>
> > 2.0 final is broken (bug found& fixed but not in time for the release),
> > you need to build/run svn trunk or stay with 1.8.1. See
> > https://issues.apache.org/jira/browse/FELIX-1580
> >
> > Holger
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-NativeCode:
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, forgot about that bug. In short, if you have a bundle with more
than one native library, then you will run into the issue below...the
2.0.1 release will include this fix.
Sorry.
-> richard
On 9/28/09 16:47, Holger Hoffstätte wrote:
> Sorry for the late reply, catching up..
>
> Joel Schuster wrote:
> > In 2.0 native libraries don't seem to be loading at all. I get
>
>> java.lang.ExceptionInInitializerError trying to get to the native
>> library.
>>
> 2.0 final is broken (bug found& fixed but not in time for the release),
> you need to build/run svn trunk or stay with 1.8.1. See
> https://issues.apache.org/jira/browse/FELIX-1580
>
> Holger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-NativeCode:
Posted by Holger Hoffstätte <ho...@googlemail.com>.
Sorry for the late reply, catching up..
Joel Schuster wrote:
> In 2.0 native libraries don't seem to be loading at all. I get
> java.lang.ExceptionInInitializerError trying to get to the native
> library.
2.0 final is broken (bug found & fixed but not in time for the release),
you need to build/run svn trunk or stay with 1.8.1. See
https://issues.apache.org/jira/browse/FELIX-1580
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-NativeCode:
Posted by "Richard S. Hall" <he...@ungoverned.org>.
There were some changes in this area, but native libraries still do load.
If you want to create an issue and attach a test bundle with the steps
to reproduce, I could look into it.
-> richard
On 9/24/09 18:07, Joel Schuster wrote:
>
> I'm having dissimilar behavior in native library loading b/t felix 1.8& 2.0
>
> In 1.8 if I have the shell tui service running and I make a call into a bundle that uses a native library the call will hang until I enter something into the command console. Then everything works. If I turn off the tui (don't load the bundle) then everything flys right through.
>
> In 2.0 native libraries don't seem to be loading at all. I get java.lang.ExceptionInInitializerError trying to get to the native library.
>
> Anyone else seen this kind of behavior?
>
> - Joel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Bundle-NativeCode:
Posted by Joel Schuster <jo...@Navsys.com>.
I'm having dissimilar behavior in native library loading b/t felix 1.8 & 2.0
In 1.8 if I have the shell tui service running and I make a call into a bundle that uses a native library the call will hang until I enter something into the command console. Then everything works. If I turn off the tui (don't load the bundle) then everything flys right through.
In 2.0 native libraries don't seem to be loading at all. I get java.lang.ExceptionInInitializerError trying to get to the native library.
Anyone else seen this kind of behavior?
- Joel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 23.09.2009, at 21:02, Joel Schuster wrote:
> I'm beginning to understand just how much I don't understand.
>
> Is there some documentation on how iPojo works? How factories are
> created and how instances are created? Esp. with how they work with
> FileInstaller? I'm stumped.
Factories and Instance : http://felix.apache.org/site/how-to-use-ipojo-factories.html
Well, the is two different layer:
component factories create component instances
component instances contain and manage POJO objects (may be service
object).
When you use @Component or <component> you declare a component factory
(component type).
When you use <instance> or .cfg file using a factoryPID you declare a
component instance.
POJO objects are created either eagerly or lazily:
- if the instance does not provide a service (or if the component
factory set immediate-true of set a validate callback), the pojo
object is created when the component instance becomes valid.
- if the instance provides a service, the service object (POJO object)
is created when required according to the creation strategy
(singleton : one service object, instance : one service object per
asking instance ...) [to publish services, the instance is necessary
valid]
>
> When I use INSTANCE strategy I'm seeing the two instances being
> created from the cfg files but then I'm seeing two new instances
> being created when my KNClient asks for a list, but those don't have
> any configuration in the properties (just the defaults). When I use
> SINGLETON, the list from the @Requires in the KNClient actually
> contains the two instances that were created by the cfg files but
> that's when I get (sometimes) the cycle error.
> When I use immediate=true, the instances (object instances) are
> created but can't be seen by the arch command.
When you use the Instance strategy, component instance are created
normally. But such instances will produce one service object per
asking instance. If the component instance has already created a pojo
object, it will NOT be used when your KNClient asks for the service
(because the created one is not attached to the KNClient instance).
However, I don't understand why the configuration (given in the
component instance configuration) is not applied to these objects.
When using immediate, you declare your component instance normally.
when the instance becomes valid, it will immediately create a pojo
object (not another component instance). So, you should see only one
component instance. But if you ask for details, you will see the
created pojo object.
BTW, in your architecture, I don't see any cycle. So, I guess there is
an issue when the pojo object is created. Something wrong happens
during the pojo object creation forcing iPOJO to dispose the component
instance (then the component instance is no more visible from arch).
Hope this helps,
Regards,
Clement
>
> It's all over the place on how these things work, and none of it
> seems consistent.
>
> I can't find any documentation about when and where instances
> (object or iPojo) are created and what the difference is between
> when/where the constructor on components/services are called verses
> the @Validate methods are called.
>
> Please help me out. Thanks.
>
> - Joel
>
>> -----Original Message-----
>> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
>> Sent: Wednesday, September 23, 2009 11:37 AM
>> To: users@felix.apache.org
>> Subject: Re: @Requires : ServiceFactory.getService() resulted in a
>> cycle.
>>
>>
>> On 23.09.2009, at 19:33, Joel Schuster wrote:
>>
>>> As a side note... might this be a problem with the @Provides in the
>>> RxTx service? If the default strategy is SINGLETON, how does
>>> multiple cfg files create multiple instances? Or is this just
>>> referring to the factory?
>>
>> The singleton policy just says that each iPOJO instance will have one
>> one service object. But you can have several iPOJO instance (each
>> with
>> one service object). However, be care if you use statics (because
>> they
>> are shared.)
>>
>> Clement
>>
>>>
>>> - Joel
>>>
>>>> -----Original Message-----
>>>> From: Joel Schuster [mailto:joels@Navsys.com]
>>>> Sent: Wednesday, September 23, 2009 11:03 AM
>>>> To: 'users@felix.apache.org'
>>>> Subject: RE: @Requires : ServiceFactory.getService() resulted in a
>>>> cycle.
>>>>
>>>> Clement,
>>>>
>>>> I have an rxtx bundle. I use cfg files to create one or more ipojo
>>>> instances of my rxtx service. These cfg files have stuff like baud,
>>>> parity, com port name, etc.
>>>>
>>>> I have another bundle that uses just one of those, I get the list
>>>> of all
>>>> of them and then pick one based on a property within the rxtx
>>>> service also
>>>> configured by the cfg files.
>>>>
>>>> So:
>>>>
>>>> KNClient (instance from cfg file)
>>>> |
>>>> V
>>>> <uses one of x number based on property set in rxtx cfg file>
>>>> |
>>>> V
>>>> SerialRxTx (instances from cfg files)
>>>>
>>>> I tried putting immediate=true on the RxTx service, however the cfg
>>>> files
>>>> no longer were setting the properties and the arch command no
>>>> longer
>>>> showed any instances being created even though the constructor for
>>>> the
>>>> service was being called. As the KNClient is not a service, just a
>>>> component, it is automatically immediate.
>>>>
>>>> Thanks for your help!
>>>>
>>>> - Joel
>>>>
>>>>> -----Original Message-----
>>>>> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
>>>>> Sent: Wednesday, September 23, 2009 12:53 AM
>>>>> To: users@felix.apache.org
>>>>> Subject: Re: @Requires : ServiceFactory.getService() resulted in a
>>>> cycle.
>>>>>
>>>>> Hi,
>>>>>
>>>>> It sounds like a cycle during object creation. iPOJO object are
>>>>> created when needed by default (if your component provides a
>>>>> service).
>>>>> To handle that iPOJO uses OSGi service factories.
>>>>>
>>>>> The problem sounds to be the following:
>>>>> - a service is going to be used
>>>>> - iPOJO creates the pojo object (because, we need it)
>>>>> - this object can also depending on a service, which may use the
>>>>> one
>>>>> of the previous ones.... Cycle
>>>>>
>>>>> To break the cycle, you can set one component to immediate. In
>>>>> that
>>>>> case, the object will be created eagerly. the big question is :
>>>>> Which
>>>>> ones.
>>>>>
>>>>> If you gives me more detail on your system, I can figure out how
>>>>> to
>>>>> break the cycle.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Clement
>>>>>
>>>>> On 22.09.2009, at 23:21, Joel Schuster wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> I hate sending stack traces but I'm running into a real nasty
>>>>>> issue.
>>>>>> I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
>>>>>> tried various forms of the @Requires annotation.
>>>>>>
>>>>>> This problem is sometimes reproducible on two systems but not on
>>>>>> the
>>>>>> third so I'm beginning to suspect a race condition of some sort
>>>>>> as
>>>>>> it only manifests some of the time and is sometimes dependant
>>>>>> upon
>>>>>> the order of the bundle loading.
>>>>>>
>>>>>> I have one bundle that @Requires a collection of instances from
>>>>>> another bundle that implements two different interfaces, also
>>>>>> each
>>>>>> in their own bundles. I've created a test set of bundles to see
>>>>>> if
>>>>>> the problem comes from the inheritance model, but I can't
>>>>>> reproduce
>>>>>> in a smaller example. Yet another reason it feels like a race
>>>>>> condition.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -> ERROR: EventDispatcher: Error during dispatch.
>>>>>> (java.lang.IllegalStateException: ServiceFactory.getService()
>>>>>> resulted in a cycle.)
>>>>>> java.lang.IllegalStateException: ServiceFactory.getService()
>>>>>> resulted in a cycle.
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>>>>> 261)
>>>>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>>>>> 357)
>>>>>> at
>>>>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>>>>> 260)
>>>>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
>>>>>> 434)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.util.DependencyModel.ungetService(DependencyModel.java:
>>>>>> 917)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:
>>>>>> 435)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.util.DependencyModel.removedService(DependencyModel.java:
>>>>>> 424)
>>>>>> at org.apache.felix.ipojo.util.Tracker
>>>>>> $Tracked.untrack(Tracker.java:
>>>>>> 736)
>>>>>> at org.apache.felix.ipojo.util.Tracker
>>>>>> $Tracked.serviceChanged(Tracker.java:636)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .util
>>>>>> .EventDispatcher
>>>>>> .invokeServiceListenerCallback(EventDispatcher.java:
>>>>>> 878)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:
>>>>>> 732)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>>>>> at
>>>>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
>>>>>> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
>>>>>> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:
>>>>>> 624)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .ServiceRegistry.unregisterService(ServiceRegistry.java:
>>>>>> 117)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:
>>>>>> 128)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .providedservice
>>>>>> .ProvidedService.unregisterService(ProvidedService.java:298)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .providedservice
>>>>>> .ProvidedServiceHandler
>>>>>> .__stateChanged(ProvidedServiceHandler.java:
>>>>>> 435)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .providedservice
>>>>>> .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>>>>> 451)
>>>>>> at
>>>>>> org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
>>>>>> 340)
>>>>>> at org.apache.felix.ipojo.util.Property.invoke(Property.java:
>>>>>> 502)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .configuration
>>>>>> .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .configuration
>>>>>> .ConfigurationHandler.onCreation(ConfigurationHandler.java)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
>>>>>> 787)
>>>>>> at
>>>>>> org.apache.felix.ipojo.handlers.providedservice.ProvidedService
>>>>>> $SingletonStrategy.getService(ProvidedService.java:438)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .providedservice.ProvidedService.getService(ProvidedService.java:
>>>>>> 263)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .ServiceRegistrationImpl
>>>>>> .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework
>>>>>> .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:
>>>>>> 207)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>>>>> 307)
>>>>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>>>>> 357)
>>>>>> at
>>>>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>>>>> 260)
>>>>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
>>>>>> 426)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.util.DependencyModel.getService(DependencyModel.java:
>>>>>> 901)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .dependency.Dependency.createServiceObject(Dependency.java:
>>>>>> 481)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.handlers.dependency.Dependency.onGet(Dependency.java:
>>>>>> 456)
>>>>>> at
>>>>>> org
>>>>>> .apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:
>>>>>> 944)
>>>>>> at
>>>>>> com
>>>>>> .navsys
>>>>>> .mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
>>>>>> at
>>>>>> com
>>>>>> .navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:
>>>>>> 49)
>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>>>> Method)
>>>>>> at
>>>>>> sun
>>>>>> .reflect
>>>>>> .NativeConstructorAccessorImpl
>>>>>> .newInstance(NativeConstructorAccessorImpl.java:39)
>>>>>> at
>>>>>> sun
>>>>>> .reflect
>>>>>> .DelegatingConstructorAccessorImpl
>>>>>> .newInstance(DelegatingConstructorAccessorImpl.java:27)
>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:
>>>>>> 513)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.ipojo.InstanceManager.createObject(InstanceManager.java:
>>>>>> 600)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
>>>>>> 776)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .lifecycle
>>>>>> .callback
>>>>>> .LifecycleCallbackHandler
>>>>>> .__stateChanged(LifecycleCallbackHandler.java:156)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo
>>>>>> .handlers
>>>>>> .lifecycle
>>>>>> .callback
>>>>>> .LifecycleCallbackHandler
>>>>>> .stateChanged(LifecycleCallbackHandler.java)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>>>>> 440)
>>>>>> at
>>>>>> org
>>>>>> .apache.felix.ipojo.InstanceManager.start(InstanceManager.java:
>>>>>> 321)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.ComponentFactory.createInstance(ComponentFactory.java:
>>>>>> 155)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>>>>> 298)
>>>>>> at
>>>>>> org
>>>>>> .apache
>>>>>> .felix
>>>>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>>>>> 235)
>>>>>> at
>>>>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
>>>>>> at org.apache.felix.cm.impl.ConfigurationManager
>>>>>> $UpdateConfiguration.run(ConfigurationManager.java:1460)
>>>>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:
>>>>>> 88)
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Joel Schuster <jo...@Navsys.com>.
I'm beginning to understand just how much I don't understand.
Is there some documentation on how iPojo works? How factories are created and how instances are created? Esp. with how they work with FileInstaller? I'm stumped.
When I use INSTANCE strategy I'm seeing the two instances being created from the cfg files but then I'm seeing two new instances being created when my KNClient asks for a list, but those don't have any configuration in the properties (just the defaults). When I use SINGLETON, the list from the @Requires in the KNClient actually contains the two instances that were created by the cfg files but that's when I get (sometimes) the cycle error.
When I use immediate=true, the instances (object instances) are created but can't be seen by the arch command.
It's all over the place on how these things work, and none of it seems consistent.
I can't find any documentation about when and where instances (object or iPojo) are created and what the difference is between when/where the constructor on components/services are called verses the @Validate methods are called.
Please help me out. Thanks.
- Joel
> -----Original Message-----
> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> Sent: Wednesday, September 23, 2009 11:37 AM
> To: users@felix.apache.org
> Subject: Re: @Requires : ServiceFactory.getService() resulted in a cycle.
>
>
> On 23.09.2009, at 19:33, Joel Schuster wrote:
>
> > As a side note... might this be a problem with the @Provides in the
> > RxTx service? If the default strategy is SINGLETON, how does
> > multiple cfg files create multiple instances? Or is this just
> > referring to the factory?
>
> The singleton policy just says that each iPOJO instance will have one
> one service object. But you can have several iPOJO instance (each with
> one service object). However, be care if you use statics (because they
> are shared.)
>
> Clement
>
> >
> > - Joel
> >
> >> -----Original Message-----
> >> From: Joel Schuster [mailto:joels@Navsys.com]
> >> Sent: Wednesday, September 23, 2009 11:03 AM
> >> To: 'users@felix.apache.org'
> >> Subject: RE: @Requires : ServiceFactory.getService() resulted in a
> >> cycle.
> >>
> >> Clement,
> >>
> >> I have an rxtx bundle. I use cfg files to create one or more ipojo
> >> instances of my rxtx service. These cfg files have stuff like baud,
> >> parity, com port name, etc.
> >>
> >> I have another bundle that uses just one of those, I get the list
> >> of all
> >> of them and then pick one based on a property within the rxtx
> >> service also
> >> configured by the cfg files.
> >>
> >> So:
> >>
> >> KNClient (instance from cfg file)
> >> |
> >> V
> >> <uses one of x number based on property set in rxtx cfg file>
> >> |
> >> V
> >> SerialRxTx (instances from cfg files)
> >>
> >> I tried putting immediate=true on the RxTx service, however the cfg
> >> files
> >> no longer were setting the properties and the arch command no longer
> >> showed any instances being created even though the constructor for
> >> the
> >> service was being called. As the KNClient is not a service, just a
> >> component, it is automatically immediate.
> >>
> >> Thanks for your help!
> >>
> >> - Joel
> >>
> >>> -----Original Message-----
> >>> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> >>> Sent: Wednesday, September 23, 2009 12:53 AM
> >>> To: users@felix.apache.org
> >>> Subject: Re: @Requires : ServiceFactory.getService() resulted in a
> >> cycle.
> >>>
> >>> Hi,
> >>>
> >>> It sounds like a cycle during object creation. iPOJO object are
> >>> created when needed by default (if your component provides a
> >>> service).
> >>> To handle that iPOJO uses OSGi service factories.
> >>>
> >>> The problem sounds to be the following:
> >>> - a service is going to be used
> >>> - iPOJO creates the pojo object (because, we need it)
> >>> - this object can also depending on a service, which may use the one
> >>> of the previous ones.... Cycle
> >>>
> >>> To break the cycle, you can set one component to immediate. In that
> >>> case, the object will be created eagerly. the big question is :
> >>> Which
> >>> ones.
> >>>
> >>> If you gives me more detail on your system, I can figure out how to
> >>> break the cycle.
> >>>
> >>> Regards,
> >>>
> >>> Clement
> >>>
> >>> On 22.09.2009, at 23:21, Joel Schuster wrote:
> >>>
> >>>>
> >>>>
> >>>> I hate sending stack traces but I'm running into a real nasty
> >>>> issue.
> >>>> I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> >>>> tried various forms of the @Requires annotation.
> >>>>
> >>>> This problem is sometimes reproducible on two systems but not on
> >>>> the
> >>>> third so I'm beginning to suspect a race condition of some sort as
> >>>> it only manifests some of the time and is sometimes dependant upon
> >>>> the order of the bundle loading.
> >>>>
> >>>> I have one bundle that @Requires a collection of instances from
> >>>> another bundle that implements two different interfaces, also each
> >>>> in their own bundles. I've created a test set of bundles to see if
> >>>> the problem comes from the inheritance model, but I can't reproduce
> >>>> in a smaller example. Yet another reason it feels like a race
> >>>> condition.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -> ERROR: EventDispatcher: Error during dispatch.
> >>>> (java.lang.IllegalStateException: ServiceFactory.getService()
> >>>> resulted in a cycle.)
> >>>> java.lang.IllegalStateException: ServiceFactory.getService()
> >>>> resulted in a cycle.
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
> >>>> 261)
> >>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
> >>>> 357)
> >>>> at
> >>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> >>>> 260)
> >>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
> >>>> 434)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> >>>> 917)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:
> >>>> 435)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo.util.DependencyModel.removedService(DependencyModel.java:
> >>>> 424)
> >>>> at org.apache.felix.ipojo.util.Tracker
> >>>> $Tracked.untrack(Tracker.java:
> >>>> 736)
> >>>> at org.apache.felix.ipojo.util.Tracker
> >>>> $Tracked.serviceChanged(Tracker.java:636)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .util
> >>>> .EventDispatcher
> >>>> .invokeServiceListenerCallback(EventDispatcher.java:
> >>>> 878)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:
> >>>> 732)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> >>>> at
> >>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> >>>> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> >>>> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:
> >>>> 624)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:
> >>>> 117)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:
> >>>> 128)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .providedservice
> >>>> .ProvidedService.unregisterService(ProvidedService.java:298)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .providedservice
> >>>> .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> >>>> 435)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .providedservice
> >>>> .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> >>>> at
> >>>> org
> >>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> >>>> 451)
> >>>> at
> >>>> org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> >>>> 340)
> >>>> at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .configuration
> >>>> .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .configuration
> >>>> .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
> >>>> 787)
> >>>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> >>>> $SingletonStrategy.getService(ProvidedService.java:438)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .providedservice.ProvidedService.getService(ProvidedService.java:
> >>>> 263)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .ServiceRegistrationImpl
> >>>> .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework
> >>>> .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:
> >>>> 207)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
> >>>> 307)
> >>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
> >>>> 357)
> >>>> at
> >>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> >>>> 260)
> >>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
> >>>> 426)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:
> >>>> 901)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .dependency.Dependency.createServiceObject(Dependency.java:
> >>>> 481)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:
> >>>> 456)
> >>>> at
> >>>> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:
> >>>> 944)
> >>>> at
> >>>> com
> >>>> .navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> >>>> at
> >>>> com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:
> >>>> 49)
> >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>>> Method)
> >>>> at
> >>>> sun
> >>>> .reflect
> >>>> .NativeConstructorAccessorImpl
> >>>> .newInstance(NativeConstructorAccessorImpl.java:39)
> >>>> at
> >>>> sun
> >>>> .reflect
> >>>> .DelegatingConstructorAccessorImpl
> >>>> .newInstance(DelegatingConstructorAccessorImpl.java:27)
> >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
> >>>> 776)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .lifecycle
> >>>> .callback
> >>>> .LifecycleCallbackHandler
> >>>> .__stateChanged(LifecycleCallbackHandler.java:156)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo
> >>>> .handlers
> >>>> .lifecycle
> >>>> .callback
> >>>> .LifecycleCallbackHandler
> >>>> .stateChanged(LifecycleCallbackHandler.java)
> >>>> at
> >>>> org
> >>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> >>>> 440)
> >>>> at
> >>>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:
> >>>> 321)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> >>>> 155)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> >>>> 298)
> >>>> at
> >>>> org
> >>>> .apache
> >>>> .felix
> >>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> >>>> 235)
> >>>> at
> >>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> >>>> at org.apache.felix.cm.impl.ConfigurationManager
> >>>> $UpdateConfiguration.run(ConfigurationManager.java:1460)
> >>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Clement Escoffier <cl...@gmail.com>.
On 23.09.2009, at 19:33, Joel Schuster wrote:
> As a side note... might this be a problem with the @Provides in the
> RxTx service? If the default strategy is SINGLETON, how does
> multiple cfg files create multiple instances? Or is this just
> referring to the factory?
The singleton policy just says that each iPOJO instance will have one
one service object. But you can have several iPOJO instance (each with
one service object). However, be care if you use statics (because they
are shared.)
Clement
>
> - Joel
>
>> -----Original Message-----
>> From: Joel Schuster [mailto:joels@Navsys.com]
>> Sent: Wednesday, September 23, 2009 11:03 AM
>> To: 'users@felix.apache.org'
>> Subject: RE: @Requires : ServiceFactory.getService() resulted in a
>> cycle.
>>
>> Clement,
>>
>> I have an rxtx bundle. I use cfg files to create one or more ipojo
>> instances of my rxtx service. These cfg files have stuff like baud,
>> parity, com port name, etc.
>>
>> I have another bundle that uses just one of those, I get the list
>> of all
>> of them and then pick one based on a property within the rxtx
>> service also
>> configured by the cfg files.
>>
>> So:
>>
>> KNClient (instance from cfg file)
>> |
>> V
>> <uses one of x number based on property set in rxtx cfg file>
>> |
>> V
>> SerialRxTx (instances from cfg files)
>>
>> I tried putting immediate=true on the RxTx service, however the cfg
>> files
>> no longer were setting the properties and the arch command no longer
>> showed any instances being created even though the constructor for
>> the
>> service was being called. As the KNClient is not a service, just a
>> component, it is automatically immediate.
>>
>> Thanks for your help!
>>
>> - Joel
>>
>>> -----Original Message-----
>>> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
>>> Sent: Wednesday, September 23, 2009 12:53 AM
>>> To: users@felix.apache.org
>>> Subject: Re: @Requires : ServiceFactory.getService() resulted in a
>> cycle.
>>>
>>> Hi,
>>>
>>> It sounds like a cycle during object creation. iPOJO object are
>>> created when needed by default (if your component provides a
>>> service).
>>> To handle that iPOJO uses OSGi service factories.
>>>
>>> The problem sounds to be the following:
>>> - a service is going to be used
>>> - iPOJO creates the pojo object (because, we need it)
>>> - this object can also depending on a service, which may use the one
>>> of the previous ones.... Cycle
>>>
>>> To break the cycle, you can set one component to immediate. In that
>>> case, the object will be created eagerly. the big question is :
>>> Which
>>> ones.
>>>
>>> If you gives me more detail on your system, I can figure out how to
>>> break the cycle.
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>> On 22.09.2009, at 23:21, Joel Schuster wrote:
>>>
>>>>
>>>>
>>>> I hate sending stack traces but I'm running into a real nasty
>>>> issue.
>>>> I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
>>>> tried various forms of the @Requires annotation.
>>>>
>>>> This problem is sometimes reproducible on two systems but not on
>>>> the
>>>> third so I'm beginning to suspect a race condition of some sort as
>>>> it only manifests some of the time and is sometimes dependant upon
>>>> the order of the bundle loading.
>>>>
>>>> I have one bundle that @Requires a collection of instances from
>>>> another bundle that implements two different interfaces, also each
>>>> in their own bundles. I've created a test set of bundles to see if
>>>> the problem comes from the inheritance model, but I can't reproduce
>>>> in a smaller example. Yet another reason it feels like a race
>>>> condition.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>> -> ERROR: EventDispatcher: Error during dispatch.
>>>> (java.lang.IllegalStateException: ServiceFactory.getService()
>>>> resulted in a cycle.)
>>>> java.lang.IllegalStateException: ServiceFactory.getService()
>>>> resulted in a cycle.
>>>> at
>>>> org
>>>> .apache
>>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>>> 261)
>>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>>> 357)
>>>> at
>>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>>> 260)
>>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
>>>> 434)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo.util.DependencyModel.ungetService(DependencyModel.java:
>>>> 917)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:
>>>> 435)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo.util.DependencyModel.removedService(DependencyModel.java:
>>>> 424)
>>>> at org.apache.felix.ipojo.util.Tracker
>>>> $Tracked.untrack(Tracker.java:
>>>> 736)
>>>> at org.apache.felix.ipojo.util.Tracker
>>>> $Tracked.serviceChanged(Tracker.java:636)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .util
>>>> .EventDispatcher
>>>> .invokeServiceListenerCallback(EventDispatcher.java:
>>>> 878)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:
>>>> 732)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>>> at
>>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
>>>> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
>>>> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:
>>>> 624)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:
>>>> 117)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:
>>>> 128)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .providedservice
>>>> .ProvidedService.unregisterService(ProvidedService.java:298)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .providedservice
>>>> .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
>>>> 435)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .providedservice
>>>> .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
>>>> at
>>>> org
>>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>>> 451)
>>>> at
>>>> org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
>>>> 340)
>>>> at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .configuration
>>>> .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .configuration
>>>> .ConfigurationHandler.onCreation(ConfigurationHandler.java)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
>>>> 787)
>>>> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
>>>> $SingletonStrategy.getService(ProvidedService.java:438)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .providedservice.ProvidedService.getService(ProvidedService.java:
>>>> 263)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .ServiceRegistrationImpl
>>>> .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework
>>>> .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:
>>>> 207)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:
>>>> 307)
>>>> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .framework.BundleContextImpl.getService(BundleContextImpl.java:
>>>> 357)
>>>> at
>>>> org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
>>>> 260)
>>>> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:
>>>> 426)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:
>>>> 901)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .dependency.Dependency.createServiceObject(Dependency.java:
>>>> 481)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:
>>>> 456)
>>>> at
>>>> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:
>>>> 944)
>>>> at
>>>> com
>>>> .navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
>>>> at
>>>> com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:
>>>> 49)
>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>> Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeConstructorAccessorImpl
>>>> .newInstance(NativeConstructorAccessorImpl.java:39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingConstructorAccessorImpl
>>>> .newInstance(DelegatingConstructorAccessorImpl.java:27)
>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:
>>>> 776)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .lifecycle
>>>> .callback
>>>> .LifecycleCallbackHandler
>>>> .__stateChanged(LifecycleCallbackHandler.java:156)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo
>>>> .handlers
>>>> .lifecycle
>>>> .callback
>>>> .LifecycleCallbackHandler
>>>> .stateChanged(LifecycleCallbackHandler.java)
>>>> at
>>>> org
>>>> .apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
>>>> 440)
>>>> at
>>>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:
>>>> 321)
>>>> at
>>>> org
>>>> .apache
>>>> .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
>>>> 155)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>>> 298)
>>>> at
>>>> org
>>>> .apache
>>>> .felix
>>>> .ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
>>>> 235)
>>>> at
>>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
>>>> at org.apache.felix.cm.impl.ConfigurationManager
>>>> $UpdateConfiguration.run(ConfigurationManager.java:1460)
>>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by John Stump <jo...@Navsys.com>.
Sorry, that email wasn't meant for the list....
-----Original Message-----
From: John Stump [mailto:johns@Navsys.com]
Sent: Wednesday, September 23, 2009 11:39 AM
To: 'users@felix.apache.org'
Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
More weird stuff.
When I set the strategy to "instance":
I don't get the cycle exception, but I get a no port found exception, which is correct because I don't have the sensor connected. However, if I try to issue another command, the rxtx instance is gone and my Communications field is null.
When the strategy is not "instance":
I don't see the instance in arch output, *but* I can continue to use the rxtx bundle over and over, producing the same no port exception.
-----Original Message-----
From: Joel Schuster [mailto:joels@Navsys.com]
Sent: Wednesday, September 23, 2009 11:33 AM
To: 'users@felix.apache.org'
Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
As a side note... might this be a problem with the @Provides in the RxTx service? If the default strategy is SINGLETON, how does multiple cfg files create multiple instances? Or is this just referring to the factory?
- Joel
> -----Original Message-----
> From: Joel Schuster [mailto:joels@Navsys.com]
> Sent: Wednesday, September 23, 2009 11:03 AM
> To: 'users@felix.apache.org'
> Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
>
> Clement,
>
> I have an rxtx bundle. I use cfg files to create one or more ipojo
> instances of my rxtx service. These cfg files have stuff like baud,
> parity, com port name, etc.
>
> I have another bundle that uses just one of those, I get the list of all
> of them and then pick one based on a property within the rxtx service also
> configured by the cfg files.
>
> So:
>
> KNClient (instance from cfg file)
> |
> V
> <uses one of x number based on property set in rxtx cfg file>
> |
> V
> SerialRxTx (instances from cfg files)
>
> I tried putting immediate=true on the RxTx service, however the cfg files
> no longer were setting the properties and the arch command no longer
> showed any instances being created even though the constructor for the
> service was being called. As the KNClient is not a service, just a
> component, it is automatically immediate.
>
> Thanks for your help!
>
> - Joel
>
> > -----Original Message-----
> > From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> > Sent: Wednesday, September 23, 2009 12:53 AM
> > To: users@felix.apache.org
> > Subject: Re: @Requires : ServiceFactory.getService() resulted in a
> cycle.
> >
> > Hi,
> >
> > It sounds like a cycle during object creation. iPOJO object are
> > created when needed by default (if your component provides a service).
> > To handle that iPOJO uses OSGi service factories.
> >
> > The problem sounds to be the following:
> > - a service is going to be used
> > - iPOJO creates the pojo object (because, we need it)
> > - this object can also depending on a service, which may use the one
> > of the previous ones.... Cycle
> >
> > To break the cycle, you can set one component to immediate. In that
> > case, the object will be created eagerly. the big question is : Which
> > ones.
> >
> > If you gives me more detail on your system, I can figure out how to
> > break the cycle.
> >
> > Regards,
> >
> > Clement
> >
> > On 22.09.2009, at 23:21, Joel Schuster wrote:
> >
> > >
> > >
> > > I hate sending stack traces but I'm running into a real nasty issue.
> > > I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> > > tried various forms of the @Requires annotation.
> > >
> > > This problem is sometimes reproducible on two systems but not on the
> > > third so I'm beginning to suspect a race condition of some sort as
> > > it only manifests some of the time and is sometimes dependant upon
> > > the order of the bundle loading.
> > >
> > > I have one bundle that @Requires a collection of instances from
> > > another bundle that implements two different interfaces, also each
> > > in their own bundles. I've created a test set of bundles to see if
> > > the problem comes from the inheritance model, but I can't reproduce
> > > in a smaller example. Yet another reason it feels like a race
> > > condition.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > >
> > > -> ERROR: EventDispatcher: Error during dispatch.
> > > (java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.)
> > > java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> > > 917)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
> > > at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:
> > > 736)
> > > at org.apache.felix.ipojo.util.Tracker
> > > $Tracked.serviceChanged(Tracker.java:636)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util
> > > .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
> > > 878)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> > > at
> > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> > > at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> > > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedService.unregisterService(ProvidedService.java:298)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> > > 435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 451)
> > > at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> > > 340)
> > > at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
> > > at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> > > $SingletonStrategy.getService(ProvidedService.java:438)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice.ProvidedService.getService(ProvidedService.java:263)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl
> > > .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers.dependency.Dependency.createServiceObject(Dependency.java:
> > > 481)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
> > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > > at
> > > sun
> > > .reflect
> > > .NativeConstructorAccessorImpl
> > > .newInstance(NativeConstructorAccessorImpl.java:39)
> > > at
> > > sun
> > > .reflect
> > > .DelegatingConstructorAccessorImpl
> > > .newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler
> > > .__stateChanged(LifecycleCallbackHandler.java:156)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 440)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> > > 155)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 298)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 235)
> > > at
> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> > > at org.apache.felix.cm.impl.ConfigurationManager
> > > $UpdateConfiguration.run(ConfigurationManager.java:1460)
> > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by John Stump <jo...@Navsys.com>.
More weird stuff.
When I set the strategy to "instance":
I don't get the cycle exception, but I get a no port found exception, which is correct because I don't have the sensor connected. However, if I try to issue another command, the rxtx instance is gone and my Communications field is null.
When the strategy is not "instance":
I don't see the instance in arch output, *but* I can continue to use the rxtx bundle over and over, producing the same no port exception.
-----Original Message-----
From: Joel Schuster [mailto:joels@Navsys.com]
Sent: Wednesday, September 23, 2009 11:33 AM
To: 'users@felix.apache.org'
Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
As a side note... might this be a problem with the @Provides in the RxTx service? If the default strategy is SINGLETON, how does multiple cfg files create multiple instances? Or is this just referring to the factory?
- Joel
> -----Original Message-----
> From: Joel Schuster [mailto:joels@Navsys.com]
> Sent: Wednesday, September 23, 2009 11:03 AM
> To: 'users@felix.apache.org'
> Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
>
> Clement,
>
> I have an rxtx bundle. I use cfg files to create one or more ipojo
> instances of my rxtx service. These cfg files have stuff like baud,
> parity, com port name, etc.
>
> I have another bundle that uses just one of those, I get the list of all
> of them and then pick one based on a property within the rxtx service also
> configured by the cfg files.
>
> So:
>
> KNClient (instance from cfg file)
> |
> V
> <uses one of x number based on property set in rxtx cfg file>
> |
> V
> SerialRxTx (instances from cfg files)
>
> I tried putting immediate=true on the RxTx service, however the cfg files
> no longer were setting the properties and the arch command no longer
> showed any instances being created even though the constructor for the
> service was being called. As the KNClient is not a service, just a
> component, it is automatically immediate.
>
> Thanks for your help!
>
> - Joel
>
> > -----Original Message-----
> > From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> > Sent: Wednesday, September 23, 2009 12:53 AM
> > To: users@felix.apache.org
> > Subject: Re: @Requires : ServiceFactory.getService() resulted in a
> cycle.
> >
> > Hi,
> >
> > It sounds like a cycle during object creation. iPOJO object are
> > created when needed by default (if your component provides a service).
> > To handle that iPOJO uses OSGi service factories.
> >
> > The problem sounds to be the following:
> > - a service is going to be used
> > - iPOJO creates the pojo object (because, we need it)
> > - this object can also depending on a service, which may use the one
> > of the previous ones.... Cycle
> >
> > To break the cycle, you can set one component to immediate. In that
> > case, the object will be created eagerly. the big question is : Which
> > ones.
> >
> > If you gives me more detail on your system, I can figure out how to
> > break the cycle.
> >
> > Regards,
> >
> > Clement
> >
> > On 22.09.2009, at 23:21, Joel Schuster wrote:
> >
> > >
> > >
> > > I hate sending stack traces but I'm running into a real nasty issue.
> > > I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> > > tried various forms of the @Requires annotation.
> > >
> > > This problem is sometimes reproducible on two systems but not on the
> > > third so I'm beginning to suspect a race condition of some sort as
> > > it only manifests some of the time and is sometimes dependant upon
> > > the order of the bundle loading.
> > >
> > > I have one bundle that @Requires a collection of instances from
> > > another bundle that implements two different interfaces, also each
> > > in their own bundles. I've created a test set of bundles to see if
> > > the problem comes from the inheritance model, but I can't reproduce
> > > in a smaller example. Yet another reason it feels like a race
> > > condition.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > >
> > > -> ERROR: EventDispatcher: Error during dispatch.
> > > (java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.)
> > > java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> > > 917)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
> > > at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:
> > > 736)
> > > at org.apache.felix.ipojo.util.Tracker
> > > $Tracked.serviceChanged(Tracker.java:636)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util
> > > .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
> > > 878)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> > > at
> > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> > > at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> > > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedService.unregisterService(ProvidedService.java:298)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> > > 435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 451)
> > > at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> > > 340)
> > > at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
> > > at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> > > $SingletonStrategy.getService(ProvidedService.java:438)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice.ProvidedService.getService(ProvidedService.java:263)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl
> > > .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers.dependency.Dependency.createServiceObject(Dependency.java:
> > > 481)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
> > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > > at
> > > sun
> > > .reflect
> > > .NativeConstructorAccessorImpl
> > > .newInstance(NativeConstructorAccessorImpl.java:39)
> > > at
> > > sun
> > > .reflect
> > > .DelegatingConstructorAccessorImpl
> > > .newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler
> > > .__stateChanged(LifecycleCallbackHandler.java:156)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 440)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> > > 155)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 298)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 235)
> > > at
> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> > > at org.apache.felix.cm.impl.ConfigurationManager
> > > $UpdateConfiguration.run(ConfigurationManager.java:1460)
> > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Joel Schuster <jo...@Navsys.com>.
As a side note... might this be a problem with the @Provides in the RxTx service? If the default strategy is SINGLETON, how does multiple cfg files create multiple instances? Or is this just referring to the factory?
- Joel
> -----Original Message-----
> From: Joel Schuster [mailto:joels@Navsys.com]
> Sent: Wednesday, September 23, 2009 11:03 AM
> To: 'users@felix.apache.org'
> Subject: RE: @Requires : ServiceFactory.getService() resulted in a cycle.
>
> Clement,
>
> I have an rxtx bundle. I use cfg files to create one or more ipojo
> instances of my rxtx service. These cfg files have stuff like baud,
> parity, com port name, etc.
>
> I have another bundle that uses just one of those, I get the list of all
> of them and then pick one based on a property within the rxtx service also
> configured by the cfg files.
>
> So:
>
> KNClient (instance from cfg file)
> |
> V
> <uses one of x number based on property set in rxtx cfg file>
> |
> V
> SerialRxTx (instances from cfg files)
>
> I tried putting immediate=true on the RxTx service, however the cfg files
> no longer were setting the properties and the arch command no longer
> showed any instances being created even though the constructor for the
> service was being called. As the KNClient is not a service, just a
> component, it is automatically immediate.
>
> Thanks for your help!
>
> - Joel
>
> > -----Original Message-----
> > From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> > Sent: Wednesday, September 23, 2009 12:53 AM
> > To: users@felix.apache.org
> > Subject: Re: @Requires : ServiceFactory.getService() resulted in a
> cycle.
> >
> > Hi,
> >
> > It sounds like a cycle during object creation. iPOJO object are
> > created when needed by default (if your component provides a service).
> > To handle that iPOJO uses OSGi service factories.
> >
> > The problem sounds to be the following:
> > - a service is going to be used
> > - iPOJO creates the pojo object (because, we need it)
> > - this object can also depending on a service, which may use the one
> > of the previous ones.... Cycle
> >
> > To break the cycle, you can set one component to immediate. In that
> > case, the object will be created eagerly. the big question is : Which
> > ones.
> >
> > If you gives me more detail on your system, I can figure out how to
> > break the cycle.
> >
> > Regards,
> >
> > Clement
> >
> > On 22.09.2009, at 23:21, Joel Schuster wrote:
> >
> > >
> > >
> > > I hate sending stack traces but I'm running into a real nasty issue.
> > > I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> > > tried various forms of the @Requires annotation.
> > >
> > > This problem is sometimes reproducible on two systems but not on the
> > > third so I'm beginning to suspect a race condition of some sort as
> > > it only manifests some of the time and is sometimes dependant upon
> > > the order of the bundle loading.
> > >
> > > I have one bundle that @Requires a collection of instances from
> > > another bundle that implements two different interfaces, also each
> > > in their own bundles. I've created a test set of bundles to see if
> > > the problem comes from the inheritance model, but I can't reproduce
> > > in a smaller example. Yet another reason it feels like a race
> > > condition.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > >
> > > -> ERROR: EventDispatcher: Error during dispatch.
> > > (java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.)
> > > java.lang.IllegalStateException: ServiceFactory.getService()
> > > resulted in a cycle.
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> > > 917)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
> > > at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:
> > > 736)
> > > at org.apache.felix.ipojo.util.Tracker
> > > $Tracked.serviceChanged(Tracker.java:636)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util
> > > .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
> > > 878)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> > > at
> > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> > > at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> > > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedService.unregisterService(ProvidedService.java:298)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> > > 435)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice
> > > .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 451)
> > > at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> > > 340)
> > > at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .configuration
> > > .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
> > > at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> > > $SingletonStrategy.getService(ProvidedService.java:438)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .providedservice.ProvidedService.getService(ProvidedService.java:263)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl
> > > .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .framework
> > > .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
> > > at
> > > org
> > > .apache
> > > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
> > > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > > at
> > > org
> > > .apache
> > > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > > 357)
> > > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > > 260)
> > > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers.dependency.Dependency.createServiceObject(Dependency.java:
> > > 481)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> > > at
> > > com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
> > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > > at
> > > sun
> > > .reflect
> > > .NativeConstructorAccessorImpl
> > > .newInstance(NativeConstructorAccessorImpl.java:39)
> > > at
> > > sun
> > > .reflect
> > > .DelegatingConstructorAccessorImpl
> > > .newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler
> > > .__stateChanged(LifecycleCallbackHandler.java:156)
> > > at
> > > org
> > > .apache
> > > .felix
> > > .ipojo
> > > .handlers
> > > .lifecycle
> > > .callback
> > > .LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > > 440)
> > > at
> > > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> > > 155)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 298)
> > > at
> > > org
> > > .apache
> > > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > > 235)
> > > at
> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> > > at org.apache.felix.cm.impl.ConfigurationManager
> > > $UpdateConfiguration.run(ConfigurationManager.java:1460)
> > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Joel Schuster <jo...@Navsys.com>.
Clement,
I have an rxtx bundle. I use cfg files to create one or more ipojo instances of my rxtx service. These cfg files have stuff like baud, parity, com port name, etc.
I have another bundle that uses just one of those, I get the list of all of them and then pick one based on a property within the rxtx service also configured by the cfg files.
So:
KNClient (instance from cfg file)
|
V
<uses one of x number based on property set in rxtx cfg file>
|
V
SerialRxTx (instances from cfg files)
I tried putting immediate=true on the RxTx service, however the cfg files no longer were setting the properties and the arch command no longer showed any instances being created even though the constructor for the service was being called. As the KNClient is not a service, just a component, it is automatically immediate.
Thanks for your help!
- Joel
> -----Original Message-----
> From: Clement Escoffier [mailto:clement.escoffier@gmail.com]
> Sent: Wednesday, September 23, 2009 12:53 AM
> To: users@felix.apache.org
> Subject: Re: @Requires : ServiceFactory.getService() resulted in a cycle.
>
> Hi,
>
> It sounds like a cycle during object creation. iPOJO object are
> created when needed by default (if your component provides a service).
> To handle that iPOJO uses OSGi service factories.
>
> The problem sounds to be the following:
> - a service is going to be used
> - iPOJO creates the pojo object (because, we need it)
> - this object can also depending on a service, which may use the one
> of the previous ones.... Cycle
>
> To break the cycle, you can set one component to immediate. In that
> case, the object will be created eagerly. the big question is : Which
> ones.
>
> If you gives me more detail on your system, I can figure out how to
> break the cycle.
>
> Regards,
>
> Clement
>
> On 22.09.2009, at 23:21, Joel Schuster wrote:
>
> >
> >
> > I hate sending stack traces but I'm running into a real nasty issue.
> > I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> > tried various forms of the @Requires annotation.
> >
> > This problem is sometimes reproducible on two systems but not on the
> > third so I'm beginning to suspect a race condition of some sort as
> > it only manifests some of the time and is sometimes dependant upon
> > the order of the bundle loading.
> >
> > I have one bundle that @Requires a collection of instances from
> > another bundle that implements two different interfaces, also each
> > in their own bundles. I've created a test set of bundles to see if
> > the problem comes from the inheritance model, but I can't reproduce
> > in a smaller example. Yet another reason it feels like a race
> > condition.
> >
> > Thoughts?
> >
> >
> >
> >
> > -> ERROR: EventDispatcher: Error during dispatch.
> > (java.lang.IllegalStateException: ServiceFactory.getService()
> > resulted in a cycle.)
> > java.lang.IllegalStateException: ServiceFactory.getService()
> > resulted in a cycle.
> > at
> > org
> > .apache
> > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
> > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > at
> > org
> > .apache
> > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > 357)
> > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > 260)
> > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
> > at
> > org
> > .apache
> > .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> > 917)
> > at
> > org
> > .apache
> > .felix
> > .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
> > at
> > org
> > .apache
> > .felix
> > .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
> > at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:
> > 736)
> > at org.apache.felix.ipojo.util.Tracker
> > $Tracked.serviceChanged(Tracker.java:636)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .util
> > .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
> > 878)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> > at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> > at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
> > at
> > org
> > .apache
> > .felix
> > .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .providedservice
> > .ProvidedService.unregisterService(ProvidedService.java:298)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .providedservice
> > .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> > 435)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .providedservice
> > .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> > at
> > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > 451)
> > at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> > 340)
> > at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .configuration
> > .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .configuration
> > .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> > at
> > org
> > .apache
> > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
> > at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> > $SingletonStrategy.getService(ProvidedService.java:438)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .providedservice.ProvidedService.getService(ProvidedService.java:263)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .ServiceRegistrationImpl
> > .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> > at
> > org
> > .apache
> > .felix
> > .framework
> > .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
> > at
> > org
> > .apache
> > .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
> > at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> > at
> > org
> > .apache
> > .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> > 357)
> > at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> > 260)
> > at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
> > at
> > org
> > .apache
> > .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers.dependency.Dependency.createServiceObject(Dependency.java:
> > 481)
> > at
> > org
> > .apache
> > .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
> > at
> > org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
> > at
> > com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> > at
> > com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> > sun
> > .reflect
> > .NativeConstructorAccessorImpl
> > .newInstance(NativeConstructorAccessorImpl.java:39)
> > at
> > sun
> > .reflect
> > .DelegatingConstructorAccessorImpl
> > .newInstance(DelegatingConstructorAccessorImpl.java:27)
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > at
> > org
> > .apache
> > .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> > at
> > org
> > .apache
> > .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .lifecycle
> > .callback
> > .LifecycleCallbackHandler
> > .__stateChanged(LifecycleCallbackHandler.java:156)
> > at
> > org
> > .apache
> > .felix
> > .ipojo
> > .handlers
> > .lifecycle
> > .callback
> > .LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
> > at
> > org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> > 440)
> > at
> > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
> > at
> > org
> > .apache
> > .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> > 155)
> > at
> > org
> > .apache
> > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > 298)
> > at
> > org
> > .apache
> > .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> > 235)
> > at
> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> > at org.apache.felix.cm.impl.ConfigurationManager
> > $UpdateConfiguration.run(ConfigurationManager.java:1460)
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: @Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
It sounds like a cycle during object creation. iPOJO object are
created when needed by default (if your component provides a service).
To handle that iPOJO uses OSGi service factories.
The problem sounds to be the following:
- a service is going to be used
- iPOJO creates the pojo object (because, we need it)
- this object can also depending on a service, which may use the one
of the previous ones.... Cycle
To break the cycle, you can set one component to immediate. In that
case, the object will be created eagerly. the big question is : Which
ones.
If you gives me more detail on your system, I can figure out how to
break the cycle.
Regards,
Clement
On 22.09.2009, at 23:21, Joel Schuster wrote:
>
>
> I hate sending stack traces but I'm running into a real nasty issue.
> I've tried both Felix 1.8.x and 2.0. I get the same issue. I've
> tried various forms of the @Requires annotation.
>
> This problem is sometimes reproducible on two systems but not on the
> third so I'm beginning to suspect a race condition of some sort as
> it only manifests some of the time and is sometimes dependant upon
> the order of the bundle loading.
>
> I have one bundle that @Requires a collection of instances from
> another bundle that implements two different interfaces, also each
> in their own bundles. I've created a test set of bundles to see if
> the problem comes from the inheritance model, but I can't reproduce
> in a smaller example. Yet another reason it feels like a race
> condition.
>
> Thoughts?
>
>
>
>
> -> ERROR: EventDispatcher: Error during dispatch.
> (java.lang.IllegalStateException: ServiceFactory.getService()
> resulted in a cycle.)
> java.lang.IllegalStateException: ServiceFactory.getService()
> resulted in a cycle.
> at
> org
> .apache
> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> at
> org
> .apache
> .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> 357)
> at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> 260)
> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
> at
> org
> .apache
> .felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:
> 917)
> at
> org
> .apache
> .felix
> .ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
> at
> org
> .apache
> .felix
> .ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
> at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:
> 736)
> at org.apache.felix.ipojo.util.Tracker
> $Tracked.serviceChanged(Tracker.java:636)
> at
> org
> .apache
> .felix
> .framework
> .util
> .EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:
> 878)
> at
> org
> .apache
> .felix
> .framework
> .util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
> at
> org
> .apache
> .felix
> .framework
> .util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
> at org.apache.felix.framework.Felix.access$000(Felix.java:40)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
> at
> org
> .apache
> .felix
> .framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
> at
> org
> .apache
> .felix
> .framework
> .ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .providedservice
> .ProvidedService.unregisterService(ProvidedService.java:298)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .providedservice
> .ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:
> 435)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .providedservice
> .ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
> at
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> 451)
> at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:
> 340)
> at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .configuration
> .ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .configuration
> .ConfigurationHandler.onCreation(ConfigurationHandler.java)
> at
> org
> .apache
> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
> at org.apache.felix.ipojo.handlers.providedservice.ProvidedService
> $SingletonStrategy.getService(ProvidedService.java:438)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .providedservice.ProvidedService.getService(ProvidedService.java:263)
> at
> org
> .apache
> .felix
> .framework
> .ServiceRegistrationImpl
> .getFactoryUnchecked(ServiceRegistrationImpl.java:293)
> at
> org
> .apache
> .felix
> .framework
> .ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
> at
> org
> .apache
> .felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
> at org.apache.felix.framework.Felix.getService(Felix.java:2881)
> at
> org
> .apache
> .felix.framework.BundleContextImpl.getService(BundleContextImpl.java:
> 357)
> at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:
> 260)
> at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
> at
> org
> .apache
> .felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers.dependency.Dependency.createServiceObject(Dependency.java:
> 481)
> at
> org
> .apache
> .felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
> at
> org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
> at
> com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
> at
> com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun
> .reflect
> .NativeConstructorAccessorImpl
> .newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingConstructorAccessorImpl
> .newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org
> .apache
> .felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
> at
> org
> .apache
> .felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .lifecycle
> .callback
> .LifecycleCallbackHandler
> .__stateChanged(LifecycleCallbackHandler.java:156)
> at
> org
> .apache
> .felix
> .ipojo
> .handlers
> .lifecycle
> .callback
> .LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
> at
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:
> 440)
> at
> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
> at
> org
> .apache
> .felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:
> 155)
> at
> org
> .apache
> .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> 298)
> at
> org
> .apache
> .felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:
> 235)
> at org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
> at org.apache.felix.cm.impl.ConfigurationManager
> $UpdateConfiguration.run(ConfigurationManager.java:1460)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
@Requires : ServiceFactory.getService() resulted in a cycle.
Posted by Joel Schuster <jo...@Navsys.com>.
I hate sending stack traces but I'm running into a real nasty issue. I've tried both Felix 1.8.x and 2.0. I get the same issue. I've tried various forms of the @Requires annotation.
This problem is sometimes reproducible on two systems but not on the third so I'm beginning to suspect a race condition of some sort as it only manifests some of the time and is sometimes dependant upon the order of the bundle loading.
I have one bundle that @Requires a collection of instances from another bundle that implements two different interfaces, also each in their own bundles. I've created a test set of bundles to see if the problem comes from the inheritance model, but I can't reproduce in a smaller example. Yet another reason it feels like a race condition.
Thoughts?
-> ERROR: EventDispatcher: Error during dispatch. (java.lang.IllegalStateException: ServiceFactory.getService() resulted in a cycle.)
java.lang.IllegalStateException: ServiceFactory.getService() resulted in a cycle.
at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:261)
at org.apache.felix.framework.Felix.getService(Felix.java:2881)
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:357)
at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:260)
at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:434)
at org.apache.felix.ipojo.util.DependencyModel.ungetService(DependencyModel.java:917)
at org.apache.felix.ipojo.util.DependencyModel.manageDeparture(DependencyModel.java:435)
at org.apache.felix.ipojo.util.DependencyModel.removedService(DependencyModel.java:424)
at org.apache.felix.ipojo.util.Tracker$Tracked.untrack(Tracker.java:736)
at org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:636)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603)
at org.apache.felix.framework.Felix.access$000(Felix.java:40)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624)
at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:117)
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:128)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.unregisterService(ProvidedService.java:298)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:435)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java)
at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:451)
at org.apache.felix.ipojo.InstanceManager.stop(InstanceManager.java:340)
at org.apache.felix.ipojo.util.Property.invoke(Property.java:502)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.__onCreation(ConfigurationHandler.java:432)
at org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.onCreation(ConfigurationHandler.java)
at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:787)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedService$SingletonStrategy.getService(ProvidedService.java:438)
at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.getService(ProvidedService.java:263)
at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:293)
at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:207)
at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:307)
at org.apache.felix.framework.Felix.getService(Felix.java:2881)
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:357)
at org.apache.felix.ipojo.IPojoContext.getService(IPojoContext.java:260)
at org.apache.felix.ipojo.util.Tracker.getService(Tracker.java:426)
at org.apache.felix.ipojo.util.DependencyModel.getService(DependencyModel.java:901)
at org.apache.felix.ipojo.handlers.dependency.Dependency.createServiceObject(Dependency.java:481)
at org.apache.felix.ipojo.handlers.dependency.Dependency.onGet(Dependency.java:456)
at org.apache.felix.ipojo.InstanceManager.onGet(InstanceManager.java:944)
at com.navsys.mcmpge.kearfott.knclient.KNClient.__getcomms(KNClient.java)
at com.navsys.mcmpge.kearfott.knclient.KNClient.<init>(KNClient.java:49)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.felix.ipojo.InstanceManager.createObject(InstanceManager.java:600)
at org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:776)
at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged(LifecycleCallbackHandler.java:156)
at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:440)
at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:321)
at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:155)
at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:298)
at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:235)
at org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:603)
at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1460)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/23/09 0:52, Matthias Neubert wrote:
> So congratulations from me, if this leads us to have solved it
> completly, you and felix contributors solved a problem
> which the ProSyst Android Edition wasn't able to solve. So Felix is
> the best choice for Android.
Maybe we should start a "testimonials" page... ;-)
-> richard
>
> regards
> Matthias
>
>
>
> Am 22.09.2009 um 22:42 schrieb Karl Pauls:
>
>> On Tue, Sep 22, 2009 at 10:22 PM, Karl Pauls <ka...@gmail.com>
>> wrote:
>>> On Tue, Sep 22, 2009 at 9:28 PM, Matthias Neubert
>>> <su...@onlinehome.de> wrote:
>>>> Hello,
>>>>
>>>> I tried your advice, but it still doesn't work, but the error
>>>> changed a bit:
>>>>
>>>> Current Configuration:
>>>>
>>>> no use of boot delegation
>>>
>>> You have to keep the bootdelegation as you have it except remove the
>>> com.google.* and then add the packages I told you in the last mail.
>>> That did make it work for me until the NullPointer which didn't look
>>> like it is felix releated.
>>
>> Correction, I figured out the problem. Bootdelegation does work
>> correctly. All you have to do is use "framework" instead of "app".
>> That gets me to the mentioned Nullpointer with bootdelegation (you
>> still need the implicit=false so).
>>
>> regards,
>>
>> Karl
>>
>>> regards,
>>>
>>> Karl
>>>
>>>> configProps.put("felix.bootdelegation.implicit", "false");
>>>>
>>>> system.packages.extra contains among other the following
>>>> maps.jar-Packages:
>>>> "com.google.android.maps; " +
>>>> "com.google.android.xmppService; " +
>>>> "com.google.googlenav.map; " +
>>>> "com.google.common;" +
>>>> "com.google.map;"
>>>>
>>>>
>>>> Error:
>>>>
>>>> It remains the basic error:
>>>>
>>>> java.lang.LinkageError: Classes resolve differently in superclass
>>>>
>>>> but he now adds:
>>>>
>>>> Method mismatch: setup in
>>>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;
>>>> (cl=0x43891310) and
>>>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>>>>
>>>>
>>>> Error:
>>>>
>>>> 09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>>>> android.graphics.drawable -> 0
>>>> 09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>>>> android.util -> 0
>>>> 09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>>>> android.location -> 0
>>>> 09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>>>> com.google.googlenav.map -> 0
>>>> 09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in
>>>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;
>>>> (cl=0x43891310) and
>>>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>>>> 09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
>>>> 09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting
>>>> with
>>>> uncaught exception (group=0x4001aa28)
>>>> 09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler:
>>>> thread main
>>>> exiting due to uncaught exception
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): java.lang.LinkageError:
>>>> Classes resolve differently in superclass
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:112)
>>>>
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> android.os.Handler.handleCallback(Handler.java:587)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> android.os.Handler.dispatchMessage(Handler.java:92)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> android.os.Looper.loop(Looper.java:123)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> android.app.ActivityThread.main(ActivityThread.java:4203)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> java.lang.reflect.Method.invokeNative(Native Method)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> java.lang.reflect.Method.invoke(Method.java:521)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
>>>>
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
>>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>>> dalvik.system.NativeStart.main(Native Method)
>>>>
>>>>
>>>>
>>>> I will now add to export list just all Packages maps.jar has (I did
>>>> so for
>>>> android.jar) but I'm afraid that this will not change
>>>> the situation. I'm still hoping that you will find a workaround for
>>>> the
>>>> bootdelegation in order to see if this solves the problem.
>>>>
>>>> regards
>>>> Matthias
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 22.09.2009 um 19:06 schrieb Karl Pauls:
>>>>
>>>>> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert
>>>>> <su...@onlinehome.de>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> additional info: setting the Imports of the using Bundles to
>>>>>>
>>>>>> DynamicImport-Package: android.*, com.google.*
>>>>>>
>>>>>> does NOT solve the problem.
>>>>>
>>>>> It does for me, but you are missing some exports from the system
>>>>> bundle
>>>>> namely,
>>>>>
>>>>> com.google.android.maps
>>>>> com.google.googlenav.map
>>>>> com.google.common
>>>>> com.google.map
>>>>>
>>>>> if I add those plus implict=false and not bootdelegating com.google.*
>>>>> the app starts for me and if I hit the button I get a NullPointer
>>>>> somewhere but one that doesn't seem to be releated to felix.
>>>>>
>>>>> Regarding the bootdelegation I think I know what is going on and will
>>>>> try to find a workaround soon. Until then, please let me know whether
>>>>> it works with the above for you now.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>> Changing it has one advantage for me: Now I can
>>>>>> easily switch between
>>>>>> bootdelegation and system.packages.extra without touching the
>>>>>> bundles,
>>>>>> only
>>>>>> by changing the felix configuration.
>>>>>>
>>>>>> I'm looking foreward that we can solve this issue. Important for
>>>>>> me is
>>>>>> what
>>>>>> do you think: will boot delegation be able to solve the underlying
>>>>>> problem?
>>>>>>
>>>>>> regards
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I've tried this combination without success.(he doesn't find the
>>>>>>> class)
>>>>>>> Some minutes ago I mailed to you the requested Eclipse Projects
>>>>>>> for
>>>>>>> testing
>>>>>>> it locally.
>>>>>>>
>>>>>>> I hope there is a way for felix to work around this DalvikVM
>>>>>>> Bug. The
>>>>>>> people from ProSyst seem to have the same problem.[1] I don't
>>>>>>> know if
>>>>>>> they also had the idea solving this by boot delegation, but as
>>>>>>> far as I
>>>>>>> understand the dalvik bug [2], boot delegation instead of
>>>>>>> system.extra
>>>>>>> export will solve the problem.
>>>>>>>
>>>>>>> If not I will have a bigger problem than I ever
>>>>>>> thought.(regarding to my
>>>>>>> diploma thesis)
>>>>>>>
>>>>>>> feel free to experiment with my test-projects.
>>>>>>>
>>>>>>> regards
>>>>>>> Matthias
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>>>>>>
>>>>>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>>>>>
>>>>>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert
>>>>>>>> <su...@onlinehome.de>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I tested
>>>>>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>>>>>> when felix.bootdelegation.implicit=false then he do not find the
>>>>>>>>> class.
>>>>>>>>> When
>>>>>>>>> true, he hang for ever.
>>>>>>>>
>>>>>>>> Well, the latter (i.e., hang for ever) seems to be a bug in
>>>>>>>> android
>>>>>>>> which we didn't anticipate but we might be able to detect this
>>>>>>>> situation and workaround it in felix. The former, however, is
>>>>>>>> not yet
>>>>>>>> clear to me what is going on exactly but please make sure that it
>>>>>>>> doesn't work if you set the bundle.parent to app and the
>>>>>>>> bootdelegation.implicit to false.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>> So no solution from that option. I will try to change my
>>>>>>>>> embedding
>>>>>>>>> using
>>>>>>>>> the
>>>>>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>>>>>> the normal Felix instancing in a standardized manner and so
>>>>>>>>> will not
>>>>>>>>> help.
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>> <he...@ungoverned.org>
>>>>>>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Karl Pauls
>>>>>>>>>>> karlpauls@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> karlpauls@gmail.com
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
You solved it, Karl !!! I thank you so much. If you are ever in
Dresden (Germany) you'll have a place to stay and beer for free!
Configuration:
on host side
- using boot delegation for all android and google maps packages
- using system.packages.extra for exporting packages which are defined
in Hostapplication, and some osgi packages (I still don'tknow if this
is needed)
- configProps.put("org.osgi.framework.bundle.parent", "framework");
- configProps.put("felix.bootdelegation.implicit", "false");
on bundle side
- using Import-Package for the packages exported via
system.packages.extra
- using DynamicImport-Package: android.*, com.google.* for importing
those packages from boot delegation
The null pointer you received after beeing successfull is my fault,
because I made the testbundle
I mailed to you "quick and dirty" and created the subclass of MapView
with passing null in constructor.
So this realy doesn't have anything to do with felix or dalvik.
So congratulations from me, if this leads us to have solved it
completly, you and felix contributors solved a problem
which the ProSyst Android Edition wasn't able to solve. So Felix is
the best choice for Android.
regards
Matthias
Am 22.09.2009 um 22:42 schrieb Karl Pauls:
> On Tue, Sep 22, 2009 at 10:22 PM, Karl Pauls <ka...@gmail.com>
> wrote:
>> On Tue, Sep 22, 2009 at 9:28 PM, Matthias Neubert <sureal@onlinehome.de
>> > wrote:
>>> Hello,
>>>
>>> I tried your advice, but it still doesn't work, but the error
>>> changed a bit:
>>>
>>> Current Configuration:
>>>
>>> no use of boot delegation
>>
>> You have to keep the bootdelegation as you have it except remove the
>> com.google.* and then add the packages I told you in the last mail.
>> That did make it work for me until the NullPointer which didn't look
>> like it is felix releated.
>
> Correction, I figured out the problem. Bootdelegation does work
> correctly. All you have to do is use "framework" instead of "app".
> That gets me to the mentioned Nullpointer with bootdelegation (you
> still need the implicit=false so).
>
> regards,
>
> Karl
>
>> regards,
>>
>> Karl
>>
>>> configProps.put("felix.bootdelegation.implicit", "false");
>>>
>>> system.packages.extra contains among other the following maps.jar-
>>> Packages:
>>> "com.google.android.maps; " +
>>> "com.google.android.xmppService; " +
>>> "com.google.googlenav.map; " +
>>> "com.google.common;" +
>>> "com.google.map;"
>>>
>>>
>>> Error:
>>>
>>> It remains the basic error:
>>>
>>> java.lang.LinkageError: Classes resolve differently in superclass
>>>
>>> but he now adds:
>>>
>>> Method mismatch: setup in
>>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;
>>> (cl=0x43891310) and
>>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>>>
>>>
>>> Error:
>>>
>>> 09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE:
>>> 10.0 ->
>>> android.graphics.drawable -> 0
>>> 09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE:
>>> 10.0 ->
>>> android.util -> 0
>>> 09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE:
>>> 10.0 ->
>>> android.location -> 0
>>> 09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE:
>>> 10.0 ->
>>> com.google.googlenav.map -> 0
>>> 09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in
>>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView;
>>> (cl=0x43891310) and
>>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>>> 09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
>>> 09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting
>>> with
>>> uncaught exception (group=0x4001aa28)
>>> 09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler:
>>> thread main
>>> exiting due to uncaught exception
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751):
>>> java.lang.LinkageError:
>>> Classes resolve differently in superclass
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:
>>> 112)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> android.os.Handler.handleCallback(Handler.java:587)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> android.os.Handler.dispatchMessage(Handler.java:92)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> android.os.Looper.loop(Looper.java:123)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> android.app.ActivityThread.main(ActivityThread.java:4203)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> java.lang.reflect.Method.invokeNative(Native Method)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> java.lang.reflect.Method.invoke(Method.java:521)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> com.android.internal.os.ZygoteInit
>>> $MethodAndArgsCaller.run(ZygoteInit.java:791)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
>>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>>> dalvik.system.NativeStart.main(Native Method)
>>>
>>>
>>>
>>> I will now add to export list just all Packages maps.jar has (I
>>> did so for
>>> android.jar) but I'm afraid that this will not change
>>> the situation. I'm still hoping that you will find a workaround
>>> for the
>>> bootdelegation in order to see if this solves the problem.
>>>
>>> regards
>>> Matthias
>>>
>>>
>>>
>>>
>>>
>>> Am 22.09.2009 um 19:06 schrieb Karl Pauls:
>>>
>>>> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <sureal@onlinehome.de
>>>> >
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> additional info: setting the Imports of the using Bundles to
>>>>>
>>>>> DynamicImport-Package: android.*, com.google.*
>>>>>
>>>>> does NOT solve the problem.
>>>>
>>>> It does for me, but you are missing some exports from the system
>>>> bundle
>>>> namely,
>>>>
>>>> com.google.android.maps
>>>> com.google.googlenav.map
>>>> com.google.common
>>>> com.google.map
>>>>
>>>> if I add those plus implict=false and not bootdelegating
>>>> com.google.*
>>>> the app starts for me and if I hit the button I get a NullPointer
>>>> somewhere but one that doesn't seem to be releated to felix.
>>>>
>>>> Regarding the bootdelegation I think I know what is going on and
>>>> will
>>>> try to find a workaround soon. Until then, please let me know
>>>> whether
>>>> it works with the above for you now.
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>> Changing it has one advantage for me: Now I can
>>>>> easily switch between
>>>>> bootdelegation and system.packages.extra without touching the
>>>>> bundles,
>>>>> only
>>>>> by changing the felix configuration.
>>>>>
>>>>> I'm looking foreward that we can solve this issue. Important for
>>>>> me is
>>>>> what
>>>>> do you think: will boot delegation be able to solve the underlying
>>>>> problem?
>>>>>
>>>>> regards
>>>>> Matthias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I've tried this combination without success.(he doesn't find
>>>>>> the class)
>>>>>> Some minutes ago I mailed to you the requested Eclipse
>>>>>> Projects for
>>>>>> testing
>>>>>> it locally.
>>>>>>
>>>>>> I hope there is a way for felix to work around this DalvikVM
>>>>>> Bug. The
>>>>>> people from ProSyst seem to have the same problem.[1] I don't
>>>>>> know if
>>>>>> they also had the idea solving this by boot delegation, but as
>>>>>> far as I
>>>>>> understand the dalvik bug [2], boot delegation instead of
>>>>>> system.extra
>>>>>> export will solve the problem.
>>>>>>
>>>>>> If not I will have a bigger problem than I ever thought.
>>>>>> (regarding to my
>>>>>> diploma thesis)
>>>>>>
>>>>>> feel free to experiment with my test-projects.
>>>>>>
>>>>>> regards
>>>>>> Matthias
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>>>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>>>>
>>>>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert
>>>>>>> <su...@onlinehome.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I tested
>>>>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>>>>> when felix.bootdelegation.implicit=false then he do not find
>>>>>>>> the
>>>>>>>> class.
>>>>>>>> When
>>>>>>>> true, he hang for ever.
>>>>>>>
>>>>>>> Well, the latter (i.e., hang for ever) seems to be a bug in
>>>>>>> android
>>>>>>> which we didn't anticipate but we might be able to detect this
>>>>>>> situation and workaround it in felix. The former, however, is
>>>>>>> not yet
>>>>>>> clear to me what is going on exactly but please make sure that
>>>>>>> it
>>>>>>> doesn't work if you set the bundle.parent to app and the
>>>>>>> bootdelegation.implicit to false.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>> So no solution from that option. I will try to change my
>>>>>>>> embedding
>>>>>>>> using
>>>>>>>> the
>>>>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>>>>> the normal Felix instancing in a standardized manner and so
>>>>>>>> will not
>>>>>>>> help.
>>>>>>>>
>>>>>>>> regards
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> <he...@ungoverned.org>
>>>>>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Karl Pauls
>>>>>>>>>> karlpauls@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> karlpauls@gmail.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Sep 22, 2009 at 10:22 PM, Karl Pauls <ka...@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 9:28 PM, Matthias Neubert <su...@onlinehome.de> wrote:
>> Hello,
>>
>> I tried your advice, but it still doesn't work, but the error changed a bit:
>>
>> Current Configuration:
>>
>> no use of boot delegation
>
> You have to keep the bootdelegation as you have it except remove the
> com.google.* and then add the packages I told you in the last mail.
> That did make it work for me until the NullPointer which didn't look
> like it is felix releated.
Correction, I figured out the problem. Bootdelegation does work
correctly. All you have to do is use "framework" instead of "app".
That gets me to the mentioned Nullpointer with bootdelegation (you
still need the implicit=false so).
regards,
Karl
> regards,
>
> Karl
>
>> configProps.put("felix.bootdelegation.implicit", "false");
>>
>> system.packages.extra contains among other the following maps.jar-Packages:
>> "com.google.android.maps; " +
>> "com.google.android.xmppService; " +
>> "com.google.googlenav.map; " +
>> "com.google.common;" +
>> "com.google.map;"
>>
>>
>> Error:
>>
>> It remains the basic error:
>>
>> java.lang.LinkageError: Classes resolve differently in superclass
>>
>> but he now adds:
>>
>> Method mismatch: setup in
>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>>
>>
>> Error:
>>
>> 09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>> android.graphics.drawable -> 0
>> 09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>> android.util -> 0
>> 09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>> android.location -> 0
>> 09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
>> com.google.googlenav.map -> 0
>> 09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in
>> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
>> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>> 09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
>> 09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting with
>> uncaught exception (group=0x4001aa28)
>> 09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler: thread main
>> exiting due to uncaught exception
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): java.lang.LinkageError:
>> Classes resolve differently in superclass
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:112)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> android.os.Handler.handleCallback(Handler.java:587)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> android.os.Handler.dispatchMessage(Handler.java:92)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> android.os.Looper.loop(Looper.java:123)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> android.app.ActivityThread.main(ActivityThread.java:4203)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> java.lang.reflect.Method.invokeNative(Native Method)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> java.lang.reflect.Method.invoke(Method.java:521)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
>> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
>> dalvik.system.NativeStart.main(Native Method)
>>
>>
>>
>> I will now add to export list just all Packages maps.jar has (I did so for
>> android.jar) but I'm afraid that this will not change
>> the situation. I'm still hoping that you will find a workaround for the
>> bootdelegation in order to see if this solves the problem.
>>
>> regards
>> Matthias
>>
>>
>>
>>
>>
>> Am 22.09.2009 um 19:06 schrieb Karl Pauls:
>>
>>> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <su...@onlinehome.de>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> additional info: setting the Imports of the using Bundles to
>>>>
>>>> DynamicImport-Package: android.*, com.google.*
>>>>
>>>> does NOT solve the problem.
>>>
>>> It does for me, but you are missing some exports from the system bundle
>>> namely,
>>>
>>> com.google.android.maps
>>> com.google.googlenav.map
>>> com.google.common
>>> com.google.map
>>>
>>> if I add those plus implict=false and not bootdelegating com.google.*
>>> the app starts for me and if I hit the button I get a NullPointer
>>> somewhere but one that doesn't seem to be releated to felix.
>>>
>>> Regarding the bootdelegation I think I know what is going on and will
>>> try to find a workaround soon. Until then, please let me know whether
>>> it works with the above for you now.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>> Changing it has one advantage for me: Now I can
>>>> easily switch between
>>>> bootdelegation and system.packages.extra without touching the bundles,
>>>> only
>>>> by changing the felix configuration.
>>>>
>>>> I'm looking foreward that we can solve this issue. Important for me is
>>>> what
>>>> do you think: will boot delegation be able to solve the underlying
>>>> problem?
>>>>
>>>> regards
>>>> Matthias
>>>>
>>>>
>>>>
>>>>
>>>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>>>
>>>>> Hello,
>>>>>
>>>>> I've tried this combination without success.(he doesn't find the class)
>>>>> Some minutes ago I mailed to you the requested Eclipse Projects for
>>>>> testing
>>>>> it locally.
>>>>>
>>>>> I hope there is a way for felix to work around this DalvikVM Bug. The
>>>>> people from ProSyst seem to have the same problem.[1] I don't know if
>>>>> they also had the idea solving this by boot delegation, but as far as I
>>>>> understand the dalvik bug [2], boot delegation instead of system.extra
>>>>> export will solve the problem.
>>>>>
>>>>> If not I will have a bigger problem than I ever thought.(regarding to my
>>>>> diploma thesis)
>>>>>
>>>>> feel free to experiment with my test-projects.
>>>>>
>>>>> regards
>>>>> Matthias
>>>>>
>>>>> [1]
>>>>>
>>>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>>>
>>>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert
>>>>>> <su...@onlinehome.de>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I tested
>>>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>>>> when felix.bootdelegation.implicit=false then he do not find the
>>>>>>> class.
>>>>>>> When
>>>>>>> true, he hang for ever.
>>>>>>
>>>>>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>>>>>> which we didn't anticipate but we might be able to detect this
>>>>>> situation and workaround it in felix. The former, however, is not yet
>>>>>> clear to me what is going on exactly but please make sure that it
>>>>>> doesn't work if you set the bundle.parent to app and the
>>>>>> bootdelegation.implicit to false.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>> So no solution from that option. I will try to change my embedding
>>>>>>> using
>>>>>>> the
>>>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>>>> the normal Felix instancing in a standardized manner and so will not
>>>>>>> help.
>>>>>>>
>>>>>>> regards
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>>>
>>>>>>>> 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
>>>>>>>>> <he...@ungoverned.org>
>>>>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Karl Pauls
>>>>>>>>> karlpauls@gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Sep 22, 2009 at 9:28 PM, Matthias Neubert <su...@onlinehome.de> wrote:
> Hello,
>
> I tried your advice, but it still doesn't work, but the error changed a bit:
>
> Current Configuration:
>
> no use of boot delegation
You have to keep the bootdelegation as you have it except remove the
com.google.* and then add the packages I told you in the last mail.
That did make it work for me until the NullPointer which didn't look
like it is felix releated.
regards,
Karl
> configProps.put("felix.bootdelegation.implicit", "false");
>
> system.packages.extra contains among other the following maps.jar-Packages:
> "com.google.android.maps; " +
> "com.google.android.xmppService; " +
> "com.google.googlenav.map; " +
> "com.google.common;" +
> "com.google.map;"
>
>
> Error:
>
> It remains the basic error:
>
> java.lang.LinkageError: Classes resolve differently in superclass
>
> but he now adds:
>
> Method mismatch: setup in
> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
>
>
> Error:
>
> 09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.graphics.drawable -> 0
> 09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.util -> 0
> 09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> android.location -> 0
> 09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
> com.google.googlenav.map -> 0
> 09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in
> Lde/mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
> super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
> 09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
> 09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting with
> uncaught exception (group=0x4001aa28)
> 09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler: thread main
> exiting due to uncaught exception
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): java.lang.LinkageError:
> Classes resolve differently in superclass
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:112)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Handler.handleCallback(Handler.java:587)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Handler.dispatchMessage(Handler.java:92)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.os.Looper.loop(Looper.java:123)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> android.app.ActivityThread.main(ActivityThread.java:4203)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> java.lang.reflect.Method.invokeNative(Native Method)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> java.lang.reflect.Method.invoke(Method.java:521)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
> 09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
> dalvik.system.NativeStart.main(Native Method)
>
>
>
> I will now add to export list just all Packages maps.jar has (I did so for
> android.jar) but I'm afraid that this will not change
> the situation. I'm still hoping that you will find a workaround for the
> bootdelegation in order to see if this solves the problem.
>
> regards
> Matthias
>
>
>
>
>
> Am 22.09.2009 um 19:06 schrieb Karl Pauls:
>
>> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <su...@onlinehome.de>
>> wrote:
>>>
>>> Hello,
>>>
>>> additional info: setting the Imports of the using Bundles to
>>>
>>> DynamicImport-Package: android.*, com.google.*
>>>
>>> does NOT solve the problem.
>>
>> It does for me, but you are missing some exports from the system bundle
>> namely,
>>
>> com.google.android.maps
>> com.google.googlenav.map
>> com.google.common
>> com.google.map
>>
>> if I add those plus implict=false and not bootdelegating com.google.*
>> the app starts for me and if I hit the button I get a NullPointer
>> somewhere but one that doesn't seem to be releated to felix.
>>
>> Regarding the bootdelegation I think I know what is going on and will
>> try to find a workaround soon. Until then, please let me know whether
>> it works with the above for you now.
>>
>> regards,
>>
>> Karl
>>
>>> Changing it has one advantage for me: Now I can
>>> easily switch between
>>> bootdelegation and system.packages.extra without touching the bundles,
>>> only
>>> by changing the felix configuration.
>>>
>>> I'm looking foreward that we can solve this issue. Important for me is
>>> what
>>> do you think: will boot delegation be able to solve the underlying
>>> problem?
>>>
>>> regards
>>> Matthias
>>>
>>>
>>>
>>>
>>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>>
>>>> Hello,
>>>>
>>>> I've tried this combination without success.(he doesn't find the class)
>>>> Some minutes ago I mailed to you the requested Eclipse Projects for
>>>> testing
>>>> it locally.
>>>>
>>>> I hope there is a way for felix to work around this DalvikVM Bug. The
>>>> people from ProSyst seem to have the same problem.[1] I don't know if
>>>> they also had the idea solving this by boot delegation, but as far as I
>>>> understand the dalvik bug [2], boot delegation instead of system.extra
>>>> export will solve the problem.
>>>>
>>>> If not I will have a bigger problem than I ever thought.(regarding to my
>>>> diploma thesis)
>>>>
>>>> feel free to experiment with my test-projects.
>>>>
>>>> regards
>>>> Matthias
>>>>
>>>> [1]
>>>>
>>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>>
>>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert
>>>>> <su...@onlinehome.de>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I tested
>>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>>> when felix.bootdelegation.implicit=false then he do not find the
>>>>>> class.
>>>>>> When
>>>>>> true, he hang for ever.
>>>>>
>>>>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>>>>> which we didn't anticipate but we might be able to detect this
>>>>> situation and workaround it in felix. The former, however, is not yet
>>>>> clear to me what is going on exactly but please make sure that it
>>>>> doesn't work if you set the bundle.parent to app and the
>>>>> bootdelegation.implicit to false.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>> So no solution from that option. I will try to change my embedding
>>>>>> using
>>>>>> the
>>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>>> the normal Felix instancing in a standardized manner and so will not
>>>>>> help.
>>>>>>
>>>>>> regards
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>>
>>>>>>> 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
>>>>>>>> <he...@ungoverned.org>
>>>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> karlpauls@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
I tried your advice, but it still doesn't work, but the error changed
a bit:
Current Configuration:
no use of boot delegation
configProps.put("felix.bootdelegation.implicit", "false");
system.packages.extra contains among other the following maps.jar-
Packages:
"com.google.android.maps; " +
"com.google.android.xmppService; " +
"com.google.googlenav.map; " +
"com.google.common;" +
"com.google.map;"
Error:
It remains the basic error:
java.lang.LinkageError: Classes resolve differently in superclass
but he now adds:
Method mismatch: setup in Lde/mnsoft/mapprovider/gmapsimpl/
AutoRefreshMapView; (cl=0x43891310) and super Lcom/google/android/maps/
MapView; (cl=0x43760eb0)
Error:
09-22 21:15:26.981: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
android.graphics.drawable -> 0
09-22 21:15:27.031: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
android.util -> 0
09-22 21:15:27.091: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
android.location -> 0
09-22 21:15:27.150: INFO/System.out(751): DEBUG: DYNAMIC WIRE: 10.0 ->
com.google.googlenav.map -> 0
09-22 21:15:27.481: WARN/dalvikvm(751): Method mismatch: setup in Lde/
mnsoft/mapprovider/gmapsimpl/AutoRefreshMapView; (cl=0x43891310) and
super Lcom/google/android/maps/MapView; (cl=0x43760eb0)
09-22 21:15:27.481: DEBUG/AndroidRuntime(751): Shutting down VM
09-22 21:15:27.481: WARN/dalvikvm(751): threadid=3: thread exiting
with uncaught exception (group=0x4001aa28)
09-22 21:15:27.491: ERROR/AndroidRuntime(751): Uncaught handler:
thread main exiting due to uncaught exception
09-22 21:15:27.521: ERROR/AndroidRuntime(751): java.lang.LinkageError:
Classes resolve differently in superclass
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
de.mnsoft.mapprovider.gmapsimpl.ViewBuilder$1.run(ViewBuilder.java:112)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
android.os.Handler.handleCallback(Handler.java:587)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
android.os.Handler.dispatchMessage(Handler.java:92)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
android.os.Looper.loop(Looper.java:123)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
android.app.ActivityThread.main(ActivityThread.java:4203)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
java.lang.reflect.Method.invokeNative(Native Method)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
java.lang.reflect.Method.invoke(Method.java:521)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:791)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549)
09-22 21:15:27.521: ERROR/AndroidRuntime(751): at
dalvik.system.NativeStart.main(Native Method)
I will now add to export list just all Packages maps.jar has (I did so
for android.jar) but I'm afraid that this will not change
the situation. I'm still hoping that you will find a workaround for
the bootdelegation in order to see if this solves the problem.
regards
Matthias
Am 22.09.2009 um 19:06 schrieb Karl Pauls:
> On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <sureal@onlinehome.de
> > wrote:
>> Hello,
>>
>> additional info: setting the Imports of the using Bundles to
>>
>> DynamicImport-Package: android.*, com.google.*
>>
>> does NOT solve the problem.
>
> It does for me, but you are missing some exports from the system
> bundle namely,
>
> com.google.android.maps
> com.google.googlenav.map
> com.google.common
> com.google.map
>
> if I add those plus implict=false and not bootdelegating com.google.*
> the app starts for me and if I hit the button I get a NullPointer
> somewhere but one that doesn't seem to be releated to felix.
>
> Regarding the bootdelegation I think I know what is going on and will
> try to find a workaround soon. Until then, please let me know whether
> it works with the above for you now.
>
> regards,
>
> Karl
>
>> Changing it has one advantage for me: Now I can
>> easily switch between
>> bootdelegation and system.packages.extra without touching the
>> bundles, only
>> by changing the felix configuration.
>>
>> I'm looking foreward that we can solve this issue. Important for me
>> is what
>> do you think: will boot delegation be able to solve the underlying
>> problem?
>>
>> regards
>> Matthias
>>
>>
>>
>>
>> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>>
>>> Hello,
>>>
>>> I've tried this combination without success.(he doesn't find the
>>> class)
>>> Some minutes ago I mailed to you the requested Eclipse Projects
>>> for testing
>>> it locally.
>>>
>>> I hope there is a way for felix to work around this DalvikVM Bug.
>>> The
>>> people from ProSyst seem to have the same problem.[1] I don't know
>>> if
>>> they also had the idea solving this by boot delegation, but as far
>>> as I
>>> understand the dalvik bug [2], boot delegation instead of
>>> system.extra
>>> export will solve the problem.
>>>
>>> If not I will have a bigger problem than I ever thought.(regarding
>>> to my
>>> diploma thesis)
>>>
>>> feel free to experiment with my test-projects.
>>>
>>> regards
>>> Matthias
>>>
>>> [1]
>>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>>
>>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert <sureal@onlinehome.de
>>>> >
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I tested
>>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>>> when felix.bootdelegation.implicit=false then he do not find the
>>>>> class.
>>>>> When
>>>>> true, he hang for ever.
>>>>
>>>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>>>> which we didn't anticipate but we might be able to detect this
>>>> situation and workaround it in felix. The former, however, is not
>>>> yet
>>>> clear to me what is going on exactly but please make sure that it
>>>> doesn't work if you set the bundle.parent to app and the
>>>> bootdelegation.implicit to false.
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>> So no solution from that option. I will try to change my
>>>>> embedding using
>>>>> the
>>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>>> the normal Felix instancing in a standardized manner and so will
>>>>> not
>>>>> help.
>>>>>
>>>>> regards
>>>>> Matthias
>>>>>
>>>>>
>>>>>
>>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>>
>>>>>> 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
>>>>>>> <he...@ungoverned.org>
>>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> karlpauls@gmail.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Sep 22, 2009 at 6:00 PM, Matthias Neubert <su...@onlinehome.de> wrote:
> Hello,
>
> additional info: setting the Imports of the using Bundles to
>
> DynamicImport-Package: android.*, com.google.*
>
> does NOT solve the problem.
It does for me, but you are missing some exports from the system bundle namely,
com.google.android.maps
com.google.googlenav.map
com.google.common
com.google.map
if I add those plus implict=false and not bootdelegating com.google.*
the app starts for me and if I hit the button I get a NullPointer
somewhere but one that doesn't seem to be releated to felix.
Regarding the bootdelegation I think I know what is going on and will
try to find a workaround soon. Until then, please let me know whether
it works with the above for you now.
regards,
Karl
> Changing it has one advantage for me: Now I can
> easily switch between
> bootdelegation and system.packages.extra without touching the bundles, only
> by changing the felix configuration.
>
> I'm looking foreward that we can solve this issue. Important for me is what
> do you think: will boot delegation be able to solve the underlying problem?
>
> regards
> Matthias
>
>
>
>
> Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
>
>> Hello,
>>
>> I've tried this combination without success.(he doesn't find the class)
>> Some minutes ago I mailed to you the requested Eclipse Projects for testing
>> it locally.
>>
>> I hope there is a way for felix to work around this DalvikVM Bug. The
>> people from ProSyst seem to have the same problem.[1] I don't know if
>> they also had the idea solving this by boot delegation, but as far as I
>> understand the dalvik bug [2], boot delegation instead of system.extra
>> export will solve the problem.
>>
>> If not I will have a bigger problem than I ever thought.(regarding to my
>> diploma thesis)
>>
>> feel free to experiment with my test-projects.
>>
>> regards
>> Matthias
>>
>> [1]
>> http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
>> [2] http://code.google.com/p/android/issues/detail?id=2711
>>
>>
>>
>>
>>
>>
>>
>>
>> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>>
>>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert <su...@onlinehome.de>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I tested
>>>> configProps.put("org.osgi.framework.bundle.parent",
>>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>>> (which is org.osgi.framework.bundle.parent=boot)
>>>> when felix.bootdelegation.implicit=false then he do not find the class.
>>>> When
>>>> true, he hang for ever.
>>>
>>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>>> which we didn't anticipate but we might be able to detect this
>>> situation and workaround it in felix. The former, however, is not yet
>>> clear to me what is going on exactly but please make sure that it
>>> doesn't work if you set the bundle.parent to app and the
>>> bootdelegation.implicit to false.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>> So no solution from that option. I will try to change my embedding using
>>>> the
>>>> new FrameworkFactory way, but as far I can the this only wraps
>>>> the normal Felix instancing in a standardized manner and so will not
>>>> help.
>>>>
>>>> regards
>>>> Matthias
>>>>
>>>>
>>>>
>>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>>
>>>>> 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
>>>>>> <he...@ungoverned.org>
>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
additional info: setting the Imports of the using Bundles to
DynamicImport-Package: android.*, com.google.*
does NOT solve the problem. Changing it has one advantage for me: Now
I can easily switch between
bootdelegation and system.packages.extra without touching the bundles,
only by changing the felix configuration.
I'm looking foreward that we can solve this issue. Important for me is
what do you think: will boot delegation be able to solve the
underlying problem?
regards
Matthias
Am 22.09.2009 um 15:26 schrieb Matthias Neubert:
> Hello,
>
> I've tried this combination without success.(he doesn't find the
> class) Some minutes ago I mailed to you the requested Eclipse
> Projects for testing it locally.
>
> I hope there is a way for felix to work around this DalvikVM Bug.
> The people from ProSyst seem to have the same problem.[1] I don't
> know if
> they also had the idea solving this by boot delegation, but as far
> as I understand the dalvik bug [2], boot delegation instead of
> system.extra export will solve the problem.
>
> If not I will have a bigger problem than I ever thought.(regarding
> to my diploma thesis)
>
> feel free to experiment with my test-projects.
>
> regards
> Matthias
>
> [1] http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
> [2] http://code.google.com/p/android/issues/detail?id=2711
>
>
>
>
>
>
>
>
> Am 22.09.2009 um 15:05 schrieb Karl Pauls:
>
>> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert <sureal@onlinehome.de
>> > wrote:
>>> Hello,
>>>
>>> I tested
>>> configProps.put("org.osgi.framework.bundle.parent",
>>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>>> (which is org.osgi.framework.bundle.parent=boot)
>>> when felix.bootdelegation.implicit=false then he do not find the
>>> class. When
>>> true, he hang for ever.
>>
>> Well, the latter (i.e., hang for ever) seems to be a bug in android
>> which we didn't anticipate but we might be able to detect this
>> situation and workaround it in felix. The former, however, is not yet
>> clear to me what is going on exactly but please make sure that it
>> doesn't work if you set the bundle.parent to app and the
>> bootdelegation.implicit to false.
>>
>> regards,
>>
>> Karl
>>
>>> So no solution from that option. I will try to change my embedding
>>> using the
>>> new FrameworkFactory way, but as far I can the this only wraps
>>> the normal Felix instancing in a standardized manner and so will
>>> not help.
>>>
>>> regards
>>> Matthias
>>>
>>>
>>>
>>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>>
>>>> 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 <heavy@ungoverned.org
>>>>> >
>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
I've tried this combination without success.(he doesn't find the
class) Some minutes ago I mailed to you the requested Eclipse
Projects for testing it locally.
I hope there is a way for felix to work around this DalvikVM Bug. The
people from ProSyst seem to have the same problem.[1] I don't know if
they also had the idea solving this by boot delegation, but as far as
I understand the dalvik bug [2], boot delegation instead of
system.extra export will solve the problem.
If not I will have a bigger problem than I ever thought.(regarding to
my diploma thesis)
feel free to experiment with my test-projects.
regards
Matthias
[1] http://dz.prosyst.com/pdoc/changes/Release-Notes_ProSyst-mBS-OSGi-Android_v1.0.0.pdf
[2] http://code.google.com/p/android/issues/detail?id=2711
Am 22.09.2009 um 15:05 schrieb Karl Pauls:
> On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert <sureal@onlinehome.de
> > wrote:
>> Hello,
>>
>> I tested
>> configProps.put("org.osgi.framework.bundle.parent",
>> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
>> (which is org.osgi.framework.bundle.parent=boot)
>> when felix.bootdelegation.implicit=false then he do not find the
>> class. When
>> true, he hang for ever.
>
> Well, the latter (i.e., hang for ever) seems to be a bug in android
> which we didn't anticipate but we might be able to detect this
> situation and workaround it in felix. The former, however, is not yet
> clear to me what is going on exactly but please make sure that it
> doesn't work if you set the bundle.parent to app and the
> bootdelegation.implicit to false.
>
> regards,
>
> Karl
>
>> So no solution from that option. I will try to change my embedding
>> using the
>> new FrameworkFactory way, but as far I can the this only wraps
>> the normal Felix instancing in a standardized manner and so will
>> not help.
>>
>> regards
>> Matthias
>>
>>
>>
>> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>>
>>> 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 <heavy@ungoverned.org
>>>> >
>>>> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Sep 22, 2009 at 2:54 PM, Matthias Neubert <su...@onlinehome.de> wrote:
> Hello,
>
> I tested
> configProps.put("org.osgi.framework.bundle.parent",
> Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
> (which is org.osgi.framework.bundle.parent=boot)
> when felix.bootdelegation.implicit=false then he do not find the class. When
> true, he hang for ever.
Well, the latter (i.e., hang for ever) seems to be a bug in android
which we didn't anticipate but we might be able to detect this
situation and workaround it in felix. The former, however, is not yet
clear to me what is going on exactly but please make sure that it
doesn't work if you set the bundle.parent to app and the
bootdelegation.implicit to false.
regards,
Karl
> So no solution from that option. I will try to change my embedding using the
> new FrameworkFactory way, but as far I can the this only wraps
> the normal Felix instancing in a standardized manner and so will not help.
>
> regards
> Matthias
>
>
>
> Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
>
>> 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 <he...@ungoverned.org>
>>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
I tested
configProps.put("org.osgi.framework.bundle.parent",
Constants.FRAMEWORK_BUNDLE_PARENT_BOOT);
(which is org.osgi.framework.bundle.parent=boot)
when felix.bootdelegation.implicit=false then he do not find the
class. When true, he hang for ever.
So no solution from that option. I will try to change my embedding
using the new FrameworkFactory way, but as far I can the this only wraps
the normal Felix instancing in a standardized manner and so will not
help.
regards
Matthias
Am 22.09.2009 um 13:30 schrieb Matthias Neubert:
> 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 <heavy@ungoverned.org
>> > 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Matthias Neubert <su...@onlinehome.de>.
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 <heavy@ungoverned.org
> > 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
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 <he...@ungoverned.org> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Problem with Bootdelegation using Felix 2.0.0
Posted by Karl Pauls <ka...@gmail.com>.
Would it be possible for you to make you app available to me (direct
mail or put it someplace where I can download it)?
regards,
Karl
On Tue, Sep 22, 2009 at 11:32 AM, Matthias Neubert <su...@onlinehome.de> 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.
>
>
> regards
> Matthias
>
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org