Re: [hibernate-dev] JBoss Cache Searchable interfaces
-- Emmanuel Bernard http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com | http://twitter.com/emmanuelbernard Hibernate Search in Action (http://is.gd/Dl1) On Jun 24, 2008, at 13:15, Manik Surtani wrote: Hi guys - a few comments on the public interfaces of SearchableCache - 1) IMO, I think that the SearchableCache.createQuery() method should *not* return a FullTextQuery, but instead a JBCS-specific CacheQuery interface with a subset of the methods in FullTextQuery. +1 I think the only methods in FullTextQuery that are relevant and that should be carried across to CacheQuery are: * list() +1 * iterator(); don't think it's that useful in practice, scroll is probably more practical as it lazily loads Lucene data (contrary to iterator) * setFirstResult(int i); +1 * setMaxResults(int i); +1 * setFetchSize(int i); +1 * getResultSize(); +1 * setSort(); +1 scroll() setFilter, enableFullTextFilter, disableFullTextFilter is a total must have to do temporal patterns, category filter and so on. This is Lucene filters, not Hibernate Core filters. setProjection() you need projection for metadata setResultTransformer is a consequence. It probably makes sense to project regular properties too (memory wise for sure, needs probably more testing speed wise) uniqueResult() is quite nice I think all of the rest - such as filters, criteria and projections - are irrelevant to a query on a cache. WDYT? Emmanuel? they are relevant, see above 2) Also, rather than implement FullTextQuery.scroll() to return a ScrollableResults instance, I'd rather that iterator() returns an instance of a new interface, QueryResultsIterator, which extends j.u.ListIterator. This gives us the ability to scroll back and forth over a result set, and we could add additional methods to jump to a specific point in the result set and helpers such as isLast(), isFirst(), isBeforeLast(), isAfterFirst(), first(), last(), afterFirst(), beforeLast(). That's the point of Scroll, but you can rename it if you want. What's important is that you need a .close() method to release the lucene resources. also scroll() could return null if the object is not found in the cache (inconsistency), iterate() will just ignore the entry. I think that any benefit of a scrollable result set window preventing loading unnecessary objects from a DB are lost when your backing store is a cache and the objects are in memory anyway. And besides, any further optimisations can be in the iterator implementation, such as just maintaining a list of CachedEntityIds (a composite of Fqn and key) and fetching the objects from the cache lazily, as required. iterate() lazily load object from the DB but eagerly loads Lucene stuffs scroll() lazily load everything but need a .close() Also, with the above, 2, we don't leak any Hibernate or Hibernate Search interfaces into the user API which again IMO is a good thing. You can use your own Scrolalble interface, that's fair. Essentially Search should look natural to cache users, not Hibernate users :) Thoughts, comments? Cheers Manik On 24 Jun 2008, at 11:47, Navin Surtani wrote: Begin forwarded message: From: Emmanuel Bernard <[EMAIL PROTECTED]> Date: 24 June 2008 08:19:03 BST To: Navin Surtani <[EMAIL PROTECTED]> Subject: Re: More hibernate questions Scroll is more important than iterate because it allows to read objects s a window and get rid of them on a regular basis without facing out of memory exception. I think it's used more often than iterate On Jun 23, 2008, at 18:17, Navin Surtani wrote: Hey again - I have a CacheQueryImpl class that extends the FullTextQuery interface and I am implementing the methods as similar as possible. A couple of problems occur when you are taking in and using certain Hibernate objects for example. A problem lies with the scroll() method. I think it is very similar to the iterate() method and does not need to be implemented in CacheQueryImpl. Do you know if Hibernate users generally use this method and find that they need it? If so then I will try and implement it otherwise then I will just make it throw an exception. Thanks again :) Navin. -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Work on HHH-3110
Steve, Chris, What do you think? does this look good? On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > Hey guys, > > I finally was able to attack this today and created an issue: > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 > > The patch was created based on an SVN checkout of trunk and attached > to the issue. Comments about the change and exactly what I did are > detailed as well. > > The best thing about the fix is that I realized I didn't need to add > any parent abstract classes or even subclasses. I was even able to > consolidate a common JNDI lookup that was spread out (perhaps > unnecessarily) across two classes into one class in one method. > > The change was pretty clean and only touched two files, but still > retains backward compatibility. > > Please let me know what you think! > > Thanks, > > Les > > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> Hi Steve! >> >> Great to hear from you again :) >> >>> Not sure why you find it so interesting considering that that JTA spec >>> itself *requires* binding into JNDI :) This is true both in the older >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe >>> that org.hibernate.transaction.JTATransaction is the correct place to >>> be adding support for not acquiring these resources from JNDI. >> >> My frustration lies in the JTA spec itself, requiring JNDI due to >> remnants from the EJB 2.1 era. Which is why I consider my approach to >> be a feature request as opposed to a bug - its a 'nice to have' when >> using a JTA TM that doesn't require JNDI. >> >> And I agree that JTATransaction _should_ be using the JNDI lookup - my >> intention was never to change that, ensuring 100% backwards >> compatibility. My intention was that the JTATransaction was a minimal >> subclass of a parent abstract class. That abstract class would >> delegate to children classes how do do the lookup, and in the >> JTATransaction case, it would do it from JNDI, just as things occur >> today. >> >>> However, I have no issue with adding support for these psuedo-JTA TMs. >>> Its just a matter of semantics and being consistent with terminology. >>> So, the basic thing we are trying to describe is support for interacting >>> with "distributed transaction" systems. So, I'd prefer that the base >>> class in question here be called DistributedTransaction, of which >>> JTATransaction would be a subclass with the same behavior as it has >>> today (some delegated to its new super). And from there we can begin to >>> build the support for Atomikos and the other TP services not conforming >>> to the JNDI aspect of the JTA spec. >> >> Perfect, this is exactly my thinking as well. And I much prefer your >> superclass name ;) I'll post to this list again when I have my patch >> attached to the issue so you guys can see the end result. >> >> Thanks again, >> >> Les >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JBoss Cache Searchable interfaces
On 26 Jun 2008, at 13:48, Emmanuel Bernard wrote: * iterator(); don't think it's that useful in practice, scroll is probably more practical as it lazily loads Lucene data (contrary to iterator) Then why don't we just lazily load Lucene data into the iterator and drop scroll()? I see supporting both as superfluous. And iterator() is more familiar to devs. That's the point of Scroll, but you can rename it if you want. What's important is that you need a .close() method to release the lucene resources. also scroll() could return null if the object is not found in the cache (inconsistency), iterate() will just ignore the entry. +1, good point. We'd need a close() method on the QueryResultIterator. I see just returning a null if the object is not in the cache as something people would expect. I think that any benefit of a scrollable result set window preventing loading unnecessary objects from a DB are lost when your backing store is a cache and the objects are in memory anyway. And besides, any further optimisations can be in the iterator implementation, such as just maintaining a list of CachedEntityIds (a composite of Fqn and key) and fetching the objects from the cache lazily, as required. iterate() lazily load object from the DB but eagerly loads Lucene stuffs scroll() lazily load everything but need a .close() If you think eager loading of Lucene data is something people would find useful, we could have 2 separate implementations of the QueryResultIterator - a QRILazyImpl and a QRIEagerImpl. And the interface to obtain these could be on the CacheQuery interface: CacheQuery.iterator(boolean lazy); You can use your own Scrolalble interface, that's fair. Essentially Search should look natural to cache users, not Hibernate users :) Yup. :-) -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Work on HHH-3110
One thing I'd ask for future is that you stick to hibernate style as it makes it easier to see *real* changes. For example, you are using space-expansion in place of tabs, etc. This discussion has come up before and I had been thinking of another approach to address this, however, my approach is more disruptive. Basically, right now we have this org.hibernate.transaction.TransactionManagerLookup contract which has morphed beyond a simple TM lookup. And wrt this discussion it is the point at which we make the decision to support only JTA-compliant TMs because org.hibernate.transaction.TransactionManagerLookup defines a getUserTransactionName() method which returns the JNDI namespace where the UserTransaction can be located. If this were instead changed to actually return the UserTransaction instance I think it is much cleaner in the long run. Conceptually, I think the argument to make the change here is much stronger since it aligns with the actual roles these things fulfill. Of course, because it is disruptive, such a change would need to wait until until at least 3.4. In the meantime, I'll go ahead and apply this patch (sans the tab cleanup and some javadoc changes). - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: > Steve, Chris, > > What do you think? does this look good? > > On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > > Hey guys, > > > > I finally was able to attack this today and created an issue: > > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 > > > > The patch was created based on an SVN checkout of trunk and attached > > to the issue. Comments about the change and exactly what I did are > > detailed as well. > > > > The best thing about the fix is that I realized I didn't need to add > > any parent abstract classes or even subclasses. I was even able to > > consolidate a common JNDI lookup that was spread out (perhaps > > unnecessarily) across two classes into one class in one method. > > > > The change was pretty clean and only touched two files, but still > > retains backward compatibility. > > > > Please let me know what you think! > > > > Thanks, > > > > Les > > > > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> Hi Steve! > >> > >> Great to hear from you again :) > >> > >>> Not sure why you find it so interesting considering that that JTA spec > >>> itself *requires* binding into JNDI :) This is true both in the older > >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe > >>> that org.hibernate.transaction.JTATransaction is the correct place to > >>> be adding support for not acquiring these resources from JNDI. > >> > >> My frustration lies in the JTA spec itself, requiring JNDI due to > >> remnants from the EJB 2.1 era. Which is why I consider my approach to > >> be a feature request as opposed to a bug - its a 'nice to have' when > >> using a JTA TM that doesn't require JNDI. > >> > >> And I agree that JTATransaction _should_ be using the JNDI lookup - my > >> intention was never to change that, ensuring 100% backwards > >> compatibility. My intention was that the JTATransaction was a minimal > >> subclass of a parent abstract class. That abstract class would > >> delegate to children classes how do do the lookup, and in the > >> JTATransaction case, it would do it from JNDI, just as things occur > >> today. > >> > >>> However, I have no issue with adding support for these psuedo-JTA TMs. > >>> Its just a matter of semantics and being consistent with terminology. > >>> So, the basic thing we are trying to describe is support for interacting > >>> with "distributed transaction" systems. So, I'd prefer that the base > >>> class in question here be called DistributedTransaction, of which > >>> JTATransaction would be a subclass with the same behavior as it has > >>> today (some delegated to its new super). And from there we can begin to > >>> build the support for Atomikos and the other TP services not conforming > >>> to the JNDI aspect of the JTA spec. > >> > >> Perfect, this is exactly my thinking as well. And I much prefer your > >> superclass name ;) I'll post to this list again when I have my patch > >> attached to the issue so you guys can see the end result. > >> > >> Thanks again, > >> > >> Les > >> > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Work on HHH-3110
On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <[EMAIL PROTECTED]> wrote: > One thing I'd ask for future is that you stick to hibernate style as it > makes it easier to see *real* changes. For example, you are using > space-expansion in place of tabs, etc. Ah, yes, I'll definitely do that - my apologies. I'm assuming there is a style guide that I can use to ensure IntelliJ is set up appropriately? > > This discussion has come up before and I had been thinking of another > approach to address this, however, my approach is more disruptive. > Basically, right now we have this > org.hibernate.transaction.TransactionManagerLookup contract which has > morphed beyond a simple TM lookup. And wrt this discussion it is the > point at which we make the decision to support only JTA-compliant TMs > because org.hibernate.transaction.TransactionManagerLookup defines a > getUserTransactionName() method which returns the JNDI namespace where > the UserTransaction can be located. If this were instead changed to > actually return the UserTransaction instance I think it is much cleaner > in the long run. Conceptually, I think the argument to make the change > here is much stronger since it aligns with the actual roles these things > fulfill. Of course, because it is disruptive, such a change would need > to wait until until at least 3.4. > > In the meantime, I'll go ahead and apply this patch (sans the tab > cleanup and some javadoc changes). Very cool - thanks so much. In which release will it be available (so I can tell the Atomikos guys)? Cheers, Les > On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: >> Steve, Chris, >> >> What do you think? does this look good? >> >> On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> > Hey guys, >> > >> > I finally was able to attack this today and created an issue: >> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 >> > >> > The patch was created based on an SVN checkout of trunk and attached >> > to the issue. Comments about the change and exactly what I did are >> > detailed as well. >> > >> > The best thing about the fix is that I realized I didn't need to add >> > any parent abstract classes or even subclasses. I was even able to >> > consolidate a common JNDI lookup that was spread out (perhaps >> > unnecessarily) across two classes into one class in one method. >> > >> > The change was pretty clean and only touched two files, but still >> > retains backward compatibility. >> > >> > Please let me know what you think! >> > >> > Thanks, >> > >> > Les >> > >> > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> >> Hi Steve! >> >> >> >> Great to hear from you again :) >> >> >> >>> Not sure why you find it so interesting considering that that JTA spec >> >>> itself *requires* binding into JNDI :) This is true both in the older >> >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe >> >>> that org.hibernate.transaction.JTATransaction is the correct place to >> >>> be adding support for not acquiring these resources from JNDI. >> >> >> >> My frustration lies in the JTA spec itself, requiring JNDI due to >> >> remnants from the EJB 2.1 era. Which is why I consider my approach to >> >> be a feature request as opposed to a bug - its a 'nice to have' when >> >> using a JTA TM that doesn't require JNDI. >> >> >> >> And I agree that JTATransaction _should_ be using the JNDI lookup - my >> >> intention was never to change that, ensuring 100% backwards >> >> compatibility. My intention was that the JTATransaction was a minimal >> >> subclass of a parent abstract class. That abstract class would >> >> delegate to children classes how do do the lookup, and in the >> >> JTATransaction case, it would do it from JNDI, just as things occur >> >> today. >> >> >> >>> However, I have no issue with adding support for these psuedo-JTA TMs. >> >>> Its just a matter of semantics and being consistent with terminology. >> >>> So, the basic thing we are trying to describe is support for interacting >> >>> with "distributed transaction" systems. So, I'd prefer that the base >> >>> class in question here be called DistributedTransaction, of which >> >>> JTATransaction would be a subclass with the same behavior as it has >> >>> today (some delegated to its new super). And from there we can begin to >> >>> build the support for Atomikos and the other TP services not conforming >> >>> to the JNDI aspect of the JTA spec. >> >> >> >> Perfect, this is exactly my thinking as well. And I much prefer your >> >> superclass name ;) I'll post to this list again when I have my patch >> >> attached to the issue so you guys can see the end result. >> >> >> >> Thanks again, >> >> >> >> Les >> >> >> > >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > __
Re: [hibernate-dev] Work on HHH-3110
Oh, please feel free to resolve/close http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 when the patch is applied/tests run, etc... On Thu, Jun 26, 2008 at 1:36 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <[EMAIL PROTECTED]> wrote: >> One thing I'd ask for future is that you stick to hibernate style as it >> makes it easier to see *real* changes. For example, you are using >> space-expansion in place of tabs, etc. > > Ah, yes, I'll definitely do that - my apologies. I'm assuming there > is a style guide that I can use to ensure IntelliJ is set up > appropriately? > >> >> This discussion has come up before and I had been thinking of another >> approach to address this, however, my approach is more disruptive. >> Basically, right now we have this >> org.hibernate.transaction.TransactionManagerLookup contract which has >> morphed beyond a simple TM lookup. And wrt this discussion it is the >> point at which we make the decision to support only JTA-compliant TMs >> because org.hibernate.transaction.TransactionManagerLookup defines a >> getUserTransactionName() method which returns the JNDI namespace where >> the UserTransaction can be located. If this were instead changed to >> actually return the UserTransaction instance I think it is much cleaner >> in the long run. Conceptually, I think the argument to make the change >> here is much stronger since it aligns with the actual roles these things >> fulfill. Of course, because it is disruptive, such a change would need >> to wait until until at least 3.4. >> >> In the meantime, I'll go ahead and apply this patch (sans the tab >> cleanup and some javadoc changes). > > Very cool - thanks so much. In which release will it be available (so > I can tell the Atomikos guys)? > > Cheers, > > Les > >> On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: >>> Steve, Chris, >>> >>> What do you think? does this look good? >>> >>> On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>> > Hey guys, >>> > >>> > I finally was able to attack this today and created an issue: >>> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 >>> > >>> > The patch was created based on an SVN checkout of trunk and attached >>> > to the issue. Comments about the change and exactly what I did are >>> > detailed as well. >>> > >>> > The best thing about the fix is that I realized I didn't need to add >>> > any parent abstract classes or even subclasses. I was even able to >>> > consolidate a common JNDI lookup that was spread out (perhaps >>> > unnecessarily) across two classes into one class in one method. >>> > >>> > The change was pretty clean and only touched two files, but still >>> > retains backward compatibility. >>> > >>> > Please let me know what you think! >>> > >>> > Thanks, >>> > >>> > Les >>> > >>> > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>> >> Hi Steve! >>> >> >>> >> Great to hear from you again :) >>> >> >>> >>> Not sure why you find it so interesting considering that that JTA spec >>> >>> itself *requires* binding into JNDI :) This is true both in the older >>> >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe >>> >>> that org.hibernate.transaction.JTATransaction is the correct place to >>> >>> be adding support for not acquiring these resources from JNDI. >>> >> >>> >> My frustration lies in the JTA spec itself, requiring JNDI due to >>> >> remnants from the EJB 2.1 era. Which is why I consider my approach to >>> >> be a feature request as opposed to a bug - its a 'nice to have' when >>> >> using a JTA TM that doesn't require JNDI. >>> >> >>> >> And I agree that JTATransaction _should_ be using the JNDI lookup - my >>> >> intention was never to change that, ensuring 100% backwards >>> >> compatibility. My intention was that the JTATransaction was a minimal >>> >> subclass of a parent abstract class. That abstract class would >>> >> delegate to children classes how do do the lookup, and in the >>> >> JTATransaction case, it would do it from JNDI, just as things occur >>> >> today. >>> >> >>> >>> However, I have no issue with adding support for these psuedo-JTA TMs. >>> >>> Its just a matter of semantics and being consistent with terminology. >>> >>> So, the basic thing we are trying to describe is support for interacting >>> >>> with "distributed transaction" systems. So, I'd prefer that the base >>> >>> class in question here be called DistributedTransaction, of which >>> >>> JTATransaction would be a subclass with the same behavior as it has >>> >>> today (some delegated to its new super). And from there we can begin to >>> >>> build the support for Atomikos and the other TP services not conforming >>> >>> to the JNDI aspect of the JTA spec. >>> >> >>> >> Perfect, this is exactly my thinking as well. And I much prefer your >>> >> superclass name ;) I'll post to this list again when I have my patch
Re: [hibernate-dev] Work on HHH-3110
http://hibernate.org/436.html is the developer resource page. If you click through the "Intellij User Info" link it will show you the style config I use. Unfortunately our wiki does not have attachment capability, so the style xml doc is there inline; just follow the instructions... It'll be in 3.3.0 and 3.2.7 - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, 2008-06-26 at 13:36 -0400, Les Hazlewood wrote: > On Thu, Jun 26, 2008 at 1:28 PM, Steve Ebersole <[EMAIL PROTECTED]> wrote: > > One thing I'd ask for future is that you stick to hibernate style as it > > makes it easier to see *real* changes. For example, you are using > > space-expansion in place of tabs, etc. > > Ah, yes, I'll definitely do that - my apologies. I'm assuming there > is a style guide that I can use to ensure IntelliJ is set up > appropriately? > > > > > This discussion has come up before and I had been thinking of another > > approach to address this, however, my approach is more disruptive. > > Basically, right now we have this > > org.hibernate.transaction.TransactionManagerLookup contract which has > > morphed beyond a simple TM lookup. And wrt this discussion it is the > > point at which we make the decision to support only JTA-compliant TMs > > because org.hibernate.transaction.TransactionManagerLookup defines a > > getUserTransactionName() method which returns the JNDI namespace where > > the UserTransaction can be located. If this were instead changed to > > actually return the UserTransaction instance I think it is much cleaner > > in the long run. Conceptually, I think the argument to make the change > > here is much stronger since it aligns with the actual roles these things > > fulfill. Of course, because it is disruptive, such a change would need > > to wait until until at least 3.4. > > > > In the meantime, I'll go ahead and apply this patch (sans the tab > > cleanup and some javadoc changes). > > Very cool - thanks so much. In which release will it be available (so > I can tell the Atomikos guys)? > > Cheers, > > Les > > > On Thu, 2008-06-26 at 12:12 -0400, Les Hazlewood wrote: > >> Steve, Chris, > >> > >> What do you think? does this look good? > >> > >> On Wed, Jun 25, 2008 at 5:24 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> > Hey guys, > >> > > >> > I finally was able to attack this today and created an issue: > >> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358 > >> > > >> > The patch was created based on an SVN checkout of trunk and attached > >> > to the issue. Comments about the change and exactly what I did are > >> > detailed as well. > >> > > >> > The best thing about the fix is that I realized I didn't need to add > >> > any parent abstract classes or even subclasses. I was even able to > >> > consolidate a common JNDI lookup that was spread out (perhaps > >> > unnecessarily) across two classes into one class in one method. > >> > > >> > The change was pretty clean and only touched two files, but still > >> > retains backward compatibility. > >> > > >> > Please let me know what you think! > >> > > >> > Thanks, > >> > > >> > Les > >> > > >> > On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> >> Hi Steve! > >> >> > >> >> Great to hear from you again :) > >> >> > >> >>> Not sure why you find it so interesting considering that that JTA spec > >> >>> itself *requires* binding into JNDI :) This is true both in the older > >> >>> 1.0.1B as well as the latest 1.1 specs. Thus I do not believe > >> >>> that org.hibernate.transaction.JTATransaction is the correct place to > >> >>> be adding support for not acquiring these resources from JNDI. > >> >> > >> >> My frustration lies in the JTA spec itself, requiring JNDI due to > >> >> remnants from the EJB 2.1 era. Which is why I consider my approach to > >> >> be a feature request as opposed to a bug - its a 'nice to have' when > >> >> using a JTA TM that doesn't require JNDI. > >> >> > >> >> And I agree that JTATransaction _should_ be using the JNDI lookup - my > >> >> intention was never to change that, ensuring 100% backwards > >> >> compatibility. My intention was that the JTATransaction was a minimal > >> >> subclass of a parent abstract class. That abstract class would > >> >> delegate to children classes how do do the lookup, and in the > >> >> JTATransaction case, it would do it from JNDI, just as things occur > >> >> today. > >> >> > >> >>> However, I have no issue with adding support for these psuedo-JTA TMs. > >> >>> Its just a matter of semantics and being consistent with terminology. > >> >>> So, the basic thing we are trying to describe is support for > >> >>> interacting > >> >>> with "distributed transaction" systems. So, I'd prefer that the base > >> >>> class in question here be called DistributedTransaction, of wh
