As much as I understand your explanation as to why JBoss doesnt support client lookup
of Datasource objects, Section 6.9 JNDI 1.2 requirements clearly states that "a J2EE
product must make available in the application specific namespace - EJBHome objects,
JTA User Transaction objects, JDBC API datasource objects........". So Weblogic
(Villain or otherwise !!!!!) does have a reason to expose the namespace to other
processes.
--
On Sat, 07 Jul 2001 21:24:55
danch wrote:
>Frank Marx wrote:
>
>> Hi,
>>
>> the question was why I cannot do it ? The question was not why I want to do
>> this without using EJB,
>> the challenge was to find out how can I use JNDI to do that from a
>> standalone JAVA Client
>> which accesses a JNDI Service.
>>
>> But as far as I know now it is possible, because the use of JNDI is not
>> bound to EJB.
>>
>>
>
>(sighs...again)
>
>This might go into more detail than you really wanted, but when you
>start asking 'why' that'll happen.
>
>There are two reasons that you can't look up datasources from outside
>the VM they exist in in JBoss.
>
>1. JBoss binds them under the 'java:' context for its own use. This
>context isn't accessable outside of the VM that it's created in.
>Weblogic (the usual vilain when people are trying to do this) puts
>datasources at 'whateverINamedIt' - in the default, global level where
>they are accessable to other processes.
><technical>Your earlier message mentioned (paraphrasing here) that for
>an EJB's use they'll be bound under 'java:comp/env'. The DataSource
>isn't actually bound at 'java:comp/env/jdbc/whatever' - there's a Link
>object that's bound there that points to wherever the actual datasource
>is bound. Weblogic does something very similiar, except that it puts the
>actual datasource under 'whatever' where JBoss puts in at
>'java:/whatever'.</technical>
>
>2. The really important reason and why #1 is there: DataSources aren't
>remote objects. Weblogic (the usual villain when people are trying to do
>this) actually hands out RmiDataSource (or something like that) objects,
>which are remotable and either put a remote invocation facade around the
>datasource, or just duplicate the code into the calling VM. I'm not sure
>which way they do it and I'm really not interested in duplicating it.
>The wisdom of doing either is debatable at best.
>
>-danch
>
>
>_______________________________________________
>JBoss-user mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-user
>
Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
