Validation of Complete EJB2.x Views: EJB3 or Metadata?

[alrubinger]

Which component should be responsible for validating an EJB2.x View as dictated by EJBTHREE-1075?

The rules:

1) If EJBHome/EJBLocalHome is defined, at least one EJBObject/EJBLocalObject is defined.
2) If one EJBObject/EJBLocalObject is defined, an EJBHome/EJBLocalHome is defined.
3) SLSB EJB2.x Home interface returns only valid remote interface (EJBObject) from "create" method
4) SLSB EJB2.x LocalHome interface returns only valid local interface (EJBLocalObject) from "create" method
5) SFSB EJB2.x Home interface returns only valid remote interfaces (EJBObject) from "create{METHOD}" methods
6) SFSB EJB2.x LocalHome interface returns only valid local interfaces (EJBLocalObject) from "create{METHOD}" methods

Currently this is done in EJB3 Core. Should either move to Proxy or be handled by jboss-metadata.

Leaning towards EJB3 Proxy to test these conditions as they are EJB3 Spec Rules, though since jboss-metadata is already doing some checks I wonder if they should be placed together.

S,
ALR

[alrubinger]

Note that in 2), this would already be taken care of given my suggestion to not support local/remote EJB2.x interfaces in @Local/@Remote; in Home would be the only place they could be defined.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
Leaning towards EJB3 Proxy to test these conditions as they are EJB3 Spec Rules

I revoke that. jboss-metadata is already doing JBMETA-41 to achieve EJB3 Core Spec 3.6.2.1, so jboss-metadata has become the authority to ensure metadata is not only defined, but valid. So I'd like to see these checks in there.

S,
ALR

[wolfc]

Some things can not be checked in metadata, because they require the correct class loader.

For example whether a remote interface is really an interface and extends EJBObject.

This is different for the annotation meta data creator, it has classes to work with. So it can do more checks. As a post condition it should not be allowed to create invalid meta data.

I think the validations should be in jboss-metadata, but care must be taken that they should not be intertwined with code that performs a different function.

In the end, somewhere in the deployer chain something like:

Set<InvalidConstraint<JBossMetaData>> violations = someValidator.validate(jbossMetaData, "ejb3");

should occur.

[emuckenhuber]

Well at the moment i have put some validation in the AnnotationProcessors, as there were some checks in other processors too.
Although doing those checks would lead to some regressions in the metadata test as there are some few declarations like:

@Remote(Multiview21Remote.class)

Just let me know if i should enable or disable those, because i don't know if this would create more regressions somewhere else.

[alrubinger]

"wolfc" wrote:
Some things can not be checked in metadata, because they require the correct class loader.

I'd intended for these to be done from the context of the Annotation Processing Deployers, where the CL is available.

"wolfc" wrote:
In the end, somewhere in the deployer chain something like:

Set<InvalidConstraint<JBossMetaData>> violations = someValidator.validate(jbossMetaData, "ejb3");

should occur.

How about:

Set<InvalidConstraint<JBossMetaData>> violations = new HashSet<InvalidConstraint<JBossMetaData>>();
violations.addAll(ejb21ViewCompleteValidator.validate(jbossMetaData));
violations.addAll(validBusinessInterfaceValidator.validate(jbossMetaData));
violations.addAll(validEjb21InterfaceValidator.validate(jbossMetaData));
...etc...

Then we can process all the validation failures and report them to the bean developer together, as opposed to failing on the first error only and hiding the rest.

S,
ALR

[alrubinger]

"emuckenhuber" wrote:
Just let me know if i should enable or disable those, because i don't know if this would create more regressions somewhere else.

I'm unclear as to what you'd like to enable/disable, and why the regressions would be present.

If:

1) You introduce a new check
2) The check is valid
3) This results in TestSuite regression

Then you've exposed a problem with the TestSuite and have strengthened it.

S,
ALR

[wolfc]

I'm assuming that 'someValidator' is a facade for all validations. :-)

[emuckenhuber]

"ALRubinger" wrote:

I'm unclear as to what you'd like to enable/disable, and why the regressions would be present.

Actually i meant doing the validation for JBMETA-41 - which results in a regression as some test provided are wrong.

"ALRubinger" wrote:

If:
1) You introduce a new check
2) The check is valid
3) This results in TestSuite regression

Then you've exposed a problem with the TestSuite and have strengthened it.

So i will correct that.

Thanks,
Emanuel