Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
I have checked in the changes and testcases to Branch_3_2 to support ejb-link changes. I was unable to verify that the DTD changes validate for the test cases, because if validation is enabled, then the standardjboss.xml file fails validation (both on the 3_2_1-src release and Branch_3_2 head) with the error: 2003-07-13 18:32:53,843 ERROR [org.jboss.metadata.XmlFileLoader] XmlFileLoader: File file:/usr/local/java/jboss/jboss-branch-3-2/ build/output/jboss-3.2.2RC2/server/default/conf/standardjboss.xml process error. Line: 697. Error message: The content of element type container-configuration must match (container-name,call-logging?,invoker-proxy-binding-name?,sync-on-commit-only?,contai ner-interceptors?,instance-pool?,instance-cache?,persistence-manager?,web-class-loader?,locking-policy?,container-cache-conf?,con tainer-pool-conf?,commit-option?,optiond-refresh-rate?,security-domain?,cluster-config?,depends*). 2003-07-13 18:32:53,863 ERROR [org.jboss.metadata.XmlFileLoader] failed to load standardjboss.xml. There could be a syntax error . org.jboss.deployment.DeploymentException: Invalid XML: file=file:/usr/local/java/jboss/jboss-branch-3-2/build/output/jboss-3.2.2R C2/server/default/conf/standardjboss.xml at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:296) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:247) at org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoader.java:219) at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:156) at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:433) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:774) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:766) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:629) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:603) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:587) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) regards, Jan Ok, your access is restored. Thanks. Please make sure there are tests added to the following unit tests to cover these changes: testsuite/src/main/org/jboss/test/naming/test/EjbLinkUnitTestCase.java testsuite/src/main/org/jboss/test/web/servlets/ENCServlet.java testsuite/src/main/org/jboss/test/web/test/ WebIntegrationUnitTestCase.java OK, I will integrate my test cases into these. cheers, Jan Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 2003, at 07:27 PM, Jan Bartel wrote: I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the
Re[2]: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
This is fixed now in Branch_3_2. In HEAD, validation of standardjboss.xml against jboss_3_2.dtd or jboss_4_0.dtd resulted in 73 errors. It is realy broken and needs review. alex Sunday, July 13, 2003, 1:09:20 PM, Jan Bartel wrote: JB I have checked in the changes and testcases to Branch_3_2 to support JB ejb-link changes. JB I was unable to verify that the DTD changes validate for the test cases, JB because if validation is enabled, then the standardjboss.xml file fails JB validation (both on the 3_2_1-src release and Branch_3_2 head) with the JB error: JB 2003-07-13 18:32:53,843 ERROR [org.jboss.metadata.XmlFileLoader] JB XmlFileLoader: File file:/usr/local/java/jboss/jboss-branch-3-2/ JB build/output/jboss-3.2.2RC2/server/default/conf/standardjboss.xml JB process error. Line: 697. Error message: The content of element JB type container-configuration must match JB (container-name,call-logging?,invoker-proxy-binding-name?,sync-on-commit-only?,contai JB ner-interceptors?,instance-pool?,instance-cache?,persistence-manager?,web-class-loader?,locking-policy?,container-cache-conf?,con JB tainer-pool-conf?,commit-option?,optiond-refresh-rate?,security-domain?,cluster-config?,depends*). JB 2003-07-13 18:32:53,863 ERROR [org.jboss.metadata.XmlFileLoader] failed JB to load standardjboss.xml. There could be a syntax error JB . JB org.jboss.deployment.DeploymentException: Invalid XML: JB file=file:/usr/local/java/jboss/jboss-branch-3-2/build/output/jboss-3.2.2R JB C2/server/default/conf/standardjboss.xml JB at JB org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:296) JB at JB org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:247) JB at JB org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoader.java:219) JB at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:156) JB at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:433) JB at org.jboss.deployment.MainDeployer.create(MainDeployer.java:774) JB at org.jboss.deployment.MainDeployer.create(MainDeployer.java:766) JB at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:629) JB at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:603) JB at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:587) JB at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) JB at JB sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) JB at JB sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) JB at java.lang.reflect.Method.invoke(Method.java:324) JB at JB org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) JB at JB org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) JB at JB org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:278) JB at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) JB at JB sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) JB at JB sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) JB at java.lang.reflect.Method.invoke(Method.java:324) JB at JB sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) JB at sun.rmi.transport.Transport$1.run(Transport.java:148) JB at java.security.AccessController.doPrivileged(Native Method) JB at sun.rmi.transport.Transport.serviceCall(Transport.java:144) JB at JB sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) JB at JB sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) JB at java.lang.Thread.run(Thread.java:536) JB regards, JB Jan Ok, your access is restored. Thanks. Please make sure there are tests added to the following unit tests to cover these changes: testsuite/src/main/org/jboss/test/naming/test/EjbLinkUnitTestCase.java testsuite/src/main/org/jboss/test/web/servlets/ENCServlet.java testsuite/src/main/org/jboss/test/web/test/ WebIntegrationUnitTestCase.java OK, I will integrate my test cases into these. cheers, Jan Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 2003, at 07:27 PM, Jan Bartel wrote: I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Scott, Ok, your access is restored. Thanks. Please make sure there are tests added to the following unit tests to cover these changes: testsuite/src/main/org/jboss/test/naming/test/EjbLinkUnitTestCase.java testsuite/src/main/org/jboss/test/web/servlets/ENCServlet.java testsuite/src/main/org/jboss/test/web/test/ WebIntegrationUnitTestCase.java OK, I will integrate my test cases into these. cheers, Jan Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 2003, at 07:27 PM, Jan Bartel wrote: I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the ejb-local-ref support. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the ejb-local-ref support. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref]
This is a re-post as I didn't see this echo on the list. Jan Original Message I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the ejb-local-ref support. -- / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [Fwd: Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref]
I saw the last one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jan Bartel Sent: Friday, July 11, 2003 4:31 AM To: [EMAIL PROTECTED] Subject: [Fwd: Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref] This is a re-post as I didn't see this echo on the list. Jan Original Message I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the ejb-local-ref support. -- / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Ok, your access is restored. Please make sure there are tests added to the following unit tests to cover these changes: testsuite/src/main/org/jboss/test/naming/test/EjbLinkUnitTestCase.java testsuite/src/main/org/jboss/test/web/servlets/ENCServlet.java testsuite/src/main/org/jboss/test/web/test/ WebIntegrationUnitTestCase.java Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 2003, at 07:27 PM, Jan Bartel wrote: I have made the changes as agreed: + both war deployer and ejb deployer to examine ejb-link first for both ejb-ref and ejb-local-ref. + war deployer to have a switch LenientEjbLink allowing misconfigured ejb-links to be ignored for backward compatibility. This is set to false by default, meaning misconfigured ejb-links will cause a deployment error. + war deployer and ejb deployer to support a new element in jboss descriptors called ejb-local-ref which contains a local-jndi-name element, similar to the ejb-ref element. This ejb-local-ref in the jboss deployment descriptor is only consulted in the case that the ejb-local-ref in the standard descriptor does not contain an ejb-link element (or in the case of the war deployer, the LenientEjbLink flag has been set and the ejb-link contains a name that cannot be resolved). May I please have my cvs write access back so I can commit? thanks Jan Scott M Stark wrote: Ok, then I agree with adding the ejb-local-ref support. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
On Tue, 2003-07-08 at 06:54, Jeremy Boynes wrote: I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any ejb/). If both exist, we can check they are consistent. A clear error message will help people where it is not. ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. This would help when porting from weblogic which has a similar descriptor. -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Reply inline. I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any ejb/). I agree. I think using the ejb-link first is preferable, because it is part of the standard descriptor. If it is absent, fallback to the [local-]jndi-name. If it is specified but wrong, then use the flag to indicate to use the jndi-name. ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Yup, I agree. Jan / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Jeremy Boynes wrote: Scott Stark wrote: There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Jeremy I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Victor Langelo wrote: I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor The spec makes the usage optional as well: The Application Assembler *can* use the ejb-link element in the deployment descriptor to link an EJB reference to a target enterprise bean. [EJB2.0 pp 418] Note the use of can not must And: *If* an EJB reference declaration includes the ejb-link element, the Deployer *should* bind the enterprise bean reference to the home of the enterprise bean specified as the link's target. [EJB2.0 pp 420] Again note If and should Finally: The Deployer must ensure that all the declared EJB references are bound to the homes of enterprise beans that exist in the operational environment. [EJB2.0 pp 420] So if the target is not there then it is a Deployment error. That seems a little restrictive if checked at deploy time because of boot order dependencies and redeployment, but if the target is not present when used then an error must be raised. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Ok, then I agree with adding the ejb-local-ref support. -- Scott Stark Chief Technology Officer JBoss Group, LLC Jeremy Boynes wrote: The spec makes the usage optional as well: The Application Assembler *can* use the ejb-link element in the deployment descriptor to link an EJB reference to a target enterprise bean. [EJB2.0 pp 418] Note the use of can not must And: *If* an EJB reference declaration includes the ejb-link element, the Deployer *should* bind the enterprise bean reference to the home of the enterprise bean specified as the link's target. [EJB2.0 pp 420] Again note If and should Finally: The Deployer must ensure that all the declared EJB references are bound to the homes of enterprise beans that exist in the operational environment. [EJB2.0 pp 420] So if the target is not there then it is a Deployment error. That seems a little restrictive if checked at deploy time because of boot order dependencies and redeployment, but if the target is not present when used then an error must be raised. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Handling of ejb-ref and ejb-local-ref
Hi There appear to be a couple of anomalies in the handling of bean references (ie ejb-ref and ejb-local-ref) elements of the web.xml and ejb-jar.xml descriptors. Firstly, the war deployer and the ejb deployer handle ejb-ref elements differently. The war deployer (org.jboss.web.AbstractWebContainer) always looks first for a jndi-name element in a matching ejb-ref element in jboss-web.xml, only falling back to looking for an ejb-link element in the ejb-jar.xml when no jndi-name has been provided. On the other hand, the ejb deployer (org.jboss.ejb.Container) always looks first for an ejb-link element, only falling back to the jndi-element if no ejb-link is specified. Both deployers should handle the ejb-ref element in the same way, and I'd argue that it is 'more correct' to look for the ejb-link name first, as this is provided in the spec, and only fallback to the application server-specific jboss.xml and jboss-web.xml descriptor elements where no ejb-link has been provided. Secondly, the handling of ejb-local-refs is very different to ejb-refs. Both the war and the ejb deployers look exclusively for an ejb-link element. Ie there is no possibility to provide the jndi-name of the referenced bean as there is with ejb-refs. Is there any reason why this is handled differently? By that I mean, why shouldn't the ejb-local-ref attempt to locate a jndi-name element in a jboss specific descriptor as a fallback? It would make things much more symmetrical if this was the case. Assuming that symmetry would be desirable, I propose an addition to the jboss-web.xml and jboss.xml descriptors to add this element: !-- The ejb-local-ref element is used to give the jndi-name of an ejb reference. This is an alternative to using ejb-link in ejb-jar.xml Used in: entity, session, and message-driven -- !ELEMENT ejb-local-ref (ejb-ref-name , jndi-name) Modifications would be necessary to several source files including org.jboss.metadata.BeanMetaData, org.jboss.metadata.EjbLocalRefMetaData, org.jboss.web.AbstractWebContainer and org.jboss.ejb.Container. If these changes are acceptable, I am almost ready to commit them, but it appears I no longer have CVS write access?? Can I get it back again to commit these changes? thanks Jan -- / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
All, I saw this behavior already too. And I had some problems porting a BEA Weblogic Application to JBoss because JBoss is looking exclusively for the ejb-link tag. The BEA application I am trying to port is using the JNDI name in the application server specific descriptor. I don't know what the spec says to local-ref but I support Jan's suggestion. --Marcus [EMAIL PROTECTED] schrieb am 07.07.03 08:44:59: Hi There appear to be a couple of anomalies in the handling of bean references (ie ejb-ref and ejb-local-ref) elements of the web.xml and ejb-jar.xml descriptors. Firstly, the war deployer and the ejb deployer handle ejb-ref elements differently. The war deployer (org.jboss.web.AbstractWebContainer) always looks first for a jndi-name element in a matching ejb-ref element in jboss-web.xml, only falling back to looking for an ejb-link element in the ejb-jar.xml when no jndi-name has been provided. On the other hand, the ejb deployer (org.jboss.ejb.Container) always looks first for an ejb-link element, only falling back to the jndi-element if no ejb-link is specified. Both deployers should handle the ejb-ref element in the same way, and I'd argue that it is 'more correct' to look for the ejb-link name first, as this is provided in the spec, and only fallback to the application server-specific jboss.xml and jboss-web.xml descriptor elements where no ejb-link has been provided. Secondly, the handling of ejb-local-refs is very different to ejb-refs. Both the war and the ejb deployers look exclusively for an ejb-link element. Ie there is no possibility to provide the jndi-name of the referenced bean as there is with ejb-refs. Is there any reason why this is handled differently? By that I mean, why shouldn't the ejb-local-ref attempt to locate a jndi-name element in a jboss specific descriptor as a fallback? It would make things much more symmetrical if this was the case. Assuming that symmetry would be desirable, I propose an addition to the jboss-web.xml and jboss.xml descriptors to add this element: !-- The ejb-local-ref element is used to give the jndi-name of an ejb reference. This is an alternative to using ejb-link in ejb-jar.xml Used in: entity, session, and message-driven -- !ELEMENT ejb-local-ref (ejb-ref-name , jndi-name) Modifications would be necessary to several source files including org.jboss.metadata.BeanMetaData, org.jboss.metadata.EjbLocalRefMetaData, org.jboss.web.AbstractWebContainer and org.jboss.ejb.Container. If these changes are acceptable, I am almost ready to commit them, but it appears I no longer have CVS write access?? Can I get it back again to commit these changes? thanks Jan -- / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Mit der Auslands-SMS von WEB.DE FreeMail erreichen Sie Ihre Freunde auf der ganzen Welt - http://freemail.web.de/features/?mc=021171 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
On Mon, 2003-07-07 at 07:38, Jan Bartel wrote: Hi There appear to be a couple of anomalies in the handling of bean references (ie ejb-ref and ejb-local-ref) elements of the web.xml and ejb-jar.xml descriptors. Firstly, the war deployer and the ejb deployer handle ejb-ref elements differently. The war deployer (org.jboss.web.AbstractWebContainer) always looks first for a jndi-name element in a matching ejb-ref element in jboss-web.xml, only falling back to looking for an ejb-link element in the ejb-jar.xml when no jndi-name has been provided. On the other hand, the ejb deployer (org.jboss.ejb.Container) always looks first for an ejb-link element, only falling back to the jndi-element if no ejb-link is specified. Both deployers should handle the ejb-ref element in the same way, and I'd argue that it is 'more correct' to look for the ejb-link name first, as this is provided in the spec, and only fallback to the application server-specific jboss.xml and jboss-web.xml descriptor elements where no ejb-link has been provided. Making that change would break previously working configurations, where both are specified and it is inconsistent. IMHO if the user specifies a jndi-name it should be used, it provides an exact binding. Unless the url#ejb-name format is used, ejb-link is not as deterministic. The best way to cater for this change would be to provide an option on the ejb deployer for the old behaviour. Secondly, the handling of ejb-local-refs is very different to ejb-refs. Both the war and the ejb deployers look exclusively for an ejb-link element. Ie there is no possibility to provide the jndi-name of the referenced bean as there is with ejb-refs. Is there any reason why this is handled differently? By that I mean, why shouldn't the ejb-local-ref attempt to locate a jndi-name element in a jboss specific descriptor as a fallback? It would make things much more symmetrical if this was the case. Assuming that symmetry would be desirable, I propose an addition to the jboss-web.xml and jboss.xml descriptors to add this element: !-- The ejb-local-ref element is used to give the jndi-name of an ejb reference. This is an alternative to using ejb-link in ejb-jar.xml Used in: entity, session, and message-driven -- !ELEMENT ejb-local-ref (ejb-ref-name , jndi-name) Modifications would be necessary to several source files including org.jboss.metadata.BeanMetaData, org.jboss.metadata.EjbLocalRefMetaData, org.jboss.web.AbstractWebContainer and org.jboss.ejb.Container. If these changes are acceptable, I am almost ready to commit them, but it appears I no longer have CVS write access?? Can I get it back again to commit these changes? ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. thanks Jan -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Reply in-line. Adrian Brock wrote: On Mon, 2003-07-07 at 07:38, Jan Bartel wrote: Hi There appear to be a couple of anomalies in the handling of bean references (ie ejb-ref and ejb-local-ref) elements of the web.xml and ejb-jar.xml descriptors. Firstly, the war deployer and the ejb deployer handle ejb-ref elements differently. The war deployer (org.jboss.web.AbstractWebContainer) always looks first for a jndi-name element in a matching ejb-ref element in jboss-web.xml, only falling back to looking for an ejb-link element in the ejb-jar.xml when no jndi-name has been provided. On the other hand, the ejb deployer (org.jboss.ejb.Container) always looks first for an ejb-link element, only falling back to the jndi-element if no ejb-link is specified. Both deployers should handle the ejb-ref element in the same way, and I'd argue that it is 'more correct' to look for the ejb-link name first, as this is provided in the spec, and only fallback to the application server-specific jboss.xml and jboss-web.xml descriptor elements where no ejb-link has been provided. Making that change would break previously working configurations, where both are specified and it is inconsistent. IMHO if the user specifies a jndi-name it should be used, it provides an exact binding. Unless the url#ejb-name format is used, ejb-link is not as deterministic. OK, fine we could elect to always try the jboss specific mechanism of jndi-name first, and fallback to the ejb-link name. But, you do agree that this should be consistent between war and ejb, right? The best way to cater for this change would be to provide an option on the ejb deployer for the old behaviour. What about an approach whereby both war and ejb deployers always try the jndi-name first, and if there is none specificied, or if the jndi-name is not bound, or if the jndi-name is bound to the wrong home class, we fallback to the ejb-link name? That wouldn't require any extra config switches and would cover the situation where beans in existing deployments have specified both and the jndi-name is wrong. Secondly, the handling of ejb-local-refs is very different to ejb-refs. Both the war and the ejb deployers look exclusively for an ejb-link element. Ie there is no possibility to provide the jndi-name of the referenced bean as there is with ejb-refs. Is there any reason why this is handled differently? By that I mean, why shouldn't the ejb-local-ref attempt to locate a jndi-name element in a jboss specific descriptor as a fallback? It would make things much more symmetrical if this was the case. Assuming that symmetry would be desirable, I propose an addition to the jboss-web.xml and jboss.xml descriptors to add this element: !-- The ejb-local-ref element is used to give the jndi-name of an ejb reference. This is an alternative to using ejb-link in ejb-jar.xml Used in: entity, session, and message-driven -- !ELEMENT ejb-local-ref (ejb-ref-name , jndi-name) Modifications would be necessary to several source files including org.jboss.metadata.BeanMetaData, org.jboss.metadata.EjbLocalRefMetaData, org.jboss.web.AbstractWebContainer and org.jboss.ejb.Container. If these changes are acceptable, I am almost ready to commit them, but it appears I no longer have CVS write access?? Can I get it back again to commit these changes? ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? cheers, Jan -- / * Jan Bartel [EMAIL PROTECTED] * Associate * Core Developers Network LLC * http://www.coredevelopers.net / --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Jan Bartel wrote: IMHO if the user specifies a jndi-name it should be used, it provides an exact binding. Unless the url#ejb-name format is used, ejb-link is not as deterministic. OK, fine we could elect to always try the jboss specific mechanism of jndi-name first, and fallback to the ejb-link name. But, you do agree that this should be consistent between war and ejb, right? ... What about an approach whereby both war and ejb deployers always try the jndi-name first, and if there is none specificied, or if the jndi-name is not bound, or if the jndi-name is bound to the wrong home class, we fallback to the ejb-link name? That wouldn't require any extra config switches and would cover the situation where beans in existing deployments have specified both and the jndi-name is wrong. I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Scott Stark wrote: What about an approach whereby both war and ejb deployers always try the jndi-name first, and if there is none specificied, or if the jndi-name is not bound, or if the jndi-name is bound to the wrong home class, we fallback to the ejb-link name? That wouldn't require any extra config switches and would cover the situation where beans in existing deployments have specified both and the jndi-name is wrong. I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during deployment. Therefore, use the ejb-link first, and if none is specified, use the jndi-name. To maintain the current behavior add a flag to the war deployer which treats failures to resolve ejb-links as deployment errors. This would be false by default in which case a failure to resolve an ejb-link triggers fallback to the use of the jndi-name. I disagee with the last bit here. If ejb-link is specified and the target EJB does not exist in the current deployment, then it should definitely be a deployment error as the standard descriptor was mis-assembled. Any flag should be to turn this behaviour off and allow a mis-configured deployment to drop through to the [local-]jndi-name; this should apply to the EJB deployer as well for consistency. If no ejb-link is specified, then a [local-]jndi-name must be specified. If it is not, then it's a deployment error (as it is now for EJBs and should be for WARs) as there is no sensible default (well, maybe the ejb-ref-name less any ejb/). ejb-local-refs are only intended for ejbs in the same deployment so ejb-link should suffice, but the spec is not very explicit. The way jboss works, this won't be a problem. It should not break any existing deployments. Sorry, but I'm not sure what you mean - do you mean that you are or aren't in favour of making the handling consistent, and therefore introducing the ejb-local-ref element? There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: !ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type, local-home, local, ejb-link?) ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Jeremy /* * Jeremy Boynes * Partner * Core Developers Network */ --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
