[wildfly-dev] Copies of LazyValidatorFactory

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

[wildfly-dev] Copies of LazyValidatorFactory

Farah Juma
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.

[1] https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12787076
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882

Thanks,
Farah

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

Re: [wildfly-dev] Copies of LazyValidatorFactory

Jesper Pedersen
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

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

Re: [wildfly-dev] Copies of LazyValidatorFactory

Stan Silvert
In reply to this post by Farah Juma
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&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12787076
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882

Thanks,
Farah

_______________________________________________
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: [wildfly-dev] Copies of LazyValidatorFactory

Gunnar Morling
Hi Stan,

2013/8/20 <[hidden email]>
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?



_______________________________________________
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: [wildfly-dev] Copies of LazyValidatorFactory

Gunnar Morling
In reply to this post by Jesper Pedersen
Hi Jesper,

2013/8/14 Jesper Pedersen <[hidden email]>
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
[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: [wildfly-dev] Copies of LazyValidatorFactory

Jesper Pedersen
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

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

Re: [wildfly-dev] Copies of LazyValidatorFactory

Stan Silvert
In reply to this post by Gunnar Morling
On 8/21/2013 3:04 AM, Gunnar Morling wrote:
Hi Stan,

2013/8/20 <[hidden email]>
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?
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/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java


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

Re: [wildfly-dev] Copies of LazyValidatorFactory

Scott Marlow
In reply to this post by Gunnar Morling
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.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Copies of LazyValidatorFactory

Stan Silvert
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
> [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: [wildfly-dev] Copies of LazyValidatorFactory

Emmanuel Bernard
On Mon 2013-08-26 11:36, [hidden email] 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.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Copies of LazyValidatorFactory

Stan Silvert
On 8/26/2013 11:52 AM, Emmanuel Bernard wrote:

> On Mon 2013-08-26 11:36, [hidden email] 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Copies of LazyValidatorFactory

Tomaž Cerar-2
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, <[hidden email]> wrote:
On 8/26/2013 11:52 AM, Emmanuel Bernard wrote:
> On Mon 2013-08-26 11:36, [hidden email] 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
[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: [wildfly-dev] Copies of LazyValidatorFactory

Scott Marlow
In reply to this post by Emmanuel Bernard
On 08/26/2013 11:52 AM, Emmanuel Bernard wrote:

> On Mon 2013-08-26 11:36, [hidden email] 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

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