On 8/26/2013 11:52 AM, Emmanuel Bernard wrote:
> On Mon 2013-08-26 11:36, ssilvert@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev