Bringing Bean Validation 2.0 to WildFly

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Bringing Bean Validation 2.0 to WildFly

Gunnar Morling
Hi,

<TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable?</TL,DR>

The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8.

I can think of two approaches:

1) Just updating the existing WildFly modules for BV API and HV to the new versions
2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0

1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API.

2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work:

* A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml
* Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user.

What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11?

Thanks,

--Gunnar



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

Martin Kouba
FYI the same applies to Weld 3.0/CDI 2 except that CDI 2.0 and Weld
3.0.0.Final were released already. Right now, we provide a patch for
both WildFly 10.1.0 and 11.0.0.Alpha1 [1].

BTW there is also SWARM-731 [2] - Investigate creation of CDI 2.0 / Weld
3.0 fractions.

Martin

[1]
http://download.jboss.org/weld/3.0.0.Final/

[2]
https://issues.jboss.org/browse/SWARM-731


Dne 13.7.2017 v 10:50 Gunnar Morling napsal(a):

> Hi,
>
> <TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0,
> or should new modules be added for those, letting the user to choose the
> version to enable?</TL,DR>
>
> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like
> to discuss how BV 2 and its reference implementation HV 6 can be
> integrated into WildFly. BV 2 will be part of Java EE 8.
>
> I can think of two approaches:
>
> 1) Just updating the existing WildFly modules for BV API and HV to the
> new versions
> 2) Leave the existing modules for BV 1.1 (+ implementation) and add
> separate modules for BV 2.0
>
> 1) would be easier and less effort. But I'm not sure how feasible it is,
> in case that WF should remain Java EE 7 compatible for the time being.
> Also, while BV 2 is fully backwards compatible at the spec-level,
> Hibernate Validator amends the spec API with some extended
> functionality. In that extended HV-specific API some changes were
> required, mostly as previous experimental features were replaced by
> equivalent standardized functionality in the BV API.
>
> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail some
> more work:
>
> * A place for that configuration is required. I think it could be done
> similarly to JPA, i.e. via a property with the module name in
> META-INF/validation.xml
> * Depending on that configuration, the right set of modules needs to be
> enabled. Several modules currently have a fixed dependency to the
> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy)
> which would have be made more dynamic, based on the version chosen by
> the user.
>
> What does everyone think on this? And what could be a suitable WildFly
> target version for such change? Could we aim at incorporating BV 2.0
> into WF 11?
>
> Thanks,
>
> --Gunnar
>
> [1]
> http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

James Perkins
In reply to this post by Gunnar Morling
I think either approach is going to have to wait until WildFly 12. We can't upgrade specs at this point unfortunately.

On Thu, Jul 13, 2017 at 1:50 AM, Gunnar Morling <[hidden email]> wrote:
Hi,

<TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable?</TL,DR>

The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8.

I can think of two approaches:

1) Just updating the existing WildFly modules for BV API and HV to the new versions
2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0

1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API.

2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work:

* A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml
* Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user.

What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11?

Thanks,

--Gunnar



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

Emmanuel Bernard
In reply to this post by Gunnar Morling
Barring other constraints, I would think we would want to move forward to the latest in the next WF major. What’s the point of holding up technology? Likewise there is very little value in keeping the old one in in parallel. More knobs and more pain in the subsystems.

On 13 Jul 2017, at 10:50, Gunnar Morling <[hidden email]> wrote:

Hi,

<TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable?</TL,DR>

The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8.

I can think of two approaches:

1) Just updating the existing WildFly modules for BV API and HV to the new versions
2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0

1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API.

2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work:

* A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml
* Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user.

What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11?

Thanks,

--Gunnar


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

Tomaž Cerar-2
In reply to this post by Gunnar Morling
Any work on such features is something that cannot go into 11, as we are mostly at cut-off point with development.

Such work should target WildFly 12.



On Thu, Jul 13, 2017 at 10:50 AM, Gunnar Morling <[hidden email]> wrote:
Hi,

<TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0, or should new modules be added for those, letting the user to choose the version to enable?</TL,DR>

The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like to discuss how BV 2 and its reference implementation HV 6 can be integrated into WildFly. BV 2 will be part of Java EE 8.

I can think of two approaches:

1) Just updating the existing WildFly modules for BV API and HV to the new versions
2) Leave the existing modules for BV 1.1 (+ implementation) and add separate modules for BV 2.0

1) would be easier and less effort. But I'm not sure how feasible it is, in case that WF should remain Java EE 7 compatible for the time being. Also, while BV 2 is fully backwards compatible at the spec-level, Hibernate Validator amends the spec API with some extended functionality. In that extended HV-specific API some changes were required, mostly as previous experimental features were replaced by equivalent standardized functionality in the BV API.

2) would let the user chose between BV 1.1 and 2.0, but it'd entail some more work:

* A place for that configuration is required. I think it could be done similarly to JPA, i.e. via a property with the module name in META-INF/validation.xml
* Depending on that configuration, the right set of modules needs to be enabled. Several modules currently have a fixed dependency to the "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy) which would have be made more dynamic, based on the version chosen by the user.

What does everyone think on this? And what could be a suitable WildFly target version for such change? Could we aim at incorporating BV 2.0 into WF 11?

Thanks,

--Gunnar



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

Tristan Tarrant
In reply to this post by Emmanuel Bernard
+1.

Where are the Alphas (aside from Alpha1), the Betas, the CRs for WildFly
11 ?

Tristan

On 7/13/17 7:06 PM, Emmanuel Bernard wrote:

> Barring other constraints, I would think we would want to move forward
> to the latest in the next WF major. What’s the point of holding up
> technology? Likewise there is very little value in keeping the old one
> in in parallel. More knobs and more pain in the subsystems.
>
>> On 13 Jul 2017, at 10:50, Gunnar Morling <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> <TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0,
>> or should new modules be added for those, letting the user to choose
>> the version to enable?</TL,DR>
>>
>> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like
>> to discuss how BV 2 and its reference implementation HV 6 can be
>> integrated into WildFly. BV 2 will be part of Java EE 8.
>>
>> I can think of two approaches:
>>
>> 1) Just updating the existing WildFly modules for BV API and HV to the
>> new versions
>> 2) Leave the existing modules for BV 1.1 (+ implementation) and add
>> separate modules for BV 2.0
>>
>> 1) would be easier and less effort. But I'm not sure how feasible it
>> is, in case that WF should remain Java EE 7 compatible for the time
>> being. Also, while BV 2 is fully backwards compatible at the
>> spec-level, Hibernate Validator amends the spec API with some extended
>> functionality. In that extended HV-specific API some changes were
>> required, mostly as previous experimental features were replaced by
>> equivalent standardized functionality in the BV API.
>>
>> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail
>> some more work:
>>
>> * A place for that configuration is required. I think it could be done
>> similarly to JPA, i.e. via a property with the module name in
>> META-INF/validation.xml
>> * Depending on that configuration, the right set of modules needs to
>> be enabled. Several modules currently have a fixed dependency to the
>> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy)
>> which would have be made more dynamic, based on the version chosen by
>> the user.
>>
>> What does everyone think on this? And what could be a suitable WildFly
>> target version for such change? Could we aim at incorporating BV 2.0
>> into WF 11?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bringing Bean Validation 2.0 to WildFly

Gunnar Morling
I was wondering the same thing; just from looking at it from the outside, being after Alpha1 seems like the right time to do this kind of update.

Also is there any public schedule available for WF 11 and 12? It'd be sad if we could get BV 2 into WF only in a year or so (wildly guessing here when to expect WF 12), while e.g. Spring 5 with BV 2 support is planned to be released this summer.

--Gunnar



2017-07-14 18:38 GMT+03:00 Tristan Tarrant <[hidden email]>:
+1.

Where are the Alphas (aside from Alpha1), the Betas, the CRs for WildFly
11 ?

Tristan

On 7/13/17 7:06 PM, Emmanuel Bernard wrote:
> Barring other constraints, I would think we would want to move forward
> to the latest in the next WF major. What’s the point of holding up
> technology? Likewise there is very little value in keeping the old one
> in in parallel. More knobs and more pain in the subsystems.
>
>> On 13 Jul 2017, at 10:50, Gunnar Morling <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> <TL,DR>Should we update WildFly to BV 2.0 and Hibernate Validator 6.0,
>> or should new modules be added for those, letting the user to choose
>> the version to enable?</TL,DR>
>>
>> The Bean Validation 2.0 spec (JSR 380) is almost done [1], so I'd like
>> to discuss how BV 2 and its reference implementation HV 6 can be
>> integrated into WildFly. BV 2 will be part of Java EE 8.
>>
>> I can think of two approaches:
>>
>> 1) Just updating the existing WildFly modules for BV API and HV to the
>> new versions
>> 2) Leave the existing modules for BV 1.1 (+ implementation) and add
>> separate modules for BV 2.0
>>
>> 1) would be easier and less effort. But I'm not sure how feasible it
>> is, in case that WF should remain Java EE 7 compatible for the time
>> being. Also, while BV 2 is fully backwards compatible at the
>> spec-level, Hibernate Validator amends the spec API with some extended
>> functionality. In that extended HV-specific API some changes were
>> required, mostly as previous experimental features were replaced by
>> equivalent standardized functionality in the BV API.
>>
>> 2) would let the user chose between BV 1.1 and 2.0, but it'd entail
>> some more work:
>>
>> * A place for that configuration is required. I think it could be done
>> similarly to JPA, i.e. via a property with the module name in
>> META-INF/validation.xml
>> * Depending on that configuration, the right set of modules needs to
>> be enabled. Several modules currently have a fixed dependency to the
>> "org.hibernate.validator:main" module (e.g. JPA, Weld, JCA, RestEasy)
>> which would have be made more dynamic, based on the version chosen by
>> the user.
>>
>> What does everyone think on this? And what could be a suitable WildFly
>> target version for such change? Could we aim at incorporating BV 2.0
>> into WF 11?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev