-
1. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
wolfc Jul 2, 2008 4:12 AM (in response to alrubinger)The point of JBossSessionPolicyDecorator is to hide the fact that there is a binding policy from the user code. Thus it introduces a new piece of functionality without affecting any EJB3 code. (Which is the basis of a decorator pattern.)
-
2. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 2, 2008 11:58 AM (in response to alrubinger)After the decorator is instanciated, the policy is hidden.
Are you drawing a critique or clarifying a point? The decorator adds new functionality by implementing "ResolveableJndiNameJbossEnterpriseBeanMetadata" methods on existing metadata, giving it the ability to figure out target JNDI names without impacting the Object Model itself.
S,
ALR -
3. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
wolfc Jul 2, 2008 12:38 PM (in response to alrubinger)As shown in the following change the decorator no longer adheres to the API:
public void testHome() { - String actual = sessionBeanMetaData.getHomeJndiName(); + String actual = JbossSessionBeanJndiNameResolver.resolveRemoteHomeJndiName(sessionBeanMetaData); assertEquals("MyStatelessBean/home", actual); }
The point of the decorator is to hide this function completely, without any API change. -
4. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 2, 2008 1:14 PM (in response to alrubinger)This should be no problem. I was decorating by enhancement, but I can also redirect the "getJndiName", "getLocalJndiName", "getHomeJndiName", and "getLocalHomeJndiName" methods to use the new logic.
S,
ALR -
5. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 2, 2008 4:13 PM (in response to alrubinger)So I've verified this stays intact without API changes. The test now looks like:
String actual = JbossSessionBeanJndiNameResolver.resolveRemoteHomeJndiName(sessionBeanMetaData); String fromBean = sessionBeanMetaData.getHomeJndiName(); assertEquals("MyStatelessBean/home", actual); assertEquals(actual, fromBean);
Updating the patch on the ticket.
S,
ALR -
6. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
wolfc Jul 3, 2008 3:38 AM (in response to alrubinger)You should not create an artifact that's not compatible with CR1.
The determine methods should become deprecated and delegate to the new way of things. -
7. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 3, 2008 4:02 AM (in response to alrubinger)In theory, sure. But in practice, no one's going to honor the @Deprecated warnings, and in the meantime we'll still have JNDI logic to debug if I keep the "determine" methods in place.
I wanted big glaring compile errors for all cases where the Object Model was being asked to perform logic it shouldn't be doing, and it made resolving these problems much easier. I've attached the AS patch to the JIRA as well.
For whom do we want to maintain backwards-compatibility? Ourselves? We should be moving everything to the more elegant way of doing things.
That in mind, what's the argument for CR1 compatibility (with regards to metadata and JNDI names only, not a general discussion)?
S,
ALR -
8. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 3, 2008 2:24 PM (in response to alrubinger)Any objections to putting the deployer that decorates metadata with a JNDI Policy within EJB3 Core as opposed to AS "ejb3" module?
S,
ALR -
9. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
wolfc Jul 3, 2008 5:34 PM (in response to alrubinger)Suppose we want to try out a release of the EJB3 plugin?
Neither. The JNDI policy is also meant for EJB2. So the server module is the place to put it in at the moment. -
10. Re: [jboss-metadata] Decoupling JNDI Logic from Object Model
alrubinger Jul 8, 2008 1:10 AM (in response to alrubinger)I've committed to jboss-metadata the patch that removes JNDI name resolution logic from the object model. Still in place should be backwards-compatible methods, marked as @Deprecated, forwarding to new logic (as appropriate), and WARN-level logging.
The revamped "ResolveJndiNameDecoratorUnitTestCase" should handle the new logic alongside legacy handling, testing each works.
S,
ALR