aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes EJB and inheritance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "EJB and inheritance" Watch "EJB and inheritance" New topic
Author

EJB and inheritance

Alex Sharkoff
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
Hi all,

I'd greatly appreciate if you could shed some light on the followin question

Question.
SessionBean2(SB2) extends SessionBean1(SB1).
SB2 has public access as it is declared as <ejb-class> in the ejb-jar.xml, SB1 has package access as it is never declared a <ejb-class> and should be only visible to classes that live in the same package.


Will the ejb container throw an error when deploying/executing methods on SB2 as it extends a bean (SB1) that does not have public access?

Thanks a lot in advance to all.


Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Your example does not conform to what the spec mandates in section 7.10.2, namely that session bean classes must be declared public.

I know this does not answer your question, but everything that does not conform to the spec is not worth investigating anyway


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Vitaliy Geraymovych
Greenhorn

Joined: Jun 15, 2004
Posts: 24
Originally posted by Valentin Crettaz:
Your example does not conform to what the spec mandates in section 7.10.2, namely that session bean classes must be declared public.

I know this does not answer your question, but everything that does not conform to the spec is not worth investigating anyway


In my opinion the example is correct. Here is why.
We are deploying session bean SB2 which is public and implements SessionBean interface indirectly. As long as SB1 class file is accessable to SB2 and they both reside in the same package, container should be fine with it.

Vitaly


SCBCD 1.3<br />SCJP 1.2<br /> <br />"Every time I learn something new, it pushes some old stuff out of my brain" H.Simpson
Alex Sharkoff
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
Thanks Valentin & Vitaly for your replies.

We will have to agree with the spec and Valentin . I have tested the situation (the one I described in my original question) on JBoss and it throws an error. Made SB1 public - no error.

Thanks a lot again.

[ June 22, 2004: Message edited by: Alex Sharkoff ]
[ June 22, 2004: Message edited by: Alex Sharkoff ]
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Alex,
I'm glad you made it work

Vitaliy,
Unfortunately, when the spec says that the session bean class has to be public, it really means it and expects that container providers enforce the rule
Vitaliy Geraymovych
Greenhorn

Joined: Jun 15, 2004
Posts: 24
Originally posted by Valentin Crettaz:
Alex,
I'm glad you made it work

Vitaliy,
Unfortunately, when the spec says that the session bean class has to be public, it really means it and expects that container providers enforce the rule


I guess there is a misunderstanding. I just deployed a quick example into RI server without any problems.

Here is the code:

class AdviceBeanSuper implements SessionBean {
... /* all needed stuff here, callbacks and ejbCreate */
}


public class AdviceBean extends AdviceBeanSuper {
/* actual bean*/
}

As long as I am deploying AdviceBean and not AdviceBeanSuper I am OK. I think all spec rules are correct. AdviceBean is public and implements SessionBean interface. HFE page 186 refers to inheritance in EJB.

Alex, you are not trying to deploy SB1 in your exmaple? Right? Only SB2.

Vitaly
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: EJB and inheritance