• 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

Exception question for *REAL EJB MEN* (ok, Kathy, for REAL J2EE GIRLS too)

 
Bartender
Posts: 3904
43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reading EJB Specs found strange sentences:
p.96:
----
ejbCreate<METHOD> methods:
The throws clause may define arbitrary application exceptions, possibly including the javax.ejb.CreateException.
NOTE Word : "possibly"
and later for create<METHOD>:
p.98
----
� All the exceptions defined in the throws clause of an ejbCreate<METHOD> method of the session bean class must be defined in the throws clause of the matching create<METHOD> method of the remote home interface.
� The throws clause must include javax.ejb.CreateException.
NOTE Word : "must"
Should not be *must* instead of *possibly* in first case too ?
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy -- yeah, this is a little confusing the way they print it. The difference is between 'create' and 'ejbCreate'
The 'create' method in the Home MUST define the CreateException
The 'ejbCreate' method does not necessarily need to (although you usually WILL and should).
Does that help?
Kathy (almost-real J2EE girl)
 
Mikalai Zaikin
Bartender
Posts: 3904
43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah,
Thanks, Kathy, it helps.
I just realized that "ejbCreate()" is like a "boss".
When they talking about "javax.ejb.CreateException", he says to "create()" : Hey, I can define it in my signature or I can not to define. I am a boss.
But "create" as an "employee" does not have choice: it always HAD TO define "javax.ejb.CreateException".
 
Kathy Sierra
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Mikalai, I like that! And yes, I think that works -- the create() has no choice, while the ejbCreate() can do whatever it wants -- depending on whether it *really* might throw the exception.
Actually, the rules about ejbCreate() are the same as for any other Java implementation -- you do NOT have to declare an exception for an interface implementation method, even though that exception is declared in the interface. You must declare it in your implementation only if you might actually throw it.
OK, but having said all that... there *are* some deployment tools that might actually *force* you to declare the CreateException on the ejbCreate() method, and in general, it is considered a good practice even if you do NOT have to declare it.
So, for the exam -- the rules are according to the spec: create() MUST declare it, ejbCreate() CAN declare it.
But for real world -- you should probably declare a CreateException on your ejbCreate() as well. Remember, the Container might actually deploy a *subclass* of your bean class, and decide to do whatever it wants. If you haven't declared the CreateException (a checked exception) on your ejbCreate methods, the subclass won't be allowed to declare it (or throw it).
Anyway, I like the boss/employee thing
cheers,
Kathy
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Uhhh... I just read the spec for ejbCreate page 192 and it says MUST

"The throws clause must define the javax.ejb.CreateException. The throws clause may define arbitrary application specific exceptions."

The ejbPostCreate says MAY again p192 in ejb
 
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow, how did you even find this thread? Anyway, good catch. For CMPs, the ejbCreate methods must declare CreateException, according to the EJB 2.0 spec, page 192. For BMPs, declaring CreateException is optional, according to the spec, page 269. The create methods in the home interface must always declare CreateException.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason for the ejbCreate method of an entity bean having to declare CreateException seems clear enough to me: the client, whose invocation of create triggered ejbCreate, needs to receive an exception if something goes wrong.

But what about session beans? A stateful session bean is very similar to an entity bean in that its ejbCreate method is only invoked in response to the client's create call. So, it makes sense to declare CreateException. For a stateful session bean, it's different in that ejbCreate is not tied to a client call and is typically called long before the client even exists. So, CreateException makes no sense here.

To put it another way, it looks as if the optional CreateException in the throws clause of a session bean is to cater for the possibility of the bean being stateless.
 
Greg Charles
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, I don't think that's it. You have to declare CreateException in the home interface because there might be a problem with creating the bean. Even with stateless bean, if the pool were empty and not allowed to grow, maybe you would get a create exception. I'm not sure about that actually. However, with the ejbCreate method, you don't need to declare CreateException unless you are explicitly throwing it, or calling something that does.

For CMPs, you may be calling things during the ejbCreate method that throw CreateException, even though you don't see that in your code. That's just part of the magic of CMPs. For session beans and BMPs, if you don't see it, it's not there. A CreateException may still go back to the client, but it didn't get raised within ejbCreate. That's the difference.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Even with stateless bean, if the pool were empty and not allowed to grow, maybe you would get a create exception. I'm not sure about that actually.


My view is that you do need to be sure about this, because what is the point of the container throwing an exception to a non-existent client? This is why I believe that it is optional for CreateException to be declared in the throws clause of a session bean's ejbCreate method.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic