Yes and no,
Yes: a service provider for naming could perfectly take the reference we
pass to it and persist them (if able). Here I am talking about the "global"
directory, i.e. your naming file system (I like to think of it as a
distributed filesystem) can expose the global references, this is
transparent to jboss and j2ee "en general", i.e. orthogonal, should work.
However: j2ee defines the "java:" namespace which in the case of beans is a
projection of the global namespace (or filesystem) to a given bean. Think
of it as a Unix filesystem where you only see the files you have r access
to, you don't see the rest. In other words unlike Unix you won't even *see*
in the sense of ls -al the files or objects in the namespace because java:
is scoped for a particular bean.
Bottom line: jboss needs to keep the java: association in the container and
does calls to the naming provider (in our case jnp) to set the scoped and
projected view of the namespace to the bean. That requires acces to the
root setting and we don't do that with LDAP. If there is a way to access
the equivalent of "setRoot(beanNamingRoot)" on the LDAP provider then we
could code it (trivial) but it needs to be done. If there are takers of
that, i will gladly kick a sub project on it.
As a final note I would like to point out that examples like RMH use the
java: namespace as a global namespace *even for clients* and that the scoped
namespace on beans goes counter of that. In other words java: has different
meanings for beans and clients (clients = global, beans = scoped) .If java:
and the default namespace are equivalent (i.e. Unix like) then it is a
matter of enforcing security access ala unix (rwx permissions) as opposed to
what we do now which is enforcing the visibility which is more powerful (and
light, you look up on a smaller namespace). For that to work we would still
need to rely on the secure access to these filesystems and that is either in
LDAP either in a wrapper.
marc
> > Background...
> >
> > I would like to have JBoss store its object references in a
> Win2000 Active
> > Directory via a JNDI LDAP service provider. I would also like
> to have my
> > client applications access these same object references via a JNDI LDAP
> > service provider.
> >
> > Question 1. Does JBoss support an LDAP JNDI Service Provider?
> >
> > Question 2. Can JBoss support the scenario I have described above?
> >
> > Question 3. If the answer to Question 2 is "Yes", what are the general
> > steps to accomplish the scenario?
> >
> > Note: I tried setting the jndi.properties file as shown below:
> >
> > java.naming.factory.initial com.sun.jndi.ldap.LdapCtxFactory
> > java.naming.provider.url ldap://myldaphost:389
> > java.naming.factory.url.pkgs=org.jboss.naming
> >
> > when I did this, JBoss reported the following on startup:
> >
> > [Webserver] Initializing
> > [Webserver] Initialized
> > [Hypersonic] Initializing
> > [Hypersonic] Server 1.4 is running
> > [Hypersonic] Database started
> > [Hypersonic] Initialized
> > [Naming] Initializing
> > [Naming] Naming started on port 1099
> > [Naming] Initialized
> > [Transaction manager] Initializing
> > [Transaction manager] Initialization failed
> > [Transaction manager] javax.naming.directory.NoSuchAttributeException:
> > [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090909,
> comment: Error in
> > attribute conversion operation, data 0, v893 ]; remaining name
> > 'TransactionManager'
> > [Transaction manager] at
> com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown
> > Source)
> > [Transaction manager] at
> > com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
> > [Transaction manager] at
> > com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
> > [Transaction manager] at com.sun.jndi.ldap.LdapCtx.c_bind(Unknown
> > Source)
> > [Transaction manager] at com.sun.jndi.ldap.LdapCtx.c_bind(Unknown
> > Source)
> > [Transaction manager] at
> > com.sun.jndi.toolkit.ctx.ComponentContext.p_bind(Unknown Source)
> > [Transaction manager] at
> > com.sun.jndi.toolkit.ctx.PartialCompositeContext.bind(Unknown Source)
> > [Transaction manager] at
> > com.sun.jndi.toolkit.ctx.PartialCompositeContext.bind(Unknown Source)
> > [Transaction manager] at javax.naming.InitialContext.bind(Unknown
> > Source)
> > [Transaction manager] at
> >
> org.jboss.tm.TransactionManagerService.initService(TransactionManagerServi
> > ce.java:76)
> > [Transaction manager] at
> > org.jboss.util.ServiceMBeanSupport.init(ServiceMBeanSupport.java:64)
> > [Transaction manager] at
> >
> org.jboss.util.ServiceMBeanSupport.preRegister(ServiceMBeanSupport.java:15
> > 4)
> > [Transaction manager] at
> java.lang.reflect.Method.invoke(Native Method)
> > [Transaction manager] at
> > javax.management.MBeanServer.preRegisterInvoker(MBeanServer.java:2253)
> > [Transaction manager] at
> > javax.management.MBeanServer.createMBean(MBeanServer.java:505)
> > [Transaction manager] at
> > javax.management.loading.MLet.getMBeansFromURL(MLet.java:368)
> > [Transaction manager] at
> > javax.management.loading.MLet.getMBeansFromURL(MLet.java:208)
> > [Transaction manager] at org.jboss.Main.<init>(Main.java:111)
> > [Transaction manager] at org.jboss.Main.<init>(Main.java:86)
> > [Transaction manager] at org.jboss.Main$1.run(Main.java:76)
> > [Transaction manager] at
> > java.security.AccessController.doPrivileged(Native Method)
> > [Transaction manager] at org.jboss.Main.main(Main.java:67)
> > [DataSource] Initializing
> > [DataSource] Initialization failed
> >
> > Thanks!
> >
> > Mark H. McLain
> > Systems Developer
> > Sybron Laboratory Products Corporation (SLPC)
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
