[jira] [Closed] (GERONIMO-5066) Java EE 6 Global JNDI enhancments
[ 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 enhancments - Key: GERONIMO-5066 URL: https://issues.apache.org/jira/browse/GERONIMO-5066 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ 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 javaee 6 spec Key: GERONIMO-5025 URL: https://issues.apache.org/jira/browse/GERONIMO-5025 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6008) use openejb remote jndi system in client container to do global jndi lookup.
[ https://issues.apache.org/jira/browse/GERONIMO-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang resolved GERONIMO-6008. --- Resolution: Fixed Fix Version/s: 3.0 fixed. 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 Issue Type: Task Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 3.0 Reporter: Shawn Jiang Assignee: Shawn Jiang Fix For: 3.0 See https://issues.apache.org/jira/browse/OPENEJB-1596 and discussion on http://apache-geronimo.328035.n3.nabble.com/DISCUSSION-How-to-bring-server-global-app-context-to-applient-context-td3054685.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5066) Java EE 6 Global JNDI enhancments
[ https://issues.apache.org/jira/browse/GERONIMO-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055358#comment-13055358 ] David Jencks commented on GERONIMO-5066: I have a working solution for exposing server side global datasources to app clients based on: 1. representing datasource definitions as naming References 2. using an ObjectFactory service using aries jndi to turn these definitions into the osgi services needed to supply the datasource from jndi lookups 3. copying all the global jndi entries into the openejb global tree 4. using the openejb jndi transport to pull the datasource Reference back to the app client where it can be set up using step (2) just like all other datasources. This is currently in the osgi-friendly code I periodically push. I'll work on getting 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 Security Level: public(Regular issues) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5066) Java EE 6 Global JNDI enhancments
[ https://issues.apache.org/jira/browse/GERONIMO-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056189#comment-13056189 ] David Jencks commented on GERONIMO-5066: pushed to svn in rev 1140357 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) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSSION] How to bind and locate global JNDI for datasource.
On Jun 17, 2011, at 3:25 AM, Shawn Jiang wrote: 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 that JndiRequestHandler can only handle org.apache.commons.dbcp.BasicDataSource type DS. It can't handle TranqlDataSource used in geronimo. My gut says we'll 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 Geronimo but were really just links that resulted in the OpenEJB JNDI being used to look those up via different names (the openejb/Deployment names). Seems like we need a way to leverage that here. Is this code running in the AppClient container or as a bare plain java se client? -David
[DISCUSSION] How to bind and locate global JNDI for datasource.
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 that JndiRequestHandler can only handle org.apache.commons.dbcp.BasicDataSource type DS. It can't handle TranqlDataSource used in geronimo. Any good idea ? -- Shawn
[jira] [Created] (GERONIMO-6008) use openejb remote jndi system in client container to do global jndi lookup.
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 Issue Type: Task Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 3.0 Reporter: Shawn Jiang Assignee: Shawn Jiang See https://issues.apache.org/jira/browse/OPENEJB-1596 and discussion on http://apache-geronimo.328035.n3.nabble.com/DISCUSSION-How-to-bring-server-global-app-context-to-applient-context-td3054685.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901396#action_12901396 ] Rick McGuire commented on GERONIMO-5025: I believe this work is complete 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 Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12874475#action_12874475 ] David Jencks commented on GERONIMO-5025: rev 950397 (see also 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 URL: https://issues.apache.org/jira/browse/GERONIMO-5025 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870212#action_12870212 ] David Jencks commented on GERONIMO-5025: rev 947211 moves around jndi configuration in openejb so that the jndi enc context in openejb is an immutable federation of the global, app, module, and comp context constructed by geronimo, and an additional writable comp context that openejb can bind stuff like TimerService and EJBContext into. Injections now seem to work 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 Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868788#action_12868788 ] David Jencks commented on GERONIMO-5025: Rev 945814 and 945820 add support 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 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5066) Java EE 6 Global JNDI enhancments
[ 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 enhancments - Key: GERONIMO-5066 URL: https://issues.apache.org/jira/browse/GERONIMO-5066 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5066) Java EE 6 Global JNDI enhancments
[ https://issues.apache.org/jira/browse/GERONIMO-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865420#action_12865420 ] David Jencks commented on GERONIMO-5066: This is mostly implemented. Further work is needed to make the openejb and geronimo naming systems work better together, and to figure out exactly what is supposed to be exposed in the app client and what global means there. Also whether global datasources need to be redefined on the app client and what that 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 Security Level: public(Regular issues) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Assignee: David Jencks Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire updated GERONIMO-5025: --- Issue Type: Sub-task (was: New Feature) Parent: GERONIMO-5066 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: Sub-task Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5066) Java EE 6 Global JNDI enhancments
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) Components: javaee6, Web Profile Affects Versions: 3.0 Reporter: Rick McGuire Fix For: 3.0 Enhancements for the java ee 6 global JNDI additions specified by JSR 316, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804196#action_12804196 ] David Jencks commented on GERONIMO-5025: rev 902527 moves web app jndi context 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 6 spec Key: GERONIMO-5025 URL: https://issues.apache.org/jira/browse/GERONIMO-5025 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803554#action_12803554 ] David Jencks commented on GERONIMO-5025: rev 901935 basically does the work described above. There aren't really any tests yet. More stuff to do: 1. detect if an entry is specified twice and object if it is specified differently. 2. find out what is meant for web apps about java:comp and java:module being the same 3. figure out if/how to get 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/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 Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
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 Level: public (Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2973) Bind JDBC DataSource to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2973. -- Resolution: Fixed Fix Version/s: 2.1.3 This was implemented a long time ago 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 Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Fix For: 2.1.3 Auto bind JDBC DataSource objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-2971) Auto bind resources to Global JNDI
[ 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 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) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assignee: David Jencks Fix For: 2.0.x, 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3476) maybe more flexible auto-bind into global jndi?
[ https://issues.apache.org/jira/browse/GERONIMO-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3476. -- Resolution: Duplicate So I did it this way when implementing GERONIMO-2971 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: public(Regular issues) Components: naming Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 A long time ago dain wrote some auto-bind-into global jndi gbeans for ejbs and resources. I never liked the idea much but with dblevins' idea of a jndi formatter and maybe an abstract name filter the idea is starting to seem more appealing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2971) Auto bind resources to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2971. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) Shutdown problem fixed in rev 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://issues.apache.org/jira/browse/GERONIMO-2971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assignee: David Jencks Fix For: 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2971) Auto bind resources to Global JNDI
[ 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 JNDI -- Key: GERONIMO-2971 URL: https://issues.apache.org/jira/browse/GERONIMO-2971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assignee: David Jencks Fix For: 2.0.x, 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2971) Auto bind resources to Global JNDI
[
https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562923#action_12562923
]
Aman Nanner commented on GERONIMO-2971:
---
Now that this JIRA item has been assigned, will EJBs be bound to a Global JNDI
context using their {{jndi-name}} and {{local-jndi-name}} values as
specified in the {{openejb-jar.xml}}?
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)
Components: naming
Affects Versions: 2.0-M5
Reporter: Christopher M. Cardona
Assignee: David Jencks
Fix For: 2.0.x, 2.1
We need a way to auto bind resources like JDBC DataSource, JavaMail Session,
EJB, etc. to Global JNDI namespace. This will allow the lookup of the said
resources without declaring resource references in the deployment plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2971) Auto bind resources to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2971. -- Resolution: Fixed Implemented based on Dain's work and inspired by David Blevins format idea for global ejb binding names and Tomasz Mazan's idea of filtering which resources to bind with a regexp on the name component of the abstract name. Rev 615514. There are a couple problems: - it appears that xbean naming doesn't allow more than one context for a nameInNamespace 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: GERONIMO-2971 URL: https://issues.apache.org/jira/browse/GERONIMO-2971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assignee: David Jencks Fix For: 2.0.x, 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2971) Auto bind resources to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562930#action_12562930 ] David Jencks commented on GERONIMO-2971: Hi Aman, Ejbs are already bound 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 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) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assignee: David Jencks Fix For: 2.0.x, 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3476) maybe more flexible auto-bind into global jndi?
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: public (Regular issues) Components: naming Affects Versions: 2.0.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 A long time ago dain wrote some auto-bind-into global jndi gbeans for ejbs and resources. I never liked the idea much but with dblevins' idea of a jndi formatter and maybe an abstract name filter the idea is starting to seem more appealing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2971) Auto bind resources to Global JNDI
[ 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 JNDI -- Key: GERONIMO-2971 URL: https://issues.apache.org/jira/browse/GERONIMO-2971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Fix For: 2.0.x, 2.1 We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Global JNDI
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 dependency only to the geronimo-corba-yoko configuration in the plan. Thanks Manu
Re: Global JNDI
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 namespace http://openejb.apache.org/xml/ns/corba-tss-config-2.1 during deployment. Does anyone know why this is happening. I gave dependency only to the geronimo-corba-yoko configuration in the plan. Thanks Manu
ejbs in 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 the appropriate jndi Properties in a new InitialContext(props) call, but I don't even know how to do that. I think it would be very convenient to bind the openejb context into geronimo's global context. I'm not entirely sure how to do this. One idea is to write a GBean implementing Context that delegates to SystemInstance.get().getComponent (ContainerSystem.class).getJNDIContext() and registers with geronimo's GlobalContextGBean to get bound (and presumably federated). Can anyone think of a better way? Perhaps another possibility is to write a GeronimoOpenejbContextGBean that is a subclass of IvmContext so it can register with the GlobalContextGBean, and also registers a ContainerSystem implementation with openejb's SystemInstance? This would avoid the delegation step. Is this already done and I just don't know about it? thanks david jencks
Re: ejbs in global jndi?
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 space. I suspect it's possible to get it using the appropriate jndi Properties in a new InitialContext(props) call, but I don't even know how to do that. I'd be: Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, org.apache.openejb.client.LocalInitialContextFactory); InitialContext ctx = new InitialContext(properties); As far as getting the ejb global context, this is the least volatile way and has remained pretty consistent across 0.x, 1.x, 2.x, and 3.x. Even the old package name org.openejb.client still works for backwards compatible reasons. I think it would be very convenient to bind the openejb context into geronimo's global context. I'm not entirely sure how to do this. One idea is to write a GBean implementing Context that delegates to SystemInstance.get().getComponent (ContainerSystem.class).getJNDIContext() and registers with geronimo's GlobalContextGBean to get bound (and presumably federated). Can anyone think of a better way? Perhaps another possibility is to write a GeronimoOpenejbContextGBean that is a subclass of IvmContext so it can register with the GlobalContextGBean, and also registers a ContainerSystem implementation with openejb's SystemInstance? This would avoid the delegation step. As far as how to actually get the context into the G Global JNDI Context, I'm not sure. Seems that context will ultimately delegate (federate) to this context. IIRC from talking with Dain about this when he was hacking on it is that there should be some way to bind another context in at a given path in the G Global context in some sort of factory-like here's my context, you deal with it sort of way. If there isn't, we should just add that. -David
[jira] Updated: (GERONIMO-2971) Auto bind resources to Global JNDI
[ 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 JNDI -- Key: GERONIMO-2971 URL: https://issues.apache.org/jira/browse/GERONIMO-2971 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2973) Bind JDBC DataSource to Global JNDI
[ 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 JNDI Key: GERONIMO-2973 URL: https://issues.apache.org/jira/browse/GERONIMO-2973 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: naming Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Auto bind JDBC DataSource objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom reassigned GERONIMO-2972: Assignee: Dain Sundstrom (was: Christopher M. Cardona) 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) Components: mail Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assigned To: Dain Sundstrom Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, sendmail.war, testjndi.war Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed GERONIMO-2972. Resolution: Fixed Fix Version/s: 2.0-M4 Assignee: Christopher M. Cardona (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 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: mail Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Fix For: 2.0-M4 Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, sendmail.war, testjndi.war Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher M. Cardona updated GERONIMO-2972: - Attachment: sendmail.war mailsession1-plan.xml GERONIMO-2972.patch Attached are the ff. files: 1. GERONIMO-2972.patch - tried it on trunk rev 522662. This patch will create the ger: context and all created JavaMail resource is bound to this context using the 'name' key property from the object name of the gbean. 2. mailsession1-plan.xml - a plan to create a test JavaMail resource. After deploying, you can access the resource using ger:/MailSession1. 3. sendmail.war - a webapp for sending test emails where you can specify the JNDI name of JavaMail session to use. 4. testjndi.war - a webapp 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 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: mail Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, sendmail.war Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ 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 JNDI Key: GERONIMO-2972 URL: https://issues.apache.org/jira/browse/GERONIMO-2972 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: mail Affects Versions: 2.0-M5 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, sendmail.war, testjndi.war Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2971) Auto bind resources to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483709 ] Aman Nanner commented on GERONIMO-2971: --- This feature is also badly needed for the Geronimo 1.x stream. 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) Affects Versions: 2.0 Reporter: Christopher M. Cardona We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2971) Auto bind resources to Global JNDI
[
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 sandbox so
that I can use the {{org.apache.geronimo.gjndi.binding.EjbBindings}} GBean to
auto-bind all my EJBs into JNDI. However, it seems as though that the
{{EjbBindings}} context itself does not get bound as a nested context to the
java: context, and so it is not accessible via JNDI.
I had tried modifying the EjbBindings class so that it would add itself to the
java: namespace using the following steps:
1) Accessing the top-level global context by calling
{{GlobalContextManager.getGlobalContext()}}.
2) Calling {{lookup( java: )}} on the global context to get the java:
{{WritableContext}}.
3) Adding the {{EjbBindings}} context to the java: {{WritableContext}}.
Unfortunately, once the java: {{WritableContext}} is bound to the
{{GlobalContext}}, it becomes unmodifiable, and so I can't bind anymore
contexts to it (presumable for security reasons).
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)
Affects Versions: 2.0
Reporter: Christopher M. Cardona
We need a way to auto bind resources like JDBC DataSource, JavaMail Session,
EJB, etc. to Global JNDI namespace. This will allow the lookup of the said
resources without declaring resource references in the deployment plans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2153) Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2153. -- Resolution: Fixed Fix Version/s: 2.0-beta1 1.2 Dain'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 Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: David Jencks Fix For: 1.2, 2.0-beta1 Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2971) Auto bind resources to Global JNDI
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) Affects Versions: 2.0 Reporter: Christopher M. Cardona We need a way to auto bind resources like JDBC DataSource, JavaMail Session, EJB, etc. to Global JNDI namespace. This will allow the lookup of the said resources without declaring resource references in the deployment plans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
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) Components: mail Affects Versions: 2.0 Reporter: Christopher M. Cardona Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2973) Bind JDBC DataSource to Global JNDI
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) Affects Versions: 2.0 Reporter: Christopher M. Cardona Auto bind JDBC DataSource objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2972) Bind JavaMail Session to Global JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher M. Cardona reassigned GERONIMO-2972: Assignee: Christopher M. Cardona 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) Components: mail Affects Versions: 2.0 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Auto bind JavaMail Session objects to Global JNDI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Global JNDI effectively required for Jee5
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
Re: Global JNDI effectively required for Jee5
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 after Geronimo provides one ;-) Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Global JNDI effectively required for Jee5
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.
Re: Global JNDI effectively required for Jee5
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 exaggeration to me. @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 any form. @MessageDriven.mappedName() A product specific name(e.g. global JNDI name of a queue) that this message-driven bean should be mapped to. @WebServiceRef.mappedName() This mapped name is often a global JNDI name, but may be a name of any form. persistence-unitjta-data-source persistence-unitnon-jta-data-source InJavaEEenvironments,thejta-data-sourceandnon-jta-data- sourceelementsareused tospecifytheglobal JNDInameoftheJTAand/ornon- JTAdatasourcetobeusedbythepersistence provider. The spec makes it clear that Global JNDI is not required to satisfy these values, and that the meaning of these fields is completely vendor specific. In the case of mapped name, the application server can completely ignore the field. 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 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 their code with the mapped names, effectively locking in the Global JNDI names that they expect to work in our application server. umm, that assumes that either every other app server has come up with exactly the same scheme for global jndi names so they are in fact interoperable or that we can imitate everyone elses naming scheme at once. Do you have any evidence for the first? How would you propose we do the second? What are the jndi naming schemes for each other app server? So do you agree that Global JNDI is the defacto required implementation for these and other similar entries? no. Since the beginning of geronimo we've carefully stayed away from relying on global jndi for resolving references since it imposes global constraints on what you can deploy at once in the app server, despite every other app server I know of relying on global jndi for resolving references. I'm extremely reluctant to abandon the lack of conflicts between apps that we have now to run after an alleged similarity with other app servers without thorough investigation of compatibility between other app servers and thinking about other choices that would preserve the lack of conflicts. Note that the use of any particular style of name in such annotations does not imply that the target is actually bound in jndi: all it requires is that we can find the resource somehow. Two alternatives that I would prefer to global jndi are: 1. We know the type of the thing we're looking for, so we can simply treat the provided string as an (extended) ejb-link, resource-link, etc and search the ancestor tree of the current app for a unique match. IMO this would be a lot simpler to implement that relying on global jndi, because we already have the code implemented and don't have to bind anything anywhere. 2. scoped global jndi. Each application gets a global jndi tree that only includes stuff from itself and its ancestor graph. This avoids conflicts and should satisfy those with a jndi fetish. thanks david jencks -dain
Re: Global JNDI effectively required for Jee5
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 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 their code with the mapped names, effectively locking in the Global JNDI names that they expect to work in our application server. umm, that assumes that either every other app server has come up with exactly the same scheme for global jndi names so they are in fact interoperable or that we can imitate everyone elses naming scheme at once. um, I'm not making that assumption. I'm assuming that other systems are using Global JNDI for resolving refs and that users will have normal JNDI names hardcoded into their apps. By normal names I would say that they are simple words separated by a '/' character. I'm saying: 1. simple names are good 2. simple names have nothing necessarily to do with global jndi althought that is one possible implementation strategy 3. if users expect portability across app servers we need to do some actual research on what other app servers do and find out if there is in fact a de-facto standard. Hand waving won't cut it. My impression from various code that attempts to locate TransactionManagers in various app servers jndi is that while everyone has schemes that are vaguely similar, they are all in fact different and incompatible. So my initial bias before doing any research is that compatibility across app servers is going to be rather hard. So do you agree that Global JNDI is the defacto required implementation for these and other similar entries? no. Since the beginning of geronimo we've carefully stayed away from relying on global jndi for resolving references since it imposes global constraints on what you can deploy at once in the app server, despite every other app server I know of relying on global jndi for resolving references. I'm extremely reluctant to abandon the lack of conflicts between apps that we have now to run after an alleged similarity with other app servers without thorough investigation of compatibility between other app servers and thinking about other choices that would preserve the lack of conflicts. I understand your reluctance and know the history, but reality is *everyone* uses Global JNDI. I challenge you to find a single JEE server that doesn't. Since everyone does, it is the defacto standard, and it is becoming more ingrained into the specs. I think we need give up on our custom system, and simply implement it the way everyone else dose. I don't really understand what your insistence on global jndi has to do with the problem of resolving these annotations. The user's app isn't directly using jndi for this. To me you are saying we can't do anything better than anyone else because it might be different. Note that the use of any particular style of name in such annotations does not imply that the target is actually bound in jndi: all it requires is that we can find the resource somehow. Two alternatives that I would prefer to global jndi are: 1. We know the type of the thing we're looking for, so we can simply treat the provided string as an (extended) ejb-link, resource-link, etc and search the ancestor tree of the current app for a unique match. IMO this would be a lot simpler to implement that relying on global jndi, because we already have the code implemented and don't have to bind anything anywhere. 2. scoped global jndi. Each application gets a global jndi tree that only includes stuff from itself and its ancestor graph. This avoids conflicts and should satisfy those with a jndi fetish. There is nothing wrong with either proposal, and either would be a step forward. I just think we shouldn't invent something new and just give users what they expect. Do you think (2) would surprise people too much? I'm very reluctant to abandon the conflict avoidance of what we have in order to copy the lowest common denominator. (1) is the easiest solution I can think of since it's basically already implemented and doesn't involve coming up with a binding strategy for everything and (2) seems to me to combine the advantages of global jndi with the conflict avoidance we have now. Why is plain global jndi better? thanks david jencks -dain
Global JNDI effectively required for Jee5
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 any form. @MessageDriven.mappedName() A product specific name(e.g. global JNDI name of a queue) that this message-driven bean should be mapped to. @WebServiceRef.mappedName() This mapped name is often a global JNDI name, but may be a name of any form. persistence-unitjta-data-source persistence-unitnon-jta-data-source InJavaEEenvironments,thejta-data-sourceandnon-jta-data- sourceelementsareused tospecifytheglobal JNDInameoftheJTAand/ornon- JTAdatasourcetobeusedbythepersistence provider. The spec makes it clear that Global JNDI is not required to satisfy these values, and that the meaning of these fields is completely vendor specific. In the case of mapped name, the application server can completely ignore the field. 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 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 their code with the mapped names, effectively locking in the Global JNDI names that they expect to work in our application server. So do you agree that Global JNDI is the defacto required implementation for these and other similar entries? -dain
[jira] Created: (GERONIMO-2673) WARN message from Global JNDI
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: naming Affects Versions: 2.0-M2 Reporter: Krishnakumar B When stopping an application a WARN message and exception is thrown 14:43:57,265 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:234) 14:43:57,275 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop
[jira] Commented: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=comments#action_12440360 ] David Jencks commented on GERONIMO-2153: In rev 453522 I installed the jndi gbeans into the client module (configuration) and removed some code that 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 Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: David Jencks Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2153) Global JNDI
[ 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 URL: http://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: David Jencks Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=comments#action_12439349 ] David Jencks commented on GERONIMO-2153: I've copied most of dains sandbox work into geronimo-naming and removed the obsolete stuff we had there so all our naming is based on xbean-naming and the gjndi gbeans etc. g rev 452262 openejb rev 452263 Remaining work: -rationalize the package names - Improve the design of and decide on a good location for the ResourceBinding and EJBBinding gbeans that I did not copy from the plugin. These involve both connector/naming and openejb/naming classes, and I'm not certain where esp. the connector one should go. I'm not enthusiastic about introducing more dependencies from connector due to its use in Jencks. - check if java:comp/env should be able to be looked up even if empty. 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 --- Key: GERONIMO-2153 URL: http://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: Dain Sundstrom Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=comments#action_12439029 ] David Jencks commented on GERONIMO-2153: dain has put a plugin in the sandbox that uses the xbean naming stuff. Now we need to put this into trunk. I 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 JNDI --- Key: GERONIMO-2153 URL: http://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: Dain Sundstrom Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r451419 - in /geronimo/sandbox/plugins/global-jndi: ./ src/java/org/apache/geronimo/gjndi/ src/java/org/apache/geronimo/gjndi/binding/ src/test/org/apache/geronimo/gjndi/binding/
see revision 451423 (http://svn.apache.org/viewvc? view=revrevision=451423) -dain On Sep 29, 2006, at 1:40 PM, Jason Dillon wrote: Can we plz use the new m2 layout? --jason
Re: svn commit: r451419 - in /geronimo/sandbox/plugins/global-jndi: ./ src/java/org/apache/geronimo/gjndi/ src/java/org/apache/geronimo/gjndi/binding/ src/test/org/apache/geronimo/gjndi/binding/
Cool! Thx, --jason On Sep 29, 2006, at 5:19 PM, Dain Sundstrom wrote: see revision 451423 (http://svn.apache.org/viewvc? view=revrevision=451423) -dain On Sep 29, 2006, at 1:40 PM, Jason Dillon wrote: Can we plz use the new m2 layout? --jason
Global JNDI
Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote 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't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. -dain
Re: Global JNDI
Dain Sundstrom wrote: Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote 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't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. Looks interesting. Why would we put this in a patch branch and not just trunk for v1.2? Regards, Alan
Re: Global JNDI
On Aug 17, 2006, at 10:57 AM, Alan D. Cabrera wrote: Dain Sundstrom wrote: Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote 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't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. Looks interesting. Why would we put this in a patch branch and not just trunk for v1.2? I'm actually working on a new plugin that will run in 1.1+ in the sandbox (not a branch). After I get it working, I think we should look at pulling it directly into 1.2. -dain
[jira] Assigned: (GERONIMO-2153) Global JNDI
[ 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://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Assigned To: Dain Sundstrom Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
How Can I give global jndi name od Database pool in geronimo 1.1
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, Gurgaon,Haryana – 122001Call at:+91-124-2805091/92 Ext. 35+91-99113-16998 Visit: http://www.aceva.com
Re: How Can I give global jndi name od Database pool in geronimo 1.1
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 usage can be seen by going to Database pools and clicking on the usage link near a currently deployed pool. I am also showing it below In your j2ee deployment descriptor (eg web.xml)add the following resource-ref res-ref-namejdbc/MyDataSource/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref In your geronimo specific descriptor (eg geronimo-web.xml) add the following resource-ref ref-namejdbc/MyDataSource/ref-name resource-linkSystemDatasource/resource-link /resource-ref Note that the contents of res-ref-name tag in web.xml should be the same as the contents of ref-name tag in geronimo-web.xml and that will match the name you lookup in JNDI(java:comp/env/jdbc/MyDataSource) SystemDatasource is the name of the datasource you deploy on geronimo Thanks Manu On 8/8/06, Manish Satwani [EMAIL PROTECTED] 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 Plan Thanks Manish Satwani Senior Software Engineer Aceva Technologies | Unlock Your Working Capital A-1501, Signature Towers - I, South City, Gurgaon, Haryana – 122001 Call at: +91-124-2805091/92 Ext. 35 +91-99113-16998 Visit: http://www.aceva.com
Re: How Can I give global jndi name od Database pool in geronimo 1.1
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 context.We are planning to have a working global jndi in geronimo 1.2thanksdavid jencksThanks Manish Satwani Senior Software EngineerAceva Technologies | Unlock Your Working CapitalA-1501, Signature Towers - I,South City, Gurgaon,Haryana – 122001Call at:+91-124-2805091/92 Ext. 35+91-99113-16998 Visit: http://www.aceva.com
Re: Implementing Global JNDI
Hi David, Few days back i had attached a implementation to JIRA-2153. Would be glad if u can provide ur review comments for the same. Regards Krishnakumar On 7/18/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi David, I have updated the JIRA-2153 with Context implementation and GBean that binds to JNDI. Kindly provide ur comments. Regards Krish On 7/6/06, David Jencks [EMAIL PROTECTED] wrote: See my comment in the jira about this, I don't think you need to use any naming References at all, nor do you need anything but a GBean reference to the appropriate 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 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 ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: 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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnec tionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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
[jira] Updated: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=all ] Krishnakumar B updated GERONIMO-2153: - Attaching a Context Implementation and GBean for binding connectors. The GBean is called from Builder and a reference is passed thats bound to JNDI. 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) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Attachments: jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2153) 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: GERONIMO-2153 URL: http://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Attachments: GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2153) Global JNDI
[ 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 --- Key: GERONIMO-2153 URL: http://issues.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: naming Affects Versions: 1.2 Reporter: Krishnakumar B Attachments: ConnectorJNDIBindingGBean.java, GeronimoGlobalContext.java, jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Implementing Global JNDI
Hi David, I have updated the JIRA-2153 with Context implementation and GBean that binds to JNDI. Kindly provide ur comments. Regards Krish On 7/6/06, David Jencks [EMAIL PROTECTED] wrote: See my comment in the jira about this, I don't think you need to use any naming References at all, nor do you need anything but a GBean reference to the appropriate 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 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 ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: 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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnec tionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume
Re: Implementing Global JNDI
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 loaded in j2ee-deployer. Hence we dont get access in ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: 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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Implementing Global JNDI
See my comment in the jira about this, I don't think you need to use any naming References at all, nor do you need anything but a GBean reference to the appropriate 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 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 ServiceConfigBuilder to GBeanReference thats part of naming. Currently all the binding GBeans are in naming package. So it works for all j2ee deployments. Is there a way to work around this ClassLoading problem heirarchy for binding GBeans through builder? Regards Krishnakumar On 6/28/06, David Jencks [EMAIL PROTECTED] wrote: I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it. thanks david jencks On Jun 28, 2006, at 12:39 AM, Manu George wrote: 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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks Manu On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnec tionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2153) Global JNDI
[ http://issues.apache.org/jira/browse/GERONIMO-2153?page=comments#action_12419191 ] David Jencks commented on GERONIMO-2153: I apologize for taking so long to get to reviewing this. This has some good elements but also quite a few problems. Here are a few suggestions. 1. The bindingGBeans do not need to know the name of the gbean they are getting something to bind into jndi from, they need a reference to it. Similarly they do not need to bind a naming Reference, they can bind the object itself. For instance, the connector binding gbean can do something like this: private final ManagedConnectionFactoryWrapper managedConnectionFactoryWrapper; // this is the reference to the gbean that gives us the connection factory to bind ... //now it's time to bind the connection factory Object connectionFactory = managedConnectionFactoryWrapper.$getResource(); globalContext.bind(jndiName, connectionFactory); This is also going to affect how the builders set up the binding gbeans: they know the name of the appropriate gbean such as managedConnectionFactoryWrapper, since they just created it, so they need to use that name to set the reference pattern in the binding gbean. The binding gbean will then get (a proxy to) the real gbean that it can use as outlined above. 2. I don't see an implementation of a writable thread safe jndi Context, as dain pointed out you would need. 3. The zip file consists almost entirely of irrelevant files and the actual source files do not all appear to be in the geronimo project structure. This makes it extremely hard to figure out what to look at. 4. Some of the code modifications (such as to ServiceConfigBuilder) appear to be test cases rather than production code. It will be a lot easier to evaluate your work if you keep test cases and production code clearly separated as is done in typical maven projects. 5. I think you will need to redo the openejb work after dain's reintegration of his container rewrite. Thanks! Let us know if you 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: naming Versions: 1.2 Reporter: Krishnakumar B Attachments: jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2153) Global JNDI
[ 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 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 Attachments: jndi-project.zip Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Implementing Global JNDI
Hi, We have created a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attached the initial draft. We have tried two approaches. * Adding to plan * Deploying from Builder. The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan. Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBean class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean attribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attribute attribute name=componentNameJMSQueueFactory/attribute attribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute /gbean and gbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean attribute name=configIdtest/gbean/1.0/car/attribute attribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attribute attribute name=j2eeTypeGBean/attribute attribute name=classNamegbean.test.TestGBean/attribute /gbean We have a Classloading issue when trying to maintain all the BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource Adapters that are not J2EE interfaces like javax.sql.DataSource / javax.jms.QueueConnectionFactory we get a ClassNotFound as the class is not available at Classloader of rmi-naming. We spent a lot of time trying to solve this issue but are not able to find a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces like DataSource, EJB interfaces, Queue, Topic etc.. If the approach is correct we would like to add the other features to make this more suitable for adding into the product. Regards Krishnakumar B On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Implementing Global JNDI
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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks ManuOn 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi,We have createda JIRA(http://issues.apache.org/jira/browse/GERONIMO-2153) and attachedthe initial draft. We have tried two approaches. * Adding to plan* Deploying from Builder.The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tagglobal-jndi/ in opene ejb plan.Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name=JMSQueueFactoryJNDIBindingGBeanclass=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBeanattribute name=configIdtest/jms.rar/1.0/rar/attribute attribute name=jndiNameglobalJMSQueueFactory/attributeattribute name=componentNameJMSQueueFactory/attributeattribute name=j2eeTypeJCAManagedConnectionFactory/attribute attribute name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute/gbeanandgbean name=TestGBeanJNDIBindingGBean class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBeanattribute name=configIdtest/gbean/1.0/car/attributeattribute name=jndiNameglobalTestGBean/attribute attribute name=componentNameTestGBean/attributeattribute name=j2eeTypeGBean/attributeattribute name=classNamegbean.test.TestGBean/attribute /gbeanWe have a Classloading issue when trying to maintain all theBindingGbeans at one level. ( rmi-naming ). For GBeans and ResourceAdapters that are not J2EE interfaces like javax.sql.DataSource /javax.jms.QueueConnectionFactory we get a ClassNotFound as the classis not available at Classloader of rmi-naming.We spent a lot of time trying to solve this issue but are not able tofind a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces likeDataSource, EJB interfaces, Queue, Topic etc..If the approach is correct we would like to add the other features tomake this more suitable for adding into the product. RegardsKrishnakumar BOn 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Implementing Global JNDI
I think there is a simpler solution, or perhaps I don't understand all the details of what you are proposing. I think if you give your binding gbeans the magic classLoader attribute everything will work. This will be set to the configuration classloader for the configuration the gbean is in, not the configuration the gbeans class is loaded in. This classloader should always have the necessary classes in it.thanksdavid jencksOn Jun 28, 2006, at 12:39 AM, Manu George wrote: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 will be done in the builders. All the reference creation logic can also be moved to the gbeans.The Binding GBeans will then have access to application level classes as they will be loaded in the app class loader. We hope this approach will solve the current problem. We will post the code again after making these changes. Thanks ManuOn 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi,We have created a JIRA(http://issues.apache.org/jira/browse/GERONIMO-2153 ) and attachedthe initial draft. We have tried two approaches. * Adding to plan* Deploying from Builder.The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag global-jndi/ in opene ejb plan.Resource Adapter and GBean have a gbean plan added to deployment plan. gbean name="JMSQueueFactoryJNDIBindingGBean"class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean"attribute name="configId"test/jms.rar/1.0/rar/attribute attribute name="jndiName"globalJMSQueueFactory/attributeattribute name="componentName"JMSQueueFactory/attributeattribute name="j2eeType"JCAManagedConnectionFactory/attribute attribute name="interfaceName"org.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute/gbeanandgbean name="TestGBeanJNDIBindingGBean" class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean"attribute name="configId"test/gbean/1.0/car/attributeattribute name="jndiName"globalTestGBean/attribute attribute name="componentName"TestGBean/attributeattribute name="j2eeType"GBean/attributeattribute name="className"gbean.test.TestGBean/attribute /gbeanWe have a Classloading issue when trying to maintain all theBindingGbeans at one level. ( rmi-naming ). For GBeans and ResourceAdapters that are not J2EE interfaces like javax.sql.DataSource /javax.jms.QueueConnectionFactory we get a ClassNotFound as the classis not available at Classloader of rmi-naming.We spent a lot of time trying to solve this issue but are not able tofind a solution as the application level interface or class is not available. This problem will not occur for j2ee interfaces likeDataSource, EJB interfaces, Queue, Topic etc..If the approach is correct we would like to add the other features tomake this more suitable for adding into the product. RegardsKrishnakumar BOn 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2153) Global JNDI
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 Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2153) Global JNDI
[ 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.apache.org/jira/browse/GERONIMO-2153 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: naming Versions: 1.2 Reporter: Krishnakumar B Implementing Global JNDI for server Requirements * Non -persistent * Read/Write * Bindings to JNDI/COS-NAMING/JAXR * Can bind RA,EJB,GBEAN,Any object -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Implementing Global JNDI
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 jndi. I might've misunderstood it, but isn't Global JNDI == geronimo: context == global: context? If so, why is this copying from Global JNDI to the geronimo: namespace? Looking forward to seeing your patch for it. Just as Guillaume suggested, please create an JIRA issue and attach the patch to it. Krishnakumar B Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Implementing Global JNDI
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 implementation uses GeronimoRootContext and ReadOnlyContextthats part of naming module to create the root context ( geronimo: ). TheContext is accessed by means of a FactoryGeronimoInitialContextFactory that implements InitialContextFactory.* A GBean ( GeronimoContextGBean ) loads on start of server andcreates the Root Context.Now applications can bind to this context. * We have added GBeans to naming ( GlobalJNDIBindingGBean for RA,DataSource, QCF/TCF,Queue, Topicand EJBJNDIBindingGBean for EJB )that are deployed when an app is deployed.* The builders add the Gbeans during the deployment process. [ ConnectorModule Builder, OpenEJBModuleBuilder, ServiceConfigBuilder ].The plan needs to have some XML Tag to say this resource needs to getsinto Global JNDI and the builder can then add it to geronimo: Context. This is not implemented yet. Currently if we deploy a connector itgets in global jndi.The current code we can add DataSource, RA, EJB, QCF, Queue/Topic,GBeans to geronimo: Context. With some changes to context implementation any object can be bound to global JNDI. ( Have notlooked at security aspect and would need some ideas on how to proceed).This may need some more work and changes before it takes final form to get into product. Kindly provide your review, comments andcontributions from others who are interested and have better ideas.We are not able to attach the code as mailing list rejects attachments.Regards Krishnakumar BOn 5/24/06, Krishnakumar B [EMAIL PROTECTED] wrote: 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 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 by the j2ee spec for what it requires: thus IMO we should use something else.IIRC the original global jndi context used geronimo:I'm OK with that or maybe global:. IIRC some servers use just /foo/bar with no context.If I am correct, we should support that also (but not the default). * When we implement global JNDI we have some entries in Global and All entries related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global I'm not sure what you're asking about here.Unless you do something screwy to link one of these to the other, the contents of these contexts will be completely unrelated. Looking at the JavaDocs for InitialContext, it does not have a constructor that takes a String.Did you mean: Context context = (Context) new InitialContext().lookup(java:comp/ env); Context context = (Context) new InitialContext().lookup(global:); * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g ) DataSource reference directly put in JNDI For j2ee components I think we should bind the same kinds of References in the global jndi tree as we bind in the current java: context.What we bind for stuff that can't get into the java: context needs more thought: it probably depends on what it is.Of course if the context is not read-only an app can bind whatever it wants wherever it wants, thus bringing to mind the need for security and permissions for this stuff. I don't think we can use the current Reference object we bind into our read only context because they do cache the value and never release it.It is expected that the referece will be GCed when the J2EE application is unloaded.It shouldn't be hard to either turn off the cache or to register listener for the reference target life- cycle events.Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. My plan for implementing this was: 1. Look at the current ReadOnlyContext implementation and figure out how to make a sufficiently synchronized version of it.I'm hoping that we can have synchronized wrappers around this implementation rather than needing a copy, subclass, or new implementation. I think a read only JNDI
Re: Implementing Global JNDI
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 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 by the j2ee spec for what it requires: thus IMO we should use something else. IIRC the original global jndi context used geronimo: I'm OK with that or maybe global:. IIRC some servers use just /foo/bar with no context. If I am correct, we should support that also (but not the default). * When we implement global JNDI we have some entries in Global and All entries related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global I'm not sure what you're asking about here. Unless you do something screwy to link one of these to the other, the contents of these contexts will be completely unrelated. Looking at the JavaDocs for InitialContext, it does not have a constructor that takes a String. Did you mean: Context context = (Context) new InitialContext().lookup(java:comp/ env); Context context = (Context) new InitialContext().lookup(global:); * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g) DataSource reference directly put in JNDI For j2ee components I think we should bind the same kinds of References in the global jndi tree as we bind in the current java: context. What we bind for stuff that can't get into the java: context needs more thought: it probably depends on what it is. Of course if the context is not read-only an app can bind whatever it wants wherever it wants, thus bringing to mind the need for security and permissions for this stuff. I don't think we can use the current Reference object we bind into our read only context because they do cache the value and never release it. It is expected that the referece will be GCed when the J2EE application is unloaded. It shouldn't be hard to either turn off the cache or to register listener for the reference target life- cycle events. Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. My plan for implementing this was: 1. Look at the current ReadOnlyContext implementation and figure out how to make a sufficiently synchronized version of it. I'm hoping that we can have synchronized wrappers around this implementation rather than needing a copy, subclass, or new implementation. I think a read only JNDI and a mutable one are different enough that they need separate implementations. Currently our ENC is using a the EnterpriseNamingContext which does not extend ReadOnlyContext (as it isn't really read only). I'd like to keep the EnterpriseNamingContext simple and strictly read only. Therefore, I'd like to see an new separate implementation. If I were going to write it, I'd base it on ConcurrentReaderHashMap and future objects in Java5 (or backport-concurrent-util), but I'm not writing it, so I say do whatever you are comfortable with. 2. Remind myself of how the geronimo: context used to be installed. I think the same method will still work. We might want a gbean to specifically install it. Make sure that programmatic binding and lookup works. IIRC, we add set naming provider package to org.apache.geronimo.naming and when a user tries to access the foo: root-context, the jvm looks for the class org.apache.geronimo.naming.foo.fooURLContextFactory. We still have one named global that most likely gets loaded when someone looks up global: 3. Figure out how to bind stuff into this context from plans rather than java code. Currently my idea is to do this with binding gbeans: I'm not entirely sure how to do this but one possibility would be to have them contain a Reference object and the name to bind it under. Another possibility would be to not use References but rather have a binding gbean with say a gbean reference to a ManagedConnectionFactoryWrapper: the gbean would call $getResource () on it and then bind the result directly into jndi. This would result in simpler builders but more gbeans: we'd need one for resource-refs and resource-env-refs, and another one for ejbs, and another for plain gbean bindings. One thing I like about this second plan is that the object would only
Re: Implementing Global JNDI
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 related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g) DataSource reference directly put in JNDI Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. Regards Krishnakumar On 4/28/06, David Jencks [EMAIL PROTECTED] wrote: 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=objectnamemyService/... attribute name=addressservices/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
Re: Implementing Global JNDI
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 by the j2ee spec for what it requires: thus IMO we should use something else. IIRC the original global jndi context used geronimo: I'm OK with that or maybe global:. * When we implement global JNDI we have some entries in Global and All entries related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global I'm not sure what you're asking about here. Unless you do something screwy to link one of these to the other, the contents of these contexts will be completely unrelated. * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g) DataSource reference directly put in JNDI For j2ee components I think we should bind the same kinds of References in the global jndi tree as we bind in the current java: context. What we bind for stuff that can't get into the java: context needs more thought: it probably depends on what it is. Of course if the context is not read-only an app can bind whatever it wants wherever it wants, thus bringing to mind the need for security and permissions for this stuff. Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. My plan for implementing this was: 1. Look at the current ReadOnlyContext implementation and figure out how to make a sufficiently synchronized version of it. I'm hoping that we can have synchronized wrappers around this implementation rather than needing a copy, subclass, or new implementation. 2. Remind myself of how the geronimo: context used to be installed. I think the same method will still work. We might want a gbean to specifically install it. Make sure that programmatic binding and lookup works. 3. Figure out how to bind stuff into this context from plans rather than java code. Currently my idea is to do this with binding gbeans: I'm not entirely sure how to do this but one possibility would be to have them contain a Reference object and the name to bind it under. Another possibility would be to not use References but rather have a binding gbean with say a gbean reference to a ManagedConnectionFactoryWrapper: the gbean would call $getResource() on it and then bind the result directly into jndi. This would result in simpler builders but more gbeans: we'd need one for resource-refs and resource-env-refs, and another one for ejbs, and another for plain gbean bindings. One thing I like about this second plan is that the object would only be bound in jndi while the resource was actually available. Of course, the component that looks up the entry can still keep it until the underlying gbean support is long gone, and get exceptions when it tries to use the entry. I was planning to work on this for 1.2, but I will be more than happy to work with you if you would like to implement it. Please let us know of your intentions, progress, and please, if you decide not to implement it let us know :-) I'll be mostly offline for the next few days but will try to check for messages and respond as often as I can. many thanks david jencks Regards Krishnakumar On 4/28/06, David Jencks [EMAIL PROTECTED] wrote: 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=objectnamemyService/... attribute name=addressservices/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
Re: Implementing Global JNDI
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 namespace e.g) java: or java:global? IIUC java: is reserved by the j2ee spec for what it requires: thus IMO we should use something else. IIRC the original global jndi context used geronimo: I'm OK with that or maybe global:. IIRC some servers use just /foo/bar with no context. If I am correct, we should support that also (but not the default). * When we implement global JNDI we have some entries in Global and All entries related to application in Local. When a user creates a context he needs to get from either global or local based on what he needs. Would it be right for lookup code to decide from where to fetch the entry based on how the Context is created? for e.g) if i say InitialContext iniCtx = new InitialContext(java:comp/env); fetch from local and if InitialContext iniCtx = new InitialContext(java:global); fetch from global I'm not sure what you're asking about here. Unless you do something screwy to link one of these to the other, the contents of these contexts will be completely unrelated. Looking at the JavaDocs for InitialContext, it does not have a constructor that takes a String. Did you mean: Context context = (Context) new InitialContext().lookup(java:comp/ env); Context context = (Context) new InitialContext().lookup(global:); * Currently in Local JNDI we store Resource References. Should global JNDI also use the same approach or can we use Object references for e.g) DataSource reference directly put in JNDI For j2ee components I think we should bind the same kinds of References in the global jndi tree as we bind in the current java: context. What we bind for stuff that can't get into the java: context needs more thought: it probably depends on what it is. Of course if the context is not read-only an app can bind whatever it wants wherever it wants, thus bringing to mind the need for security and permissions for this stuff. I don't think we can use the current Reference object we bind into our read only context because they do cache the value and never release it. It is expected that the referece will be GCed when the J2EE application is unloaded. It shouldn't be hard to either turn off the cache or to register listener for the reference target life- cycle events. Would appreciate any thoughts as i am still learning and might have missed some points to consider while trying to implement something like this. My plan for implementing this was: 1. Look at the current ReadOnlyContext implementation and figure out how to make a sufficiently synchronized version of it. I'm hoping that we can have synchronized wrappers around this implementation rather than needing a copy, subclass, or new implementation. I think a read only JNDI and a mutable one are different enough that they need separate implementations. Currently our ENC is using a the EnterpriseNamingContext which does not extend ReadOnlyContext (as it isn't really read only). I'd like to keep the EnterpriseNamingContext simple and strictly read only. Therefore, I'd like to see an new separate implementation. If I were going to write it, I'd base it on ConcurrentReaderHashMap and future objects in Java5 (or backport-concurrent-util), but I'm not writing it, so I say do whatever you are comfortable with. 2. Remind myself of how the geronimo: context used to be installed. I think the same method will still work. We might want a gbean to specifically install it. Make sure that programmatic binding and lookup works. IIRC, we add set naming provider package to org.apache.geronimo.naming and when a user tries to access the foo: root-context, the jvm looks for the class org.apache.geronimo.naming.foo.fooURLContextFactory. We still have one named global that most likely gets loaded when someone looks up global: 3. Figure out how to bind stuff into this context from plans rather than java code. Currently my idea is to do this with binding gbeans: I'm not entirely sure how to do this but one possibility would be to have them contain a Reference object and the name to bind it under. Another possibility would be to not use References but rather have a binding gbean with say a gbean reference to a ManagedConnectionFactoryWrapper: the gbean would call $getResource () on it and then bind the result directly into jndi. This would result in simpler builders but more gbeans: we'd need one for resource-refs and resource-env-refs, and another one for ejbs, and another for plain gbean bindings. One thing I like about this second plan is that the object would only be bound in jndi while the resource was actually
Re: Implementing Global JNDI
I agree with what Dain said. I also believe that as the spec says the J2EE component enviroment should not be writable and we need not provide any option for that either. It is not necessary. Apps can bind to other namespaces.On 4/26/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Are you planning on making the J2EE component enviroment (java:comp/env) writable?I can see making the global tree writable, but amconcerned about making the component environment itself writable.The J2EE 1.4 spec page 64 states:The container must ensure that the application component instanceshave onlyread access to their environment variables. The container must throw thejavax.naming.OperationNotSupportedException from all the methods of thejavax.naming.Context interface that modify the environment namingcontextand its subcontextsI suppose we could add an optional flag for non-compliantapplications to allow them to modify their environment, but I think the default for the component environment should be read-only.BTW, I am in favor of making everything else writable.-dainOn Apr 26, 2006, at 6:32 AM, Manu George wrote: Hi, Guillaume I guess if a writable context is implemented still the approach given above should work. As we will be using the ENCConfigBuilder only to populate the ENC during startup the interfaces can be used to refer to the gbeans representing the deployed artefacts. Whatever we will be writing to context from apps would be done after startup of server and lost at shutdown.So there would not be any problem due to geronimo using interfaces to get the GBean names as what we will be adding at runtime will not be gbeans and we will not use ENCConfigBuilder.Am I right? Now a new property for jndiname will also be required in the plans for the connectors. P.S.This property was actually present in the older versions of geronimo but was removed. I also remember david jencks mentioning in the mailing list that he had a working implementation of a context which he removed for some reason. Thanks Manu On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be 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. 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 George wrote:Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name?Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Comments inlineOn 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong.Gbeans with a j2eeType=JCAManagedConnectionFactory have aconnectionFactoryInterface attribute that gives the name of the maininterface 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 globalJNDI tree when the resource is created: each configuration 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. 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 isread-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 fora 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 isnothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same nameI 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
Re: Implementing Global JNDI
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.thanksdavid jencksOn Apr 26, 2006, at 11:56 PM, Manu George wrote:Comments inlineOn 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong.Gbeans with a j2eeType=JCAManagedConnectionFactory have aconnectionFactoryInterface attribute that gives the name of the maininterface 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 globalJNDI tree when the resource is created: each configuration 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. 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 isread-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 fora 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 isnothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same nameI 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
Re: Implementing Global JNDI
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=objectnamemyService/... attribute name=addressservices/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. -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
Re: Implementing Global JNDI
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=objectnamemyService/... attribute name=addressservices/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
Re: Implementing Global JNDI
Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name? Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, David Jencks [EMAIL PROTECTED] wrote: It's required for corba ejb references.david jencksOn Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be 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. 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 George wrote: Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name? Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Hi Guillaume, The ENCConfigBuilder and ComponentContextBuilder are called when u deploy an application and need a JNDI reference. How does it happen when u start the app server with some apps already deployed? How is the Context built? Regards Krish On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be 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. 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 George wrote: Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name? Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Hi, Guillaume I guess if a writable context is implemented still the approach given above should work. As we will be using the ENCConfigBuilder only to populate the ENC during startup the interfaces can be used to refer to the gbeans representing the deployed artefacts. Whatever we will be writing to context from apps would be done after startup of server and lost at shutdown. So there would not be any problem due to geronimo using interfaces to get the GBean names as what we will be adding at runtime will not be gbeans and we will not use ENCConfigBuilder. Am I right? Now a new property for jndiname will also be required in the plans for the connectors. P.S.This property was actually present in the older versions of geronimo but was removed. I also remember david jencks mentioning in the mailing list that he had a working implementation of a context which he removed for some reason. Thanks Manu On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote:When a JNDI context is created for a given configuration, the interfacename is used to determine the name of the gbean that will be 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 arecreated. 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 George wrote:Thanks David.Guillaume , Which proxy in the JNDI Tree are you referring wheregeronimo requires the main interface name?Are you speaking of UserTransaction etc? I thought those were standard names that we canuse to access them and will not be provided in DD? Please clarify andcorrect me if I am wrong. ThanksManuOn 4/25/06, *David Jencks* [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote:It's required for corba ejb references.david jencksOn Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
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. 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. 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 ... * 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. * 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 Guillaume Nodet Manu George wrote: Hi, Guillaume I guess if a writable context is implemented still the approach given above should work. As we will be using the ENCConfigBuilder only to populate the ENC during startup the interfaces can be used to refer to the gbeans representing the deployed artefacts. Whatever we will be writing to context from apps would be done after startup of server and lost at shutdown. So there would not be any problem due to geronimo using interfaces to get the GBean names as what we will be adding at runtime will not be gbeans and we will not use ENCConfigBuilder. Am I right? Now a new property for jndiname will also be required in the plans for the connectors. P.S.This property was actually present in the older versions of geronimo but was removed. I also remember david jencks mentioning in the mailing list that he had a working implementation of a context which he removed for some reason. Thanks Manu On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be 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. 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 George wrote: Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name? Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Are you planning on making the J2EE component enviroment (java:comp/ env) writable? I can see making the global tree writable, but am concerned about making the component environment itself writable. The J2EE 1.4 spec page 64 states: The container must ensure that the application component instances have only read access to their environment variables. The container must throw the javax.naming.OperationNotSupportedException from all the methods of the javax.naming.Context interface that modify the environment naming context and its subcontexts I suppose we could add an optional flag for non-compliant applications to allow them to modify their environment, but I think the default for the component environment should be read-only. BTW, I am in favor of making everything else writable. -dain On Apr 26, 2006, at 6:32 AM, Manu George wrote: Hi, Guillaume I guess if a writable context is implemented still the approach given above should work. As we will be using the ENCConfigBuilder only to populate the ENC during startup the interfaces can be used to refer to the gbeans representing the deployed artefacts. Whatever we will be writing to context from apps would be done after startup of server and lost at shutdown. So there would not be any problem due to geronimo using interfaces to get the GBean names as what we will be adding at runtime will not be gbeans and we will not use ENCConfigBuilder. Am I right? Now a new property for jndiname will also be required in the plans for the connectors. P.S.This property was actually present in the older versions of geronimo but was removed. I also remember david jencks mentioning in the mailing list that he had a working implementation of a context which he removed for some reason. Thanks Manu On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be 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. 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 George wrote: Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name? Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
I would be glad to help writing / testing this feature. Is the code available somewhere ? I also just have one question: when I was looking at how to use Geronimo JNDI implementation, i faced the problem that to access one of the proxy in the JNDI tree, Geronimo requires the main interface name (which is usually given by deployment descriptors). How did you work around that ? Cheers, Guillaume Nodet Krishnakumar B wrote: Hi, In geronimo road map there was a requirement for implementing Global JNDI for geronimo. An approach to implementing the same is posted below. Kindly post your valuable feedback. * Write and Deploy a GBean For Global JNDI * GBean on startup of server would introspect the server and build JNDI tree - jdbc - jms - ejb etc... * JNDI tree is stored in Hashmap and we can use ComponentContextBuilder to build this tree. * We can use EnterpriseNamingContext to create a context. * The Context is stored as a static variable in the Local Factory Class. * During deployment a new entry is added to Context ( Hashmap.) * During undeployment an entry is removed from Context ( Hashmap ) * We can reuse the existing the geronimo-naming package for directory operations. We have done some initial ground work ( Writing Gbean, Building JNDI Tree ) and would be glad to know how such an implementation would fit into geronimo server, limitations if any so that we know we are using the right approach. Regards Krish
Re: Implementing Global JNDI
I would be glad to help writing / testing this feature. Is the code available somewhere ? I also just have one question: when I was looking at how to use Geronimo JNDI implementation, i faced the problem that to access one of the proxy in the JNDI tree, Geronimo requires the main interface name (which is usually given by deployment descriptors). How did you work around that ? Cheers, Guillaume Nodet Krishnakumar B wrote: Hi, In geronimo road map there was a requirement for implementing Global JNDI for geronimo. An approach to implementing the same is posted below. Kindly post your valuable feedback. * Write and Deploy a GBean For Global JNDI * GBean on startup of server would introspect the server and build JNDI tree - jdbc - jms - ejb etc... * JNDI tree is stored in Hashmap and we can use ComponentContextBuilder to build this tree. * We can use EnterpriseNamingContext to create a context. * The Context is stored as a static variable in the Local Factory Class. * During deployment a new entry is added to Context ( Hashmap.) * During undeployment an entry is removed from Context ( Hashmap ) * We can reuse the existing the geronimo-naming package for directory operations. We have done some initial ground work ( Writing Gbean, Building JNDI Tree ) and would be glad to know how such an implementation would fit into geronimo server, limitations if any so that we know we are using the right approach. Regards Krish
