@LocalBean and implied local interface change

[David Blevins <da...@visi.com>]

Heads up to the group that I had to make a backwards incompatible change to the interface processing.  

Specifically some interfaces that were previously treated implicitly as @Local now will need the @Local annotation.  I hope we can add a backwards compatible flag before we release -- easy to do, we just need a nice name for it and to test it.

Per the strict rules of the spec this has always been allowed:

  public interface Color {}
  
  public class ColorBean implements Color {
  }

Here, Color is implied to be an @Local interface.  But per spec rules, this was considered an error:

  public interface Color {}
  public interface Colour {}
  
  public class ColorBean implements Color, Colour {
  }

We've always treated that as two @Local interfaces.  Additionally, this has also been illegal per-spec, but allowed by us:

  public interface Color {}
  
  public class ColorBean implements Color {
  }

  public class RedBean extends ColorBean {
  }

In this scenario we would imply the RedBean to have one @Local interface, Color.

It's specifically this last scenario that is somewhat at odds with the current spec notions.  In the new rules the above RedBean would be considered an @LocalBean with no other views (i.e. no @Local interface).  If we imply the RedBean to have a business local interface Color, it breaks compatibility with the TCK.  In an incredibly harmless way to be sure, but still.

Anyway, having thought about it for a while it seemed less terrible to me, since RedBean would now be treated as an @LocalBean it will automatically have all the java type of the super class and all interfaces implemented, so the proxy itself will have no loss in functionality -- you will still be able to cast it to Color.

Where there is a loss in functionality is in how it can be referenced.  Namely, this will no longer work:

  public class AnotherBean {
  
      @EJB Color colorBean;
  }

Since the RedBean doesn't have a Color business local interface in a strict sense, this reference will not work.  Here's where we should make an improvement to our @EJB processing code (EjbResolver).

Ideally, a reference like '@EJB Color colorBean' would still work because the bean has a view (the @LocalBean view) which is of a type that is assignable to Color.

This isn't required for TCK compliance, but definitely something we should add so that there is as little breakage as possible.

We should also add a flag so that unclassified interfaces still get treated as @Local as the did before.  Anyone have a name suggestion?

Off the top of my head:

  openejb.imply.businesslocal
  openejb.interface.businesslocal.implied (default would be false)
  openejb.interface.businesslocal.strict (default would be true)

Something....  Open to ideas.  Note we already have a related:

  openejb.strict.interface.declaration

Which when set follows the spec rules rigidly.  When not set, we try to offer as much functionality as possible without making the TCK angry :)

Maybe we want to go with something that at least starts with "openejb.interface." so that if we have other things people might want to turn on/off, the properties would at least be sort of logically grouped.

Course, now that I think of it our 'Options' util class supports converting a previously true/false option into an java enum.  'true' implies all enum options, 'false' implies none.  And individual options can be listed to more specifically configure behavior.  So if we go with that thinking (might be overkill, so who knows), we could end up with something like this:

 openejb.strict.interface.declaration=local, inheritance, mixed

Where 'local' would tell us if we should be strict with requiring @Local.  The 'inheritance' would tell us if we should consider interfaces and annotations in super classes.  And 'mixed' might tell us if we should allow an interface to be both @Remote and @Local.  So again, 'true' would imply all options, and 'false' would imply non.  The default would be 'local' for compatibility reasons.  That pretty much covers what we currently use the strict flag for.

Might be a little specific, but on the positive side there will be fewer actual properties for users to learn about.

Thoughts?


-David