RE: Stopping the Server at the Beginning of Tests

2003-03-19 Thread Robertson, Jason
If you start the server manually before running your build process, the
runsservertests will detect this and not try to start the server.
Subsequently, it won't try to stop it when it is done since it wasn't the
one who started it. Does this solve your problem?

Jason

-Original Message-
From: Clint Shank [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2003 2:57 PM
To: [EMAIL PROTECTED]
Subject: Stopping the Server at the Beginning of Tests


Hi,

I'm trying to do this kind of automated testing:

stop a running server instance
get the latest code and build
start the server
run the tests
wait for the next build cycle which is a few hours away

I'm actually using CruiseControl for this and am using the 
runservertests Ant task.  The ultimate goal is to keep the server up 
until the next build cycle for manual testing.  I first tried removing 
the stopTarget of runservertests, but the build fails saying this is 
required.  Any suggestions?  I'm using 1.4b1.




-
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]



WebRequest and header values

2003-02-10 Thread Robertson, Jason
The current WebRequest object only has an addHeader method, and we've come
across a need for a setHeader method and I was wondering if there was any
specific reason something like this isn't there. The difference would be
that in setHeader it would replace any existing values with the new value.

The issue has appeared because some of my team members implemented a test
case that in 29 of the 34 test methods has a common configuration that they
put into the begin() method. Then, in those 5 other tests, they need
different configuration options which they put into beginXXX() methods (this
way they didn't have to write 34 beginXXX() methods). However, the
configuration involves setting header values and since there's no way to
override the existing headers the begin() configuration put there they can't
be replaced in beginXXX().

Also, it was suggested that instead of using a Vector for the header values
it should be an ArrayList (or some other unsynchronized collection) so that
you don't pay the slight but unnecessary synchronization penalty.

I have the guy rewriting WebRequest with these changes, I'll submit it when
he has it ready. I just wanted to toss these comments out before he gets too
far.

Jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Clearing request parameters in test method

2002-12-10 Thread Robertson, Jason
ServletRequest has a removeAttribute() method, is this what you're looking
for?

   request.removeAttribute(lang);

Jason

-Original Message-
From: James Childers [Clearing request parameters in test method,
James Childers

 
RE: Clearing request parameters in test method,
Robertson, Jason

RE: Clearing request parameters in test method,
James Childers

RE: Clearing request parameters in test method,
Robertson, Jason

 












 
--  
Chronological
--
  

 
  

 
  --  
  Thread 
  --  
  





  
  
  
  
  B73009094E87D511B7D700B0D0D1066301621F5E@ATLEXU01">
  Reply via email to
  
  










 




<!--
google_ad_client = "pub-7266757337600734";
google_alternate_ad_url = "http://www.mail-archive.com/blank.png";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_channel = "3243237953";
google_color_border = "CE9689";
google_color_bg = ["FF","ECE5DF"];
google_color_link = "006792";
google_color_url = "006792";
google_color_text = "00";
//-->







Clearing request parameters in test method
James Childers

 

Clearing request parameters in test method
James Childers


RE: Clearing request parameters in test method
Robertson, Jason


RE: Clearing request parameters in test method
James Childers


RE: Clearing request parameters in test method
Robertson, Jason

 



 






  
  





Reply via email to



  
  





 
 







RE: Basic Authentication and special characters

2002-12-04 Thread Robertson, Jason
The easiest thing to do would be to extend the BasicAuthentication class and
override the validateName method to just return without checking anything
(or you could copy the existing code and just remove the @ from the
illegalChars string). Then, just use your new class in your test case.

I don't know of any way to escape it that would make it work, and I'm pretty
sure most of the illegal characters are defined as illegal to avoid
potential control characters in networking hardware. If in your particular
environment the @ doesn't hold a special place then you can ignore the spec.


Jason

-Original Message-
From: Randy Shoup [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 5:03 PM
To: [EMAIL PROTECTED]
Subject: Basic Authentication and special characters


I am not sure whether this is proper forum for this question, but ...

I am trying to use Cactus 1.4.1 and JBoss 3.0.4, with Basic 
Authentication.  In the back, JBoss authenticates the login to an LDAP 
server where user names are like email addresses ([EMAIL PROTECTED]).

When I try to authenticate with such a user name, Cactus complains that 
'@' is a special character (stack trace below).

According to the Cactus code, and the HTTP 1.0 spec, this is perfectly 
correct.  I tried escaping the '@' in various ways -- '%40' and '#64;' 
-- but neither worked.

My question is:  How do other people use Basic Authentication and 
so-called special characters like the extremely common '@'?  Am I just 
out of luck?  Is there a way to escape the '@' so that I can in fact 
authenticate?


stack trace:
 [junit] Testcase: testBasicAuthentication took 0.078 sec
 [junit] Caused an ERROR
 [junit] Given theName contains illegal characters.
 [junit] java.lang.IllegalArgumentException: Given theName contains 
illegal characters.
 [junit] at 
org.apache.cactus.client.authentication.BasicAuthentication.validateName(Bas
icAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k)
:153)
 [junit] at 
org.apache.cactus.client.authentication.AbstractAuthentication.dispatch6_set
Name(AbstractAuthentication.java;org/apache/cactus/util/log/LogAs
pect.aj(1k):108)
 [junit] at 
org.apache.cactus.client.authentication.AbstractAuthentication.around6_setNa
me(AbstractAuthentication.java;org/apache/cactus/util/log/LogAspe
ct.aj(1k):1156)
 [junit] at 
org.apache.cactus.client.authentication.AbstractAuthentication.setName(Abstr
actAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k
):106)
 [junit] at 
org.apache.cactus.client.authentication.AbstractAuthentication.init(Abstra
ctAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k)
:97)
 [junit] at 
org.apache.cactus.client.authentication.BasicAuthentication.init(BasicAuth
entication.java;org/apache/cactus/util/log/LogAspect.aj(1k):113)

Thanks,
-- Randy
_
Randy Shoup
Tumbleweed Communications Corporation   [EMAIL PROTECTED]




--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: [Musing] Offline mode

2002-11-20 Thread Robertson, Jason
Sorry to take so long to respond, but I'm not clear as to the full benefits
of doing this. If I'm creating a servlet, and that servlet does nothing
involving certain container resources (i.e., connection pools, EJBs, etc.),
then I could see how a mock container could work. But how often does this
happen?

And I don't see at all how it could test JSPs (would the mock container
compile them into servlets?), or EJBs. 

The far majority of my cactus testing is testing EJBs, and will soon be
testing Struts action classes which will all use EJBs to get their data. Am
I just not a potential offline mode user, and that's why I can't see it?
Am I missing the big picture?

Jason 

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 02, 2002 12:00 PM
To: 'Cactus Users List'
Cc: [EMAIL PROTECTED]
Subject: [Musing] Offline mode


Hi Cactusers,

Today I haven been thinking about Cactus and Mock Objects and more
specifically when to choose one over another, etc. The choice is not
always easy. In the past, I had thought about implementing an offline
mode in Cactus, i.e. the ability to run the same cactus test without a
container. Of course, it won't be integration unit testing any more but
the rationale is the following:

* use the offline mode when coding in your favorite IDE. Run the tests
very often.
* use the online mode to perform integration unit testing with your
target containers.
* The benefits over using an existing mock object library for
Servlet/JSP/Filter/EJBs API is evident: tests written using the Cactus
API can run as is in in-container mode.

Of course, not all tests should be run in both modes but a lot of them
could.

At that time I had dismissed the idea because I did not see how I could
do it and I did not see the real interest of doing so. It seems much
clearer now... :-)

Here are some ideas:

* The mode is specified by passing a JVM system parameter
(-Dcactus.offline=true)
* In offline mode, Cactus creates dummy (mock) Servlet implicit objects,
and filling them with the information it has (mostly from WebRequest).
* In addition, the wrappers need to be extended (or added) to offer
methods to set the behaviours of the mocks. For example:
HttpServletRequestWrapper.setForwardResult(HttpServletResponse response,
OutputStream mockStream)
* In online mode, the setForwardResult() and such can be ignored.
However, if we want to refine this, we can also have an additional
HttpServletRequestWrapper.setForwardResult(HttpServletResponse response,
OutputStream mockStream, boolean useInOnlineMode) API that tells Cactus
to use this even in online mode. This can be handy when the JSP is not
yet written and you still wish to perform integration unit tests.
* In offline mode, there is no HTTP connection to the server side and
beginXXX(), testXXX() and endXXX() are all run on the client side.

What do you think?

-Vincent


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: [Musing] Offline mode

2002-11-20 Thread Robertson, Jason
I understand all the points you make as far as in- vs. out-of-container, and
I'm with ya on that part - Cactus tests are slow! :)

