Seam 2
  1. Seam 2
  2. JBSEAM-3262

Allow entity class component to be assigned stateless scope

    Details

    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      Scope the prototype to the event scope, though then it is stored for the remainder of the request. This can be a problem depending on the usage scenario.

      Show
      Scope the prototype to the event scope, though then it is stored for the remainder of the request. This can be a problem depending on the usage scenario.
    • Similar Issues:
      Show 10 results 

      Description

      There is no reason for not allowing an entity class component to be assigned to the stateless context like JavaBean and stateless session bean components. In fact, you could argue that there is no difference between a JavaBean and an entity class based on the fact that they are both vanilla Java classes.

      There is a perfect use case for this feature that comes right from the heart of Seam. When using the Home component, it is perfectly natural to create a component role for an entity class that is wired to the newInstance property to be used as a prototype. For instance, here is an example:

      <component name="roundPrototype" class="org.open18.model.Round" scope="stateless">
      <property name="golfer">#

      {currentGolfer}

      </property>
      <property name="date">#

      {currentDate}

      </property>
      </component>

      <framework:entity-home name="roundHome" class="org.open18.action.RoundHome" new-instance="#

      {roundPrototype}

      "/>

      You don't want the roundPrototype to be stored in a scope since it is only used internally to produce the instance managed by the roundHome component. However, with this configuration, Seam throws an exception at startup.

      1. JBSEAM-3262-branch20.txt
        1 kB
        Dan Allen
      2. JBSEAM-3262-trunk.txt
        1 kB
        Dan Allen

        Activity

        Hide
        Pete Muir
        added a comment -

        >> I don't undestand what "unscoped" is really...

        > I assumed what Norman meant was not scoped specifically to a context.

        So, what I don't understand here, is what it means for something not to be scoped to a context. Seam is contextual by nature.

        Show
        Pete Muir
        added a comment - >> I don't undestand what "unscoped" is really... > I assumed what Norman meant was not scoped specifically to a context. So, what I don't understand here, is what it means for something not to be scoped to a context. Seam is contextual by nature.
        Hide
        Jacob Orshalick
        added a comment -

        > So, what I don't understand here, is what it means for something not to be scoped to a context. Seam is contextual by nature.

        Agreed, context can always be inferred by relationship so, yes, "unscoped" is a bad term altogether

        Show
        Jacob Orshalick
        added a comment - > So, what I don't understand here, is what it means for something not to be scoped to a context. Seam is contextual by nature. Agreed, context can always be inferred by relationship so, yes, "unscoped" is a bad term altogether
        Hide
        Dan Allen
        added a comment -

        > That's a bit unnerving

        Must frustration is just shining through here. I just don't understand why this is so hard to explain. In Seam, as it stands now, the stateless scope doesn't store the result. It is an "unscope" because after the creation process happens, it returns the result to the caller and doesn't keep a reference to it. Yes, Seam is contextual by nature, but the stateless scope falls outside of that nature. Frankly, the stateless scope is a perfect scope for creating prototypes because its kind of like a static method (the closest thing I can come up with).

        Now, do we need what I am asking for? Maybe I am the only person who finds it useful. I'm willing to accept that. But I found some way to use Seam that appears like a perfectly good use case. I like that Seam doesn't force designs on me, yet here we are trying to force a design.

        I completely agree that the stateless scope might not work this way in the future because the idea was perhaps to be more like stateless session beans. In that case, I would be referring to another scope, perhaps something like "prototype" scope in Spring, which, by the way, is exactly like Seam's stateless scope as it stands now.

        Show
        Dan Allen
        added a comment - > That's a bit unnerving Must frustration is just shining through here. I just don't understand why this is so hard to explain. In Seam, as it stands now, the stateless scope doesn't store the result. It is an "unscope" because after the creation process happens, it returns the result to the caller and doesn't keep a reference to it. Yes, Seam is contextual by nature, but the stateless scope falls outside of that nature. Frankly, the stateless scope is a perfect scope for creating prototypes because its kind of like a static method (the closest thing I can come up with). Now, do we need what I am asking for? Maybe I am the only person who finds it useful. I'm willing to accept that. But I found some way to use Seam that appears like a perfectly good use case. I like that Seam doesn't force designs on me, yet here we are trying to force a design. I completely agree that the stateless scope might not work this way in the future because the idea was perhaps to be more like stateless session beans. In that case, I would be referring to another scope, perhaps something like "prototype" scope in Spring, which, by the way, is exactly like Seam's stateless scope as it stands now.
        Hide
        Pete Muir
        added a comment -

        > In Seam, as it stands now, the stateless scope doesn't store the result. It is an "unscope" because after the creation process happens, it returns the result to the caller and doesn't keep a reference to it. Yes, Seam is contextual by nature, but the stateless scope falls outside of that nature. The API vs implemetnation, of Seam is hard to understand sometimes as we have no spec it is based on.

        No, the stateless scope is well defined, no state is held by objects between calls to the object. You are confusing the implementation of the stateless scope and it's semantics.

        > Now, do we need what I am asking for? Maybe I am the only person who finds it useful. I'm willing to accept that.

        We all agree, there are valid use cases for this. That's why it is defined in Web Beans, and will be available in Seam 3.

        > I completely agree that the stateless scope might not work this way in the future because the idea was perhaps to be more like stateless session beans. In that case, I would be referring to another scope, perhaps something like "prototype" scope in Spring, which, by the way, is exactly like Seam's stateless scope as it stands now.

        Seam's stateless scope is semantically identical to the stateless scope in EJB3. It just isn't implemented that way currently.

        So, you are asking for a new scope. That new scope is the dependent scope, which Web Beans introduces.

        As we have a big step change in Seam just around the corner which resolves this issue, introducing anything extra at this stage would just confuse people.

        And to go back:

        > I don't care if it's consider hackish because the idea works for me.

        Which is fine if you are a user, however for it to make its way into core, it must be semantically consistent and correct, otherwise we end up with a big incoherent mess

        Show
        Pete Muir
        added a comment - > In Seam, as it stands now, the stateless scope doesn't store the result. It is an "unscope" because after the creation process happens, it returns the result to the caller and doesn't keep a reference to it. Yes, Seam is contextual by nature, but the stateless scope falls outside of that nature. The API vs implemetnation, of Seam is hard to understand sometimes as we have no spec it is based on. No, the stateless scope is well defined, no state is held by objects between calls to the object. You are confusing the implementation of the stateless scope and it's semantics. > Now, do we need what I am asking for? Maybe I am the only person who finds it useful. I'm willing to accept that. We all agree, there are valid use cases for this. That's why it is defined in Web Beans, and will be available in Seam 3. > I completely agree that the stateless scope might not work this way in the future because the idea was perhaps to be more like stateless session beans. In that case, I would be referring to another scope, perhaps something like "prototype" scope in Spring, which, by the way, is exactly like Seam's stateless scope as it stands now. Seam's stateless scope is semantically identical to the stateless scope in EJB3. It just isn't implemented that way currently. So, you are asking for a new scope. That new scope is the dependent scope, which Web Beans introduces. As we have a big step change in Seam just around the corner which resolves this issue, introducing anything extra at this stage would just confuse people. And to go back: > I don't care if it's consider hackish because the idea works for me. Which is fine if you are a user, however for it to make its way into core, it must be semantically consistent and correct, otherwise we end up with a big incoherent mess
        Hide
        Dan Allen
        added a comment -

        > Seam's stateless scope is semantically identical to the stateless scope in EJB3. It just isn't implemented that way currently.

        Okay, I think the whole root of this discussion is intent vs actual, so in fact we are not disagreeing, but debating about different things. You are understandably looking at it from the scope's intent and I am looking at it from how it works today. Fair enough.

        > So, you are asking for a new scope. That new scope is the dependent scope, which Web Beans introduces.

        I am in complete agreement with you that I don't want to introduce a new scope in Seam right now. We see eye-to-eye on that for sure, for all the reasons you stated.

        > Which is fine if you are a user, however for it to make its way into core, it must be semantically consistent and correct, otherwise we end up with a big incoherent mess

        Amen. Given that we want to promote intent, not necessarily a opening in the implementation, I understand the decision to take no action. I think this discussion was very revealing and will serve as an eye-opening reference for the user regarding the stateless scope.

        Show
        Dan Allen
        added a comment - > Seam's stateless scope is semantically identical to the stateless scope in EJB3. It just isn't implemented that way currently. Okay, I think the whole root of this discussion is intent vs actual, so in fact we are not disagreeing, but debating about different things. You are understandably looking at it from the scope's intent and I am looking at it from how it works today. Fair enough. > So, you are asking for a new scope. That new scope is the dependent scope, which Web Beans introduces. I am in complete agreement with you that I don't want to introduce a new scope in Seam right now. We see eye-to-eye on that for sure, for all the reasons you stated. > Which is fine if you are a user, however for it to make its way into core, it must be semantically consistent and correct, otherwise we end up with a big incoherent mess Amen. Given that we want to promote intent, not necessarily a opening in the implementation, I understand the decision to take no action. I think this discussion was very revealing and will serve as an eye-opening reference for the user regarding the stateless scope.

          People

          • Assignee:
            Pete Muir
            Reporter:
            Dan Allen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 5 minutes
              5m
              Remaining:
              Remaining Estimate - 5 minutes
              5m
              Logged:
              Time Spent - Not Specified
              Not Specified