HI Karan... I know that commons validation was not originally made for EJB validation tasks, but from what I've read yesterday I think it can be changed to our needs, or at least we can take the idea being the validation tasks can be configured using XML files, at that point people can really download the lasted rules from whatever source we provide them, and in OpenEJB we will provide an engine which will parse those rules and validate them against a deployed module. So this way we provided both ideas
1- The validator being configurable wihout the need to change the code and make another set of binaries. 2- The code itself of the validation is distributed with OpenEJB as I suggested. what do u think ? On Mon, Mar 17, 2008 at 8:41 PM, Karan Malhi <[EMAIL PROTECTED]> wrote: > Thanks Mohammad, > > Not sure how commons validator would help in this scenario. Commons > validator is a different kind of validation, whereas I was talking more from > the perpective of checking if the ejb jar itself was valid. For example, a > SLSB not having a corresponding interface , or using an annotation in the > wrong location. > > Regarding validation being part of OpenEJB, I definitely agree with that. I > was thinking that maybe we could extract a separate jar for validation which > could be enhanced without depending on a release of OpenEJB itself. The > latest version of the jar would definitely be part of an OpenEJB release, > its just between OpenEJB versions, where people might just want to upgrade > to a better validation check, they might want to bring in the latest jar for > validation without touching the rest of the installation. > > I am just over thinking probably, people can simply use the snapshot > version of OpenEJB. :) > > > > > On Mon, Mar 17, 2008 at 1:01 PM, Mohammad Nour El-Din < > [EMAIL PROTECTED]> wrote: > > > Hi Karan... > > > > There is an Apache Commons Validator component, which mostly > > designed for validating form submitted data, but it is extensible so > > we can use it as a core for our validation process. But allow me to > > disagree with you about making the validator as a separate module > > regarding distribution with OpenEJB, cause validation is a must for > > having a compliant EJB container as I remember from the specs - please > > some one corrects me if I am wrong - but I agree regarding that making > > it a separate module and it is actually a separate module on JIRA so > > we can assign enhancements issues on it. And if we found that the > > Commons Validator component can be useful for us I think we should use > > it as out validation frame-work as DBlevins used the CLI one. > > > > On Mon, Mar 17, 2008 at 6:03 PM, Karan Malhi <[EMAIL PROTECTED]> > > wrote: > > > Hi, > > > > > > Was just trying things out with validation. The more I abuse OpenEJB > > > deploy(which is actually using validation the right way if I want to > > learn > > > EJB :)) , the more I end up using validation. There are so many things > > which > > > could be done in validation itself. For example, a little framework > > could be > > > created to give a more feature rich help (interactive help etc..) . > > > However, to reach that level , lot of work would need to be done on > > this > > > feature. It would not be possible to keep the changes made to > > validation > > > with the release requirement dates of OpenEJB. So, I was thinking that > > could > > > validation be its own separate module where we could release its jars > > > separately, which could simply be dropped in into an existing OpenEJB > > > install? An OpenEJB release will have a default validation jar , lets > > say > > > 1.0 (for openejb 3.0). But we could independently update the validation > > > module and its releases and ask users to download and install the > > latest jar > > > to have the latest and greatest in validation. This way validation > > releases > > > become independent of OpenEJB releases and we can release validation > > modules > > > much more frequently. > > > Since I do not know much about the release process, so I am not sure if > > the > > > above is doable or not, or even a direction worth looking into. It > > would be > > > nice to know the pros and cons of the above approach, would be good > > learning > > > for me. > > > > > > Thanks! > > > > > > -- > > > Karan Singh Malhi > > > > > > > > > > > -- > > Thanks > > - Mohammad Nour > > > > > > -- > Karan Singh Malhi > -- Thanks - Mohammad Nour
