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