Alternatives to using AS DataSource remotely? - it caused me some headaches today :(
by Galder Zamarreno
After a bit of a fight, I have managed to run unsuccessfully JDBCCacheLoaderTest accessing the AS datasource remotely. The tests were failing with JBoss Serialization and not with Java Serialization.
After a bit of thought and discussion with Clebert, my gut feeling started to tell me that using the DataSource remotely was probably influencing the errors reported with JBoss Serialization.
I then took one of the tests and put it in a SAR and deployed in AS with the new JBossCache. I run the one of the failing tests via the MBean interface with jboss serialization on and it worked fine.
What does this tell me? Until we're not able to run the JDBCCacheLoaderTest inside the AS, we're not gonna be able to confirm that JDBCCacheLoader works fine inside AS. Besides, some of the tests use transactions and it'd be ideal to use JBoss TransactionManager for that.
This is important for the work I'm doing so that I can confirm I haven't broken anything anywhere else while introducing C3P0 connection pooling, so 3 choices here:
1) HACK, UGLY and everything bad u can think of!!! Create a SAR that contains all the tests in JDBCCacheLoaderTest and parent and check manually the logs. uuuuggghhhhh
2) Start up a mini App Server (JNDI, JDBC Connection Pooling, TransactionManager). If the JNDI was started locally from the unit test, I could potentially plug the Hypersonic DataSource and JBoss Transaction Manager and I could run the tests very easily and confirm that it works. Have you done this? Do you see it feasible? I might be able to use EJB3 standalone to provide a small container for this...
3) Create some kind of SAR that is deployed in a running AS and runs the test. I used to do this using Cactus in my previous work but didn't like it at all. Quite ugly as well.
Any other opinions?
p.s. Clebert, thanks for your help today :)
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
19 years, 3 months
State transfer and VAM (JBCACHE-908)
by Manik Surtani
Ok, guys. I've made a bunch of changes here, to allow the state
transfer code base work with the VAM.
1) Added interface methods for the VAM to read/write to streams
rather than just byte arrays (this is all JGroups used for RPC)
2) Added interface methods to the VAM so callers could pass in an
Fqn as a 'region' (up until now this was extracted from MethodCalls
for RPC)
3) Changed all stream read/write code in StateTransferManager,
DefaultStateTransferIntegrator, DefaultStateTransferGenerator,
StateTransferFactory and AbstractCacheLoader to use the marshaller
rather than direct stream IO
4) Changed same classes above to not set context class loaders for
regions. This is left up to the marshaller, which has knowledge of
how to do this anyway.
The result is simplified state transfer code (no concerns re: context
class loaders) and a unified marshalling mechanism.
So far, things look good and the unit tests run fine. Do shout if
this does break anything - Brian, particularly interested in how this
deals with regions with web app deployment in AS.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 3 months
RE: FAO Brian & Manik - RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
by Galder Zamarreno
I need JNDI and JDBC connection pooling so that I can test the ManagedConnectionFactory path. Basically, retrieve the DataSource from JNDI and make sure that the JDBCCacheLoaderTest works fine with it.
I'm gonna try setting this up in the test using libraries from AS. Otherwise, I might failover on standalone pooling from C3P0 that I could bind to JNDI and try that.
C3P0 stuff is moving forward. I hope to have it ready by Monday including documentation, fingers crossed :)
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 17 January 2007 10:24
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: FAO Brian & Manik - RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
On 16 Jan 2007, at 18:58, Galder Zamarreno wrote:
> In fact, I can't see a straightforward way of running
> JDBCCacheLoaderTest without running the test inside AS. We could
> set up the necessary libraries and system properties to query java:/
> DefaultDS, but of course, you can only search this locally.
>
> There's a hack to make DefaultDS available outside the VM but this
> returns javax.naming.Reference and not javax.sql.DataSource, so any
> attempt to go down this route would mean modification to the source
> code.
>
> I just wanna make sure that the JDBCCacheLoaderTest runs for
> ManagedConnectionFactories. This is because as a result of
> introducing external standalone connection pooling, I'm having to
> do some fairly fundamental changes JDBCCacheLoader. I can easily
> test NonManagedConnectionFactory and C3P0ConnectionFactory, but
> testing ManagedConnectionFactories path becomes a bit more
> complicated.
>
What resources do you need from the AS? Can these be emulated?
> In fact, deep down, I wanna refactor a little bit JDBCCacheLoader
> cos there's too much going on in one file and I'd like to take out
> some of the classes/interfaces defined inside.
+1!! :-)
>
> This might not be that important at this stage cos, which AS
> version would I test it against? JBossCache 2.0 won't work with
> 4.0.x, so the only use case for ManagedConnectionFactory I can
> think of would be a user defined cache with a JDBCCacheLoader as
> none of the 4.0.x code would be able to interact with this cache.
> Only user code could really interact with JBossCache 2.0 at the
> moment and even if they did, they either run default configuration
> or, if they run all, they'd need scoped deployment. Has it been
> defined the plan for 4.2 in terms of JBossCache? What version are
> we gonna be shipping there?
1.4.1.
>
> Brian, Manik, thoughts?
>
> For the moment, I'm focusing on getting all the stuff right for
> NonManagedConnectionFactory and C3P0ConnectionFactory paths.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: Galder Zamarreno
> Sent: 16 January 2007 18:23
> To: Galder Zamarreno; Ryan Campbell; Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding
> AS inside aUT?
>
> BTW, I have taken Head, modified cache-jdbc.properties so that I
> can test JDBCCacheLoaderTest with AS and the tests fail. Currently
> investigating it...
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 16 January 2007 17:49
> To: Ryan Campbell; Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding
> AS inside aUT?
>
> But thinking about this, should JBC be the one providing
> integration tests with Hibernate? Unlike JBDCCL where Cache is the
> client for AS, in Hibernate's case, it's Hibernate who's JBC's
> client and therefore, Hibernate should be the one tested.
>
>> From JBC's point of view, we don't know what we need to do to
>> Hibernate to confirm that is working correctly, it's not really
>> our domain. IMHO, this is Hibernate's domain and it's this project
>> who should include integration tests with JBC versions.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
> -----Original Message-----
> From: Ryan Campbell
> Sent: 16 January 2007 17:39
> To: Manik Surtani; Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding
> AS inside a UT?
>
> The portal builds do something similar. We have exploded jboss
> instances on cruisecontrol, and pass in their paths via system
> properties.
>
> We don't have anything like this for hibernate, although this is
> pretty easy using <get/> and repository.jboss.com.
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, January 16, 2007 4:05 AM
>> To: Galder Zamarreno
>> Cc: jbosscache-dev(a)lists.jboss.org; QA
>> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
>> inside a UT?
>>
>> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
>> version, starting and stopping it from within a unit test.
>>
>> As an immediate solution we could add this to the list of manual
>> release procedures so it gets done with every release, but as you
>> pointed out manual steps suck too.
>>
>> IMO, this falls into a category of integration tests (such as testing
>> with Hibernate releases) which needs to sit outside of the usual
>> cruise control runs and the functional test suite.
>>
>> I propose a more formal integration test suite (maybe with it's own
>> cruise control target?) which:
>>
>> 1) Pulls down different versions of JBC and performs compat/interop
>> tests (we already have these)
>> 2) Pulls down different Hibernate versions and performs tests on
>> these
>> 3) Pulls down different AS versions and performs tests, including
>> the JDBCCacheLoader with managed collections as well as other JBC
>> 'use cases' such as SFSBs and HTTP Sessions
>> 3.1) Different combinations of the versions in 2) and 3), to test
>> EJB3 entity beans
>> 3.2) Combinations including different JGroups versions
>>
>> So as you can see, we have a shit load of test combinations that can
>> come out of this. I do see the value here though, it will even make
>> QA's work in certifying JBC releases against AS versions and JGroups
>> versions (and even Hibernate versions) easier.
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>>
>>> I've been messing around with JDBCCacheLoader and I have realised
>>> that we don't currently have a unit test that can test the
>>> JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
>>> can work based on the cache-jdbc.properties and you could start AS
>>> manually and test it.
>>>
>>> This however is a manual process and when it comes to CC, only
>>> standalone JDBCCacheLoader is being tested.
>>>
>>> I think it'd be ideal to basically extend JDBCCacheLoaderTest to
>>> set it up to work with an AS (starting it/stopping it). This would
>>> give us even more confidence and coverage for the
>>> ManagedConnectionFactory area. I might not have time to do that
>>> before I commit my current work for BETA1 but definitely something
>>> worth bearing in mind.
>>>
>>> Another question would be of course, what AS version would be
>>> integrate against?
>>>
>>> There're various projects out there that have done something
>>> similar, first obviously AS itself and second messaging. What's
>>> your experience with this? What have we learnt about it? Shall we
>>> reuse some code for this? We would need a very limited AS version
>>> actually with JNDI, JDBC Connection Pooling, HS and HS driver.
>>>
>>> As you can see, this opens ups whole bunch of questions. Thoughts?
>>> Opinions? Critics?
>>>
>>> Cheers,
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>>> promo/vendor/
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 3 months
FAO Brian & Manik - RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
by Galder Zamarreno
In fact, I can't see a straightforward way of running JDBCCacheLoaderTest without running the test inside AS. We could set up the necessary libraries and system properties to query java:/DefaultDS, but of course, you can only search this locally.
There's a hack to make DefaultDS available outside the VM but this returns javax.naming.Reference and not javax.sql.DataSource, so any attempt to go down this route would mean modification to the source code.
I just wanna make sure that the JDBCCacheLoaderTest runs for ManagedConnectionFactories. This is because as a result of introducing external standalone connection pooling, I'm having to do some fairly fundamental changes JDBCCacheLoader. I can easily test NonManagedConnectionFactory and C3P0ConnectionFactory, but testing ManagedConnectionFactories path becomes a bit more complicated.
In fact, deep down, I wanna refactor a little bit JDBCCacheLoader cos there's too much going on in one file and I'd like to take out some of the classes/interfaces defined inside.
This might not be that important at this stage cos, which AS version would I test it against? JBossCache 2.0 won't work with 4.0.x, so the only use case for ManagedConnectionFactory I can think of would be a user defined cache with a JDBCCacheLoader as none of the 4.0.x code would be able to interact with this cache. Only user code could really interact with JBossCache 2.0 at the moment and even if they did, they either run default configuration or, if they run all, they'd need scoped deployment. Has it been defined the plan for 4.2 in terms of JBossCache? What version are we gonna be shipping there?
Brian, Manik, thoughts?
For the moment, I'm focusing on getting all the stuff right for NonManagedConnectionFactory and C3P0ConnectionFactory paths.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Galder Zamarreno
Sent: 16 January 2007 18:23
To: Galder Zamarreno; Ryan Campbell; Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
BTW, I have taken Head, modified cache-jdbc.properties so that I can test JDBCCacheLoaderTest with AS and the tests fail. Currently investigating it...
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 16 January 2007 17:49
To: Ryan Campbell; Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
But thinking about this, should JBC be the one providing integration tests with Hibernate? Unlike JBDCCL where Cache is the client for AS, in Hibernate's case, it's Hibernate who's JBC's client and therefore, Hibernate should be the one tested.
>From JBC's point of view, we don't know what we need to do to Hibernate to confirm that is working correctly, it's not really our domain. IMHO, this is Hibernate's domain and it's this project who should include integration tests with JBC versions.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Ryan Campbell
Sent: 16 January 2007 17:39
To: Manik Surtani; Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
The portal builds do something similar. We have exploded jboss instances on cruisecontrol, and pass in their paths via system properties.
We don't have anything like this for hibernate, although this is pretty easy using <get/> and repository.jboss.com.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, January 16, 2007 4:05 AM
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
> inside a UT?
>
> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
> version, starting and stopping it from within a unit test.
>
> As an immediate solution we could add this to the list of manual
> release procedures so it gets done with every release, but as you
> pointed out manual steps suck too.
>
> IMO, this falls into a category of integration tests (such as testing
> with Hibernate releases) which needs to sit outside of the usual
> cruise control runs and the functional test suite.
>
> I propose a more formal integration test suite (maybe with it's own
> cruise control target?) which:
>
> 1) Pulls down different versions of JBC and performs compat/interop
> tests (we already have these)
> 2) Pulls down different Hibernate versions and performs tests on these
> 3) Pulls down different AS versions and performs tests, including
> the JDBCCacheLoader with managed collections as well as other JBC
> 'use cases' such as SFSBs and HTTP Sessions
> 3.1) Different combinations of the versions in 2) and 3), to test
> EJB3 entity beans
> 3.2) Combinations including different JGroups versions
>
> So as you can see, we have a shit load of test combinations that can
> come out of this. I do see the value here though, it will even make
> QA's work in certifying JBC releases against AS versions and JGroups
> versions (and even Hibernate versions) easier.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>
> > I've been messing around with JDBCCacheLoader and I have realised
> > that we don't currently have a unit test that can test the
> > JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
> > can work based on the cache-jdbc.properties and you could start AS
> > manually and test it.
> >
> > This however is a manual process and when it comes to CC, only
> > standalone JDBCCacheLoader is being tested.
> >
> > I think it'd be ideal to basically extend JDBCCacheLoaderTest to
> > set it up to work with an AS (starting it/stopping it). This would
> > give us even more confidence and coverage for the
> > ManagedConnectionFactory area. I might not have time to do that
> > before I commit my current work for BETA1 but definitely something
> > worth bearing in mind.
> >
> > Another question would be of course, what AS version would be
> > integrate against?
> >
> > There're various projects out there that have done something
> > similar, first obviously AS itself and second messaging. What's
> > your experience with this? What have we learnt about it? Shall we
> > reuse some code for this? We would need a very limited AS version
> > actually with JNDI, JDBC Connection Pooling, HS and HS driver.
> >
> > As you can see, this opens ups whole bunch of questions. Thoughts?
> > Opinions? Critics?
> >
> > Cheers,
> >
> > Galder Zamarreño
> > Sr. Software Maintenance Engineer
> > JBoss, a division of Red Hat
> >
> > IT executives: Red Hat still #1 for value http://www.redhat.com/
> > promo/vendor/
> >
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 3 months
RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
by Brian Stansberry
I don't think the JBC testsuite is the place to test how the AS or Hibernate use it. Those tests belong in Hibernate or the AS.
I do think the JBC testsuite should test the major known usage patterns that people like Hibernate use (e.g. simulate a read followed by a putForExternalRead) so any problems can be found quickly. But you shouldn't need the AS to do that.
It would be great though if it were fairly easy to test a new version of JBC against the relevant releases of AS/Hibernate. E.g., perhaps a target in the AS/Hibernate testsuites that is able to execute the unit tests that involve JBC, along with some infrastructure to pull in the desired JBC release.
I'm not fundamentally disagreeing with what Manik said about integration tests though -- I don't like http session replication tests in the JBC testsuite, but that's different from tests of how JBC uses AS resources. A lot of JBC code assumes the presence of JEE resources; there should be tests of that code that are run in a real JEE environment. The JDBCCacheLoader case is one; another issue is the use of DummyTransactionManager in most unit tests in lieu of testing in the AS with a real transaction manager.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> But thinking about this, should JBC be the one providing
> integration tests with Hibernate? Unlike JBDCCL where Cache
> is the client for AS, in Hibernate's case, it's Hibernate
> who's JBC's client and therefore, Hibernate should be the one tested.
>
>> From JBC's point of view, we don't know what we need to do
> to Hibernate to confirm that is working correctly, it's not
> really our domain. IMHO, this is Hibernate's domain and it's
> this project who should include integration tests with JBC versions.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value
> http://www.redhat.com/promo/vendor/
>
> -----Original Message-----
> From: Ryan Campbell
> Sent: 16 January 2007 17:39
> To: Manik Surtani; Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader -
> Embedding AS inside a UT?
>
> The portal builds do something similar. We have exploded
> jboss instances on cruisecontrol, and pass in their paths via
> system properties.
>
> We don't have anything like this for hibernate, although this
> is pretty easy using <get/> and repository.jboss.com.
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, January 16, 2007 4:05 AM
>> To: Galder Zamarreno
>> Cc: jbosscache-dev(a)lists.jboss.org; QA
>> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
>> inside a UT?
>>
>> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
>> version, starting and stopping it from within a unit test.
>>
>> As an immediate solution we could add this to the list of manual
>> release procedures so it gets done with every release, but as you
>> pointed out manual steps suck too.
>>
>> IMO, this falls into a category of integration tests (such as testing
>> with Hibernate releases) which needs to sit outside of the usual
>> cruise control runs and the functional test suite.
>>
>> I propose a more formal integration test suite (maybe with it's own
>> cruise control target?) which:
>>
>> 1) Pulls down different versions of JBC and performs compat/interop
>> tests (we already have these) 2) Pulls down different Hibernate
>> versions and performs tests on these 3) Pulls down different AS
>> versions and performs tests, including the JDBCCacheLoader with
>> managed collections as well as other JBC 'use cases' such as SFSBs
>> and HTTP Sessions
>> 3.1) Different combinations of the versions in 2) and 3), to test
>> EJB3 entity beans
>> 3.2) Combinations including different JGroups versions
>>
>> So as you can see, we have a shit load of test combinations that can
>> come out of this. I do see the value here though, it will even make
>> QA's work in certifying JBC releases against AS versions and JGroups
>> versions (and even Hibernate versions) easier.
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>>
>>> I've been messing around with JDBCCacheLoader and I have realised
>>> that we don't currently have a unit test that can test the
>>> JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
>>> can work based on the cache-jdbc.properties and you could start AS
>>> manually and test it.
>>>
>>> This however is a manual process and when it comes to CC, only
>>> standalone JDBCCacheLoader is being tested.
>>>
>>> I think it'd be ideal to basically extend JDBCCacheLoaderTest to set
>>> it up to work with an AS (starting it/stopping it). This would give
>>> us even more confidence and coverage for the
>>> ManagedConnectionFactory area. I might not have time to do that
>>> before I commit my current work for BETA1 but definitely something
>>> worth bearing in mind.
>>>
>>> Another question would be of course, what AS version would be
>>> integrate against?
>>>
>>> There're various projects out there that have done something
>>> similar, first obviously AS itself and second messaging. What's your
>>> experience with this? What have we learnt about it? Shall we reuse
>>> some code for this? We would need a very limited AS version actually
>>> with JNDI, JDBC Connection Pooling, HS and HS driver.
>>>
>>> As you can see, this opens ups whole bunch of questions. Thoughts?
>>> Opinions? Critics?
>>>
>>> Cheers,
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>>> promo/vendor/
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 3 months
RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
by Galder Zamarreno
BTW, I have taken Head, modified cache-jdbc.properties so that I can test JDBCCacheLoaderTest with AS and the tests fail. Currently investigating it...
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 16 January 2007 17:49
To: Ryan Campbell; Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside aUT?
But thinking about this, should JBC be the one providing integration tests with Hibernate? Unlike JBDCCL where Cache is the client for AS, in Hibernate's case, it's Hibernate who's JBC's client and therefore, Hibernate should be the one tested.
>From JBC's point of view, we don't know what we need to do to Hibernate to confirm that is working correctly, it's not really our domain. IMHO, this is Hibernate's domain and it's this project who should include integration tests with JBC versions.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Ryan Campbell
Sent: 16 January 2007 17:39
To: Manik Surtani; Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
The portal builds do something similar. We have exploded jboss instances on cruisecontrol, and pass in their paths via system properties.
We don't have anything like this for hibernate, although this is pretty easy using <get/> and repository.jboss.com.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, January 16, 2007 4:05 AM
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
> inside a UT?
>
> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
> version, starting and stopping it from within a unit test.
>
> As an immediate solution we could add this to the list of manual
> release procedures so it gets done with every release, but as you
> pointed out manual steps suck too.
>
> IMO, this falls into a category of integration tests (such as testing
> with Hibernate releases) which needs to sit outside of the usual
> cruise control runs and the functional test suite.
>
> I propose a more formal integration test suite (maybe with it's own
> cruise control target?) which:
>
> 1) Pulls down different versions of JBC and performs compat/interop
> tests (we already have these)
> 2) Pulls down different Hibernate versions and performs tests on these
> 3) Pulls down different AS versions and performs tests, including
> the JDBCCacheLoader with managed collections as well as other JBC
> 'use cases' such as SFSBs and HTTP Sessions
> 3.1) Different combinations of the versions in 2) and 3), to test
> EJB3 entity beans
> 3.2) Combinations including different JGroups versions
>
> So as you can see, we have a shit load of test combinations that can
> come out of this. I do see the value here though, it will even make
> QA's work in certifying JBC releases against AS versions and JGroups
> versions (and even Hibernate versions) easier.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>
> > I've been messing around with JDBCCacheLoader and I have realised
> > that we don't currently have a unit test that can test the
> > JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
> > can work based on the cache-jdbc.properties and you could start AS
> > manually and test it.
> >
> > This however is a manual process and when it comes to CC, only
> > standalone JDBCCacheLoader is being tested.
> >
> > I think it'd be ideal to basically extend JDBCCacheLoaderTest to
> > set it up to work with an AS (starting it/stopping it). This would
> > give us even more confidence and coverage for the
> > ManagedConnectionFactory area. I might not have time to do that
> > before I commit my current work for BETA1 but definitely something
> > worth bearing in mind.
> >
> > Another question would be of course, what AS version would be
> > integrate against?
> >
> > There're various projects out there that have done something
> > similar, first obviously AS itself and second messaging. What's
> > your experience with this? What have we learnt about it? Shall we
> > reuse some code for this? We would need a very limited AS version
> > actually with JNDI, JDBC Connection Pooling, HS and HS driver.
> >
> > As you can see, this opens ups whole bunch of questions. Thoughts?
> > Opinions? Critics?
> >
> > Cheers,
> >
> > Galder Zamarreño
> > Sr. Software Maintenance Engineer
> > JBoss, a division of Red Hat
> >
> > IT executives: Red Hat still #1 for value http://www.redhat.com/
> > promo/vendor/
> >
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 3 months
RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
by Galder Zamarreno
But thinking about this, should JBC be the one providing integration tests with Hibernate? Unlike JBDCCL where Cache is the client for AS, in Hibernate's case, it's Hibernate who's JBC's client and therefore, Hibernate should be the one tested.
>From JBC's point of view, we don't know what we need to do to Hibernate to confirm that is working correctly, it's not really our domain. IMHO, this is Hibernate's domain and it's this project who should include integration tests with JBC versions.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Ryan Campbell
Sent: 16 January 2007 17:39
To: Manik Surtani; Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
The portal builds do something similar. We have exploded jboss instances on cruisecontrol, and pass in their paths via system properties.
We don't have anything like this for hibernate, although this is pretty easy using <get/> and repository.jboss.com.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, January 16, 2007 4:05 AM
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
> inside a UT?
>
> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
> version, starting and stopping it from within a unit test.
>
> As an immediate solution we could add this to the list of manual
> release procedures so it gets done with every release, but as you
> pointed out manual steps suck too.
>
> IMO, this falls into a category of integration tests (such as testing
> with Hibernate releases) which needs to sit outside of the usual
> cruise control runs and the functional test suite.
>
> I propose a more formal integration test suite (maybe with it's own
> cruise control target?) which:
>
> 1) Pulls down different versions of JBC and performs compat/interop
> tests (we already have these)
> 2) Pulls down different Hibernate versions and performs tests on these
> 3) Pulls down different AS versions and performs tests, including
> the JDBCCacheLoader with managed collections as well as other JBC
> 'use cases' such as SFSBs and HTTP Sessions
> 3.1) Different combinations of the versions in 2) and 3), to test
> EJB3 entity beans
> 3.2) Combinations including different JGroups versions
>
> So as you can see, we have a shit load of test combinations that can
> come out of this. I do see the value here though, it will even make
> QA's work in certifying JBC releases against AS versions and JGroups
> versions (and even Hibernate versions) easier.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>
> > I've been messing around with JDBCCacheLoader and I have realised
> > that we don't currently have a unit test that can test the
> > JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
> > can work based on the cache-jdbc.properties and you could start AS
> > manually and test it.
> >
> > This however is a manual process and when it comes to CC, only
> > standalone JDBCCacheLoader is being tested.
> >
> > I think it'd be ideal to basically extend JDBCCacheLoaderTest to
> > set it up to work with an AS (starting it/stopping it). This would
> > give us even more confidence and coverage for the
> > ManagedConnectionFactory area. I might not have time to do that
> > before I commit my current work for BETA1 but definitely something
> > worth bearing in mind.
> >
> > Another question would be of course, what AS version would be
> > integrate against?
> >
> > There're various projects out there that have done something
> > similar, first obviously AS itself and second messaging. What's
> > your experience with this? What have we learnt about it? Shall we
> > reuse some code for this? We would need a very limited AS version
> > actually with JNDI, JDBC Connection Pooling, HS and HS driver.
> >
> > As you can see, this opens ups whole bunch of questions. Thoughts?
> > Opinions? Critics?
> >
> > Cheers,
> >
> > Galder Zamarreño
> > Sr. Software Maintenance Engineer
> > JBoss, a division of Red Hat
> >
> > IT executives: Red Hat still #1 for value http://www.redhat.com/
> > promo/vendor/
> >
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
19 years, 3 months
RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
by Ryan Campbell
The portal builds do something similar. We have exploded jboss instances on cruisecontrol, and pass in their paths via system properties.
We don't have anything like this for hibernate, although this is pretty easy using <get/> and repository.jboss.com.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, January 16, 2007 4:05 AM
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
> inside a UT?
>
> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
> version, starting and stopping it from within a unit test.
>
> As an immediate solution we could add this to the list of manual
> release procedures so it gets done with every release, but as you
> pointed out manual steps suck too.
>
> IMO, this falls into a category of integration tests (such as testing
> with Hibernate releases) which needs to sit outside of the usual
> cruise control runs and the functional test suite.
>
> I propose a more formal integration test suite (maybe with it's own
> cruise control target?) which:
>
> 1) Pulls down different versions of JBC and performs compat/interop
> tests (we already have these)
> 2) Pulls down different Hibernate versions and performs tests on these
> 3) Pulls down different AS versions and performs tests, including
> the JDBCCacheLoader with managed collections as well as other JBC
> 'use cases' such as SFSBs and HTTP Sessions
> 3.1) Different combinations of the versions in 2) and 3), to test
> EJB3 entity beans
> 3.2) Combinations including different JGroups versions
>
> So as you can see, we have a shit load of test combinations that can
> come out of this. I do see the value here though, it will even make
> QA's work in certifying JBC releases against AS versions and JGroups
> versions (and even Hibernate versions) easier.
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>
> > I've been messing around with JDBCCacheLoader and I have realised
> > that we don't currently have a unit test that can test the
> > JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
> > can work based on the cache-jdbc.properties and you could start AS
> > manually and test it.
> >
> > This however is a manual process and when it comes to CC, only
> > standalone JDBCCacheLoader is being tested.
> >
> > I think it'd be ideal to basically extend JDBCCacheLoaderTest to
> > set it up to work with an AS (starting it/stopping it). This would
> > give us even more confidence and coverage for the
> > ManagedConnectionFactory area. I might not have time to do that
> > before I commit my current work for BETA1 but definitely something
> > worth bearing in mind.
> >
> > Another question would be of course, what AS version would be
> > integrate against?
> >
> > There're various projects out there that have done something
> > similar, first obviously AS itself and second messaging. What's
> > your experience with this? What have we learnt about it? Shall we
> > reuse some code for this? We would need a very limited AS version
> > actually with JNDI, JDBC Connection Pooling, HS and HS driver.
> >
> > As you can see, this opens ups whole bunch of questions. Thoughts?
> > Opinions? Critics?
> >
> > Cheers,
> >
> > Galder Zamarreño
> > Sr. Software Maintenance Engineer
> > JBoss, a division of Red Hat
> >
> > IT executives: Red Hat still #1 for value http://www.redhat.com/
> > promo/vendor/
> >
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
19 years, 3 months
RE: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
by Galder Zamarreno
+100...
Something we can start looking at once 2.0 is out?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 16 January 2007 11:05
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org; QA
Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS inside a UT?
Wow. I'd hate to add the weight of downloading (on the fly?) an AS
version, starting and stopping it from within a unit test.
As an immediate solution we could add this to the list of manual
release procedures so it gets done with every release, but as you
pointed out manual steps suck too.
IMO, this falls into a category of integration tests (such as testing
with Hibernate releases) which needs to sit outside of the usual
cruise control runs and the functional test suite.
I propose a more formal integration test suite (maybe with it's own
cruise control target?) which:
1) Pulls down different versions of JBC and performs compat/interop
tests (we already have these)
2) Pulls down different Hibernate versions and performs tests on these
3) Pulls down different AS versions and performs tests, including
the JDBCCacheLoader with managed collections as well as other JBC
'use cases' such as SFSBs and HTTP Sessions
3.1) Different combinations of the versions in 2) and 3), to test
EJB3 entity beans
3.2) Combinations including different JGroups versions
So as you can see, we have a shit load of test combinations that can
come out of this. I do see the value here though, it will even make
QA's work in certifying JBC releases against AS versions and JGroups
versions (and even Hibernate versions) easier.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
> I've been messing around with JDBCCacheLoader and I have realised
> that we don't currently have a unit test that can test the
> JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
> can work based on the cache-jdbc.properties and you could start AS
> manually and test it.
>
> This however is a manual process and when it comes to CC, only
> standalone JDBCCacheLoader is being tested.
>
> I think it'd be ideal to basically extend JDBCCacheLoaderTest to
> set it up to work with an AS (starting it/stopping it). This would
> give us even more confidence and coverage for the
> ManagedConnectionFactory area. I might not have time to do that
> before I commit my current work for BETA1 but definitely something
> worth bearing in mind.
>
> Another question would be of course, what AS version would be
> integrate against?
>
> There're various projects out there that have done something
> similar, first obviously AS itself and second messaging. What's
> your experience with this? What have we learnt about it? Shall we
> reuse some code for this? We would need a very limited AS version
> actually with JNDI, JDBC Connection Pooling, HS and HS driver.
>
> As you can see, this opens ups whole bunch of questions. Thoughts?
> Opinions? Critics?
>
> Cheers,
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/
> promo/vendor/
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 3 months
Testing JDBCCacheLoader - Embedding AS inside a UT?
by Galder Zamarreno
I've been messing around with JDBCCacheLoader and I have realised that we don't currently have a unit test that can test the JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that can work based on the cache-jdbc.properties and you could start AS manually and test it.
This however is a manual process and when it comes to CC, only standalone JDBCCacheLoader is being tested.
I think it'd be ideal to basically extend JDBCCacheLoaderTest to set it up to work with an AS (starting it/stopping it). This would give us even more confidence and coverage for the ManagedConnectionFactory area. I might not have time to do that before I commit my current work for BETA1 but definitely something worth bearing in mind.
Another question would be of course, what AS version would be integrate against?
There're various projects out there that have done something similar, first obviously AS itself and second messaging. What's your experience with this? What have we learnt about it? Shall we reuse some code for this? We would need a very limited AS version actually with JNDI, JDBC Connection Pooling, HS and HS driver.
As you can see, this opens ups whole bunch of questions. Thoughts? Opinions? Critics?
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
19 years, 3 months