Hibernate extension testing

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Hibernate extension testing

Holger
Hey guys,

I intend to add some testcases for the new Hibernate extension.
Where to put these unittests? I guess

test/ca/odell/glazedlists/hibernate

would fit the pattern.

Unfortunately, running tests with Hibernate requires a bunch of
additional jars in the classpath:

antlr.jar
cglib.jar
asm.jar
asm-attrs.jars
commons-collections.jar
commons-logging.jar
log4j.jar
jta.jar
dom4j.jar
hibernate3.jar
hsqldb.jar

How to handle that? Download with HttpClient as usual?

Thanks,
Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hibernate extension testing

Jesse Wilson
Hey Holger ---

I recommend you create a single uberjar called
umm hibernate-libs.jar and just jam everything in
there. Then you can get HttpClient to download
that.

As for tests location, we've typically done them
in the plain old tests/ folder, but I agree that
extensions/test might be better.

Cheers,
Jesse

On 8/19/06, Holger Brands <[hidden email]> wrote:

> Hey guys,
>
> I intend to add some testcases for the new Hibernate extension.
> Where to put these unittests? I guess
>
> test/ca/odell/glazedlists/hibernate
>
> would fit the pattern.
>
> Unfortunately, running tests with Hibernate requires a bunch of
> additional jars in the classpath:
>
> antlr.jar
> cglib.jar
> asm.jar
> asm-attrs.jars
> commons-collections.jar
> commons-logging.jar
> log4j.jar
> jta.jar
> dom4j.jar
> hibernate3.jar
> hsqldb.jar
>
> How to handle that? Download with HttpClient as usual?
>
> Thanks,
> Holger
>
> ______________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hibernate extension testing

Holger
In reply to this post by Holger
Jesse,

> Hey Holger ---
>
> I recommend you create a single uberjar called
> umm hibernate-libs.jar and just jam everything in
> there. Then you can get HttpClient to download
> that.

Good idea, I'll try that. Then we will have only
hibernate.jar
hibernate-libs.jar
hsqldb.jar (could be another JDBC driver)

>
> As for tests location, we've typically done them
> in the plain old tests/ folder, but I agree that
> extensions/test might be better.

Actually, I was refering to the plain old test folder.

One other option would be to have a source and test folder
per extension so that it would be self-contained.
On the other side, compiling tests would be more complicated
- but analog to compiling sources.

Just an idea,
Holger

>
> Cheers,
> Jesse
>
> On 8/19/06, Holger Brands <[hidden email]> wrote:
> > Hey guys,
> >
> > I intend to add some testcases for the new Hibernate extension.
> > Where to put these unittests? I guess
> >
> > test/ca/odell/glazedlists/hibernate
> >
> > would fit the pattern.
> >
> > Unfortunately, running tests with Hibernate requires a bunch of
> > additional jars in the classpath:
> >
> > antlr.jar
> > cglib.jar
> > asm.jar
> > asm-attrs.jars
> > commons-collections.jar
> > commons-logging.jar
> > log4j.jar
> > jta.jar
> > dom4j.jar
> > hibernate3.jar
> > hsqldb.jar
> >
> > How to handle that? Download with HttpClient as usual?
> >
> > Thanks,
> > Holger
> >
> > ______________________________________________________________
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Hibernate extension testing

Jesse Wilson
On 8/19/06, Holger Brands <[hidden email]> wrote:
> One other option would be to have a source and test folder
> per extension so that it would be self-contained.
> On the other side, compiling tests would be more complicated
> - but analog to compiling sources.

It's up to you dude. I like the idea of using Hypersonic so
the tests can be completely self-contained. It shouldn't be
necessary to have a database installed to run the hibernate
tests, just in case I need to do some work on it! And hopefully
any files created by the db get cleaned up after the tests
complete.

I'm totally stoked about Hibernate support.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Hibernate extension testing

James Lemieux
+1 for hibernate-libs.jar from me

as for where the test cases should be located, I'd probably recommend placing them where the others are, mainly for consistency and because cross-extension testing, if necessary, makes good sense in a "communal location" rather that in either of the extensions.

But, I'm not a staunch defender of the status quo. This is more of a preference that anything else...

James

On 8/19/06, Jesse Wilson < [hidden email]> wrote:
On 8/19/06, Holger Brands < [hidden email]> wrote:
> One other option would be to have a source and test folder
> per extension so that it would be self-contained.
> On the other side, compiling tests would be more complicated
> - but analog to compiling sources.

It's up to you dude. I like the idea of using Hypersonic so
the tests can be completely self-contained. It shouldn't be
necessary to have a database installed to run the hibernate
tests, just in case I need to do some work on it! And hopefully
any files created by the db get cleaned up after the tests
complete.