But, what I don't see is, to pick one specific example, is how would I test
my EJBs? Or even how would I test my struts action classes? In both of these
cases I have to validate data that was retrieved from the database, external
systems, etc. And in my probably narrow view of the world, it seems like any
dynamic web-app would do something similar, and that most tests validate
that data was retrieved successfully and put into the request/session/etc.
appropriately. If I don't design mock objects to simulate the retrieval of
the data (which it doesn't sound like I would do in your description) how
does this happen? What am I validating?

Again, maybe I'm just not the right customer, because you speak of finding
errors not related to integration and I'm not seeing a clear example of what
kind of errors you'd be finding.

Jason

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 3:16 PM
To: 'Cactus Users List'
Subject: RE: [Musing] Offline mode


Hi Jason,

The idea is simply productivity boost. Running a Cactus test takes time
whereas a mock one is fast. You can run around 400 mock objects tests in
a second whereas Cactus tests will take at least 10-20 seconds overall
(or more. That's best time). Cactus tests yields more value as they
really verify that it works. But MO tests are enough to find errors not
related to integration. Both are good and complementary.

The idea is to have the best of both worlds by writing only one test (if
possible, not sure yet how well this would be). That is you would run
the tests quickly from your IDE as you type and from time to time you
would run with online mode on to verify it does really work.

In practice I am using both MO and Cactus on my projects but I have to
write against 2 frameworks.

Does it make sense?

Thanks
-Vincent

 -Original Message-
 From: Robertson, Jason [mailto:[EMAIL PROTECTED]]
 Sent: 20 November 2002 18:35
 To: 'Cactus Users List'
 Subject: RE: [Musing] Offline mode
 
 Sorry to take so long to respond, but I'm not clear as to the full
 benefits
 of doing this. If I'm creating a servlet, and that servlet does
nothing
 involving certain container resources (i.e., connection pools, EJBs,
 etc.),
 then I could see how a mock container could work. But how often does
 this
 happen?
 
 And I don't see at all how it could test JSPs (would the mock
container
 compile them into servlets?), or EJBs.
 
 The far majority of my cactus testing is testing EJBs, and will soon
be
 testing Struts action classes which will all use EJBs to get their
data.
 Am
 I just not a potential offline mode user, and that's why I can't see
it?
 Am I missing the big picture?
 
 Jason
 
 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, November 02, 2002 12:00 PM
 To: 'Cactus Users List'
 Cc: [EMAIL PROTECTED]
 Subject: [Musing] Offline mode
 
 
 Hi Cactusers,
 
 Today I haven been thinking about Cactus and Mock Objects and more
 specifically when to choose one over another, etc. The choice is not
 always easy. In the past, I had thought about implementing an offline
 mode in Cactus, i.e. the ability to run the same cactus test without a
 container. Of course, it won't be integration unit testing any more
but
 the rationale is the following:
 
 * use the offline mode when coding in your favorite IDE. Run the tests
 very often.
 * use the online mode to perform integration unit testing with your
 target containers.
 * The benefits over using an existing mock object library for
 Servlet/JSP/Filter/EJBs API is evident: tests written using the Cactus
 API can run as is in in-container mode.
 
 Of course, not all tests should be run in both modes but a lot of them
 could.
 
 At that time I had dismissed the idea because I did not see how I
could
 do it and I did not see the real interest of doing so. It seems much
 clearer now... :-)
 
 Here are some ideas:
 
 * The mode is specified by passing a JVM system parameter
 (-Dcactus.offline=true)
 * In offline mode, Cactus creates dummy (mock) Servlet implicit
objects,
 and filling them with the information it has (mostly from WebRequest).
 * In addition, the wrappers need to be extended (or added) to offer
 methods to set the behaviours of the mocks. For example:
 HttpServletRequestWrapper.setForwardResult(HttpServletResponse
response,
 OutputStream mockStream)
 * In online mode, the setForwardResult() and such can be ignored.
 However, if we want to refine this, we can also have an additional
 HttpServletRequestWrapper.setForwardResult(HttpServletResponse
response,
 OutputStream mockStream, boolean useInOnlineMode) API that tells
Cactus
 to use this even in online mode. This can be handy when the JSP is not
 yet written and you still wish to perform integration unit tests.
 * In offline mode

RE: Transactions and EJB testing

2002-11-07 Thread Robertson, Jason
Cactus does not configure a transaction for you. If you haven't started a
transaction manually, then each method call on your CMP beans execute in its
own transaction. 

To manually start a transaction do something like this:

public class MyTest extends ServletTestCase
{
   private UserTransaction _ut = null;

   ...

   public void setUp() throws Exception
   {
  Context ctx = new InitialContext();
  _ut = (UserTransaction)
ctx.lookup(javax.transaction.UserTransaction);
  _ut.begin();
   }

   public void tearDown() throws Exception
   {
  _ut.commit();
   }

   ...
}

This will cause each test case to run in its own transaction. If you use any
CMR fields in your beans you must do this, as you have to access CMRs in the
context of a transaction.

Jason

-Original Message-
From: Ajay Gullapalli [mailto:Ajay_Gullapalli;compaid.com]
Sent: Thursday, November 07, 2002 8:42 AM
To: [EMAIL PROTECTED]
Subject: Transactions and EJB testing


Hi,

I was wondering if someone could post how transactions work in Cactus
when testing EJBs. I have a test case that has several testXXX in it
that test some container managed beans. When I run the test case, all
the individual tests seem to run under one transaction. 

When does Cactus start a transaction? When does it commit or abort this
transaction. Does it start and run under one single transaction for the
entire test case? 

 

Thank you.

Ajay


--
To unsubscribe, e-mail:   mailto:cactus-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org




RE: FormAuthentication

2002-10-29 Thread Robertson, Jason
Here's my SimpleFormLogin project. This is project source, so look into
the build.xml file and adjust the !-- Jar files -- section to fit your
setup.

As far as I know, form authentication over https shouldn't be a problem as
it's really not much different than any other form submission. As long as
the server is setup right and the context URL has https I'd assume it would
all work, but I've never tested it.

Jason

-Original Message-
From: Koegel, Michael [mailto:Michael.Koegel;partner.commerzbank.com]
Sent: Tuesday, October 29, 2002 3:23 AM
To: Cactus Users List
Subject: AW: FormAuthentication


Hi Jason,

I would also be interested in this FormAuthentication Example.
I didn't follow the discussion closely the last couple weeks is it also
possible to test form based login with https?

Regards,
 Michael

-Ursprüngliche Nachricht-
Von: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Gesendet am: Montag, 28. Oktober 2002 21:35
An: 'Cactus Users List'
Betreff: RE: FormAuthentication

I think this is a good solution. Separate WAR files is the only way I know
of to use different authentication techniques.

Plus, the side effect of making a clearer separation between the example and
the unit tests I agree is a good thing.

Do you want my test app? It's just a very simple web app with pages to do
the form authentication as well, so you have a 2nd avenue to test
configuration if you're having troubles with cactus. Its the one I used to
test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE
server. Let me know and I'll try to bundle it up.

Jason

-Original Message-
From: Vincent Massol [mailto:vmassol;octo.com]
Sent: Saturday, October 26, 2002 2:12 PM
To: 'Cactus Users List'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: FormAuthentication


Hi Jason/Pranab,

Thank you both for the good analysis! There are indeed 2 bugs you have
found:
- one with the FormAuthentication using only the default redirector
- one with the HttpClient fetching the test result using only the
default redirector

I have now fixed (hopefully) both bugs in CVS. You can check the CVS
commit emails if you wish to see what I have modified. I would be happy
to know if you agree with my changes... :-)

However, there is still something missing which I was not able to code:
it is a test for the FormAuthentication class. The problem is that
apparently you can only have one method of authentication in a given
webapp and ATM the sample webapp is using Basic authentication... Thus
we cannot easily add one more test for testing Jason's
FormaAuthentication code ... I was pondering about what route to take
for that. Any idea?

One solution would be to have several webapp of course and more
specifically to have the following directory structure in CVS:

jakarta-cactus
  |_ [...]
  |_ servlet-sample
  |_ servlet-unit

servlet-sample: contains only the org.apache.cactus.sample.* packages.
It is the sample application.

servlet-unit: contains only the org.apache.cactus.unit.* packages. The
goal of this application is to offer a full regression test suite for
Cactus. It is not a sample application per see. The idea would then be
to have a build file that produces 3 wars: one test.war (no
authentication tests), one test-basic.war (basic authentication tests)
and one test-form.war (form-based authentication tests). 

Note: Some persons have told me it was difficult to understand the
differences between the unit/ and sample/ directories in the
servlet-sample project. That would solve the problem.

What do you think?

Thanks
-Vincent

 -Original Message-
 From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
 Sent: 26 October 2002 15:40
 To: 'Cactus Users List'
 Subject: RE: FormAuthentication
 
 Time for Vincent to chime in!
 
 Vincent, Pranab's comments below show that there's a problem in the
 reconfiguring of the Redirector in that you can configure it in two
 places:
 in WebRequest and in cactus.properties, but only the latter is
persistent
 between callRunTest and callGetResult. In callGetResult, a new
WebRequest
 is
 created and gets initialized with the cactus.properties value.
 
 Should calling setRedirectorName in the WebRequest propagate that
setting
 to
 the configuration? Or should that method be removed from WebRequest
and
 added to the WebConfiguration interface and then you'd say:
 
 aWebRequestObject.getConfiguration().setRedirectorName(...);
 
 Or should the same WebRequest object be shared between callRunTest and
 callGetResult? I would think this would make the most sense, I don't
know
 if
 I like accessing static properties through a transient object.
 
 If we take the reuse-the-WebRequest approach, the signature for
 callGetResult would change to remove the AbstractAuthen. Thetication
and add
 the
 WebRequest (the authentication object would already be configured in
the
 WebRequest) and you'd have to add something like a setParameter that
 would
 overwrite any existing

RE: FormAuthentication

2002-10-28 Thread Robertson, Jason
I think this is a good solution. Separate WAR files is the only way I know
of to use different authentication techniques.

Plus, the side effect of making a clearer separation between the example and
the unit tests I agree is a good thing.

Do you want my test app? It's just a very simple web app with pages to do
the form authentication as well, so you have a 2nd avenue to test
configuration if you're having troubles with cactus. Its the one I used to
test Tomcat and WLS. I'm sure it can be easily adapted to any other J2EE
server. Let me know and I'll try to bundle it up.

Jason

-Original Message-
From: Vincent Massol [mailto:vmassol;octo.com]
Sent: Saturday, October 26, 2002 2:12 PM
To: 'Cactus Users List'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: FormAuthentication


Hi Jason/Pranab,

Thank you both for the good analysis! There are indeed 2 bugs you have
found:
- one with the FormAuthentication using only the default redirector
- one with the HttpClient fetching the test result using only the
default redirector

I have now fixed (hopefully) both bugs in CVS. You can check the CVS
commit emails if you wish to see what I have modified. I would be happy
to know if you agree with my changes... :-)

However, there is still something missing which I was not able to code:
it is a test for the FormAuthentication class. The problem is that
apparently you can only have one method of authentication in a given
webapp and ATM the sample webapp is using Basic authentication... Thus
we cannot easily add one more test for testing Jason's
FormaAuthentication code ... I was pondering about what route to take
for that. Any idea?

One solution would be to have several webapp of course and more
specifically to have the following directory structure in CVS:

jakarta-cactus
  |_ [...]
  |_ servlet-sample
  |_ servlet-unit

servlet-sample: contains only the org.apache.cactus.sample.* packages.
It is the sample application.

servlet-unit: contains only the org.apache.cactus.unit.* packages. The
goal of this application is to offer a full regression test suite for
Cactus. It is not a sample application per see. The idea would then be
to have a build file that produces 3 wars: one test.war (no
authentication tests), one test-basic.war (basic authentication tests)
and one test-form.war (form-based authentication tests). 

Note: Some persons have told me it was difficult to understand the
differences between the unit/ and sample/ directories in the
servlet-sample project. That would solve the problem.

What do you think?

Thanks
-Vincent

 -Original Message-
 From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
 Sent: 26 October 2002 15:40
 To: 'Cactus Users List'
 Subject: RE: FormAuthentication
 
 Time for Vincent to chime in!
 
 Vincent, Pranab's comments below show that there's a problem in the
 reconfiguring of the Redirector in that you can configure it in two
 places:
 in WebRequest and in cactus.properties, but only the latter is
persistent
 between callRunTest and callGetResult. In callGetResult, a new
WebRequest
 is
 created and gets initialized with the cactus.properties value.
 
 Should calling setRedirectorName in the WebRequest propagate that
setting
 to
 the configuration? Or should that method be removed from WebRequest
and
 added to the WebConfiguration interface and then you'd say:
 
 aWebRequestObject.getConfiguration().setRedirectorName(...);
 
 Or should the same WebRequest object be shared between callRunTest and
 callGetResult? I would think this would make the most sense, I don't
know
 if
 I like accessing static properties through a transient object.
 
 If we take the reuse-the-WebRequest approach, the signature for
 callGetResult would change to remove the AbstractAuthen. Thetication
and add
 the
 WebRequest (the authentication object would already be configured in
the
 WebRequest) and you'd have to add something like a setParameter that
 would
 overwrite any existing parameter and allow you to reconfigure the
service
 name parameter.
 
 None of these changes are that difficult, but does any one look better
or
 worse in the big picture?
 
 Jason

[snip]



--
To unsubscribe, e-mail:
mailto:cactus-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:cactus-user-help;jakarta.apache.org

--
To unsubscribe, e-mail:   mailto:cactus-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:cactus-user-help;jakarta.apache.org




RE: FormAuthentication

2002-10-26 Thread Robertson, Jason
Time for Vincent to chime in!

Vincent, Pranab's comments below show that there's a problem in the
reconfiguring of the Redirector in that you can configure it in two places:
in WebRequest and in cactus.properties, but only the latter is persistent
between callRunTest and callGetResult. In callGetResult, a new WebRequest is
created and gets initialized with the cactus.properties value.

Should calling setRedirectorName in the WebRequest propagate that setting to
the configuration? Or should that method be removed from WebRequest and
added to the WebConfiguration interface and then you'd say:

aWebRequestObject.getConfiguration().setRedirectorName(...);

Or should the same WebRequest object be shared between callRunTest and
callGetResult? I would think this would make the most sense, I don't know if
I like accessing static properties through a transient object.

If we take the reuse-the-WebRequest approach, the signature for
callGetResult would change to remove the AbstractAuthentication and add the
WebRequest (the authentication object would already be configured in the
WebRequest) and you'd have to add something like a setParameter that would
overwrite any existing parameter and allow you to reconfigure the service
name parameter.

None of these changes are that difficult, but does any one look better or
worse in the big picture?

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:17 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
   I found the Redirector change happening at function
