• 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
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

ejbActivate

 
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On page 354 HF EJB , the things one can do during activation are listed as :

Can use the EntityContext to:
1)get reference to your home
2)get reference to your EJB object
3)get your primary key.

I dont understand why we cannot use the EntiryContext to "get security infromation about the client".For ejbActivate to be called , its because the client has called a business method on the EJB object , and hence needs the service of the bean.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bean Things are confusing!! may shed some light on things.
 
jeff mutonho
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peer.I appreciate your pointer , but I'll be honest and say the explanation there isn't clear, to me ,that is.I checked what the spec says on page 180 :

� Invoking the getCallerPrincipal and isCallerInRole methods is disallowed in the entity bean methods for which the Container does not have a client security context.



Fine , but then how can the container NOT have a client security context , when it was the client who invoked a business method that resulted in he calling of ejbActivate on the bean.Surely the container should know who caused it to activate the bean.Or am I totally lost here ?

jeff mutonho
 
jeff mutonho
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or is it that the container just doesn't bother with knowing the client security context as it DOES NOT consider the ejbActivate() call a "meaningful transaction context" ?

jeff mutonho
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by jeff mutonho:
It was the client who invoked a business method that resulted in he calling of ejbActivate on the bean.



The point that I tried to make in the fifth post of Bean Things are confusing!! is that the specification is giving the server the freedom to complete the ejbActivate before a client invokes a business call in order to serve that future invocation by a client faster - clearly it would only want to do that for entities that in the (recent) past were in high demand - i.e. it is highly likely that there will be a call coming in for that entity "any time now".

In the ejbActivate you can already perform JNDI lookups which can be "slow/expensive". You can get a hold of your component interface which you will return in place of "this", similarly you can get the home interface.
The peculiar one is getPrimaryKey. This is useless if the object-model was designed first because the data model will usually use synthetic keys only - these keys belong in the category of an existence based identity - i.e. the key has no further meaning other than uniquely identifying the entity's existence.
In systems where the data model came before the object-model however you can encounter value based identities - usually a compound key of fields that uniquely identify the entity. These compound keys can include discriminator fields that can be used to configure the entity bean - even before you run ejbLoad.

So again I state that the specification disallows the access to client specific functions in the ejbActivate so that the server may complete the ejbActivate even before a client invokes a business method on that entity bean.
[ October 27, 2005: Message edited by: Peer Reynders ]
 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeff,
There will be a lot of surprises like thisin Bean Things. My advice to you for the exam would be not to look too much into these and just work out a way to remember them for the exam
 
jeff mutonho
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So again I state that the specification disallows the access to client specific functions in the ejbActivate so that the server may complete the ejbActivate even before a client invokes a business method on that entity bean.



Makes sense.Thanks guys for your responses
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic