2:08 p.m.
Hi,
I recently worked on CDI and Bean Validation integration for method validation (WFLY-529).
As described in [1], part of this work involved replacing the delegate of the EE
LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still
currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should
also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove
the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the
current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA,
it looks like we can access the EE LazyValidatorFactory from the deployment unit
attachment (i.e., via
deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described
in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since
the code that currently instantiates the JCAValidatorFactory doesn't have access to
the deploymentUnit (and it seems like there isn't a way to modify the code to be able
to access this). Another option might be to register the ValidatorFactory as a service and
then perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to
go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track this.
In addition to JCA and JPA, we'll need to consider what should be done for JSF since
it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF
doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping
Bean Validation in another way.
[1]
https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&pa...
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882
Thanks,
Farah
2:40 p.m.
Hi,
On 08/14/2013 03:08 PM, Farah Juma wrote:
However, for JCA, it doesn't seem like this will be possible
since the code that currently instantiates the JCAValidatorFactory doesn't have access
to the deploymentUnit (and it seems like there isn't a way to modify the code to be
able to access this). Another option might be to register the ValidatorFactory as a
service and then perform a manual lookup on the service.
Currently the BeanValidation integration is used to verify JCA 1.6+
based resource adapters, and passed into the deployment chain through
AbstractResourceAdapterDeploymentService::AbstractAS7RaDeployer::getBeanValidation()
so the deployment service name is available at that point. A resource
adapter can also look up a ValidatorFactory through JNDI at run-time -
there is no access through the JCA API.
Registering the ValidatorFactory as a service sounds like a solution to me.
Note, however, that resource adapter deployments doesn't support the CDI
model - at least vendor specific behavior. So investigating this would
be part of the JIRA.
I was wondering if anyone had any thoughts about what approach to
take for JCA or how to go about removing the JCAValidatorFactory. I've created
WFLY-1882 [3] to track this.
Thank you. If you have a working branch feel free to add it as a comment.
Best regards,
Jesper
4:18 a.m.
Hi Jesper,
2013/8/14 Jesper Pedersen <jesper.pedersen(a)jboss.org>
Hi,
On 08/14/2013 03:08 PM, Farah Juma wrote:
> However, for JCA, it doesn't seem like this will be possible since the
code that currently instantiates the JCAValidatorFactory doesn't have
access to the deploymentUnit (and it seems like there isn't a way to modify
the code to be able to access this). Another option might be to register
the ValidatorFactory as a service and then perform a manual lookup on the
service.
>
Currently the BeanValidation integration is used to verify JCA 1.6+
based resource adapters, and passed into the deployment chain through
AbstractResourceAdapterDeploymentService::AbstractAS7RaDeployer::getBeanValidation()
so the deployment service name is available at that point. A resource
adapter can also look up a ValidatorFactory through JNDI at run-time -
there is no access through the JCA API.
Registering the ValidatorFactory as a service sounds like a solution to me.
If looking up the VF via JNDI works I think that might be a bit simpler, as
no changes on the provider side would be required. Resteasy also looks up
the VF via JNDI.
Note, however, that resource adapter deployments doesn't support
the CDI
model - at least vendor specific behavior. So investigating this would
be part of the JIRA.
Does this mean that CDI is never enabled for an RA deployment? Do we need
to care about the CDI/BV integration in this case at all? Using the VF from
the EE module might still be nice to get rid of the (copied)
JcaValidatorFactory but the VF would never be CDI-aware for a
non-CDI-enabled deployment.
> I was wondering if anyone had any thoughts about what approach to take
for JCA or how to go about removing the JCAValidatorFactory. I've created
WFLY-1882 [3] to track this.
Thank you. If you have a working branch feel free to add it as a comment.
Best regards,
Jesper
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:09 a.m.
Hi,
On 08/21/2013 05:18 AM, Gunnar Morling wrote:
> Currently the BeanValidation integration is used to verify JCA
1.6+
> based resource adapters, and passed into the deployment chain through
>
> AbstractResourceAdapterDeploymentService::AbstractAS7RaDeployer::getBeanValidation()
>
> so the deployment service name is available at that point. A resource
> adapter can also look up a ValidatorFactory through JNDI at run-time -
> there is no access through the JCA API.
>
> Registering the ValidatorFactory as a service sounds like a solution to me.
>
If looking up the VF via JNDI works I think that might be a bit simpler, as
no changes on the provider side would be required. Resteasy also looks up
the VF via JNDI.
Could be an option, lets look at it once the IronJacamar 1.1 PR is in.
And for the above I meant a resource adapter implementation that
requires extra bean validation functionality other than verifying its
configuration properties during activation.
Does this mean that CDI is never enabled for an RA deployment? Do we
need
to care about the CDI/BV integration in this case at all? Using the VF from
the EE module might still be nice to get rid of the (copied)
JcaValidatorFactory but the VF would never be CDI-aware for a
non-CDI-enabled deployment.
I don't think so with the current spec - CDI beans can use the resource
adapter objects bound in JNDI. A resource adapter implementation can't
depend on CDI beans.
So maybe we will keep the JcaValidationFactory, since EE depends on JCA,
and not the other way around.
Best regards,
Jesper
10:22 a.m.
On 08/21/2013 05:18 AM, Gunnar Morling wrote:
If looking up the VF via JNDI works I think that might be a bit simpler,
as no changes on the provider side would be required. Resteasy also
looks up the VF via JNDI.
I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
during deployment. If the VF isn't needed until post deployment time,
the JNDI lookup would be more likely to work (when the application
component context will be available).
In the case of JPA, we need the VF during deployment. I'm not sure
about the other (JSF/JCA) cases.
10:36 a.m.
On 8/26/2013 11:22 AM, Scott Marlow wrote:
On 08/21/2013 05:18 AM, Gunnar Morling wrote:
> If looking up the VF via JNDI works I think that might be a bit simpler,
> as no changes on the provider side would be required. Resteasy also
> looks up the VF via JNDI.
I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
during deployment. If the VF isn't needed until post deployment time,
the JNDI lookup would be more likely to work (when the application
component context will be available).
In the case of JPA, we need the VF during deployment. I'm not sure
about the other (JSF/JCA) cases.
JSF also needs the VF during deployment. So if it
is provided via JNDI
it does need to be fully intialized at that time.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:52 a.m.
On Mon 2013-08-26 11:36, ssilvert(a)redhat.com wrote:
On 8/26/2013 11:22 AM, Scott Marlow wrote:
> On 08/21/2013 05:18 AM, Gunnar Morling wrote:
>> If looking up the VF via JNDI works I think that might be a bit simpler,
>> as no changes on the provider side would be required. Resteasy also
>> looks up the VF via JNDI.
> I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
> during deployment. If the VF isn't needed until post deployment time,
> the JNDI lookup would be more likely to work (when the application
> component context will be available).
>
> In the case of JPA, we need the VF during deployment. I'm not sure
> about the other (JSF/JCA) cases.
JSF also needs the VF during deployment. So if it is provided via JNDI
it does need to be fully intialized at that time.
That is not true. A ValidatorFactory needs to be available from JNDI
during deployment time so that the module can retrieve it (assuming that
the approach we want) and possibly access its metadata which is
unaffected by a CDI enabled VF.
But the actual CDI enabled VF does not have to be initialized for
deployment time. JPA, JSF and CDI do not need it until after the
application is fully deployed. Using a delegate approach (the famous
LazyVF delegating to a non CDI VF initially - and lazily built - and a
CDI VF later one), we should be good.
11:19 a.m.
On 8/26/2013 11:52 AM, Emmanuel Bernard wrote:
On Mon 2013-08-26 11:36, ssilvert(a)redhat.com wrote:
> On 8/26/2013 11:22 AM, Scott Marlow wrote:
>> On 08/21/2013 05:18 AM, Gunnar Morling wrote:
>>> If looking up the VF via JNDI works I think that might be a bit simpler,
>>> as no changes on the provider side would be required. Resteasy also
>>> looks up the VF via JNDI.
>> I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
>> during deployment. If the VF isn't needed until post deployment time,
>> the JNDI lookup would be more likely to work (when the application
>> component context will be available).
>>
>> In the case of JPA, we need the VF during deployment. I'm not sure
>> about the other (JSF/JCA) cases.
> JSF also needs the VF during deployment. So if it is provided via JNDI
> it does need to be fully intialized at that time.
That is not true. A ValidatorFactory needs to be available from JNDI
during deployment time so that the module can retrieve it (assuming that
the approach we want) and possibly access its metadata which is
unaffected by a CDI enabled VF.
But the actual CDI enabled VF does not have to be initialized for
deployment time. JPA, JSF and CDI do not need it until after the
application is fully deployed. Using a delegate approach (the famous
LazyVF delegating to a non CDI VF initially - and lazily built - and a
CDI VF later one), we should be good.
Well, it might depend on what you mean by
"deployment time" and "fully
deployed". I can't guarantee that someone won't write application
initialization code that generates beans which need validation. So to
be more specific, it needs to be initialized by the time
ServletContextListeners run. That's the earliest that JSF would
actually need to use it.
11:23 a.m.
Why don't you just create a msc Service that provides VF?
and all other subsystems will just inject that service/VF that service
provides and you are all good.
On Mon, Aug 26, 2013 at 6:19 PM, <ssilvert(a)redhat.com> wrote:
On 8/26/2013 11:52 AM, Emmanuel Bernard wrote:
> On Mon 2013-08-26 11:36, ssilvert(a)redhat.com wrote:
>> On 8/26/2013 11:22 AM, Scott Marlow wrote:
>>> On 08/21/2013 05:18 AM, Gunnar Morling wrote:
>>>> If looking up the VF via JNDI works I think that might be a bit
simpler,
>>>> as no changes on the provider side would be required. Resteasy also
>>>> looks up the VF via JNDI.
>>> I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
>>> during deployment. If the VF isn't needed until post deployment time,
>>> the JNDI lookup would be more likely to work (when the application
>>> component context will be available).
>>>
>>> In the case of JPA, we need the VF during deployment. I'm not sure
>>> about the other (JSF/JCA) cases.
>> JSF also needs the VF during deployment. So if it is provided via JNDI
>> it does need to be fully intialized at that time.
> That is not true. A ValidatorFactory needs to be available from JNDI
> during deployment time so that the module can retrieve it (assuming that
> the approach we want) and possibly access its metadata which is
> unaffected by a CDI enabled VF.
>
> But the actual CDI enabled VF does not have to be initialized for
> deployment time. JPA, JSF and CDI do not need it until after the
> application is fully deployed. Using a delegate approach (the famous
> LazyVF delegating to a non CDI VF initially - and lazily built - and a
> CDI VF later one), we should be good.
Well, it might depend on what you mean by "deployment time" and "fully
deployed". I can't guarantee that someone won't write application
initialization code that generates beans which need validation. So to
be more specific, it needs to be initialized by the time
ServletContextListeners run. That's the earliest that JSF would
actually need to use it.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:34 a.m.
On 08/26/2013 11:52 AM, Emmanuel Bernard wrote:
On Mon 2013-08-26 11:36, ssilvert(a)redhat.com wrote:
> On 8/26/2013 11:22 AM, Scott Marlow wrote:
>> On 08/21/2013 05:18 AM, Gunnar Morling wrote:
>>> If looking up the VF via JNDI works I think that might be a bit simpler,
>>> as no changes on the provider side would be required. Resteasy also
>>> looks up the VF via JNDI.
>> I don't think the JNDI (java:comp/ValidatorFactory) lookup would work
>> during deployment. If the VF isn't needed until post deployment time,
>> the JNDI lookup would be more likely to work (when the application
>> component context will be available).
>>
>> In the case of JPA, we need the VF during deployment. I'm not sure
>> about the other (JSF/JCA) cases.
> JSF also needs the VF during deployment. So if it is provided via JNDI
> it does need to be fully intialized at that time.
I previously tried to do a java:comp lookup during deployment and was
schooled that the application component is not yet accessible yet.
That is not true. A ValidatorFactory needs to be available from JNDI
during deployment time so that the module can retrieve it (assuming that
the approach we want) and possibly access its metadata which is
unaffected by a CDI enabled VF.
But the actual CDI enabled VF does not have to be initialized for
deployment time. JPA, JSF and CDI do not need it until after the
application is fully deployed. Using a delegate approach (the famous
LazyVF delegating to a non CDI VF initially - and lazily built - and a
CDI VF later one), we should be good.
I think we are using a lazily built VF currently, so we should be good
if we continue to use a lazily built VF after these changes.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:43 a.m.
On 8/14/2013 3:08 PM, Farah Juma wrote:
Hi,
I recently worked on CDI and Bean Validation integration for method validation
(WFLY-529). As described in [1], part of this work involved replacing the delegate of the
EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still
currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should
also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove
the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the
current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA,
it looks like we can access the EE LazyValidatorFactory from the deployment unit
attachment (i.e., via
deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described
in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since
the code that currently instantiates the JCAValidatorFactory doesn't have access to
the deploymen!
tUnit (and it seems like there isn't a way to modify the code to be able to access
this). Another option might be to register the ValidatorFactory as a service and then
perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to
go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track this.
In addition to JCA and JPA, we'll need to consider what should be done for JSF since
it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF
doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping
Bean Validation in another way.
Farah,
JSF bootstraps Bean Validation as per JSF spec section 3.5.6.2:
/The Bean Validation ValidatorFactory is the main entry point into
Bean Validation and is responsible for creating//
//Validator instances. [P1-start-validatoryfactory]A
ValidatorFactory is retrieved using the following algorithm://
//If the servlet context contains a ValidatorFactory instance under
the attribute named//
//javax.faces.validator.beanValidator.ValidatorFactory, this
instance is used by JSF to acquire Validator instances//
//(specifically in the BeanValidator). This key should be defined in
the constant named VALIDATOR_FACTORY_KEY//
//on BeanValidator.//
//If the servlet context does not contain such an entry, JSF looks
for a Bean Validation provider in the classpath. If//
//present, the standard Bean Validation bootstrap strategy is used.
If not present, Bean Validation integration is//
//disabled.//
/
In our case, we use the second method, which is to simply place the Bean
Validation provider in the classpath. For every deployment that uses
JSF, the JSF subsystem will add the org.hibernate.validator module to
the deployment.
[1]
https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&pa...
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882
Thanks,
Farah
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:04 a.m.
Hi Stan,
2013/8/20 <ssilvert(a)redhat.com>
On 8/14/2013 3:08 PM, Farah Juma wrote:
Hi,
I recently worked on CDI and Bean Validation integration for method validation
(WFLY-529). As described in [1], part of this work involved replacing the delegate of the
EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still
currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should
also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove
the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the
current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA,
it looks like we can access the EE LazyValidatorFactory from the deployment unit
attachment (i.e., via
deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described
in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since
the code that currently instantiates the JCAValidatorFactory doesn't have access to
the deploymen!
tUnit (and it seems like there isn't a way to modify the code to be able to access
this). Another option might be to register the ValidatorFactory as a service and then
perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to
go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track this.
In addition to JCA and JPA, we'll need to consider what should be done for JSF since
it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF
doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping
Bean Validation in another way.
Farah,
JSF bootstraps Bean Validation as per JSF spec section 3.5.6.2:
*The Bean Validation ValidatorFactory is the main entry point into Bean
Validation and is responsible for creating**
**Validator instances. [P1-start-validatoryfactory]A ValidatorFactory is
retrieved using the following algorithm:**
**If the servlet context contains a ValidatorFactory instance under the
attribute named**
**javax.faces.validator.beanValidator.ValidatorFactory, this instance is
used by JSF to acquire Validator instances**
**(specifically in the BeanValidator). This key should be defined in the
constant named VALIDATOR_FACTORY_KEY**
**on BeanValidator.**
**If the servlet context does not contain such an entry, JSF looks for a
Bean Validation provider in the classpath. If**
**present, the standard Bean Validation bootstrap strategy is used. If
not present, Bean Validation integration is**
**disabled.**
*
In our case, we use the second method, which is to simply place the Bean
Validation provider in the classpath. For every deployment that uses JSF,
the JSF subsystem will add the org.hibernate.validator module to the
deployment.
Thanks for that info, that's very helpful. The problem we're trying to
solve is making sure that Bean Validation and CDI are properly integrated
as required by the BV spec. For instance CDI-based dependency injection
must be available to constraint validator implementations.
The validator factory maintained in the WildFly EE module (which e.g. is
available via JNDI) provides this functionality as it is configured as
necessary during bootstrap. A validator factory obtained via the standard
BV bootstrap strategy won't offer this functionality, though.
So based on what you say, one solution for the JSF case could be to make
the VF from the EE module available in the servlet context, e.g. by
retrieving it via JNDI (assuming the order of loading the modules allows
for that). I'm not sure though about a WAR deployment which is CDI-enabled.
Is the EE module activated in this case?
[1]
https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&pa...
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882
Thanks,
Farah
_______________________________________________
wildfly-dev mailing
listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:33 p.m.
On 8/21/2013 3:04 AM, Gunnar Morling wrote:
Hi Stan,
2013/8/20 <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
On 8/14/2013 3:08 PM, Farah Juma wrote:
> Hi,
>
> I recently worked on CDI and Bean Validation integration for method validation
(WFLY-529). As described in [1], part of this work involved replacing the delegate of the
EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still
currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should
also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove
the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the
current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA,
it looks like we can access the EE LazyValidatorFactory from the deployment unit
attachment (i.e., via
deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described
in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since
the code that currently instantiates the JCAValidatorFactory doesn't have access to
the deploymen!
> tUnit (and it seems like there isn't a way to modify the code to be able to
access this). Another option might be to register the ValidatorFactory as a service and
then perform a manual lookup on the service.
>
> I was wondering if anyone had any thoughts about what approach to take for JCA or
how to go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track
this. In addition to JCA and JPA, we'll need to consider what should be done for JSF
since it will also need to be able to access the CDI-enabled ValidatorFactory. Note that
JSF doesn't use a copy of the EE LazyValidatorFactory and so it seems to be
bootstrapping Bean Validation in another way.
Farah,
JSF bootstraps Bean Validation as per JSF spec section 3.5.6.2
<http://3.5.6.2>;:
/The Bean Validation ValidatorFactory is the main entry point
into Bean Validation and is responsible for creating//
//Validator instances. [P1-start-validatoryfactory]A
ValidatorFactory is retrieved using the following algorithm://
//If the servlet context contains a ValidatorFactory instance
under the attribute named//
//javax.faces.validator.beanValidator.ValidatorFactory, this
instance is used by JSF to acquire Validator instances//
//(specifically in the BeanValidator). This key should be
defined in the constant named VALIDATOR_FACTORY_KEY//
//on BeanValidator.//
//If the servlet context does not contain such an entry, JSF
looks for a Bean Validation provider in the classpath. If//
//present, the standard Bean Validation bootstrap strategy is
used. If not present, Bean Validation integration is//
//disabled.//
/
In our case, we use the second method, which is to simply place
the Bean Validation provider in the classpath. For every
deployment that uses JSF, the JSF subsystem will add the
org.hibernate.validator module to the deployment.
Thanks for that info, that's very helpful. The problem we're trying to
solve is making sure that Bean Validation and CDI are properly
integrated as required by the BV spec. For instance CDI-based
dependency injection must be available to constraint validator
implementations.
The validator factory maintained in the WildFly EE module (which e.g.
is available via JNDI) provides this functionality as it is configured
as necessary during bootstrap. A validator factory obtained via the
standard BV bootstrap strategy won't offer this functionality, though.
So based on what you say, one solution for the JSF case could be to
make the VF from the EE module available in the servlet context, e.g.
by retrieving it via JNDI (assuming the order of loading the modules
allows for that). I'm not sure though about a WAR deployment which is
CDI-enabled. Is the EE module activated in this case?
I'm not sure what you
mean by "Is the EE module activated?".
It's easy enough for you to try out putting your ValidatorFactory into
the ServletContext. This class is where bean validation is added to the
deployment and it also has an example of stuffing a value into the
ServletContext at deployment time.
https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav...
> [1]
https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&pa...
> [2] https://issues.jboss.org/browse/WFLY-1705
> [3] https://issues.jboss.org/browse/WFLY-1882
>
> Thanks,
> Farah
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4088
days inactive
4100
days old
12 comments
7 participants
participants (7)
-
Emmanuel Bernard -
Farah Juma -
Gunnar Morling -
Jesper Pedersen -
Scott Marlow -
ssilvert＠redhat.com -
Tomaž Cerar