[
https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-5025.
--
Resolution: Fixed
has been resolved. close it.
> New module/app/global jndi contexts in javae
[
https://issues.apache.org/jira/browse/GERONIMO-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rex Wang closed GERONIMO-5066.
--
Resolution: Fixed
has been resolved. close it.
> Java EE 6 Global JNDI enhancme
in client container to do global jndi lookup.
>
>
> Key: GERONIMO-6008
> URL: https://issues.apache.org/jira/browse/GERONIMO-6008
> Project: Geronimo
>
t; Java EE 6 Global JNDI enhancments
> -
>
> Key: GERONIMO-5066
> URL: https://issues.apache.org/jira/browse/GERONIMO-5066
> Project: Geronimo
> Issue Type: Improvement
> Security
etting it committed to svn.
> Java EE 6 Global JNDI enhancments
> -
>
> Key: GERONIMO-5066
> URL: https://issues.apache.org/jira/browse/GERONIMO-5066
> Project: Geronimo
> Issue Type: Improvement
probably have to handle global DataSources vs global EJB
lookups differently.
For the non-global JNDI lookups the AppClient would use the Geronimo built JNDI
and that would have all the datasource, jms connection factory, topic, queue,
and other resources bound into it. The EJB names were built by
Here are what I tried:
1, use openejb remote jndi system to bind DS object with moduleId
"openejb/global". I added a DataSource service tracker in EjbDaemonGBean
to listen DS service to complete this step.
2, I tried to use fall back to remoteInitialContext lookup in RootContext.
3, I found
use openejb remote jndi system in client container to do global jndi lookup.
Key: GERONIMO-6008
URL: https://issues.apache.org/jira/browse/GERONIMO-6008
Project: Geronimo
now, correct?
> New module/app/global jndi contexts in javaee 6 spec
>
>
> Key: GERONIMO-5025
> URL: https://issues.apache.org/jira/browse/GERONIMO-5025
> Project: Geronimo
>
5117) moves jndi support directly into Modules
and straightens out when contexts are shared between submodules and ears and
modules.
> New module/app/global jndi contexts in javaee 6 spec
>
>
> Key: GERONIMO-5025
>
k in openejb.
> New module/app/global jndi contexts in javaee 6 spec
>
>
> Key: GERONIMO-5025
> URL: https://issues.apache.org/jira/browse/GERONIMO-5025
> Project: Geronimo
>
for jndi configuration in application.xml
> New module/app/global jndi contexts in javaee 6 spec
>
>
> Key: GERONIMO-5025
> URL: https://issues.apache.org/jira/browse/GERONIMO-5025
>
means for jta.
> Java EE 6 Global JNDI enhancments
> -
>
> Key: GERONIMO-5066
> URL: https://issues.apache.org/jira/browse/GERONIMO-5066
> Project: Geronimo
> Issue Type: Improvement
>
[
https://issues.apache.org/jira/browse/GERONIMO-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reassigned GERONIMO-5066:
--
Assignee: David Jencks
> Java EE 6 Global JNDI enhancme
app/global jndi contexts in javaee 6 spec
>
>
> Key: GERONIMO-5025
> URL: https://issues.apache.org/jira/browse/GERONIMO-5025
> Project: Geronimo
> Issue Type: Sub-task
>
Java EE 6 Global JNDI enhancments
-
Key: GERONIMO-5066
URL: https://issues.apache.org/jira/browse/GERONIMO-5066
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues
text setup to a different object since jsf
needs to be set up before the web app. Both the myfaces instance construction
service and the web context now have a reference to the jndi object.
> New module/app/global jndi contexts in javaee
the global context available to app clients.
Also we could probably have a urlHandler for jca: and ger: contexts. What we
used to do was bogus, treating the "scheme" part as a name component.
> New module/app/globa
New module/app/global jndi contexts in javaee 6 spec
Key: GERONIMO-5025
URL: https://issues.apache.org/jira/browse/GERONIMO-5025
Project: Geronimo
Issue Type: New Feature
Security
certainly before 2.1.3
> Bind JDBC DataSource to Global JNDI
>
>
> Key: GERONIMO-2973
> URL: https://issues.apache.org/jira/browse/GERONIMO-2973
> Project: Geronimo
> Issue Type: Sub-task
616570.
There appear to be an unrelated NPE during shutdown from the java:comp context
being unbound, but I'm not sure how to fix that.
> Auto bind resources to Global JNDI
> --
>
> Key: GERONIMO-2971
> URL: https
ore flexible auto-bind into global jndi?
> ---
>
> Key: GERONIMO-3476
> URL: https://issues.apache.org/jira/browse/GERONIMO-3476
> Project: Geronimo
> Issue Type: New Feature
>
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reopened GERONIMO-2971:
unbind on app stop doesn't work right
> Auto bind resources to Glo
into a global context based on their abstract name and I
think the jndi-name values. There should be info log messages indicating where
they end up. I don't think we can really bind anything directly at the root
due to the likelyhood of collisions.
> Auto bind resources to
mespace" so you cant put these under "java:" or "ger:". I put them
under "jca:"
- The console spits out a lot of log errors when you view the jndi tree.
> Auto bind resources to Global JNDI
> --
>
> Key:
been assigned, will EJBs be bound to a Global JNDI
context using their {{}} and {{}} values as
specified in the {{openejb-jar.xml}}?
> Auto bind resources to Global JNDI
> --
>
> Key: GERONIMO-2971
> URL: https://issues.apa
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reassigned GERONIMO-2971:
--
Assignee: David Jencks
> Auto bind resources to Global J
maybe more flexible auto-bind into global jndi?
---
Key: GERONIMO-3476
URL: https://issues.apache.org/jira/browse/GERONIMO-3476
Project: Geronimo
Issue Type: New Feature
Security Level
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-2971:
---
Fix Version/s: 2.1
2.0.x
> Auto bind resources to Global J
Got it resolved. Needed to start the openejb-corba-deployer.
Thanks
Manu
On 8/1/07, Manu George <[EMAIL PROTECTED]> wrote:
> Hi,
> How can I access ejbs over CORBA in Geronimo 2.0? On specifying
> the TSS configs as in 1.1, I was getting an error saying there is no
> builder configured for
Hi,
Sorry for the misleading subject in the previous mail. Actually I also
checked out the Global JNDI stuff in sandbox. Looks like it needs some
changes to work with 2.0. It doesn't compile as is now.
Regards
Manu
On 8/1/07, Manu George <[EMAIL PROTECTED]> wrote:
> Hi,
>
Hi,
How can I access ejbs over CORBA in Geronimo 2.0? On specifying
the TSS configs as in 1.1, I was getting an error saying there is no
builder configured for namespace
http://openejb.apache.org/xml/ns/corba-tss-config-2.1 during
deployment. Does anyone know why this is happening. I gave dep
On Jun 21, 2007, at 8:18 AM, David Jencks wrote:
This is pretty much speculation on my part, I haven't tried
anything to see if it already is implemented...
Openejb has a nice global jndi context for all the ejbs, but I
don't think its bound into the geronimo global jndi
This is pretty much speculation on my part, I haven't tried anything
to see if it already is implemented...
Openejb has a nice global jndi context for all the ejbs, but I don't
think its bound into the geronimo global jndi space. I suspect it's
possible to get it using
[
https://issues.apache.org/jira/browse/GERONIMO-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated GERONIMO-2973:
---
Component/s: naming
> Bind JDBC DataSource to Global J
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated GERONIMO-2971:
---
Component/s: naming
> Auto bind resources to Global J
(was: Dain Sundstrom)
Committed revision 524985.
Thanks!
> Bind JavaMail Session to Global JNDI
>
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
>
ion to Global JNDI
>
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
> Project: Geronimo
> Issue Type: Sub-task
> Security Leve
[
https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher M. Cardona updated GERONIMO-2972:
-
Attachment: testjndi.war
> Bind JavaMail Session to Global J
for doing JNDI lookup and see if an object is bound
to a given name.
> Bind JavaMail Session to Global JNDI
>
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
> P
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483716
]
Aman Nanner commented on GERONIMO-2971:
---
I have attempted to integrate the Global JNDI plugin into my 1.2
.
> Auto bind resources to Global JNDI
> --
>
> Key: GERONIMO-2971
> URL: https://issues.apache.org/jira/browse/GERONIMO-2971
> Project: Geronimo
> Issue Type: New Feature
> Security Leve
to Global JNDI
>
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
>
Bind JDBC DataSource to Global JNDI
Key: GERONIMO-2973
URL: https://issues.apache.org/jira/browse/GERONIMO-2973
Project: Geronimo
Issue Type: Sub-task
Security Level: public (Regular issues
Bind JavaMail Session to Global JNDI
Key: GERONIMO-2972
URL: https://issues.apache.org/jira/browse/GERONIMO-2972
Project: Geronimo
Issue Type: Sub-task
Security Level: public (Regular issues
Auto bind resources to Global JNDI
--
Key: GERONIMO-2971
URL: https://issues.apache.org/jira/browse/GERONIMO-2971
Project: Geronimo
Issue Type: New Feature
Security Level: public (Regular issues
x27;s implementaiton has been in 1.2 and 2.0 for a long time. auto-binding
needs a different jira.
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: https://issues.apache.org/jira/browse/GERONIMO-2153
> Project: Geronimo
>
hat I know if is implementing these with Global JNDI, it
becomes a defacto standard and requirement for Jee5. Moreover,
I believe that our GlobalJNDI names must be simple normal names
(i.e, not encoded abstract names) you would see in other
application servers, because users will annotate
On Feb 7, 2007, at 9:54 AM, Dain Sundstrom wrote:
On Feb 7, 2007, at 8:01 AM, David Jencks wrote:
The problem is our users' applications will make use of mapped
name in other application servers, and since every application
server that I know if is implementing these with Global JND
On Feb 7, 2007, at 8:01 AM, David Jencks wrote:
The problem is our users' applications will make use of mapped
name in other application servers, and since every application
server that I know if is implementing these with Global JNDI, it
becomes a defacto standard and requirement for
On Feb 6, 2007, at 5:34 PM, Dain Sundstrom wrote:
Jee5 makes extensive use of Global JNDI for references.
Specifically, the following use Global JNDI:
It looks to me as if these all mention global jndi but saying they
"use" global jndi seems like an exaggera
So do you agree that Global JNDI is the defacto required
implementation for these and other similar entries?
I think you're assessment is spot on.king in the Global JNDI names
that they expect to work in our application server.
On 2/7/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
So do you agree that Global JNDI is the defacto required
implementation for these and other similar entries?
Having read what you cited, I came to conclusion that if Global JNDI
is not a de facto standard yet it will surely be right
On 2/6/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
...
So do you agree that Global JNDI is the defacto required
implementation for these and other similar entries?
Sounds like it to me.
Thanks,
Aaron
Jee5 makes extensive use of Global JNDI for references.
Specifically, the following use Global JNDI:
@Resource.mappedName()
This mapped name is often a global JNDI name, but may be a name of
any form.
@EJB.mappedName()
This mapped name is often a global JNDI name, but may be a name of
WARN message from Global JNDI
-
Key: GERONIMO-2673
URL: http://issues.apache.org/jira/browse/GERONIMO-2673
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components
was hardcoding jndi properties that
are already set by the NamingProperties gbean.
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: http://issues.apache.org/jira/browse/GERONIMO-2153
> Project: Geronimo
> Is
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
David Jencks reassigned GERONIMO-2153:
--
Assignee: David Jencks (was: Dain Sundstrom)
> Global JNDI
> ---
>
> Key: GERONIMO-2153
>
ty. There's
a disabled unit test in TestEnvironmentEntryBuilder that suggests that
currently it is not possible to look it up.
- Decide on good syntax in connector and ejb plans to specify bindings into
global jndi and possibly other naming systems.
> Global JNDI
> ---
>
&g
think the steps are:
- change openejb remote jndi to use xbean naming classes
- remove unused geronimo naming classes (such as geronimo context)
- change g. to use xbean ImmutableContext instead of EnterpriseNamingContext
- move the classes from sandbox to geronimo-naming
> Global J
Cool! Thx,
--jason
On Sep 29, 2006, at 5:19 PM, Dain Sundstrom wrote:
see revision 451423 (http://svn.apache.org/viewvc?
view=rev&revision=451423)
-dain
On Sep 29, 2006, at 1:40 PM, Jason Dillon wrote:
Can we plz use the new m2 layout?
--jason
see revision 451423 (http://svn.apache.org/viewvc?
view=rev&revision=451423)
-dain
On Sep 29, 2006, at 1:40 PM, Jason Dillon wrote:
Can we plz use the new m2 layout?
--jason
cate bindings to the same name - basically
we create a wating queue and when the current binding unregisters
the next in the queue gets registered.
Fixed several bugs in cleanup code.
Added:
geronimo/sandbox/plugins/global-jndi/src/java/org/apache/
geronimo/gjndi/binding/
geronimo/san
up some very rudimentary instruction on how to
manually install it (need to figure out how to automate this) here:
http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI
+Plugin
Anyway, while writing this code I ended up writing a thread safe
context which althought it isn&#
install
it (need to figure out how to automate this) here:
http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI+Plugin
Anyway, while writing this code I ended up writing a thread safe
context which althought it isn't publicly modifiable can internally
modify itself. I also wr
figure out how to automate this) here:
http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI+Plugin
Anyway, while writing this code I ended up writing a thread safe
context which althought it isn't publicly modifiable can internally
modify itself. I also wrote a subclass of
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
Dain Sundstrom reassigned GERONIMO-2153:
Assignee: Dain Sundstrom
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: http://is
On Aug 7, 2006, at 9:40 PM, Manish Satwani wrote:Hi All,Please tell me How can I give JNDI Name of Database pool in Geronimo 1.1 , there is no way to define from the console.How can I give in deployment PlanThere is no global jndi in geronimo 1.1: you have to use the j2ee java:comp/env jndi
Hi Manish,
You need to give a resource reference in the deployment
plan. Geronimo does not have a Global JNDI context currently since its
not mandated by the J2EE spec. So you will be able to lookup and
access the datasource from JNDI only within the module in which it is
defined. The
Hi All,Please tell me How can I give JNDI Name of Database pool in Geronimo 1.1 , there is no way to define from the console.How can I give in deployment PlanThanks Manish Satwani
Senior Software EngineerAceva Technologies | Unlock Your Working CapitalA-1501, Signature Towers - I,South City, Gurgao
ppropriate GBean.
>
> http://issues.apache.org/jira/browse/GERONIMO-2153
>
> thanks
> david jencks
>
> On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote:
>
> > Hi David,
> >
> > I tried this and it works for Custom Resource Adapters. There is still
>
till
> a problem for Registering GBeans in Global JNDI through the builder (
> ServiceConfigBuilder ). The Builder is a part of
> geronimo-gbean-deployer plan which is parent of j2ee-deployer. The
> geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
> access in Ser
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
Krishnakumar B updated GERONIMO-2153:
-
Attachment: ConnectorJNDIBindingGBean.java
GBean that binds and unbinds Connectors to JNDI
> Global JNDI
> ---
>
>
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
Krishnakumar B updated GERONIMO-2153:
-
Attachment: GeronimoGlobalContext.java
Context implementation
> Global JNDI
> ---
>
> Key: G
.
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: http://issues.apache.org/jira/browse/GERONIMO-2153
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Comp
mar B wrote:
Hi David,
I tried this and it works for Custom Resource Adapters. There is still
a problem for Registering GBeans in Global JNDI through the builder (
ServiceConfigBuilder ). The Builder is a part of
geronimo-gbean-deployer plan which is parent of j2ee-deployer. The
geronimo-naming jar
Hi David,
I tried this and it works for Custom Resource Adapters. There is still
a problem for Registering GBeans in Global JNDI through the builder (
ServiceConfigBuilder ). The Builder is a part of
geronimo-gbean-deployer plan which is parent of j2ee-deployer. The
geronimo-naming jars are
have any questions about this.
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: http://issues.apache.org/jira/browse/GERONIMO-2153
> Project: Geronimo
> Type: New Feature
> Security: public(Regular issues)
> Components: namin
odule of geronimo. We are planning to change this by creating a separate module for global jndi and then adding it as a dependency in the configuration that is getting deployed. This will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans
Hi,
The problem we are
facing regarding adapters is because the binding gbeans were added to
the naming module of geronimo. We are planning to change this by
creating a separate module for global jndi and then adding it as a
dependency in the configuration that is getting deployed. This
s
> into Global JNDI and the builder can then add it to geronimo: Context.
> This is not implemented yet. Currently if we deploy a connector it
> gets in global jndi.
I might've misunderstood it, but isn't Global JNDI == geronimo:
context == global: context? If so, why is th
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
Krishnakumar B updated GERONIMO-2153:
-
Attachment: jndi-project.zip
Initial Draft for review.
> Global JNDI
> ---
>
> Key: GERONIMO-2153
>
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ]
Krishnakumar B updated GERONIMO-2153:
-
Patch Info: (was: [Patch Available])
> Global JNDI
> ---
>
> Key: GERONIMO-2153
> URL: http://issues.
Global JNDI
---
Key: GERONIMO-2153
URL: http://issues.apache.org/jira/browse/GERONIMO-2153
Project: Geronimo
Type: New Feature
Security: public (Regular issues)
Components: naming
Versions: 1.2
Reporter: Krishnakumar B
Implementing
On 6/23/06, Krishnakumar B <[EMAIL PROTECTED]> wrote:
The plan needs to have some XML Tag to say this resource needs to gets
into Global JNDI and the builder can then add it to geronimo: Context.
This is not implemented yet. Currently if we deploy a connector it
gets in global jnd
Could you raise a JIRA and attach the patch for review ?Thanks,Guillaume NodetOn 6/23/06, Krishnakumar B <
[EMAIL PROTECTED]> wrote:hi,We ( Me & Manu ) have created a implementation of global JNDI based
on the feedback received on the dev list.It works like this.* The implement
hi,
We ( Me & Manu ) have created a implementation of global JNDI based
on the feedback received on the dev list.
It works like this.
* The implementation uses GeronimoRootContext and ReadOnlyContext
thats part of naming module to create the root context ( geronimo: ).
The Contex
Thanks for the feedback and inputs.
Regards
Krishnakumar
On 5/24/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On May 23, 2006, at 5:19 PM, David Jencks wrote:
>
> On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
>
>> Hi,
>>
>> I have a few doubts related
On May 23, 2006, at 5:19 PM, David Jencks wrote:
On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
Hi,
I have a few doubts related to implementation of global jndi.
* Currently we have java:comp/env stored in Local JNDI. In Global
JNDI
should objects be bound using a different
On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
Hi,
I have a few doubts related to implementation of global jndi.
* Currently we have java:comp/env stored in Local JNDI. In Global JNDI
should objects be bound using a different namespace e.g) java: or
java:global?
IIUC java: is reserved
Hi,
I have a few doubts related to implementation of global jndi.
* Currently we have java:comp/env stored in Local JNDI. In Global JNDI
should objects be bound using a different namespace e.g) java: or
java:global?
* When we implement global JNDI we have some entries in Global and All
entries
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
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
he jndi tree when the configuration isloaded. 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 u
would contain
a list of gbeans to bind in the jndi tree when the configuration isloaded. 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. Bu
> mapped to
> >>this JNDI reference (and to create a proxy ?).> >>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.> >>But I guess this is irrelevant if the objects are bound when they
> are> >>created.> >>> >>Bt
(and to create a proxy ?).
>>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.
>>But I guess this is irrelevant if the objects are bound when they
are
>>created.
>>
>>Btw, should the global JNDI tree be read-only, or read-write ?
>>IMHO, a read-writ
EntityBean ...)
have attributes for the home and business interfaces.
So i guess it should be ok.
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
a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.
But I guess this is irrelevant if the objects are bound when they are
created.
Btw, should the global JNDI tree be read-only, or read-write ? IMHO, a
read-write global JNDI tree would be very usefull.
Cheers,
Guillaume Nodet
Manu
o create a proxy ?).>>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.>>But I guess this is irrelevant if the objects are bound when they are>>created.
>>>>Btw, should the global JNDI tree be read-only, or read-write ?>>IMHO, a read-write global JNDI t
1 - 100 of 124 matches
Mail list logo
