No, it would not take THAT much time.
Basically, a JDBC driver is 7 classes:
Driver
DataSource
Connection
Statement
PreparedStatement
CallableStatement
ResultSet
Only Statement would be truly needed in this case; and it's pretty
straigthforward.
Luckily you're not using ADSI to access Active Directory... it fails when
results are above 50 (instead of 1000).... MS's LDAP implementation has
severe glitches, and you may expect a lot more latency if the deployment
place is away from the PDC.
HTH
JP
> -----Original Message-----
> From: Jose González Gómez [mailto:[EMAIL PROTECTED]]
> Sent: Lunes, 05 de Febrero de 2001 5:56
> To: [EMAIL PROTECTED]
> Subject: Re: Reading LDAP data with EJBs
>
>
> Juan,
>
> Haven't thougt about that... maybe that could be a good
> solution, but
> we must keep the planning of this project and I think that
> would take us
> a long time.
>
> We are using Active Directory (this was client
> requirement) and we're
> accessing it with JNDI and the LDAP provider. The only significant
> problem we have found is that Active Directory fails when returning
> results for more than 1000 values in a single query. There seems to be
> some way to raise this value, but anyway is limited. If you try to use
> the methods that JNDI provide to control the number of
> objects returned
> you get an exception.
>
> Regards
> Jose
>
> Juan Lorandi (Chile) wrote:
>
> > José, have you ever considered to implement LDAP as a JDBC
> 2.0 driver? you
> > could there handle pooling, reuse
> > anything your want.
> >
> > BTW, won't you be using Active Directory? How do you access
> the LDAP? JNI &
> > ADSI?
> >
> > JP
> >
> >> -----Original Message-----
> >> From: Jose González Gómez [mailto:[EMAIL PROTECTED]]
> >> Sent: Viernes, 02 de Febrero de 2001 16:36
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Reading LDAP data with EJBs
> >>
> >>
> >> Ian,
> >>
> >> We are talking here about internal users. The directory
> >> I'm accessing
> >> keeps a copy of the structure of the organization I'm making the
> >> application for. As you say, I use this directory to give different
> >> access rights to each users regarding their absolute and relative
> >> position (a manager may authorize requests from employees under his
> >> organizational unit, but not in others). Anyway, there is some info
> >> specific to the application that cannot be kept in the
> directory, so I
> >> use my database for this purpose.
> >>
> >> Under this scenario it made sense for us to make some
> abstraction
> >> that would isolate us from LDAP and database access, and
> we thought of
> >> an entity bean representing our users. Keep in mind that
> we have also
> >> the application administrator role, that may change permissions for
> >> other users. Our entity bean provides us methods for all
> those things:
> >> asking for permissions, asking for relation between two employees,
> >> changing rights for an user,...
> >>
> >> Any thoughts about this?
> >>
> >> Regards
> >> Jose
> >>
> >> Ian McCallion wrote:
> >>
> >>> Jose González Gómez wrote:
> >>>
> >>>> I have an ejb named User that models an user
> interacting with my
> >>>> application. I need this as the actions this user may do in the
> >>>> application depend on his position in a directory I access
> >>>
> >> through LDAP.
> >>
> >>>> I keep some info I need about the user in a database, as
> >>>
> >> this info is
> >>
> >>>> not in the directory. This way the bean encapsulates all
> the needed
> >>>> access to LDAP and database.
> >>>>
> >>>> My problem is that in ejbLoad I need to connect to LDAP
> >>>
> >> and database,
> >>
> >>>> and in ejbStore I connect only to the database, as the
> >>>
> >> info in LDAP will
> >>
> >>>> never be changed in my application. I get the connections to the
> >>>> database from the connection pool of my app server, but
> there's no
> >>>> connection pooling for LDAP connnections, so the ejbLoad
> >>>
> >> operation takes
> >>
> >>>> a lot of time in making this connection time after time.
> >>>>
> >>>> What could I do? Should I make my own connection
> >>>
> >> pooling mechanism
> >>
> >>>> for LDAP? Is this possible under J2EE? Any other ideas
> about this?
> >>>
> >>>
> >>> There are two reasons to know who your users are:
> >>>
> >>> 1. So that you can limit their authority e.g. a supervisor,
> >>
> >> front-office
> >>
> >>> clerk and a backoffice clerk are allowed to do
> different things.
> >>>
> >>> 2. So that you can "know your users" e.g. give them
> access to their
> >>> account, keep track of what they like to do when
> >>
> >> visiting your site,
> >>
> >>> etc.
> >>>
> >>> Clearly 1. is related to internal users and 2. is related
> >>
> >> to customers or other
> >>
> >>> external users.
> >>>
> >>> I do not recommend keeping information about external users
> >>
> >> in LDAP as your
> >>
> >>> requirements for access to the information are almost
> >>
> >> certain to exceed LDAP's
> >>
> >>> ability to provide it.
> >>>
> >>> So use LDAP for internal users of your application, but
> >>
> >> keep ALL external user
> >>
> >>> data in a database only.
> >>>
> >>>
> >>> Ian McCallion
> >>> Alexis Systems Limited
> >>> Romsey, UK
> >>>
> >>>
> >> ==============================================================
> >> =============
> >>
> >>> 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".
>
===========================================================================
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".
