-
1. Re: JBMETA-42
In revision 73473 (http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=73473) I fixed 2 of the 6 Unit Tests that Carlo had committed. No regression in jboss-metadata occurred as a side effect.
However, look at the base names now found for Business Remote (specific) Interface, Business Local (specific) interface, home and local home - they've got a baseName of:
MyStatelessBean/remote
...instead of the expected:
MyStatelessBean
...when a DeploymentSummary is present.
Best I can tell is that there's a disconnect in "determineResolvedJndiName" when there's a DeploymentSummary in place, which is not always the case.
S,
ALR -
2. Re: JBMETA-42
The change to determineLocalJndiName to drop the unique System.identityHashCode portion won't be valid for ejb2 deployments where there are multiple ejb jars that have the same ejb-names for beans with local interfaces, or mdbs. The same problem should exist for ejb3 as well doesn't? How are two standalone ejb3 jars each with a LocalBean going to share the same LocalBean/local global binding?
I need to look at the tests to see what the issue is. -
3. Re: JBMETA-42
"scott.stark@jboss.org" wrote:
How are two standalone ejb3 jars each with a LocalBean going to share the same LocalBean/local global binding?
They don't. You'll get an error. -
4. Re: JBMETA-42
By default, we'll also run into Global JNDI collisions in the case that 2 EJB JARs (or EARs) are placed in different WARs.
To avoid these defaults we introduced the JndiBindingPolicies, which should have priority over the commits I made.
S,
ALR -
5. Re: JBMETA-42
Also, if I introduced something that'll present a problem for EJB2, we should have a Unit Test for it? Tests green == commit away.
S,
ALR -
6. Re: JBMETA-42
This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?
No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given. -
-
8. Re: JBMETA-42
"scott.stark@jboss.org" wrote:
This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?
No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given.
That can't be. All jndi names must be unique or you'll get a NotContextException.
As already shown by Andrews prototype, my original idea of having the object factory bound at at a base jndi name turned out to be a 'Bad Idea (tm)'.
So the tests in ResolvedJndiNameUnitTestCase are out-dated in that respect.
What I also said was that the final jndi name is overridable. So if a jndi-name is set in jboss.xml then beanMD.determineResolvedJndiName(KnownInterfaces.REMOTE, null); must return that jndi-name.
This is just plain wrong in ResolvedJndiNameUnitTestCase.
There is a side issue where JBossWS expects to find a home interface on the jndi name. This might also be the case for EJB 2.1 compatibility. -
9. Re: JBMETA-42
Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy.
As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself.
Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup? -
10. Re: JBMETA-42
"wolfc" wrote:
Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy.
As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself.
Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup?
The profile service would only store the non-XmlTransient values, so as long determineResolvedJndiName does not set something like the jndiName, mappedName, its not interfering with the administered view. -
11. Re: JBMETA-42
But does it store the orginal JBossSessionBeanMetaData, the merged one, or the final one (in this case JBossSessionPolicyDecorator)?
-
12. Re: JBMETA-42
It stores the non-transient managed attachments. Any attachments derived from the managed metadata should be transient attachments that are not stored. Merged metadata should be transient. The deployer that adds the attachment controls this.
-
13. Re: JBMETA-42
In that case I vote in favor of patch 2 and removing the JNDI policy functionality from the base JBossSessionBeanMetaData.
-