Do you have more info on these failures?
On Mar 9, 2012, at 7:01 PM, Steve Ebersole wrote:
Yaay! It ony took slightly over 5 minutes today. But of course:
Building :hibernate-infinispan:test Resolving dependencies
':hibernate-infinispan:test:hibernate-infinispan:test
Test
I think we should use classloading service to load it
yes, a HHH would be great.
-
Best Regards,
Strong Liu stliu at hibernate.org
http://about.me/stliu/bio
On Mar 13, 2012, at 8:24 AM, Scott Marlow wrote:
Should Hibernate 4.x use the AvailableSettings.APP_CLASSLOADER
Its just more of the same sometimes they pass, sometimes they fail.
On Tue 13 Mar 2012 03:44:25 AM CDT, Galder Zamarreño wrote:
Do you have more info on these failures?
On Mar 9, 2012, at 7:01 PM, Steve Ebersole wrote:
Yaay! It ony took slightly over 5 minutes today. But of course:
Is it koser to deploy JDBC drivers with an app? I thought the general
suggestion was to make them available to the server classpath?
On Tue 13 Mar 2012 06:47:14 AM CDT, Strong Liu wrote:
I think we should use classloading service to load it
yes, a HHH would be great.
from the post, it seems either deploy jdbc driver within war or deploy the
driver as module, hibernate fails to find it
-
Best Regards,
Strong Liu stliu at hibernate.org
http://about.me/stliu/bio
On Mar 13, 2012, at 8:51 PM, Steve Ebersole wrote:
Is it koser to deploy
I agree that its only a problem when the JDBC driver is not on the
server classpath (AS7 has Global Modules that allows for that as a
last resort option).
I think it is always better to have the JDBC drivers be available
globally. However, it doesn't matter which approach is used for these
Sure we can make a change like that. Like I said, just trying to make
sure this deployment setup is not frowned upon by AS.
On Tue 13 Mar 2012 08:43:12 AM CDT, Scott Marlow wrote:
I agree that its only a problem when the JDBC driver is not on the
server classpath (AS7 has Global Modules that
Hello,
About unit tests during the development phase on OGM-mongodb, I'm wondering
what is the best way.
Actually, I've developped some specific tests (CRUD mainly) because I was
not aware of the existing test suite. So my question is: should I remove
all my tests and just use core test or should
Hi all,
I have pushed the early draft we have been discussion for a while now to the
JCP. I also put a copy in the open. Check out http://goo.gl/FlAuQ
It contains main TODOs I would like your opinion on. But that's a significant
work that moves dependency injection and method-levle validation
I created HHH-7169 for this.
On 03/13/2012 11:26 AM, Steve Ebersole wrote:
Sure we can make a change like that. Like I said, just trying to make
sure this deployment setup is not frowned upon by AS.
On Tue 13 Mar 2012 08:43:12 AM CDT, Scott Marlow wrote:
I agree that its only a problem when
ok, I'll get to it later today hopefully
On Tue 13 Mar 2012 12:50:37 PM CDT, Scott Marlow wrote:
I created HHH-7169 for this.
On 03/13/2012 11:26 AM, Steve Ebersole wrote:
Sure we can make a change like that. Like I said, just trying to make
sure this deployment setup is not frowned upon by
Hi,
I'm answering inline:
On 13 March 2012 16:39, Guillaume SCHEIBEL guillaume.schei...@gmail.com wrote:
Hello,
About unit tests during the development phase on OGM-mongodb, I'm wondering
what is the best way.
Actually, I've developped some specific tests (CRUD mainly) because I was
not
On 13 mars 2012, at 20:19, Sanne Grinovero wrote:
Hi,
I'm answering inline:
On 13 March 2012 16:39, Guillaume SCHEIBEL guillaume.schei...@gmail.com
wrote:
Hello,
About unit tests during the development phase on OGM-mongodb, I'm wondering
what is the best way.
Actually, I've
Can someone verify I am not off my rocker here? Re :
https://hibernate.onjira.com/browse/HHH-7161
We have a case where Session defines a method that returns a public
interface org.hibernate.IdentifierLoadAccess. When SessionImpl
implements those methods it redefines the return to instead be
Hi,
I see it the same way as you do; narrowing down the return type in the
implementation class shouldn't be a problem.
I'm also getting no compilation error when compiling the user's code
(as you said, IdentifierLoadAccessImpl shouldn't even be visible at
the call site). Maybe it's a problem
Hi Steve,
On Tue, Mar 13, 2012 at 10:39 PM, Steve Ebersole st...@hibernate.org wrote:
As I understood it, when accessed through the Session interface what
return type is defined by SessionImpl is irrelevant. And indeed I am
not able to reproduce this when access those methods via Session. My
16 matches
Mail list logo
