RE: Stopping the Server at the Beginning of Tests
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
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
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
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
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
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
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
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
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
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
/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
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
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
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
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
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
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
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
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
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)
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.
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
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?
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
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
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
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
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
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
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]
