Hi Jean-Baptiste, I'm with you on this aspect. Producing the .java files, building them, and then using them in a JVM seems to be a more logical means of accomplishing this task.
But, since the poster was asking about the dynamic class approach like the Fluent Hibernate API, I thought it would still be an interesting exercise for someone. Just not high on my priority list... :-) Kevin On Sat, May 15, 2010 at 8:38 AM, Jean-Baptiste BRIAUD -- Novlog < [email protected]> wrote: > How do you generate classes dynamically (at runtime) in Java ??? > Did you meant modifying the mapping at runtime for existing classes or did > you meant producing new classes at runtime and using it just after that and > still in the same JVM ? > > We are using OpenJPA 2.0 and are generating classes, but this is to > understand like generation time, before compile time before runtime. > So, we start producing .java text files that includes JPA annotation, then > compiling them, then using them by starting a new JVM. > To do so, we do not need any JPA dynamic modification not any kind of JPA > introspection. > JPA introspection was not needed because the only modification I needed > coming from Hibernate was a way to change dynamically the eager/fetch > settings but that wonderful fetchplan feature did the job ! > > On 12 mai 2010, at 17:06, Kevin Sutter wrote: > > > Hi Matthew, > > I can agree with the idea of dynamically generating classes at runtime > and > > be able to persist them and use them in queries. But, the dynamic > > generation of mappings makes me go tilt. :-) > > > > Kevin > > > > On Wed, May 12, 2010 at 9:56 AM, Matthew Adams <[email protected] > >wrote: > > > >> I don't think the intent is to be able to dynamically change mappings, > >> although I suppose that's certainly possible. The primary use case > >> for the metadata API is to be able to generate classes at runtime and > >> be able to persist them. I didn't follow the metadata API > >> justification email thread too closely, so there may be other reasons > >> to have it. > >> > >> -matthew > >> > >> On Wed, May 12, 2010 at 6:35 AM, Kevin Sutter <[email protected]> > wrote: > >>> Hi Christopher, > >>> Hmmm... Interesting idea, but is this dynamic mapping really > practical? > >> It > >>> sounds like you are looking for the means to dynamically create or > change > >>> the mappings defined by your Entity and your database Schema. The > >> attribute > >>> types in your Entity definitions will need to match (or at least easily > >>> convert to) the types in your database Schema. Since most customer > >> database > >>> schemas are fairly static, I don't quite see the need for dynamic > >> mappings. > >>> > >>> Maybe I need another cup of coffee this morning, but I'd still be > >> interested > >>> in hearing a specific, real-world use case where the mappings between > >> your > >>> Entity and Schema need to be dynamic. > >>> > >>> Thanks, > >>> Kevin > >>> > >>> On Tue, May 11, 2010 at 11:33 AM, Christopher Gardner < > >>> [email protected]> wrote: > >>> > >>>> Kevin, > >>>> > >>>> The only use case I can think of is the obvious one: a mapping system > >>>> more expressive and typesafe than xml, while allowing for refactoring > >> and > >>>> clutter-free entity code. However--and this is just coming off the > top > >> of > >>>> my head as I'm writing--I wonder if there might be needs to compute > >>>> mappings > >>>> based on dynamic criteria rather than be bound to compiled annotations > >> or > >>>> static xml (of course, I can't think of what those needs are at the > >>>> moment). > >>>> > >>>> On Tue, May 11, 2010 at 12:21 PM, Kevin Sutter <[email protected]> > >> wrote: > >>>> > >>>>> Hi Christopher, > >>>>> Now I see what you meant by a "fluent API"... To be honest, my > >> viewpoint > >>>>> of > >>>>> this API was to allow for an alternate means of configuring > Hibernate, > >>>>> other > >>>>> than just using XML. Classic Hibernate only supported configuration > >>>>> through > >>>>> XML, so this fluentHibernate allowed for a programming-based > mechanism > >>>> for > >>>>> configuration. On the surface, it seems like this would be more > >>>> difficult > >>>>> to use than just using annotations. > >>>>> > >>>>> Can you provide any use cases in the JPA sense that would describe > how > >>>> this > >>>>> type of configuration API would be helpful? > >>>>> > >>>>> On a similar vein, we are considering an API to help with > >> configuration > >>>> of > >>>>> the persistence unit. Since the persistence unit is defined by the > >>>>> persistence.xml only, allowing some alternate means via an API would > >> be > >>>>> welcome. > >>>>> > >>>>> Kevin > >>>>> > >>>>> On Tue, May 11, 2010 at 10:27 AM, Christopher Gardner < > >>>>> [email protected]> wrote: > >>>>> > >>>>>> Thanks. I'm in the former camp, i.e., a legacy database. I'm aware > >> of > >>>>> the > >>>>>> xml alternative. Though I'm no DotNet developer, I read about an > >>>> Fluent > >>>>>> NHibernate, which allows you to create a object to store mapping in > >>>> code. > >>>>>> > >>>>>> http://wiki.fluentnhibernate.org/Getting_started > >>>>>> > >>>>>> <http://wiki.fluentnhibernate.org/Getting_started>Maybe such an API > >>>>> isn't > >>>>>> appropriate for a spec, but it would be an interesting alternative > >> to > >>>>> both > >>>>>> annotations and xml for JPA. > >>>>>> > >>>>>> On Tue, May 11, 2010 at 11:21 AM, Kevin Sutter <[email protected]> > >>>>> wrote: > >>>>>> > >>>>>>> Hi Christopher, > >>>>>>> You're right, annotations can be verbose. But, they don't have to > >>>> be. > >>>>>> It > >>>>>>> all depends on whether your application can live with the default > >>>>>>> processing > >>>>>>> defined by the spec. We tried to pick the most common default > >> values > >>>>> for > >>>>>>> the various annotation elements. If your application can live > >> with > >>>> the > >>>>>>> default processing, then all that is really necessary is the > >> @Entity > >>>>> and > >>>>>>> @Id > >>>>>>> annotations. But, most legacy applications and schemas can not > >> live > >>>>> with > >>>>>>> the default settings, thus the annotations can become verbose. > >>>>>> Flexibility > >>>>>>> can be a killer... But, then we'd be crucified if we didn't allow > >>>> for > >>>>>> the > >>>>>>> flexibility... :-) > >>>>>>> > >>>>>>> The annotations can also be overridden via orm.xml declarations. > >>>> This > >>>>>>> would > >>>>>>> keep your base code more readable, while putting the detailed gorp > >>>> into > >>>>>> the > >>>>>>> xml file(s). Maybe this would be more suitable for your > >> environment. > >>>>>>> > >>>>>>> Not sure what you mean by "fluent API". Any specific examples to > >>>> help > >>>>>> with > >>>>>>> this discussion? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Kevin > >>>>>>> > >>>>>>> On Tue, May 11, 2010 at 10:10 AM, Christopher Gardner < > >>>>>>> [email protected]> wrote: > >>>>>>> > >>>>>>>> Vis-a-vis all JPA specs, streamlining annotations would be nice. > >>>> The > >>>>>>>> annotations can be verbose. Maybe a fluent API would be in > >> order. > >>>>>>>> > >>>>>>>> On Tue, May 11, 2010 at 10:46 AM, Kevin Sutter < > >> [email protected] > >>>>> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi Chris, > >>>>>>>>> Sorry to hear that you are frustrated with JPA 2.0. Can you > >>>>>> elaborate? > >>>>>>>>> The > >>>>>>>>> JPA Expert Group is currently soliciting feedback for the next > >>>>>> revision > >>>>>>>> of > >>>>>>>>> the JPA spec (2.x or 3.0). Here's the e-mail address for this > >>>>>>>>> correspondence [1]. But, if there are distinct improvements > >> that > >>>>> are > >>>>>>> you > >>>>>>>>> looking for, maybe they could be entertained by the OpenJPA > >>>>> community > >>>>>>>>> first. Bugs and/or Features can be entered into our JIRA > >> system > >>>>> [2] > >>>>>>> for > >>>>>>>>> future consideration. Of course, community involvement can > >> help > >>>>>> speed > >>>>>>> up > >>>>>>>>> this process. > >>>>>>>>> > >>>>>>>>> Thanks for the input, > >>>>>>>>> Kevin > >>>>>>>>> > >>>>>>>>> [1] [email protected] > >>>>>>>>> [2] https://issues.apache.org/jira/browse/OPENJPA > >>>>>>>>> > >>>>>>>>> On Tue, May 11, 2010 at 9:12 AM, C N Davies <[email protected] > >>> > >>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> I'm so frustrated by JPA 2.0 but can't seem to find an JSR > >> for > >>>>> JPA > >>>>>> 3 > >>>>>>> or > >>>>>>>>>> anything. Can anyone point me it? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks J > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Chris > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > >> > >> -- > >> mailto:[email protected] > >> skype:matthewadams12 > >> yahoo:matthewadams > >> aol:matthewadams12 > >> google-talk:[email protected]<google-talk%[email protected]> > <google-talk%[email protected]<google-talk%[email protected]> > > > >> msn:[email protected] <msn%[email protected]> < > msn%[email protected] <msn%[email protected]>> > >> http://matthewadams.me > >> http://www.linkedin.com/in/matthewadams > >> > >
