Win a copy of Spring in Action (5th edition) this week in the Spring forum!

Frits Walraven

Creator of Enthuware JWS+ V6
+ Follow
since Apr 07, 2010
Frits likes ...
Android Chrome Eclipse IDE
Amersfoort, The Netherlands
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Frits Walraven

a compiler doesn't execute anything, it can only check what is being declared. declares an Exception, so you will have to deal with it. It doesn't matter whether overrides or not.

The compiler reads that g is a Game, which means that play() can thow an Exception.
Before System.out.println(b.h+" "+b.getH()); is completely finished it has to execute b.getH(), and in the execution of that method there is a System.out.println("Beta " + h);.

Does that make sense to you?
Yes, play() of Soccer does declare fewer exceptions. So that is ok, right?

The compiler doesn't know what happens runtime though, so it can only check method declarations. When it compiles the code it sees that you declare a Game g, and invoke the play method on g. According to the declaration of the method public void play() throws Exception it throws an Exception, right?

That means, that you will have to handle (try...catch) or declare (throws...) that exception. What will be the outcome if you do handle the Exception?
You are really close. When I run it, it outputs:

Beta 44
4 44
Beta 44
44 44

What part did you not get?
There are a number of important rules when overriding a method:
  • The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception
  • The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method
  • The overriding method can throw narrower or fewer exceptions.

  • Which one does apply here, do you think?
    What are the rules when overriding a method when it comes to Exceptions?

    Also another thing that I would like to ask: Is it really needed to transform my @WebService annotated class in an EJB using the @Stateless annotation?

    No, in EE6 it isn't needed. A Webservice class is by default wrapped into a Servlet. In EE5, as far as I remember, you needed to add some configuration otherwise the Webservice class was just a POJO.

    I just did a small test on Glassfish v3.1.2 and it worked without any problems. (in Eclipse I created a Dynamic Web Project with Target Runtime pointing to Glassfish).
    Ok, the problem now is that you can't package an EJB inside a WAR in EE5. That feature is introduced in EE6.

    Are you stuck on EE5?

    The Webservice class is now handled as a POJO (or did you add some configuration to treat it as a Servlet?). Injecting an EJB inside a POJO doesn't work.

    Am I missing something? I'm available to give more details if needed.  

    Please remove the mappedName attribute (2 times) from the EJB as it is an not portable propriety attribute.

    Apart from that I would make the WebService an EJB (add @Stateless on top of it) as you are calling it in a EE-environment. You might have a look at my notes, chapter 7 (OCEEJBD-Links)
    Although I haven't looked at the puzzles, but I just enjoy reading your posts. It must be good fun.

    All of you deserve a Cow!
    Note that there is not one single book to prepare you for the exam!  
    Start your preparation by reading either EJB 3 in Action (Manning) or Enterprise JavaBeans 3.1 (OReilly, 6th Edition).

    I have made a summary of the specifications that are important for the certification (check the notes section of the OCEEJBD-Links). Read, understand and study those and finally get the Enthuware mock exams.

    Don't forget to write your own code to verify what you have learned.

    Good Luck!  ....and don't forget to post your questions in this forum.
    Congratulations Tim.... don't let the Cows wait too long  
    1 week ago