Re: [hibernate-dev] Hibernate extension points

I mean 6. HBMBinder is essentially static, there is no real way around that without rewriting a lot of boring code. On Feb 28, 2008, at 17:26, Ali H. Ibrahim wrote: > Hi, > > I have opened some JIRA improvement issues for the points below. I > assumed you meant forget #7 as that seems to be one that requires a > lot of work. I mistakenly marked one of the issues as major when I > meant minor, but it seems I don't have permission to fix that. > > Regards, > > Ali > > Emmanuel Bernard wrote: >> Nice work >> Can you open a JIRA issue for each point (forget #6 though, too much >> work) and explain the reason for the need briefly? >> >> Emmanuel >> >> On Feb 26, 2008, at 14:10, Ali H. Ibrahim wrote: >> >>> Hi, >>> >>> I have been working on an extension to Hibernate called Autofetch. >>> I ran >>> into some pain points and although I have worked around them for >>> now, I >>> was wondering which of these I could help make better either through >>> patches or JIRA issues. Most of these are pretty selfish in that they >>> would have made my life easier by making more code accessible. >>> >>> 1. AbstractLazyInitializer has the initialize method as final. It >>> can be >>> useful to be able to override that method to do stuff. I realize it is >>> important to make sure that the method is eventually called. >>> >>> 2. AbstractPersistentCollection has read and write methods as final. >>> Again, it was useful in my extension to be able to override these >>> methods. >>> >>> 3. DefaultInitializeCollectionListener has >>> initializeCollectionFromCache >>> method as private. When I subclassed the >>> DefaultInitializeCollectionListener I would have like to have been >>> able >>> to call this method from my subclass instead of copying the code. >>> >>> 4. The PojoInstantiator's state is all private with no getters. It >>> would >>> have nice to be able to subclass it in a meaningful way. >>> >>> 5. A generally useful class is a delegate interceptor which takes >>> takes >>> an interceptor as a constructor argument and by default dispatches >>> requests to that interceptor. >>> >>> 6. Might be nice for HbmBinder not to be a static class. >>> >>> 7. Right now, the tuplizer extension point allows for very broad >>> changes >>> in how entities are instantiated, proxies, etc. However there is no >>> such >>> extension point for the PersistentCollection classes. I know you can >>> change the underlying collection behavior, but I need to change the >>> behavior of the collection classes before the underlying collection is >>> instantiated. >>> >>> Shameless plug for Autofetch: >>> http://www.cs.utexas.edu/~aibrahim/autofetch. Basically Autofetch >>> tries >>> to automate association fetches for queries, with the goal of >>> eliminating the need for programmer provided fetch annotations >>> either in >>> the configuration file or in the queries themselves. It does so by >>> monitoring a programs traversals and learning the correct fetch >>> profile >>> for each class of queries. It differentiates queries not only using >>> the >>> query itself, but also the stack trace so that different >>> invocations of >>> method containing a query will be treated differently. >>> >>> Regards, >>> >>> Ali Ibrahim >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>