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