And if we had an Application Client Container it would remove any of my
complaints about the business of remotable datasources - they wouldn't
be remote anymore.
David Jencks wrote:
> Please state where your reference is from.
>
> I consulted the j2ee-1_3-pfd3-spec.pdf which makes it quite clear that
> Application Clients for j2ee apps are running in an Application Client
> Container providing various services, such as JDBC DataSource lookup. See
> for instance section 9. Jboss is an ejb container, not an application
> client container. I suspect you could easily construct an application
> client container using pieces of jboss (basically the jmx backbone and
> whatever services you want, like jdbc DataSource access), however this is
> not currently part of jboss. Running an app in a separate vm does not mean
> it is in an Application Client Container.
>
> Incidently 9.3 states that a j2ee product is not required to provide a JTA
> UserTransaction object fro use by application clients.
>
> david jencks
>
> On 2001.07.08 00:59:57 -0400 ejb gsekar wrote:
>
>> 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
