DS adds a component.name property to each component's properties. You
control the component name. So you can find a service with the
component.name you control.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <raymond.a...@liferay.com>
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Date: 2015/03/08 12:48
Subject: Re: [osgi-dev] getting a service filtered on my bundleId
Sent by: osgi-dev-boun...@mail.osgi.org
I come up with:
@Activate
protected void activate(BundleContext bundleContext) {
Bundle bundle = bundleContext.getBundle();
_bundleId = bundle.getBundleId();
}
@Reference(
cardinality = ReferenceCardinality.AT_LEAST_ONE,
policy = ReferencePolicy.DYNAMIC,
policyOption = ReferencePolicyOption.GREEDY
)
protected void setServletContext(
ServletContext servletContext, Map<String, Object> properties) {
long serviceBundleId = MapUtil.getLong(properties,
"service.bundleid");
if (serviceBundleId == _bundleId) {
_servletContext = servletContext;
}
}
private long _bundleId;
private volatile ServletContext _servletContext;
Man that's ugly!
I think I prefer:
@Activate
protected void activate(BundleContext bundleContext)
throws InvalidSyntaxException {
Bundle bundle = bundleContext.getBundle();
Filter filter = bundleContext.createFilter(
"(&(objectClass=" + ServletContext.class.getName() +
")(service.bundleid=" + bundle.getBundleId() + "))");
_serviceTracker = new ServiceTracker<ServletContext,
ServletContext>(
bundleContext, filter, null);
_serviceTracker.open();
}
@Deactivate
protected void deactivate() {
_serviceTracker.close();
}
private ServiceTracker<ServletContext, ServletContext>
_serviceTracker;
But I really wish I could do:
@Reference(target = "(service.bundleid=${bundle.id})")
protected void setServletContext(ServletContext servletContext) {
_servletContext = servletContext;
}
private volatile ServletContext _servletContext;
On Sun, Mar 8, 2015 at 12:17 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:
.. pray there isn't multi version, or mutli-instance support for this type
of extender.
On Sun, Mar 8, 2015 at 12:08 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:
Tim and Neil,
Are you both suggesting that it's better to do the following?
The manifest file contains:
Web-ContextPath: /blah
The component contains:
@Reference(target = "(osgi.web.contextpath=/blah)")
protected void setServletContext(ServletContext servletContext) { ... }
On Sun, Mar 8, 2015 at 12:02 PM, Raymond Auge <raymond.a...@liferay.com>
wrote:
On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <njbartl...@gmail.com>
wrote:
Ray, to quote two sentences from your email:
* "I want the thing that was built for me specifically”
* "I never talked about coupling providers to consumers.”
These two statements are in direct contradiction with each other!
If there is coupling, it's coupling I specifically want, and it lives
inside my bundle! So what's the issue?
To be honest this doesn’t sound like a job for the service registry, but
instead Java’s “new” keyword…
You've missed the point! It's someone else who already created the thing I
need! However, it still belongs to me!
Please see my examples.
Neil
On 8 Mar 2015, at 15:38, Raymond Auge <raymond.a...@liferay.com> wrote:
On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <tim.w...@paremus.com> wrote:
Hi Ray,
Using the bundle id feels more like a workaround for a missing feature of
the extender.
Wouldn't it make more sense for the metadata processed by the extender
publish a property to filter on, and/or to have the service published by
the extender respond to config admin in the same way that DS components
do?
If, for example, the extendee asked for the property
"mySuperCoolProperty=awesome" to be applied to the extender registered
service then that could be used in the filter.
that won't work because neither do you know the value of the property at
build time, nor in this case do you want to change the value during
configuration. I want the thing that was built for me specifically... the
only unique value that I know about is bundleId.
Ideally the target filter would be set using config admin to maximise the
reusability of the bundle (for example in an environment without the
extender where another service should be used).
Config admin implies human responsibility and in this case I don't want
humans involved.
I can create a contrived example of this using current OSGi pieces.
I have a bundle, it uses both gemini blueprint and DS.
How can I tell the DS component to get my instance of
org.springframework.context.ConfigurableApplicationContext? I can't
without manually implementing a ServiceTracker because the only bits I can
filter on are things you can't know at XML creation time or that you'd
never want to duplicate from the manifest.
One of the best things about the service registry is decoupling the
provider from the consumer. I'd try very hard to avoid breaking that.
I never talked about coupling providers to consumers.
Regards,
Tim
Sent from my iPhone
On 8 Mar 2015, at 14:49, Raymond Auge <raymond.a...@liferay.com> wrote:
Hey all,
I have a need for a component to get a service created on behalf of the
bundle by an extender. There are many such services in the system so what
I really need is to get a bundle with a filter like so:
Filter filter = bundleContext.createFilter(
"(&(objectClass=" + ExtenderCreatedService.class.getName() +
")(service.bundleid=" + bundle.getBundleId() + "))");
i.e. get the one created which has my bundleId.
Is there any trick to doing this besides a ServiceTracker which the
component must manually create and start?
Note the component can't know it's own bundleId at the time of generating
the XML.
Is there any property parsing happening in the component XML files or
anything?
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