(AbstractHttpClient.java)
private WebTestResult callGetResult(
AbstractAuthentication theAuthentication) throws Throwable
{
WebRequest resultsRequest = new WebRequest(this.configuration); ---
here
  // Add authentication details
if (theAuthentication != null)
{
resultsRequest.setAuthentication(theAuthentication);
}

// Open the second connection to get the test results
 ConnectionHelper helper = ConnectionHelperFactory.getConnectionHelper(
getRedirectorURL(resultsRequest), this.configuration);

The ServletConfiguration does not contain the redirector set in WebRequest
object
instead it loads it default redirector from the cactus.properties.
   this.configuration is coming from new Configuration being initialized in 
ServletTestCase class 
 * see AbstractTestCase#createConfiguration()
 */
protected Configuration createConfiguration()
{
return new ServletConfiguration();
}
When the user sets the redirector in Webrequest that never gets updated in
the configuration.
So when getRedirectorURL() gets called in AbstractHttpClient.java which is
actually implemented 
in ServletHttpClient.java as 
protected String getRedirectorURL(WebRequest theRequest)
{
String url;

// Check if user has overriden the servlet redirector

if (theRequest.getRedirectorName() != null)
{
url = this.configuration.getContextURL() + /
+ theRequest.getRedirectorName();
}
else
{
url = this.configuration.getRedirectorURL();
}

return url;
}

The theRequest parameter being a newly intialized WebRequest object does not
have the 
redirector set from the old request object used for Form Authentication.
Hence callResult function never goes to the Secured Servlet Redirector used
earlier to run the test.
I am not too sure if the unsecured redirector will be able to return the
results.
Maybe cactus guru's will know the answer to this design.

Pranab




-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Sent: Friday, October 25, 2002 6:20 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Yes, you're correct with the need to get the context URL as well.

As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
 Sorry for the typo Error in my last post.it should be
 getConfiguration().getContextURL()+/+theRequest.getRedirectorName();

I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
 is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error  404 instead of the regulars output
from the servlet.

Pranab

I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL(localhost:8080, /, /secure/idsconf,
null, null); --
theRequest.addCookie( test, test

RE: FormAuthentication

2002-10-25 Thread Robertson, Jason
/IDSCONF-REALM/security-domain
/container-configuration
!-- Entity beans are secure by default --
container-configuration
container-nameStandard BMP EntityBean/container-name

security-domainjava:/jaas/IDSCONF-REALM/security-domain
/container-configuration
!-- A stateless session config that is not secured --
container-configuration extends=Standard Stateless SessionBean
container-nameUnsecure Stateless
SessionBean/container-name
security-domain/
/container-configuration
/container-configurations
/jboss
--

# A sample users.properties file for use with the UsersRolesLoginModule
# user=password
admin=admin
pkdhar=pkdhar
bob=bob
--
# A sample roles.properties file for use with the UsersRolesLoginModule
# user=role1,role2...
admin=idsconf_admin,idsconf_user
pkdhar=idsconf_user
bob=idsconf_user

-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Sent: Friday, October 25, 2002 11:21 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Buried in the stack trace is Failed to authenticate the principal. If you
try to log into the website normally using admin/admin does it work? 

What server are you using? We have test cases that work with Tomcat and
WebLogic.

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication


Hi,
   I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
  I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
  My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL(localhost:8080, /, /secure/idsconf,
null, null);
theRequest.addCookie( test, test );
theRequest.setRedirectorName(ServletRedirectorSecure);
theRequest.setAuthentication(new FormAuthentication(admin,
admin));
}
public void testBasicAuthentication() {
assertEquals(admin,
request.getUserPrincipal().getName());
assertEquals(admin, request.getRemoteUser());
assertTrue(User not in 'admin' role,
request.isUserInRole(admin));
}
I am getting this error when I run the test in Log4J DEBUG mode

-
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper  -
getCookieString([simulation URL = [null], automatic session = [true],
cookies = [], headers = [], GET parameters = [], POST parameters = []],
[http://localhost:8080/ServletRedirector]) 
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper  - getCookieString
= [null] 
18:00:13,891 [main] DEBUG ent.HttpClientConnectionHelper  - connect =
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector] 
18:00:13,901 [main] DEBUG util.HttpURLConnection  -
getHeaderFieldKey([1]) 
18:00:13,901 [main] DEBUG util.HttpURLConnection  -
getHeaderFieldKey = [Connection] 
18:00:13,901 [main] DEBUG util.HttpURLConnection  -
getHeaderFieldKey([2]) 
18:00:13,901 [main] DEBUG util.HttpURLConnection  -
getHeaderFieldKey = [null] 
18:00:13,901 [main] DEBUG hentication.FormAuthentication  - Using security
check URL [http://localhost:8080/j_security_check] 
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory  -
getConnectionHelper([http://localhost:8080/j_security_check],
[org.apache.cactus.util.ServletConfiguration@1dff3a2]) 
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory  -
getConnectionHelper =
[org.apache.cactus.client.HttpClientConnectionHelper@1d9fd51] 
18:00:13,901 [main] DEBUG cactus.WebRequest   -
addCookie([null], [null]) 
18:00:13,901 [main] DEBUG cactus.WebRequest   -
addCookie([localhost], [null], [null]) 
18:00:13,901 [main] DEBUG servlet.TestLoginServlet- Exception in
test 
18:00:13,901 [main] DEBUG util.ChainedRuntimeException-
printStackTrace([org.apache.log4j.spi.VectorWriter@121f1d]) 
18:00:13,971 [main] DEBUG util.ChainedRuntimeException- printStackTrace

org.apache.cactus.util.ChainedRuntimeException: Failed to authenticate the
principal
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate(Form
Authentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):288

RE: FormAuthentication

2002-10-25 Thread Robertson, Jason
I think you've found a problem! 

I was unaware that you could change the redirector name in the WebRequest so
I didn't deal with that scenario. If you can, change the authenticate
function to be this (add the WebRequest argument, and then use it to get the
redirector name):

public void authenticate(WebRequest theRequest)
{
//Note: This method needs refactoring. It is too complex.

try
{
// Create a helper that will connect to a restricted resource.
String resource = theRequest.getRedirectorName();
...

and pass theRequest to the authenticate function in configuration method:

if (this.sessionId == null)
{
   authenticate(theRequest);
}

and give it a try.

If that fixes things I'll work up a proper patch and submit it.

Good catch!

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 1:32 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
  The servlet mapping in WEB-INF/web.xml is
  !-- Cactus Servlet Redirectors --
  servlet
servlet-nameServletRedirector/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
  servlet
servlet-nameServletRedirectorSecure/servlet-name
 
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

  /servlet
two aliases for the same Redirector servlet and the security constraint is
on the 
ServletRedirectorSecure alias.
security-constraint
web-resource-collection
web-resource-nameSecurityRestriction/web-resource-name
descriptionProtect the Cactus
redirectorservlet./description
url-pattern/ServletRedirectorSecure/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
descriptionAuthorized Users Group/description
role-nameidsconf_admin/role-name
role-nameidsconf_user/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
cactus.properties contains :-
cactus.contextURL = http://localhost:8080   only

and the testcase sets the redirector by calling :-
theRequest.setRedirectorName(ServletRedirectorSecure);


As long as I set the redirector in the test case it will override the
default redirector.
Then the question is why the default redirector is being used after the
override.
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector] 

I think I found the problem in cactus code.
 I am setting redirector in the class WebRequest.redirectorName whereas the 
FormAuthentication is getting the redirector name from the WebConfiguration
interface 
implemented by the ServletConfiguration class which reads the redirector
name from
cactus.properties and used the default ServletRedirector if not specified.
  The WebRequest wrapper should rather modify the stored configuration
object to
the new Redirector or the Servlet Configuration should check the request
object to get
the modified redirector. 
   /**
 * @param theConfiguration the Cactus configuration
*/
public WebRequest(WebConfiguration theConfiguration)
{
this.configuration = theConfiguration;
}
   /**
 * Override the redirector Name defined in
codecactus.properties/code.
 * This is useful to define a per test case Name (for example, if some
 * test case need to have authentication turned on and not other tests,
 * etc).
 *
 * @param theRedirectorName the new redirector Name to use
 */
public void setRedirectorName(String theRedirectorName)
{
this.redirectorName = theRedirectorName;
}

Tell me what you think.

Pranab

-Original Message-
From: Robertson, Jason [mailto:Jason.Robertson;acs-inc.com]
Sent: Friday, October 25, 2002 12:44 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the Secure from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add Secure to you cactus.properties file, but I'd say it would be
better to remove it.)

Let me know if that changes anything.

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Hi Jason,
 Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway

RE: FormAuthentication

2002-10-25 Thread Robertson, Jason
Yes, you're correct with the need to get the context URL as well.

As for the rest of it, I'm not sure. I'll try looking at the log again, but
there's a lot of information there!

Jason

-Original Message-
From: Dhar, Pranab [mailto:Pranab.Dhar;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 3:43 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication


Jason,
 Sorry for the typo Error in my last post.it should be
 getConfiguration().getContextURL()+/+theRequest.getRedirectorName();

I just compiled the code and tested it. I am getting past the authentication
now
but getting stuck somewhere after that. Somewhere down the line the
ServletRedirectorSecure
 is getting switched back to ServletRedirector even though I am setting the
URL to a
secured resource.I am getting a Error  404 instead of the regulars output
from the servlet.

Pranab

I added the following in the test code
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL(localhost:8080, /, /secure/idsconf,
null, null); --
theRequest.addCookie( test, test );
theRequest.setRedirectorName(ServletRedirectorSecure);
theRequest.setAuthentication(   new
FormAuthentication(admin, admin));
}
public void testBasicAuthentication() {
try {
idsconfServlet servlet = new
idsconfServlet();--
servlet.init(this.config);--

servlet.doGet(this.request,this.response);--
assertEquals(admin,
request.getUserPrincipal().getName());
assertEquals(admin,
request.getRemoteUser());
assertTrue(User not in 'admin' role,
request.isUserInRole(admin));
} catch (ServletException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
}


Debug LOG

15:25:40,563 [main] DEBUG util.UrlUtil-
getPath([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=te
stBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost
%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.
servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=ht
tpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getPath =
[/ServletRedirectorSecure] 
15:25:40,563 [main] DEBUG util.UrlUtil-
getQuery([http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=t
estBasicAuthenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhos
t%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids
.servlet.TestLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=h
ttpCactus_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG util.UrlUtil- getQuery =
[Cactus_TestMethod=testBasicAuthenticationCactus_URL_ContextPath=%2FCactus
_URL_Server=localhost%3A8080Cactus_URL_ServletPath=%2Fsecure%2FidsconfCact
us_TestClass=com.ids.servlet.TestLoginServletCactus_AutomaticSession=trueC
actus_URL_Protocol=httpCactus_Service=CALL_TEST] 
15:25:40,563 [main] DEBUG ent.HttpClientConnectionHelper  -
getCookieString([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate
= [null]][name = [JSESSIONID], value = [B9D9DDE0DD962B211E36D92FBE854D67],
domain = [localhost], path = [null], isSecure = [false], comment = [null],
expiryDate = [null]]], headers = [], GET parameters = [[[Cactus_TestMethod]
= [[testBasicAuthentication]]][[Cactus_URL_ContextPath] =
[[/]]][[Cactus_URL_Server] = [[localhost:8080]]][[Cactus_URL_ServletPath] =
[[/secure/idsconf]]][[Cactus_TestClass] =
[[com.ids.servlet.TestLoginServlet]]][[Cactus_AutomaticSession] =
[[true]]][[Cactus_URL_Protocol] = [[http]]][[Cactus_Service] =
[[CALL_TEST, POST parameters = []],
[http://localhost:8080/ServletRedirectorSecure?Cactus_TestMethod=testBasicAu
thenticationCactus_URL_ContextPath=%2FCactus_URL_Server=localhost%3A8080C
actus_URL_ServletPath=%2Fsecure%2FidsconfCactus_TestClass=com.ids.servlet.T
estLoginServletCactus_AutomaticSession=trueCactus_URL_Protocol=httpCactus
_Service=CALL_TEST]) 
15:25:40,563 [main] DEBUG cactus.Cookie   -
getCookiePath([simulation URL = [protocol = [http], host name =
[localhost], port = [8080], context path = [/], servlet path =
[/secure/idsconf], path info = [null], query string = [null]], automatic
session = [true], cookies = [[name = [test], value = [test], domain =
[localhost], path = [null], isSecure = [false], comment = [null], expiryDate

RE: Error accessing local interfaces from JBOSS

2002-10-11 Thread Robertson, Jason

This is a deployment descriptor problem, not a Cactus problem. Try doing a
lookup with whatever you declared the jndi name to be in the
jboss-ejb-jar.xml, and forget about the ejb-local-ref (I assume this is
where your ejb-ref-name is located) just to see if you can get it to work. 

Also, as a side note, if you're using local interfaces you don't need the
PortableRemoteObject.narrow() call, that's only for remote interfaces (but
it doesn't hurt to use it).

Jason

-Original Message-
From: Binoy Patrick [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 13, 2001 2:28 AM
To: [EMAIL PROTECTED]
Subject: Error accessing local interfaces from JBOSS


Hi all,
  I'm having problems with accesing the session bean local interface from my
cactus testcase.
i'm accesing the interface the following way:

Context ctx = new InitialContext();
  ConverterHome home = (ConverterHome)
  PortableRemoteObject.narrow(ctx.lookup(java:ejb/Converter),
  ConverterHome.class);

and i get the following message:(in the web.xml i specified
ejb-ref-nameejb/Converter/ejb-ref-name)


Name java:ejb is not bound in this Context 

javax.naming.NameNotFoundException: Name java:ejb is not bound in this
Context
at org.apache.naming.NamingContext.lookup(NamingContext.java:811)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at ConverterTest.testConvert(ConverterTest.java:40)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.cactus.AbstractTestCase.runServerTest(AbstractTestCase.java:332)
at
org.apache.cactus.AbstractTestCase.runBareServerTest(AbstractTestCase.java:2
35)
at
org.apache.cactus.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.
java:149)
at
org.apache.cactus.server.AbstractWebTestController.dispatch87_handleRequest(
AbstractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
25)
at
org.apache.cactus.server.AbstractWebTestController.around87_handleRequest(Ab
stractWebTestController.java;org/apache/cactus/util/log/LogAspect.aj(1k):114
9)
at
org.apache.cactus.server.AbstractWebTestController.handleRequest(AbstractWeb
TestController.java;org/apache/cactus/util/log/LogAspect.aj(1k):101)
at
org.apache.cactus.server.ServletTestRedirector.dispatch113_doPost(ServletTes
tRedirector.java;org/apache/cactus/util/log/LogAspect.aj(1k):123)
at
org.apache.cactus.server.ServletTestRedirector.around113_doPost(ServletTestR
edirector.java;org/apache/cactus/util/log/LogAspect.aj(1k):1149)
at
org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedirector.
java;org/apache/cactus/util/log/LogAspect.aj(1k):109)
at
org.apache.cactus.server.ServletTestRedirector.dispatch112_doGet(ServletTest
Redirector.java;org/apache/cactus/util/log/LogAspect.aj(1k):96)
at
org.apache.cactus.server.ServletTestRedirector.around112_doGet(ServletTestRe
director.java;org/apache/cactus/util/log/LogAspect.aj(1k):1149)
at
org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedirector.j
ava;org/apache/cactus/util/log/LogAspect.aj(1k):92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at

RE: testing ejb's with cactus

2002-09-26 Thread Robertson, Jason

Have you looked at the EJB Howto guide on the cactus site?

http://jakarta.apache.org/cactus/howto_ejb.html

You can test EJBs over their remote interface just fine using JUnit by
itself. But if, for example, you want to test Local Interfaces then you have
to run you test on the app server, and this is what Cactus does for you.
It's also good to test on the app server if you're building a web app since
this is the context in which your EJBs will be used.

As for your connection refused error, it's likely a configuration problem so
look through the other Howto guides to make sure you have everything
configured properly.

Jason

-Original Message-
From: kendo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 10:32 AM
To: cactus usergroup
Subject: testing ejb's with cactus



Hi all

 

I have recently downloaded cactus to use for testing ejb's, however from
working with junit  I know the setup method should be called before each
test method etc. But when using cactus and following your example on the
apache site, it seems that the setup method is not called at all but the
test methods are.  Also I can test the ejb using junit by itself and this
works but rather than extending ServletTestCase, i extend the general
TestCase.

However with extending ServletTestCase

I always get connection refused from the container(which happens to be OC4J)

 

 

1) can you inform me on the proceedure is for testing ejb's with cactus
because I have looked the apache site and followed the example :

 

package org.apache.cactus.sample.ejb; 

 

import javax.ejb.*; 

 

public class ConverterEJB implements SessionBean 

{ 

private SessionContext context; 

 

public double convertYenToDollar(double theYenAmount) 

{ 

return theYenAmount / 100.0; 

} 

 

public ConverterEJB() 

{ 

} 

 

public void ejbCreate() throws CreateException 

{ 

} 

 

public void setSessionContext(SessionContext theContext) 

{ 

this.context = theContext; 

} 

 

public void ejbActivate() 

{ 

} 

 

public void ejbPassivate() 

{ 

} 

 

public void ejbRemove() 

{ 

} 

} 

and added the test with main to call the 

junit.textui.TestRunner.run(suite()), however, this does not seem

to work. 

test example:

package org.apache.cactus.sample.ejb; 

 

import javax.naming.*; 

import javax.rmi.*; 

import junit.framework.*; 

 

import org.apache.cactus.*; 

 

public class ConverterTest extends ServletTestCase 

{ 

private Converter converter; 

 

public ConverterTest(String name) 

{ 

super(name); 

} 

 //added this method to call on the cmd line

 //acting as a client

 public static void main(String []args){
  junit.textui.TestRunner.run(suite());
  
} 

public static Test suite() 

{ 

return new TestSuite(ConverterTest.class); 

} 

 

public void setUp() 

{ 

Context ctx = new InitialContext(); 

ConverterHome home = (ConverterHome) 

PortableRemoteObject.narrow(ctx.lookup(java:comp/ejb/Converter), 

ConverterHome.class); 

this.converter = home.create(); 

} 

 

public void testConvert() throws Exception 

{ 

double dollar = this.converter.convertYenToDollar(100.0); 

assertEquals(dollar, 1.0, dollar, 0.01); 

} 

} 

 

Can anyone let me know to go about testing ejb's with cactus 

 Many thanks for your help or advice in advance

 

Kendo



-
Do you Yahoo!?
New DSL Internet Access from SBC  Yahoo!

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Disabling Log Messages

2002-09-26 Thread Robertson, Jason

I had a similar issue when I upgraded to 1.4.1 the other day. The content of
the request and response were showing up as INFO log statements even
though I had cactus and commons-httpclient log levels set to WARN. 

I haven't looked at the httpclient code, but my suspicion is that there's
something in there configured wrong and the logger that being used has an
incorrect name or something. 

When I turned the global level to WARN, the statements went away, so I'm
obviously just not configuring the right category, but the right category
should be org.apache.commons.httpclient (shouldn't it?).

Jason

-Original Message-
From: Steve Appling [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 9:01 AM
To: [EMAIL PROTECTED]
Subject: Disabling Log Messages


By default I am seeing the content of the HTTP responses to my tests on
stderr.  I assume this is being logged through the SimpleLog logger, but I
have been unsuccessful disabling it.  I have tried
using -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpL
og, but that seems to have no impact.  I also tried changing the logging
level with -Dorg.apache.commons.logging.simplelog.defaultlog=fatal, but that
also did nothing.  What level are these messages being logged at?  How do I
stop it.

This would be a good topic on the howto_config.html page.  BTW, the Jakarta
Commons Logging link on that page in the documentation is currently
broken - it needs a .html at the end of the URL.


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Form Authentication

2002-09-17 Thread Robertson, Jason

Ok, I merged with the latest from CVS, and have tested on WebLogic 7 and
Tomcat.

Jason

-Original Message-
From: Robertson, Jason [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 16, 2002 5:53 PM
To: 'Cactus Users List'
Subject: RE: Form Authentication


Hmmm, I've gotten it to work, but there is some strange behavior.

I found an additional post saying you can't go directly to the login page
or j_security_check because then Tomcat wouldn't know where to send you once
you've authenticated. Therefore you _must_ go to a restricted resource
first, so that once authenticated you can be redirected there. I understand
the point, but would it really be that horrible to redirect to the defined
welcome-page in lieu of a known location? That seems like a quite reasonable
thing to do.

But, that's not what it does. 

So I now get the servlet redirector and go there first, on the assumption
that it is a restricted resource (which it must be for any of this to work).


Vincent - is this safe? I'm thinking not because what if the person writing
a JSP Redirector-only test case and they want to use form authentication?
Can they? I've never done a JSP Redirector before.

Once I get back the JSESSIONID from that request, I cache it, then log in.
There is something strange with the 302, however. I get back I get this
Location header:

Location: http://localhost/simple-form-login/secure/ServletRedirector

I'm using the stock Tomcat, so notice the fact that the port (:8080) is not
present in this redirect. Thus, my compare to my original request fails. Is
this a bug in Tomcat? How does my browser work (which is does)?

So, for now, I've commented out the check and it all works. On WebLogic,
too.

I've attached my code that works which is a mod of the last code I sent in
(i.e. not a mod of the latest in CVS). I hate to do it to ya Vincent, but I
don't have CVS access from here at work, so if you want to merge my changes
into your version you can (it's not much), or you can wait about 5 hours and
I can do it when I get home... :)

Jason

-Original Message-
From: Robertson, Jason [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 16, 2002 4:59 PM
To: 'Vincent Massol'; 'Cactus Users List'
Subject: RE: Form Authentication


Yeah, I'm working on it in between meetings :), it seems like it's a Tomcat
feature.

This is what is returned from tomcat when I try to go directly to
j_security_check:

HTTP Status 400 - Invalid direct reference to form login page
Status report
message: Invalid direct reference to form login page
description: The request sent by the client was syntactically incorrect
(Invalid direct reference to form login page).

I read one web page that said you get this when you try to go directly to
the login page (as opposed to going to a restricted resource first), and to
me that seems like a bug but I didn't really find anything that said it was
or should be a bug.

I'm going to experiment, perhaps if I have the JSESSIONID when I go to the
j_security_check page it'll be happy. I'll try to go the ServletRedirector
first, get a JSESSIONID, then log in. We'll see.

I'll pass on info as I find it...

Jason

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 16, 2002 4:45 PM
To: 'Cactus Users List'
Cc: 'Robertson, Jason'
Subject: RE: Form Authentication


Ok, we now have more info. The error you're getting in the stack trace
is:

Unable to login, probably due to bad username/password. Received a
[400] response code andwas expecting a [302]

This means that the URL used to login is not correct (400 - bad
request). The default URL used is: cactus.contextURL +
j_security_check. Maybe this is not correct.

I can't help you more here as I don't know enough about form-based
authentication. I'll have to read up on that.

Jason, any idea?
Thanks
-Vincent

 -Original Message-
 From: Qingxian Wang [mailto:[EMAIL PROTECTED]]
 Sent: 16 September 2002 17:47
 To: 'Cactus Users List'
 Subject: RE: Form Authentication
 
 I have tried the 1.5dev.  I still cannot run the authenticate test.
The
 username, password and the role are set in tomcat-user.xml.  My code
is
 like
 this:
 
 public class CactusTest_WebDeployerActionServlet extends
ServletTestCase {
 
 public CactusTest_WebDeployerActionServlet(String strName) {
 super(strName);
 }
 
 /**
  * Start the tests.
  *
  * @param theArgs the arguments. Not used
  */
 public static void main(String[] theArgs)
 {
 junit.textui.TestRunner.main(new String[]{
 CactusTest_WebDeployerActionServlet.class.getName()});
 }
 
 /**
  * @return a test suite (codeTestSuite/code) that includes all
 methods
  * starting with test
  */
 public static Test suite()
 {
 // All methods starting with test will be executed in the
test
 suite.
 return new
TestSuite(CactusTest_WebDeployerActionServlet.class);
 }
 
 public

Form Authentication

2002-09-12 Thread Robertson, Jason

Here's a FormAuthentication implementation that doesn't need any rework of
the standard flow. The only modification needed to make this compile is to
make the base class AbstractAuthentication's member variables 'theName' and
'thePassword' protected instead of private.

This is a first pass. It's short on comments, and has some debugging code
temporarily commented out, but it works. At least for me, on WebLogic 7.0.
:) 

I'll comment it and express some minor concerns especially with regards to
various app servers in the coming days, but I thought I'd throw this out
now.

I tried to include a sample ear that has a basic example, but the war's lib
directory is too big and it bounced. So I've included the project, just
adjust the jar file properties in build.xml to make it all work.

Jason




FormAuthentication.java
Description: Binary data


SimpleFormLogin.zip
Description: Binary data

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


Build Experience Feedback

2002-09-12 Thread Robertson, Jason

Just a few observation from a guy starting from ground zero trying to build
Cactus (my last build from scratch was around the 1.3dev timeframe):

The clover.jar definition is way below other jar definitions (on one hand it
might be nicer if they were together, but keep reading), and the clover.jar
file *must* exist regardless of if you're using clover or not. (If it
doesn't exist there's a copy that fails.) I guess if the copy gets fixed
then you don't have to move up the definition, keeping it with
clover.enabled seems reasonable.

Next, I got this (I think in the doc target):

BUILD FAILED
file:C:/java/jakarta-cactus-src-20020911/documentation/build.xml:200:
C:\java\ja
karta-cactus-src-20020911\documentation\docs\xdocs\misc not found.

Looks like the directory should be created first? But with info from the
next issue it seems like it's an empty directory, so maybe it should be
pruned from CVS?

So I then created the directory by hand and got this:

doc:
 [copy] Copied 1 empty directory to
C:\java\jakarta-cactus-src-20020911\docu
mentation\target\doc\misc
[stylebook] java.lang.NoClassDefFoundError: org/apache/stylebook/StyleBook
[stylebook] Exception in thread main

This I assume is the ant stylebook task, which I don't have. Is there any
documentation of all external stuff that is needed to do a full compile? I
did a quick look in a few files but found nothing.

I've since figured out I only needed to do ant run.framework to do what I
need to do, and this was by examining the build.xml file. BTW, it says at
the top of build.xml to do ant -projecthelp which I did but I didn't feel
this information was very useful as it was only the main targets.

And actually, I ended up making my own run.framework.jar that just does the
jar task for the framework. Shouldn't this be a little easier to do? I don't
want to build all the docs and such during development - I just want to
build the jar.

None of this is major stuff, except maybe needing to figure out all the
external stuff that is necessary to build, but I thought I'd give the
feedback.

Jason

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Form Authentication

2002-09-12 Thread Robertson, Jason

Ok, attached is a slightly updated file with some comments and such.

The basic premise is:
1. Is JSESSIONID non-null? If yes, stick it into a cookie and we're done.
2. If it's null, authenticate.
3. To authenticate, connect to ${ContextURL}/j_security_check with the
username/password. This _should_ authenticate you.
4. Cache the returned JSESSIONID.
5. To verify we were authenticated, check a combination of the response code
and maybe redirect location. See question below.

A TestCase could create a new FormAuthentication object for each test, or
could have a static one in the TestCase that will get initialized once and
reused. The latter would provide quicker testcases at the expense of keeping
state between test cases, which is a philosophical expense at best. The cool
thing is in this case, though, that even if a single test case is run in the
middle of the sequence it will still work. It doesn't really rely on the
TestCase before it (the authentication will just happen when needed), so it
may not really violate any of the unit test philosophy.

Only a couple questions: 

1. Will all app servers send a 302 response with the location being the
ContextURL after a successful login? WebLogic does, and that's my only
source right now. What about on an unsuccessful login? WebLogic returns a
200 and the content is that of the login page, but I think it would be
acceptable to return a 302 with a Location of the login page. I think my
code will work with both, but testing will be the only proof.

2. Do I need the setSecurityCheck method? Or will
${ContextURL}/j_security_check always work? It's really a safety net, but it
might be unnecessary.

Jason

-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 12, 2002 9:17 AM
To: Cactus Users List
Subject: Re: Form Authentication


Wow, just in the nick of time too!  I haven't looked at your code, but 
this is exactly what we need as well.

I look forward to the Cactus committers having a look at this to see if 
it fits in and getting it committed!  :)

Thanks Jason!

Erik

Robertson, Jason wrote:
 Here's a FormAuthentication implementation that doesn't need any rework of
 the standard flow. The only modification needed to make this compile is to
 make the base class AbstractAuthentication's member variables 'theName'
and
 'thePassword' protected instead of private.
 
 This is a first pass. It's short on comments, and has some debugging code
 temporarily commented out, but it works. At least for me, on WebLogic 7.0.
 :) 
 
 I'll comment it and express some minor concerns especially with regards to
 various app servers in the coming days, but I thought I'd throw this out
 now.
 
 I tried to include a sample ear that has a basic example, but the war's
lib
 directory is too big and it bounced. So I've included the project, just
 adjust the jar file properties in build.xml to make it all work.
 
 Jason
 
 
 
 
 
 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]




FormAuthentication.java
Description: Binary data

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


RE: Jetty integration Form-based authentication (was FW: Cactus)

2002-09-09 Thread Robertson, Jason

Vincent, 

Do you still have the original patch? (I'm pretty sure I do if you don't.)
The only issues I remember were that we needed to decide what the best path
was for implementing it. The problem is that it requires an internal round
trip and detecting that scenario was a little painful (more user
configuration than I would prefer), but not impossible.

The process was:
1. Make a normal request, automatically inserting JSESSIONID if we have one.
2. We're we redirected? If so, were we redirected to the user-defined login
page?
3. If so, we need to log in. Do that. Cache the JSESSIONID that's returned.
4. The response to the login request should be the response from the initial
request so make sure it gets routed properly and the rest of the unit test
continues as if nothing happened.

I guess one issue that was indirectly raised was the issue of keeping state
(JSESSIONID) between unit tests. This was a while back during a big
philosophical discussion about unit testing and I brought up a point
paralleling the one person's desire to keep state with form-based
authentication but I don't recall ever seeing a response and I forgot about
it until now. So do your feelings on this extend to form-based
authentication, or is this a special case?

Jason

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 09, 2002 4:07 AM
To: 'Cactus Users List'
Subject: Jetty integration  Form-based authentication (was FW: Cactus)


FYI. 

I have also committed the Jetty integration thing in CVS and it's
working for me! I'll write up a short tutorial soon. If some of you are
interested, feel free to ask and I can give quick directions and
information.

Thanks
-Vincent

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]]
 Sent: 08 September 2002 09:09
 To: 'nathan phillips'
 Subject: RE: Cactus
 
 Hi Nathan,
 
 Thank you very much for the compliment. It's great to know I can be of
use
 to someone! :-). I really like to receive feedback (be it good or bad)
but
 I don't receive that often ... So, thank you for that!
 
 WRT Cactus and Jetty, you'll be glad to know that I have finished a
very
 tight integration with Jetty which allow Cactus tests to be run
 transparently from any IDE or any simply Ant junit task. I'll try to
 commit the work during this coming week.
 
 Again that's a special integration, very unlike the Ant scripts that
we
 currently have for the other application servers. As Jetty is
embeddable
 it has allowed me to go much further in term of integration! I'm
really
 excited about the result.
 
 WRT form-based authentication, Jason Robertson (if I remember
correctly)
 had posted a patch on the mailing list a long time ago but there were
a
 few things that needed to be corrected before it could be integrated.
I am
 currently struggling for time (I'm working on other open source
projects
 and I'm writing a book, which takes all my time - that's for my night
time
 of course ;-)). Thus, I'm waiting for someone to step in and submit
again
 a patch.
 
 Nathan, can I repost this exchange to the Cactus mailing list. There's
 information that will interest others and maybe someone will step in
for
 the form-based authentication stuff?
 
 Thanks
 -Vincent
 
 
  -Original Message-
  From: nathan phillips [mailto:[EMAIL PROTECTED]]
  Sent: 08 September 2002 02:56
  To: [EMAIL PROTECTED]
  Subject: Cactus
 
 
 
  Hi Vincent,
 
  I wanted to thank you for doing such a great job with Cactus.  I've
been
  using it with great success on my current project.  I was wondering
if
  there
  were any plans for Form based security support and support for Jetty
any
  time soon?  Thanks again.
 
  Nathan
 
  _
  MSN Photos is the easiest way to share and print your photos:
  http://photos.msn.com/support/worldwide.aspx



--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Problem with JspTestCase for custom body tags.

2002-09-03 Thread Robertson, Jason

The period on the end of the link is necessary to see the text (when I
clicked on the link in Outlook it did not include the period). Don't know
why - but that fixes things!

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 11:01 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Problem with JspTestCase for custom body tags.


Nick - this link points to an empty page...can you repost?

Ken

-Original Message-

http://java-tools.eblox.com/index.php?JspTestCase%20for%20custom%20body%20ta
gs.

I'll try to either edit the documentation or post a FAQ entry sometime in
the next few weeks, but I thought I'd alert users now rather than later.

Nick Lesiecki

--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: [VOTE] Rename clientSetUp() and clientTearDown() in 1.5dev

2002-08-01 Thread Robertson, Jason

I didn't really like 'begin()/end()' at first because I though it might be
confusing. But I think it seems this way because it's being designed
backwards. 

If originally there was a begin()/end() (to mirror setUp()/tearDown()) and
then someone needed test-specific initialization (which likely would have
been Vincent as he wrote his first, maybe second, test case) and the
standard beginXXX() was created I don't think anyone would think twice.

+1

Jason 

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 01, 2002 1:55 PM
To: 'Patrick Lightbody'; 'Cactus Users List'
Subject: RE: [VOTE] Rename clientSetUp() and clientTearDown() in 1.5dev




 -Original Message-
 From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
 Sent: 01 August 2002 18:48
 To: Vincent Massol; 'Cactus Users List'
 Subject: Re: [VOTE] Rename clientSetUp() and clientTearDown() in
1.5dev
 
 Well, since you put it that way... I see your point. My only concern
is
 confusion between beginXxx() and begin(), being that one is tied to an
 individual test and the other is tied to the test suite, yet they both
 share
 a common name.

yes, I also see your point ... :-). I don't really care but we need a
name with which cactus users will be comfortable with as it will be hard
to change once it is released.  Hence the vote I have asked. ATM more
persons seem to prefer begin() and end(). Let's let it open for a few
days and we'll see then.

Could you live with begin() and end() if that choice was made or are you
categorically -1 ?

Thanks
-Vincent

 
 -Pat
 
 - Original Message -
 From: Vincent Massol [EMAIL PROTECTED]
 To: 'Cactus Users List' [EMAIL PROTECTED]
 Cc: 'Patrick Lightbody' [EMAIL PROTECTED]
 Sent: Thursday, August 01, 2002 6:43 PM
 Subject: RE: [VOTE] Rename clientSetUp() and clientTearDown() in
1.5dev
 
 
 
 
   -Original Message-
   From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
   Sent: 01 August 2002 11:11
   To: Cactus Users List
   Subject: Re: [VOTE] Rename clientSetUp() and clientTearDown() in
  1.5dev
  
   Personally I think clientSetUp and clientTearDown make more sense,
   assuming
   they work just like setUp and tearDown (once per test).
 
  ... yes, but Cactus has already extended JUnit by having beginXXX()
and
  endXXX() methods that are executed on the client side. In other
words,
  Cactus is Junit-compliant on the server side but the client side
is
  purely Cactus-specific.
 
  As we already have beginXXX() and endXXX(), don't you think it looks
  logical to have begin() and end() being global extensions (before
and
  after each test) ?
 
  Thanks
  -Vincent
 
  
   -Pat
  
   - Original Message -
   From: Vincent Massol [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Cc: 'Cactus Users List' [EMAIL PROTECTED]
   Sent: Thursday, August 01, 2002 10:56 AM
   Subject: [VOTE] Rename clientSetUp() and clientTearDown() in
1.5dev
  
  
Hi,
   
Charles Massey has proposed on the 15th of July another name for
the
clientSetUp() and clientTearDown() methods : begin() and end().
   
I think it is a better name than what we have and I propose to
make
  the
change to begin() and end(). It is more logical as we already
have
beginXXX() and endXXX() methods.
   
What do you think ?
   
Here is my +1
   
Thanks
-Vincent
   
   
--
To unsubscribe, e-mail:
   mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
   mailto:[EMAIL PROTECTED]
   
  
   --
   To unsubscribe, e-mail:   mailto:cactus-user-
   [EMAIL PROTECTED]
   For additional commands, e-mail: mailto:cactus-user-
   [EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Is there a WebLogic guru in the house?

2002-05-02 Thread Robertson, Jason

Your DOCTYPE for weblogic.xml is for WLS6.1, but the DOCTYPE for
weblogic-ejb-jar says WLS5.1.

If you're using WLS6.1 then WLS might be choking on your weblogic-ejb-jar
file which contains your JNDI mapping. If the JNDI mapping isn't getting
through then you'd see a NamingException. The format in 6.0 is a little
different, so check the DTD
(http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd).

Also, check your weblogic.log file, when I successfully deploy I see this:

... EJB Deployed EJB with JNDI name ejb/UserService. 

Jason

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 11:08 AM
To: Cactus Mailing List
Subject: Is there a WebLogic guru in the house?


Hi,

I'm having a hell of a time trying to get my head around the WebApp
configuration to get EJB tests to work correctly. I think my main problem is
that I don't understand the relationship between the weblogic.xml file and
the EJB. So here's my setup. If someone can pinpoint my problem, I'd be so
ever thankful!

META-INF/
META-INF/MANIFEST.MF
META-INF/weblogic-ejb-jar.xml I'm not sure I need this
META-INF/ejb-jar.xml If I include this I get a NPE when starting WL
WEB-INF/
WEB-INF/classes/contains all my classes including the
junit/home/remote/bean class
WEB-INF/lib/
WEB-INF/lib/aspectjrt.jar
WEB-INF/lib/cactus-ant.jar
WEB-INF/lib/cactus.jar
WEB-INF/lib/crimson.jar
WEB-INF/lib/httpunit.jar
WEB-INF/lib/junit.jar
WEB-INF/lib/log4j.jar
WEB-INF/lib/mockobjects-core.jar
WEB-INF/lib/mockobjects-doc.jar
WEB-INF/lib/mockobjects-j2ee1.3.jar
WEB-INF/lib/mockobjects-jdk1.3.jar
WEB-INF/lib/xalan.jar
WEB-INF/lib/some other jars specific to our project
WEB-INF/weblogic.xml
WEB-INF/web.xml

in my web.xml I have the following:

web-app
display-name
handler
/display-name
description
bla bla bla
/description

!-- Cactus configuration
Note: Do not place any XML comments in this Cactus configuration section
(Ant's filtered copy is used to activate this configuration when the test
web application is built)
--
!-- Begin Cactus Configuration --
servlet
servlet-nameServletRedirector/servlet-name
servlet-classorg.apache.cactus.server.ServletTestRedirector/servlet-class

/servlet

servlet-mapping
servlet-nameServletRedirector/servlet-name
url-pattern/ServletRedirector/url-pattern
/servlet-mapping

ejb-ref
  ejb-ref-namecreate_subscriber_profile/ejb-ref-name
  ejb-ref-typeSession/ejb-ref-type
  !-- these two classes are in the classes directory --
  homeca.masq.fido.handler.HandlerHome/home
  remoteca.masq.fido.handler.Handler/remote
/ejb-ref

!-- End Cactus Configuration --


/web-app


In my weblogic.xml I have:

!DOCTYPE weblogic-web-app PUBLIC -//BEA Systems, Inc.//DTD Web Application
6.0//EN
http://www.bea.com/servers/wls610/dtd/weblogic-web-jar.dtd;

weblogic-web-app

 description
Web app to test cactus
 /description

 weblogic-version/

 reference-descriptor
ejb-reference-description
  ejb-ref-namecreate_subscriber_profile/ejb-ref-name
  jndi-namecreate_subscriber_profile/jndi-name
/ejb-reference-description
 /reference-descriptor


/weblogic-web-app

In my ejb-jar.xml file, I have the following. If I put this in my META-INF
directory, I get a
null pointer exception.

?xml version=1.0?
!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'
ejb-jar
enterprise-beans

!-- CreateSubscriberHandler --
session
ejb-namecreateSubscriberHandler/ejb-name
homeca.masq.fido.handler.HandlerHome/home
remoteca.masq.fido.handler.Handler/remote

ejb-classca.masq.fido.handler.registration.CreateSubscriberHandlerBean/ej
b-class
session-typeStateless/session-type
transaction-typeContainer/transaction-type

env-entry
descriptionEndUserManager Jndi
Name/description

env-entry-nameEND_USER_MANAGER_JNDI_NAME/env-entry-name

env-entry-typejava.lang.String/env-entry-type

env-entry-valueendusermanager.EndUserManagerHome/env-entry-value
/env-entry
/session

/enterprise-beans

assembly-descriptor

container-transaction
method
ejb-namecreateSubscriberHandler/ejb-name
method-intfRemote/method-intf
method-name*/method-name
/method
trans-attributeSupports/trans-attribute
/container-transaction
/assembly-descriptor

/ejb-jar

in my weblogic-ejb-jar file, I have this:

?xml version=1.0?

Log4J Issues

2002-05-02 Thread Robertson, Jason

I'm having a bear of a time getting my log4j setup working with the final
1.3 that was working fine with my dev build of a couple months ago. Some of
it was me not updating my property files, but I have found a few issues:

1. On the server side, I need cactus.properties in the classpath. This is
necessary so that LogService can find the 'cactus.enableLogging = true'
property and enable the logging. The docs say this is only necessary on the
client side.

2. The docs also say that default log_client.properties and
log_server.properties files are in cactus.jar, but they are not.

3. I'm getting duplicate entries for each log line. I doubt this is a Cactus
problem, anyone else seeing this? A log4j-1.2rc1 issue?

4. I no longer see my EJB's log statements (I'm testing EJBs via
ServletRedirector). I also don't see any errors (e.g., 'please initialize
the log4j subsystem properly') - I just don't see anything. This worked fine
before. 

If anyone has ideas, please let me know!

Jason

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Log4J Issues

2002-05-02 Thread Robertson, Jason

Errr, scratch the EJBs not logging mystery. Mystery solved by finding the
particular call I was doing didn't actually have any log statements. Doh!

Jason

-Original Message-
From: Robertson, Jason 
Sent: Thursday, May 02, 2002 1:26 PM
To: 'Cactus Users List'
Subject: Log4J Issues


I'm having a bear of a time getting my log4j setup working with the final
1.3 that was working fine with my dev build of a couple months ago. Some of
it was me not updating my property files, but I have found a few issues:

1. On the server side, I need cactus.properties in the classpath. This is
necessary so that LogService can find the 'cactus.enableLogging = true'
property and enable the logging. The docs say this is only necessary on the
client side.

2. The docs also say that default log_client.properties and
log_server.properties files are in cactus.jar, but they are not.

3. I'm getting duplicate entries for each log line. I doubt this is a Cactus
problem, anyone else seeing this? A log4j-1.2rc1 issue?

4. I no longer see my EJB's log statements (I'm testing EJBs via
ServletRedirector). I also don't see any errors (e.g., 'please initialize
the log4j subsystem properly') - I just don't see anything. This worked fine
before. 

If anyone has ideas, please let me know!

Jason

--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Log4J Issues

2002-05-02 Thread Robertson, Jason

Ok, the duplicate entries does seem to be a log4j problem. When I add
nothing to the default log_server.properties file, this line is all I need
to get my debug statements (as it should be):

log4j.rootCategory=DEBUG, cactus

but when I add my own category lines:

log4j.category.mypackage1 = DEBUG, cactus
log4j.category.mypackage2 = DEBUG, cactus

then I get two entries for log statements coming from these packages.

Anyone on the log4j list? Is this a known issue? A 1.2 feature?

Jason

-Original Message-
From: Robertson, Jason 
Sent: Thursday, May 02, 2002 1:37 PM
To: 'Cactus Users List'
Subject: RE: Log4J Issues


Errr, scratch the EJBs not logging mystery. Mystery solved by finding the
particular call I was doing didn't actually have any log statements. Doh!

Jason

-Original Message-
From: Robertson, Jason 
Sent: Thursday, May 02, 2002 1:26 PM
To: 'Cactus Users List'
Subject: Log4J Issues


I'm having a bear of a time getting my log4j setup working with the final
1.3 that was working fine with my dev build of a couple months ago. Some of
it was me not updating my property files, but I have found a few issues:

1. On the server side, I need cactus.properties in the classpath. This is
necessary so that LogService can find the 'cactus.enableLogging = true'
property and enable the logging. The docs say this is only necessary on the
client side.

2. The docs also say that default log_client.properties and
log_server.properties files are in cactus.jar, but they are not.

3. I'm getting duplicate entries for each log line. I doubt this is a Cactus
problem, anyone else seeing this? A log4j-1.2rc1 issue?

4. I no longer see my EJB's log statements (I'm testing EJBs via
ServletRedirector). I also don't see any errors (e.g., 'please initialize
the log4j subsystem properly') - I just don't see anything. This worked fine
before. 

If anyone has ideas, please let me know!

Jason

--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Testing EJB implementing EJBLocalObject interface with Cactus

2002-03-27 Thread Robertson, Jason

I found this page:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts6.html

And from the section Deciding on Remote or Local Access it says:

Type of client: ... If an enterprise bean's clients are Web components or
other enterprise beans, then the type of access depends on how you want to
distribute your components. 

To me, Web components equals a servlet or a JSP and this paragraph implies
local access from a web component is fine if it meets your distribution
needs, which for cactus testing isn't an issue.

Jacek, when you try to access the local interface in the reference
implementation, what error are you getting?

Jason

-Original Message-
From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 27, 2002 11:08 AM
To: Cactus Users List; [EMAIL PROTECTED]
Subject: RE: Testing EJB implementing EJBLocalObject interface with
Cactus


Thanks Franck!

I found that paragraph, but to quote from earlier in the thread:


To be exact, it's possible to access locals while war and ejb-jar
are both in the same *ear*.

Regards,

Slava Imeshev

--- Robertson, Jason [EMAIL PROTECTED] wrote:
 You can access the local interfaces from within a servlet as long as (I
 think) the servlet container and the EJB container are running in the same
 JVM. If it has to jump JVM boundaries then a remote interface is needed.


These don't imply that clients are limited to EJBS only. However, the spec
says:


A local client of a session bean or an entity bean may be another enterprise
bean (a session bean, entity bean, or message-driven bean).


What I'm wondering is: can you have spec compliant local clients who reside
in the same JVM but are not enterprise beans? (I have heard conflicting
reports.)

Cheers,

Nicholas Lesiecki
Principal Software Engineer
eBlox, Inc.
(520) 615-9345 x104
Check out my new book!:
Java Tools for Extreme Programming: Mastering Open Source Tools, including
Ant, JUnit, and Cactus

http://www.amazon.com/exec/obidos/ASIN/047120708X/

Check out my article on AspectJ:
http://www-106.ibm.com/developerworks/java/?loc=dwmain




-Original Message-
From: Franck Rasolo [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 6:18 PM
To: Cactus Users List
Subject: RE: Testing EJB implementing EJBLocalObject interface with
Cactus


Nicholas,

I believe Jason got it right according to the first two paragraphs of
section 5.3 (page 52) of the EJB 2.0 specification:

snip
5.3 Local Clients

Session and entity beans may have local clients. A local client is a client
that is collocated in the same JVM with the session or entity bean that
provides the local client view and which may be tightly coupled to the bean.
A local client of a session bean or an entity bean may be another enterprise
bean (a session bean, entity bean, or message-driven bean).

Unlike the remote client view, the local client view of a bean is not
location
independent. Access to an enterprise bean through the local client view
requires the collocation in the same JVM of both the local client and the
enterprise bean that provides the local client view. The local client view
therefore does not provide the location transparency provided by the remote
client view.
/snip

Cheers,

Franck Rasolo
Independent Consultant
London, UK

--- Nicholas Lesiecki [EMAIL PROTECTED] wrote:
 Does anyone have the spec chapter and verse on these issues? I'd like to
 read up. I checked the EJB spec but couldn't find anything in a couple of
 quick scans. Does anyone have page numbers in front of them?


 Cheers,

 Nicholas Lesiecki
 Principal Software Engineer
 eBlox, Inc.
 (520) 615-9345 x104
 Check out my new book!:
 Java Tools for Extreme Programming: Mastering Open Source Tools, including
 Ant, JUnit, and Cactus

 http://www.amazon.com/exec/obidos/ASIN/047120708X/

 Check out my article on AspectJ:
 http://www-106.ibm.com/developerworks/java/?loc=dwmain

 -Original Message-
 From: Slava Imeshev [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, March 26, 2002 2:08 PM
 To: Cactus Users List
 Subject: RE: Testing EJB implementing EJBLocalObject interface with
 Cactus


 To be exact, it's possible to access locals while war and ejb-jar
 are both in the same *ear*.

 Regards,

 Slava Imeshev

 --- Robertson, Jason [EMAIL PROTECTED] wrote:
  You can access the local interfaces from within a servlet as long as (I
  think) the servlet container and the EJB container are running in the
same
  JVM. If it has to jump JVM boundaries then a remote interface is needed.
 
  I'm testing my Entity beans with local interfaces just fine by extending
  ServletTestCase and accessing them in the traditional fashion.
 
  Jason

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards.
http://movies.yahoo.com/

--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional

RE: Testing EJB implementing EJBLocalObject interface with Cactus

2002-03-26 Thread Robertson, Jason

You can access the local interfaces from within a servlet as long as (I
think) the servlet container and the EJB container are running in the same
JVM. If it has to jump JVM boundaries then a remote interface is needed.

I'm testing my Entity beans with local interfaces just fine by extending
ServletTestCase and accessing them in the traditional fashion.

Jason

-Original Message-
From: Jacek Skrzypiec [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 12:20 PM
To: [EMAIL PROTECTED]
Subject: Testing EJB implementing EJBLocalObject interface with Cactus


Dear All,

Is there any support for testing ejb that instead of EJBObject implement
only EJBLocalObject.

To call a method of an ejb from servlet or JSP, it has to implement remote
interface (EJBObject, EJBHome).
If my bean implements local interface I cannot to anything.

I think that the way around it is to use an session bean (extending
TestCase) that implements the test methods and execute them indirectly
through another
object implementing ServletTestCase.

It requires a lot of work.  Is there any better way to achieve it?

I think it would be possible to save time if there was a ejb session bean
version of TestSuit or JUnit Test Runner

Thanks in advance for any suggestions.

Jacek

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Log Hijacking

2002-02-18 Thread Robertson, Jason

Hmmm, interesting feature ya got there! 

What concerned me the most, at first, was that after creating my test case
things weren't working and I went to the jboss log to see how far my EJB had
gotten - and none of my debug statements were there! After a bit, I found
them in the cactus log, but that certainly wasn't the first place I looked.

Your arguments all make sense, but I would think if the container already
initialized things that cactus should just piggy pack onto that log. I'll
look into it to see if there's anything I can find that would do that, but
it's not a pressing priority since I did finally find my EJB's debug
statements. :)

Jason

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 16, 2002 5:01 AM
To: 'Cactus Users List'
Subject: RE: Log Hijacking


Hi Jason,

This is the way it is meant to be :-) (it's called a feature ;-)). Log
Hijacking is the perfect way to describe it !

Ideally, Cactus logs would be completely independent of applications
logs (and application server ones). However, this is not possible with
Log4J 1.1.x. It is possible with Log4J 1.2 (with the notion of
Repository). However, everyone is still using version 1.1 and version
1.2 is not out yet, thus Cactus cannot move to version 1.2 yet and
probably for a while.

That said, I tried to find the best approach. Here are some ideas so
that you understand better my line of thoughts :

1/ Let's imagine that the code to test is already logging data using
Log4J. Cactus is about unit testing methods. Thus, it will usually
bypass any code that is used by the application to initialize its own
logging system and hit directly the method to test. Thus, if Cactus does
not initialize Log4J itself, nothing would be logged.

2/ Cactus logs are only interesting to debug Cactus and thus are not of
interest most of the time. However, Cactus still need to initialize
Log4J because of point 1/ above. Also, by default the logging level for
Cactus is set to WARN, thus there should be no Cactus log in the Cactus
log files.

3/ When you execute your application in test mode with Cactus, Cactus
takes control and becomes the new container if you prefer (so to speak).
Thus it is can be logical that it redirects all logs to its log files
...

What about the case where log4J is initialized by the container engine ?
This happens before Cactus initializes Log4J itself. However, Cactus
re-initializes Log4J and thus any appender/category that would have been
previously defined are ignored. This is potentially an area we could
improve by telling log4J to append and not replace. I don't know of an
easy to do it but it might exist. Feel free to submit a patch if you
wish !

WRT to your problem, the solution if you want several log files is to
add the different appenders and categories to log_server.properties

I have no clue WRT the name of the file issue. I don't remember of any
default name.

Thanks
-Vincent

 -Original Message-
 From: Robertson, Jason [mailto:[EMAIL PROTECTED]]
 Sent: 15 February 2002 22:55
 To: '[EMAIL PROTECTED]'
 Subject: Log Hijacking
 
 I'm running Cactus in JBoss, and as soon as I run a Cactus test case,
all
 logging goes into cactus_server.log. And I mean ALL logging: Cactus,
my
 tests, and JBoss. JBoss' server.log is never written to again.
 
 This may be a log4j issue, or a lack of understanding of log4j on my
part,
 but it sure doesn't seem right! And since it happens only after
running a
 Cactus test case, I'm asking here first. :)
 
 Adding to my confusion, I removed the cactus appender completely from
my
 log_server.properties file and I tell Cactus and my tests to use the
JBoss
 appenders, which are presumably already defined. This doesn't have any
 affect, and even more interesting is that the line defining the name
of
 the
 file is not there, but the file is still used. Is there a default
 somewhere
 or something?
 
 I've rebuilt from scratch, removed JBoss' temp deploy directory,
 redeployed
 several times and it make no difference. Any ideas?
 
 Jason
 
 --
 To unsubscribe, e-mail:   mailto:cactus-user-
 [EMAIL PROTECTED]
 For additional commands, e-mail: mailto:cactus-user-
 [EMAIL PROTECTED]




--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]