Switch Pax Web extender war to DS [PAXWEB-786]

[ops4j-issues]

Achim Nierbeck created PAXWEB-786

---

Votes: 0, Watches: 2

[ops4j-issues]

Achim Nierbeck commented

doesn't look like the DS supports Bundle Tracker ....

[ops4j-issues]

Christoph Läubrich commented

You can make use of DS the following way:

1. Create a Component with an activate and deactivate method with parameter BundleContext
2. create/start/stop BundleTracker there

That way you don't need an activator and it can be activated/deactivated like every other DS component as well as havin Refernces to other services.

[ops4j-issues]

Achim Nierbeck commented

well, how is a component without interface and activate/deactivate differently then an activator class?
I don't see much benefit of switching to that, cause it just behaves like an activator.
If it walks like a duck, quacks like a duck, it might just be a duck :wink:

[ops4j-issues]

Christoph Läubrich commented

Just consider the following:

1. If the Task is "Switch to DS for Pax Web" is just consistent to transform all components to DS
2. The Activator at least tracks one service and register one service so it is perfectly suited to be replaced by DS components logic

From looking at the code it seems that you can drop the Activator at all and transform WebObserver into a DS Component, you might want to use AbstractExtender still as an inner class for doing the tracking job.

Beside this even though you hava a pice of code that wants to interact with the OSGi-Framework you have the following benefits using DS:

• Your code is visible to DS management functions
• It can be started/stopped/disabled independetly from the bundle life cycle
• It can declare its requirements to configuration (require, ignore or optional use it) and recive one easily, it can even be controlled/instatiated multiple times by configuration without any hassle
• It can declare dependencies on services and those can even be configured without the need for code changes
• If required in rare cases (like this) it can interact with the OSGi Framework like an Activator
• In most cases it is easier to test since it does not depend on the low-level Service(tracker)-API
• There can be can be multiple such componets in one bundle which can be indivdually be managed

[ops4j-issues]

Achim Nierbeck commented

you're mostly right, still I don't see the point of removing a perfectly working Activator to another thing that is doing the same. At this point it doesn't make any sense as it doesn't give a benefit at all.
Might also be interested in the views of a DS-Evangelist ... (http://njbartlett.name/2010/08/05/when-servicetrackers-trump-ds.html)

[ops4j-issues]

Christoph Läubrich commented

I just wanted to show a kind of alternative to "dosen't work / is not supported" :wink:

IMO its perfectly fine to keep this open and migrate step-by step (e.g. next time when refactoring takes place).

About your link, there is no "direct-declarative-only" way but still one without ServiceTracker.

• For case A you can do for example:

  • declare bind method for the service you want to shaddow, add it to a Map<Service2Shaddow, ServiceRegistration>
  • declare a Component with an @Activate method that takes BundleContext as only parameter, register all "shaddow-services" like done in the example, rember the ServiceReference in the Map
  • in @Deactivate unregister all ShaddowServices
  • This resembles the Componet he declared, but this does not reflect the example below, IMO he meant to use dynamic references, the default is static that means service reference won't change one the component is activated! For the dynamic case it works similar, you just have to add some check if component is already startet but that is not much more complicated.

• For Case B it is not completely clear what should be archived, e.g. I can't belive that C does not care at all WHAT combination of services A+B it want to bind to, but since DS is like OSGi API single-threaded from the point of a component at least threading should not be an issue there.

  • If for example A has a property that must match one of B's you can make C a ComponentFactory, let a Component X Track that Factory+A, build a filterstring for the references and activate a component for this.
  • As an alternative it is in most times easier to do it by configuration.

If you can provide an example of the problem I'll try to outline it a little bit more, that often shows it better than some very abstract and vague A/B/C-FooBars :grinning:

[ops4j-issues]

Achim Nierbeck commented

Not worth the hazzle