Hi Magnus,
> -----Original Message-----
> From: Magnus Grimsell [mailto:[EMAIL PROTECTED]
> Sent: mardi 1 f�vrier 2005 10:22
> To: Cactus Users List
> Subject: SV: JNDI-lookup of local EJB:s on Oracle appserver
>
> Hi Vincent
>
> As I said switching to Cactus and contributing definitely seems like a
> good alternative. However as I was reading in on your browser intergration
> it seems like our web interface is a little bit more advanced. On the
> other hand its the only integration we got :)
>
> In our framework you can browse your tests and run induvidual tests or
> whole suites. There is also possible to run all test suites for an entire
> package. As far as I could see this is not possible in Cactus(?), is this
> something you planning on adding?
I'm personally not planning in working this area but if people contribute
patches we can apply them. The reason this is not an area of interest to me
is that I consider the web runner a second category runner. It's manual and
I much prefer using either the Ant tasks or the Maven plugin. Both are
completely automated and you can choose which test to run.
>
> Furthermore we have a feature where you can choose to execute only the
> setup
> and the actual test but not the teardown. This is very useful when
> developing
> database code. When a test fails you often want to see what the test data
> looks like. Does this feature exist in Cactus? Do your think it is
> possible
> (or even a good idea) to add it?
Hmm... The way I do it is different. I always set up the database in setUp()
instead of cleaning in teardown(). The reason is that in this manner the
tests are really independent of each other. Also you can never be sure a
test will have left the database in the right state (the test can be
ctrl-c'ed, someone can change the database in between the 2 tests, etc).
I know it's a little bit more effort than for example rollbacking the
database commit (is that what you're doing?) but I think it's more sound.
It's possible to implement easily in Cactus but I'm not sure yet this is a
general enough request. What you can easily write is an extension of say
ServletTestCase:
public myTestCase extends ServletTestCase
{
public void runBareServer() throws Throwable
{
getServerCaller().runBareInit();
// Note: We cannot delegate this piece of code in the
// ServerTestCaseDelegate class as it requires to call
// super.runBare()
if (getServerCaller().getWrappedTest() != null)
{
((TestCase) getServerCaller().getWrappedTest()).runBare();
}
else
{
super.setUp();
try
{
super.runTest();
}
finally
{
if (someFlag)
super.tearDown();
}
}
}
}
What we can do easily is refactor runBareServer() so that you would only
have to write:
public myTestCase extends ServletTestCase
{
public void runBareServer() throws Throwable
{
super.setUp();
try
{
super.runTest();
}
finally
{
if (someFlag)
super.tearDown();
}
}
}
>
> My problem is that I have a very hard time motivating a switch to Cactus
> if some
> of our current features disappears.
Sure, I can understand that. If the other features of Cactus are not more
interesting than what you have I don't think you should switch. Said in
another way, you must have a reason to switch... :-)
Thanks
-Vincent
>
> /Magnus
>
> -----Ursprungligt meddelande-----
> Fr�n: Vincent Massol [mailto:[EMAIL PROTECTED]
> Skickat: den 31 januari 2005 20:50
> Till: 'Cactus Users List'
> �mne: RE: JNDI-lookup of local EJB:s on Oracle appserver
>
>
> Hi Magnus,
>
> > -----Original Message-----
> > From: Magnus Grimsell [mailto:[EMAIL PROTECTED]
> > Sent: lundi 31 janvier 2005 18:12
> > To: [email protected]
> > Subject: JNDI-lookup of local EJB:s on Oracle appserver
> >
> > Hi
> >
> > I am using an inhouse developed framework for running serverside junit
> > tests. The framework is built upon JUnitEE and have worked rather well
> for
> > us in the past. However we are currently porting one of our applications
> > to Oracle Application Server 10g, and here we run into trouble. The
> > problem is that in Oracle, local ejbs cannot be looked up in the global
> > jndi context. You must map the ejb via an ejb-ref in your web.xml (or
> ejb-
> > jar.xml).
> >
> > I was thinking of extending our framework so that the web.xml of the
> > testrunner application would be generated with mappings to all local
> ejbs
> > of the current ear. Is this something that is already implemented in
> > Cactus.
>
> No, this is a piece that is missing in Cactus. We have a <cactifywar> Ant
> task but we're missing a <cactifyear> one that would cactify an existing
> EAR
> and possibly do some fancy things like adding EJB mappings.
>
> >
> > When looking into Cactus I realized that its got some feature that I
> > really want, like Ant/Eclipse integration, so switching to Cactus might
> be
> > a good idea anyhow. It seems like a better idea to put the effort to
> make
> > this work into a good open source project rather then into our existing
> > framework.
>
> I completely agree with this approach :-)
>
> Here's the best way of contributing:
> 1/ You create a JIRA issue for this
> 2/ You use the Cactus-dev mailing list to discuss. You may have questions
> and we can help you understand the cactus code base, etc.
> 3/ Once you have a patch against CVS HEAD ready you attach it to the
> above-mentioned JIRA issue
> 4/ One Cactus committer applies it
>
> Thanks a lot
> -Vincent
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
