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