Jean Robillard

Greenhorn
+ Follow
since Apr 07, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jean Robillard

I am wondering how one might automate logging into some system protected by SSO (single sing-on). I say SSO because in SSO, when you enter a URL of the page you want to log into, often you are re-directed to a totally different URL which is the SSO login page (whose URL often contains a long, dynamic string such as session ID). After the successful authentication, you are back to the original URL.

I haven't used QTP in years so I am not sure if it can automate this sort of authentication, but I know that QTP could automate non-SSO type of authentication by recording & reply.

I don't really want to have to use a pricey tool like QTP even if SSO authentication automation is possible with it. Is there a way to do this via Java, Groovy, expect, or any other language or free tool ?

Thanks.

9 years ago
Thanks for the reply. I really needed to understand how namespaces really worked. The following URL was helpful.

http://radio.weblogs.com/0118231/stories/2006/10/03/xslt10PatternMatchingTipsForSourceDocumentsWithNamespaces.html
I want to transform the following simple XML, replacing test1 with test2 and test2 with test3.

<?xml version="1.0" encoding="UTF-8"?>
<bla xmlns="http://java.sun.com/xml/ns/javaee">
<display-name>test1</display-name>
<module>
<web>
<web-uri>RAV.war</web-uri>
<context-root>test2</context-root>
</web>
</module>
</bla>

And here's my XSL:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />

<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*" />
</xsl:copy>
</xsl:template>

<xsl:template match="/bla/display-name">
<display-name>test2<display-name>
</xsl:template>

<xsl:template match="/bla/module/web/context-root">
<context-root>test3</context-root>
</xsl:template>
</xsl:stylesheet>

This should work but the result is that I am not seeing any transformation at all (it only applied identity transformation). It didn't match /bla/display-name or /bla/module/web/context-root.

When I removed the default namespace ("xmlns="http://java.sun.com/xml/ns/javaee") for <bla> tag, then the transformation worked as expected.

How come it could not match /bla/ if it contained this default namespace? How can I fix XSL so that it works? Thank you so much.
When a new project begins, source codes are checked into mainline first.
Then the mainline is branched when/before the product is released to allow parallel development, etc.
Let's say I branched into v1.0.
And let's say the upcoming new features are so vastly different than v1.0 that a lot of 'new' files are to be checked into mainline, as well as a lot of pre-existing files are no longer relevant.
What is the correct way to handle the mainline regarding these non-relevant files ?

1) Remove (delete) them from mainline. Of course it leaves the deletion history so that we can go back to them, but as far as the HEAD revision goes, they will no longer be visible. With each releases (v2.0, v3.0), the mainline is kept clean. But there are a lot of deletions going on in mainline with each release. And we won't be able to mix old (deleted) files with latest files when a need arises in the future in order to produce a certain feature.

2) Just leave the non-relevant files. When it's time to branch again (v2.0), select only those relevant files to branch, so that this branch will not be polluted with irrelevant files. Let's say the next set of features are (again) so vastly different that a lot of files become irrelevant, then the irrelevant files will keep growing through each releases (v2.0, v3.0), but at least with each release we take care to branch right set of files and we are not deleting files from mainline. So, latest files can work with old files to produce a new feature as needed.

This situation (vastly different features) may sound unrealistic, but imagine that a product starts with client/server, and then later decides to replace a thick client with HTML. Another example is replacing flat file database with relational database. With 1), we can't mix deleted files with latest development code. In other words, if I am developing a new feature and it needs a thick client (which is now deleted), the mainline can only check out old revision or new, not both at the same time. With 2), a lot of files in mainline will become irrelevant over time, while allowing reuse of old-revision files when needed.

What would you choose - 1), 2)? Any other ideas?
No I am not using Maven. But it's resolved now. For some reason, I must go to Project->Properties->Source tab->Add Folder... menu to add a new source folder. Instead, I had manually created a folder called test from Windows explorer. Even though Eclipse detected this directory and displayed it under "Java Resources" in its Project Explorer, it didn't quite do it right and exhibited the problem I originally described, even though the Project properties correctly displayed it as a source folder. Weird.
Hi, I have the following directory structure w/ JUNIT (which is not really relevant though)

src (directory)
src/com
src/com/xyz
src/com/xyz/SomeClass.java

test (directory)
test/com
test/com/xyz
test/com/xyz/SomeClassTest.java

Note: src, test are under the same project's "Java Resources" node in Eclipse.


Unfortunately, within Eclipse, SomeClassTest cannot test SomeClass, because it cannot "see" SomeClass even though they are supposed to be in the same package com.xyz. Eclipse would simply complain that SomeClass cannot be resolved, with an "X" icon at the offending line that references SomeClass within SomeClassTest.

Can I resolve this issue in Eclipse, or do I have to do this manually (e.g. via ANT) by copying these files into the same directory before compiling them together (which means, I wouldn't be able to use Eclipse anymore). Thanks....
What�s true about the lifecycle of a servlet? (Choose all that apply.)
A. The service() method is the first method invoked by the container when a new request is received.
B. The service() method is invoked by either doPost() or doGet() after they�ve completed a request.
C. Each time that doPost() is invoked, it runs in its own thread.
D. The destroy() method is invoked after every invocation of doGet() completes.
E. The container issues a separate thread for each client request.

The answers are C and E. However, I think that A and C are highly debatable.

For A: the wording of "when a new request is received" is vague. I think the author meant "when the very first request is receved by the servlet". Then yes, I agree that service() is not the first method called, but rather init(). But the current wording to too vague to learn toward one way or the other, because we don't know if it's the very first request or not. I believe all requests are "new" requests!

C is debatable too. Each time service() is invoked, it runs in its own thread. So it's rather obvious that doGet() does also. So while C is not technically wrong, the problem is that it's equally likely for another test author to say "C is wrong, it's service() that runs in its own thread" and our choice would have been denied.

Any comments... ?
[ September 09, 2008: Message edited by: Jean Robillard ]
To answer Charles's question, the question is from Marcus Green's mock exam 3.

http://www.examulator.com/moodle/course/view.php?id=5&topic=all

I'm not trying to knock Marcus here, I think his mock exams are really helpful.
Which of the following statements are true?

Choose at least one answer.
A. A filter must extend the HttpFilter class Incorrect
B. A filter must implement the Filter interface Correct
C. Filters are chained to servlets through the flter tag in the deployment descriptor Correct
D. A filter must be mapped to one and only one servlet Incorrect
E. A filter may be mapped either to a single servlet or to multiple servlets via a URL pattern Correct

The answers are B, C, and E, but I don't agree with C. I believe the filters are chained to servlets through the "<filter-mapping>", not "<filter>" tag, because <filter> declares a filter, not saying anything about the associated servlet.

Am I being too picky or is the question wrong..? Thanks.
<% request.setAttribute("bab", ""); %>

${bab eq 0} => outputs false
${bab gt -1} => outputs true

How can I explain this? In a logical expression, an empty string is not treated as 0, because

${6 / bab} => results in an exception, not "Infinity"

How does EL treat an empty string in a logical or arithmetical expression ?

Thanks.
Anybody who passed SCJD more than 30 days ago still waiting for the certificate ?

The final passing score was posted on www.CertManager.net/sun_assignment back in July 12th, but "the other" site (CertManager/sun) still says it's "Pending".

I sent an email to who2contact the other day, but no reply. What's going on? Anybody else in the same boat ?

For those who already got their certificate, how long did it take *after* you actually passed SCJD? Thanks.
Hmm I don't know which version of URLyBird you guys are working on, but my version (1.2.3) of URLyBird does not throw RNFE from unlock, only SecurityException. This makes sense for me because my implementation of unlock() does not care whether the record is deleted or not, it cares only that it can successfully unlock a record.


You are doing the right thing. But you must also manually create a stub for RemoteServiceImpl in addition to the factory. Then it won't be downloaded dynamically.
By providing the implementation of the given interface, you will be writing a data access object (i.e., the database system).
I just let each other overwrite the config settings

I am fine with it - if the server & client are launched from the same working directory using the same JAR file, then whatever the last-invoked JVM will make the most recent updates to the cofig file. This works for me because all the config settings are identical between a server & a client. and I only read & write at startup. There are many choice for approaching this obviously.