You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2010/10/07 18:42:56 UTC

Connector and Bean Validation support.

  I've finally gotten the code I've been working on for adding Bean 
Validation support to the Geronimo connector component working well 
enough that the server will come up.  I've attached patches to the Jira 
showing what I've changed.

https://issues.apache.org/jira/browse/GERONIMO-5230

I'd love a review and comments from anybody who has time to look at 
this.  I also have a couple of questions about whether this is complete 
enough or not:

1)  In general, I've added the validation code to the connector 
component.  Each of the bean wrapper classes now takes an optional 
ValidatorFactory instance and uses that be validate the object instance 
before it is started.  The one exception to this is the AdminObject 
beans.  The AdminObjectWrapper class only exists in Geronimo and is 
directly a GBean.  For the other object types, the wrapper class is 
implemented in the connector component, and the Geronimo code subclasses 
the wrapper to make it into a GBean and adds the additional GBean 
lifecycle methods.  I'm thinking that the AdminObjectWrapper class 
should be refactored the same way so that these objects are also 
directly validated by the connector component.  That is, much of the 
existing AdminObjectWrapper should be moved to the connector component, 
and then Geronimo will create an appropriate GBean wrapper for the object.

2)  I see that OpenEJB has a bit of code that deals with 
ActivationSpecs.  Do these OpenEJB ActivationSpec instances get wrapped 
up with ActivationSpecWrappers on the Geronimo side, or is there some 
additional validation support that needs to be implemented inside of 
OpenEJB?  I don't have a very clear picture on how things interoperate 
at this level.

Rick

Re: Connector and Bean Validation support.

Posted by David Jencks <da...@yahoo.com>.
On Oct 7, 2010, at 9:42 AM, Rick McGuire wrote:

> I've finally gotten the code I've been working on for adding Bean Validation support to the Geronimo connector component working well enough that the server will come up.  I've attached patches to the Jira showing what I've changed.
> 
> https://issues.apache.org/jira/browse/GERONIMO-5230
> 
> I'd love a review and comments from anybody who has time to look at this.  I also have a couple of questions about whether this is complete enough or not:

I'll take a look, may be a couple days.  I think if you're happy with the code you should commit it.

> 
> 1)  In general, I've added the validation code to the connector component.  Each of the bean wrapper classes now takes an optional ValidatorFactory instance and uses that be validate the object instance before it is started.  The one exception to this is the AdminObject beans.  The AdminObjectWrapper class only exists in Geronimo and is directly a GBean.  For the other object types, the wrapper class is implemented in the connector component, and the Geronimo code subclasses the wrapper to make it into a GBean and adds the additional GBean lifecycle methods.  I'm thinking that the AdminObjectWrapper class should be refactored the same way so that these objects are also directly validated by the connector component.  That is, much of the existing AdminObjectWrapper should be moved to the connector component, and then Geronimo will create an appropriate GBean wrapper for the object.

I think this would be a good idea.

> 
> 2)  I see that OpenEJB has a bit of code that deals with ActivationSpecs.  Do these OpenEJB ActivationSpec instances get wrapped up with ActivationSpecWrappers on the Geronimo side, or is there some additional validation support that needs to be implemented inside of OpenEJB?  I don't have a very clear picture on how things interoperate at this level.

The openejb code does not relate to the ActivationSpecWrapper.  You'd probably need an interface in openejb, but I wonder if we should have openejb delegate creating the activation spec to the oonnector component.

david jencks

> 
> Rick