All inline.
>
>
> Dear Juan ,
> It was nice getting in to a discussion with you and some of
> your points have sure added a bit to my knowledge as well. So
> Thanks again Juan.
>
> I would like to add to the comment provided by you
> <Juan>
> At a low level, Java's instance(non-static) methods receive
> implicitly the this object as the first parameter. The 'this'
> keyword is automatically added in the code where it's
> implicit by the compiler(just as C++ internally works). See
> the JVM specification for details. </Juan>
>
> <Aashish> As far as Core Java Objects are concerned they
> behave the same
> way as you have mentioned above.
All Java Objects that run in a JVM as per the spec. That includes Entity
Beans.
> but as far as EJB are concerned will not that break the very
> purpose of EJB's i.e beans talk to each other through Remote
> Interface.
Well, let's forget Local objects. Then you're right. But I cannot see
using a methodless interface as a purpose, but as means to an end. I
write solutions to existing problems and tagging my classes as Remote,
Serializable or whatever isn't what I get paid for.
> and doesnot involves in any way the object
> themselves so the "this" keyword wont be availble to the
> beans accessing Distributed objects.
'this' is always there. If you write:
public void mth1() {
if(this.flag)
this.mth2();
}
It will both compile and run. In fact, this code is equal to this one:
public void mth1() {
if(flag)
mth2();
}
The keyword 'this' is implicit. It's added by the compiler if it can
detect when to. Now, if you're talking about passing 'this' as a
parameter:
public void mth2(Object a) {}
And calling it:
ejb.mth2(this);
Then yes, it will compile/run or not depending on the context. For
instance:
public class MyValue impements Serializable {
public MyValue(long pk) {
...
ejb.mth2(pk, this);
...
}
}
Works like a charm. I'm afraid I fail to see how this relates to static
and synchronized methods, tough. You previously wrote:
> Answer : Static methods could be declared in Beans.
True. I agree.
> but since in static methods we dont have the Refernce to the Object
who called the method
In no method, static or not, you have the reference to the object who
called the method, unless you pass it in as a parameter. Even if it is
an EJB pointer you'd like to pass as a parameter, you can do so by
using(example of a caller:
public class MyEB implements EntityBean {
private EntityContext ctx;
public setEntityContext(EntityContext ctx) {
this.ctx = ctx;
}
...
public void someMethod() {
...
otherBean.methodX(this.ctx.getEJBObject(), someParam);
...
}
}
EJBObject extends Remote.
> (Since the use of "this" is strictly
> prohibted)
Again, 'this', the reference to the callee or the caller? And how does
it intersect with the notion of a static method? Maybe if you supply an
example I could understand what you're stating.
>
> I have O'Reilly to suppoprt my statement
Wow! I only have my sorry a## to back me up. You must have huge
connections ;)
>
> </Aashish>
>
> Aashish Kaushik
> Software Engg.
> TEL : 0120-4777881(Extn. 2390)
> Cell : 9810744076
> E-MAIL:[EMAIL PROTECTED]
> Visit Us At : www.jilit.de
>
> ~~~~~~~~~~~~~~~~~~~~~~
> There are no great people in this world,
> only great challenges which ordinary
> people rise to meet.
> - William Frederick Halsy, Jr. ~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
> Juan Pablo
>
> Lorandi To:
> [EMAIL PROTECTED]
> <rifle@CODEFOUNDR cc:
>
> Y.COM> Subject: Re:
> ejb method signature-Why Cant
> Sent by: A EJB methods be
> static-Group Plz. Contribute
> mailing list for
>
> Enterprise
>
> JavaBeans
>
> development
>
> <EJB-INTEREST@JAV
>
> A.SUN.COM>
>
>
>
>
>
> 09/29/02 12:05 AM
>
> Please respond to
>
> Juan Pablo
>
> Lorandi
>
>
>
>
>
>
>
>
> Instead of responding with stuff woven out of your mind, you
> could read the specs carefully. Section 24.1.2 "Programming
> restrictions" discusses this and gives reasoning for them:
>
> . An enterprise Bean must not use read/write static fields.
> Using read-only static fields is allowed. Therefore, it is
> recommended that all static fields in the enterprise bean
> class be declared as final.
>
> This rule is required to ensure consistent runtime semantics
> because while some EJB Containers may use a single JVM to
> execute all enterprise bean's instances, others may
> distribute the instances across multiple JVMs.
>
> . An enterprise Bean must not use thread synchronization
> primitives to synchronize execution of multiple instances.
>
> Same reason as above. Synchronization would not work if the
> EJB Container distributed enterprise bean's instances across
> multiple JVMs.
>
> Also, some comments of my own:
>
> At a low level, Java's instance(non-static) methods receive
> implicitly the this object as the first parameter. The 'this'
> keyword is automatically added in the code where it's
> implicit by the compiler(just as C++ internally works). See
> the JVM specification for details.
>
> Also, you may code static methods in your EJB class. They
> would never be exposed though, as interfaces (to your bean)
> cannot include the signatures of those methods. See the Java
> Language specification for details.
>
> Your response implies that static methods would need to
> interact with a particular bean instance. That doesn't
> necessarily break the EJB spec, but it's a shameful
> programming practice. EJBs, even Entity Beans are fully blown
> business objects. The facade pattern is quite useful, but it
> seems most programmers think all business logic belongs in
> these and Entity Beans are just an excuse not to write JDBC
> code. Don't break encapsulation just to use facades; I mean
> the complete definition of
> encapsulation: An object should expose its state as little as
> possible(without being a fundamentalist of OOP).
>
> The question should be: Which purpose should a static method serve?
>
> A - If it is a utility method, then it probably could also be
> placed in a regular java class.
>
> B - If it is geared towards managing the lifetime of objects
> of that class, then it is either superceeded by the Home
> interfaces or not applicable or even undesirable(for
> singletons, for instance).
>
> I honestly doubt there are many other uses for static methods
> that aren't directly related for these two, but I'm open to comments.
>
> The bottom line is: EJB Containers abstract some concepts
> such as instance lifetime and load distribution. That makes
> EJBs easier to write and maintain. That also makes static
> and/or synchronized directives superfluous(Except when
> defining constant fields, using 'static final').
>
> My 2c,
>
> Juan Pablo Lorandi
> Chief Software Architect
> Code Foundry Ltd.
> [EMAIL PROTECTED]
>
> Barberstown, Straffan, Co. Kildare, Ireland.
> Tel: +353-1-6012050 Fax: +353-1-6012051
> Mobile: +353-86-2157900
> www.codefoundry.com
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Aashish Kaushik
> > Sent: Saturday, September 28, 2002 9:22 AM
> > To: [EMAIL PROTECTED]
> > Subject: ejb method signature-Why Cant EJB methods be static-Group
> > Plz. Contribute
> >
> >
> > Hello All ,
> >
> > This seems to be a good question raised by Javed and i would
> > appreciate if everybody would contribute in his quest for
> the answer.
> > I Reframe the question with a bit of my own personal query added to
> > it.
> >
> > I make it clear now that whatever i answer to the question framed
> > below is purely woven out of my mind and has nothing to do with the
> > specification .
> >
> > Any Corrections are welcome.
> >
> > Question : Why cant ejb methods be Static ??
> >
> > Answer : Static methods could be declared in Beans but since in
> > static methods we dont have the Refernce to the Object who
> called the
> > method (Since the use of "this" is strictly
> > prohibted) so that would involve the extra
> > work of looking up the bean and executing the methods on
> its fields.
> > Which is quiet opposed to Object methods which have the
> reference of
> > the Stub or Remote Refernce and hence doesnot have to lookup the
> > object ,which in turn saves the extra overhed of looking up the
> > concerned bean as was in the case of static methods of the
> Bean Class.
> >
> >
> >
> > Javed as far as your answer of Synchronized methods in Beans is
> > concerned ,There is no need for methods to be declared
> synchronized as
> > its EJBObject who can receive multiple calls from the
> clients on the
> > same methods. But in order to maintain concurrency EJB
> OBject passes
> > the call to the Bean methods one at a time. So the need of
> > synchronized methos doesnot arises.
> >
> > Regards,
> > Aashish
> >
> > **************************************************************
> > ***********************************************
> >
> > Hi
> >
> > Is there any restrictions on the method signature of ejb
> methods like
> > it should not be static and synchronized. Is there any
> article on the
> > restrictions of signatures in ejb methods
> >
> > regards
> > javid
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > body of the message "signoff EJB-INTEREST". For general help, send
> > email to [EMAIL PROTECTED] and include in the body of
> the message
> > "help".
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > body of the message "signoff EJB-INTEREST". For general help, send
> > email to [EMAIL PROTECTED] and include in the body of
> the message
> > "help".
> >
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "signoff EJB-INTEREST".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
>
>
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
