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