I'm totally stoked about Hibernate support.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Hibernate extension testing

Holger
In reply to this post by Holger
Hey guys,

I've just added some initial tests for the hibernate extension, see
package test\ca\odell\glazedlists\hibernate.
There are now three jars downloaded:
hibernate.jar
hibernate-libs.jar
hsqldb.jar

The tests run with an in-memory HSQL-DB.
The hibernate extension dir contains a subdir 'etc'
which contains the required hibernate and log4j configuration.

Things work ok so far.
Two things to note:

1.) lazy collections
Initializing a lazy loaded EventList causes list events to be triggered,
two for each list element, because for some reason Hibernate adds first
'null' and then sets the correct value for each element.
So, if you've registered listeners on this list, you'll get these (unexpected/undesired?)
events.

2.) ClassCastException with debug logging
Turning on the Hibernate debug logging causes a ClassCastException when
Hibernate tries to log away the entities at flush time.
But that issue is not specific to our implementation, but happens also with
the UserCollectionType from the Hibernate tests and others as well.
For example, see the comments to issue
http://opensource.atlassian.com/projects/hibernate/browse/HHH-547?decorator=printable


Please let me know any problems or suggestions.

BTW, the java14 build is currently broken.
com.publicobject.misc.util.concurrent.QueuedExecutor seems to hava a problem.

Thanks,
Holger


>+1 for hibernate-libs.jar from me
>
> as for where the test cases should be located, I'd probably recommend placing them where the others are, mainly for consistency and because cross-extension testing, if necessary, makes good sense in a "communal location" rather that in either of the extensions.
>
>
> But, I'm not a staunch defender of the status quo. This is more of a preference that anything else...
>
> James
>
>
> On 8/19/06, Jesse Wilson <
> [hidden email]> wrote:On 8/19/06, Holger Brands <
> [hidden email]> wrote:
> > One other option would be to have a source and test folder
> > per extension so that it would be self-contained.
> > On the other side, compiling tests would be more complicated
>
> > - but analog to compiling sources.
>
> It's up to you dude. I like the idea of using Hypersonic so
> the tests can be completely self-contained. It shouldn't be
> necessary to have a database installed to run the hibernate
>
> tests, just in case I need to do some work on it! And hopefully
> any files created by the db get cleaned up after the tests
> complete.
>
> I'm totally stoked about Hibernate support.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Hibernate extension testing

James Lemieux
Holger, et al,

   I fixed up the java14 build tonight. QueuedExecutor was using an anonymous inner class, which is not supported by Declawer at this point, so I simply had to make a small inner class to get by that problem.

   I also added treetable in the java14 build, which pointed out a few small problems in TreeList code w.r.t. the java14 build, but they were all trivial to work around.

   So, long story short, is, our java14 build is healthy again.

James

On 8/20/06, Holger Brands <[hidden email]> wrote:
Hey guys,

I've just added some initial tests for the hibernate extension, see
package test\ca\odell\glazedlists\hibernate.
There are now three jars downloaded:
hibernate.jar
hibernate-libs.jar
hsqldb.jar

The tests run with an in-memory HSQL-DB.
The hibernate extension dir contains a subdir 'etc'
which contains the required hibernate and log4j configuration.

Things work ok so far.
Two things to note:

1.) lazy collections
Initializing a lazy loaded EventList causes list events to be triggered,
two for each list element, because for some reason Hibernate adds first
'null' and then sets the correct value for each element.
So, if you've registered listeners on this list, you'll get these (unexpected/undesired?)
events.

2.) ClassCastException with debug logging
Turning on the Hibernate debug logging causes a ClassCastException when
Hibernate tries to log away the entities at flush time.
But that issue is not specific to our implementation, but happens also with
the UserCollectionType from the Hibernate tests and others as well.
For example, see the comments to issue
http://opensource.atlassian.com/projects/hibernate/browse/HHH-547?decorator=printable


Please let me know any problems or suggestions.

BTW, the java14 build is currently broken.
com.publicobject.misc.util.concurrent.QueuedExecutor seems to hava a problem.

Thanks,
Holger


>+1 for hibernate-libs.jar from me
>
> as for where the test cases should be located, I'd probably recommend placing them where the others are, mainly for consistency and because cross-extension testing, if necessary, makes good sense in a "communal location" rather that in either of the extensions.
>
>
> But, I'm not a staunch defender of the status quo. This is more of a preference that anything else...
>
> James
>
>
> On 8/19/06, Jesse Wilson <
> [hidden email]> wrote:On 8/19/06, Holger Brands <
> [hidden email]> wrote:
> > One other option would be to have a source and test folder
> > per extension so that it would be self-contained.
> > On the other side, compiling tests would be more complicated
>
> > - but analog to compiling sources.
>
> It's up to you dude. I like the idea of using Hypersonic so
> the tests can be completely self-contained. It shouldn't be
> necessary to have a database installed to run the hibernate
>
> tests, just in case I need to do some work on it! And hopefully
> any files created by the db get cleaned up after the tests
> complete.
>
> I'm totally stoked about Hibernate support.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Hibernate extension testing

