Re: felix:persistentFactoryComponent
Yes, now that you mention it, that is actually seeming like more of the motivation for the flag than what I originally recalled. In general I think it’s supposed to make the factory-created instances act as much as possible like regular components. David Jencks > On Apr 25, 2023, at 9:05 AM, Raymond Augé > wrote: > > Thanks David, that's great information. > > Let me try to explain what I've witnessed in another way to see if that is > something you would have expected: > > * When a factory component has a reference, which cannot be _immediately_ > resolved at the moment of activation, it will fail. > > * However, when setting felix:persistentFactoryComponent="true" the > component behaves as any other component which might have an unresolved > reference, resulting in deferred activation only upon satisfaction of the > reference. > > Would you consider that inline with the intent? (I certainly hope so :D > because that's what I'm looking for.) > > Ray > > On Tue, Apr 25, 2023 at 11:54 AM David Jencks > wrote: > >> This is my recollection from the distant past, it could be wrong in >> several ways. >> >> IIRC if you have a factory component, when you call it to create a >> component the properties are a mix of the factory component’s properties >> and the ones you supply. >> >> Furthermore, the spec says if you change the factory component’s >> properties, all the previously created instances are immediately disposed >> of. If the manually created component instances are used as dependencies >> this might not be what you want. >> >> So, IIRC, setting this property changes the behavior when you change the >> factory properties so the created instances are not automatically disposed >> of. >> >> I thought I’d documented all the non-standard behaviors I implemented, but >> this certainly isn’t in the .md. >> >> David Jencks >> >>> On Apr 25, 2023, at 6:56 AM, Raymond Augé >> wrote: >>> >>> Hello all, >>> >>> Could someone explain what it means to use >>> >>> felix:persistentFactoryComponent="true" >>> >>> As in: >>> >>> http://www.osgi.org/xmlns/scr/v1.1.0; >>> >>> xmlns:felix="http://felix.apache.org/xmlns/scr/extensions/v1.0.0;> >>> >>> >>> >> >>> felix:persistentFactoryComponent="true" >>> >>> enabled="false" >>> >>> factory="factory.component.factory" > >>> >>> >>> >>> >>> >>> ... >>> >>> -- >>> *Raymond Augé* (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* (@Liferay) >>> OSGi Fellow, Java Champion >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow, Java Champion - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: felix:persistentFactoryComponent
This is my recollection from the distant past, it could be wrong in several ways. IIRC if you have a factory component, when you call it to create a component the properties are a mix of the factory component’s properties and the ones you supply. Furthermore, the spec says if you change the factory component’s properties, all the previously created instances are immediately disposed of. If the manually created component instances are used as dependencies this might not be what you want. So, IIRC, setting this property changes the behavior when you change the factory properties so the created instances are not automatically disposed of. I thought I’d documented all the non-standard behaviors I implemented, but this certainly isn’t in the .md. David Jencks > On Apr 25, 2023, at 6:56 AM, Raymond Augé > wrote: > > Hello all, > > Could someone explain what it means to use > > felix:persistentFactoryComponent="true" > > As in: > > http://www.osgi.org/xmlns/scr/v1.1.0; > > xmlns:felix="http://felix.apache.org/xmlns/scr/extensions/v1.0.0;> > > > > felix:persistentFactoryComponent="true" > > enabled="false" > > factory="factory.component.factory" > > > > > > > ... > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow, Java Champion - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: @Component and @AspectService not playing nice
I’m used to the DS OSGI spec @Component annotation but I guess you are using the DM annotations and not DS? David Jencks > On Jun 16, 2021, at 1:57 PM, Steve Runion > wrote: > > My company has used activators for quite some time, instead of annotations, > due to a perceived inability for the annotations to fit our needs. > > I have cornered the use case that is reported to be the challenge. We have > services that are both aspects on services by their interfaces and also > implement another (common) interface which are whiteboarded in elsewhere. The > plumbing to get that to work would look like… > > @AspectService(ranking = 10, service = AimEncryptionKeyService.class) > @Component(provides = EntitySynchronizer.class) > > … however it seems as if these two annotations are not intended to be used as > the same time. Whichever one is first is applied and the second is ignored. > Is anyone aware of a workaround, or an idiomatic way, to get this scenario to > work? > > > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: SCR duplicating service PIDs
> On Dec 2, 2020, at 7:27 PM, Raymond Auge
> wrote:
>
> On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal wrote:
>
>> ---
>>
>> My sample component:
>>
>> @Component(
>>name = "hello",
>>property = "service.pid=hello",
>>
>
> This is not quite correct actually. I would have expected SCR to complain
> about this because service.pid should be one of the "managed" component
> properties. (i.e. never pass service.pid as a property)
>
> Since you have set _name_ property, what you want is simply:
>
>> @Component(
>>name = "hello",
>
>immediate = true)
>> public class HelloComponent { ... }
>>
>
> ... without setting _configurationPid_ property, 'service.pid' is implied
> from _name_.
>
> With that, you should notice that your component responds as you expect
> when a configuration with pid "hello" appears.
>
> HTH
>
> PS: _All components are configurable_ (even ones you never anticipated
> passing configuration to) because they always infer at least their
> component name as a service.pid (AFAIC this is one of the most understated
> wonders of DS.)
What if you’ve specified configuration policy IGNORE?
Otherwise, I agree it’s a wonderful feature, although I always preferred
configuration policy REQUIRE.
David Jencks
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: FrameworkEvent ERROR org.osgi.framework.ServiceException: Service factory exception: Could not obtain lock
it’s been quite a few years since I worked on this area…. do you have any circular references between DS components? Sometimes a thread dump is useful in understanding what is going on: I thought DS actually produced one in this situation. David Jencks > On May 8, 2020, at 10:09 AM, raj.all...@gmail.com wrote: > > Hi, > > Please see the below error. It is happening inconsistently. Tried several > things but didn't workout. > Kindly help me in resolving the issue. > > *Environment*: > JDK11 > karaf-4.2.8 > > *ERROR:* > 2020-05-08T08:21:07,162 | ERROR | FelixDispatchQueue | FrameworkEvent > > | 200 - ui - 4.0.0 | FrameworkEvent ERROR > org.osgi.framework.ServiceException: Service factory exception: Could not > obtain lock > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) > ~[?:?] > at org.apache.felix.framework.Felix.getService(Felix.java:3737) ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:86) > ~[?:?] > at > org.apache.felix.scr.impl.inject.BindParameters.getServiceObject(BindParameters.java:47) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:664) > ~[?:?] > at > org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2308) > ~[?:?] > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1154) > ~[?:?] > at > org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1568) > ~[?:?] > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1029) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:935) > ~[?:?] > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:765) > ~[?:?] > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1045) > ~[?:?] > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:999) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1216) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1137) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:944) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:880) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1168) > ~[?:?] > at > org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) > ~[?:?] > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) > ~[?:?] > at org.apache.felix.framework.Felix.registerService(Felix.java:3587) > ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > ~[?:?] > at > org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:381) > ~[?:?] > at > org.ops4j.pax.web.service.internal.Activator.lambda$scheduleUpdateFactory$1(Activator.java:299) > ~[?:?] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > ~[?:?] > at java.lang.T
Re: Missing Capability for ComponentFactory service
I don’t understand how your question and Jean-Baptiste’s answer relate to each other. ComponentFactory is not a service provided by the SCR bundle, so it certainly won’t be a capability of the SCR bundle. When you have a component factory DS component in a bunldle A, SCR registers a ComponentFactory service for the bundle A. so you should look in the A manifest. I don’t know if this actually works, but it would be a bnd thing, not something felix has any control over. David Jencks > On Jun 9, 2019, at 10:58 AM, Clément Delgrange > wrote: > > Thanks a lot, I should have checked the updated versions! > > > > > ‐‐‐ Original Message ‐‐‐ > On Sunday 9 June 2019 14:46, Jean-Baptiste Onofré wrote: > >> Hi, >> >> Just check in SCR 2.1.16 and I can see: >> >> Provide-Capability = >> >> osgi.extender;uses:=org.osgi.service.component;osgi.extender=osgi.component;version:Version=1.4, >> >> osgi.service;uses:=org.osgi.service.component.runtime;objectClass:List=org.osgi.service.component.runtime.ServiceComponentRuntime >> >> So it looks good to me. >> >> About jetty, with 4.0.6, I also have: >> >> Provide-Capability = >> >> osgi.implementation;uses:="javax.servlet,javax.servlet.http,org.osgi.service.http.context,org.osgi.service.http.whiteboard";osgi.implementation=osgi.http;version:Version=1.1, >> >> osgi.service;uses:="org.osgi.service.http.runtime,org.osgi.service.http.runtime.dto";objectClass:List=org.osgi.service.http.runtime.HttpServiceRuntime >> >> So the capabilities are there. >> >> Regards >> JB >> >> On 09/06/2019 14:30, Clément Delgrange wrote: >> >>> Hi JB, >>> I am using SCR version 2.1.10 and jetty 4.0.6. I am not using Karaf, but I >>> can use the augment directive of bnd to make it work. Does these missing >>> Capabilities should be considered as bugs or are they wanted? >>> Message d'origine >>> On 9 juin 2019 à 13:59, Jean-Baptiste Onofré a écrit : >>> >>>> Hi Clément, >>>> If you are using Karaf, we provide the capability at feature level. >>>> What scr version are you using ? >>>> Regards >>>> JB >>>> On 09/06/2019 10:43, Clément Delgrange wrote: >>>> >>>>> Hi, >>>>> When I use ComponentFactory my bundle has a requirement for >>>>> osgi.service;objectClass:List="org.osgi.service.component.ComponentFactory. >>>>> However, felix SCR doesn't provide this capability in its manifest and >>>>> the resolver fails if I try to resolve with effective=active. >>>>> There is the same issue with HttpService. Why felix SCR and felix http >>>>> jetty does not provide these capabilities with effective set to active? >>>>> Thanks, >>>>> Clément Delgrange. >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >> >> -- >> >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Running felix container inside another felix container
You can also construct an isolation solution using the (non spec I think) region digraph support that is used to implement subsystems. This would be much easier than dealing with the framework hooks yourself. I think subsystems will be adequate for isolation but you may find they introduce constraints on how additional bundles must be deployed that don’t work for you. However, from your description, deploying your solution in a subsystem and exporting the packages and services you want to expose for extension will meet your needs. David Jencks Sent from my iPhone > On Nov 5, 2018, at 4:59 AM, Casper van der Tuin > wrote: > > Hi all, > > Thanks for the quick answers. I will explore them to see which most fit our > requirements. > > Greetings, > Casper > > > > -- > Sent from: > http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: how to enable http2 in jetty
Jetty may be modular, and each of their jars may include OSGI metadata so they are bundles, but the use of service loader (implied I think by the discussion of spi-fly; I haven’t looked at jetty myself) carries an extremely strong presumption that the jetty modularity is not very compatible with osgi modularity. I’d regard the jetty modularity as very compatible with osgi if they provided “service” wiring that could use either the OSGI registry directly or service loader directly. Relying on service loader only has a bias towards everything being in the same class loader, so it’s more likely to work correctly with a fat bundle than with spi-fly. These are rather abstract or philosophical arguments, so they may or may not match the reality of using jetty in any particular way. david jencks > On Oct 20, 2018, at 1:20 PM, Eric Norman wrote: > > Carsten and others, > > Well, if the newer jetty version of the jetty artifacts causes the code to > not compile then perhaps that is an issue you would want to raise with the > jetty folks to not make incompatible changes to the public APIs without > incrementing the major version numbers of their exports? > > For me, the claim that the new jetty version breaks something isn't a > compelling reason do continue on as before as the same argument could be > made for any third party artifact. If the third party releases a new > version that doesn't work with your bundles then it seems to me that the > proper remedy would be to raise the issue with the third party, declare the > known issue in your own documentation and/or declare a more specific > version range for the bundle/package imports in the affected consumer > bundles that you have control over. Perhaps, the felix http bundle > documentation could have some statement that says which versions of jetty > were tested and certified against if that would make you more comfortable > about the de-coupling. > > It seems to me that the jetty project has made a lot of efforts to make a > modular system where you can chose which parts to include and they have > made sure all their modules are OSGi bundles. Going back to jamming it all > the jetty code into a fat bundle for the convenience of some demo-ware > seems to be the wrong direction and I'm surprised that OSGi based project > like felix would still be promoting such things. Also, this fat way of > packaging jetty isn't tested by jetty proper, so who can say what side > effects may be lurking? > > The eclipse equinox impl of the http service works in the "thin" way like I > have proposed and looks to me like a better solution. Is there much > collaboration between equinox and felix on the parts that seem to be common > to both? > > Regarding your suggestions: I still don't see a good solution with your > hybrid approach either since the same problems I raised in the July message > thread about the activation timing remain. For example. the bundle > activator where jetty is started synchronously happens before the spifly > bundle extender makes the ServiceLoader stuff available so any > ServiceLoader configuration embedded inside of the felix.http bundle would > not be available yet when jetty is starting up. > > Plus I'm not sure I like the impression that http/2 support would have the > appearance of being a second-class feature when wider adoption of http/2 > would be better for everyone. > > Regards, > -Eric > > On Sat, Oct 20, 2018 at 5:25 AM Carsten Ziegeler > wrote: > >> Let's focus for a minute on having jetty as separate bundles. This will >> potentially create a lot of problems as people will use the wrong jetty >> version. I just recently updated from on 9.4.x version to the next >> 9.4.(x+1) version and our code was not even compiling anymore. Therefore >> ultimately our code is tied to a very specific version of Jetty. >> From that PoV it's dangerous to not bundle jetty. >> My suggestion is still: >> - we bundle Jetty as today but add the missing service loader files. >> This bundle has code to support http2 if the additional stuff is installed. >> - for people needing http2 they install a number of more bundles and >> voila everything works. >> >> Unless this plan is not possible, I don't see a reason why we shouldn't >> go there? >> >> Carsten >> >> >> Am 19.10.2018 um 17:34 schrieb Raymond Auge: >>> >>> >>> On Fri, Oct 19, 2018 at 11:11 AM Carsten Ziegeler >> <mailto:cziege...@apache.org>> wrote: >>> >>> >>> >>>Am 19.10.2018 um 17:06 schrieb Raymond Auge: >>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler >>>mai
Re: Constructor injection with multivalue
The .cardinality.minimum property keeps DS from starting your component until that many reference services are available, and stops it when there get to be fewer. Supplying that information to config admin may be a different problem :-). If you know at compile time how many there will be you could use the new configurator (?name) and put a json file in your bundle with the appropriate configuration. I’m not sure how is determined for activator parameters, you might consult the spec. david jencks > On Sep 21, 2018, at 6:01 PM, David Daniel wrote: > > Thank you David and Eric, > So what I did was set the ReferncePolicyOption to greedy so the service > is restarted everytime a new item is added to the List. This seems to > match your second suggestion of adjusting the code to take account of > dynamic referenced service appearance although it seems like a lot of > restarting eg. if I have 50 web endpoints the component will restart 50 > times. I did not completely understand the first suggestion. I do know at > buildtime the size of the list and the items in the list. Are you saying > that there is a way to tell configadmin the minimum number of items in the > list before starting the component. > > Thanks, > David > > > On Fri, Sep 21, 2018 at 8:34 PM David Jencks > wrote: > >> startlevel is not an appropriate solution for this problem. >> >> Your original code doesn’t show the use of the service tracker. Your >> replacement code appears to assume that every referenced service is already >> present at activation. In order to assure this I suggest you supply your >> component with a mandatory configuration specifying >> .cardinality.minimum, or adjust your code to take account of >> dynamic referenced service appearance and disappearance. I don’t know how >> the new R7 features work with this property but I’d be surprised if >> constructor injection didn’’t take it into account. >> >> david jencks >> >>> On Sep 21, 2018, at 5:16 PM, David Daniel >> wrote: >>> >>> Adding a cardinality did not seem to solve the issue. It appears to be >> an >>> issue with the startlevel as stopping and starting the bundle worked and >>> the only bundle that started before it was added. Is there an example of >>> the new R7 startlevel stuff in felix. I would like to give the bundle I >>> want loaded last a start level of 5 or something. >>> >>> Thanks, >>> David >>> >>> 45|Active |1|web.server (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT >>> 46|Active |1|web.ui.site (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT >>> 47|Active |1|web.ui.qr (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT >>> g! stop 45 >>> >>> 20:11:57 >>> 20:12:09.153 [pipe-stop 45] INFO Events.Service.web.server:? - >>> ServiceEvent UNREGISTERING [com.mobigov.web.server.HandlerBuilder] >>> 20:12:09.164 [ixDispatchQueue] INFO Events.Bundle.web.server:? - >>> BundleEvent STOPPED >>> g! start 45 >>> >>>20:12:09 >>> 20:12:16.266 [pipe-start 45] INFO Events.Service.web.server:? - >>> ServiceEvent REGISTERED [com.mobigov.web.server.HandlerBuilder] >>> 20:12:16.285 [pipe-start 45] INFO >> c.mobigov.web.server.HandlerBuilder:31 - >>> Adding Handler for: /communication >>> 20:12:16.286 [pipe-start 45] INFO >> c.mobigov.web.server.HandlerBuilder:31 - >>> Adding Handler for: /web.ui >>> 20:12:16.286 [pipe-start 45] INFO >> c.mobigov.web.server.HandlerBuilder:31 - >>> Adding Handler for: /qr >>> 20:12:16.287 [pipe-start 45] INFO >> c.mobigov.web.server.UndertowServer:42 - >>> Directory exists >>> 20:12:16.299 [ixDispatchQueue] INFO Events.Bundle.web.server:? - >>> BundleEvent STARTED >>> >>> On Thu, Sep 20, 2018 at 11:30 PM Eric Norman >>> wrote: >>> >>>> Are those the SCR annotations, or the newer official OSGi declarative >>>> service annotations? >>>> >>>> In either cause, I suppose you'd need to to adjust the cardinality >> property >>>> on the @Reference annotation to tell it you want multiple service >>>> references. >>>> >>>> Regards, >>>> -Eric >>>> >>>> On Thu, Sep 20, 2018 at 7:42 PM David Daniel < >> david.daniel.1...@gmail.com> >>>> wrote: >>>> >>>>> I had switched form a servicetracker to constructor injection of a list >>>>> with scr 2.1.6 . The
Re: Constructor injection with multivalue
startlevel is not an appropriate solution for this problem.
Your original code doesn’t show the use of the service tracker. Your
replacement code appears to assume that every referenced service is already
present at activation. In order to assure this I suggest you supply your
component with a mandatory configuration specifying
.cardinality.minimum, or adjust your code to take account of
dynamic referenced service appearance and disappearance. I don’t know how the
new R7 features work with this property but I’d be surprised if constructor
injection didn’’t take it into account.
david jencks
> On Sep 21, 2018, at 5:16 PM, David Daniel wrote:
>
> Adding a cardinality did not seem to solve the issue. It appears to be an
> issue with the startlevel as stopping and starting the bundle worked and
> the only bundle that started before it was added. Is there an example of
> the new R7 startlevel stuff in felix. I would like to give the bundle I
> want loaded last a start level of 5 or something.
>
> Thanks,
> David
>
> 45|Active |1|web.server (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT
> 46|Active |1|web.ui.site (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT
> 47|Active |1|web.ui.qr (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT
> g! stop 45
>
>20:11:57
> 20:12:09.153 [pipe-stop 45] INFO Events.Service.web.server:? -
> ServiceEvent UNREGISTERING [com.mobigov.web.server.HandlerBuilder]
> 20:12:09.164 [ixDispatchQueue] INFO Events.Bundle.web.server:? -
> BundleEvent STOPPED
> g! start 45
>
> 20:12:09
> 20:12:16.266 [pipe-start 45] INFO Events.Service.web.server:? -
> ServiceEvent REGISTERED [com.mobigov.web.server.HandlerBuilder]
> 20:12:16.285 [pipe-start 45] INFO c.mobigov.web.server.HandlerBuilder:31 -
> Adding Handler for: /communication
> 20:12:16.286 [pipe-start 45] INFO c.mobigov.web.server.HandlerBuilder:31 -
> Adding Handler for: /web.ui
> 20:12:16.286 [pipe-start 45] INFO c.mobigov.web.server.HandlerBuilder:31 -
> Adding Handler for: /qr
> 20:12:16.287 [pipe-start 45] INFO c.mobigov.web.server.UndertowServer:42 -
> Directory exists
> 20:12:16.299 [ixDispatchQueue] INFO Events.Bundle.web.server:? -
> BundleEvent STARTED
>
> On Thu, Sep 20, 2018 at 11:30 PM Eric Norman
> wrote:
>
>> Are those the SCR annotations, or the newer official OSGi declarative
>> service annotations?
>>
>> In either cause, I suppose you'd need to to adjust the cardinality property
>> on the @Reference annotation to tell it you want multiple service
>> references.
>>
>> Regards,
>> -Eric
>>
>> On Thu, Sep 20, 2018 at 7:42 PM David Daniel
>> wrote:
>>
>>> I had switched form a servicetracker to constructor injection of a list
>>> with scr 2.1.6 . The servicetracker got all the services correctly but
>> the
>>> list is only getting 1. I was wondering if I did not understand
>> something
>>> or if there was an open bug.
>>>
>>> Thanks for any help,
>>> David
>>>
>>> From
>>>
>>>try {
>>>mBundleContext = bc;
>>>String filterString = "(" + Constants.OBJECTCLASS + "=" +
>>> IHandlerFactory.class.getName() + ")";
>>>Filter filter = bc.createFilter(filterString);
>>>tracker = new ServiceTracker(bc, filter, this);
>>>tracker.open();
>>>
>>>} catch (InvalidSyntaxException e) {
>>>if (log != null) {
>>>log.log(LogService.LOG_ERROR, e.getMessage());
>>>}
>>>}
>>>
>>> To
>>>
>>> @Activate
>>> public HandlerBuilder(@Reference List handlerFactories)
>> {
>>> pathHandler.addExactPath("/", new Forwarding());
>>> pathHandler.addExactPath("/manifest.json", new Manifest());
>>> for(IHandlerFactory handler : handlerFactories) {
>>> if (handler.Type().equals("path")) {
>>> if (handler instanceof IPathHandlerFactory) {
>>> logger.info("Adding Handler for: " + ((IPathHandlerFactory)
>>> handler).Prefix
>>> ());
>>> pathHandler.addPrefixPath(((IPathHandlerFactory) handler).Prefix(),
>>> handler.
>>> Get());
>>> }
>>> }
>>> }
>>> }
>>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Configurator R7 example
Inline...
Sent from my iPhone
> On Jul 16, 2018, at 6:34 AM, Raymond Auge wrote:
>
> On Mon, Jul 16, 2018 at 6:16 AM, Philipp Höfler <
> philipp.hoef...@pernexas.com> wrote:
>
>> Hallo Ray,
>>
>> thanks for your detailed explanation. You're right, I think one can
>> consider this scenario as multi-tenant.
>> This sounds pretty promising.
>>
>> The following points are unclear to me:
>> * Even if I decouple the configuration from the endpoint, the security
>> check has to be done in the endpoint, as it depends on the function that is
>> invoked.
>> I've several classes / endpoints for handling different functions.
>> Basically, it is about the CRUD functions, but there are also some
>> additional ones.
>> Is it still possible to handle the security check based on the
>> configuration in the endpoint itself, but "route" the call to the right
>> instance of the endpoint based on the ID coming from the rest call?
>>
>
> First off let me answer your second bullet, the two interfaces I used were
> just "mock" types based on your example. The Endpoint is whatever you
> endpoint object was. The Tenant was just an object I made up which should
> encompass the instance of your configuration with which you can make
> security checks.
>
>
>> * I was trying to implement your suggestion, but I am facing problems.
>> What is Endpoint and Tenant for interfaces? Are they part of the JAX-RS
>> framework or osgi or are they custom interfaces?
>>
>
> See above, they are just pseudo code of your design.
>
>
>> * Can I still use endpoints with the annotations (@Path, @Get, etc)?
>>
>
> Yeah! this is what Endpoint was suppose to represent, again in pseudo code.
>
>
>> * You have a map of tenants in the endpoint A. How do you create and fill
>> these tenants? Is this done automagically be the factory configuration?
>>
>
> DS supports tuples of services (as in my example), and it's maintained for
> you. Then you have each "Tenant" created for you by configuration admin
> from a component that requires factory configuration, automagically ;)
>
Don’t you mean something like...
Specify the “Require” configuration policy for your DS tenant component. Then,
when a management agent creates a factory configuration for each tenant, DS
will create a corresponding instance of the tenant component.
?
Config admin isn’t going to create component instances for you. This is close
to nitpicking, but if you aren’t familiar with who does what even a little
imprecision can be very confusing, at least to me.
Thanks
David Jencks
> Sincerely,
> - Ray
>
>
>> Again, thanks for your help.
>> Philipp
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Raymond Auge
>> Gesendet: Freitag, 13. Juli 2018 16:01
>> An: felix users
>> Betreff: Re: Configurator R7 example
>>
>> On Fri, Jul 13, 2018 at 4:37 AM, Philipp Höfler <
>> philipp.hoef...@pernexas.com> wrote:
>>
>>> I've tested the factory configuration and I am afraid that my problem
>>> is not being solved with this approach.
>>>
>>> I think I might have to explain the problem in more detail, that
>>> you'll get a better understanding.
>>> I am implementing a REST service using the HTTP Whiteboard mechanism.
>>> This interface is described in a quite old standard.
>>> Each call contains an identifier. I would like to configure my service
>>> based on this identifier.
>>> Meaning, depending on this identifier I would like to use different
>>> configuration.
>>>
>>> Example:
>>> I am receiving a call with identifier for S1 (System 1).
>>> {
>>>// Resource Format Version
>>>":configurator:resource-version" : 1,
>>>
>>>// First Configuration
>>>"my.config~system1":
>>>{
>>> "test.securityEnabled": false,
>>> "test.test": false
>>> },
>>> // Second Configuration
>>>"my.config~system2":
>>>{
>>> "test.securityEnabled": true,
>>> "test.test": false
>>> }
>>> }
>>> }
>>>
>>> Then, I would like to disable the security when the call comes from
>>> System 1.
>>> But when the call comes from System 2 the security should be enabled.
>>>
>&g
Re: Configurator R7 example
Hi Martin, If I understand what you are saying, it doesn’t seem very osgi friendly to me. To me the “osgi way” would be to have the config admin service work from normal property files, databases, or what have you, and have ManagedProperties only work from configuration from config admin. That way any configuration consumer in your system can rely on getting its configuration from config admin, whether or not it uses ManagedProperties. If ManagedProperties gets all or part of its information from something other than config admin, then either every configuration consumer in your system has to use ManagedProperties or you run a risk of different consumers getting inconsistent data. For instance, DS components can use multiple pids, where the idea is that there’s some “base” configuration used by a lot of components associated with one or more of the pids. If one of the components uses ManagedProperties for this pid and some others use ds config-by-annotation, and ManagedProperties has conflicting info for this pid from config admin, the components will get conflicting configuration. thanks david jencks > On Jul 13, 2018, at 12:09 AM, Martin Nielsen wrote: > > Hi again David > ManagedProperties uses the Configuration Admin ManagedService and MetaType > service for everything it does. It really is just spice on top, so except > for making the configuration widely available, i don't see how i could > really go against the divisions of resposibility you describe. > I might look into the R7 spec. But i want to be a little cautious here > because another ManagedProperties quirk is that it doesnt only support the > ConfigurationAdmin. Its pluggable, so it could be implemented on top og > normal property files, databases, webservices or what have you. > > -Martin > > On Fri, 13 Jul 2018, 00:40 David Jencks, wrote: > >> Hi Martin, >> >> It’s refreshing to see so much enthusiasm! I wonder if you might provide >> a valuable service to your current and potential users by providing a >> detailed comparison of capabilities compared with the R6 and R7 specs, and >> possibly also including felix DS extensions such as configuration via >> interfaces rather than annotations and nested configuration objects (I >> don’t know if this last is still present in the R7 code; it worked great in >> the R6 code). >> >> I’m slightly confused by some aspects of your description. The osgi model >> is that, if you are using config admin, all configuration comes from the >> config admin service, although it might be stored or originated in many >> places such as a file, database, remote rest service, or some combination >> of these. Also there’s a distinction between consumers of configurations >> such as DS components and and management agents that create, modify, and >> delete configurations in the config admin service. I can’t tell how your >> system relates to these divisions of responsibility. >> >> I haven’t kept up with the R7 specs for nearly 2 years now but as I recall >> there was a possibility of making the DS implementation use the (R7) >> converter service. I wonder if you might be able to repackage some of your >> code as a converter service enabling its’ use in more contexts. >> >> thanks! >> David Jencks >> >>> On Jul 12, 2018, at 1:39 PM, Martin Nielsen wrote: >>> >>> Hi David >>> >>> I started managedproperties before tjat specification was finished and i >>> havent really used it, as ManagedProperties has been my goto configadmin >>> communication method. I will highlight the main functions of it, but i >> cant >>> say if DS can do it too now. But the advantages are: >>> >>> The configuration is just an interface, so it can be easily replaced for >>> testing purposes. >>> You can use any class you want for config items, not just primitives. >> URL, >>> file, Datetime, Instant or whatever you can parse to a string os fair >> game. >>> You can write validation logic to check any configuration item before it >> is >>> changed. For example if you have a string that must be valid regex, or an >>> URL that needs to actually resolve, or a filepath where the file must >>> exist. If the validation code fails, the config is not updated. With >> this, >>> a silly spelling mistake will be caught, and you wont stop your >> production >>> server because pf sausage fingers:) >>> You can implement a configuration interface to supply easy and versitile >>> defaults. If you want to do random generatio, get defaults from a >> database, >>> initiate a new s
Re: Configurator R7 example
Hi Martin, It’s refreshing to see so much enthusiasm! I wonder if you might provide a valuable service to your current and potential users by providing a detailed comparison of capabilities compared with the R6 and R7 specs, and possibly also including felix DS extensions such as configuration via interfaces rather than annotations and nested configuration objects (I don’t know if this last is still present in the R7 code; it worked great in the R6 code). I’m slightly confused by some aspects of your description. The osgi model is that, if you are using config admin, all configuration comes from the config admin service, although it might be stored or originated in many places such as a file, database, remote rest service, or some combination of these. Also there’s a distinction between consumers of configurations such as DS components and and management agents that create, modify, and delete configurations in the config admin service. I can’t tell how your system relates to these divisions of responsibility. I haven’t kept up with the R7 specs for nearly 2 years now but as I recall there was a possibility of making the DS implementation use the (R7) converter service. I wonder if you might be able to repackage some of your code as a converter service enabling its’ use in more contexts. thanks! David Jencks > On Jul 12, 2018, at 1:39 PM, Martin Nielsen wrote: > > Hi David > > I started managedproperties before tjat specification was finished and i > havent really used it, as ManagedProperties has been my goto configadmin > communication method. I will highlight the main functions of it, but i cant > say if DS can do it too now. But the advantages are: > > The configuration is just an interface, so it can be easily replaced for > testing purposes. > You can use any class you want for config items, not just primitives. URL, > file, Datetime, Instant or whatever you can parse to a string os fair game. > You can write validation logic to check any configuration item before it is > changed. For example if you have a string that must be valid regex, or an > URL that needs to actually resolve, or a filepath where the file must > exist. If the validation code fails, the config is not updated. With this, > a silly spelling mistake will be caught, and you wont stop your production > server because pf sausage fingers:) > You can implement a configuration interface to supply easy and versitile > defaults. If you want to do random generatio, get defaults from a database, > initiate a new selfsigned certificate or whatever, practically anything is > possible. > You can register callbacks so you can take action when the configuration is > changed, for example if you have a Soap Server that has to reboot to take > in new configuration. > You can use the configuration interface to save new configurations simply > by adding a matching setter. That means that you can have an application > admin change configurations for that specific bundle without letting them > loose in the entire app server. Saving in this way is also subject to > validation. > When a configuration is registered, it will also be availableaa a service, > so although a specific bundne owns it, other bundles can also read it. > Of cause we use MetaType as well, so it is possible to supply defaults, > suggested values, cardinalities and so on. > > > I am sorry that i dont really have a good grip on the new standard, so i > can't tell you exactly where each one falæs short. But i can say that > ManagedProperties can do the things it can because we found out we needed > it, especially the validation. You can only kill a production server > because you mistyped a file name so many times before do something to fix > it:) > > > > On 12 Jul 2018 20:11, "Philipp Höfler" wrote: > > Thanks for your very detailed explanation. > If I got you right, with ManagedProperties I am not bound to the primitives > the default osgi implementation provides, but I can use any Java type. > > Up to now, I think I am fine with factory configuration, but probably I > come back to you in a few weeks, when I realize that the scenario is more > complex as I thought > > Anyhow, thanks for your help. > I am quite new to all the osgi stuff, but slowly but surely I am getting a > picture of it. > > -Ursprüngliche Nachricht- > Von: Martin Nielsen > Gesendet: Donnerstag, 12. Juli 2018 19:53 > > An: users@felix.apache.org > Betreff: Re: Configurator R7 example > > Hello everyone > > I saw ManagedProperties mentioned so now I appear! > > @Philipp.Hoefler if what you mean by complex types is that you want the > configuration admin to return some more advanced types like URLs Files or > Dates, then ManagedPropert
Re: Configurator R7 example
Hi Martin,
I guess you are the developer of this ManagedProperties? How does it differ in
capabilities to the configuration-by-annotation that is built into DS 1.3?
thanks
david jencks
> On Jul 12, 2018, at 10:53 AM, Martin Nielsen wrote:
>
> Hello everyone
>
> I saw ManagedProperties mentioned so now I appear!
>
> @Philipp.Hoefler if what you mean by complex types is that you want the
> configuration admin to return some more advanced types like URLs Files or
> Dates, then ManagedProperties will handle that for you. If not then stop
> reading:)
>
> If you want to use ManagedProperties and have questions, you can write me.
> I am very talkative:)
>
> ManagedProperties is made to handle mapping and propper handling of
> advanced or complex types to the Configuration Admin. It works through the
> java util Proxy as a middle layer, allowing an application to request
> complex types like Dates or URLs while storing them as primitives and
> Strings in the Configuration Admin.
>
> In order to use a ManagedProperties, you register an annotated interface
> with the ManagedProperties service, like so:
>
> First you create the interface which will serve as your configuration
>
> package my.package.config;
> import dk.netdesign.common.osgi.config.annotation.Property;
> import dk.netdesign.common.osgi.config.annotation.PropertyDefinition;
> import dk.netdesign.common.osgi.config.exception.UnknownValueException;
>
> @PropertyDefinition
> public interface MyConfiguration {
> @Property(type = String.class, typeMapper = ExistingFileFilter.class)
> throws UnknownValueException
> public File getExistingFile();
>
> @Property(type = String.class, typeMapper = URLMapper.class) throws
> UnknownValueException
> public File getURL();
> @Property
> public String getUsername();
> }
>
> Then you register it with a bundle, either through an activator or through
> Declarative Services
>
> @Component
> public class MyComponent {
> ManagedPropertiesService mpRegistration;
> MyConfiguration config;
> @Activate
>public void register(BundleContext context) throws
> InstantiationException, IllegalAccessException, InvalidSyntaxException {
> config = mpRegistration.register(MyConfiguration.class, context);
> }
> @Reference(cardinality = ReferenceCardinality.MANDATORY)
> public void setManagedPropertiesService(ManagedPropertiesService
> managedPropertiesService) throws Exception {
> mpRegistration = managedPropertiesService;
> }
> }
>
> This will create a configuration in the ConfigurationAdmin with 3
> configurations, ExistingFile, URL and Username. Calling the getter methods
> in the interface will return the current configuration, which means that it
> will update if it gets changed in the WebConsole or anywhere else.
>
> If you want you can pass a number of defaults with the config registration
> like this:
> config = mpRegistration.register(MyConfiguration.class, new
> MyConfigurationDefaults(), context);
>
> MyConfigurationDefaults is simply a class that implements the
> MyConfiguration interface. The defaults come into play if no configuration
> is found, for example if no configuration has been set yet, or if a single
> configuration item was not set.
> The Defaults class can do anything basically, if you want configuration
> from a database or a webservice, it is possible.
>
> This setup has the following advantages:
> 1. Since the Configuration is simply an interface it is easily tested
> outside OSGi, by creating a setter or extra constructor for the interface.
> Then you can simply pass whatever you want to the test, no need for
> configuration admin or anything.
> 2. The defaults can be a powerful fallback for missing configuration.
> 3. When handling complex types, ManagedProperties can test the input and
> fail the configuration update if something doesn't add up. This is very
> useful for handling complex types, as you don't want to acidentally write
> something that won't parse to what you want. For example, say you only want
> to be able to specify files which actually exist.
>
> public class ExistingFileFilter extends TypeFilter {
>
>@Override
>public File parse(String input) throws TypeFilterException {
>File f = new File(input);
>try {
>f.getCanonicalPath();
>
>} catch (IOException ex) {
>throw new TypeFilterException("Could not read the file '" +
> input + "'. Could not resolve path: " + ex.getMessage(), ex);
>}
>return f;
>}
>@Override
>public String revert(File input) throws TypeFilterException {
>try {
>return input.getCanonicalPath();
&g
Re: How to investigate a "Unsatisfied" reference with felix.scr ?
Hi Cristiano, That doesn’t look much like what I recall my version of scr:info produced, I’d expect better indenting and a ComponentConfiguration section following, and the ComponentConfiguration ought to list the references defined in the component xml. Are you sure that you are actually using felix ds and that the scr:info command you use actually comes from felix? What is in the “equinox compendium” you mention? Did anyone significantly change how scr:info works? thanks david jencks > On Jul 11, 2018, at 9:51 AM, Cristiano wrote: > > Hi David, thanks for the time... > > Unfortunately, there are no enough information provided by scr:info in order > to help identify what is happen with this immediate component. > > Below is what I'm seeing: > >> g! scr:info >> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider >> Component Description: >> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider >> >> Class: >> c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider >> Bundle:1 (br.com.c8tech.osgi.lib.cm:0.1.1.SNAPSHOT) >> Enabled: true >> Immediate: true >> Services: [c8tech.osgi.lib.api.cm.ConfigurationAdminExtendedService] >> Scope: singleton >> Config PID(s): >> [c8tech.osgi.lib.cm.internal.ComponentConfigurationExtendedServiceProvider], >> Policy: optional >> Base Props:(0 entries) > > best regards, > > Cristiano > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: How to investigate a "Unsatisfied" reference with felix.scr ?
Hmm, when I last worked on it, admittedly a couple of years ago, I recall
scr:info did indicate everything possible about the components including
unsatisfied references. What are you seeing from scr:info? At one time karaf
replaced the felix-supplied scr command with something that basically didn’t
work, but I think that was long ago. I certainly used the info provided from
the scr command (although in IBM Liberty it shows up elsewhere more easily) to
figure out missing references.
david jencks
> On Jul 9, 2018, at 4:29 PM, Cristiano wrote:
>
> Hi all,
>
> Couple years ago I used to use a command (from equinox.ds that uses felix.scr
> from behind) called "comp" that help me a lot to investigate when a component
> was not activated:
>> |osgi> comp 6 Component[ name = com.mycompany.foo.Service ... state =
>> Unsatisfied references = { ... Reference[name = HttpService, interface =
>> org.osgi.service.http.HttpService, policy = static, cardinality = 1..1,
>> target = null, bind = setHttpService, unbind = unsetHttpService] } located
>> in bundle = com.mycompany.foo_1.2.3 [18] ] Dynamic information : *The
>> component is NOT satisfied The following references are not satisfied:
>> Reference[name = HttpService, interface = org.osgi.service.http.HttpService,
>> policy = static, cardinality = 1..1, target = null, bind = setHttpService,
>> unbind = unsetHttpService] Component configurations : Configuration
>> properties: component.name = com.mycompany.foo.Service component.id = 6
>> Instances: |
>
> |Returning to the OSGi world and using the current versions of felix and
> equinox compendium bundles I cannot find such command anymore. I tried
> scr:info but it doesn't show me component's reference information.
>
> So, how do you guys do to investigate an "Unsatisfied" reference with felix ?
>
> thanks for any tip,
>
> best regards,
>
> Cristiano
> |
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Override Require-Capability in Maven-Bundle-Plugin
The effective:=active clause means the requirements/capabilities are not used at runtime when wiring bundles, they are information for figuring out which bundles will work together and are used by things such as (spec) subsystems and the karaf feature installer. Aries implements the osgi jpa spec so it ought to work fine. Perhaps asking on the Aries list would get better results. David Jencks Sent from my iPhone > On Dec 13, 2017, at 4:19 AM, Kerry <karaf-u...@avionicengineers.com> wrote: > > David, > > Thanks for taking a look. As you and Neil Bartlett have said, my work around > isn't the correct solution and I perhaps have to accept that I cannot achieve > my desired result. > > I think this is because in part persistence units don't have OSGi in mind so > don't place nice with it? I'm possibly trying to shoe-horn the proverbial > round peg into a square hole. Wherever those headers are being generated they > are required but the feature resolver is not quite clever enough to work out > that I am truly providing everything in my feature? I might be too hard on > the resolver here as it is likely that resolving dependencies is not as easy > as I am imagining. > > I'll dig around a bit further but one solution is to provide separate > features and have to install them in a specific order. ( Not good either) > > Kerry > > Sent from BlueMail > >> On 12 Dec 2017, 23:22, at 23:22, David Jencks <david.a.jen...@gmail.com> >> wrote: >> Kerry, >> >> I looked at your project and since you are not using any DS components >> what I suggested does not apply. I have no idea where the generated >> capabilities/requirement headers are coming from. >> >> In general I think it is worth expending considerable effort to >> straighten out the capabilities/requirements wiring so it works >> properly rather than trying to provide non-standard workarounds that >> disable it and may have further unwanted side effects. >> >> The obvious question is whether the openjpa feature includes a bundle >> with a Provide-Capability header matching the unsatisfied >> Require-Capability. Frankly, I’d expect that what would be needed was >> a Require-Capability header for a jpa extender, but I’m not that >> familiar with jpa in osgi. AFAICT your bundle doesn’t import the >> java.persistence.provider package so it couldn’t do anything with the >> service whether or not it was present. This makes me wonder even more >> where the generated headers are coming from any why. >> >> david jencks >> >> >>> On Dec 12, 2017, at 2:23 PM, Kerry <karaf-u...@avionicengineers.com> >> wrote: >>> >>> David, >>> >>> I quickly tried your suggested POM modification and still generates >> the headers for me, though I remember the underscore technique to pass >> instructions direct to bnd so will investigate further. >>> >>> The headers that are generated are: >>> >>> Export-Service = >>> >> com.javatechnics.jpa.dao.BookServiceDao;ServiceManager=Blueprint;name=BookServiceDao;osgi.service.blueprint.compname=bookServiceDao >>> Provide-Capability = >>> >> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name=test, >>> >> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name=test, >>> >> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name=test, >>> >> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name=test >>> Require-Capability = >>> >> osgi.service;effective:=active;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;objectClass=javax.persistence.spi.PersistenceProvider, >>>osgi.extender;osgi.extender=aries.jpa, >>> >> osgi.service;effective:=active;filter:=(osgi.jndi.service.name=jdbc/test);objectClass=javax.sql.DataSource, >>>osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.5)) >>> >>> I've also added further information on my stackoverflow question. >>> >>> thanks >>> >>> Kerry >>> >>> >>>> On 12/12/17 20:29, David Jencks wrote: >>>> I’d be interested to know the exact capabilities/requirements you >> supply and that are generated. >>>> >>>> If these capabilities/requirements are from DS components you should >> be able to turn off generation in a bnd.bnd file with >>>> >>>> -d
Re: Override Require-Capability in Maven-Bundle-Plugin
Kerry, I looked at your project and since you are not using any DS components what I suggested does not apply. I have no idea where the generated capabilities/requirement headers are coming from. In general I think it is worth expending considerable effort to straighten out the capabilities/requirements wiring so it works properly rather than trying to provide non-standard workarounds that disable it and may have further unwanted side effects. The obvious question is whether the openjpa feature includes a bundle with a Provide-Capability header matching the unsatisfied Require-Capability. Frankly, I’d expect that what would be needed was a Require-Capability header for a jpa extender, but I’m not that familiar with jpa in osgi. AFAICT your bundle doesn’t import the java.persistence.provider package so it couldn’t do anything with the service whether or not it was present. This makes me wonder even more where the generated headers are coming from any why. david jencks > On Dec 12, 2017, at 2:23 PM, Kerry <karaf-u...@avionicengineers.com> wrote: > > David, > > I quickly tried your suggested POM modification and still generates the > headers for me, though I remember the underscore technique to pass > instructions direct to bnd so will investigate further. > > The headers that are generated are: > > Export-Service = > com.javatechnics.jpa.dao.BookServiceDao;ServiceManager=Blueprint;name=BookServiceDao;osgi.service.blueprint.compname=bookServiceDao > Provide-Capability = > osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name=test, > osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name=test, > osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name=test, > osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name=test > Require-Capability = > osgi.service;effective:=active;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;objectClass=javax.persistence.spi.PersistenceProvider, > osgi.extender;osgi.extender=aries.jpa, > osgi.service;effective:=active;filter:=(osgi.jndi.service.name=jdbc/test);objectClass=javax.sql.DataSource, > osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.5)) > > I've also added further information on my stackoverflow question. > > thanks > > Kerry > > > On 12/12/17 20:29, David Jencks wrote: >> I’d be interested to know the exact capabilities/requirements you supply and >> that are generated. >> >> If these capabilities/requirements are from DS components you should be able >> to turn off generation in a bnd.bnd file with >> >> -dsannotations-options:nocapabilities,norequirements >> >> I haven’t used the maven-bundle-plugin in some time, but if you are using it >> with in-pom xml configuration I think you say something like >> <_dsannotations-options>nocapabilities,norequirements >> >> Hope this helps >> david jencks >> >> >>> On Dec 12, 2017, at 9:58 AM, Kerry <karaf-u...@avionicengineers.com> wrote: >>> >>> Hi, >>> >>> First of all I have asked this question already on StackOverflow so >>> apologies for 'duplicating' : >>> >>> https://stackoverflow.com/questions/47738402/override-require-capability-in-maven-bundle-plugin >>> >>> I short, the Maven bundle plugin is duplicating my 'Require-Capability' >>> headers I manually set in the plugin configuration. This is because the >>> plugin is auto-generating the same headers as well as including my own >>> manually set ones. I need to override the 'resolution' attribute to become >>> optional (this is probably not ideal but it's the only way I can create a >>> single Apache Karaf feature to install all my own bundles and other >>> features and not fail on deploy). >>> >>> Is there a way I can get the plugin to merge or use my manually specified >>> 'Require-Capability' headers? >>> >>> Thanks >>> >>> Kerry >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: New to Felix - can someone help explain what this error means (and how to fix it)?
While what Neil says is entirely correct, the information you supply doesn't look internally consistent to me. Is that really the manifest of the actual bundle you've constructed? I don't see a package import for the package in the error message and the Bundle-classpath doesn't appear to correspond to the contents of lib/ you've listed. David Jencks Sent from my iPhone > On Sep 6, 2017, at 12:06 PM, Neil Bartlett <njbartl...@gmail.com> wrote: > > This error message simply says that your bundle imports (that is, it depends > on) the package named “oracle.security.jps”, but that no other bundle exports > or provides that package. > > The normal fix for this is to find a bundle that exports the package > “oracle.security.jps” and install it into your framework. The documentation > for OAM should have a list somewhere of all the bundles you need to make it > work. > > Regards, > Neil > >> On 6 Sep 2017, at 19:19, o haya <oh...@yahoo.com.INVALID> wrote: >> >> Hi, >> >> I am working on what Oracle calls an "authentication plugin" to work with >> their Oracle Access Manager (OAM) product. >> >> I have implemented one of their sample plugins (SampleAuthPlugin) but now >> want to have that plugin access another API that they have called the >> Identity Context API: >> >> https://docs.oracle.com/cd/E27559_01/admin.1112/e27239/id_context.htm#AIAAG7296 >> >> So I added some snippets from one of their examples on that page (Example >> 41-3) to make a method that would list/dump out the contents of the Identity >> Context. This new code has dependencies on several other Oracle JARs, from >> what I can tell: >> >> IdentityContext.jar >> jps-api.jar >> >> Possibly some others, but my code compiled ok, and I could build a new >> SampleAuthPlugin.jar successfully. >> >> However, when I try to (what oracle calls) "Activate" the plugin, I am >> getting errors. I've tried all kinds of things, but at this point, I am >> still getting this: >> >> <> 1:35:44 PM EDT> >> > starting the bundle.null >> java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at >> oracle.security.am.plugin.internal.OSGIPluginService.installAndStartBundle(OSGIPluginService.java:179) >> at >> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.installAndStartBundle(NodeMessageListener.java:66) >> at >> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessage(NodeMessageListener.java:112) >> at >> oracle.security.am.extensibility.lifecycle.messaging.NodeMessageListener.receiveMessageList(NodeMessageListener.java:49) >> at >> oracle.security.am.extensibility.lifecycle.messaging.MessageListenerWrapper.objectCreated(MessageListenerWrapper.java:30) >> at >> oracle.security.am.foundation.mapimpl.coherence.events.MapListenerWrapper.notifyListener(MapListenerWrapper.java:174) >> at >> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.dispatch(EventDispatcher.java:132) >> at >> oracle.security.am.foundation.mapimpl.coherence.events.EventDispatcher.run(EventDispatcher.java:114) >> Caused By: org.osgi.framework.BundleException: Unresolved constraint in >> bundle SampleAuthPlugin [2]: Unable to resolve 2.0: missing requirement >> [2.0] osgi.wiring.package; (osgi.wiring.package=oracle.security.jps) >> at >> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980) >> at org.apache.felix.framework.Felix.startBundle(Felix.java:2043) >> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976) >> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at >> oracle.security.am.plugin.internal.OSGIPluginService.installAndStartBundle(OSGIPluginService.java:179) >> a
Re: Service Factory returned null
DS will explain in great detail what happened in circumstances like this, so look in the log. You might need to increase the amount logged by setting the ds.loglevel property to debug, as a framework property or in the DS configuration. What exactly are you setting and where with the "keep component switch"? Thanks David Jencks Sent from my iPhone > On Jul 7, 2017, at 5:46 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > > I cant tell atm what is going on, but I suggest you to use the latest > Apache Felix SCR Release (org.apache.felix.scr) just to rule out already > known and solved problems. The same is true for the DS web console plugin > > Regards > Carsten > > Martin12 wrote >> Update: >> Activating the keep component switch of org.apache.felix.scr.ScrService >> seems to solve the problem. Any ideas why? This seems to suggest that >> delayed components are cleaned up (for good) even if they are still needed. >> >> >> >> -- >> View this message in context: >> http://apache-felix.18485.x6.nabble.com/Service-Factory-returned-null-tp5021777p5021779.html >> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: SCR : Unsatisfied ComponentFactory
> On Mar 31, 2017, at 2:20 PM, Dave Smith <dave.sm...@candata.com> wrote:
>
> The model controls the UI. When a service becomes unavailable the
> deactivate is called which then tells the UI that is is not available. In
> reality this never happens , so it is not an issue.
it might be here :-)
>
> I would suggest then there is an issue. We should be able to find out why
> factory components do not resolve , no?
I really want the scr command to be based off of scr runtime. I couldn’t think
of a plausible way to show the status of the component factory itself when this
was being specced. You are welcome to take this up with the EG :-).
One thing that ought to show the reason is to make all the references optional
and then in your supplied configuration set the minimum cardinality to 1,
making them required in the component instances. So for a reference named Foo
you’d have Foo.cardinality.minimum=1. As long as the factory component is
enabled the ComponentFactory service will be registered and if you can’t create
an instance you might be able to figure out why.
david jencks
>
> Dave
>
> On Fri, Mar 31, 2017 at 5:12 PM, David Jencks <david.a.jen...@gmail.com>
> wrote:
>
>>
>>> On Mar 31, 2017, at 1:02 PM, David Jencks <david.a.jen...@gmail.com>
>> wrote:
>>>
>>>>
>>>> On Mar 31, 2017, at 11:03 AM, Dave Smith <dave.sm...@candata.com
>> <mailto:dave.sm...@candata.com>> wrote:
>>>>
>>>> See below
>>>>
>>>> On Fri, Mar 31, 2017 at 1:51 PM, David Jencks <david.a.jen...@gmail.com
>> <mailto:david.a.jen...@gmail.com>>
>>>> wrote:
>>>>
>>>>> I think scr:info shows you instances of the factory component you’ve
>>>>> created with newInstance on the ComponentFactory service. If you list
>>>>> services do you see the ComponentFactory service registered from your
>>>>> bundle?
>>>>>
>>>>
>>>> No. In the case of a standard service you always get a service pid
>>>> regardless if the component resolves or not. Thus src:info will
>> tell
>>>> you what is not resolved. In the case of ComponentFactory if it
>> resolves it
>>>> gets a PID that you can then get details on otherwise you have to give
>> it
>>>> the full name and all this gives you is CompoentInfo but not it's state.
>>>
>>> I’m not quite sure what you mean and I don’t think you answered my
>> question about what listing services (not using scr, just by bundle)
>> shows. Reviewing the code this from ComponentFactoryImpl makes me think
>> that the component descriptions
>>
>> Apparently I’m not yet awake…. component configurations of course.
>>
>>> shown are those created by newInstance, not including one for the
>> component factory itself:
>>>
>>>@Override
>>>public void getComponentManagers(List<AbstractComponentManager>
>> cms)
>>>{
>>>synchronized (m_componentInstances)
>>>{
>>>cms.addAll(m_componentInstances.keySet());
>>>}
>>>}
>>>
>>> So I continue to think the scr command won’t tell you much about the
>> component factory service itself.
>>>>
>>>>
>>>>>
>>>>> On a separate note, Ive never seen a plausible use of a factory
>> component
>>>>> with references, so I’d be interested to see some info about a
>> situation in
>>>>> which this is a suitable approach.
>>>>>
>>>>
>>>> Legacy UI code that follows a Presentation Model style . It holds the
>> state
>>>> plus change listeners that call services. Thus the UI looks up the
>> factory
>>>> and creates an instance to hold state and run actions (Sort of like a
>>>> Stateful Session bean , remember those?)
>>>
>>> What happens to the UI when one of the referenced services disappears?
>> Have you found a way to detect this?
>>
>> Not being able to find a solution to this has led me to either create
>> factory configurations or use the felix persistent factory components
>> extension I wrote to try to make the lifecycle more usable.
>>
>> david jencks
>>
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>>>
>>>>> thanks
>>>>> david jencks
>>&g
Re: SCR : Unsatisfied ComponentFactory
> On Mar 31, 2017, at 1:02 PM, David Jencks <david.a.jen...@gmail.com> wrote:
>
>>
>> On Mar 31, 2017, at 11:03 AM, Dave Smith <dave.sm...@candata.com
>> <mailto:dave.sm...@candata.com>> wrote:
>>
>> See below
>>
>> On Fri, Mar 31, 2017 at 1:51 PM, David Jencks <david.a.jen...@gmail.com
>> <mailto:david.a.jen...@gmail.com>>
>> wrote:
>>
>>> I think scr:info shows you instances of the factory component you’ve
>>> created with newInstance on the ComponentFactory service. If you list
>>> services do you see the ComponentFactory service registered from your
>>> bundle?
>>>
>>
>> No. In the case of a standard service you always get a service pid
>> regardless if the component resolves or not. Thus src:info will tell
>> you what is not resolved. In the case of ComponentFactory if it resolves it
>> gets a PID that you can then get details on otherwise you have to give it
>> the full name and all this gives you is CompoentInfo but not it's state.
>
> I’m not quite sure what you mean and I don’t think you answered my question
> about what listing services (not using scr, just by bundle) shows. Reviewing
> the code this from ComponentFactoryImpl makes me think that the component
> descriptions
Apparently I’m not yet awake…. component configurations of course.
> shown are those created by newInstance, not including one for the component
> factory itself:
>
> @Override
> public void getComponentManagers(List<AbstractComponentManager> cms)
> {
> synchronized (m_componentInstances)
> {
> cms.addAll(m_componentInstances.keySet());
> }
> }
>
> So I continue to think the scr command won’t tell you much about the
> component factory service itself.
>>
>>
>>>
>>> On a separate note, Ive never seen a plausible use of a factory component
>>> with references, so I’d be interested to see some info about a situation in
>>> which this is a suitable approach.
>>>
>>
>> Legacy UI code that follows a Presentation Model style . It holds the state
>> plus change listeners that call services. Thus the UI looks up the factory
>> and creates an instance to hold state and run actions (Sort of like a
>> Stateful Session bean , remember those?)
>
> What happens to the UI when one of the referenced services disappears? Have
> you found a way to detect this?
Not being able to find a solution to this has led me to either create factory
configurations or use the felix persistent factory components extension I wrote
to try to make the lifecycle more usable.
david jencks
>
> thanks
> david jencks
>
>>
>> Dave
>>
>>
>>
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Mar 31, 2017, at 8:46 AM, Dave Smith <dave.sm...@candata.com
>>>> <mailto:dave.sm...@candata.com>> wrote:
>>>>
>>>> No, It still has to resolve to know if it is available to activate and
>>>> then register a facade. Otherwise non DS services that might use it
>>> would
>>>> not see it.
>>>>
>>>> Dave
>>>>
>>>> On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge <raymond.a...@liferay.com
>>>> <mailto:raymond.a...@liferay.com>
>>>>
>>>> wrote:
>>>>
>>>>> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith <dave.sm...@candata.com
>>>>> <mailto:dave.sm...@candata.com>>
>>>>> wrote:
>>>>>
>>>>>> It is ugly (long story)
>>>>>>
>>>>>> scr:info com.candata.b3.client.bbx.TRACK01
>>>>>> *** Bundle: com.candata.b3.client.jnj (7)
>>>>>> Component Description:
>>>>>> Name: com.candata.b3.client.bbx.TRACK01
>>>>>> Implementation Class: com.candata.b3.client.bbx.TRACK01
>>>>>> Default State: enabled
>>>>>> Activation: delayed
>>>>>>
>>>>>
>>>>> This is significant! It means the component is lazily activated!
>>>>> Effectively this says that the component won't do anything (such as
>>>>> activate) until some other actor requests the service from the service
>>>>> registry.
>>>>>
>>>>> Could that be your issue?
>>>>>
>>>>> - Ray
>>>>>
>>>>>
>>>>>> Configuration Policy: option
Re: SCR : Unsatisfied ComponentFactory
> On Mar 31, 2017, at 11:03 AM, Dave Smith <dave.sm...@candata.com> wrote:
>
> See below
>
> On Fri, Mar 31, 2017 at 1:51 PM, David Jencks <david.a.jen...@gmail.com
> <mailto:david.a.jen...@gmail.com>>
> wrote:
>
>> I think scr:info shows you instances of the factory component you’ve
>> created with newInstance on the ComponentFactory service. If you list
>> services do you see the ComponentFactory service registered from your
>> bundle?
>>
>
> No. In the case of a standard service you always get a service pid
> regardless if the component resolves or not. Thus src:info will tell
> you what is not resolved. In the case of ComponentFactory if it resolves it
> gets a PID that you can then get details on otherwise you have to give it
> the full name and all this gives you is CompoentInfo but not it's state.
I’m not quite sure what you mean and I don’t think you answered my question
about what listing services (not using scr, just by bundle) shows. Reviewing
the code this from ComponentFactoryImpl makes me think that the component
descriptions shown are those created by newInstance, not including one for the
component factory itself:
@Override
public void getComponentManagers(List<AbstractComponentManager> cms)
{
synchronized (m_componentInstances)
{
cms.addAll(m_componentInstances.keySet());
}
}
So I continue to think the scr command won’t tell you much about the component
factory service itself.
>
>
>>
>> On a separate note, Ive never seen a plausible use of a factory component
>> with references, so I’d be interested to see some info about a situation in
>> which this is a suitable approach.
>>
>
> Legacy UI code that follows a Presentation Model style . It holds the state
> plus change listeners that call services. Thus the UI looks up the factory
> and creates an instance to hold state and run actions (Sort of like a
> Stateful Session bean , remember those?)
What happens to the UI when one of the referenced services disappears? Have
you found a way to detect this?
thanks
david jencks
>
> Dave
>
>
>
>>
>> thanks
>> david jencks
>>
>>> On Mar 31, 2017, at 8:46 AM, Dave Smith <dave.sm...@candata.com> wrote:
>>>
>>> No, It still has to resolve to know if it is available to activate and
>>> then register a facade. Otherwise non DS services that might use it
>> would
>>> not see it.
>>>
>>> Dave
>>>
>>> On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge <raymond.a...@liferay.com
>>>
>>> wrote:
>>>
>>>> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith <dave.sm...@candata.com>
>>>> wrote:
>>>>
>>>>> It is ugly (long story)
>>>>>
>>>>> scr:info com.candata.b3.client.bbx.TRACK01
>>>>> *** Bundle: com.candata.b3.client.jnj (7)
>>>>> Component Description:
>>>>> Name: com.candata.b3.client.bbx.TRACK01
>>>>> Implementation Class: com.candata.b3.client.bbx.TRACK01
>>>>> Default State: enabled
>>>>> Activation: delayed
>>>>>
>>>>
>>>> This is significant! It means the component is lazily activated!
>>>> Effectively this says that the component won't do anything (such as
>>>> activate) until some other actor requests the service from the service
>>>> registry.
>>>>
>>>> Could that be your issue?
>>>>
>>>> - Ray
>>>>
>>>>
>>>>> Configuration Policy: optional
>>>>> Activate Method: activate
>>>>> Deactivate Method: deactivate
>>>>> Modified Method: -
>>>>> Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
>>>>> Factory: com.candata.b3.client.bbx.TRACK01
>>>>> Services:
>>>>> com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
>>>>> Service Scope: singleton
>>>>> Reference: B313AFactory
>>>>> Interface Name: org.osgi.service.component.ComponentFactory
>>>>> Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
>>>>> Cardinality: 1..1
>>>>> Policy: static
>>>>> Policy option: reluctant
>>>>> Reference Scope: bundle
>>>>> Reference: B3LogDAO
>>>>> Interface Name: com.candata.b3.common.interfaces.B3LogDAO
>>>>> Cardinality: 1..1
>>>>> Policy: static
>>&g
Re: Using OSGi DS and old Apache Felix SCR together
I think the bnd support is for the proprietary bnd annotations, not the
proprietary felix annotations. AFAIR bnd never supported the proprietary felix
scr annotations.
I also think that bnd (and thus the maven-bundle-plugin) runs and generates
the xml after the unit tests run, so that you will never be able to get the
xml’s in time for unit tests. I don’t know if integration tests (failsafe
plugin) run before or after the bundle is assembled, but I think after, so
perhaps that would be worth looking into.
david jencks
> On Mar 16, 2017, at 2:09 AM, Stefan Seifert <sseif...@pro-vision.de> wrote:
>
> you should not use the maven-scr-plugin at all in this case - there is a bnd
> plugin for the old felix SCR annotations that does the same job.
> so use only maven-bundle-plugin and add an instruction
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}
>
> for a full example see [1]
>
> on the long run you should migrate to the OSGi annotations and remove the
> felix scr annotations.
>
> stefan
>
> [1]
> https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
>
>
>> -Original Message-
>> From: Roy Teeuwen [mailto:r...@teeuwen.be]
>> Sent: Thursday, March 16, 2017 9:03 AM
>> To: users@felix.apache.org
>> Subject: Using OSGi DS and old Apache Felix SCR together
>>
>> Hey all,
>>
>> I am running in a problem when trying to use OSGi DS annotations and Apache
>> Felix annotations together. I have unit tests that depend on the service
>> xml's being present (I am using the Apache Sling osgi-mock to run unit
>> tests), but the problem that I am facing is that when the maven-bundle-
>> plugin:manifest phase has been executed, the maven-scr-plugin deletes the
>> maven-bundle-plugin xml's again created by the maven-bundle manifest phase,
>> is there any way to avoid this and make it that they are merged togheter?
>> All xmls are present in the JAR file when everything is compiled so in the
>> end it works out, but I need them for the unit tests too.
>>
>> The configuration I am currently using at the moment:
>>
>>
>> org.apache.felix
>> maven-bundle-plugin
>> 3.2.0
>>
>>
>> ...
>> <_dsannotations>*
>> <_metatypeannotations>*
>>
>> true
>>
>>
>>
>>
>> scr-metadata
>>
>> manifest
>>
>>
>> true
>>
>>
>>
>>
>>
>> org.apache.felix
>> maven-scr-plugin
>> 1.24.0
>>
>>
>> generate-scr-reportDescriptor
>>
>> scr
>>
>>
>>
>>
>>
>> Greetings,
>> Roy
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: How to compile classes in different packages ?
I don’t quite understand what you are describing. Normally you want a service to implement an interface, say a.A. The service implementation would be in a different package say b, so you’d have b.AImpl implementing a.A. It’s usually most convenient to have both packages a and b in the same bundle. Package a will be exported, and package b will NOT be exported. There are various techniques for setting up one or more instances of the service, usually the most convenient and flexible way is to use DS (SCR). Any other classes needed by a.A such as data parameters to methods need to be available to clients as well, usually by putting such classes also in package a. It’s rarely a good idea to use services in a BundleActivator….. what is supposed to happen if the services aren’t there? Usually it’s better to put the functionality into a DS component with a reference to the service you want to use. hope this helps david jencks > On Mar 12, 2017, at 1:13 PM, Dorian Vegara <dorian.veg...@gmail.com> wrote: > > Hello to everyone, > > > I wrote three bundles : a provider (providing a service|A|), a client > (containing one `BundleActivator` class using this service|A|) and a > service (containing the interface|A|). Each bundle is, obviously,*in its > own package*. > > The problem is that my client, for example, instantiates an object|:A|. > So I should write|import package.to.A|to compile my client. > > But I don't think I should do this in OSGI. I'm using Apache Felix, and > I indicated the champ|Import-Packages|in the|META-INF/manifest.mf|: is > there any command in Felix to compile my client without having to write > the|import|? > > > Thank you in advance. > Best regards, > Dorian VEGARA > > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le > logiciel antivirus Avast. > https://www.avast.com/antivirus - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: [osgi-dev] Components are not started,although marked with immediate=true
In addition, to get full information out of felix ds, you need to set the framework or config admin property ds.loglevel to “debug” or 4. While little else of http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html appears remotely up to date, the “Configuration” section explains this accurately. thanks david jencks > On Feb 17, 2017, at 3:07 PM, Neil Bartlett <njbartl...@gmail.com> wrote: > > Normally it’s enough to have a Log Service bundle installed, such as > org.apache.felix.log. Then you can view messages with the “log” command in > the Gogo shell. > > >> On 17 Feb 2017, at 22:54, Thomas Driessen <thomas.dries...@ds-lab.org> wrote: >> >> It has indeed been an Exception in the initializer. >> Thank you so much! >> >> Can you point me to some resources on how to setup the logging for DS, so >> that in the future I might see such Exceptions? >> >> Kind regards, >> Thomas >> >> -- Originalnachricht -- >> Von: "David Jencks" <david.a.jen...@gmail.com> >> An: users@felix.apache.org >> Gesendet: 17.02.2017 22:42:18 >> Betreff: Re: [osgi-dev] Components are not started,although marked with >> immediate=true >> >>> One way this could happen is if the activate methods on the testThread >>> components threw exceptions. You might try making the activate/deactivate >>> methods empty to check. If you’ve set up logging for DS (including the >>> framework or config property ds.loglevel=debug) the logs will show in >>> excruciating detail what is happening. >>> >>> hope this helps, if it’s not exceptions please supply debug logs and i will >>> take a look. >>> >>> david jencks >>> >>>> On Feb 17, 2017, at 12:36 PM, Thomas Driessen >>>> <thomas.driessen...@gmail.com> wrote: >>>> >>>> After asking in the osgi-dev list in was adviced to try ist at the Felix >>>> Mailinglist. >>>> >>>> Dies anyone know why Services that are marked as immediate are not started >>>> although marked as satisfied by felix-scr? ( See E-Mails below dir the >>>> Code) >>>> >>>> Kind regards, >>>> Thomas >>>> -- Weitergeleitete Nachricht -- >>>> Von: "BJ Hargrave" <hargr...@us.ibm.com> >>>> Datum: 17.02.2017 21:09 >>>> Betreff: Re: [osgi-dev] Components are not started,although marked with >>>> immediate=true >>>> An: <thomas.driessen...@gmail.com>, <osgi-...@mail.osgi.org> >>>> Cc: >>>> >>>> Seems like they should all be active. You may need to check with the >>>>> felix-dev list about Felix SCR's handling of this. >>>>> -- >>>>> >>>>> BJ Hargrave >>>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781 >>>>> <(386)%20848-1781> >>>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >>>>> <(386)%20848-3788> >>>>> hargr...@us.ibm.com >>>>> >>>>> >>>>> >>>>> - Original message - >>>>> From: "Thomas Driessen" <thomas.driessen...@gmail.com> >>>>> Sent by: osgi-dev-boun...@mail.osgi.org >>>>> To: osgi-...@mail.osgi.org >>>>> Cc: >>>>> Subject: [osgi-dev] Components are not started, although marked with >>>>> immediate=true >>>>> Date: Fri, Feb 17, 2017 2:46 PM >>>>> >>>>> Hi, >>>>> >>>>> I have a problem with immediate services and hoped that you guys maybe can >>>>> help. >>>>> >>>>> I'm currently trying to implement several services within one bundle (see >>>>> below for code). >>>>> I have set all of them to be immediate (by immediate=true), but still, >>>>> when I start the OSGi container with my bundle in it, only Con1, >>>>> InDataPort1 and OutDataPort1 are active. The rest is satisfied but not >>>>> active according to felix.scr console output: >>>>> >>>>> g! list >>>>> BundleId Component Name Default State >>>>> Component Id State PIDs (Factory PID) >>>>> [ 10] test.Con1 enabled >>>>> [ 0] [active ] >>>>> [ 10] test.InDataPort1 enabled >>
Re: [osgi-dev] Components are not started,although marked with immediate=true
One way this could happen is if the activate methods on the testThread
components threw exceptions. You might try making the activate/deactivate
methods empty to check. If you’ve set up logging for DS (including the
framework or config property ds.loglevel=debug) the logs will show in
excruciating detail what is happening.
hope this helps, if it’s not exceptions please supply debug logs and i will
take a look.
david jencks
> On Feb 17, 2017, at 12:36 PM, Thomas Driessen <thomas.driessen...@gmail.com>
> wrote:
>
> After asking in the osgi-dev list in was adviced to try ist at the Felix
> Mailinglist.
>
> Dies anyone know why Services that are marked as immediate are not started
> although marked as satisfied by felix-scr? ( See E-Mails below dir the Code)
>
> Kind regards,
> Thomas
> -- Weitergeleitete Nachricht --
> Von: "BJ Hargrave" <hargr...@us.ibm.com>
> Datum: 17.02.2017 21:09
> Betreff: Re: [osgi-dev] Components are not started,although marked with
> immediate=true
> An: <thomas.driessen...@gmail.com>, <osgi-...@mail.osgi.org>
> Cc:
>
> Seems like they should all be active. You may need to check with the
>> felix-dev list about Felix SCR's handling of this.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> <(386)%20848-1781>
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> <(386)%20848-3788>
>> hargr...@us.ibm.com
>>
>>
>>
>> - Original message -
>> From: "Thomas Driessen" <thomas.driessen...@gmail.com>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> To: osgi-...@mail.osgi.org
>> Cc:
>> Subject: [osgi-dev] Components are not started, although marked with
>> immediate=true
>> Date: Fri, Feb 17, 2017 2:46 PM
>>
>> Hi,
>>
>> I have a problem with immediate services and hoped that you guys maybe can
>> help.
>>
>> I'm currently trying to implement several services within one bundle (see
>> below for code).
>> I have set all of them to be immediate (by immediate=true), but still,
>> when I start the OSGi container with my bundle in it, only Con1,
>> InDataPort1 and OutDataPort1 are active. The rest is satisfied but not
>> active according to felix.scr console output:
>>
>> g! list
>> BundleId Component Name Default State
>> Component Id State PIDs (Factory PID)
>> [ 10] test.Con1 enabled
>> [ 0] [active ]
>> [ 10] test.InDataPort1 enabled
>> [ 1] [active ]
>> [ 10] test.OutDataPort1 enabled
>> [ 2] [active ]
>> [ 10] test.Process1 enabled
>> [ 3] [satisfied ]
>> [ 10] test.Thread1_1 enabled
>> [ 4] [satisfied ]
>> [ 10] test.Thread1_2 enabled
>> [ 5] [satisfied ]
>>
>> Am I doing something wrong?
>> I assumed that all services should be started as soon as they are
>> satisfied.
>>
>> Any advice is highly appreciated.
>>
>> Kind regards,
>> Thomas
>>
>>
>> @Component(immediate = true, service = IProcess.class, property =
>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Process1")
>> public class Process1 implements IProcess {
>>
>> @Reference(target = "(uid=test.Thread1_1)")
>> private volatile IPeriodicThread thread1;
>>
>> @Reference(target = "(uid=test.Thread1_2)")
>> private volatile IPeriodicThread thread2;
>> }
>>
>>
>> @Component(service = IPeriodicThread.class, property =
>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_1", immediate =
>> true)
>> public class Thread1_1 implements IPeriodicThread {
>>
>> @Reference(target = "(uid=test.OutDataPort1)")
>> private volatile IOutDataPort outport;
>>
>> @Activate
>> public void initialize_FW() {
>> init();
>> }
>>
>> @Deactivate
>> public void finalize_FW() {
>> deinit();
>> }
>> }
>>
>>
>> @Component(service = IPeriodicThread.class, property =
>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_2", immediate =
>> true)
>> public class Thread1_2 implements IPeriodicThread {
>>
>> @Reference(target = "(uid=test.InDataPort1)")
>> private volatile IOutDataPort outport;
>>
>> @Activate
>> public void initialize_FW() {
>> init();
>> }
>>
>> @Deactivate
>> public void finalize_FW
Re: DS 1.3 Components from different bundle using same configurationPid are not all updated
Thinking a bit more, as long as you are only using DS components then you won’t
have a problem with recent felix DS’s as DS no longer ever sets the bundle
location, so all bundles will have access to it. If you also had a
ManagedService[Factory] using the configuration then you’d need to set the
bundle location to e.g. “?” as MS/MSF do set any missing bundle locations. On
the other hand I am not sure how many other configuration-consuming extenders
deal appropriately with these multi-locations.
I think the “need to update file twice” problem was reported and fixed recently
in config admin. I’m not sure if it’s released yet.
david jencks
> On Jan 11, 2017, at 1:31 AM, Christian Wolf <christian.wol...@gmail.com>
> wrote:
>
> Hi,
>
> As Carsten suggested in a previous email, I moved to scr 2.0.6. It is
> working fine. I don't have any problem regarding being notified of
> configurationPid changes for component defined in separated bundles (and
> sharing the same pid file).
>
> The problem I was talking about in my latest email was regarding the pid
> file first update and karaf 4.0.8 (for shared pid or pid not shared by any
> other bundle)
>
> When restarting karaf and updating the foo.bar.cfg pid file, the @Modified
> annotated method is invoked only after the second update/save of the file.
>
> I also noticed that if I set karaf.clean.cache = true (in
> karaf/etc/system.properties)
> the problem does not occur and the component @Modified method is invoked
> after every change of the file.
>
> As default, this property is set as follow:
> #
> # Deletes the karaf.data/cache directory at every start
> #
> karaf.clean.cache = false
>
>
> As I mentioned already, this problem does not occur with karaf 4.0.5.
>
> - Any thought about this?
> - Maybe I should now move this discussion to the karaf users mailing list?
>
> Thanks
> Christian
>
>
>
>
>
>
>
> On Tue, Jan 10, 2017 at 2:00 AM, David Jencks <david.a.jen...@gmail.com>
> wrote:
>
>> There is no bug in DS here. In order to use a configuration with more
>> than one bundle, you need to arrange that the configuration location be a
>> multi-location. normally you’d want “?” so any bundle can receive the
>> configuration. AFAIK fileinstall doesn’t support setting the location, so
>> the first bundle to start wins and no other bundle uses the configuration.
>>
>> david jencks
>>
>>> On Jan 9, 2017, at 8:17 AM, Christian Wolf <christian.wol...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I did more tests and I noticed the following behavior with karaf 4.0.8
>> and
>>> scr 2.0.6 (which does not occur with karaf 4.0.5 and scr 2.0.2).
>>>
>>> Having a simple pid defined as:
>>>
>>> @ObjectClassDefinition(pid = "foo.bar")
>>> public @interface MyConfig {
>>> String username() default "myuser";
>>> String url() default "http://localhost:8080;;
>>> }
>>>
>>> And a simple @Component bind to it:
>>>
>>> @Component(configurationPid = "foo.bar")
>>> @Designate(ocd = MyConfig.class)
>>> public class CompA implements MyInterfaceA {
>>>
>>> @Activate
>>> public void activate(MyConfig myConfig) {
>>> ...
>>> }
>>>
>>> @Modified
>>> public synchronized void modify(MyConfig myConfig) {
>>> ...
>>> }
>>> }
>>>
>>> When starting karaf 4.0.8, the @Activate method of my component in
>> invoked
>>> Then, I update the foo.bar.cfg pid file to change a property.
>>> From time to time and only for the first pid manual update:
>>> - the first update is detected by fileinstall, however, the @Modified
>>> related method of the @Component(configurationPid = "foo.bar") is not
>>> invoked.
>>> - using the config:property-list shows the right updated value.
>>> - updating and saving the file a second time triggers the @Modified
>>> annotated method of that component.
>>>
>>> This happens only from time to time when restarting karaf.
>>>
>>> I cannot reproduce this issue with karaf 4.0.5
>>>
>>> Question:
>>> - Did someone already noticed this?
>>> - Is it a regression?
>>>
>>> Thanks
>>> Kind Regards,
>>> Christian
>>>
>>>
>>> On Mon, Jan 9, 2017 at 1:06 PM, Christian Wolf <
>> christian.wol...@gmail.com>
>>> wrote:
>>>
>>>> Hi Ca
Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?
I’m not sure if my suggestion would continue to work i R7 due to coordination support. david jencks > On Jan 9, 2017, at 11:46 AM, David Jencks <david.a.jen...@gmail.com> wrote: > > Felix DS runs off the configuration events too, so just waiting for the > events isn’t going to determine whether you or DS is notified first. > > I’m not sure if you can use serviceRanking to determine which configuration > listener gets notified first. If you can arrange that your listener is > called after DS, the configuration event is processed synchronously by DS. > > hope this helps > david jencks > > > >> On Jan 9, 2017, at 9:01 AM, Tom Quarendon >> <tom.quaren...@worldprogramming.com> wrote: >> >> I'm trying to use the CM_UPDATED and CM_DELETED config admin events in a >> test harness to ensure that a configuration change has been actioned before >> the test case gets run, but I'm unclear when exactly these get called. >> >> The OSGi specification doesn't seem very enlightening. "An event is fired >> when a call to Configuration.update(Dictionary) successfully changes a >> configuration". >> Configuration.update is documented as being actioned asynchronously. >> >> For example, I have a component that has a configurationPolicy of REQUIRED. >> In my test harness, in a tear down method (junit @After), I invoke a >> Configuration.delete method, then wait until the CM_DELETED event is fired. >> Am I guaranteed that the component has been deactivated by the time the >> CM_DELETED event gets fired? >> That's just an example. For UPDATED, if you have a configurationPolicy of >> REQUIRED, updating the configuration results in a deactivation and >> reactivation of the component, and consequent deactivation and reactivation >> of anything that has a required reference to it. Does the CM_UPDATED only >> occur after all that has happened? >> >> Annecdotally I do appear to see components being deactivated before the >> CM_DELETED event gets called for example. However, what I'm trying to do is >> solve test case unreliability that we are getting that we believe are caused >> by background "rewiring" still occurring when the test is then run, I want >> to be sure. >> >> What I'd *really* like is a guaranteed way of saying "come back to me when >> there's no further wiring to be done, your queue of outstanding >> configuration changes is empty". Then I know that I can put one of those in >> my test setup and I know that I've got a stable environment in which to run >> the test. At the moment, what we appear to see is that there is still >> reconfiguration going on in the background when tests start. >> >> Thanks. > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DS 1.3 Components from different bundle using same configurationPid are not all updated
There is no bug in DS here. In order to use a configuration with more than one
bundle, you need to arrange that the configuration location be a
multi-location. normally you’d want “?” so any bundle can receive the
configuration. AFAIK fileinstall doesn’t support setting the location, so the
first bundle to start wins and no other bundle uses the configuration.
david jencks
> On Jan 9, 2017, at 8:17 AM, Christian Wolf <christian.wol...@gmail.com> wrote:
>
> Hi,
>
> I did more tests and I noticed the following behavior with karaf 4.0.8 and
> scr 2.0.6 (which does not occur with karaf 4.0.5 and scr 2.0.2).
>
> Having a simple pid defined as:
>
> @ObjectClassDefinition(pid = "foo.bar")
> public @interface MyConfig {
>String username() default "myuser";
>String url() default "http://localhost:8080;;
> }
>
> And a simple @Component bind to it:
>
> @Component(configurationPid = "foo.bar")
> @Designate(ocd = MyConfig.class)
> public class CompA implements MyInterfaceA {
>
>@Activate
>public void activate(MyConfig myConfig) {
> ...
>}
>
>@Modified
>public synchronized void modify(MyConfig myConfig) {
> ...
>}
> }
>
> When starting karaf 4.0.8, the @Activate method of my component in invoked
> Then, I update the foo.bar.cfg pid file to change a property.
> From time to time and only for the first pid manual update:
> - the first update is detected by fileinstall, however, the @Modified
> related method of the @Component(configurationPid = "foo.bar") is not
> invoked.
> - using the config:property-list shows the right updated value.
> - updating and saving the file a second time triggers the @Modified
> annotated method of that component.
>
> This happens only from time to time when restarting karaf.
>
> I cannot reproduce this issue with karaf 4.0.5
>
> Question:
> - Did someone already noticed this?
> - Is it a regression?
>
> Thanks
> Kind Regards,
> Christian
>
>
> On Mon, Jan 9, 2017 at 1:06 PM, Christian Wolf <christian.wol...@gmail.com>
> wrote:
>
>> Hi Carsten,
>>
>> Thanks for your quick answer.
>>
>> I've just tested with latest karaf 4.0.8 which ships with scr 2.0.6
>> => It is working now without changing any piece of code.
>> It seems that a fix has been provided between 2.0.2 and 2.0.6.
>>
>> Thanks for you advice
>>
>> Kind Regards,
>> Christian
>>
>> On Mon, Jan 9, 2017 at 10:38 AM, Carsten Ziegeler <cziege...@apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> I think this should be possible the way you do it, so that's a "yes" to
>>> the first two of your questions at the end :)
>>>
>>> Before we start to look for a bug in the implementation, could you
>>> please check the scr 2.0.6 release and see whether it's already fixed
>>> there?
>>> If not, please open a jira ticket.
>>>
>>> Regards
>>> Carsten
>>>
>>> Christian Wolf wrote
>>>> Hi,
>>>>
>>>> I am using DS @Component and trying to get notified through @Modified
>>> when
>>>> a shared pid file is updated (using felix scr 2.0.2 in karaf 4.0.5)
>>>>
>>>> I defined a configuration interface such as:
>>>>
>>>> @ObjectClassDefinition(pid = "foo.bar")
>>>> public @interface MyConfig {
>>>>String username() default "myuser";
>>>>String url() default "http://localhost:8080;;
>>>> }
>>>>
>>>> Then, I have 3 differents classes with @Component annotation. All of
>>> them
>>>> are mapped to this pid "foo.bar".
>>>> Please note that each component is defined in separated bundles.
>>>>
>>>> @Component(configurationPid = "foo.bar", immediate = true)
>>>> @Designate(ocd = MyConfig.class)
>>>> public class CompA implements MyInterfaceA {
>>>>
>>>>@Activate
>>>>public void activate(MyConfig myConfig) {
>>>> ...
>>>>}
>>>>
>>>>@Modified
>>>>public synchronized void modify(MyConfig myConfig) {
>>>> ...
>>>>}
>>>> }
>>>>
>>>> @Component(configurationPid = "foo.bar")
>>>> @Designate(ocd = MyConfig.class)
>>>> public class CompB implements MyInterfaceB {
>>>>
>>>>@Activate
>>&g
Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?
Felix DS runs off the configuration events too, so just waiting for the events isn’t going to determine whether you or DS is notified first. I’m not sure if you can use serviceRanking to determine which configuration listener gets notified first. If you can arrange that your listener is called after DS, the configuration event is processed synchronously by DS. hope this helps david jencks > On Jan 9, 2017, at 9:01 AM, Tom Quarendon > <tom.quaren...@worldprogramming.com> wrote: > > I'm trying to use the CM_UPDATED and CM_DELETED config admin events in a test > harness to ensure that a configuration change has been actioned before the > test case gets run, but I'm unclear when exactly these get called. > > The OSGi specification doesn't seem very enlightening. "An event is fired > when a call to Configuration.update(Dictionary) successfully changes a > configuration". > Configuration.update is documented as being actioned asynchronously. > > For example, I have a component that has a configurationPolicy of REQUIRED. > In my test harness, in a tear down method (junit @After), I invoke a > Configuration.delete method, then wait until the CM_DELETED event is fired. > Am I guaranteed that the component has been deactivated by the time the > CM_DELETED event gets fired? > That's just an example. For UPDATED, if you have a configurationPolicy of > REQUIRED, updating the configuration results in a deactivation and > reactivation of the component, and consequent deactivation and reactivation > of anything that has a required reference to it. Does the CM_UPDATED only > occur after all that has happened? > > Annecdotally I do appear to see components being deactivated before the > CM_DELETED event gets called for example. However, what I'm trying to do is > solve test case unreliability that we are getting that we believe are caused > by background "rewiring" still occurring when the test is then run, I want to > be sure. > > What I'd *really* like is a guaranteed way of saying "come back to me when > there's no further wiring to be done, your queue of outstanding configuration > changes is empty". Then I know that I can put one of those in my test setup > and I know that I've got a stable environment in which to run the test. At > the moment, what we appear to see is that there is still reconfiguration > going on in the background when tests start. > > Thanks. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: SCR: Issues with static reference mixed with multiple dynamic ref
I didn’t investigate, so there might be a bug, but note that your field example
has fieldOption REPLACE, so the CopyOnWriteArrayList you set will never
actually be used, DS will install it’s own list. What is your evidence that
the field is never set? What happens if you make the field final, which will
result in the UPDATE fieldOption?
thanks
david jencks
> On Nov 28, 2016, at 2:51 PM, Roy Teeuwen <r...@teeuwen.be> wrote:
>
> Hey,
>
> Maybe I should start making a new thread for this hehe :). Not sure if this
> is a bug or if I'm just using it incorrectly.
>
> So created some test classes quickly.
> Don't know when it used to work with the immediate = true, but I guess it
> might not be related then, seeing as it wont work for field even with
> immediate true.
> I tried the following two examples. The one with the bind method does work,
> the one with field reference does not.
>
> # Field reference:
>
> @Component(service = TestAggregator.class)
> public class TestAggregator {
>
>@Reference(policy = ReferencePolicy.DYNAMIC, cardinality =
> ReferenceCardinality.MULTIPLE)
>private List interfaces = new
> CopyOnWriteArrayList();
>
> }
>
> generates following xml:
>
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.felix.osgi.ds.TestAggregator">
>
>
>
>
> interface="org.apache.felix.osgi.ds.TestInterface" field="interfaces"
> field-collection-type="service"/>
>
>
> # Method reference:
>
> @Component(service = TestAggregator.class)
> public class TestAggregator {
>
>@Reference(policy = ReferencePolicy.DYNAMIC, cardinality =
> ReferenceCardinality.MULTIPLE)
>protected void bindTestInterface(TestInterface testInterface) {
>interfaces.add(testInterface);
>}
>
>protected void unbindTestInterface(TestInterface testInterface) {
>interfaces.remove(testInterface);
>}
> }
>
> generates following xml:
>
>
>
>
>
>
>
> interface="org.apache.felix.osgi.ds.TestInterface"
> bind="bindTestInterface"
> unbind="unbindTestInterface"/>
>
>
> The field reference one won't bind an existing TestInterface service, the
> method reference will.
>
> Greets,
> Roy
>
>
>> On 29 Nov 2016, at 00:28, David Jencks <david.a.jen...@gmail.com> wrote:
>>
>> As everyone has said, the immediate setting isn’t going to make any
>> difference to the binding. You may be able to investigate what is going on
>> by installing gogo and looking at the output of scr:info in various
>> circumstances and also by installing an osgi logger and setting the
>> ds.loglevel=debug framework or ds configuration property and examining the
>> resulting voluminous log output.
>>
>> For the @Reference-on-field question could you show the component xml
>> generated by bnd (perhaps via the maven-bundle-plugin)? Which version of
>> bnd is in use? Some older versions didn’t figure out the service type very
>> well, and I’m not sure anyone has tested with the <> “diamond” notation
>> (although I can’t imagine how this could mess anything up).
>>
>> thanks
>> david jencks
>>
>>> On Nov 28, 2016, at 12:33 PM, Roy Teeuwen <r...@teeuwen.be> wrote:
>>>
>>> Hey Karel,
>>>
>>> Sorry to go further than the original question, but seeing as my question
>>> is related to exactly the same thing, maybe you can help me understand it
>>> better.
>>> Using the exact same example as the in the initial post, if I don't put
>>> immediate=true, it won't bind all of the services get created at startup or
>>> get added during the runtime. Is there a reason why it has to be immediate
>>> = true?
>>>
>>> I also tried it by using the following notation, and then this it doesn't
>>> even bind any of services:
>>>
>>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
>>> ReferencePolicy.DYNAMIC)
>>> private List stateMachines = new CopyOnWriteArrayList<>();
>>>
>>> Greetings,
>>> Roy
>>>> On 28 Nov 2016, at 21:39, Karel Haeck <karel.ha...@telenet.be> wrote:
>>>>
>>>> Nicolas,
>>>>
>>>> the spec does not specify that static references should be injected before
>>>> dynamic,
>>>> but it does specify that references must be processed in sequence as
>>>> specified i
Re: SCR: Issues with static reference mixed with multiple dynamic ref
As everyone has said, the immediate setting isn’t going to make any difference
to the binding. You may be able to investigate what is going on by installing
gogo and looking at the output of scr:info in various circumstances and also by
installing an osgi logger and setting the ds.loglevel=debug framework or ds
configuration property and examining the resulting voluminous log output.
For the @Reference-on-field question could you show the component xml generated
by bnd (perhaps via the maven-bundle-plugin)? Which version of bnd is in use?
Some older versions didn’t figure out the service type very well, and I’m not
sure anyone has tested with the <> “diamond” notation (although I can’t imagine
how this could mess anything up).
thanks
david jencks
> On Nov 28, 2016, at 12:33 PM, Roy Teeuwen <r...@teeuwen.be> wrote:
>
> Hey Karel,
>
> Sorry to go further than the original question, but seeing as my question is
> related to exactly the same thing, maybe you can help me understand it
> better.
> Using the exact same example as the in the initial post, if I don't put
> immediate=true, it won't bind all of the services get created at startup or
> get added during the runtime. Is there a reason why it has to be immediate =
> true?
>
> I also tried it by using the following notation, and then this it doesn't
> even bind any of services:
>
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
> ReferencePolicy.DYNAMIC)
> private List stateMachines = new CopyOnWriteArrayList<>();
>
> Greetings,
> Roy
>> On 28 Nov 2016, at 21:39, Karel Haeck <karel.ha...@telenet.be> wrote:
>>
>> Nicolas,
>>
>> the spec does not specify that static references should be injected before
>> dynamic,
>> but it does specify that references must be processed in sequence as
>> specified in the component xml:
>>
>> "When binding services, the references are processed in the order in which
>> they are specified in the
>> component description. That is, target services from the first specified
>> reference are bound before
>> services from the next specified reference."
>>
>> In addition the spec specifies how @Reference annotations are ordered:
>>
>> " In the generated Component Description for a component, the references
>> must be ordered in ascending
>> lexicographical order (using String.compareTo ) of the reference names."
>>
>> Note that the default name is based on the field or method name. In your
>> case get aclService for the static reference
>> and "" (empty string) for the dynamic reference as spec states that the add
>> , bind or set prefix is removed.
>> ( Actually if one uses Java naming conventions the event methods will have
>> names starting with an upper case character and precede the field
>> references).
>>
>> By specifying e.g. @Reference( name = "zStateMachine", cardinality =
>> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
>> the static reference should be bound first.
>>
>> Note that there is still a potential race condition between the add and an
>> activate method if present,
>> or between two concurrent add() executions.
>>
>> regards,
>> Karel
>>
>> On 28/11/2016 12:09, Nicolas Brasey wrote:
>>> Hi,
>>>
>>> I have a bind order issue with a component that has :
>>>
>>> 1) A static reference specified with annotation @Reference on the private
>>> field
>>> 2) A dynamic multiple reference specificed with annotation on a method
>>>
>>> The static reference is not bound before the dynamic ones.
>>>
>>> The code looks like this:
>>>
>>> @Component(immediate = true)
>>> public class MyServiceImpl implements MyService {
>>>
>>>@Reference
>>>private AclService aclService;
>>>
>>>@Reference(
>>>cardinality = ReferenceCardinality.MULTIPLE,
>>>policy = ReferencePolicy.DYNAMIC
>>>)
>>>public void add(StateMachine stateMachine) {
>>>
>>>
>>>}
>>>
>>>
>>> According to the Declarative Service specifications, the static references
>>> should always be injected before the activate method.
>>>
>>>
>>> Does anyone have any idea what might be wrong ?
>>>
>>>
>>> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
>>>
>>>
>>> Thanks for you help!
>>>
>>> Nicolas
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi and ObjectInputStream.readObject() deserialization classloading
I think I’m repeating what Christian said…. Deseriailizing arbitrary classes usually results in a giant security exposure, as there are exploits that result in arbitrary code execution on deserialization (not use!) of some commonly used library class instances. Most of the projects I’m involved in recently spent a lot of time rewriting their ObjectInputStreams to whitelist allowable classes. One approach I have used is for a bundle with classes that need to be deserialized to register those class names together with the bundle with the class loading apparatus. david jencks > On Oct 27, 2016, at 6:11 AM, Christopher BROWN <br...@reflexe.fr> wrote: > > Hi Scott, Hi Carsten, > > Overridding ObjectInputStream::resolveClass was what I needed. My > "fetch" method has 3 variants: > > /* uses Thread::getContextClassLoader */ > Object fetch(String id) > /* uses type.getClass().getClassLoader(), may not work if "type" is an > interface or superclass, mainly useful for a bundle's internal types > only */ > T fetchAs(String id, Class type) > > /* more flexible, caller must understand how things work, eg: type can > be an interface type, the definer can be a lambda capable of providing > a reference to an implementation bundle's classloader */ > T fetchAs(String id, Class type, Supplier definer) > > The last signature variant makes it possible to get similar behavior > to the IClassResolver example suggested by Scott (the filter approach > is clever, but might have a higher maintenance cost ; the use of a > Supplier function makes it possible to delegate to such an > implementation however). I considered the PackageAdmin (bundle > wiring) suggestion by Carsten, but I figured it might deserialise the > wrong class version if multiple bundles define similar classes (the > first match might be incorrect, it seems non-trivial to correctly and > efficiently select a classloader without a "brute force, trial and > error" approach). > > I had also considered providing my service using a ServiceFactory, > which could access the consumer's bundle classloader automatically, > however if the code calling "store" is in a different bundle from that > calling "fetch", it wouldn't help much. Perhaps it would be possible > to combine this approach with use of WeakReferences (referring to the > classloader of the bundle that invoked "store"), automatically > invaliding the stored (serialized) object if the "storer" classloader > was de-referenced... but I felt that that approach was _too_ > aggressive (because all I can assume was that the "storer" classloader > was able to find the classloader -- via imported packages -- and not > assume that it was the actual classloader). > > For my use cases, that seems like the best trade-off for deterministic > behavior, small API surface, and flexibility (all the other "smart" > cases would seem to be vulnerable to side effects). > > Thanks for your suggestions, I hope this message (once archived) is of > use to others. > > -- > Christopher > > > > On 26 October 2016 at 20:21, Scott Lewis <sle...@composent.com> wrote: >> Another (somewhat similar to Carsten's) approach to this is the one that >> we've implemented in ECF's Remote Services/RSA implementation [1]. >> >> We've got a service interface: IClassResolver [2] and a ObjectInputStream >> subclass called ClassResolverObjectInputStream. The way that this works is >> that when creating a ClassResolverInputStream one specifies a filter for >> finding (via service registry) the IClassResolver service instance to use to >> resolve the class upon first deserialization. For example, a particular >> bundle (with version) that is to be responsible for resolving the classes >> (bundle.loadClass) for that ObjectInputStream [4]. Of course, other/custom >> implementations of IClassResolver are possible as well, but so far we have >> found the BundleClassResolver + ClassResolverObjectInputStream useful. >> >> Scott >> >> [1] http://wiki.eclipse.org/Eclipse_Communication_Framework_Project >> [2] >> http://download.eclipse.org/rt/ecf/latest/javadoc/org/eclipse/ecf/core/util/IClassResolver.html >> [3] >> http://download.eclipse.org/rt/ecf/latest/javadoc/org/eclipse/ecf/core/util/ClassResolverObjectInputStream.html >> [4] >> http://download.eclipse.org/rt/ecf/latest/javadoc/org/eclipse/ecf/core/util/BundleClassResolver.html >> >> >> On 10/26/2016 9:03 AM, Carsten Ziegeler wrote: >>> >>> Christopher Brown wrote >>>> >>>> Hello, >>>> >>>> I n
Re: Unhappy log message from felix DS/CM, what is is trying to tell me?
It shouldn’t be error for sure. It just says the metatype spec classes aren’t available so it can’t register the ManagedService that also implements MetatypeProvider, so it’s just registering a ManagedService that doesn’t implement MetatypeProvider. Does info level seem appropriate? thanks david jencks > On Oct 7, 2016, at 7:30 AM, Benson Margulies <ben...@basistech.com> wrote: > > What is this about? I have DS and CM in my container. > > [java] ERROR: Cannot create MetaType providing ManagedService; > not providing Metatype information but just accepting configuration > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: setting the objectclassdefinition from felix file install
You spotted the problem.
For a component, the default pid is the component name and the default
component name is the class name. The @Designate annotation hooks up a
component with a single pid to the mentioned OCD. So….
Figure out what pid you want, either the FQCN, component name, or explicitly
specified pid
Hook the component and OCD together using either @Designate or specifying pid
in @ObjectClassDefinition, but not both
Make sure the file name matches the pid.
david jencks
> On Oct 3, 2016, at 10:38 AM, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Well, I'm not sure about that but because you've not named a pid in your
> component, it's not associating that with the configuration. Honestly, I'm
> not sure the pid in the OCD will get interpreted as being the pid of the
> configuration. My gut tells me it's not doing that. So you still need to
> name the pid in your component.
>
> Someone else may correct me of course. However, it should be simple to
> assert by adding the configurationPid property on the component and seeing
> if it does eventually bind.
>
> - Ray
>
> On Mon, Oct 3, 2016 at 1:27 PM, David Daniel <david.daniel.1...@gmail.com>
> wrote:
>
>> Thank you, I think I may be wrong somewhere else then. I have this in my
>> logs
>>
>> *DEBUG*
>> listConfigurations(filter=(felix.fileinstall.filename=
>> file:/media/david/abcd2f06-6ee4-4c5a-8c80-e4023ec8a52c/
>> development/asae/asae-base/packaging/all/etc/com.marklogic.cfg))
>> *DEBUG* Listing configurations matching
>> (felix.fileinstall.filename=file:/media/david/abcd2f06-
>> 6ee4-4c5a-8c80-e4023ec8a52c/development/asae/asae-base/
>> packaging/all/etc/com.marklogic.cfg)
>> Creating configuration from com.marklogic.cfg
>> *DEBUG* getConfiguration(pid=com.marklogic, location=null)
>>
>> does setting the pid as I did above not do what I thought it would do.
>>
>>
>> On Mon, Oct 3, 2016 at 1:12 PM, Raymond Auge <raymond.a...@liferay.com>
>> wrote:
>>
>>> Make the configuration mandatory in the component!
>>>
>>> - Ray
>>>
>>> On Mon, Oct 3, 2016 at 1:08 PM, David Daniel <
>> david.daniel.1...@gmail.com>
>>> wrote:
>>>
>>>> I have an object class definition
>>>>
>>>> @ObjectClassDefinition(name = "Marklogic Configuration",
>>>> pid = "com.marklogic")
>>>> @interface MarklogicConfig {
>>>>String content_host() default "localhost";
>>>>String content_username() default "admin";
>>>>String content_pword() default "**";
>>>>String content_dbname() default "";
>>>> }
>>>>
>>>> and a component
>>>>
>>>> @Component(service = {MarkLogicConnector.class})
>>>> @Designate(ocd = MarklogicConfig.class)
>>>> public class MarkLogicConnector {
>>>>
>>>> I have the felix file install bundle installed and working. It seems
>>> like
>>>> it is loading com.marklogic.cfg correctly. Is there a way to make sure
>>>> that the file is loaded before the configuration is passed into the
>>>> activate method. I seem to be getting the default values rather than
>> the
>>>> configured ones that came from fileinstall.
>>>>
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi Declarative Services
Yes :-) I think you’ll like it…. I did :-) david jencks > On Oct 2, 2016, at 2:56 PM, Roy Teeuwen <r...@teeuwen.be> wrote: > > Hey Neil, > > Thanks, I guess I have to use ObjectClassDefinition and AttributeDefinition > annotations then :) > > Greets > Roy >> On 2 Oct 2016, at 23:46, Neil Bartlett <njbartl...@gmail.com> wrote: >> >> Oh I see. For that you should use a configuration type. See the first >> section of >> http://njbartlett.name/2015/08/17/osgir6-declarative-services.html >> <http://njbartlett.name/2015/08/17/osgir6-declarative-services.html> >> >> Regards, >> Neil >> >> >> >>> On 2 Oct 2016, at 22:43, Roy Teeuwen <r...@teeuwen.be >>> <mailto:r...@teeuwen.be>> wrote: >>> >>> Hey Neil, >>> >>> See >>> http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property >>> >>> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property><http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property >>> >>> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property>> >>> Here you see you can also assign a label and a description to a property, >>> these will then be shown when configuring a component in the felix web >>> console. >>> Thats what I am looking for in the new OSGi DS >>> >>> Greets, >>> Roy >>>> On 2 Oct 2016, at 23:37, Neil Bartlett <njbartl...@gmail.com> wrote: >>>> >>>> Hi Roy, >>>> >>>> What are you looking for exactly? Service properties are simply key-value >>>> pairs. >>>> >>>> Regards, >>>> Neil >>>> >>>> >>>>> On 2 Oct 2016, at 22:13, Roy Teeuwen <r...@teeuwen.be> wrote: >>>>> >>>>> Hey all, >>>>> >>>>> Seeing as we upgraded our instance, we want to switch from Apache Felix >>>>> SCR Annotations to OSGi Declarative Services for new components. >>>>> One of the things I noticed is that there is no @Property and @Properties >>>>> in declarative services. Is there still a way to provide label and >>>>> descriptions for properties? >>>>> Looking at the @Component it is just key=value property types, without >>>>> any extra metadata. >>>>> >>>>> Greets, >>>>> Roy >>>>> - >>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> <mailto:users-unsubscr...@felix.apache.org> >> For additional commands, e-mail: users-h...@felix.apache.org >> <mailto:users-h...@felix.apache.org> - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Does SCR have to start before the bundles with services?
Neither this nor restarting the framework should cause problems. Can you come up with a self contained demonstration of this (no components) behavior? I vaguely recall someone having a similar problem that I couldn’t reproduce. thanks david jencks > On Sep 28, 2016, at 8:50 AM, Benson Margulies <ben...@basistech.com> wrote: > > On Wed, Sep 28, 2016 at 11:43 AM, David Jencks > <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> > wrote: >> It should work in any order. > > OK, then I've got some other problem on my hands. Does the last of > these three messages indicate a problem? > > 177 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Starting > with globalExtender setting: false > 181 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Version = 2.0.6 > 242 [CM Configuration Updater (ManagedService Update: > pid=[org.apache.felix.scr.ScrService])] ERROR > org.apache.felix.scr.2.0.6 - Cannot create MetaType providing > ManagedService; not providing Metatype information but just accepting > configuration > > > > >> >> david jencks >> >>> On Sep 28, 2016, at 8:28 AM, Benson Margulies <ben...@basistech.com> wrote: >>> >>> I'm trying to retrofit SCR/DS into a very dumb application that loads >>> some bundles and starts the framework. Everything is at the same start >>> level, and no @Components are ever activated. >>> >>> I have logging working; I see >>> >>> 191 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Starting >>> with globalExtender setting: false >>> 195 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Version = 2.0.6 >>> >>> In a more sophisticated cousin of this, I carefully start SCR and DS >>> at one start level, and only after they are started do I get involved >>> in starting the rest. I wonder: is this in fact a requirement, or >>> should I look for some other explanation of why the dumber app is not >>> activating anything. >>> >>> If I start up a container to a shell command line everything works >>> fine, so I can't get any diagnostic traction that way. >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
Re: Does SCR have to start before the bundles with services?
It should work in any order. david jencks > On Sep 28, 2016, at 8:28 AM, Benson Margulies <ben...@basistech.com> wrote: > > I'm trying to retrofit SCR/DS into a very dumb application that loads > some bundles and starts the framework. Everything is at the same start > level, and no @Components are ever activated. > > I have logging working; I see > > 191 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Starting > with globalExtender setting: false > 195 [FelixStartLevel] INFO org.apache.felix.scr.2.0.6 - Version = 2.0.6 > > In a more sophisticated cousin of this, I carefully start SCR and DS > at one start level, and only after they are started do I get involved > in starting the rest. I wonder: is this in fact a requirement, or > should I look for some other explanation of why the dumber app is not > activating anything. > > If I start up a container to a shell command line everything works > fine, so I can't get any diagnostic traction that way. > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: JNI, classloaders, framework shutdown
Ah, I didn’t read your first post closely enough….. IIUC your code is loading the native library, you are not using OSGI native code support? Can you modify things to use OSGI native code support? david jencks > On Sep 17, 2016, at 4:16 PM, Benson Margulies <ben...@basistech.com> wrote: > > On Sat, Sep 17, 2016 at 7:05 PM, David Jencks > <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> > wrote: >> I have no idea what I’m talking about, but I had the vague idea that osgi >> frameworks get around this by copying the native library to a new, unique, >> location each time the bundle[revision] starts. The link into your local >> maven repo doesn’t seem like it’s native code that’s actually in a bundle. >> Do you have any idea how this path relates to your bundle containing the >> native code? > > That makes a great deal of sense. In our case, the native code is not > in Maven at all; it's sitting in an outboard product installation > directory along with 100 tons of NLP models and dictionaries. > > However, I'm trying to build something that someone else embeds into > an arbitrary Java application (and I launch the OSGi framework for > them). So, getting the temporary directory into java.library.path is > not going to be straightforward. Options I see include simply changing > the filename but using the same directory, or changing the Java code > to know how to call System.load (which takes a pathname) instead of > System.loadLibrary (which looks in java.library.path). > >> >> david jencks >> >>> On Sep 17, 2016, at 3:57 PM, Benson Margulies <ben...@basistech.com> wrote: >>> >>> Has anyone out there succeeded shutting down the Felix container and >>> having the classloaders GC to the point where native classes are no >>> longer loaded, so that the same JVM can then start a new framework and >>> again load the same native classes? >>> >>> To be a bit more precise, I have a bundle that includes some native >>> classes. I start the framework, load and start this bundle, and it >>> does the System.loadLibrary to load up these classes. >>> >>> I shut down the framework, and try again, and get: >>> >>> 18:51:39.140 [Thread-4] ERROR r.1.4.0.201609171300 - >>> [com.basistech.ws.worker.core.Worker(8)] The activate method has >>> thrown an exception >>> java.lang.UnsatisfiedLinkError: Native Library >>> /Users/benson/.m2/repository/bt/rosapi/roots/native/7.14.100.0/rlp/lib/amd64-darwin11-xcode4/libbtnamesutiljni.dylib >>> already loaded in another classloader >>> >>> My vague sense is that it's somewhere between difficult and impossible >>> to get native code cleaned up enough to make this work, but I wondered >>> if anyone else had succeeded using Felix. >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
Re: Prop expansion via fileinstall but not configuration admin
Along with Carsten, I’m confused by your jira report. What happens when you
create a configuration in code and try to update it with your property? Can
you get it back? There might be a problem with persisting such a property, but
your test doesn’t demonstrate it because perhaps the persistence is encoding
the value somehow.
thanks
david jencks
> On Sep 17, 2016, at 9:59 AM, Benson Margulies <ben...@basistech.com> wrote:
>
> I could commit this test, which fails, if you like, with an @Ignore.
>
>
> public class InvalidFileSyntaxTest {
>private static final String CONFIG = "rootPath=${bt.root}\n";
>
>@Test
>public void testPropSyntax() throws IOException
>{
>final Dictionary dict = ConfigurationHandler.read(new
> ByteArrayInputStream(CONFIG.getBytes("UTF-8")));
>assertEquals(1, dict.size());
>assertEquals("${bt.root}", dict.get("rootPath"));
>}
> }
>
> On Sat, Sep 17, 2016 at 12:49 PM, Benson Margulies <ben...@basistech.com>
> wrote:
>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>> <david_jen...@yahoo.com.invalid> wrote:
>>>
>>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org
>>>> <mailto:cziege...@apache.org>> wrote:
>>>>>> I don’t think this belongs in ca. You could use a ConfigurationPlugin.
>>>>>> Unfortunately you’ll have to wait till R7 until this works with DS.
>>>>>> Maybe Carsten already implemented the CA part, but I didn’t do the DS
>>>>>> part yet.
>>>>
>>>> Interesting. When I tried to use such a file with CA, the low-level
>>>> parser rejected the ${x} syntax long before a plugin would get a
>>>> chance to modify the dictionary contents, or so I thought.
>>>
>>> I’ve been assuming you only want to put the ${xxx} in values, where I’d
>>> expect it to be a fine persistable value…. you weren’t using it as a key
>>> were you (where it won’t work AFAIK)?
>>
>> Nope, just as a value (${bt.foo.bar}). I opened a JIRA about the fact
>> that CA discarded the entire file without even a log message. I
>> assumed that it had to do with the syntax for arrays and such that the
>> parser supports.
>>
>>
>>>
>>> david jencks
>>>
>>>>
>>>>>>
>>>>>
>>>>> I've implemented both parts, the CA part is in trunk, the DS part is in
>>>>> the sandbox branch, but I plan to move it to trunk soon.
>>>>>
>>>>> Carsten
>>>>>
>>>>>> Alternatively you can code it into whatever management agent you are
>>>>>> using instead of fileinstall.
>>>>>>
>>>>>> Maybe others have other opinions….
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> The system property expansion feature of the configuration-admin
>>>>>>> behavior of fileinstall is quite convenient. I could code it,
>>>>>>> optionally, into confadmin. I wish I could have it without all the
>>>>>>> other mechanism of fileinstall that I don't need. Acceptable?
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziege...@apache.org
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> <mailto:users-unsubscr...@felix.apache.org>
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>> <mailto:users-h...@felix.apache.org>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Prop expansion via fileinstall but not configuration admin
> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> wrote:
>
> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org
> <mailto:cziege...@apache.org>> wrote:
>>> I don’t think this belongs in ca. You could use a ConfigurationPlugin.
>>> Unfortunately you’ll have to wait till R7 until this works with DS. Maybe
>>> Carsten already implemented the CA part, but I didn’t do the DS part yet.
>
> Interesting. When I tried to use such a file with CA, the low-level
> parser rejected the ${x} syntax long before a plugin would get a
> chance to modify the dictionary contents, or so I thought.
I’ve been assuming you only want to put the ${xxx} in values, where I’d expect
it to be a fine persistable value…. you weren’t using it as a key were you
(where it won’t work AFAIK)?
david jencks
>
>>>
>>
>> I've implemented both parts, the CA part is in trunk, the DS part is in
>> the sandbox branch, but I plan to move it to trunk soon.
>>
>> Carsten
>>
>>> Alternatively you can code it into whatever management agent you are using
>>> instead of fileinstall.
>>>
>>> Maybe others have other opinions….
>>>
>>> david jencks
>>>
>>>
>>>
>>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> The system property expansion feature of the configuration-admin
>>>> behavior of fileinstall is quite convenient. I could code it,
>>>> optionally, into confadmin. I wish I could have it without all the
>>>> other mechanism of fileinstall that I don't need. Acceptable?
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> <mailto:users-unsubscr...@felix.apache.org>
> For additional commands, e-mail: users-h...@felix.apache.org
> <mailto:users-h...@felix.apache.org>
Re: Prop expansion via fileinstall but not configuration admin
I don’t think this belongs in ca. You could use a ConfigurationPlugin. Unfortunately you’ll have to wait till R7 until this works with DS. Maybe Carsten already implemented the CA part, but I didn’t do the DS part yet. Alternatively you can code it into whatever management agent you are using instead of fileinstall. Maybe others have other opinions…. david jencks > On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com> wrote: > > The system property expansion feature of the configuration-admin > behavior of fileinstall is quite convenient. I could code it, > optionally, into confadmin. I wish I could have it without all the > other mechanism of fileinstall that I don't need. Acceptable? > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: CM and DS logging interpretation
Dunno about the config admin logging, but if you don’t see any activity setting up a component manager in the DS logs, DS didn’t get a configuration for your component. The gogo scr:info command will show this more easily, there won’t be any component configurations after the component description. Is there a config admin gogo command to show you all the configurations it found? david jencks > On Sep 16, 2016, at 7:37 AM, Benson Margulies <ben...@basistech.com> wrote: > > I need some help interpreting the logging from DS and CM, if someone > could be kind enough to have a look at the material below. > > I have an @Component named WorkerBusService which is never activated. > I see no SCR messages related to it in the log except for other > components trying to depend on it. > > It need a configuration (configured policy = REQUIRED). > > I believe that the necessary file is sitting in the directory > configured with felix.cm.dir. I suspect that the log messages below > are trying to tell me something about this, one way or the other. It > says 'listing configurations for', but then doesn't list any. Does > this mean that it didn't find it? I set the CM log level all the way > up (to 4). > > 10:25:34.474 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 - > BundleComponentActivator : Bundle [86] ComponentHolder created for > com.basistech.ws.worker.bus.impl.BusService > 10:25:34.475 [main] DEBUG org.apache.felix.configadmin.1.8.10 - > [[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar))) > 10:25:34.475 [main] DEBUG org.apache.felix.configadmin.1.8.10 - > [[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations > matching > (|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar)) > 10:25:34.476 [main] DEBUG org.apache.felix.configadmin.1.8.10 - > [[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar))) > 10:25:34.476 [main] DEBUG org.apache.felix.configadmin.1.8.10 - > [[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations > matching > (|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar)) > 10:25:34.476 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 - > BundleComponentActivator : Bundle [86] May enable component holder > com.basistech.ws.worker.bus.impl.BusService > 10:25:34.476 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 - > BundleComponentActivator : Bundle [86] Enabling component holder > com.basistech.ws.worker.bus.impl.BusService > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DM4 service factory/multiple service instance support
I’d be really amazed if this worked. I imagine that DM is quite similar to DS,
and you definitely can’t do that in DS, you have to use the scope rather than
trying to write your own serviceFactory or PrototypeServiceFactory. If your
service is e.g. ServiceFactory that’s what you’ll get when you look up the
service, not the service it’s a factory for. DS already registers a
ServiceFactory for each component.
Hopefully someone who actually knows something about DM will speak up soon :-)
david jencks
> On Aug 24, 2016, at 5:54 PM, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> I'm fairly certain that DM supports publishing services of any type and
> doesn't care about scoping, including implementations of
> PrototypeServiceFactory.
>
> Mdu, your service simply needs to implement PrototypeServiceFactory and you
> should be able to use the DM's imperative API as usual.
>
> But any other DM experts may correct me if this is wrong.
>
> - Ray
>
> On Wed, Aug 24, 2016 at 3:13 PM, mduduzik <mduduzi.ke...@gmail.com> wrote:
>
>> Ray/David,
>> Thanks for your prompt responses. I would like to accomplish this using
>> API/Activator approach in DM4 (Felix Dependency Manager 4). Here's the
>> context within which I would like to do this:
>>
>> public class Activator extends DependencyActivatorBase {
>>@Override
>>public void init(BundleContext ctx, DependencyManager dm) throws
>> Exception
>> {
>>}
>> }
>>
>> So in other words, a non-Annotation based approach. I hope my request is
>> clearer.
>>
>> Regards.
>> -Mdu
>>
>>
>>
>> --
>> View this message in context: http://apache-felix.18485.x6.
>> nabble.com/DM4-service-factory-multiple-service-instance-support-
>> tp5018226p5018230.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: DM4 service factory/multiple service instance support
I think he wants something like DS’s prototype scope in DependencyManager 4….. I don’t know if it’s available. david jencks > On Aug 24, 2016, at 12:02 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > On Wed, Aug 24, 2016 at 2:17 PM, mduduzik <mduduzi.ke...@gmail.com > <mailto:mduduzi.ke...@gmail.com>> wrote: > >> I would like to create and new instance of component for every service >> request. I believe by default a component is a singleton - i.e. the same >> instance will be returned for every service consumer request. In DS/SCR, >> this is accomplished by using a factory property in @Component declaration. >> > > Correction! That is done by using the prototype scope [1][2]. > > To do this outside of DS use a PrototypeServiceFactory [3] > > Sincerely, > - Ray > > [1] > https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/Component.html#scope() > > <https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/Component.html#scope()> > [2] > https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/ServiceScope.html#PROTOTYPE > > <https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/ServiceScope.html#PROTOTYPE> > [3] > https://osgi.org/javadoc/r6/core/org/osgi/framework/PrototypeServiceFactory.html > > <https://osgi.org/javadoc/r6/core/org/osgi/framework/PrototypeServiceFactory.html> > > > >> Thanks. >> -Mdu >> >> >> >> >> -- >> View this message in context: http://apache-felix.18485.x6. >> nabble.com/DM4-service-factory-multiple-service- >> instance-support-tp5018226.html >> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile > <http://www.liferay.com/web/raymond.auge/profile>> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com > <http://www.liferay.com/>> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org > <http://osgi.org/>> (@OSGiAlliance)
Re: DM4 service factory/multiple service instance support
With regards to DS, I think you might be confusing factory component (where you get instances of your component by calling componentFactoryService.newInstance(…)) with prototype scope (where you can use a ServiceObjects.getService() call to obtain a new instance of the service for each call). thanks david jencks > On Aug 24, 2016, at 11:17 AM, mduduzik <mduduzi.ke...@gmail.com> wrote: > > I would like to create and new instance of component for every service > request. I believe by default a component is a singleton - i.e. the same > instance will be returned for every service consumer request. In DS/SCR, > this is accomplished by using a factory property in @Component declaration. > > Thanks. > -Mdu > > > > > -- > View this message in context: > http://apache-felix.18485.x6.nabble.com/DM4-service-factory-multiple-service-instance-support-tp5018226.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Bundles needed to use DS/SCR
As discussed on another thread today, this one-arg getConfiguration call nails
the configuration to the bundle doing the calling, which usually isn’t what you
want since it usually isn’t the bundle with the component you’re trying to
configure. Use the 2-arg getConfiguration method passing either null, the
actual bundle location, or “?”.
Since DS is no longer trying to set the bundle location, null leaves your
component vulnerable to something else that does set it to the wrong bundle.
Using the actual bundle location means you have to know what it is, but
restricts the configuration to that one bundle.
“?” lets all bundles see the configuration.
david jencks
> On Aug 10, 2016, at 8:29 AM, Benson Margulies <ben...@basistech.com> wrote:
>
> Configuration-wise, I have the following code. Logging-wise, I have
> pax-exam installing logging, but I will recheck that.
>
>
> org.osgi.service.cm.Configuration workerConf =
> configurationAdmin.getConfiguration("com.basistech.ws.worker");
> Dictionary<String, Object> props = new Hashtable<>();
>
> Path mainWorkerConfigPath =
> Paths.get("../../assemblies/common/configuration/src/main/resources/rosapi/worker-config.yaml");
> Path testEndpointPath = Paths.get("src/test/config/endpoints.yaml");
>
> props.put("configurationFilePathname",
> mainWorkerConfigPath.toAbsolutePath().toString());
> props.put("endpointsPathname", testEndpointPath.toAbsolutePath().toString());
>
> workerConf.setBundleLocation(null);
> workerConf.update(props);
>
>
>
> On Wed, Aug 10, 2016 at 11:17 AM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>>> Configuration Policy: require
>>
>>> (No Component Configurations)
>>
>> You need a configuration or change the configuration policy.
>>
>> Is your minimal container so minimal that it doesn’t include a log service
>> or something to collect messages from it?
>>
>> david jencks
>>
>>> On Aug 10, 2016, at 8:14 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> I have some more information. While I still don't know where my log
>>> message are going, I turned on the gogo remote shell. According to
>>> scr:info, my component is alive.
>>>
>>> However, I can't obtain a service reference to the service it exports
>>> with a plain old ServiceTracker or call to my bundle context. I'd be
>>> grateful for any diagnostic advice.
>>>
>>>
>>> scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>> *** Bundle: rosapi-worker-core (56)
>>> Component Description:
>>> Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>> Implementation Class:
>>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>> Default State: enabled
>>> Activation: immediate
>>> Configuration Policy: require
>>> Activate Method: activate
>>> Deactivate Method: deactivate
>>> Modified Method: -
>>> Configuration Pid:
>>> [com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
>>> Services:
>>> com.basistech.ws.worker.core.config.WorkerConfiguration
>>> Service Scope: singleton
>>> Reference: ConfigurationAdmin
>>> Interface Name: org.osgi.service.cm.ConfigurationAdmin
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>> Component Description Properties:
>>> (No Component Configurations)
>>>
>>> On Wed, Aug 10, 2016 at 10:32 AM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>> For unit testing purposes, I'm setting up a minimal container that has
>>>> DS/SCR .
>>>>
>>>> I included:
>>>>
>>>> org.apache.felix
>>>> org.apache.felix.scr
>>>> 2.0.6
>>>>
>>>> I set the framework ds.loglevel property to debug, and I see no sign of
>>>> life.
>>>>
>>>> I'm using standard OSGi DS annotations.
>>>>
>>>> Can anyone tell me what I'm missing?
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Bundles needed to use DS/SCR
> Configuration Policy: require > (No Component Configurations) You need a configuration or change the configuration policy. Is your minimal container so minimal that it doesn’t include a log service or something to collect messages from it? david jencks > On Aug 10, 2016, at 8:14 AM, Benson Margulies <ben...@basistech.com> wrote: > > I have some more information. While I still don't know where my log > message are going, I turned on the gogo remote shell. According to > scr:info, my component is alive. > > However, I can't obtain a service reference to the service it exports > with a plain old ServiceTracker or call to my bundle context. I'd be > grateful for any diagnostic advice. > > > scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl > *** Bundle: rosapi-worker-core (56) > Component Description: > Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl > Implementation Class: > com.basistech.ws.worker.core.config.WorkerConfigurationImpl > Default State: enabled > Activation: immediate > Configuration Policy: require > Activate Method: activate > Deactivate Method: deactivate > Modified Method: - > Configuration Pid: > [com.basistech.ws.worker.core.config.WorkerConfigurationImpl] > Services: >com.basistech.ws.worker.core.config.WorkerConfiguration > Service Scope: singleton > Reference: ConfigurationAdmin >Interface Name: org.osgi.service.cm.ConfigurationAdmin >Cardinality: 1..1 >Policy: static >Policy option: reluctant >Reference Scope: bundle > Component Description Properties: > (No Component Configurations) > > On Wed, Aug 10, 2016 at 10:32 AM, Benson Margulies <ben...@basistech.com> > wrote: >> For unit testing purposes, I'm setting up a minimal container that has >> DS/SCR . >> >> I included: >> >> org.apache.felix >> org.apache.felix.scr >> 2.0.6 >> >> I set the framework ds.loglevel property to debug, and I see no sign of life. >> >> I'm using standard OSGi DS annotations. >> >> Can anyone tell me what I'm missing? > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Cannot use configuration pid ... for bundle XX because it belongs to bundle YY
null works, ds < 2.0.4 will (except for unusual situations not likely here) set
the bundle location to the using bundle, ds >-2.0.4 will leave it null. This
will “claim” the configuration for the using bundle.
? works with a R5+ config admin and multiple bundles can use the configuration.
david jencks
> On Aug 10, 2016, at 7:36 AM, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Carsten, are you sure about null and not the literal string "?"
>
> - Ray
>
> On Wed, Aug 10, 2016 at 9:57 AM, Carsten Ziegeler <cziege...@apache.org>
> wrote:
>
>>> Did not find any annotation in those components, they actually get
>> configured using the ConfigurationAdmin.
>>>
>>> Error:
>>> >> pid=com.kuka.authorizationService.component
>> for bundle 7 because it belongs to bundle 77>
>>>
>>> OSGI-LIB\*.xml:
>>> http://www.osgi.org/xmlns/scr/v1.1.0;
>> activate="activate" configuration-policy="require" deactivate="deactivate"
>> immediate="true" name="com.kuka.authorizationService.component">
>>>
>>>
>>>
>>>
>>> >> bind="setServiceRegistry"
>>> cardinality="1..1"
>>> interface="comIServiceRegistry"
>>> name="IServiceRegistry"
>>> configuration-policy="require"
>>> policy="static"/>
>>>
>>>
>>> The component itself that has no annotations at all:
>>> [...]
>>> import com.IServiceRegistry;
>>>
>>> /**
>>> * The OSGI component for the {@link AuthorizationService}.
>>> */
>>> public class AuthorizationServiceComponent implements
>> IAuthorizationOsgiService
>>> [...]
>>>
>>> The main bundle activator does the following regarding this component:
>>> Dictionary<String, Object> properties = new Hashtable<String, Object>();
>>> properties.put("userRolesFile", "someFileSystemPath");
>>> properties.put("userCredentialsFile", "someFileSystemPath");
>>> configAdmin.getConfiguration("com.kuka.authorizationService.
>> component").update(properties);
>>
>> This is exactly your problem :) With this you bind the configuration to
>> the bundle executing this code and then DS can't use it anymore. Change
>> it to use the two argument getConfiguration method and pass null as the
>> second argument (location).
>>
>> Regards
>> Carsten
>>>
>>> Interesting that all bundles that are configured like this end in such
>> an error.
>>> The application I try to wrap was built in equinox and starts there
>> without issues.
>>>
>>>
>>>
>>> -Original Message-
>>> From: Benson Margulies [mailto:ben...@basistech.com]
>>> Sent: Mittwoch, 10. August 2016 12:46
>>> To: users@felix.apache.org
>>> Subject: Re: Cannot use configuration pid ... for bundle XX because it
>> belongs to bundle YY
>>>
>>> In my experience, it means that you have annotated two different classes
>> with @Component and specified the same configurationPid. You can't do that;
>> if you need to share a configuration between DS components, you have to
>> inject the ConfigurationAdmin service instead of using the @Component
>> annotation.
>>>
>>> On Wed, Aug 10, 2016 at 3:32 AM, Remo Liechti <remo.liec...@swisslog.com
>>>
>>> wrote:
>>>
>>>> Hi guys
>>>>
>>>> During starting of bundles I get the following message:
>>>>
>>>> >>> pid=com.kuka.configuration.manager for bundle 17 because it belongs to
>>>> bundle 7>
>>>>
>>>> What does this actually mean? I have not found good information with
>>>> uncle sams google.
>>>> What I do, is the following:
>>>> - Wrap an osgi application into a j2ee web application (war file)
>>>> - Using Felix on Weblogic: https://docs.oracle.com/
>>>> middleware/1212/wls/WLPRG/osgi.htm
>>>> - My main bundle activator is called, using a servlet I start all
>>>> other bundles manually
>>>>
>>>>
>>>> @Resource(lookup = "java:app/osgi/Bundle") Bundle bundle;
>>>>
>>>> BundleContext bc = bundle.getBundleContext(); for (Bundle b :
>>>> bc.getBundles()) { [] b.start(); [...]
Re: Logging uncaught exceptions?
BundleActivator behavior and DS component behavior are completely unrelated.
I strongly suspect that you haven’t installed anything to record the logging or
display it to you? IIRC pax-logging is a popular way to hook osgi logging up
to slf4j and make it easy to configure where it goes.
thanks
david jencks
> On Aug 4, 2016, at 12:29 PM, list+org.apache.fe...@io7m.com wrote:
>
> Hello.
>
> I have a simple declarative service such as:
>
> --8<--
> @Component(immediate = true)
> public final class Speaker implements SpeakerType
> {
> public Speaker()
> {
>System.out.println("Speaker (declarative): constructor");
> }
>
> @Activate
> private void onActivate()
> {
>System.out.println("Speaker (declarative): onActivate");
> }
>
> @Override
> public void speak(final String text)
> {
>System.out.println("Speaker (declarative): speak: " + text);
> }
> }
> -->8--
>
> If I throw an exception in either the constructor or the onActivate()
> method, I get no indication that this has happened. A quick search
> through the core spec for the word "exceptions" leads me to 9.3.6,
> which I think may be relevant even though I'm going through the
> declarative services service:
>
> If the BundleActivator.start or stop method throws an Exception, then
> the handling of this Exception is different depending who invoked
> the start or stop method.
>
> If the bundle is started/stopped due to a change in the active start
> level or the bundle's start level, then the Exception must be wrapped
> in a BundleException and broadcast as a FrameworkEvent.ERROR event.
> Otherwise, a new BundleException must be created containing the
> exception and this BundleException is then thrown to the caller.
>
> So I assume that I need to register some sort of listener to receive
> errors. However, even assuming that I do this: What if the exception is
> of a type that the listener does not import?
>
> Is there a bundle in the distribution that handles this? I have the Log
> service installed, but that doesn't appear to do anything (unless it
> requires extra configuration - I've not given it any). I just
> want errors logged to the console during development so that I don't
> sit here trying to debug silent failures.
>
> M
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: doubt about component DS 1.3 with scope Prototype and ConfigurationPolicy.REQUIRE
I’m not sure I’m receiving all your replies….
Most of the things you can specify for a DS component are completely
independent, which makes it very powerful, but there are a couple that aren’t
and that can be confusing.
It’s unusual to need to specify enabled=false. I don’t think I ever have. It
might be useful if some other component needs to set up an environment without
which the disabled component doesn’t make sense.
Configuration policy and scope are independent. Configuration policy is also
somewhat confusing since whether you get one instance or many is determined by
config admin, not DS.
For instance if you are using a factory pid in config admin, you can get as
many component configurations as you want, one for each configuration. For
each of those, the scope determines how many instances the configuration might
have. Singleton scope means you get at most one, and all requestors get the
same service instance. This is the only scope that is compatible with
immediate. Bundle scope means all requestors from the same bundle get the same
instance, and requestors from different bundles get different instances.
Prototype scope means if you use the ServiceObjects interface you can get as
many instances as you want.
There’s also stuff you can now do with multiple pids but maybe the above is
enough for now….
hope this helps
david jencks
> On Jun 27, 2016, at 3:32 PM, Cristiano Gavião <cvgav...@gmail.com> wrote:
>
> Sorry, my mistake...
>
> only now I understood what you have said about enable=true be the default
> value... :-[
>
> On 27/06/2016 19:16, Cristiano Gavião wrote:
>>
>>
>> On 27/06/2016 18:48, David Jencks wrote:
>>> You’ve specified prototype scope, so there is never going to be “ONE”
>>> canonical instance. You need something to request the service from the
>>> service reference or from the ServiceObjects interface from the service
>>> reference.
>>>
>>> With the default scope, you aren’t going to get an instance created without
>>> a user either unless you specify immediate=true as well.
>> if I understood the spec right, when I use immediate=true then I get a
>> Singleton scope, right?
>>
>> Would a component with scope singleton use ConfigurationPolicy.REQUIRE ?
>>
>>>
>>> I generally don’t specify enabled=true since that is the default value.
>> then you let your components as enabled=false and then will use a master
>> component to enable the others ?
>>
>>>
>>> david jencks
>>>
>>>> On Jun 27, 2016, at 2:42 PM, Cristiano Gavião <cvgav...@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm facing a situation that I'm not understanding. I'm using
>>>> org.apache.felix.scr 2.0.2.
>>>> I've set a component with this annotation:
>>>>
>>>> @Component(enabled = true, configurationPolicy =
>>>> ConfigurationPolicy.REQUIRE,
>>>>scope = ServiceScope.PROTOTYPE, service =
>>>> FixedControllerService.class,
>>>>configurationPid = {SERVICE_FACTORY_PID_CONTROLLER})
>>>>
>>>> http://www.osgi.org/xmlns/scr/v1.3.0;
>>>> name="com.c4biz.feast.ComponentControllerServiceProvider"
>>>> configuration-policy="require" enabled="true" activate="activate"
>>>> deactivate="deactivate" modified="modified"
>>>> configuration-pid="fixed.controller">
>>>> >>> class="com.c4biz.feast.ComponentControllerServiceProvider"/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In this component class I have a method (activate()) tagged with @Activate
>>>> annotation. And there are any reference bind being used for now.
>>>>
>>>> From another bundle I'm creating a configuration using factoryPID =
>>>> SERVICE_FACTORY_PID_CONTROLLER.
>>>> Interesting is that the service are being created and with in a proper
>>>> autogenerated PID and passed properties. At least I can see it when
>>>> listing the services using gogo console.
>>>>
>>>> also scr:list tells me that the component is enabled and satisfied.
>>>>
>>>> What I'm not understanding is that the activate method is not being
>>>> called...
>>>>
>>>> could someone explain me what am I missing here?
>>>>
>>>> thanks,
>>>>
>>>> Cristiano
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> <mailto:users-unsubscr...@felix.apache.org>
> For additional commands, e-mail: users-h...@felix.apache.org
> <mailto:users-h...@felix.apache.org>
Re: doubt about component DS 1.3 with scope Prototype and ConfigurationPolicy.REQUIRE
You’ve specified prototype scope, so there is never going to be “ONE” canonical
instance. You need something to request the service from the service reference
or from the ServiceObjects interface from the service reference.
With the default scope, you aren’t going to get an instance created without a
user either unless you specify immediate=true as well.
I generally don’t specify enabled=true since that is the default value.
david jencks
> On Jun 27, 2016, at 2:42 PM, Cristiano Gavião <cvgav...@gmail.com> wrote:
>
> Hello,
>
> I'm facing a situation that I'm not understanding. I'm using
> org.apache.felix.scr 2.0.2.
> I've set a component with this annotation:
>
> @Component(enabled = true, configurationPolicy =
> ConfigurationPolicy.REQUIRE,
>scope = ServiceScope.PROTOTYPE, service =
> FixedControllerService.class,
>configurationPid = {SERVICE_FACTORY_PID_CONTROLLER})
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="com.c4biz.feast.ComponentControllerServiceProvider"
> configuration-policy="require" enabled="true" activate="activate"
> deactivate="deactivate" modified="modified"
> configuration-pid="fixed.controller">
> class="com.c4biz.feast.ComponentControllerServiceProvider"/>
>
>
>
>
>
> In this component class I have a method (activate()) tagged with @Activate
> annotation. And there are any reference bind being used for now.
>
> From another bundle I'm creating a configuration using factoryPID =
> SERVICE_FACTORY_PID_CONTROLLER.
> Interesting is that the service are being created and with in a proper
> autogenerated PID and passed properties. At least I can see it when listing
> the services using gogo console.
>
> also scr:list tells me that the component is enabled and satisfied.
>
> What I'm not understanding is that the activate method is not being called...
>
> could someone explain me what am I missing here?
>
> thanks,
>
> Cristiano
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Same private service in different bundles
I join the calls telling you not to try hooks. DS has at least two mechanisms to allow you to configure different instances differently. Since the code and configuration xml are separate, you could just include different xml in each bundle. However, hopefully you are generating the component xml using bnd, so you’d get the same one everywhere. More flexibly, you can specify the component properties in a property file, using the @Component properties member. You can put properties files with the same name and location but different contents in each bundle. david jencks > On Jun 17, 2016, at 6:45 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > Vincent, what is the mechanism you are using to get the service? > > If you can use a service filter, then you can easily filter on the bundle > id of the service. Bundle id is a required property of services. > > It's simple to do this using a service tracker, but not simple with DS (DS > doesn't have a mechanism to let your write a target filter using local > bundle information as criteria, if so the solution would have been trivial). > > So, each of the bundles could start a service tracker which merely filters > on their own bundle id. > > - Ray > > On Fri, Jun 17, 2016 at 8:58 AM, Clement Escoffier < > clement.escoff...@gmail.com> wrote: > >> Hi, >> >> You may be able to achieve what you want with a composites: >> >> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.html >> < >> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.html >>> >> >> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-hierarchical-composition-overview.html >> < >> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-hierarchical-composition-overview.html >>> >> >> >> Regards, >> >> Clement >> >>> On 17 juin 2016, at 12:27, Vincent Vandemeulebrouck < >> vincent.vandemeulebro...@ullink.com> wrote: >>> >>> I need two different bundles to have the same private iPojo service, to >> be >>> used internally. It is defined in a shared library, included in both >> bundle. >>> >>> How can I enforce that the requiring service get the service from their >> own >>> bundle? >>> >>> Currently, as each bundle has the same service and same specifications, I >>> end-up having the private service from the other bundle injected, causing >>> some illegal accesses. >>> >>> Bundles are implemented in java. The issue is that each bundle has its >> own >>> ClassLoader, and injecting the class from the othe ClassLoader causes a >>> ClassCastException. >>> >>> >>> *--Vincent Vandemeulebrouck | *Architect - UL MIDDLE and Extensions *| >>> ULLINK | *D: +33 1 44 50 52 02* | *T: +33 1 49 95 30 00* | *23-25 rue de >>> Provence, 75009 Paris, FRANCE *|* vincent.vandemeulebro...@ullink.com >> *| * >>> >>> -- >>> *The information contained in or attached to this email is strictly >>> confidential. If you are not the intended recipient, please notify us >>> immediately by telephone and return the message to us.* >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Managing transactions in iPOJO or OSGi component
I don’t understand what you mean by “transaction”, “local transaction”, “global
transaction” or “manage transactions”. Does your usage of these terms have any
relationship with other established uses of (some of) them such as the XA
transaction spec? What properties do you want these transactions to have?
thanks
david jencks
> On May 25, 2016, at 1:23 PM, tho huynh ngoc <ngocthob...@gmail.com> wrote:
>
> Hi,
>
>
> I define a transaction is a set of continuous activities (one method or set
> of methods) in a component.
>
> I wrote a simple example as follows:
>
> //service interfacepublic interface Hello {
>String sayHello(String name);
>String sayBonjour(String name);}
> //service implementation @Componentpublic class HelloImpl implements Hello {
>
>public String sayHello(String name) {
> //start local transaction
> return "hello " + name;
> //finish local transaction
>}
>public String sayBonjour(String name) {
> //start local transaction
> return "bonjour " + name;
> //finish local transaction
>}}
> //client@Componentpublic class Client {
>
> Hello client;
> public Client() {
> //start local transaction
> client.sayHello("world");
> client.sayBonjour("le monde");
> //finish local transaction
> }
> }
>
> In this example, there are local transactions in the components HelloImpl
> and Client. I define that global transaction of the system consists of a
> set of local transactions through all components.
>
> How to manage transactions (global transaction and the local transtions in
> this example) in OSGi or iPOJO ?
>
> Thank you for your response
>
> Regards,
>
>
> 2016-05-25 21:12 GMT+02:00 tho huynh ngoc <ngocthob...@gmail.com>:
>
>> i'm sorry i have not finished my message in this mail
>>
>> 2016-05-25 21:09 GMT+02:00 tho huynh ngoc <ngocthob...@gmail.com>:
>>
>>> Hi,
>>>
>>> I define a transaction is a set of continuous activities (one method or
>>> set of methods) in a component.
>>>
>>> I wrote a simple example as follows:
>>>
>>> //service interface
>>> public interface Hello {
>>>String sayHello(String name);
>>> }
>>>
>>> //implementation service
>>> @Component
>>> public class HelloImpl implements Hello { public HelloImpl() {
>>>System.out.print("start Hello implementation");
>>>}
>>>
>>>public String sayHello(String name) { return "hello " + name; }
>>> }
>>>
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Looking into this more, the reason I didn’t support List etc originally is that its much more complicated to deal with figuring out the type information than with an array. I’m not going to add this support directly, but will look into starting to use the object converter service when it seems more or less ready. I have to investigate whether the nested object key encoding scheme implemented in DS can be added to a spec converter using an adapter. Meanwhile, can you use an array? thanks david jencks > On May 22, 2016, at 9:59 AM, David Jencks <david_jen...@yahoo.com.INVALID> > wrote: > > This extension has been used, I think, mostly by me, so the limitations are > the things I’ve not happened to run up against. At the moment the only kinds > of interfaces that DS supports are ones that look like annotations except for > inheritance. So you can only have primitive, String, Class, interface, and > arrays of the previous as return types. We’re treating the List return > type as an interface valued return type rather than something like long[] as > you expect. DS doesn’t have access to the metatype information. > > I’ll see if I can find time to support List, Set, Collection return types for > 2.0.4. I need to consult the draft object conversion spec to see what might > be reasonable. > > thanks > david jencks > >> On May 22, 2016, at 4:54 AM, Steven Walters <kemu...@gmail.com> wrote: >> >> On Sun, May 22, 2016 at 4:24 PM, David Jencks >> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> >> wrote: >>> It all does work, sorry I haven’t really documented it. I only use bndlib >>> from ant, but I use a slightly pre bnd 3.1 version so I’d guess it might >>> all work with recent maven-bundle-plugin. >>> >>> There are two things you can set: >>> >>> -dsannotations-options in the bnd.bnd file or equivalent: >>> >>> inherit has bnd analyze superclasses of your component looking for >>> additional annotations. >>> >>> felixExtensions allows lifecycle and event methods to return Map<String, >>> Object> to set the service properties, and allows configuration with >>> interfaces rather than annotations >>> >>> extender sets the namespace version to 1.3 so you always get the require >>> capability on the DS implementation. >>> >>> >>> Then you can use the DSExt annotations in the scr-ext-anno project (I think >>> you have to build this yourself at the moment) to have bnd add stuff to the >>> generated component xml descriptor >>> >>> @DSExt.ConfigurableServiceProperties tells DS to allow the lifecycle and >>> event methods to return a Map<String, Object> to set the service properties. >>> >>> @DSExt.PersistentFactoryComponent alters the lifecycle of factory >>> components (the components created from a >>> ComponentFactory.newInstance(props) invocation) to be the same as a normal >>> component instead of the somewhat useless lifecycle mandated by the spec. >>> >>> @DSExt.DeleteCallsModify adjusts the behavior of pre-ds-1.3 component to >>> match the 1.3 behavior for a component with a modified method when the >>> configuration is deleted and the component is still satisfied >>> (configuration optional or some other targeted pid available) >>> >>> @DSExt.ObsoleteFactoryComponentFactory Dont even think about using this. >>> Backwards compatibility only. >>> >>> @DSExt.ConfigureWithInterfaces allows lifecycle methods to accept >>> interfaces rather than annotations >>> >>> @DSExt.DelayedKeepInstances when applied to a delayed component, once the >>> component is created it isn’t automatically deactivated when all the uses >>> of it are returned. >>> >>> So, to configure with interfaces rather than annotations, you need to tell >>> bnd by using the >>> >>> -dsannotations-options: felix-extensions >>> >>> and tell felix DS by using the >>> @DSExt.ConfigureWithInterfaces >> >> So I got the XML generation to work successfully when using >> maven-bundle-plugin from current source, apparently 3.0.1 uses a >> version of bnd that doesn't recognize/handle the 'mapping' attribute >> correct, so the generated XML was incorrect when using 3.0.1 >> >> However, after this, on attempt of calling one of the LC methods >> utilizing the interface, an NPE gets thrown with the SCR 2.0.2's >> handling of t
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
This extension has been used, I think, mostly by me, so the limitations are the things I’ve not happened to run up against. At the moment the only kinds of interfaces that DS supports are ones that look like annotations except for inheritance. So you can only have primitive, String, Class, interface, and arrays of the previous as return types. We’re treating the List return type as an interface valued return type rather than something like long[] as you expect. DS doesn’t have access to the metatype information. I’ll see if I can find time to support List, Set, Collection return types for 2.0.4. I need to consult the draft object conversion spec to see what might be reasonable. thanks david jencks > On May 22, 2016, at 4:54 AM, Steven Walters <kemu...@gmail.com> wrote: > > On Sun, May 22, 2016 at 4:24 PM, David Jencks > <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> > wrote: >> It all does work, sorry I haven’t really documented it. I only use bndlib >> from ant, but I use a slightly pre bnd 3.1 version so I’d guess it might all >> work with recent maven-bundle-plugin. >> >> There are two things you can set: >> >> -dsannotations-options in the bnd.bnd file or equivalent: >> >> inherit has bnd analyze superclasses of your component looking for >> additional annotations. >> >> felixExtensions allows lifecycle and event methods to return Map<String, >> Object> to set the service properties, and allows configuration with >> interfaces rather than annotations >> >> extender sets the namespace version to 1.3 so you always get the require >> capability on the DS implementation. >> >> >> Then you can use the DSExt annotations in the scr-ext-anno project (I think >> you have to build this yourself at the moment) to have bnd add stuff to the >> generated component xml descriptor >> >> @DSExt.ConfigurableServiceProperties tells DS to allow the lifecycle and >> event methods to return a Map<String, Object> to set the service properties. >> >> @DSExt.PersistentFactoryComponent alters the lifecycle of factory components >> (the components created from a ComponentFactory.newInstance(props) >> invocation) to be the same as a normal component instead of the somewhat >> useless lifecycle mandated by the spec. >> >> @DSExt.DeleteCallsModify adjusts the behavior of pre-ds-1.3 component to >> match the 1.3 behavior for a component with a modified method when the >> configuration is deleted and the component is still satisfied (configuration >> optional or some other targeted pid available) >> >> @DSExt.ObsoleteFactoryComponentFactory Dont even think about using this. >> Backwards compatibility only. >> >> @DSExt.ConfigureWithInterfaces allows lifecycle methods to accept interfaces >> rather than annotations >> >> @DSExt.DelayedKeepInstances when applied to a delayed component, once the >> component is created it isn’t automatically deactivated when all the uses of >> it are returned. >> >> So, to configure with interfaces rather than annotations, you need to tell >> bnd by using the >> >> -dsannotations-options: felix-extensions >> >> and tell felix DS by using the >> @DSExt.ConfigureWithInterfaces > > So I got the XML generation to work successfully when using > maven-bundle-plugin from current source, apparently 3.0.1 uses a > version of bnd that doesn't recognize/handle the 'mapping' attribute > correct, so the generated XML was incorrect when using 3.0.1 > > However, after this, on attempt of calling one of the LC methods > utilizing the interface, an NPE gets thrown with the SCR 2.0.2's > handling of the configured properties. > My interface I'm attempting to utilize in the @Activate method has a > List return type. > This seems to eventually dive into the > org.apache.felix.scr.impl.helper.Annotations (trunk seems to have > moved this to org.apache.felix.scr.impl.inject.Annotations) where the > use of extractSubMaps ignores the existing Vector that is > defined for the attribute in the property map (it is a Vector due to > the negative cardinality that is generated due to the use of a > Collection on the type). > the functionality instead appears to use some pattern matching scheme > that assumes that the values of the attribute are independent numbered > attributes with the prefix of the attribute name, causing the > resulting returned map be empty. > > In the end, the functionality currently causes the proplist at > List<Map<String, Object>> proplist = nested.get(entry.getKey()); > be null
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
It all does work, sorry I haven’t really documented it. I only use bndlib from ant, but I use a slightly pre bnd 3.1 version so I’d guess it might all work with recent maven-bundle-plugin. There are two things you can set: -dsannotations-options in the bnd.bnd file or equivalent: inherit has bnd analyze superclasses of your component looking for additional annotations. felixExtensions allows lifecycle and event methods to return Map<String, Object> to set the service properties, and allows configuration with interfaces rather than annotations extender sets the namespace version to 1.3 so you always get the require capability on the DS implementation. Then you can use the DSExt annotations in the scr-ext-anno project (I think you have to build this yourself at the moment) to have bnd add stuff to the generated component xml descriptor @DSExt.ConfigurableServiceProperties tells DS to allow the lifecycle and event methods to return a Map<String, Object> to set the service properties. @DSExt.PersistentFactoryComponent alters the lifecycle of factory components (the components created from a ComponentFactory.newInstance(props) invocation) to be the same as a normal component instead of the somewhat useless lifecycle mandated by the spec. @DSExt.DeleteCallsModify adjusts the behavior of pre-ds-1.3 component to match the 1.3 behavior for a component with a modified method when the configuration is deleted and the component is still satisfied (configuration optional or some other targeted pid available) @DSExt.ObsoleteFactoryComponentFactory Dont even think about using this. Backwards compatibility only. @DSExt.ConfigureWithInterfaces allows lifecycle methods to accept interfaces rather than annotations @DSExt.DelayedKeepInstances when applied to a delayed component, once the component is created it isn’t automatically deactivated when all the uses of it are returned. So, to configure with interfaces rather than annotations, you need to tell bnd by using the -dsannotations-options: felix-extensions and tell felix DS by using the @DSExt.ConfigureWithInterfaces The reason the spec says to use annotations rather than interfaces is so that the annotation defaults can be put into the property map as the no-configuration values. Otherwise you’d need to either write them out by hand in the @Component annotation or use both metatype and config admin and specify then in the metatype defaultValue. Hope this helps david jencks > On May 21, 2016, at 9:51 PM, Steven Walters <kemu...@gmail.com> wrote: > > I've found that Felix appears to have an extension to the OSGi R6/DS > 1.3 specification regarding configuration of components. > > In that @Active, @Deactivate, and @Modified methods can by configured > by an interface in addition to an annotation. > per at least [0] & [1] > > However, bnd itself does not seem to be rather happy with this, and > when using maven-bundle-plugin 3.0.1, the build will fail due to this. > Though using bnd directly seems to be treating this more as a warning, > as it still writes the activate, deactivate, and modified attributes > as normal. > (That or the ability to still write the XML as expected may be an > artifact of using a newer bnd that what the maven-bundle-plugin > utilizes) > > Also, The felix extension point indicator is in the component > definition XML (which is normally generated by bnd when using the OSGi > R6 annotations). > Is there actually any expectation that bnd is able to support the > felix specific extension point here? > I'm currently seeing this as having to forego the annotations and > write the XML manually for at least these particular "violating" > components, which would be a decent cause for tedium and confusion > later. > > > This restriction to only allowing the use of annotation types in the > component lifecycle methods seems a bit contrary. > @ObjectClassDefinition explicitly states that it can specified on > interfaces (and handling interface hierarchy), but if interfaces can > not be used as part of the component lifecycle method signatures, then > this feels like the use of metatyping interfaces is rather > non-beneficial. > > This currently seems like a lack of friendliness in the specification, > which is why the Felix project created the enhancement point... > But I'm not actually all that familiar with the specification to be > confident in this viewpoint. > > Any clarity/feedback that could be provided on the matter here would > be greatly appreciated. > > Thanks, > Steven > > [0] - > http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java?revision=1744737=markup#l296 > [1] - > http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apach
Re: DS: invalid/alarmist circular reference log
Can you verify that your case is the same as Victor’s? All the circular references I encounter work fine, if there are 2 different broken cases that would be good to know when investigating Victor’s case. thanks david jencks > On May 12, 2016, at 2:58 AM, Ferry Huberts <maili...@hupie.com> wrote: > > > > On 12/05/16 11:55, Victor Antonovich wrote: >> 12.05.2016 12:42, Ferry Huberts wrote: >>> Hi, >>> >>> I'm seeing log lines like: >>> >>>> [some.component(17)] Circular reference detected, getService returning >>>> null >>> >>> >>> These are invalid for my application since one end of the relation is >>> mandatory and the other end is optional. >>> >>> DS should not complain in this way when at least one end of the relation >>> is optional. >>> >>> (I can't file an issue on this since JIRA seems to be in some kind of >>> lockdown) >> >> Fyi, this issue already has been filed a while ago: >> https://issues.apache.org/jira/browse/FELIX-4417 >> > > ok, tnx > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
Re: [SCR] Selecting services without giving a service interface
(sort of replying to 2 posts) I don’t think what you are trying to do is a
good fit for DS. It sounds to me much more like aspect-oriented programming.
Aries proxy does some byte code weaving that lets you dynamically add and
remove proxies. Using something like that seems to me to be a better fit than
trying to force DS to do something it’s not really designed for.
You might also consider turning the problem around and having each service that
might be proxied have a reference to the proxying service, this seems to me to
be a more appropriate way to do AOP using DS.
thanks
david jencks
> On Apr 9, 2016, at 3:30 AM, Jens Offenbach <wolle5...@gmx.de> wrote:
>
> I think the ExtraService annotation quite nice, but when I look at my use
> case, I am still in trouble. I am confronted with these two basic problems:
>
> 1. Service injection of "any" type filtered only by a filter expression in
> DS. This happens when the service interface is not known in advance or when
> there is no common interface.
> 2. Service provisioning in case when the objectclass attribute cannot be
> specified at design time. In my use case I am passing a type list (String
> based class names) to a proxy component. The components tries to load the
> classes using "DynamicPackage-Import" and registers a service proxy under
> these interfaces with some more attributes. I use "registerService" from the
> BundleContext because there is no way to have dynamic objectclasses for
> provided services in DS or do I miss someting?
>
> Have a nice weekend.
>
> Best regards,
> Jens
>
>
> Gesendet: Freitag, 08. April 2016 um 17:29 Uhr
> Von: "David Jencks" <david_jen...@yahoo.com.INVALID
> <mailto:david_jen...@yahoo.com.invalid>>
> An: users@felix.apache.org <mailto:users@felix.apache.org>
> Betreff: Re: [SCR] Selecting services without giving a service interface
> (going back to top-outing, sorry)
>
> From your example, I really don’t like this approach. One big reason for
> using string-matching rather than checking the java inheritance hierarchy
> when looking for services is so osgi can be lazy about loading classes. I
> think that all you actually are asking for is an easier way to get your
> FooProvider interface listed in the ObjectClass, which I can definitely
> sympathies with :-)
>
> So right now you can just explicitly list the classes your want to expose…
>
> @Component(service={FooProvider.class, FooProviderChild.class})
>
> I don’t see this as significantly more onerous that specifying a bunch of
> properties, and it’s certainly more typo-resistant since you have to get the
> class name right in order for it to compile.
>
> However, I’ve often wanted the ability to use custom annotations to modify
> the effect of the spec annotations. (we’re getting into bnd territory here).
> bnd provides a nice way to have custom annotations to add other-namespace
> attributes to the component.xml (see the scr-ext-anno project) I tried at one
> point to extend this so such a custom annotation could set stuff in the
> actual namespace, but there were too many concerns about interference between
> specifying something with the spec anno and the custom anno so I gave up.
> However this might be worth revisiting. It might look like
>
> @Component
> @ExtraService(FooProvider.class)
> public class FooProviderChildImpl implements FooProviderChild {…}
>
> david jencks
>
>> On Apr 8, 2016, at 8:07 AM, Simon Chemouil <schemo...@gmail.com> wrote:
>>
>> Le 08/04/2016 16:40, David Jencks a écrit :
>>> I don’t get it. My understanding of your last suggestion is that all the
>>> services you want to bind implement some interface, and that DS check type
>>> compatibility with this interface before accepting the service event (or
>>> discovery-by-query) before binding. How is this any different than putting
>>> that interface in the ObjectClass the service exposes, aside from
>>> duplicating functionality already managed by the service registry?
>>>
>>> Why can’t you do what you want today by including Object in the ObjectClass
>>> of all the services you want to bind, and declaring Object as the interface
>>> in all the references?
>>
>> Hi,
>>
>> You are right. I could do it that way, but I find it ugly at the
>> provider side.
>>
>> Sometimes, a component that I want to filter on, using a property, will
>> be implementing an orthogonal service and it's a shame to provide
>> Object.class because DS cannot consume it otherwise (I can do it with a
>> ServiceTracker). I don't think the pro
Re: [SCR] Selecting services without giving a service interface
(going back to top-outing, sorry)
From your example, I really don’t like this approach. One big reason for using
string-matching rather than checking the java inheritance hierarchy when
looking for services is so osgi can be lazy about loading classes. I think
that all you actually are asking for is an easier way to get your FooProvider
interface listed in the ObjectClass, which I can definitely sympathies with :-)
So right now you can just explicitly list the classes your want to expose…
@Component(service={FooProvider.class, FooProviderChild.class})
I don’t see this as significantly more onerous that specifying a bunch of
properties, and it’s certainly more typo-resistant since you have to get the
class name right in order for it to compile.
However, I’ve often wanted the ability to use custom annotations to modify the
effect of the spec annotations. (we’re getting into bnd territory here). bnd
provides a nice way to have custom annotations to add other-namespace
attributes to the component.xml (see the scr-ext-anno project) I tried at one
point to extend this so such a custom annotation could set stuff in the actual
namespace, but there were too many concerns about interference between
specifying something with the spec anno and the custom anno so I gave up.
However this might be worth revisiting. It might look like
@Component
@ExtraService(FooProvider.class)
public class FooProviderChildImpl implements FooProviderChild {…}
david jencks
> On Apr 8, 2016, at 8:07 AM, Simon Chemouil <schemo...@gmail.com> wrote:
>
> Le 08/04/2016 16:40, David Jencks a écrit :
>> I don’t get it. My understanding of your last suggestion is that all the
>> services you want to bind implement some interface, and that DS check type
>> compatibility with this interface before accepting the service event (or
>> discovery-by-query) before binding. How is this any different than putting
>> that interface in the ObjectClass the service exposes, aside from
>> duplicating functionality already managed by the service registry?
>>
>> Why can’t you do what you want today by including Object in the ObjectClass
>> of all the services you want to bind, and declaring Object as the interface
>> in all the references?
>
> Hi,
>
> You are right. I could do it that way, but I find it ugly at the
> provider side.
>
> Sometimes, a component that I want to filter on, using a property, will
> be implementing an orthogonal service and it's a shame to provide
> Object.class because DS cannot consume it otherwise (I can do it with a
> ServiceTracker). I don't think the provider should have to do that:
>
> @Component(property = "foo=true", service = { Object.class,
> FooProvider.class)
> public final MyFooProvider implements FooProvider {
>
> }
>
> ==
>
> What I'd like instead:
>
> @Component(property = "foo=true")
> public final MyFooProvider implements FooProvider {
>
> }
>
> and from the consumer's side:
>
> @Reference(ignoreInterface = true, target="(foo=true)")
> public void setFoo(Object myFoo) {
> // introspect runtime annotations on myFoo
> // e.g for event delivery by topic.
> }
>
>
> my proposal is *above* this line ^
>
> And below the convoluted case. I am not very sure it really makes so
> much sense, but here it goes:
>
> Let's say that in my code, any service providing a service property
> foo=true must implement interface FooProvider, but is not required to
> declare it through the objectClass service property (it might, or not,
> have interfaces extending FooProvider as objectClass).
>
> If DS looked only for target filters rather than the "interface" XML
> attribute, I could have:
>
> @Reference(ignoreInterface = true, target="(foo=*)")
> public void setFoo(Object myFoo) {
> // check type, if some bundle provider uses the same property
> // wrongly.
> if (myFoo instanceof FooProvider) {
> FooProvider fp = (FooProvider) myFoo;
> // actually do something
> }
> }
>
> Now, as far as the framework is concerned, my bundle is using even
> disregarded services that have the "foo" property but don't implement my
> FooProvider interface. DS cannot know from the ServiceReference whether
> the service object implements FooProvider (and to be specific, the
> bundle's view of FooProvider), so it has, only when "assignableType !=
> interface" to make that check for me, and if it fails unget() that
> service specific from that component.
>
> Obviously, it would be simpler if my service implemented FooProvider AS
> WELL as its sub-interfaces.
>
> @Component
Re: Multiple component instances in DS 1.3
I don’t think I understand your question….. configuration-policy and scope are independent or orthogonal. One way to see this is to note that configuration-policy applies whether or not the component exposes a service, whereas scope only applies when the component exposes a service. You never want to use configuration-policy OPTIONAL with a factory pid :-). So, starting with the assumption that you are using a factoryPid, each configuration will result in one “component”. Each configuration using the factoryPid will have a unique pid. Now: if the scope is - SINGLETON then every lookup of a component using the same pid will get the same object instance. - BUNDLE then every lookup of a component using the same pid from the same bundle will get the same object instance, but lookups from different bundles will get different instances, all configured the same (using the unique configuration with the pid) - PROTOTYPE then every lookup of a component using the same pid from the ServiceObjects interface will get a different instance, all configured using the unique configuration with the pid. If the client is a DS component, you can control wether the reference is looked up using the ServiceReference or ServiceObjects by specifying the ReferenceScope as BUNDLE or PROTOTYPE respectively. (or inject the ComponentServcieObjects) So, lets say you magically know the pids of all the configurations you’ve created with your factory pid, and they are pid_1, pid_2, etc. Typically you’d configure the client with a configuration including a target filter for the reference so it gets the one you want, e.g. MyReference.target=(service.pid=pid_42) If this client has prototype scope, and the reference has prototype scope, and the target service has prototype scope, then each instance of the client configured with this target filter will get a unique copy of the referred-to service. I don’t really understand your description of what you want. If you want even more copies of the referred-to-service, each configured differently on a “ ookup", maybe you are looking for a ComponentFactory? Then the client can supply the configuration for the referred-to service itself. However spec ComponentFactories have a peculiar and IMO useless lifecycle, so felix ds implements an extended lifecycle that better matches regular components. Hope this helps…. david jencks > On Apr 8, 2016, at 12:57 AM, Jens Offenbach <wolle5...@gmx.de> wrote: > > Hallo, > I am making intensive use of the DS pattern that allows us to couple a single > configuration to a single component instance using a Managed Service Factory > PID. Is it possible to combine this pattern e.g. with the prototype scope? Is > there a way to achieve that for every service lookup a new component instance > is created (prototype scope) and force at the same time that this component > requires an individual configuration? > > Does the "multiple component instances" pattern only require that someone > uses a Managed Service Factory PID in combination with > "ConfigurationPolicy.REQUIRE" instead of single a Managed Service PID? > > To make it more clear: > When I use this annotation fragment "configurationPolicy = > ConfigurationPolicy.REQUIRE" and use a Managed Service Factory PID, does this > ensure that a component instance must always have an individual configuration > or are there any interdependencies to other attributes, like "scope"? > > When I use "ServiceScope.PROTOTYPE" and "ConfigurationPolicy.REQUIRE", but > use a PID instead of a Managed Service Factory PID, does this mean, that we > have multiple component instances, all using the same configuration? > > Thanks a lot for your help! > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org >
Re: [SCR] Selecting services without giving a service interface
I don’t get it. My understanding of your last suggestion is that all the services you want to bind implement some interface, and that DS check type compatibility with this interface before accepting the service event (or discovery-by-query) before binding. How is this any different than putting that interface in the ObjectClass the service exposes, aside from duplicating functionality already managed by the service registry? Why can’t you do what you want today by including Object in the ObjectClass of all the services you want to bind, and declaring Object as the interface in all the references? thanks david jencks > On Apr 8, 2016, at 6:23 AM, Simon Chemouil <schemo...@gmail.com> wrote: > > Hi, > > For the record I have had the same need as Jens in the past. As Neil > suggested, I ended up using a ServiceTracker but this is a pity. > > BJ recently talked about a DS spec update. I have a few ideas > (in-component control of service registration for one, to support > asynchronous activations better!). > > To improve the situation Jens is describing, I would suggest making the > "interface" attribute of the "reference" element optional, in which case > only the "target" attribute would be taken into account for the filter. > > Now there are 2 options: either it would be up to the component > developer to make sure the method parameter type is compatible with the > service type (e.g use Object to be safe or another interface that he > considers "implied" by a specific set of service properties), or that > specific object type would become a new parameter (assignationType ?) > and DS would test for "assignability" before actually binding the > service if "attr(assignationType) != attr(interface)". The second design > is nice, and backwards compatible (by default, assignationType = interface). > > The @Reference annotation might (or not) get that capability through a > new parameter, false by default, such as "ignoreInterface". > > My use case: getting rid of ugly marker interfaces for services which a > "dynamic interface" (discovered through reflection on runtime > annotations). If needed I could show some pseudo-code to illustrate the > pattern. > > I understand the KISS camp is urging for an opinionated 80/20 approach, > but this is a very small update that would allow a bunch of new cool > stuff. :) > > Cheers, > Simon > > Le 08/04/2016 11:32, Neil Bartlett a écrit : >> Hi Jens, >> >> Can you clarify please… are you saying that you want to inject services of >> *any* type, using some kind of filter that looks at the other properties of >> the service reference? >> >> This is an unusual requirement, and I don’t think you can do it with DS’s >> event strategy. You should use a ServiceTracker instead. >> >> Regards, >> Neil >> >> >>> On 8 Apr 2016, at 10:23, Jens Offenbach <wolle5...@gmx.de> wrote: >>> >>> Sorry, but I am confronted with a new problem. >>> >>> I am declaring a Reference annotation on a method, but I cannot declare a >>> service interface. If I declare nothing than Object gets used and nothing >>> is happening. When I remove the interface definition from my XML >>> descriptor, SCR validation fails with "An interface must be declared for >>> the reference". I have a filter expression that selects my services, but >>> they do not have an interface in common. >>> >>> I have to select some service based on a filter expression without >>> indicating a service interface. How is this achievable? >>> >>> Again... Thanks a lot for your help! >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Updating org.apache.felix.scr from 1.8.2 to 2.0.2 breaks injection of service
Felix scr version >= 2 requires an R6 framework, which exports the dto package at version 1.0.0. There have been at least one request to provide a version that runs on R5 frameworks, but I haven’t had time to set that up. thanks david jencks > On Mar 23, 2016, at 2:51 PM, d...@beyene.org wrote: > > Hello, > > I have created an OSGi test project which uses maven and annotation-based > declarative services. > Updating org.apache.felix.scr from 1.8.2 to 2.0.2 breaks the integration test > with following error: > > org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.felix.scr [13]: Unable to resolve 13.0: missing requirement [13.0] > osgi.wiring.package; > (&(osgi.wiring.package=org.osgi.dto)(version>=1.0.0)(!(version>=2.0.0))) > > Deploying with "mvn:pax provision" still works. It seems that dependencies > have > changed, e.g. org.osgi.core (which contains org.osgi.dto) went from 5.0.0 to > 6.0.0, and that constraints are no longer satisfied. Unfortunately I don't > know > how I can use this information to make the integration test work again. > > Kind regards > Mikael Beyene > > Links: > Full build log : https://travis-ci.org/mbe24/mode/builds/114051484 > Source code: https://github.com/mbe24/mode/tree/update_scr_plugin > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: maven-scr-plugin and DS 1.3 annotations not working
I’m not certain how the maven-bundle-plugin is set up, but with bnd by itself
the default is dsannotatios and metatypeannotations are *, so I’d be surprised
if you have to specify them in the instructions here.
david jencks
> On Mar 22, 2016, at 12:18 AM, Jens Offenbach <wolle5...@gmx.de> wrote:
>
> @Carsten
> This is working... Thank you very much for your help!
>
> For all those who are on Eclipse PDE and require the OSGI-INF folder in the
> project root, use the maven-bundle-plugin with
> "true" and copy the folder to your project
> basedir like this:
>
> org.apache.maven.plugins
> maven-resources-plugin
>
>
> copy-scr-descriptor
> process-classes
>
> copy-resources
>
>
>
> ${basedir}/OSGI-INF
>
>
>
> ${project.build.outputDirectory}/OSGI-INF
> false
>
>
>
>
>
>
>
> Regards,
> Jens
>
>
> Gesendet: Dienstag, 22. März 2016 um 07:45 Uhr
> Von: "Carsten Ziegeler" <cziege...@apache.org>
> An: users@felix.apache.org
> Betreff: Re: maven-scr-plugin and DS 1.3 annotations not working
> The maven-scr-plugin does not support the DS 1.3 annotations.
> Using the maven-bundle-plugin 3.0.1 is all you need. I think you need to
> add this configuration to the bundle plugin:
>
>
>
> <_dsannotations>*
> <_metatypeannotations>*
>
>
>
> Carsten
>
>
> Jens Offenbach wrote
>> Hi,
>> I am using maven-scr-plugin:1.21.0,
>> org.osgi.service.component.annotations:1.3.0,
>> org.apache.felix.scr.ds-annotations:1.2.8 and
>> org.apache.felix.scr.annotations:1.9.12 and maven-bundle-plugin:3.0.1.
>>
>> This is my annotated class with makes use of the prototype scope:
>>
>> @Component(immediate = true, configurationPolicy =
>> ConfigurationPolicy.REQUIRE)
>> @Service(HttpContextMapping)
>> public class HttpContextMappingComponent implements HttpContextMapping {
>>
>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED, cardinality =
>> ReferenceCardinality.MANDATORY, bind = "bind", unbind = "unbind")
>> private HttpEndpointManager endpointManager;
>> ...
>>
>> }
>>
>> This is the component definition file created by maven-scr-plugin:
>>
>>
>> http://www.osgi.org/xmlns/scr/v1.1.0;
>> immediate="true"
>> name="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"
>> configuration-policy="require" activate="activate" deactivate="dispose">
>> > class="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"/>
>>
>> > interface="org.ops4j.pax.web.extender.whiteboard.HttpContextMapping"/>
>>
>>
>>
>> The prototype scope definition is missing and the plugin has classified the
>> component as DS 1.1.0 compliant.
>>
>> Furthermore the build failed with the following error message:
>> [INFO] --- maven-bundle-plugin:3.0.1:bundle (default-bundle) @
>> test.osgi.service.http.paxweb ---
>> [ERROR] Bundle test:test.osgi.service.http.paxweb:bundle:1.0.0-SNAPSHOT :
>> Service-Component entry can not be located in JAR:
>> OSGI-INF/test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent.xml~
>> [ERROR] Error(s) found in bundle configuration
>>
>> With maven-bundle-plugin:2.3.7 the build is working and the component
>> definition files get added to the jar.
>>
>> Has anybody an idea what's going on?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: SCR: Sometimes component gets instantiated twice
Can you check if this still happens with trunk? I recently fixed https://issues.apache.org/jira/browse/FELIX-5194 <https://issues.apache.org/jira/browse/FELIX-5194> which is a race condition on component startup between querying config admin and getting the initial configuration event. david jencks > On Mar 9, 2016, at 6:08 AM, Jens Offenbach <wolle5...@gmx.de> wrote: > > It has something to do with the TargetedPID. The modified or deactivate > method gets called when oldTargetedPID is null. Why is it sometimes null? Is > it possible that the component got instantiated and configured, but has a > TargetedPID of null? > > ConfigurationSupport.java (Line 338): > TargetedPID oldTargetedPID = componentHolder.getConfigurationTargetedPID(pid, > factoryPid); > if ( targetedPid.equals(oldTargetedPID)) > ... > } > > > Gesendet: Mittwoch, 09. März 2016 um 14:44 Uhr > Von: "Carsten Ziegeler" <cziege...@apache.org> > An: users@felix.apache.org > Betreff: Re: SCR: Sometimes component gets instantiated twice > Jens Offenbach wrote >> Now, I am confused... But I am using 'configuration-policy="require"'. This >> should force SCR to activate my component only when there is a valid >> configuration. >> > > Your configuration is changed, config admin fires a configuration > changed event, which in turn reactivates your component. It might be the > same configuration, but as someone updated the config, config admin > needs to send out the event. > > If you don't implement modified, your component is deactivated and then > activated. Otherwise modified is called. > > As you have require as the configuration policy, the only way to avoid > this is to make sure that the configuration is not updated in config admin. > > So this is not an SCR problem, everything behaves as expected. It looks > rather like a provisioning problem to me. > > In general, OSGi is dynamic, so your component should behave properly > and expect this "restarting" through a configuration change. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org >
Re: ComponentException: Field value type must not be set for unary field references.
multiple-dynamic-reluctant and multiple-dynamic-greedy have exactly the same behavior, you could specify either one, i.e. you can leave out the policyOption. Just to make things more complicated, if you are configuring your component with config admin and know exactly how many services will bind, and want them all before the component starts, you can use the .cardinality.minimum property to specify how many services to bind must be available before the component is satisfied and activates. thanks david jencks > On Jan 22, 2016, at 11:22 AM, b...@petinou.fr wrote: > > One last thing, the field has to be declared volatile. Otherwise, you get the > following error: > >> Field availableServices in component class org.test.FileReaderFactory must >> be declared volatile to handle a dynamic reference > > In the end, here is what I use: > > @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE, >policy = ReferencePolicy.DYNAMIC, >policyOption = ReferencePolicyOption.GREEDY) > private volatile List availableServices; > > It works, but I'm not sure what the conclusion was regarding the greedy > option. Is it required or not? From what I understood, > multiple-dynamic-reluctant would fail. > > Thanks to all for your answers > Ben > > Le 22.01.2016 20:01, Neil Bartlett a écrit : >>> On 22 Jan 2016, at 18:41, David Jencks <david_jen...@yahoo.com.INVALID> >>> wrote: >>> um, multiple and dynamic is greedy anyway, so you don’t need to specify it >>> explicitly. >> Not strictly 100% true… it’s more accurate to say that >> multiple-dynamic-reluctant and multiple-dynamic-greedy behave the same >> way, as shown in Table 112.1 in section 112.3.7 of the Compendium. >> Anyway, Raymond’s intuition seems to be correct. The binding is not >> randomly failing, it’s just that with the ‘reluctant’ policy option >> SCR gives you just one service and then doesn’t bother >> rebinding/reactivating the component in order to give you any more. >> This is all according to the specification. >> Neil >>> multiple and static requires specifying greedy explicitly to get the greedy >>> behavior. >>> Other than that, I think your explanation is correct. >>> david jencks >>>> On Jan 22, 2016, at 7:20 AM, Raymond Auge <raymond.a...@liferay.com> wrote: >>>> Perhaps you should enable this reference to be dynamic. In your current >>>> configuration it's static which means that resolution of services happens >>>> at the moment the component is instantiated and never beyond that, even if >>>> later services might satisfy it as well. >>>> You probably want something that is like a ServiceTracker (fully dynamic >>>> and greedy, sees all services and updates) >>>> @Reference( >>>> cardinality = ReferenceCardinality.MULTIPLE, >>>> policy = ReferencePolicy.DYNAMIC, >>>> policyOption = ReferencePolicyOption.GREEDY >>>> ) >>>> On Fri, Jan 22, 2016 at 5:16 AM, <b...@petinou.fr> wrote: >>>>> In fact, its worst than that. Both ReferenceCardinality.MULTIPLE and >>>>> ReferenceCardinality.AT_LEAST_ONE seem to be randomly failing. >>>>> There seems to be some kind of concurrent problem when both services start >>>>> at the same time: sometimes both are added to the service list, sometimes >>>>> only one. >>>>> I would thus think this is a bug, but I'm not quite sure... Any SCR >>>>> specialist around to help? >>>>> I tried replacing List with >>>>> CopyOnWriteArrayList but then the component is not started at >>>>> all. Anyway, I think it would be better IMHO for SCR to deal with >>>>> concurrency conflicts. >>>>> Thanks >>>>> Le 22.01.2016 10:50, b...@petinou.fr a écrit : >>>>>> Hi everyone, >>>>>> I'm back with my issue for an erratum: the solution I provided does >>>>>> not completely work. When I use: >>>>>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) >>>>>> private List availableServices; >>>>>> Only one of the file reader services is inserted in the list. Output >>>>>> of the code is: >>>>>> Reading: test.txt >>>>>> null >>>>>> Reading: test.properties >>>>>> [key6=value6, key5=value5, key4=value4] >>>>>> However, when using: >>>>>> @Reference(cardinality = Refere
Re: ComponentException: Field value type must not be set for unary field references.
um, multiple and dynamic is greedy anyway, so you don’t need to specify it explicitly. multiple and static requires specifying greedy explicitly to get the greedy behavior. Other than that, I think your explanation is correct. david jencks > On Jan 22, 2016, at 7:20 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > Perhaps you should enable this reference to be dynamic. In your current > configuration it's static which means that resolution of services happens > at the moment the component is instantiated and never beyond that, even if > later services might satisfy it as well. > > You probably want something that is like a ServiceTracker (fully dynamic > and greedy, sees all services and updates) > >@Reference( >cardinality = ReferenceCardinality.MULTIPLE, >policy = ReferencePolicy.DYNAMIC, >policyOption = ReferencePolicyOption.GREEDY >) > > > On Fri, Jan 22, 2016 at 5:16 AM, <b...@petinou.fr> wrote: > >> In fact, its worst than that. Both ReferenceCardinality.MULTIPLE and >> ReferenceCardinality.AT_LEAST_ONE seem to be randomly failing. >> >> There seems to be some kind of concurrent problem when both services start >> at the same time: sometimes both are added to the service list, sometimes >> only one. >> >> I would thus think this is a bug, but I'm not quite sure... Any SCR >> specialist around to help? >> >> I tried replacing List with >> CopyOnWriteArrayList but then the component is not started at >> all. Anyway, I think it would be better IMHO for SCR to deal with >> concurrency conflicts. >> >> Thanks >> >> Le 22.01.2016 10:50, b...@petinou.fr a écrit : >> >>> Hi everyone, >>> >>> I'm back with my issue for an erratum: the solution I provided does >>> not completely work. When I use: >>> >>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) >>> private List availableServices; >>> >>> Only one of the file reader services is inserted in the list. Output >>> of the code is: >>> Reading: test.txt >>> null >>> Reading: test.properties >>> [key6=value6, key5=value5, key4=value4] >>> >>> However, when using: >>> >>> @Reference(cardinality = ReferenceCardinality.MULTIPLE) >>> private List availableServices; >>> >>> The output is correct: >>> Reading: test.txt >>> [key1 value1, key2 value2, key3 value3] >>> Reading: test.properties >>> [key6=value6, key5=value5, key4=value4] >>> >>> Any idea why? Is this a bug or a feature? >>> >>> Kind regards, >>> Ben >>> >>> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: ComponentException: Field value type must not be set for unary field references.
Yes, this is a better place to ask :-)
I don’t see what’s wrong by just looking, I’m hoping to have enough time
shortly to try your code, unless someone else gets there first.
thanks
david jencks
> On Jan 12, 2016, at 11:02 PM, b...@petinou.fr wrote:
>
> Hi everyone,
>
> I have a ComponentException in Felix SCR that I don't understand.
>
> Here is my use case:
>
> 1) I have a file reader service that reads a file:
>
> public interface FileReaderService {
>/**
> * Reads the given file.
> * @param filePath Path of the file to read
> * @return the data object built from the file
> * @throws IOException if there is an error while reading the file
> */
>String readFile(Path filePath) throws IOException;
>
>/**
> * Detects if the format of the provided file is supported.
> * @param filePath the file to check
> * @return true if the format of the file is supported, false otherwise
> * @throws IOException if there is an error while reading the file
> */
>boolean isFormatSupported(Path filePath) throws IOException;
> }
>
> 2) I then have several implementations such as:
>
> @Component
> public class TxtFileReader implements FileReaderService {
>
>@Override
>public String readFile(Path filePath) throws IOException {
>// Do something smart with the file
>return "";
>}
>
>@Override
>public boolean isFormatSupported(Path filePath) throws IOException {
>PathMatcher matcher =
> FileSystems.getDefault().getPathMatcher("glob:*.txt");
>return matcher.matches(filePath);
>}
> }
>
> 3) I want a "factory" that would use the appropriate service depending on the
> file format:
>
> @Component
> public class FileReaderFactory implements ReaderFactoryService {
>
>@Reference
>private List availableServices;
>
>@Override
>public String readFile(Path filePath) throws IOException {
>
>for (FileReaderService reader : availableServices) {
>if (reader.isFormatSupported(filePath)) {
>return reader.readFile(filePath);
>}
>}
>
>return null;
>}
>
>@Override
>public boolean isFormatSupported(Path filePath) throws IOException {
>for (FileReaderService reader : availableServices) {
>if (reader.isFormatSupported(filePath)) {
>return true;
>}
>}
>return false;
>}
> }
>
> The source code can be found on GitHub: https://github.com/neopium/FileReader
>
> You can get it from here and build it. I configured it so that it generates a
> Karaf assembly with the required features. When you start karaf and type
> scr:list, you see the two readers with null status. The factory is not there
> at all.
>
> Here is the generated component xml file:
>
>
> http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.test.reader.service.factory.FileReaderFactory">
>
>
>
>
> interface="org.test.reader.service.FileReaderService"
> field="availableServices" field-collection-type="service"/>
>
>
> Here is the full stacktrace (can be found in
> Assembly/target/assembly/data/log/karaf.log):
>
> 2016-01-12 11:12:36,961 | ERROR | pool-8-thread-1 | file-reader-service-impl
> | 9 - file-reader-service-impl - 1.0.0.SNAPSHOT |
> [org.test.reader.service.factory.FileReaderFactory] Cannot register Component
> org.osgi.service.component.ComponentException: Component
> org.test.reader.service.factory.FileReaderFactory validation failed: Field
> value type must not be set for unary field references.
>at
> org.apache.felix.scr.impl.metadata.ComponentMetadata.validationFailure(ComponentMetadata.java:953)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.metadata.ReferenceMetadata.validate(ReferenceMetadata.java:710)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.metadata.ComponentMetadata.validate(ComponentMetadata.java:873)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:454)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:309)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:270)[24:org.apache.felix.scr:2.0.2]
>at
> org.apache.felix.scr.impl.Act
Re: scr:info missing info
Hi Ray, You are confusing a lot of terms :-) “enabled” is a component description state. If the component is disabled, whether there are CA configurations for it and required dependencies present or missing is completely irrelevant because DS isn’t even looking at that yet. Once the component is enabled, then there’s a chance that you might bet one or more instances of the component….. component configurations, not to be confused with CA configurations. Depending on the configuration policy…. ignored >> one component configuration. This will be satisfied if all the required references are satisfied and result in (one or more) instances depending on the scope, immediate setting, and whether there are any users of the exposed service (if any) optionsl >> one or more component configurations depending on CA configurations. Each one will be satisfied or not depending on it’s references, and again instances depend on scope, etc etc. You can see whether the one configuration is configured from CA by looking at the properties for a pid/factory pid. required >> 0 or more component configurations, one per CA configuration. Each one will be satisfied or not depending on its references etc etc. So, there are a lot of moving parts here. I’m not sure it’s practical to explain the entire DS model in the output of scr:info, which I think is what you’re aiming for. However I’m happy to consider suggestions that are actually in line with the model. I haven’t been able to figure out improvements to what is there that actually seem to me to provide more information without being very redundant and more confusing. Maybe you will have better luck. thanks david jencks > On Dec 3, 2015, at 8:19 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > Furthermore in looking at the > > scr:list | grep > > it produces > > [com.liferay.portal.http.tunnel.extender.HttpTunnelExtender] [ 60] [true] > > which seems to indicate that it's enabled... which it's not really. > > - Ray > > On Thu, Dec 3, 2015 at 11:10 AM, Raymond Auge <raymond.a...@liferay.com> > wrote: > >> The point is that if you start with no configuration, and you view the >> component scr:info it's hard for a less knowledgeable person to recognize >> that it's missing a configuration? >> >> I would hope to see something like this: >> >> >> g! scr:info com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >> Component Description: >> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >> Default State: enabled >> Activation: immediate >> Configuration Policy: require >> Activate Method: activate >> Deactivate Method: deactivate >> Modified Method: modified >> Configuration Pid: >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >> Services: Service Scope: null >> Properties: >> Component Configuration: >> State: missing >> g! >> >> >> make sense now? >> >> >> On Thu, Dec 3, 2015 at 11:03 AM, David Jencks <david.a.jen...@gmail.com> >> wrote: >> >>> It looks pretty blatant to me that the reason there are no component >>> configurations is that there is no CA configuration. What kind of >>> notification do you want? >>> >>> thanks >>> david jencks >>> >>>> On Dec 3, 2015, at 7:57 AM, Raymond Auge <raymond.a...@liferay.com> >>> wrote: >>>> >>>> Hey all, >>>> >>>> It seems that scr:info report is not clearly indicating when a required >>>> configuration is not available. It is showing good info when the >>> component >>>> has a configuration: >>>> >>>> Here is the report WITH required configuration: >>>> -- >>>> g! scr:info com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>> Component Description: >>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>> Default State: enabled >>>> Activation: immediate >>>> Configuration Policy: require >>>> Activate Method: activate >>>> Deactivate Method: deactivate >>>> Modified Method: modified >>>> Configuration Pid: >>>> >>> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>> Services: Service Scope
Re: scr:info missing info
well, to me it did state that quite plainly: >>>> Configuration Policy: require I look forward to your suggestions. thanks david jencks > On Dec 3, 2015, at 9:12 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > The point is that it took me and a technical support person about 15 > minutes to figure out (this is not a module I wrote) why the component > wasn't "activating". > > If scr:info had inferred that "hey, this thing won't do anything until it > receives at least ONE configuration" it would have really helped us, and I > would have had more encouraging response than ... I guess you need to infer > from the obscure messaging that it's in a "waiting" state. > > I'll see what I can come up with. > > - Ray > > On Thu, Dec 3, 2015 at 11:56 AM, David Jencks <david.a.jen...@gmail.com> > wrote: > >> Hi Ray, >> >> You are confusing a lot of terms :-) >> >> “enabled” is a component description state. If the component is disabled, >> whether there are CA configurations for it and required dependencies >> present or missing is completely irrelevant because DS isn’t even looking >> at that yet. >> >> Once the component is enabled, then there’s a chance that you might bet >> one or more instances of the component….. component configurations, not to >> be confused with CA configurations. >> >> Depending on the configuration policy…. >> ignored >> one component configuration. This will be satisfied if all the >> required references are satisfied and result in (one or more) instances >> depending on the scope, immediate setting, and whether there are any users >> of the exposed service (if any) >> >> optionsl >> one or more component configurations depending on CA >> configurations. Each one will be satisfied or not depending on it’s >> references, and again instances depend on scope, etc etc. You can see >> whether the one configuration is configured from CA by looking at the >> properties for a pid/factory pid. >> >> required >> 0 or more component configurations, one per CA configuration. >> Each one will be satisfied or not depending on its references etc etc. >> >> So, there are a lot of moving parts here. I’m not sure it’s practical to >> explain the entire DS model in the output of scr:info, which I think is >> what you’re aiming for. However I’m happy to consider suggestions that are >> actually in line with the model. I haven’t been able to figure out >> improvements to what is there that actually seem to me to provide more >> information without being very redundant and more confusing. Maybe you >> will have better luck. >> >> thanks >> david jencks >> >>> On Dec 3, 2015, at 8:19 AM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >>> >>> Furthermore in looking at the >>> >>> scr:list | grep >>> >>> it produces >>> >>> [com.liferay.portal.http.tunnel.extender.HttpTunnelExtender] [ 60] >> [true] >>> >>> which seems to indicate that it's enabled... which it's not really. >>> >>> - Ray >>> >>> On Thu, Dec 3, 2015 at 11:10 AM, Raymond Auge <raymond.a...@liferay.com> >>> wrote: >>> >>>> The point is that if you start with no configuration, and you view the >>>> component scr:info it's hard for a less knowledgeable person to >> recognize >>>> that it's missing a configuration? >>>> >>>> I would hope to see something like this: >>>> >>>> >>>> g! scr:info com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>> Component Description: >>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>> Default State: enabled >>>> Activation: immediate >>>> Configuration Policy: require >>>> Activate Method: activate >>>> Deactivate Method: deactivate >>>> Modified Method: modified >>>> Configuration Pid: >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>> Services: Service Scope: null >>>> Properties: >>>> Component Configuration: >>>> State: missing >>>> g! >>>> >>>> >>>> make sense now? >>>> >>&
Re: scr:info missing info
It looks pretty blatant to me that the reason there are no component configurations is that there is no CA configuration. What kind of notification do you want? thanks david jencks > On Dec 3, 2015, at 7:57 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > Hey all, > > It seems that scr:info report is not clearly indicating when a required > configuration is not available. It is showing good info when the component > has a configuration: > > Here is the report WITH required configuration: > -- > g! scr:info com.liferay.portal.http.tunnel.extender.HttpTunnelExtender > *** Bundle: com.liferay.portal.http.tunnel.extender (60) > Component Description: > Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender > Default State: enabled > Activation: immediate > Configuration Policy: require > Activate Method: activate > Deactivate Method: deactivate > Modified Method: modified > Configuration Pid: > [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] > Services: Service Scope: null > Properties: > Component Configuration: > ComponentId: 1936 > State: active > Properties: > component.id = 1936 > component.name = > com.liferay.portal.http.tunnel.extender.HttpTunnelExtender > hostsAllowed = [127.0.0.1] > service.pid = > com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration > g! > -- > > And here is the report when NO required configuration is available: > > -- > g! scr:info com.liferay.portal.http.tunnel.extender.HttpTunnelExtender > *** Bundle: com.liferay.portal.http.tunnel.extender (60) > Component Description: > Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender > Default State: enabled > Activation: immediate > Configuration Policy: require > Activate Method: activate > Deactivate Method: deactivate > Modified Method: modified > Configuration Pid: > [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] > Services: Service Scope: null > Properties: > g! > -- > > As you can see it's not clear at all that the component is missing the > configuration it requires. > > Can we fix this? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: scr:info missing info
Ray, see https://issues.apache.org/jira/browse/FELIX-5129 and rev 1717855 Neil, I do this in emacs using a file containing, basically, the output of scr:list and scr:info. Since there can be a lot of causes of a component configuration not being satisfied or existing at all, I’m not sure how to display a tree of problems sensibly (especially when you get to circular references and diamonds :-). The closest to a usable UI I’ve thought of is an html version of scr:info with links for unsatisfied references. What do you have in mind? I think the missing-configuration problem is now more or less solved by Ray’s request…. although it turns out you can’t tell whether the component description is enabled or disabled, so you can’t distinguish between missing configuration and disabled. thanks david jencks > On Dec 3, 2015, at 2:14 PM, Neil Bartlett <njbartl...@gmail.com> wrote: > > For what it’s worth, I’ve long had in the back of my mind an idea to develop > a DS diagnostic command that could try to work out for you exactly why a DS > component is inactive. > > For example it could look at the Configuration Policy and then the set of > available PIDs in Config Admin and report that the configuration seems to be > missing. > > Or it could notice unsatisfied service references, and follow those to some > other component that should provide the service but is inactive… and so on, > down the chain. Of course this would not work with services that are > published programmatically but it would still provide a lot of useful > information. > > It wouldn’t even be too hard to code this, given the existence of ScrService > for introspection. > > Neil > > >> On 3 Dec 2015, at 18:06, Raymond Auge <raymond.a...@liferay.com> wrote: >> >> On Thu, Dec 3, 2015 at 12:59 PM, David Jencks <david.a.jen...@gmail.com> >> wrote: >> >>> Since the Component Configuration: header appears for each component >>> configuration, I might prefer >>> … >>> (No Component Configuration) >>> >>> I think I’d leave this out when the component is disabled as an additional >>> clue about the state. >>> >>> WDYT? >>> >> >> I'd be totally cool with that! >> >> - Ray >> >> >>> >>> thanks >>> david jencks >>> >>>> On Dec 3, 2015, at 9:50 AM, Raymond Auge <raymond.a...@liferay.com> >>> wrote: >>>> >>>> On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <david.a.jen...@gmail.com >>> <mailto:david.a.jen...@gmail.com>> >>>> wrote: >>>> >>>>> well, to me it did state that quite plainly: >>>>> >>>>>>>>> Configuration Policy: require >>>>> >>>> >>>> >>>> but that's not showing that it's "waiting" for something... only that one >>>> is required... Does it have any right now? >>>> >>>> In your configuration list maybe all you need is: >>>> >>>> - >>>> ... >>>> Configuration Policy: require >>>> ... >>>> Component Configuration: none >>>> - >>>> >>>> That's not redundant. >>>> >>>> It's a) indicating that it does indeed need something before it does >>>> anything b) it doesn't have anything right now. >>>> >>>> I'd be totally satisfied with that. At least it would allow for a quick >>>> scan of the output to observe that it's just not configured!! >>>> >>>> >>>> >>>>> I look forward to your suggestions. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>>> On Dec 3, 2015, at 9:12 AM, Raymond Auge <raymond.a...@liferay.com> >>>>> wrote: >>>>>> >>>>>> The point is that it took me and a technical support person about 15 >>>>>> minutes to figure out (this is not a module I wrote) why the component >>>>>> wasn't "activating". >>>>>> >>>>>> If scr:info had inferred that "hey, this thing won't do anything until >>> it >>>>>> receives at least ONE configuration" it would have really helped us, >>> and >>>>> I >>>>>> would have had more encouraging response than ... I guess you need to >>>>> infer >>>>>> from the obscure messa
Re: scr:info missing info
Since the Component Configuration: header appears for each component configuration, I might prefer … (No Component Configuration) I think I’d leave this out when the component is disabled as an additional clue about the state. WDYT? thanks david jencks > On Dec 3, 2015, at 9:50 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <david.a.jen...@gmail.com > <mailto:david.a.jen...@gmail.com>> > wrote: > >> well, to me it did state that quite plainly: >> >>>>>> Configuration Policy: require >> > > > but that's not showing that it's "waiting" for something... only that one > is required... Does it have any right now? > > In your configuration list maybe all you need is: > > - > ... > Configuration Policy: require > ... > Component Configuration: none > - > > That's not redundant. > > It's a) indicating that it does indeed need something before it does > anything b) it doesn't have anything right now. > > I'd be totally satisfied with that. At least it would allow for a quick > scan of the output to observe that it's just not configured!! > > > >> I look forward to your suggestions. >> >> thanks >> david jencks >> >>> On Dec 3, 2015, at 9:12 AM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >>> >>> The point is that it took me and a technical support person about 15 >>> minutes to figure out (this is not a module I wrote) why the component >>> wasn't "activating". >>> >>> If scr:info had inferred that "hey, this thing won't do anything until it >>> receives at least ONE configuration" it would have really helped us, and >> I >>> would have had more encouraging response than ... I guess you need to >> infer >>> from the obscure messaging that it's in a "waiting" state. >>> >>> I'll see what I can come up with. >>> >>> - Ray >>> >>> On Thu, Dec 3, 2015 at 11:56 AM, David Jencks <david.a.jen...@gmail.com> >>> wrote: >>> >>>> Hi Ray, >>>> >>>> You are confusing a lot of terms :-) >>>> >>>> “enabled” is a component description state. If the component is >> disabled, >>>> whether there are CA configurations for it and required dependencies >>>> present or missing is completely irrelevant because DS isn’t even >> looking >>>> at that yet. >>>> >>>> Once the component is enabled, then there’s a chance that you might bet >>>> one or more instances of the component….. component configurations, not >> to >>>> be confused with CA configurations. >>>> >>>> Depending on the configuration policy…. >>>> ignored >> one component configuration. This will be satisfied if all >> the >>>> required references are satisfied and result in (one or more) instances >>>> depending on the scope, immediate setting, and whether there are any >> users >>>> of the exposed service (if any) >>>> >>>> optionsl >> one or more component configurations depending on CA >>>> configurations. Each one will be satisfied or not depending on it’s >>>> references, and again instances depend on scope, etc etc. You can see >>>> whether the one configuration is configured from CA by looking at the >>>> properties for a pid/factory pid. >>>> >>>> required >> 0 or more component configurations, one per CA >> configuration. >>>> Each one will be satisfied or not depending on its references etc etc. >>>> >>>> So, there are a lot of moving parts here. I’m not sure it’s practical >> to >>>> explain the entire DS model in the output of scr:info, which I think is >>>> what you’re aiming for. However I’m happy to consider suggestions that >> are >>>> actually in line with the model. I haven’t been able to figure out >>>> improvements to what is there that actually seem to me to provide more >>>> information without being very redundant and more confusing. Maybe you >>>> will have better luck. >>>> >>>> thanks >>>> david jencks >>>> >>>>> On Dec 3, 2015, at 8:19 AM, Raymond Auge <raymond.a...@liferay.com> >>>> wrote: >>>>> >>>>> Furthermore in looking at
Re: DRY for DS?
nonstandard == not in the DS 1.3 spec. These options are only supported by bnd, but I don’t really foresee anyone else writing a ds annotation processing tool. Do you? thanks david jencks > On Nov 17, 2015, at 2:47 PM, Benson Margulies <ben...@basistech.com> wrote: > > On Tue, Nov 17, 2015 at 2:43 PM, Robert Munteanu <romb...@apache.org> wrote: >> Hi Benson, >> >> On Tue, Nov 17, 2015 at 8:00 PM, Benson Margulies <ben...@basistech.com> >> wrote: >>> I'm feeling a bit sad; I have a family of 12 very similar services, >>> but I can't put the @Reference, @Activate, and @Deactivate into the >>> base class, I have to copy and paste it into each component class. >>> >>> Have I missed an alternative? >> >> The @Activate and @Deactivate annotations are optional if you stick to >> the standard 'activate' and 'deactivate' method names. > > I've also got some @References being repeated. > > As far as 'standard' goes, this is the standard that specs how bnd > turns .class files into XML? So my only concern would be that some > other tool might not do it? > > >> >> See 112.5.8 - Activate Method and 112.5.15 - Deactivate Method in the >> OSGi R6 Compendium specs for details. >> >> Robert >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DRY for DS?
sure you can -dsannotations-options=inherit not spec yet, but maybe we can eventually twist some arms :-) I really recommend only doing this if all the classes with annotations are in the same bundle. david jencks > On Nov 17, 2015, at 1:00 PM, Benson Margulies <ben...@basistech.com> wrote: > > I'm feeling a bit sad; I have a family of 12 very similar services, > but I can't put the @Reference, @Activate, and @Deactivate into the > base class, I have to copy and paste it into each component class. > > Have I missed an alternative? > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org >
Re: DRY for DS?
Actually…. now the @Component has a reference member and you can specify the @References there. You’ll have to do a lot of specifying, so I’d use the bnd-specific inherit support but if you are really worried about compatibility you can put everything in the @Component annotation. My theory is that (1) allowing this for classes where all the annotated superclasses are in the same bundle is completely safe (2) in any case it is just as safe as the service-component header method. So I’d be in favor of lobbying that the 1.4 ds spec allow at least case (1). david jencks > On Nov 17, 2015, at 4:24 PM, Benson Margulies <ben...@basistech.com> wrote: > > On Tue, Nov 17, 2015 at 3:32 PM, David Jencks <david.a.jen...@gmail.com > <mailto:david.a.jen...@gmail.com>> wrote: >> nonstandard == not in the DS 1.3 spec. >> >> These options are only supported by bnd, but I don’t really foresee anyone >> else writing a ds annotation processing tool. Do you? > > That was the point I was trying to make. > >> >> thanks >> david jencks >> >>> On Nov 17, 2015, at 2:47 PM, Benson Margulies <ben...@basistech.com> wrote: >>> >>> On Tue, Nov 17, 2015 at 2:43 PM, Robert Munteanu <romb...@apache.org> wrote: >>>> Hi Benson, >>>> >>>> On Tue, Nov 17, 2015 at 8:00 PM, Benson Margulies <ben...@basistech.com> >>>> wrote: >>>>> I'm feeling a bit sad; I have a family of 12 very similar services, >>>>> but I can't put the @Reference, @Activate, and @Deactivate into the >>>>> base class, I have to copy and paste it into each component class. >>>>> >>>>> Have I missed an alternative? >>>> >>>> The @Activate and @Deactivate annotations are optional if you stick to >>>> the standard 'activate' and 'deactivate' method names. >>> >>> I've also got some @References being repeated. >>> >>> As far as 'standard' goes, this is the standard that specs how bnd >>> turns .class files into XML? So my only concern would be that some >>> other tool might not do it? >>> >>> >>>> >>>> See 112.5.8 - Activate Method and 112.5.15 - Deactivate Method in the >>>> OSGi R6 Compendium specs for details. >>>> >>>> Robert >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
Re: Aries Subsystems using Repository
If you use bnd3 these Provide-Capability/Require-Capability headers should be generated for you from the DS info. david jencks > On Oct 10, 2015, at 8:55 AM, Paul F Fraser <pa...@a2zliving.com> wrote: > > On 10/10/2015 10:17 PM, John Ross wrote: >> I'm not sure if this is part of the issue, but note that there is no >> explicit support for DS in Aries Subsystems as there is for Blueprint. >> >> With Blueprint, service requirements and capabilities will be pulled >> directly from the Blueprint XML files. The same is not true for DS. >> When using DS, service requirements and capabilities must also be >> expressed via the Require-Capability and Provide-Capability bundle >> headers. >> > I think that's it.. > > I am using bundles direct from bndtools release. No manual addition of > Provide-Capability or Require-Capability. > > At least, I am not going mad, > > Thanks John & David, > > Paul - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: scr:details reports greedy as static with karaf 4.0.1
Well, that’s not too surprising because your reference is indeed static (the
default). Whatever is producing this report apparently doesn’t know about the
policy option so isn’t reporting it.
david jencks
> On Oct 1, 2015, at 7:54 PM, Benson Margulies <ben...@basistech.com> wrote:
>
> Code:
>
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
> ReferencePolicyOption.GREEDY)
> public void setWorkerComponentService(WorkerComponentService
> workerComponentService) {
>
> this.allComponents.put(workerComponentService.getComponentService().componentType().getType(),
> workerComponentService);
>LOG.info("Found component " +
> workerComponentService.getComponentService().componentType());
> }
>
>
> scr:details:
>
> References
> Reference : WorkerComponentService
>State : satisfied
>Multiple : multiple
>Optional : optional
>Policy: static
>Service Reference : Bound Service ID 147
> (com.basistech.ws.worker.rbl.BaseLinguisticsComponentServiceImpl)
>Service Reference : Bound Service ID 148
> (com.basistech.ws.worker.mockpnm.MockPairwiseNameMatchingService)
>Service Reference : Bound Service ID 154
> (com.basistech.ws.worker.mocknametranslation.impl.MockNameTranslationService)
>Service Reference : Bound Service ID 155
> (com.basistech.ws.sdk.mockrli.impl.MockRliComponentServiceImpl)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: How to 'let the dust settle' with DS?
If the reference is static greedy, then the component having the reference has to be deactivated/reactivated each time the set of available services changes. If the component exposes a service, and is not immediate, then each get/unget cycle will result in activating/deactivating the instance. You need to include a lot more information about exactly what your components look like and the circumstances around the behavior you report to assign a specific cause to it. thanks david jencks > On Sep 8, 2015, at 1:23 PM, Benson Margulies <ben...@basistech.com> wrote: > > JB says he'll have Karaf up to date next week. In the mean time, I've > onto the second chunk of blueprint that I wanted to fix. > > This time, all in one bundle, I have one multiple @Reference, and a > bundle of services that want to feed into it. > > I observe that an object is created, activate is called, and then > deactivate is called. > Then a new object is created, and the @Reference method gets called > before activate is called. > > Can you help me find the place in the spec that explains this lifecycle? > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: How to 'let the dust settle' with DS?
Hi Benson,
I don’t really understand what you are asking, but I’m going to guess.
I think you have say 5 B2 services and you want B3 to wait to activate until
all 5 B2’s are available?
There is a way to do this with DS 1.3, but you have to make B3
configuration-policy=REQUIRE.
So you have in B3:
@Component(configuration-policy=REQUIRE)
public class B3 {
@Reference(cardinality=MULTIPLE)
void setB2(B2 b2) {}
}
In your (required) configuration for B3 you put a property
B2.cardinality.minimum: 5
that is, .cardinality.minimum =
Don’t mess with start levels, they will be unreliable for this purpose.
There’s no guarantee that a bundle starting will start all the DS services it
provides. They might have all sorts of unsatisfied dependencies….. such as
missing configurations.
Let me know if this guess is a total miss :-)
thanks
david jencks
> On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com> wrote:
>
> I am hoping that David Jencks will continue his charity to strangers here.
>
> David, if you have any gogo jiras you'd like help with in return, just ask.
>
> Three bundles:
>
> B1 registers service S1.
>
> B2 consumes S1 and uses it in the implementation of S2. That is to
> say, it picks up a reference to S1 with a DS @Reference with
> cardinality MANDATORY.
>
> B3 consumes B2, but it anticipates that B2 will have siblings. So it
> consumes a reference to a List with cardinality AT_LEAST_ONE.
>
> It can take B2 and buddies a bit of time to activate.
>
> I appreciate that the most general case is intended to be that
> services come and go, and B3 should dynamically reconfigure itself.
> I'd rather not do that yet; I'd like to arrange things so that B3
> waits to finish starting itself until all the B2-ish guys are fully
> set up.
>
> Assuming that B2 and friends are all started at an earlier start
> level, is there an 'esthetic' way to arrange this? Or should I really
> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
> B2 service x=y, block until it's available?'
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: How to 'let the dust settle' with DS?
If cxf really does not have this capability, which I find hard to believe, I
would do the “publish to cxf” generically by having a component with a dynamic
reference (or a service tracker, but if your component is DS a dynamic
reference is easier) that uses service properties to figure out what to tell
cxf.
A pretty simple example of how to do this is in the aries imx jmx-whiteboard
project, which is more complicated than you would need since it has to deal
with multiple MBean servers whereas I think you would have only one cxf.
thanks
david jencks
> On Sep 7, 2015, at 12:46 PM, Benson Margulies <ben...@basistech.com> wrote:
>
> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>>
> wrote:
>> I think both of those suggestions are rather inappropriate to be used in a
>> DS component activate method, which generally should not block….. although
>> having it take a long time is also very much less than ideal.
>>
>> Certainly the second method seems to imply someone knows how many B2s there
>> are so the minimum cardinality can be set based on that knowledge, possibly
>> by whatever code has that knowledge. The (proprietary) metatype/config
>> admin I work with does this, it can count how many cm Configurations there
>> are for B2 and set properties based on that.
>>
>> If you make B3 expose a service and not be immediate, then it won’t be
>> activated until someone needs it and will pick up however many are then
>> available, even without the cardinality set.
>
> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
> which does not involve publishing an OSGi service. So I may need to
> stick with one of these less-than-ideal alternatives.
>
>
>>
>> david jencks
>>
>>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>>>
>>> Just to add a bit of detail…
>>>
>>> If you wait for 5 service instances before performing your initialisation,
>>> that’s great. But bear in mind that you might get a 6th and a 7th very soon
>>> afterwards, and depending on your implementation you may have to
>>> re-initialise each time that happens.
>>>
>>> If your (re)initialisation is expensive, you might want to avoid doing it
>>> too many times, especially if there is a rapid sequence of changes. This is
>>> typically the case during application startup for example. There are two
>>> general solutions to this:
>>>
>>> 1) You could start a timer each time the service set changes. If there are
>>> no further changes before the timer expires, then you do your
>>> reinitialisation. If there *are* changes then you cancel the existing timer
>>> and start a new one.
>>>
>>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter
>>> 130). Whoever is making changes to the set of installed bundles — e.g. the
>>> launcher, or some kind of management agent like FileInstall — should start
>>> a Coordination before it does anything, and end the coordination after that
>>> series of changes. Your component should be a Participant which detects
>>> whether there is a current coordination. If there is NO current
>>> coordination then it should immediately action any changes in the service
>>> set. However if there is a current coordination, then those changes should
>>> only be actioned when the coordination ends. This has the advantage that
>>> you don’t waste time waiting for an arbitrary-length timer to expire.
>>>
>>> Hope that helps. Regards,
>>> Neil
>>>
>>>
>>>
>>>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> That is precisely what I needed. Thanks.
>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
>>>> wrote:
>>>>
>>>>> Hi Benson,
>>>>>
>>>>> I don’t really understand what you are asking, but I’m going to guess.
>>>>>
>>>>> I think you have say 5 B2 services and you want B3 to wait to activate
>>>>> until all 5 B2’s are available?
>>>>>
>>>>> There is a way to do this with DS 1.3, but you have to make B3
>>>>> configuration-policy=REQUIRE.
>>>>>
>>>>> So you have in B3:
>>>>> @Component(configuration-policy=REQUIRE)
>>>>> public class B3 {
>>>&g
Re: How to 'let the dust settle' with DS?
I think both of those suggestions are rather inappropriate to be used in a DS
component activate method, which generally should not block….. although having
it take a long time is also very much less than ideal.
Certainly the second method seems to imply someone knows how many B2s there
are so the minimum cardinality can be set based on that knowledge, possibly by
whatever code has that knowledge. The (proprietary) metatype/config admin I
work with does this, it can count how many cm Configurations there are for B2
and set properties based on that.
If you make B3 expose a service and not be immediate, then it won’t be
activated until someone needs it and will pick up however many are then
available, even without the cardinality set.
david jencks
> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
> Just to add a bit of detail…
>
> If you wait for 5 service instances before performing your initialisation,
> that’s great. But bear in mind that you might get a 6th and a 7th very soon
> afterwards, and depending on your implementation you may have to
> re-initialise each time that happens.
>
> If your (re)initialisation is expensive, you might want to avoid doing it too
> many times, especially if there is a rapid sequence of changes. This is
> typically the case during application startup for example. There are two
> general solutions to this:
>
> 1) You could start a timer each time the service set changes. If there are no
> further changes before the timer expires, then you do your reinitialisation.
> If there *are* changes then you cancel the existing timer and start a new one.
>
> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130).
> Whoever is making changes to the set of installed bundles — e.g. the
> launcher, or some kind of management agent like FileInstall — should start a
> Coordination before it does anything, and end the coordination after that
> series of changes. Your component should be a Participant which detects
> whether there is a current coordination. If there is NO current coordination
> then it should immediately action any changes in the service set. However if
> there is a current coordination, then those changes should only be actioned
> when the coordination ends. This has the advantage that you don’t waste time
> waiting for an arbitrary-length timer to expire.
>
> Hope that helps. Regards,
> Neil
>
>
>
>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
>> wrote:
>>
>>> Hi Benson,
>>>
>>> I don’t really understand what you are asking, but I’m going to guess.
>>>
>>> I think you have say 5 B2 services and you want B3 to wait to activate
>>> until all 5 B2’s are available?
>>>
>>> There is a way to do this with DS 1.3, but you have to make B3
>>> configuration-policy=REQUIRE.
>>>
>>> So you have in B3:
>>> @Component(configuration-policy=REQUIRE)
>>> public class B3 {
>>>
>>> @Reference(cardinality=MULTIPLE)
>>> void setB2(B2 b2) {}
>>> }
>>> In your (required) configuration for B3 you put a property
>>>
>>> B2.cardinality.minimum: 5
>>>
>>> that is, .cardinality.minimum =
>>>
>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>> There’s no guarantee that a bundle starting will start all the DS services
>>> it provides. They might have all sorts of unsatisfied dependencies….. such
>>> as missing configurations.
>>>
>>> Let me know if this guess is a total miss :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>>
>>>> I am hoping that David Jencks will continue his charity to strangers
>>> here.
>>>>
>>>> David, if you have any gogo jiras you'd like help with in return, just
>>> ask.
>>>>
>>>> Three bundles:
>>>>
>>>> B1 registers service S1.
>>>>
>>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>>> say, it picks up a reference to S1 with a DS @Reference with
>>>> cardinality MANDATORY.
>>>>
>>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>>>
Re: How to 'let the dust settle' with DS?
> On Sep 7, 2015, at 5:06 PM, Benson Margulies <ben...@basistech.com
> <mailto:ben...@basistech.com>> wrote:
>
> On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>>
> wrote:
>> So it looks like we lost most of the thread but to try to keep this from
>> turning into more of a tangled ball of yarn the cat played with….
>
> I'm sorry to be so poor at communicating.
>>
>>
>> 1) NO!:
>>
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>> public void setAllComponents(List allComponents) {
>>
>>
>> This might be a blueprint-ism but DOESNT WORK FOR DS
>>
>> The event methods (bind/unbind/updated) don’t have to be called anything in
>> particular but they need to take only ONE service/service
>> reference/properties NOT a collection.
>
> Oh, so they get called more than once? Yea, apparently I caught a
> social disease from Blueprint!
>
>
>>
>> So
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>> public void setWorkerComponentService(WorkerComponentService wcs) { …}
>>
>> If you use DS 1.3 reference fields it can be a collection valued field.
>> I’ve never used these except possibly in some tests.
>>
>> 2) the minimum cardinality property has to be supplied from config admin,
>> not component.xml. So it is runtime modifiable. I might have missed it but
>> I didn’t see what your configuration was or how you were installing it. You
>> cannot set the minimum cardinality at compile time.
>
> OK, I get it. That does simplify things.
>
>>
>> I think you are making life too hard for yourself. From your description,
>> when you set up the deployment of your stuff, you know exactly how many
>> WorkerComponentService instances to expect, so you can put that value in the
>> configuration. Then DS will do the waiting for you, and your restful
>> service component will get the references and activate once the appropriate
>> number are ready. If you expect to have more WorkerComponentServices
>> registered, say 10, and want to restrict yourself to only using a particular
>> 5 of them, you can, along with the cardinality to assure you get at least 5,
>> use a target filter to find the exact 5 you want. For instance, if the
>> WorkerComponentServices have a “type” property that identifies which one
>> they are, your filter in the configuration would look something like
>>
>> WorkerComponentService.cardinality.minimum=5
>> WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”
>
> Do I really have to enumerate the types if I happen to have
> provisioned only the ones I want.
No, if you’re sure you know how many there will be you can just use the
cardinality property. I was showing the target filter approach in case you
wanted a specific subset of the available services, and you want to be sure to
get all the ones you want and exclude all the others.
thanks
david jencks
>
>>
>> Wiring up DS services is really powerful. I haven’t figured out the exact
>> computational strength available but to me it has the feel of logic
>> programming.
>>
>> thanks
>> david jencks
>>
>>
>>
>>> On Sep 7, 2015, at 2:55 PM, Benson Margulies <ben...@basistech.com
>>> <mailto:ben...@basistech.com>> wrote:
>>>
>>> I think I now understand what I have failed to explain here (and I
>>> probably know why my service is acting like tantalus).
>>>
>>> My plan is to create a series of docker containers. Call them
>>> 'workers'. Each worker publishes the same restful service; each one of
>>> them handles one or more 'tasks'. The worker accepts work via a single
>>> RESTful service, and dispatches the work to the tasks based on
>>> parameters in the requests to the service.
>>>
>>> The set of tasks implemented on a particular worker is controlled the
>>> set of OSGi bundles I provision in it. I have a whole slew of them,
>>> each registers a 'RosetteComponentService'.
>>>
>>> Each of these task bundles has, potentially, a bit of a startup delay
>>> as it gets organized.
>>>
>>> I don't want to open the restful service until the components are all set
>>> up.
>>>
>>> In spite of all the email I've sent up to this point, it dawns on me,
>>> a bit belatedly, that my own configuration file for a worker does list
>>> the compone
Re: How to 'let the dust settle' with DS?
> On Sep 7, 2015, at 8:07 PM, Benson Margulies <ben...@basistech.com> wrote:
>
> The cardinality in the config admin does not seem to be sticking:
>
> @Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
> configurationPid = "com.basistech.ws.worker")
>
> And:
>
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
> ReferencePolicyOption.GREEDY)
> public void setWorkerComponentService(WorkerComponentService
> workerComponentService) {
>
> And in the relevant Karaf cfg file (com.basistech.ws.worker.cfg):
>
> # This is a DS property. It tells DS that there is one component
> service that we are consuming.
> WorkerComponentService.cardinality.minimum=1
>
> And the reference name in the DS metadata is WorkerComponentService.
>
> but the component goes ahead and activates when it has none (due to
> leaving out the component); the activation throws an exception due to
> my own code complaining.
>
> In spite of the exception thrown in the @Activate method, the
> component goes to REGISTERED, is there some particular exception that
> would prevent that?
>
> I have it working (up to the point of fun with Json deserialization
> from CXF, which is also working mostly) by putting the component in
> place, but eventually I need the constraint to hold things up; and it
> would be nice to have a way for an exception in activation to stop the
> train.
The spec says:
• Once the component config- uration is deactivated or fails to
activate due to an exception, SCR must unbind all the component's bound
services and discard all references to the component instance associated with
the activation.
Note that this doesn’t disable the component or unregister any services it may
be exposing, because the exception may be highly transient, and e.g. the next
time someone gets the service all may work smoothly and activate succeed.
I don’t know what version of ds you are “stuck” with, at some point in the
distant past I think that an exception on activation did something like
disabling the component. Due to all the cool new 1.3 features you should use
the latest release 2.0 but the previous release may have also had the
cardinality.minimum support… but don’t quote me :-)
thanks
david jencks
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: How to 'let the dust settle' with DS?
So it looks like we lost most of the thread but to try to keep this from
turning into more of a tangled ball of yarn the cat played with….
1) NO!:
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List allComponents) {
This might be a blueprint-ism but DOESNT WORK FOR DS
The event methods (bind/unbind/updated) don’t have to be called anything in
particular but they need to take only ONE service/service reference/properties
NOT a collection.
So
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setWorkerComponentService(WorkerComponentService wcs) { …}
If you use DS 1.3 reference fields it can be a collection valued field. I’ve
never used these except possibly in some tests.
2) the minimum cardinality property has to be supplied from config admin, not
component.xml. So it is runtime modifiable. I might have missed it but I
didn’t see what your configuration was or how you were installing it. You
cannot set the minimum cardinality at compile time.
I think you are making life too hard for yourself. From your description, when
you set up the deployment of your stuff, you know exactly how many
WorkerComponentService instances to expect, so you can put that value in the
configuration. Then DS will do the waiting for you, and your restful service
component will get the references and activate once the appropriate number are
ready. If you expect to have more WorkerComponentServices registered, say 10,
and want to restrict yourself to only using a particular 5 of them, you can,
along with the cardinality to assure you get at least 5, use a target filter to
find the exact 5 you want. For instance, if the WorkerComponentServices have a
“type” property that identifies which one they are, your filter in the
configuration would look something like
WorkerComponentService.cardinality.minimum=5
WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”
Wiring up DS services is really powerful. I haven’t figured out the exact
computational strength available but to me it has the feel of logic programming.
thanks
david jencks
> On Sep 7, 2015, at 2:55 PM, Benson Margulies <ben...@basistech.com> wrote:
>
> I think I now understand what I have failed to explain here (and I
> probably know why my service is acting like tantalus).
>
> My plan is to create a series of docker containers. Call them
> 'workers'. Each worker publishes the same restful service; each one of
> them handles one or more 'tasks'. The worker accepts work via a single
> RESTful service, and dispatches the work to the tasks based on
> parameters in the requests to the service.
>
> The set of tasks implemented on a particular worker is controlled the
> set of OSGi bundles I provision in it. I have a whole slew of them,
> each registers a 'RosetteComponentService'.
>
> Each of these task bundles has, potentially, a bit of a startup delay
> as it gets organized.
>
> I don't want to open the restful service until the components are all set up.
>
> In spite of all the email I've sent up to this point, it dawns on me,
> a bit belatedly, that my own configuration file for a worker does list
> the components that it expects to find.
>
> So, I can set up a protocol where the restful service component waits
> for all the components to 'light up' and then lights itself up, since
> it knows what is supposed to be there. But not at compile time, so I
> can't use a cardinality property.
>
> One approach would be to @Reference the list, and then do a little
> sleep loop waiting until everyone arrives. I am going to go read on
> event admin to see if I can use that to sleep on an event that would
> indicate that a new example has shown up.
>
> Thanks for all your patience; I think this much will keep me out of
> your hair for a while.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Managing gogo command order
I got to one of the new JIRAs…. and found an easier way to pull the commits…. but I forgot the magic words to auto-close the pull request. If you say $git fetch https://github.com/bimargulies/felix FELIX-5008-less-messy-command-help From https://github.com/bimargulies/felix * branchFELIX-5008-less-messy-command-help - FETCH_HEAD FETCH_HEAD seems to be a sort of temporary branch that you can cherry pick from $git log FETCH_HEAD shows the remote commits $git cherry-pick 2cfe5515e0f40bcebc91dbacc3cf6196228968c8 gets your commit into my local branch. Anyway since I forgot the magic words in the commit again, could you close the pull request? thanks david jencks On Aug 22, 2015, at 12:38 PM, Benson Margulies ben...@basistech.com wrote: Oh, and I submitted two more JIRAs with PR's for gogo. On Sat, Aug 22, 2015 at 12:36 PM, Benson Margulies ben...@basistech.com wrote: I would add a remote in my repo to the repo of the person submitting the request, and then fetch from it, and then you can do it all in your repo and not keep making clones. On Sat, Aug 22, 2015 at 11:58 AM, David Jencks david_jen...@yahoo.com.invalid wrote: Thanks for the link. I thought there was probably a way to do this with cherry-picking. I always create a (local) branch for any changes, git svn dcommit from that branch, and then svn rebase on the trunk branch. Do you know if it’s possibly/easy (or how to) copy your changes on github to a branch in my github felix clone and then cherry-pick from there? I’d expect that would reduce a combinatorial explosion of remote branches as more people supplied patches on github. I didn’t see 4970 yet… thanks david jencks On Aug 22, 2015, at 7:36 AM, Benson Margulies ben...@basistech.com wrote: I'm sorry, I assumed that you all had a workflow for PR's already. I can offer you https://wiki.apache.org/lucene-java/BensonMargulies/GitSvnWorkflow. Also, please just ask and I'll be happy to make an 'svn patch' patch. Note the issue of getting the PRs to close by putting the right thing in the svn commit. There's also 4970, would you like me to make an svn patch for that? On Fri, Aug 21, 2015 at 7:16 PM, David Jencks david_jen...@yahoo.com.invalid wrote: I applied your fix from 4969 but it was rather difficult and I did it locally with a patch. Is there an explanation of how to pull stuff from github into an apache svn repo? Anyone else think we should consider git for felix? My plans for gogo are to make it find bundles using the system bundle, so the wiring info works even when regions/framework hooks are present. thanks david jencks On Aug 21, 2015, at 5:15 PM, Benson Margulies ben...@basistech.com wrote: Derek, Thanks, that did it. I've got an outstanding PR for some fixes in gogo, could I perhaps interest you in having a look? I'd proceed to make some other improvements if I had a process in motion to work with a committer to get things, well, committed. My next idea in line is to get the CommandSession out of the usage messages. On Fri, Aug 21, 2015 at 11:13 AM, Derek Baum de...@baums.org.uk wrote: set SCOPE = “myscope:gogo:*” then when you enter: mycmd, it will try: myscope:mycmd, gogo:mycmd, and then all other scopes in undefined order. The ‘type’ command can be used to find which command will be executed: % type -a mycmd mycmd is void myscope:mycmd(Object[]) mycmd is void otherscope:mycmd(String, Integer) — Derek On 21 Aug 2015, at 16:00, Benson Margulies ben...@basistech.com wrote: If two bundles both provide an 'exit' command, how do I configure to control which one is found by default? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Managing gogo command order
Thanks for the link. I thought there was probably a way to do this with cherry-picking. I always create a (local) branch for any changes, git svn dcommit from that branch, and then svn rebase on the trunk branch. Do you know if it’s possibly/easy (or how to) copy your changes on github to a branch in my github felix clone and then cherry-pick from there? I’d expect that would reduce a combinatorial explosion of remote branches as more people supplied patches on github. I didn’t see 4970 yet… thanks david jencks On Aug 22, 2015, at 7:36 AM, Benson Margulies ben...@basistech.com wrote: I'm sorry, I assumed that you all had a workflow for PR's already. I can offer you https://wiki.apache.org/lucene-java/BensonMargulies/GitSvnWorkflow. Also, please just ask and I'll be happy to make an 'svn patch' patch. Note the issue of getting the PRs to close by putting the right thing in the svn commit. There's also 4970, would you like me to make an svn patch for that? On Fri, Aug 21, 2015 at 7:16 PM, David Jencks david_jen...@yahoo.com.invalid wrote: I applied your fix from 4969 but it was rather difficult and I did it locally with a patch. Is there an explanation of how to pull stuff from github into an apache svn repo? Anyone else think we should consider git for felix? My plans for gogo are to make it find bundles using the system bundle, so the wiring info works even when regions/framework hooks are present. thanks david jencks On Aug 21, 2015, at 5:15 PM, Benson Margulies ben...@basistech.com wrote: Derek, Thanks, that did it. I've got an outstanding PR for some fixes in gogo, could I perhaps interest you in having a look? I'd proceed to make some other improvements if I had a process in motion to work with a committer to get things, well, committed. My next idea in line is to get the CommandSession out of the usage messages. On Fri, Aug 21, 2015 at 11:13 AM, Derek Baum de...@baums.org.uk wrote: set SCOPE = “myscope:gogo:*” then when you enter: mycmd, it will try: myscope:mycmd, gogo:mycmd, and then all other scopes in undefined order. The ‘type’ command can be used to find which command will be executed: % type -a mycmd mycmd is void myscope:mycmd(Object[]) mycmd is void otherscope:mycmd(String, Integer) — Derek On 21 Aug 2015, at 16:00, Benson Margulies ben...@basistech.com wrote: If two bundles both provide an 'exit' command, how do I configure to control which one is found by default? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Managing gogo command order
I applied your fix from 4969 but it was rather difficult and I did it locally with a patch. Is there an explanation of how to pull stuff from github into an apache svn repo? Anyone else think we should consider git for felix? My plans for gogo are to make it find bundles using the system bundle, so the wiring info works even when regions/framework hooks are present. thanks david jencks On Aug 21, 2015, at 5:15 PM, Benson Margulies ben...@basistech.com wrote: Derek, Thanks, that did it. I've got an outstanding PR for some fixes in gogo, could I perhaps interest you in having a look? I'd proceed to make some other improvements if I had a process in motion to work with a committer to get things, well, committed. My next idea in line is to get the CommandSession out of the usage messages. On Fri, Aug 21, 2015 at 11:13 AM, Derek Baum de...@baums.org.uk wrote: set SCOPE = “myscope:gogo:*” then when you enter: mycmd, it will try: myscope:mycmd, gogo:mycmd, and then all other scopes in undefined order. The ‘type’ command can be used to find which command will be executed: % type -a mycmd mycmd is void myscope:mycmd(Object[]) mycmd is void otherscope:mycmd(String, Integer) — Derek On 21 Aug 2015, at 16:00, Benson Margulies ben...@basistech.com wrote: If two bundles both provide an 'exit' command, how do I configure to control which one is found by default? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Enterprise business domain using DS - is it good idea?
yes. The R6 version of DS does too. (build it yourself from felix scr trunk at this point). My opinion on DS vs blueprint: The proxies are sort of irrelevant. With DS, with a mandatory dynamic reference, your component will be present when at least one instance of the required service is available and not present otherwise. If you change the target of the reference by starting the new service and then stopping the old one, then your component will just switch without any interruption. To me the biggest functional advantage of DS is the really good integration with config admin (even better in R6). This makes the configuration of your service instances orthogonal to their specification. While Aries blueprint does have config admin integration, it’s sort of bolted on and no one has figured out a plausible way to get it into the blueprint spec (possibly due to lack of interest). While when it started I thought blueprint was ideal, as I’ve learned more about OSGI I’ve come to regard blueprint as a transition crutch for those addicted to Spring. However, I have only used OSGI to develop app servers, I’ve never tried to write an enterprise app using OSGI, so there may be different considerations for your use. thanks david jencks On Jul 20, 2015, at 9:17 AM, Alex Sviridov ooo_satu...@mail.ru wrote: Hello, Christian. Thank you very much for detailed answers and great tutorial! I have one question - Does blueprint support scopes - I need new instance of service for every consumer? Понедельник, 20 июля 2015, 9:24 +02:00 от Christian Schneider ch...@die-schneider.net: Am 20.07.2015 um 07:33 schrieb Alex Sviridov: I have a few questions (I found some information but I'm afraid it is old): 2) Does blueprint support generating xml files via annotations like DS. If yes, then what maven plugin should we use There is a blueprint-maven-plugin from aries. It supports using JEE annotations for most of the functionality of blueprint. Basically the goal is to provide annotations for blueprint that are as compatible to JEE as possible so people who learned JEE feel at home. http://aries.apache.org/modules/blueprint-maven-plugin.html The example below shows a small application that uses just annotations. In practice you can also add hand written blueprint for things the plugin does not cover (like e.g. CXF integration). http://www.liquid-reality.de/display/liquid/2015/03/05/Apache+Karaf+Tutorial+Part+9+-+Annotation+based+blueprint+and+JPA The plugin works quite well and is already used in production at one of our customers. The scope of the plugin is limited a bit though. For example it already supports simple transaction and jpa injections but it is not yet compatible to Aries JPA 2. I will probably need to introduce some extension support for the plugin so people can extend it to support other blueprint namespaces. So I encourage you to try it out and see if it fits your current needs. As the code of the plugin is quite small you can also just fork it to adapt to your internal needs if something does not work like you want. In that case I would be happy about feedback or even pull requests so I can add such impovements to the aries version. 3) What is the influence of using proxies for every service on performance in comparison with DS? There is not much performance overhead for proxies. As your service calls should not be extremely fine grained anyway I do not think you will notice a problem. The problem with proxies is more in some other regards. For example blueprint blocks a service call if a mandatory service goes away. So if your business code needs to guarantee short response times this may speak against blueprint. Proxies also make debugging harder as you often hit the proxy impl code while stepping thorugh your code. 4) Could anyone provide a link to example of using blueprint of last version? You can have a look at my Karaf Tutorials. They cover many blueprint features as well as some of the integrations to other frameworks blueprint provides. Starting with my newest Tutorial I will also provide more examples of DS. My goal is to look into things like security, REST, SOAP. http://www.liquid-reality.de/display/liquid/Karaf+Tutorials Christian - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Alex Sviridov - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Is this mailing-list dead?
I looked at the stack overflow thread. I don’t understand what you are trying to do. CDI by itself (e.g. weld or openwebbeans) doesn’t have anything at all to do with OSGI and there’s no way to use them together as is. I don’t know much about pax-cdi but it may provide some integration. I don’t know if there are any other attempts to integrate. If you want to use such a solution you should ask it’s developers about it, not here where no one knows about them. The basic requirement you appear to have of “separate instance for each using instance” should be satisfied by R6 prototype scope. The DS 1.3 RI, felix DS, should support this OK but it’s not released, the CT is not done, and this feature is pretty much untested. I don’t have any idea how this capability might be accessed from a CDI bean, I’d imagine this would have to do with a hypothetical CDI-OSGI-R6 integration. DS component factories as specced are almost useless IMO and are certainly not the solution you want to try here. Why do you need to use CDI? If you are writing an OSGI based application I would look into simply using DS for all components. thanks david jencks On Jul 16, 2015, at 11:41 AM, Alex Sviridov ooo_satu...@mail.ru wrote: Neil, thank you for your answer. I asked a question about using getting new instance of DS for every consumer call to work with CDI at this mailing list and at stackoverflow http://stackoverflow.com/questions/31354996/osgi-ds-and-component-factories-issues http://stackoverflow.com/questions/31354996/osgi-ds-and-component-factories-issues You, Neil, helped me as you could, but you don't like CDI (as I understood). Is here anyone else besides you, who could help, as the question is very important for me and I can't continue work without getting certain answer. Четверг, 16 июля 2015, 16:35 +01:00 от Neil Bartlett njbartl...@gmail.com: No. On 16 Jul 2015, at 16:34, Alex Sviridov ooo_satu...@mail.ru wrote: I haven't got any messages from this mailing list. Is it dead? -- Alex Sviridov -- Alex Sviridov
Re: DS - component per service
It looks to me like your article leaves out an important detail, namely what is supposed to cause the service tracker extensions to get set up in the first place. I'd suggest that the ideal answer is…. a DS component. If your per-service objects need other constant service references (i.e. they get the same ref for each per-service instance) then these can be provided as DS references in this DS component. I agree that using ServiceTracker in this way is reasonable and simpler than only using DS. thanks david jencks On Apr 24, 2015, at 12:05 PM, Neil Bartlett njbartl...@gmail.com wrote: Service tracker really is better for this. See my (very old) blog post: http://njbartlett.name/2010/08/05/when-servicetrackers-trump-ds.html In your case I recommend returning the ServiceRegistration object from addingService(). Neil -- Neil Bartlett On Friday, 24 April 2015 at 16:53, Pawel Pogorzelski wrote: Guys, what's the standard approach for registering a DS component/OSGi service in response to a service appearing in the container? Is ServiceTracker the way to go? I'm using Declarative Services and would like stick to DS if possible. Explanation of what I'm trying to accomplish below. I'm using Felix with Gemini JPA which registers EntityManagerFactory as OSGi service per each persistence unit configuration. Since I need to open connections to multiple DBs with the same schema I end up having multiple EntityManagerFactories in the container. I'd like to map them to DAL classes one-by-one. So, assuming I have PersonReposity in DAL I'd like to have as many instances of it as EntityManagerFactories for the given schema. Is SCR able to do it? Cheers, Pawel - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DS property replacement?
I think you have prematurely decided on a solution and have not analyzed your
requirements from a sufficiently abstract level.
There are a ton of ways to specify wiring that don't augment the ds spec.
From a more conceptual level, what is determining which Fum a particular Foo is
wired to?
thanks
david jencks
On Mar 9, 2015, at 11:10 AM, Raymond Auge raymond.a...@liferay.com wrote:
In fact, I would be satisfied it there were placeholders ONLY for the
service properties which can only be known at runtime.
On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge raymond.a...@liferay.com
wrote:
Allow me to demonstrate using a real world scenario we have right now.
There is an API comprised of at least two parts - Foo Fum
There are many implementations of Foo and Fum coming from many bundles
However, the typical case is also that a Foo impl uses it's own Fum impl.
So, your first attempt looks like this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference
public void setFum(Fum fum) {..}
}
Now this can break, because there are many Fums, right?
So I need to be more specific. At the moment I have to do an ugly hack
which is export the Fum by also it's FumImpl type:
@Component(service = {Fum.class, MuFum.class})
public class MyFum implements Fum { }
and now in the Foo impl, I need to change to either:
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(service = MyFum.class)
public void setFum(Fum fum) {..}
}
OR
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (objectClass=MyFum))
public void setFum(Fum fum) {..}
}
all of that is really crappy!
Why do I need to expose the internal details just so I can connect two
Components together with such crud information.
Why can't I simply do this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (service.bundleid=${bundle.id}))
public void setFum(Fum fum) {..}
}
There! problem solved!
R6 added a few very nice service properties like service.bundleid but they
are completely useless because I CAN'T use them realistically because that
information is runtime only and you can't know about it ahead of time.
On Mon, Mar 9, 2015 at 10:51 AM, Raymond Auge raymond.a...@liferay.com
wrote:
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 09.03.15 um 15:08 schrieb Raymond Auge:
This also isn't the goal. The goal is to automate/simplify parts which
you
don't want to handle via configuration. For instance you would never
use
the bundle.id because that would be foolish since uninstall and
reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be
able to
apply filters on, but due to their dynamic nature its impractical to
use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since
this
causes a change management problem.
So, my thought about where the information for replacement is that it
would
come from only
- bundle runtime info
What exactly do you mean with that?
- manifest
How is this different from a properties file in the bundle?
It's most often calculated during the build and you can't really see the
result until the bundle is running.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e
Re: metatype extension
I haven't looked in detail at what you are proposing. The eclipse metatype impl supports pretty much arbitrary extra attributes in extension namespaces. I'd start by implementing something like that in the felix metatype impl. It won't help much with metatype providers unless they happen to generate felix or equinox specific goo. I don't think there's any plausible way around this yet. I'm pushing for an extension annotation processor plugin-plugin thingy for bnd https://github.com/bndtools/bnd/pull/838 that would let you write some felix specific annotations and get the info into the metatype xml. The proprietary metatype framework I work with uses the pid of the target configuration for foreign key references. thanks david jencks On Mar 3, 2015, at 2:29 PM, Raymond Auge raymond.a...@liferay.com wrote: Some searching lead to another request for something like this at least here: http://mail-archives.apache.org/mod_mbox/felix-dev/201301.mbox/%3C2B034BDA9437584AA6A714D3DFE23238CA6FC6@Eleos.SIDON.OLYMP%3E - Ray On Tue, Mar 3, 2015 at 10:36 AM, Raymond Auge raymond.a...@liferay.com wrote: On Tue, Mar 3, 2015 at 10:32 AM, Jan Willem Janssen janwillem.jans...@luminis.eu wrote: Hi Raymond, On 03 Mar 2015, at 16:24, Raymond Auge raymond.a...@liferay.com wrote: […] However, a metatype implementation change would be required but ONLY for access to said new hints information. This would require: 1) reading the extra schema info while parsing the metatype xml 2) providing API access to the information Implementing 1) is simple, just need to enhance the parser with the fields we decide 2) I was thinking of something like the following: […] IIRC, the MetaType spec already allows for optional attributes to be defined on ADs, Attributes, OCDs and Objects. I believe that this would already cover most of these requirements, not? Sure! However, the need to read the metatype again is painful when metatype is already reading it. Furthermore, this doesn't work for MetatypeProviders. - Ray -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is revolving around INAETICS and Amdatu Luminis Technologies B.V. Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -- *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect *Liferay, Inc.* http://www.liferay.com (@Liferay) Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance) -- *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect *Liferay, Inc.* http://www.liferay.com (@Liferay) Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi Declarative Services dependency on a generic supertype
One of the principles we've tried to keep to in DS is that all the information
about what to do is in the xml descriptor and we don't do significant runtime
analysis of capabilities and we definitely don't do runtime class scanning. So
it sounds like you are proposing a tectonic shift in the philosophy behind DS
which is unlikely to happen any time soon. Having dealt with annotation
processing for javaee I cannot express how strongly I am against runtime
annotation processing for DS.
thanks
david jencks
On Feb 5, 2015, at 3:41 PM, Milen Dyankov milendyan...@gmail.com wrote:
So as I mentioned earlier you have 2 options:
(a) build time - which is exactly how @Component annotations are processed.
Basically treat every class implementing the interface as if it was
annotated with @Component and @Service
(b) deploy / run time - which is more or less what you suggest although I
can imagine different implementations
So I fully agree with you that it can be done. But in the context set by
the original question:
- Is this possible with DS as of now - AFAIK no
- is it something that DS/SCR should support - I don't know. I think it
could, but again there may be implications I'm not aware of.
On Thu, Feb 5, 2015 at 9:29 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
I still don't understand in your example what is supposed to create an
instance of your button class.
I think it's pretty odd, but I think with my proposal for extension
annotation processors for DS and metatype annotation processing in bnd, if
you were willing to use DS and mark the button class you actually want to
be a real live button with @Component so DS knows enough to create one, you
could write an extension processor that would find your @AutoRegister
annotation on the interface in the inheritance hierarchy and add it to the
exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com wrote:
Agree to some extend. However here is what I meant with a stupid example.
Say I have GUI where I can dynamically add buttons to perform operations
on
something. If I could do
@AutoRegisterComponentsFromClassesImplementingMe
public interface Button {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make
it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a
matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
With DS and the spec annotations, if your component class directly
implements the interface, it will be registered as a service exposing
that
interface.
If your class is not a DS component, I'm not sure what you expect to
create an instance of your class in order to register it as a
service.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got
the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order
to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
wrote:
I may be interpreting Pawel's case wrong but I also have had situations
in
the past where I wish I was able to somehow mark a interface (by using
annotation for example) and basically say whoever implements that
interface should be automatically registered as a service! AFAIK that
is
not possible with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may
also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
The default for scr annotations is to expose all the directly
implemented
interfaces. If you want something else you can explicitly list the
classes
to expose in the @Component annotation.. This is really easy to
understand
from the class itself. You can re-list an interface implemented by a
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class
Re: OSGi Declarative Services dependency on a generic supertype
The default for scr annotations is to expose all the directly implemented interfaces. If you want something else you can explicitly list the classes to expose in the @Component annotation.. This is really easy to understand from the class itself. You can re-list an interface implemented by a superclass or that is a super-interface of a directly implemented interface if you want, that won't hurt your class. Your proposal of all bundle-exported interfaces seems really restrictive and odd to me, any directly implemented interface from another bundle (say from a spec) would force you to not use the default. To understand what the component exposes you would also have to try to figure out what the bundle exports, which is not obvious from the component class itself. thanks david jencks On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: Alright, thanks Neil. I can see can see some corner cases where this behavior could would be desired. It's just the default that bothers me - I think by default a service should be registered under all the bundle-exported interfaces. After all, if you want to hide implementation you do it differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: Services in OSGi are intended so that you can implement many interfaces but publish under a subset. Therefore the set of published services must be listed explicitly. Neil On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote: Thanks Ferry, it indeed works. Is there any way of doing it without specifying all the object supertypes during the registration? Maybe using Felix SCR annotations instead of OSGi ones? Cheers, Pawel On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts maili...@hupie.com wrote: On 05/02/15 16:59, Pawel Pogorzelski wrote: Guys, I have a generic interface IRepositoryT extended by IAppleRepository, IOrangeRepository and so on. Concrete implementations like AppleRepository are registered in the container with non-generic interfaces like IAppleRepository. Is it possible to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi Declarative Services dependency on a generic supertype
With DS and the spec annotations, if your component class directly implements the interface, it will be registered as a service exposing that interface. If your class is not a DS component, I'm not sure what you expect to create an instance of your class in order to register it as a service.. I guess you could register a byte-code weaver that looked for classes implementing your interface of interest, and added byte code that got the bundle context from the class loader, and registered the instance in the service registry, but I don't think you would actually find that very useful as there would be no way to specify service properties in order to distinguish different instances. It would certainly interfere with any existing component model such as DS or blueprint and probably with any attempt to register a service in code. david jencks On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote: I may be interpreting Pawel's case wrong but I also have had situations in the past where I wish I was able to somehow mark a interface (by using annotation for example) and basically say whoever implements that interface should be automatically registered as a service! AFAIK that is not possible with SCR/DS although it may be very convenient in some cases. Now if such feature was to be implemented the question is weather it should happen at run/deploy time (probably expensive) or build time (rather a matter of tooling and not strictly related to DS). However there may also be some side effects I have not thought about and perhaps a good reason not to have it. Just my 2 cents Best, Milen On Thu, Feb 5, 2015 at 8:15 PM, David Jencks david_jen...@yahoo.com.invalid wrote: The default for scr annotations is to expose all the directly implemented interfaces. If you want something else you can explicitly list the classes to expose in the @Component annotation.. This is really easy to understand from the class itself. You can re-list an interface implemented by a superclass or that is a super-interface of a directly implemented interface if you want, that won't hurt your class. Your proposal of all bundle-exported interfaces seems really restrictive and odd to me, any directly implemented interface from another bundle (say from a spec) would force you to not use the default. To understand what the component exposes you would also have to try to figure out what the bundle exports, which is not obvious from the component class itself. thanks david jencks On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski pawel.pogorzels...@gmail.com wrote: Alright, thanks Neil. I can see can see some corner cases where this behavior could would be desired. It's just the default that bothers me - I think by default a service should be registered under all the bundle-exported interfaces. After all, if you want to hide implementation you do it differently - by defining a public interface and hiding the rest in private packages. The same with lookups - if you want to get a specific instance then OSGi filters is the way to go. So, if you're relaying on not registering under all interfaces probably means there's something wrong in your design or the container you run in. Paweł On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com wrote: Services in OSGi are intended so that you can implement many interfaces but publish under a subset. Therefore the set of published services must be listed explicitly. Neil On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote: Thanks Ferry, it indeed works. Is there any way of doing it without specifying all the object supertypes during the registration? Maybe using Felix SCR annotations instead of OSGi ones? Cheers, Pawel On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts maili...@hupie.com wrote: On 05/02/15 16:59, Pawel Pogorzelski wrote: Guys, I have a generic interface IRepositoryT extended by IAppleRepository, IOrangeRepository and so on. Concrete implementations like AppleRepository are registered in the container with non-generic interfaces like IAppleRepository. Is it possible to tell DS engine I need every service sublassing IRepository? Corresponding line in my component.xml looks like follows: reference name=Repository cardinality=0..n policy=dynamic interface=com.Whatever.IRepository bind=addRepository unbind=removeRepository/ but it doesn't work. I'm on Felix 4.4.1. Then the bundles don't advertise the IRepository interface but their subclass(es). Make the bundles advertise IRepository and it'll work. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr
Re: OSGi Declarative Services dependency on a generic supertype
I still don't understand in your example what is supposed to create an instance
of your button class.
I think it's pretty odd, but I think with my proposal for extension annotation
processors for DS and metatype annotation processing in bnd, if you were
willing to use DS and mark the button class you actually want to be a real live
button with @Component so DS knows enough to create one, you could write an
extension processor that would find your @AutoRegister annotation on the
interface in the inheritance hierarchy and add it to the exposed services.
thanks
david jencks
On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com wrote:
Agree to some extend. However here is what I meant with a stupid example.
Say I have GUI where I can dynamically add buttons to perform operations on
something. If I could do
@AutoRegisterComponentsFromClassesImplementingMe
public interface Button {
void performActionOn (Something something);
}
public abstract class AbstractButton implements Button {
// some common logic here
}
then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a matter
of convenience!
On Thu, Feb 5, 2015 at 8:46 PM, David Jencks david_jen...@yahoo.com.invalid
wrote:
With DS and the spec annotations, if your component class directly
implements the interface, it will be registered as a service exposing that
interface.
If your class is not a DS component, I'm not sure what you expect to
create an instance of your class in order to register it as a service.. I
guess you could register a byte-code weaver that looked for classes
implementing your interface of interest, and added byte code that got the
bundle context from the class loader, and registered the instance in the
service registry, but I don't think you would actually find that very
useful as there would be no way to specify service properties in order to
distinguish different instances. It would certainly interfere with any
existing component model such as DS or blueprint and probably with any
attempt to register a service in code.
david jencks
On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote:
I may be interpreting Pawel's case wrong but I also have had situations
in
the past where I wish I was able to somehow mark a interface (by using
annotation for example) and basically say whoever implements that
interface should be automatically registered as a service! AFAIK that is
not possible with SCR/DS although it may be very convenient in some
cases.
Now if such feature was to be implemented the question is weather it
should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may also
be some side effects I have not thought about and perhaps a good reason
not
to have it.
Just my 2 cents
Best,
Milen
On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
david_jen...@yahoo.com.invalid
wrote:
The default for scr annotations is to expose all the directly
implemented
interfaces. If you want something else you can explicitly list the
classes
to expose in the @Component annotation.. This is really easy to
understand
from the class itself. You can re-list an interface implemented by a
superclass or that is a super-interface of a directly implemented
interface
if you want, that won't hurt your class. Your proposal of all
bundle-exported interfaces seems really restrictive and odd to me, any
directly implemented interface from another bundle (say from a spec)
would
force you to not use the default. To understand what the component
exposes
you would also have to try to figure out what the bundle exports, which
is
not obvious from the component class itself.
thanks
david jencks
On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski
pawel.pogorzels...@gmail.com wrote:
Alright, thanks Neil. I can see can see some corner cases where this
behavior could would be desired. It's just the default that bothers me
-
I
think by default a service should be registered under all the
bundle-exported interfaces. After all, if you want to hide
implementation
you do it differently - by defining a public interface and hiding the
rest
in private packages. The same with lookups - if you want to get a
specific
instance then OSGi filters is the way to go. So, if you're relaying on
not
registering under all interfaces probably means there's something wrong
in
your design or the container you run in.
Paweł
On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com
wrote:
Services in OSGi are intended so that you can implement many
interfaces
but publish under a subset. Therefore the set of published
Re: Loading a class from a different bundle dynamically
I don't understand what you are trying to do yet, but you might investigate
putting your test classes in a fragment bundle (only loaded when testing, but
then part of your main bundle) and also mocking the external input so it is
under better control (although calling the result a functional test would be a
stretch).
david jencks
On Dec 12, 2014, at 9:31 AM, Achim Nierbeck bcanh...@googlemail.com wrote:
Dynamic Import?
Add a manifest header or dynamically importing your testclass in case it's
available,
but I would actually work with a service tracker that waits for the
testservice to be available and trigger the test then.
regards, Achim
2014-12-12 15:24 GMT+01:00 Dean Schulze dean.w.schu...@gmail.com:
I don't think Pax Exam addresses my issue.
A little more explanation may help.
This system is driven by both external input and user input. The
external input will be the same on each test run. Controlling the
timing of the user input -- synchronizing it with the external input --
is the problem. The typical unit test case is only driven by user input
so timing doesn't matter.
Think of triggering a calculation where your inputs change constantly.
The calculation is different each time and in order to verify it I have
to trigger the calculation at exactly the same times on each test run.
My test classes have to monitor the internal state of my application to
synchronize with the external input in order to make them repeatable.
Without that synchronization automated testing will be impossible.
I don't want to put the test classes into the production bundles which
is why I'm trying to load them dynamically when the system is under
test.
On Fri, 2014-12-12 at 08:38 +0100, Achim Nierbeck wrote:
Hi,
just one quick question/hint.
You are aware of the Pax Exam Testframework?
I think with it you are able to do what you are looking for.
regards, Achim
2014-12-12 6:41 GMT+01:00 Dean Schulze dean.w.schu...@gmail.com:
I have an OSGI app consisting of several bundles. In order to do
functional testing I want to dynamically load test case classes when
the
-Dtest.class.name=MyTestClass property is set. I want to keep the
test
classes in their own bundle to make it easy to exclude them from the
production binary. The only test artifact that will be in the
production code bundles will be an interface that the test classes
implement.
The test bundle depends on the production bundles to access the test
interface and because the test classes also use other classes in the
production bundles. The test classes themselves are POJOs. They are
not Serice or Component classes. I only want to load them when the
test.class.name property is set so I don't want Felix injecting them.
I try to load the test class
public class MyTestClass implements MyTestClassI {
}
from the production bundle code like this
MyTestClassI myTestClass;
// Inside the @Activate method
String testClassName = System.getProperty(test.class.name);
if (testClassName != null) {
Class c = Class.forName(testClassName);
myTestClass = c.newInstance();
}
This gives a ClassNotFoundException.
The recommended solution that I've seen to this problem is to use the
Bundle.loadClass() method, but I haven't seen any example code that
actually does this. I would have to get the test Bundle first and I
haven't been able to find out how to do this.
If anyone knows of example code to do dynamic class loading in Felix I
would appreciate a link to it. If this kind of dynamic loading can
only
be done form the gogo shell I could live with that since this would
only
be done by the development and test teams.
Thanks.
Dean
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Apache Member
Apache Karaf http://karaf.apache.org/ Committer PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer
Project Lead
blog http://notizblog.nierbeck.de/
Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS
Software Architect / Project Manager / Scrum Master
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: memory mapping, bundle resources
If there was (I don't think there is), since the bundle is normally a zip file, it would expect that would mean that the framework was copying the zip entry into a file, so I don't see how you would be gaining anything time-wise, perhaps just a tiny bit less code? david jencks On Dec 12, 2014, at 9:14 AM, Benson Margulies ben...@basistech.com wrote: I've got code that makes extensive of memory mapping. I'm wishing that I could make a bundle that contained a large data resource that could be memory mapped. One path I see involves a copying process: expect to get a URL to it by getEntry() on a bundle, and then copy it into a file path from getDataFile(); once copied, it would persist. My question: is there any way to avoid the copy? Is there anything in the manifest that would cause the framework to plop the data someplace reachable with a File? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
