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
> >
>
>
> 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
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
