Hi John,
thanks for the tip. It works fine in both OSGi and non-OSGi environments.
I think you can close the bug as "Not an issue".
Cheers
Martin
On 21.1.2014 13:15, John Wells wrote:
> So looking closer at your code:
>
> private Descriptor createEventServiceDescriptor(String name) {
> return BuilderHelper.link(EventServiceImpl.class).
> to(EventService.class).
> named(name).
> in(Singleton.class).
> build();
> }
>
> In an OSGi environment this is likely not going to work because you have
> not done a "loadWith". So this EventServiceImpl will attempt to be
> loaded by the default algorithm which will not work in an OSGi
> environment. Since you seem to have access to the class here already
> you can write a fairly trivial HK2Loader that looks in a HashMap from
> name to given class which would work in both OSGi and non-OSGi
> environments or even one that hard-codes the output class file something
> like this:
>
> return BuilderHelper.link(fClass).
> to(EventService.class).
> named(name).
> in(Singleton.class).
> andLoadWith(new HK2Loader() {
> public Class<?>
> loadClass(String a) {
> return EventServiceImpl.class;
> }
> }).build()
>
> Or something like that (this is done free-form so excuse any syntax
> errors in the above code).
>
> I believe the above code should work in both an OSGi and non-OSGi
> environment.
>
> On 1/20/2014 4:04 PM, Martin Soch wrote:
>> I have created https://java.net/jira/browse/HK2-180 however I wasn't
>> able to attach demo app to it. I can send it to anyone who is interested.
>> Thanks
>> Martin
>>
>> On 18.1.2014 3:45, Tang Yong wrote:
>>> From log, service locator is null in descriptor, so, here, I am
>>> assuming the following two possible issues:
>>>
>>> 1. osgi-adaptor has a bug
>>> 2. the logic of obtaining the ServiceLocator maybe has some issue
>>>
>>> because this is your inner project and using ProSyst implementation,
>>> for better locating the reason, besides john's suggestion, I suggest
>>> that
>>>
>>> 1) making a small sample(same reproduce logic as your inner project)
>>> using *felix* rathan than ProSyst. Pl. using felix 4.0.2
>>>
>>> 2) seeing 1)'s result and whether can reproduce the issue. If being
>>> reproducing, pl. file a bug into hk2 jira and upload your small sample
>>> in order that others including me can investigate the issue better.
>>>
>>> Thanks
>>> Tang
>>>
>>> John Wells wrote:
>>>> You might also want to do this:
>>>>
>>>> https://hk2.java.net/2.2.0/apidocs/org/glassfish/hk2/utilities/ServiceLocatorUtilities.html#enableLookupExceptions%28org.glassfish.hk2.api.ServiceLocator%29
>>>>
>>>>
>>>>
>>>> to ensure that any reification errors are thrown up to the getService.
>>>> That should give us more information on why you are failing to get
>>>> your services (hopefully)...
>>>>
>>>> The reason that certain lookup exceptions are not enabled by default
>>>> is a long and bloody debate where "secure-by-default" sort of "won"
>>>> over useability (IMO)...
>>>>
>>>> John Wells
>>>> john.wells_at_oracle.comNOSPAM
>>>>
>>>> On 1/17/2014 7:04 AM, Martin Soch wrote:
>>>>> Hello Tang,
>>>>>
>>>>> thanks for the tip. However the osgi-adapter is started (bundle with
>>>>> ID 25). Attaching a run-log-file so you see what is going on there.
>>>>>
>>>>> Sahoo also mentioned (in separate email) that creating ServiceLocator
>>>>> every time getEventService(name) is called might cause returning
>>>>> null. However it looks like false alarm too.
>>>>>
>>>>> Any other ideas/tips ?
>>>>>
>>>>> Thanks
>>>>> Martin
>>>>>
>>>>> On 17.1.2014 10:58, Tang Yong wrote:
>>>>>> also cc sahoo, a point: hk2-osgi-adapter bundle must be started.
>>>>>>
>>>>>> Thanks
>>>>>> Tang
>>>>>>
>>>>>> Martin Soch wrote:
>>>>>>> Hello HK2 developers,
>>>>>>>
>>>>>>> I am evaluating HK2 and I am experiencing troubles with named
>>>>>>> services
>>>>>>> when running in OSGi environment.
>>>>>>> I would like to dynamically create named services with the following
>>>>>>> code snippet:
>>>>>>>
>>>>>>> public EventService getEventService(String name) {
>>>>>>> EventService es = locator.getService(EventService.class,
>>>>>>> name);
>>>>>>> if (es == null) {
>>>>>>> // there is no service in the registry with given
>>>>>>> name ->
>>>>>>> create it
>>>>>>> DynamicConfigurationService dcs =
>>>>>>> locator.getService(DynamicConfigurationService.class);
>>>>>>> DynamicConfiguration config =
>>>>>>> dcs.createDynamicConfiguration();
>>>>>>> Descriptor d = createEventServiceDescriptor(name);
>>>>>>> config.bind(d);
>>>>>>> config.commit();
>>>>>>> es = locator.getService(EventService.class, name);
>>>>>>> }
>>>>>>> return es;
>>>>>>> }
>>>>>>>
>>>>>>> private Descriptor createEventServiceDescriptor(String name) {
>>>>>>> return BuilderHelper.link(EventServiceImpl.class).
>>>>>>> to(EventService.class).
>>>>>>> named(name).
>>>>>>> in(Singleton.class).
>>>>>>> build();
>>>>>>> }
>>>>>>>
>>>>>>> "EventService" is the interface/contract and the
>>>>>>> "EventServiceImpl" is
>>>>>>> the implementation of that interface.
>>>>>>> The getEventService(String) works fine when running as standalone
>>>>>>> Java
>>>>>>> application but in OSGi environment it always returns "null".
>>>>>>>
>>>>>>> Under OSGi I am using hk2-osgi-adapter to obtain the ServiceLocator
>>>>>>> with the following code:
>>>>>>>
>>>>>>> Main main = (Main) bundleContext.getService((ServiceReference)
>>>>>>> bundleContext.getServiceReference(Main.class));
>>>>>>> ModulesRegistry registry = (ModulesRegistry)
>>>>>>> bundleContext.getService((ServiceReference)
>>>>>>> bundleContext.getServiceReference(ModulesRegistry.class));
>>>>>>> StartupContext ctx = new StartupContext();
>>>>>>> ServiceLocator l = main.createServiceLocator(registry, ctx, null,
>>>>>>> null);
>>>>>>>
>>>>>>> where ModulesRegistry means
>>>>>>> com.sun.enterprise.module.ModulesRegistry,
>>>>>>> Main means com.sun.enterprise.module.bootstrap.Main and
>>>>>>> bundleContext
>>>>>>> is instance of org.osgi.framework.BundleContext.
>>>>>>>
>>>>>>> Do you have any idea why I am always getting null under OSGi ?
>>>>>>> I am using ProSyst implementation of OSGi and HK2-2.2.0-b27 from
>>>>>>> Maven
>>>>>>> repo.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Martin
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>