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
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
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 a
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
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 cre
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.
Th
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.JTATransac
Hey Les, yes it has been a long time.
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 c
Yes, I wholeheartedly agree. This is definitely a feature request
and not a bug.
I'll do that and see what you guys think. And if you or Steve want to
squash it, that's fine too, but at least I'm trying :-D
Thanks,
Les
On Thu, Jun 19, 2008 at 5:57 PM, Chris Bredesen <[EMAIL PROTECTED]> wrote
Les Hazlewood wrote:
Hi guys,
It has been a while since I've talked to most of the Hibernate team -
I hope all is well with everyone. I can say that I miss that I miss
working with the people, not so much the consulting travel :-P
Anyway, lemme get to business.
I upgraded from 3.2.5 to 3.2.6
Nope - no coupling required :)
What I'm proposing is purely restricted to Hibernate's existing
dependencies and would work for any TM implementation, not just
Atomikos or JOTM.
It is the TM-specific TransactionManagerLookup (or perhaps a
TM-specific JTATransactionFactory) that would choose the
im
Hi again,
> And I know that works, but I feel like it is a hack. If the
> underlying TM doesn't require JNDI, why force it just to get around a
> lookup that is meaningless? Also, this would make a lot of other
> people happy.
>
I agree with you... For me at least (I'm not a J2EE infrastructure
My other belief, and one that is paramount in my own open source
project, is that a framework/toolkit always _should_ employ these
philosophies to support its user base and the other framework
communities that depend on it, if the solution is relatively trivial.
It is, IMHO, a good framework's res
Les Hazlewood wrote:
I agree with you Chris, it does better simulate it. But Hibernate has
always been deployable outside of a container. Shouldn't it retain
that philosophy in its code base as well, architecting flexible
approaches that work seamlessly both in a JEE container and out?
That's
I agree with you Chris, it does better simulate it. But Hibernate has
always been deployable outside of a container. Shouldn't it retain
that philosophy in its code base as well, architecting flexible
approaches that work seamlessly both in a JEE container and out?
That's my belief...
On Thu, J
joël Winteregg wrote:
I also had the same issue which was fixed using an update of the
transaction manager I use (Bitronix 1.3). A light JNDI server is now
embedded in it...
This is an alternative that I've discussed with others off list. IMHO,
this better simulates the in-container JTA envir
Hi Joël,
Thanks for the feedback :)
And I know that works, but I feel like it is a hack. If the
underlying TM doesn't require JNDI, why force it just to get around a
lookup that is meaningless? Also, this would make a lot of other
people happy.
In other words, this problem wasn't in 3.2.5 and b
Hi Les,
I also had the same issue which was fixed using an update of the
transaction manager I use (Bitronix 1.3). A light JNDI server is now
embedded in it...
For info, the main developer of Bitronix is also working for Atomikos
(JTA world seems to be small ;-)
My JNDI hibernate.cfg.xml is now
Hi guys,
It has been a while since I've talked to most of the Hibernate team -
I hope all is well with everyone. I can say that I miss that I miss
working with the people, not so much the consulting travel :-P
Anyway, lemme get to business.
I upgraded from 3.2.5 to 3.2.6 and started getting exc
19 matches
Mail list logo
