[norman.richards]

"EricJava" wrote:
Then I was using other POJOs and wondering, why are these things not starting conversations? Now I see. I need to put @Scope(CONVERSATION) on them.

Using a conversation scoped component does not automatically make the conversation long running.

[msystems]

"EricJava" wrote:

If I put just @Name, it's a POJO, and you're saying it's request scoped?

Yes.

Waitaminute, looking at the JBoss Seam book (an official JBoss publication), by Michael Yuan and Thomas Heute, on page 320:

However, Seam POJO components are stateful and have a conversational scope by default.

When you say "request scoped" maybe you mean "temporary conversation scoped"?

Must be an error ! Seam POJO's are default EVENT (request) scoped and not conversation or temp. conversation scoped.

From the Seam reference:

By default, JavaBeans are bound to the event context.

[ericjava]

"msystems" wrote:
Must be an error ! Seam POJO's are default EVENT (request) scoped and not conversation or temp. conversation scoped.

Indeed:

http://docs.jboss.org/seam/2.0.1.CR2/reference/en/html/concepts.html

By default, JavaBeans are bound to the event context.

which is not the same as the request, or the conversation, or the temporary conversation. Event is stateless.

Reading on in the doc:

However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security, efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).

Is this correct? If I'm using a POJO and I put a @Restrict on it, that @Restrict is ignored? If that's the case, I probably can't use POJOs at all in my application, because nearly every operation is restricted.

[pmuir]

"EricJava" wrote:
Waitaminute, looking at the JBoss Seam book (an official JBoss publication), by Michael Yuan and Thomas Heute, on page 320:

However, Seam POJO components are stateful and have a conversational scope by default.

When you say "request scoped" maybe you mean "temporary conversation scoped"?

No, I mean request scoped. The book is wrong and I am right ;)

By default, JavaBeans are bound to the event context which is not the same as the request, or the conversation, or the temporary conversation. Event is stateless.

No. The Event scope is the length of the request. I'm quite bad at using the words Request an Event interchangeably for that scope. Event is NOT stateless like an @Stateless EJB3, the scope of the state is the request.

"msystems" wrote:
Must be an error ! Seam POJO's are default EVENT (request) scoped and not conversation or temp. conversation scoped.


Indeed:

http://docs.jboss.org/seam/2.0.1.CR2/reference/en/html/concepts.html

Quote:
By default, JavaBeans are bound to the event context.


which is not the same as the request, or the conversation, or the temporary conversation. Event is stateless.

Reading on in the doc:

Quote:
However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security , efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).


Is this correct? If I'm using a POJO and I put a @Restrict on it, that @Restrict is ignored? If that's the case, I probably can't use POJOs at all in my application, because nearly every operation is restricted.

Thats talking about EJB3 declarative security, not Seam Security. Seam security works equally well on EJB3s or Seam POJOs.

[jacob.orshalick]

"EricJava" wrote:
However, Seam POJO components are stateful and have a conversational scope by default.

Yes, the book is wrong here. This is one of quite a few revisions for the Second Edition. A preview is coming soon. Stay tuned!

[ericjava]

Pete and Jacob, thanks for the info on that. That clarifies a lot of things.

[vladimir.kovalyuk]

"vladimir.kovalyuk" wrote:
1. Does JPA persistence context propagation rules work for Seam-managed conversation-scoped Beans?

No, they are different. JPA persistence context propagation rules are complex. SMPC propgation is simple. You will get the same PC for the length of that conversation injected into the bean. So if you aren't in a long running conversation, it will be the same PC for the whole of the request.

Thank you Pete! I missed that SMPC is employed using @In, not @PersistenceContext. I get used to think that Seam components is empoyed by interception. I should revise SMPC.