On 9/7/2015 10:17 AM, Benson Margulies wrote:
On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
<[email protected]> wrote:
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.
I am studying the relevant CXF code now, but I think that the thing
you are looking for (register a service and CXF publishes it) will
exist only if I make it exist.
I haven't followed this whole thread, but it appears like this use case
(of wanting the registration of an OSGi service to result in an export
as a REST service) is a good fit for the OSGi R6 Remote Services/RSA
specifications. Coincidently, I've recently created a tutorial about a
new provider that uses the OSGi Remote Services and Jax-RS
specifications together in this manner [1].
FWIW, I thought that CXF supported some version of the OSGi Remote
Services/RSA specifications as well as being a Jax-RS impl, but I don't
know enough about it to comment further.
Scott
[1]
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
>I have made a first pass at coding what you wrote here, but it doesn't
work yet. What a surprise. More spelunking to do.
thanks
david jencks
On Sep 7, 2015, at 12:46 PM, Benson Margulies <[email protected]> wrote:
On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
<[email protected] <mailto:[email protected]>> 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 <[email protected]> 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 <[email protected]> wrote:
That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" <[email protected]>
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, <reference-name>.cardinality.minimum = <number of required B2’s>
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 <[email protected]>
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<S2> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
