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

Bean things during activation

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi..

In HFE book, in page 354, it says that during ejbActivate(), one cannot "get the security info of the client, cannot force a transaction roolback, find out if the transaction is already rolled back, access another bean's method or access a resource manager..". All of this is possible in ejbLoad()

One can understand that in ejbPassivate the bean is no longer associated with a client or a transaction hence these methods are not feasable..Would like to understand why this restriction is in place for ejbActivate..

ejbActivate would have been called when a client calls a business method which in turn makes the container to get the bean for the entity from the pool and then call the ejbActivate.. In such a case would not this method have access to the client security info ?

TIA
cheerz
krish
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In this state transition, the bean has already associated a valid primary key, but the underlying entity is not yet synchronized, menas that the rest of your data fields are invalid. Therefore, it does not make sense to change or read them. No transaction is needed therefore. And under this circumstances, what would you like make with the security info?

Severin
 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think it would be better to get the client security info to verify whether the client has permission to access the bean method. In this way, the container does not need to load data when the client does not have permission accessing the method (it's kind of lazy initialization)
 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Joe,
Isn't that the job of the container to make sure the client has acccess to the called method?that's one of the services provided by EJB server.
sujana
 
Severin Stoeckli
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You have two possibilities:
- declarative security: it's the job of the container
- procrammatic security: it's the job of the bean provider

In this case, the programmer checks if the caller is in a specific role. How would you implement "each client has access to the data of its own account"? You can't make this delcarative. And you can't make this if the data is not yet loaded. Yo need the account number to check if it is the account of the caller. Therefore, a check in ejbActivate is not possible, since the data of the bean is not yet available.

But perhaps you have an example that shows the contrary...?


Severin
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic