While I agree with you %120 about the advisability of remotable
datasources, one of the implementation possibilities for an application
container the spec mentioned appeared to me (on a brief reading) to be
remotable datasources. Possibly this is the motivation for Weblogic's
implementation?? I still don't know any reason you'd want to break the
architecture by using this.
david jencks
On 2001.07.08 02:23:50 -0400 danch wrote:
> 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
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
