Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2-incubating
    • Fix Version/s: 0.3-incubating
    • Component/s: Core
    • Labels:
      None

      Description

      BeanProvider is a very cool way to get bean from not managed objects but it is not so cool to use with @Dependent CDI Beans because it is not cleanable

      return with the bean the creational context can help to do so ("you are not managed so clean it yourself")

      instead of returning the bean a wrapper could be returned like for instance (this class should be enhanced since it manages only one dependent instance):

      public class BeanInstance {
      private Object bean;
      private CreationalContext<?> context;

      public BeanInstance(Object bean, CreationalContext<?> context)

      { this.bean = bean; this.context = context; }

      public boolean isResolved()

      { return bean != null; }

      public Object getBean()

      { return bean; }

      public void release()

      { context.release(); }

      }

        Activity

        Hide
        Gerhard Petracek added a comment -

        basically i agree - we need something like #release for dependent scoped beans - but not for the rest (-> e.g. BeanInstance and DependentBeanInstance)

        Show
        Gerhard Petracek added a comment - basically i agree - we need something like #release for dependent scoped beans - but not for the rest (-> e.g. BeanInstance and DependentBeanInstance)
        Hide
        Mark Struberg added a comment -

        I fear this is way too complicated for now. Maybe if we one day provide a framework to easily implement own scopes we could add a 'BeanBag' which contains Bean<T>, T, and CreationalContext<T>

        Show
        Mark Struberg added a comment - I fear this is way too complicated for now. Maybe if we one day provide a framework to easily implement own scopes we could add a 'BeanBag' which contains Bean<T>, T, and CreationalContext<T>
        Hide
        Mark Struberg added a comment -

        Should we maybe log a warning if a user invokes BeanProvider#getContextualReference for a @Dependent bean?

        Or shall we at least do this when in ProjectStage.Development?

        Show
        Mark Struberg added a comment - Should we maybe log a warning if a user invokes BeanProvider#getContextualReference for a @Dependent bean? Or shall we at least do this when in ProjectStage.Development?
        Hide
        Mark Struberg added a comment -

        We now log a warning in ProjectStage Development and UnitTest if a @Dependent scoped bean gets created via BeanProvider.

        Show
        Mark Struberg added a comment - We now log a warning in ProjectStage Development and UnitTest if a @Dependent scoped bean gets created via BeanProvider.
        Hide
        Romain Manni-Bucau added a comment -

        hmm, it doesn't answer a common need i think, it should ease the user to create its own scope, maybe that's another issue but it should be managed i think

        wdyt?

        Show
        Romain Manni-Bucau added a comment - hmm, it doesn't answer a common need i think, it should ease the user to create its own scope, maybe that's another issue but it should be managed i think wdyt?
        Hide
        Mark Struberg added a comment -

        The only thing we can do is to raise attention and awareness by logging a warning in development. We neither can provide a fix nor can we return something different.

        It's really use case specific and it's not even an error in any case!. E.g. if you use this method to pick up a class (without Interceptors or Decorators) and store it in a static field, then this is perfectly fine.

        If we would require our users to use a different method for @Dependent beans, then the users would need to do a check upfront -> that's not fine neither.

        Show
        Mark Struberg added a comment - The only thing we can do is to raise attention and awareness by logging a warning in development. We neither can provide a fix nor can we return something different. It's really use case specific and it's not even an error in any case!. E.g. if you use this method to pick up a class (without Interceptors or Decorators) and store it in a static field, then this is perfectly fine. If we would require our users to use a different method for @Dependent beans, then the users would need to do a check upfront -> that's not fine neither.
        Hide
        Romain Manni-Bucau added a comment -

        never said was an error but i really think we should ease this usage, it is quite common for framework integration

        Show
        Romain Manni-Bucau added a comment - never said was an error but i really think we should ease this usage, it is quite common for framework integration

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Romain Manni-Bucau
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development