Bruce Alspaugh-2
In reply to this post by Holger
Hi Holger,

Thinking about issue #1, does Hibernate use proxy elements in the case
of lazily-loaded collections?  In other words, it initializes the
collection with proxies, and then only replaces them with the actual
object loaded from the DB when the application first tries to access the
element.  This might explain the behavior you are getting.

Bruce

Holger Brands wrote:

> Hey guys,
>
> I've just added some initial tests for the hibernate extension, see
> package test\ca\odell\glazedlists\hibernate.
> There are now three jars downloaded:
> hibernate.jar
> hibernate-libs.jar
> hsqldb.jar
>
> The tests run with an in-memory HSQL-DB.
> The hibernate extension dir contains a subdir 'etc'
> which contains the required hibernate and log4j configuration.
>
> Things work ok so far.
> Two things to note:
>
> 1.) lazy collections
> Initializing a lazy loaded EventList causes list events to be triggered,
> two for each list element, because for some reason Hibernate adds first
> 'null' and then sets the correct value for each element.
> So, if you've registered listeners on this list, you'll get these (unexpected/undesired?)
> events.
>
> 2.) ClassCastException with debug logging
> Turning on the Hibernate debug logging causes a ClassCastException when
> Hibernate tries to log away the entities at flush time.
> But that issue is not specific to our implementation, but happens also with
> the UserCollectionType from the Hibernate tests and others as well.
> For example, see the comments to issue
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-547?decorator=printable
>
>
> Please let me know any problems or suggestions.
>
> BTW, the java14 build is currently broken.
> com.publicobject.misc.util.concurrent.QueuedExecutor seems to hava a problem.
>
> Thanks,
> Holger
>
>
>  
>> +1 for hibernate-libs.jar from me
>>
>> as for where the test cases should be located, I'd probably recommend placing them where the others are, mainly for consistency and because cross-extension testing, if necessary, makes good sense in a "communal location" rather that in either of the extensions.
>>
>>
>> But, I'm not a staunch defender of the status quo. This is more of a preference that anything else...
>>
>> James
>>
>>
>> On 8/19/06, Jesse Wilson <
>> [hidden email]> wrote:On 8/19/06, Holger Brands <
>> [hidden email]> wrote:
>>    
>>> One other option would be to have a source and test folder
>>> per extension so that it would be self-contained.
>>> On the other side, compiling tests would be more complicated
>>>      
>>> - but analog to compiling sources.
>>>      
>> It's up to you dude. I like the idea of using Hypersonic so
>> the tests can be completely self-contained. It shouldn't be
>> necessary to have a database installed to run the hibernate
>>
>> tests, just in case I need to do some work on it! And hopefully
>> any files created by the db get cleaned up after the tests
>> complete.
>>
>> I'm totally stoked about Hibernate support.
>>
>> Cheers,
>> Jesse
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>    
>
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000071
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hibernate extension testing

Holger
In reply to this post by Holger
Hey Bruce,

> Hi Holger,
>
> Thinking about issue #1, does Hibernate use proxy elements in the case
> of lazily-loaded collections?  In other words, it initializes the
> collection with proxies, and then only replaces them with the actual
> object loaded from the DB when the application first tries to access the
> element.  This might explain the behavior you are getting.
>

Thanks for the suggestion.
I'm not sure if and when Hibernate fills the collection with proxy objects, perhaps with the
lazy="extra" property?

Anyway, after further investigation I found out that the following method from
PersistentList is called for every list element when the collection is initialized:

public Object readFrom(ResultSet rs, CollectionPersister persister, CollectionAliases descriptor, Object owner)
        throws HibernateException, SQLException {

  Object element = persister.readElement( rs, owner, descriptor.getSuffixedElementAliases(), getSession() ) ;
  int index = ( (Integer) persister.readIndex( rs, descriptor.getSuffixedIndexAliases(), getSession() ) ).intValue();
 
  //pad with nulls from the current last element up to the new index
  for ( int i = list.size(); i<=index; i++) {
    list.add(i, null);  // causes INSERT event
  }
  list.set(index, element); //causes UPDATE event
  return element;
}

You can see that an insert and an update occurs for a list element.
I figured this out using a list event listener and dumping a stack trace in 'listChanged'.

Thanks,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]