• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
reply
    Bookmark Topic Watch Topic
  • New Topic