finally https://issues.apache.org/jira/browse/OPENEJB-1352 is a better place ;)
2011/4/3 Romain Manni-Bucau <[email protected]> > 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 >> > >> >>>>> >> > >> >>>>> >> > >> >>> >> > >> > >> > >> >> > >> >> >
