Seems like we might have to find a way to track which module a PersistenceUnitInfo comes from so we can give it the right ValidatorFactory.
-David On Apr 2, 2011, at 12:29 PM, Romain Manni-Bucau wrote: > Probably a stupid question: validation dd can be defined by module but a > persistence module is shared between modules so how can i link a validation > factory to a module in the entitymanager creation? Did i misunderstood the > spec? > > - Romain > > Le 2 avr. 2011 01:25, "David Blevins" <[email protected]> a écrit : >> >> On Apr 1, 2011, at 1:53 PM, Romain Manni-Bucau wrote: >> >>> it was my first question about the openejb jndi tree, i don't know where >>> this context is accessible. >> >> The tree ends up looking like this BeanContext->ModuleContext->AppContext. > The Assembler builds them all so any code part of the assembler can do > whatever they want with them during building and we can pass them around as > needed in that code. Doesn't have to be on that object, but is an option if > it makes things easier. >> >> I see we don't build the individual ModuleContext objects till later. So > maybe there's some clever way to attach the ValidatorFactory instances to > AppContext. Or a clever way to build the ModuleContext objects earlier. Not > sure. >> >> In terms of the actual JNDI binding, what we did for EJB, EntityManager, > and DataSource references is when we build the actual object we bind it with > a global name. Then all references in the individual smaller JNDI trees we > build are just pointers to the global name. So building the JNDI tree of the > module or an ejb doesn't involve much and is really just a lot of > "symlinks." >> >> We may or may not be able to do that here. If we did the end result would > be that each ValidatorFactory is bound exactly twice, once as itself (a > plain Factory) and again wrapped with some sort of wrapper like > BusinessLocalReference for the "get me a new Validator instance" reference. >> >>> >>> ill verify but i think we doesn't need the mapping file but it will be >>> loaded before the entitymanager factory (of course ;)) >>> >>> so in your opinion i should load in the configurationfactory the >>> validation.xml, put it in Info objects then copy it in modules to finally >>> bind validatorfactory/validator in module contexts? i find it a bit >>> complicated for a simple need, no? >> >> Passing a URI or String are our only other two options. Any "live" objects > like URL is not allowed in the Info tree. We can always expand the > functionality later, so starting simple is fine. >> >> Here would be some side-effects of doing it in the Assembler and creating > an JAXB and Info tree: >> >> 1 validation.xml file would gain altdd support (i.e. > META-INF/test.validation.xml) >> 2 could potentially do property overriding of validation.xml like we do > for persistence.xml properties >> 3 could construct a validation.xml in code -- we do this in various tests > with ejb-jar.xml, beans.xml, and persistence.xml >> 4 xml parsing issues would be caught in the "configure" phase and not in > the "assemble" phase >> >> It may or may not be worth it to do any of those things. Pragmatic choices > are always fine :) It's usually easy to start simple and make it more > involved later, whereas the reverse is seldom true. So whatever gets the job > done is fine. :) >> >> We could probably find a way to work in #1 regardless -- we'd just need to > use the URL we get from module.getAltDDs(). Then either turn that URL into a > URI and use that in the Info tree or perhaps somewhat lame, but effective, > parse the xml and pass the contents as a String (would get us #4 at least). >> >> #3 and #4 probably would require going "all the way" like we do for > persistence.xmls. Again, not sure if it is worth it and doesn't really need > to be done now. >> >> The harder part is what to do in the Assembler anyway. >> >> >> -David >> >>> >>> 2011/4/1 David Blevins <[email protected]> >>> >>>> >>>> On Apr 1, 2011, at 1:13 PM, Romain Manni-Bucau wrote: >>>> >>>>> Hi all, >>>>> >>>>> to implement bean validation, is it a good idea to do like it (i tried > to >>>>> write something simple but understandable, say me if i failed ;)): >>>>> >>>>> <[email protected]>1) create a builder ValidatorBuilder class >>>>> i) method createValidatorFactory(ModuleType type {WEBAPP, OTHER}, URL >>>>> validationUrl {null or not}) returning a ValidatorFactory >>>>> 2) in Assembler::createApplication() >>>>> i) bind a dynamic proxy in "VALIDATOR_FACTORY_NAMING_CONTEXT + >>>>> ValidatorFactory" (same idea for Validator) - >>>>> containerSystem.getJNDIContext().bind("...", vfProxy) >>>>> ii) IMHO it should be done before the persistence building (to put it >>>> as >>>>> parameter in the entity manager factory creation) but will it not break >>>>> something about the weaving (i saw some comments about it)? >>>>> 3) the proxy/proxies >>>>> i) manage a map/cache of ValidatorFactory and Validator (is it >>>> necessary >>>>> for validator?). The key will be the module (maybe the path? it should >>>> only >>>>> be unique) >>>>> ii) invoke(...) { >>>>> type = getModuleTypeFromClassLoader(); >>>>> if (!validatorFactoryExistsForModule(currentModule())) { >>>>> vf = ValidatorBuilder::createValidatorFactory(type); >>>>> } >>>>> return whatWeWantByReflection(); >>>>> } >>>> >>>> One quick thought would be to maybe put the ValidatorFactory instance in >>>> the ModuleContext object. Should eliminate the need for any > mapping/caching >>>> which often ends up leaky. We might even (someday) want to redo some of > the >>>> EntityManagerFactory stuff that way -- we didn't have an AppContext or >>>> ModuleContext when that code was written. >>>> >>>> On the URL note. The Info object tree passed from the > ConfigurationFactory >>>> to the Assembler doesn't allow URL or Class or any other thing tied to a >>>> classloader. If we were to create a set of Info objects to represent the >>>> validation.xml, how complex would that tree be? For the beans.xml and >>>> persistence.xml it was pretty simple. >>>> >>>> The validation configuration file looks really simple. The mapping file > is >>>> complex. I'm not sure if we need both or just one of them like in JPA > (we >>>> handle persistence.xml and the provider handles the mapping files) >>>> >>>> -David >>>> >>>> >>
