Validation-api X hibernate-validation-impl about hurraa HOT 18 CLOSED

I'm in favor of javax.validation.constraints.NotNull

from hurraa.

I'm in favor to use the API ( hibernate validation or any other ), it will
provide a lot of already implemented validations, in other hand if we do
not use the API, we will have to implement our custom validation like the
@notblank and others simple validations that will be needed, ofcourse that
is not realy hard but we will lose time with a already made thing, and is
good API ( hibernate right! ).

Is preferable what we focus on functionalities, and not making the spec
work.

2014-02-06 4:51 GMT-03:00 Hildeberto Mendonça [email protected]:

I'm in favor of javax.validation.constraints.NotNull

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34299778
.

Atenciosamente,
Efraim Gentil - @efraimgentil https://twitter.com/efraimgentil
Github: efriamgentil https://github.com/efraimgentil

from hurraa.

Is preferable what we focus on functionalities, and not making the spec work.
👍

About the JAR:
WF CR1 is using hibernate-validator-5.0.2.Final.jar
maybe add scope provided on pom.xml right ?

About the API:
For me on this project, whatever, features are more important.

http://stackoverflow.com/questions/10684088/missing-notblank-in-jsr-303-how-to-emulate

from hurraa.

Then I think we made a wrong decision by opting for JavaEE 7. If we want to use any library we want, then it's better to migrate Hurraa to Spring as soon as possible. There is no point on having the specs within WildFly and not using them. Tomcat and Spring with give the freedom everybody is asking for.

In this case, CEJUG will contribute to the Java EE specification in another project.

from hurraa.

"There is no point on having the specs within WildFly and not using them"
👍

"Then I think we made a wrong decision by opting for JavaEE 7"
+-

Another question:
If spec api not solve one problem we need/must wast time with workarounds ?

My opinion : no.

from hurraa.

Maybe we can create a separeted project that will focus con the JSR 303 and
make a good implementation of it, if it goes in the right direction we
integrate the two project... i don't know it is a idea...

I realy want to get to work with JSR 303, but i think it just don't fit in
the hurraa right now.

2014-02-06 12:43 GMT-03:00 Hildeberto Mendonça [email protected]:

Then I think we made a wrong decision by opting for JavaEE 7. If we want
to use any library we want, then it's better to migrate Hurraa to Spring as
soon as possible. There is no point on having the specs within WildFly and
not using them. Tomcat and Spring with give the freedom everybody is asking
for.

In this case, CEJUG will contribute to the Java EE specification in
another project.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34335644
.

Atenciosamente,
Efraim Gentil - @efraimgentil https://twitter.com/efraimgentil
Github: efriamgentil https://github.com/efraimgentil

from hurraa.

You guys should move to Spring as soon as possible. Postpone this decision will be a problem in the future. It should be done while the project is still small.

from hurraa.

The point that we will use bean validation is not a doubt, we will use it,
the spring can use it too but i believe the point is we will have to
implement each validation from the scratch or use some already made?

We are already using JSR 303 to make some custom validation in the
EquipmentModel CRUD, and will be used in others to validade uniqueness and
others things too.
But if we going to make reusables annotations i think it is better if we
make in a separated project so we can reutilise in others projects CEJUG

2014-02-06 13:07 GMT-03:00 Hildeberto Mendonça [email protected]:

You guys should move to Spring as soon as possible. Postpone this decision
will be a problem in the future. It should be done while the project is
still small.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34338239
.

Atenciosamente,
Efraim Gentil - @efraimgentil https://twitter.com/efraimgentil
Github: efriamgentil https://github.com/efraimgentil

from hurraa.

When I use validator in model, this validating is valid to faces and jpa.
But, we can use a method parameter validator, as this:

public class OrderService {

    public OrderService(@NotNull CreditCardProcessor creditCardProcessor) {
        //...
    }

    public void placeOrder(@NotNull @Size(min=3, max=20) String customerCode, 
                           @NotNull Item item, @Min(1) int quantity) {
        //...
    }
}

With this method is possible to validate the requests in vRaptor controller class?

Ps: I don't speak english very well.. I'll improve my english with you. :-)

from hurraa.

Yes you can!

2014-02-06 14:10 GMT-03:00 Daniel Cunha [email protected]:

When I use validator in model, this validating is valid to faces and jpa.
But, we can use a method parameter validator, as this:

public class OrderService {

public OrderService(@NotNull CreditCardProcessor creditCardProcessor) {
    //...
}

public void placeOrder(@NotNull @Size(min=3, max=20) String customerCode,
                       @NotNull Item item, @Min(1) int quantity) {
    //...
}}

With this method is possible to validate the requests in vRaptor
controller class?

Ps: I don't speak english very well.. I'll improve my english with you. :-)

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34345904
.

Atenciosamente,
Efraim Gentil - @efraimgentil https://twitter.com/efraimgentil
Github: efriamgentil https://github.com/efraimgentil

from hurraa.

It's not that we are going to write each validation from scratch. Of course Hibernate is more complete than the Bean Validation, but if we don't use the JSR 303 we will never know its weaknesses and we won't be able to contribute on its evolution. Therefore, the Hurraa project will not have any concrete international contribution for the community.

If it was a real company with money involved I would certainly recommend Hibernate for validation. But it is a community project that could also have the goal of evolving all technologies around it.

But if you guys believe that it is possible to contribute to Hibernate and have CEJUG members as committers there, why not? But I personally believe that by adopting the JSRs we have a better chance to contribute because we would know the issues and we have contacts there.

Just my two cents.

from hurraa.

for me whatever, but use app server with redundant impl is not good.
and wast time with 'workaround' too.

from hurraa.

Look, lets make the things going. Our contribution with the JSR can be suggesting new functionalities and using what they already have. Use @NotNull and use @NotEmpty can be done. And our contribution with JSR 303 is asking why they don't have NotEmpty and making this become a specification. I don't see problem with it. Our server goal is WildFly, so if it provides Hibernate Validation, we use both (javax.validation and org.hibernate) until JSR has it.
@htmfilho, no body needs to move to Spring only because a validation. We can use only what BV have, but this can be limited some times when developers want to show his creation on the code.

from hurraa.

@paulojribp
"Look, lets make the things going. "

"Our server goal is WildFly, so if it provides Hibernate Validation, we use both (javax.validation and org.hibernate) until JSR has it."

For me is perfect, but i start this question because we need to make the things clear and get opinions from the others.

This discussion was started on IRC with @efraimgentil who agreed at to share on github.

Going to close this issue

from hurraa.

Guys! I've noticed we're having too much discussions like this here and in
the mailing list. The only way to avoid this for the benefit of the project
is going to Spring. To make Hurraa free to use the best of the best, only
Spring can do this.
On Feb 6, 2014 7:46 PM, "eprogramming" [email protected] wrote:

for me whatever, but use app server with redundant impl is not good.
and wast time with 'workaround' too.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34355969
.

from hurraa.

Hildeberto, this is not about Spring or JEE. This is about a single JSR and a framework called Hibernate. Spring has nothing to do with.
Just understand that this is a Good think to contribute with JSR. It is excludent.

from hurraa.

Ops... It is NOT excludent.

from hurraa.

That's ok. Let's move on. I sent the message when the issue was already
closed. Sorry.
On Feb 6, 2014 11:39 PM, "Paulo A Junior" [email protected] wrote:

Hildeberto, this is not about Spring or JEE. This is about a single JSR
and a framework called Hibernate. Spring has nothing to do with.
Just understand that this is a Good think to contribute with JSR. It is
excludent.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-34383017
.

from hurraa.