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]> >> msn:[email protected] <msn%[email protected]> >> http://matthewadams.me >> http://www.linkedin.com/in/matthewadams >>
