Re: [Springframework-developer] JBoss 3.2.4 WrappedResultSet support added in JBossNativeJdbcAdapter

[Colin S. <col...@ex...>]

Your changes work fine in JBoss 3.2.4. My probs with the integration 
test seem to be related to try to get two HSQLDB datasources going in 
JBoss at the same time. I added another one pointing to an external HSQL 
db and it wasn't a happy puppy, but the extractor works fine against a 
good DS.

I'll check in the integration test some time in the next day or two...

Colin


jürgen höller [werk3AT] wrote:

>I guess there's no way around integration for these things, against multiple versions of those products. Unit tests can just try to mock specific behavior, which doesn't say much about compatibility with actual versions of the real product.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Tuesday, June 22, 2004 8:04 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] JBoss 3.2.4 WrappedResultSet
>support added in JBossNativeJdbcAdapter
>
>
>Coincidentally, I was actually just working on an integration test for 
>testing that class. Unfortunately JBoss is giving me exceptions on 
>actually trying to call the methods to get the wrapped object, saying 
>something like 'the Subject does not have the required credentials". 
>Will continue digging into this.
>
>In general, I think we need to get integration level tests which hit all 
>of the extra stuff like these helper classes which can not be covered by 
>unit tests. I actually started down the route of using jMock or EasyMock 
>to mock the JBoss classes using cglib, but it's problematic since you 
>then need access to a ton of app server classes. Even if jMock or 
>EasyMock do allow you to mock classes (and not just interfaces) via 
>cglib, it's not generally a great practice or practical to mock external 
>classes.
>
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Colin,
>>
>>I've just rewritten all of JBossNativeJdbcExtractor with reflection, to get entirely rid of any jboss.jar dependency (and also the jdbc-common-jdbc-wrapper.jar). It caches the retrieved classes and methods in the constructor now, just like WebLogicNativeJdbcExtractor and WebSphereNativeJdbcExtractor.
>>
>>I've tested the new version against JBoss 3.2.1 - still works nicely. Could you please test it against JBoss 3.2.4? (I don't want to download those 50 MB just for testing this...)
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of jürgen höller [werk3AT]
>>Sent: Monday, June 21, 2004 10:50 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] JBoss 3.2.4 WrappedResultSet
>>support added in JBossNativeJdbcAdapter
>>
>>
>>Colin,
>>
>>I second that. Please code it via reflection; we wouldn't wan't to ship a 1.6 MB jboss.jar just because of that. The 45 KB jboss-common-jdbc.wrapper.jar is fine, so I guess just coding the ResultSet unwrapping via reflection should be good enough.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Rod Johnson
>>Gesendet: So 20.06.2004 16:16
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] JBoss 3.2.4 WrappedResultSet support added in JBossNativeJdbcAdapter
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>>>I just realized this ties this class to JBoss 3.2.4. Probably not a
>>>reasonable thing to do since people might be running 3.2.3 (or 3.2.2)
>>>for a while yet. Anybody object if I make the wrapped ResultSet access
>>>via reflection?
>>>   
>>>
>>>      
>>>
>>No, please do.
>>
>>    
>>