[wildfly-dev] Copies of LazyValidatorFactory

[Scott Marlow]

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