On Apr 27, 2006, at 9:16 AM, Dain Sundstrom wrote:
I think we need to provide a non-persistent r/w global jndi tree
since there are so many apps that depend on it. In addition, I
think we need a way for users to provide a set of bindings (JNDI,
cos-naming, jaxr... really anything) to EJBs, RAs, and any GBean so
that the services they need are available where their application
expect.
I have been thinking about the binding problem for a while and just
haven't had time to work on it myself. I think we can do something
as simple as this for most services:
<gbean name="foo-binding"
class="org.apache.geronimo.naming.JndiBinding">
<reference name="object"><name>myService</...>
<attribute name="address">services/myService</...>
</...>
For J2EE services we want to bind, I think the xml above is way to
complex and we need to provide some syntactic sugar.
That's basically what I had in mind, but expressed more clearly and
concretely
thanks
david jencks
-dain
On Apr 27, 2006, at 1:22 AM, David Jencks wrote:
I'm not convinced this discussion has got to the hard parts
yet :-) I hope there turn out not to be any :-)
Please don't change stuff in the read-only java:comp/env context
since it is pretty much completely specified by the spec. Note
also that according to the spec a j2ee compliant app will only use
this jndi context, and only use the entries defined in the j2ee
deployment descriptors.
I think you can use a lot of the jndi infrastructure we already
have including the geronimo context and the references to jca
connection factories, ejbs, etc.
The missing part is how to get these references bound into your
context. One approach is to write gbeans that install a reference
when started and remove it when stopped. I would start by just
including these as plain gbeans in plans, and once that works
consider modifying the builders to add them automatically based on
xml in the geronimo plans.
An alternative might be to investigating using say Directory to
persist the references directly. I don't know enough about ldap
to know if this makes any sense at all.
thanks
david jencks
On Apr 26, 2006, at 11:56 PM, Manu George wrote:
Comments inline
On 4/26/06, Guillaume Nodet <[EMAIL PROTECTED]>
wrote: Looking more closely, it seems I was wrong.
Gbeans with a j2eeType=JCAManagedConnectionFactory have a
connectionFactoryInterface attribute that gives the name of the main
interface to use when binding the object to the JNDI context.
For EJB, GBeans with a j2eeType=StatelessSessionBean (or
EntityBean ...)
have attributes for the home and business interfaces.
So i guess it should be ok.
great
Another way to handle that would be to bind the resource to the
global
JNDI tree when the resource is created: each configuration would
contain
a list of gbeans to bind in the jndi tree when the configuration is
loaded. Else, we will need some listener to listen to gbeans
creation /
destruction so that we can bind / unbind them from the global
jndi context.
Binding the resource during creation seems to be the simpler way.
But what about the next time the server starts up. How is the
context initialised? Do we populate during startup of each
resource or application again or is persistence used in some way?
In the case of listeners the above problem won't arise.
A few questions:
* I' m wondering how the global JNDI context will coexist with the
existing ENC context, especially if the global jndi context is
read-write ... Maybe there is no need for a local jndi context ...
Yes that is a question i also have :-) . The local jndi context
allows us to have app specific contexts and this has some
advantages. A global jndi also has some advantages. Probably by
default we can use the local context and if the user specifies a
custom factory the global one or vice versa.
* what is the purpose of the jndiname property ? If this is the
key for
a gbean in the jndi tree, I thought we could use the name
attribute of
the gbean: "jdbc/TradeDataSource" , "jms/QueueConnectionFactory".
These names can also be TradeDatasource so then we may need to
add jdbc and if jdbc is there in the name as you mentioned do we
need to add jdbc to the name or not. These are a few issues which
made me propose the jndiName property .
* what about conflicting names for JCA resources... currently
there is
nothing to prevent deploying JCA resource (or other resources
that would
be bound to jndi) with the same name
I think deployment should fail with an resource already bound
exception. Not sure if this or any other validation is
implemented for the local context.
Thanks
Manu
