oh sorry, here is the temp file (waiting to have something working at least a bit ;)): http://www.2shared.com/file/-BN3pMRJ/bean-validation-to-complete.html
Romain 2011/4/3 David Blevins <[email protected]> > Might have to attach the patch to a JIRA. Don't think the list supports > attachments. > > -David > > On Apr 3, 2011, at 8:42 AM, Romain Manni-Bucau wrote: > > > i attached a patch "to complete", i don't know how to do the TODO part > (to get module id from a unknow call). > > > > i take all comments about this start... > > > > Romain > > > > 2011/4/3 Romain Manni-Bucau <[email protected]> > > Is there a solution to get informations about current context (module id > for example) at runtime (on a lookup)? > > > > Romain > > > > Le 3 avr. 2011 10:59, "Romain Manni-Bucau" <[email protected]> a > écrit : > > > > > > > can creating as many emf as persistence-unit * validation-factory > number be > > > a solution? > > > > > > for m in modules // has exactly one validation factory > > > for p in pu > > > emfs.put(p.id + " " + m.moduleId, createEm(p, m)) > > > > > > i could bind it in the jndi tree too. IMHO it is a bit like what is > done > > > today but it starts to be a bit heavy, no? > > > > > > Romain > > > > > > 2011/4/3 Romain Manni-Bucau <[email protected]> > > > > > >> In fact we have to create one emf by module (we could add some > optimization > > >> later) so the binding will change IMHO. In a try i set persistence and > > >> validation in modules, it can work but it will change persistence > management > > >> so i think i have to wait thiago work to do it on 3.2.x too. What's > your > > >> opinion about this change? > > >> > > >> Romain > > >> > > >> Le 3 avr. 2011 01:42, "David Blevins" <[email protected]> a > écrit : > > >> > > >> > 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 > > >> >>>>> > > >> >>>>> > > >> >>> > > >> > > > >> > > > >
