You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/05/13 23:44:18 UTC
?
Chris,
>From the commits I've seen from you today, we should have pretty much
all the elements to easily write a <cactifyear> task, right?
I guess the really hard part is to find out what EJB we are calling in
our test case ... because this EJB then needs to be added to web.xml as
an ejb-ref... I guess this may warrant a new <ejbref> tag in the
<cactifyear> task. What do you think?
The other real issue is that we also need the container-specific file to
map the JNDI naming of the EJB to the underlying implementation....
yuck!
Ideally it would mean something like:
<cactifyear srcfile="target/database.ear"
destfile="target/test.ear"
cactuswarname="name of war to use in application.xml">
<jboss3x>
<ejbref jndiname="" containername=""/>
</jboss3x>
</cactifywar>
I don't think it is always possible to autodiscover the name of war to
use. If there is none, then it is the one we create. If there is one,
then that's the one but if there is more than one...
What do you think of all this? Sounds complex, no?
I was going to say it should be easier once we get the EJB redirectors
but I don't think so... We will then need to compile EJB clients which
is also container-dependent (because of stubs. Ah, long live JBoss...).
Thanks
-Vincent
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 13 May 2003 23:05
> To: Vincent Massol
> Subject: Re: [cactus] <cactus> and hooks
>
> Hi Vincent,
>
> the EAR support in <cactus> is now functional AFAICT, except for the
> container support. I'm gonna add some basic tests next.
>
> Vincent Massol wrote:
> > Hi Chris,
> >
> > I need to look more closely at your implementation in order to try
to
> > say intelligent things... ATM, I'm concerned about getting an Ant
API as
> > stable as possible for my book.... ;-) (Thanks for the cactifywar
task)
> >
> > I'm at the EJB chapter and I'm wondering how to demonstrate the use
of
> > cactus for unit testing EJBs. Maybe I could use the cactifywar task
as
> > you suggest for creating a new war from scratch and then write a
test
> > EAR task. Then modifying the <cactus> task to support deployment of
EAR
> > files shouldn't be too hard, right?
> >
> > I'll have a quick look a the code now.
> >
> > Thanks
> > -Vincent
>
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: ?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: 14 May 2003 15:52
> To: cactus-dev@jakarta.apache.org
> Subject: Re: <cactifyear>?
>
> Vincent Massol wrote:
> >>I'd like the user to supply that file, actually. If you use XDoclet,
> >>the file will be autogenerated for you, and you'd rather use the
> >>generated file than specifying something in the build file.
> >
> > Hmmm... Yes, the use of XDoclet is a good idea... On my test project
> > there are only EJBs and no web stuff, thus no webapp that I create
for
> > runtime. So I was a bit loathe to introduce a web.xml and a
container
> > specific mapping file. That said, if I use XDoclet, I don't need to
> > introduce them so that's a good solution... :-)
> >
> > I'll try that today to see if the whole chain works.
>
> Of course, integrating XDoclet is not trivial if you have not been
using
> it anyway.
>
> That said, it would be pretty cool to add an EJB sample application to
> Cactus, using XDoclet to generate the descriptors for the variety of
> app-servers we support (JBoss and Orion, maybe Resin-EE).
>
> Anyone care to donate an example application ? ;-)
I have one on http://sf.net/projects/junitbook, in CVS (I have donated
all source examples for my book to Open Source, under an ASF license).
More specifically, have a look in:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/junitbook/junitbook/ejb/.
It's a Petstore-like EJB applications. ATM I have 2 types of tests for
it:
- mock objects tests, in mockobjects/
- pure junit tests, in integration/
I'm working on it today and tomorrow to add cactus tests to the
integration/ project. I'll try the whole chain, including XDoclet and
see how easy it is.
Thanks
-Vincent
>
> -chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: ?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
>>I'd like the user to supply that file, actually. If you use XDoclet,
>>the file will be autogenerated for you, and you'd rather use the
>>generated file than specifying something in the build file.
>
> Hmmm... Yes, the use of XDoclet is a good idea... On my test project
> there are only EJBs and no web stuff, thus no webapp that I create for
> runtime. So I was a bit loathe to introduce a web.xml and a container
> specific mapping file. That said, if I use XDoclet, I don't need to
> introduce them so that's a good solution... :-)
>
> I'll try that today to see if the whole chain works.
Of course, integrating XDoclet is not trivial if you have not been using
it anyway.
That said, it would be pretty cool to add an EJB sample application to
Cactus, using XDoclet to generate the descriptors for the variety of
app-servers we support (JBoss and Orion, maybe Resin-EE).
Anyone care to donate an example application ? ;-)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: ?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 14 May 2003 00:38
> To: Cactus Developers List
> Subject: Re: <cactifyear>?
>
> Vincent Massol wrote:
> > Chris,
> >
> > From the commits I've seen from you today, we should have pretty
much
> > all the elements to easily write a <cactifyear> task, right?
>
> Depends on the feature set ;-)
>
> > I guess the really hard part is to find out what EJB we are calling
in
> > our test case ... because this EJB then needs to be added to web.xml
as
> > an ejb-ref... I guess this may warrant a new <ejbref> tag in the
> > <cactifyear> task. What do you think?
>
> I'm not sure. Considering people might use something like XDoclet to
> autogenerate the ejb-refs (I would, at least), having a mergewebxml
> attribute would be better IMO. <cactifywar> has that attribute too,
BTW.
>
> > The other real issue is that we also need the container-specific
file to
> > map the JNDI naming of the EJB to the underlying implementation....
> > yuck!
>
> I'd like the user to supply that file, actually. If you use XDoclet,
the
> file will be autogenerated for you, and you'd rather use the generated
> file than specifying something in the build file.
Hmmm... Yes, the use of XDoclet is a good idea... On my test project
there are only EJBs and no web stuff, thus no webapp that I create for
runtime. So I was a bit loathe to introduce a web.xml and a container
specific mapping file. That said, if I use XDoclet, I don't need to
introduce them so that's a good solution... :-)
I'll try that today to see if the whole chain works.
Thanks
-Vincent
>
> > Ideally it would mean something like:
> >
> > <cactifyear srcfile="target/database.ear"
> > destfile="target/test.ear"
> > cactuswarname="name of war to use in application.xml">
> > <jboss3x>
> > <ejbref jndiname="" containername=""/>
> > </jboss3x>
> > </cactifywar>
> >
> > I don't think it is always possible to autodiscover the name of war
to
> > use. If there is none, then it is the one we create. If there is
one,
> > then that's the one but if there is more than one...
>
> Yeah, that's an issue. A 'cactuswarname' attribute looks like a good
> answer.
>
> > What do you think of all this? Sounds complex, no?
>
> Yeah.
>
> I'm not yet sure we need a <cactifyear> task. I think it makes sense
to
> not provide such a task in the next release, and collect some feedback
> first. The Ant <ear> task can be used after the cactification of a war
> to assemble the ear for testing.
>
> I'll need to some more intensive thinking about this stuff after I had
> some coffee tomorrow morning ;-)
>
> > I was going to say it should be easier once we get the EJB
redirectors
> > but I don't think so... We will then need to compile EJB clients
which
> > is also container-dependent (because of stubs. Ah, long live
JBoss...).
> >
> > Thanks
> > -Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: ?
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> Chris,
>
> From the commits I've seen from you today, we should have pretty much
> all the elements to easily write a <cactifyear> task, right?
Depends on the feature set ;-)
> I guess the really hard part is to find out what EJB we are calling in
> our test case ... because this EJB then needs to be added to web.xml as
> an ejb-ref... I guess this may warrant a new <ejbref> tag in the
> <cactifyear> task. What do you think?
I'm not sure. Considering people might use something like XDoclet to
autogenerate the ejb-refs (I would, at least), having a mergewebxml
attribute would be better IMO. <cactifywar> has that attribute too, BTW.
> The other real issue is that we also need the container-specific file to
> map the JNDI naming of the EJB to the underlying implementation....
> yuck!
I'd like the user to supply that file, actually. If you use XDoclet, the
file will be autogenerated for you, and you'd rather use the generated
file than specifying something in the build file.
> Ideally it would mean something like:
>
> <cactifyear srcfile="target/database.ear"
> destfile="target/test.ear"
> cactuswarname="name of war to use in application.xml">
> <jboss3x>
> <ejbref jndiname="" containername=""/>
> </jboss3x>
> </cactifywar>
>
> I don't think it is always possible to autodiscover the name of war to
> use. If there is none, then it is the one we create. If there is one,
> then that's the one but if there is more than one...
Yeah, that's an issue. A 'cactuswarname' attribute looks like a good answer.
> What do you think of all this? Sounds complex, no?
Yeah.
I'm not yet sure we need a <cactifyear> task. I think it makes sense to
not provide such a task in the next release, and collect some feedback
first. The Ant <ear> task can be used after the cactification of a war
to assemble the ear for testing.
I'll need to some more intensive thinking about this stuff after I had
some coffee tomorrow morning ;-)
> I was going to say it should be easier once we get the EJB redirectors
> but I don't think so... We will then need to compile EJB clients which
> is also container-dependent (because of stubs. Ah, long live JBoss...).
>
> Thanks
> -Vincent
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org