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)
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
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,
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
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
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
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
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
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
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.
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
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
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
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
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
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
16 matches
Mail list logo
