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".
