Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b61
    • Fix Version/s: None
    • Component/s: OSGi-JavaEE
    • Labels:
      None

      Description

      OSGi services have two scopes:
      singleton and per bundle.

      We should create a CDI scope called BundleScope to match the later type.

        Activity

        Hide
        TangYong added a comment - - edited

        Hi Sahoo,

        I want to make a discussion of concrete means for the feature.

        1 About the scopes of "singleton and per bundle"

        My understanding is, for OSGi Service Spec, there are two ways to register service.

        1) using service implementation directly
        eg. registration = bundleContext.registerService(Interface.class.getName(),Implementation Class Object,properties);

        In this case, service consumer will get the same service implementation object instance, called "singleton pattern for object creation"

        2) using service factory
        eg. registration = bundleContext.registerService(Interface.class.getName(),Service Factory Object, properties);

        In this case, service consumer will get multi service implementation object instance, called "prototype pattern for object creation"

        So, backing the feature,
        Question: whether "singleton and per bundle." is the above two patterns or not?

        2 About "create a CDI scope called BundleScope"

        1) Creating/Design way
        My way is to create a Qualifier to decorate @Publish, once Weld Container scans a class with Qualifier and @Publish, I will judge whether the class implements service factory, if not implementing, a exception will be thrown; otherwise, I will register the class using service factory way as OSGi Service.

        Question: whether you agree with me or not?

        2) Question: whether not needing to create singleton scope and defaultly, if not specifying BundleScope, the scope is singleton scope?

        3 About singleton service object
        This should be discussed in GLASSFISH-18938, however, discussion here is also good.
        While Weld Container scans a class with @Publish and singleton scope, we will register the class as OSGi Service. Now, there are three ways to obtain the implementation class's instance.

        ・using java reflection
        eg. Class.newInstance() or Class.forName()

        ・using CDI's Instance<T>.select().get()
        This way, bean instance object is managed by CDI container.

        ・using CDI's contextual instance
        eg. Bundle bundle = BundleReference.class.cast(clazz.getClassLoader()).getBundle();
        Object instance = null ;
        CreationalContext<? extends Object> context = beanManager.createCreationalContext(pb.getBean());
        if (context != null)

        { instance = beanManager.getReference(pb.getBean(), clazz, context); }

        Question: Which one can be better?

        4 about a user's using way
        If we have four bundles, the first uses @Publish with singleton scope to register a class(eg. interface name is A) as OSGi Service, the second uses @Publish with BundleScope to register the same interface name A as OSGi Service, the third and the fourth use @OSGiService to try to obtain different service objects, then, maybe the third and the fourth maybe obtain the same service objects.

        Question: whether we should consider the case as user's error or not?

        Thanks.
        Tang

        Show
        TangYong added a comment - - edited Hi Sahoo, I want to make a discussion of concrete means for the feature. 1 About the scopes of "singleton and per bundle" My understanding is, for OSGi Service Spec, there are two ways to register service. 1) using service implementation directly eg. registration = bundleContext.registerService(Interface.class.getName(),Implementation Class Object,properties); In this case, service consumer will get the same service implementation object instance, called "singleton pattern for object creation" 2) using service factory eg. registration = bundleContext.registerService(Interface.class.getName(),Service Factory Object, properties); In this case, service consumer will get multi service implementation object instance, called "prototype pattern for object creation" So, backing the feature, Question: whether "singleton and per bundle." is the above two patterns or not? 2 About "create a CDI scope called BundleScope" 1) Creating/Design way My way is to create a Qualifier to decorate @Publish, once Weld Container scans a class with Qualifier and @Publish, I will judge whether the class implements service factory, if not implementing, a exception will be thrown; otherwise, I will register the class using service factory way as OSGi Service. Question: whether you agree with me or not? 2) Question: whether not needing to create singleton scope and defaultly, if not specifying BundleScope, the scope is singleton scope? 3 About singleton service object This should be discussed in GLASSFISH-18938 , however, discussion here is also good. While Weld Container scans a class with @Publish and singleton scope, we will register the class as OSGi Service. Now, there are three ways to obtain the implementation class's instance. ・using java reflection eg. Class.newInstance() or Class.forName() ・using CDI's Instance<T>.select().get() This way, bean instance object is managed by CDI container. ・using CDI's contextual instance eg. Bundle bundle = BundleReference.class.cast(clazz.getClassLoader()).getBundle(); Object instance = null ; CreationalContext<? extends Object> context = beanManager.createCreationalContext(pb.getBean()); if (context != null) { instance = beanManager.getReference(pb.getBean(), clazz, context); } Question: Which one can be better? 4 about a user's using way If we have four bundles, the first uses @Publish with singleton scope to register a class(eg. interface name is A) as OSGi Service, the second uses @Publish with BundleScope to register the same interface name A as OSGi Service, the third and the fourth use @OSGiService to try to obtain different service objects, then, maybe the third and the fourth maybe obtain the same service objects. Question: whether we should consider the case as user's error or not? Thanks. Tang
        Hide
        Sanjeeb Sahoo added a comment -

        When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope this answers your first question.

        I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon this feature.

        Show
        Sanjeeb Sahoo added a comment - When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope this answers your first question. I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon this feature.
        Hide
        TangYong added a comment -

        >When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope >this answers your first question.

        >I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon >this feature.

        OK. I see.

        In addition,

        >3 About singleton service object
        I have confirmed that we should use the way of CDI's Instance<T>.select().get(). Please seeing my comment on GLASSFISH-19215, because while a bean(@Publish) has a dependent bean(@OSGiService), we can not simply create a instance using java reflection, and considering portable api, we should also use CDI's contextual instance.

        Tang

        Show
        TangYong added a comment - >When service is directly bound, its singleton scope. When factory is bound, then it's scope is bundle scope. I hope >this answers your first question. >I have not thought about the design yet. I think we need to first implement GLASSFISH-19215 before embarking upon >this feature. OK. I see. In addition, >3 About singleton service object I have confirmed that we should use the way of CDI's Instance<T>.select().get(). Please seeing my comment on GLASSFISH-19215 , because while a bean(@Publish) has a dependent bean(@OSGiService), we can not simply create a instance using java reflection, and considering portable api, we should also use CDI's contextual instance. Tang

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: