This week's giveaway is in the Programmer Certification (OCPJP) forum.
We're giving away four copies of Java Mock Exams (software) and have David Mayer on-line!
See this thread for details.
Win a copy of Java Mock Exams (software) this week in the Programmer Certification (OCPJP) forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

(HF EJB) abstract-schema-type == local component interface type?

 
Ming Hu
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In P420, second bullet point from the bottom on the right side. It reads,
"A SELECT can return either an <abstract-schema-type> (which really means the bean's local component interface type), or a single-value field".
Is this correct? Thanks.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That word 'local' shouldn't be there - the deployment descriptor determines if the component interface is to be local or remote.
 
Ming Hu
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reid M. Pinchback:
the deployment descriptor determines if the component interface is to be local or remote.

Thanks Reid for your input. I have a follow up question: Can DD do that? What if you define both remote and local interfaces for a bean?
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It goes in the deployment descriptor; one of those values that the bean provider generally specifies.
Any given ejbSelect that returns object references must support either remote objects, or local objects, but not both ('both' isn't a value you can put in that field in the DD).
There isn't anything stopping you from having two virtually-identical EJB-QL select specifications in the DD; one for remote, one for local, but you would have to give them different names (and hence you'd have difference abstract ejbSelect<METHOD> declarations for each in your bean class).
Note that this remote-or-local-not-both limitation doesn't apply to the find methods. Finders will automatically provide remote object references when you are using a remote home interface, and local object references when you are using a local home interface.
 
Ming Hu
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It goes in the deployment descriptor; one of those values that the bean provider generally specifies.
Any given ejbSelect that returns object references must support either remote objects, or local objects, but not both ('both' isn't a value you can put in that field in the DD).

You are right. There is a "result-type-mapping" tag. Although it is optional, the default is local. I was misled by the following (HF EJB P408): "As if by magic, the container knows which interface view to return, local or remote, depending on whether the invocation of the query came from a home or remote interface" or wasn't I?

Note that this remote-or-local-not-both limitation doesn't apply to the find methods. Finders will automatically provide remote object references when you are using a remote home interface, and local object references when you are using a local home interface.

How do you differentiate a select from a find in the deployment descriptor. Aren't they both declared in "query" tag?
 
What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!