hi all
i am new to EJb. i am working on weblogic server6.0 which supports EJB 2.0.i was
socked when i saw the same behaviour of stateless and stateful session bean.
The description of my program is as below
in my remote interface there are 2 methods
1>void setmyname(String)
2>String getmyname()
i am setting the name variable using setmyname method and obtaining it from
getmyname() method.
if my bean is stateful session bean then the program works as expected and return
value of getmyname() method is the variable which is set by setmyname() method.
but if the bean is stateless then also it returns the same value as stateful bean(i
think this should not be done.i may be wrong!)
what is the wrong with progrsm ?does my interpretation wrong ?does there any special
setting to be do in deployment descriptor ?
Thank you
pranav shah
------------- Original Message --------------
"Kjetil H.Paulsen" <[EMAIL PROTECTED]> wrote:
To:[EMAIL PROTECTED]
From:"Kjetil H.Paulsen" <[EMAIL PROTECTED]>
Date:Fri, 6 Apr 2001 09:23:02 +0200
Subject:Re: User registry's Userid and Password
This is not the right list for your question, however JAAS solves your
problem.
http://java.sun.com/products/jaas
/kjetilhp
> -----Original Message-----
> From: krithikav [mailto:[EMAIL PROTECTED]]
> Sent: 5. april 2001 14:41
> To: [EMAIL PROTECTED]
> Subject: User registry's Userid and Password
> Importance: High
>
>
> Hi,
> Is there a way to access the OS's user registry and get the
> login id and
> password?
> In the ejbcreate method, I want to validate a user id and
> password against
> the OS's
> user registry's user id and password... If the userid and
> password do not
> match or if
> the user id is not found, I want to throw an exception and
> prevent the bean
> from being
> created..
>
> Regards,
> Krithika V
> Infosys Technologies Ltd
> 27,Bannergatta Road
> Bangalore - 79
> Tel- (O) 6588668 extn 1058
> email - [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: Lawrence Marsh [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2001 5:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB 1.1 and change of primary key values
>
>
> It seems to me that a primary key is immutable if and only if
> it serves as
> the object identity of the object whose state is represented
> by the row in
> the table to which the primary key points.
>
> So if your underlying data model supports these semantics
> then the primary
> key should indeed be immutable.
>
> The problem is that there is nothing in the relational world
> that forces you
> to adopt those semantics in your data model which is why in
> the relational
> world you can change the primary key. Hence why the primary
> key cannot be
> immutable in EJB.
>
> What would be interesting would be a mechanism within EJB to
> allow the bean
> provider to indicate these semantics in some way (for example
> throught the
> deployment descriptor) so that if a client did inadvertantly
> try to change
> the primary key the bean threw an exception.
>
> Cheers
>
> Lawrence
>
> > ----------
> > From: Jay Walters[SMTP:[EMAIL PROTECTED]]
> > Reply To: A mailing list for Enterprise JavaBeans development
> > Sent: 05 April 2001 13:30
> > To: [EMAIL PROTECTED]
> > Subject: Re: EJB 1.1 and change of primary key values
> >
> > Now in EJB 2.0 it would be much easier to implement
> immutable primary keys
> > in the CMP environment because of the abstract persistence
> schema. The
> > implementation class could throw an exception on change of
> primary key
> > fields. Do you guys think this should be done, or still left open?
> > Personally I'd like some option to go either way.
> >
> > Cheers
> > Jay
> >
> > -----Original Message-----
> > From: Cedric Beust
> > To: [EMAIL PROTECTED]
> > Sent: 4/4/01 4:57 PM
> > Subject: Re: EJB 1.1 and change of primary key values
> >
> > > From: Dave Wolf
> >
> > > Its an interesting question whether the pk is
> semantically immutable.
> > I
> > > dont see the spec every lay this out as a requirement.
> Secondly, if
> > we're
> > > persisting to an RDBMS which 90% of people are, the RDBMS does
> > actually
> > > allow updates on the PK field. So this PK mutability can occur
> > actually
> > > outside the EJB and bring about the same issue. Since
> neither EJB nor
> > the
> > > RDBMS enforce the relational models view that nothing
> changes the PK
> > value
> > > (a natural key) then how can we assume it is immutable?
> >
> > Because it doesn't make sense otherwise? :-)
> >
> > For example, Hashtable doesn't specify that
> equals()/hashCode() need to
> > return the same value after the object has been stored in
> the table, but
> > the
> > behavior is unpredictable if they don't.
> >
> > Not hard to extend this consideration to PK's.
> >
> > Be nice to the container and the container will be nice to you :-)
> >
> > --
> > Cedric
> >
> >
> ==============================================================
> ==========
> > ===
> > 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".
> >
>
>
> Visit us at http://www.clearstream.com
> Check out current job vacancies at
> http://www.clearstream.com/public/english/e_vacs.htm
>
> IMPORTANT MESSAGE
>
> Internet communications are not secure and therefore Clearstream
> International does not
> accept legal responsibility for the contents of this message.
>
> The information contained in this e-mail is confidential and
> may be legally
> privileged. It is
> intended solely for the addressee. If you are not the
> intended recipient,
> any disclosure,
> copying, distribution or any action taken or omitted to be
> taken in reliance
> on it, is
> prohibited and may be unlawful. Any views expressed in this
> e-mail are those
> of the
> individual sender, except where the sender specifically
> states them to be
> the views of
> Clearstream International or of any of its affiliates or subsidiaries.
>
> END OF DISCLAIMER
>
> ==============================================================
> =============
> 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".
_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com
===========================================================================
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".
