[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3262) Allow entity class component to be assigned stateless scope

Pete Muir (JIRA) jira-events at lists.jboss.org
Sat Aug 16 19:25:58 EDT 2008


    [ https://jira.jboss.org/jira/browse/JBSEAM-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12425362#action_12425362 ] 

Pete Muir commented on JBSEAM-3262:
-----------------------------------

[Sorry for the late reply, I lost the notification]

Ok, I now understand what you are after.

I'll address your points individually:

Dan Allen wrote:

> The stateless scope is useful for repetitive creation.

Not really, it's useful for providing stateless services. A factory is useful for repetitive creation

> It is very possible that you are feeding the prototype into more than one component and you need distinct instances.

Yes, this is a dependent scope.

> The request (event) scope would feed the same instance to everyone. While true that it will work for some cases, it seems like a pretty dumb artificial restriction. 

Yes.

> Who are we to say what the user might want to do with that prototype component?

Yes.

> It's the same exact reason why currentDate, currentDatatime, and currentTime are all stateless.

No, they aren't prototypes, they are stateless factories.

> In response, he said that what we are really going for here is "unscoped". That is exaclty what we want. But, aside from a difference in naming, I don't see a difference 
> between "stateless" and "unscoped" in Seam. "Unscoped" is exaclty what "stateless" is.

This sentence is nonsense - it's a circular arguement.

> [Implementation of stateless scope in Seam]

So what happens when we reimplement the stateless scope to *really be stateless* (i.e. based on a pool)? Then this all breaks entirely *as an entity holds state*.

Jacob Orshalick wrote:

> I agree that this is useful, but I must agree with Pete, using STATELESS here seems quite awkward. An entity holds state by definition creating a semantic clash.

Exactly, it's worse than awkward, it's totally incorrect and inconsistent.

> Unscoped or dependent scope (especially from a Web Beans perspective) makes much more sense.

I don't undestand what "unscoped" is really... But the dependent scope solves the use case Dan presents.

Dan Allen wrote:

> I think we are having a silly squabble over terminology. 

No, it's an important discussion over the semantics.

> Seam doesn't have the notion of a dependent scope, where two components can be kept loosely coupled, but one component's scope is tied not to the global context but rather to the existence of the other component. It just doesn't exist in Seam. 

No, and this is recognized as a flaw.

> Besides, my use case clearly isn't about a dependent scope. It's about object initialization.

Yes, your use case is about object initialization, but the *solution* is the dependent scope.

To go back to your use case, to claim this

<component name="roundPrototype" class="org.open18.model.Round" scope="stateless">
    <property name="golfer">#{currentGolfer}</property>
    <property name="date">#{currentDate}</property>
</component> 

is stateless is patently absurd.

> Sure, entity classes hold state,

Yes.

> and here I am giving them state.

Yes.

> I am just not letting Seam manage the scope of that entity instance directly, but putting the Home object in charge of that task.

So then why on earth are you making them components? Making something a component *makes Seam manage the instance*.

>Then, Seam takes care of the scope of the Home object.

Yes.

> This may not be the direct intent of the the STATELESS scope,

It's not even the indirect intent, it's totally orthogonal.

> but it sure as heck makes sense when you look at it from the perspective of object initialization (i.e., a decarative way of doing @Create).

It's absolutely disgusting and horribly confuses semantics. You are also relying on the implementation of the stateless scope of Seam, and not it's declared semantics.

And no, we aren't adding a dependent scope to Seam 2.1.

> Allow entity class component to be assigned stateless scope
> -----------------------------------------------------------
>
>                 Key: JBSEAM-3262
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3262
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.3.CR1, 2.1.0.A1
>            Reporter: Dan Allen
>            Assignee: Dan Allen
>            Priority: Minor
>             Fix For: 2.0.3.GA, 2.1.0.GA
>
>         Attachments: JBSEAM-3262-branch20.txt, JBSEAM-3262-trunk.txt
>
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the seam-issues mailing list