Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

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

 
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.
 
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?
 
Are you okay? You look a little big. Maybe this tiny ad will help:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic