Ian Perkins

Or else reinstall Java 1.5 alongside 1.4.2 and don't use the IBM tool for this exercise(presumably the tutorial includes instructions on how to run the app from the command line?).

I guess that if you are allowed to install different Java versions then you should have access to a command shell? You can then switch between versions by changing the PATH variable...

Hi Paul,

Many thanks - I thought I had could understand the spec but I had made exactly the same mistake as Hannah.

I owe you a virtual beer!

Ian

Hi Paul,

This is what the majority of "real life" server applications do anyways (at least the ones that are worth a crap!).

Uh, Apache Tomcat anyone?

Thanks Frans, it's good to know this worked for you...

I think I will continue anyway with my decision to rely on the properties file with either notepad or vi as the front end!

Ian

I guess you can assume that the application will be run on a system which does support GUIs, otherwise how would they test the client?

This is precisely what worries me. I think that a client/server type setup implies two different physical pieces of hardware (otherwise why bother, just run always in local mode). I plan to test with a Windows laptop client connected to a pc running Linux. Testing both components on one piece of kit is not extensive enough and, in my experience, does not reveal all the subtle bugs especially in a sockets based implementation like mine.

*Most* servers in a real-life situation will be Unix/Linux machines which would perhaps also be running a web-server app as well as perhaps hosting a database layer etc etc. Typically they do not need to support a GUI.

I guess the answer is the same as in many other threads - make a decision and document the reasons - but I am still curious as to how the examiners test our software. If they expect true cross-platform transparency (which I believe is an implicit goal of all Java development) then a server-side GUI is going to fail dramatically under certain conditions.

Thanks anyway for the feedback

Ian

Hi,
There is something that worries me here... the assumption that there can be a server gui also presupposes that the server software will be running in Windows or similar where Swing painting operations have an implementation.

If I try to run a Java gui on the HP-UX machine at work I will get some very angry error messages. The only front end is via a Telnet connection handled by some kind of terminal emulator. Write-Once-Run-Anywhere does not really apply IMHO.

How do I know that the Sun examiners will not try to run my server on this type of setup?

Thanks for any comments...
Ian

Phew! What a relief!

Some random thoughts on preparing for the exam:

- I don't think there is ever going to be one single book that will get you through this exam. I had been waiting for the HF book because I really like the concept and style but cancelled my order and went ahead anyway. All the information is out there, spread between the specs, the J2EE tutorial and a couple of existing books.
- The exam is very faithful to it's objectives so use them as a basis for study. I found the exam to be much clearer (and cleverer) than SCJP so be prepared and take your time. As I went through I was sure I was failing miserably but when I reviewed all my answers in the last 40 minutes I started to cheer up.
- Use acronyms to revise. This is not a new idea but I don't think I could memorise, for example, all the 20 implicit objects without something to spark my memory. I had six sets of acronyms that covered all the hard-to-remember stuff like listener classes and events but the DD and TLD are another story! Those just have to be remembered!

Good luck!

Thanks!

I am still a bit confused about why the JSTL 1.1 TLD for the core tags i.e. c.tld, points to the tag class files in package ...tag.rt.core (where the implementation is expecting an Object to be passed) whereas there are class files in package ...tag.el.core which expect String args.

I am using a copy of Pro JSP (JSP 2.0 and Servlet 2.4) which states that the 'rt' implementations are for backwards compatibility with scripting expressions and that the 'el' implementations are there to support the EL... this doesn't seem quite right (!)

Ah well, thanks again for the insights and advice...

Sorry, I should have downloaded the source code before posting :-(

I am new to all this and just downloaded the nearest implementation I could find without really looking at the differences...

Turns out I am using the org.apache.taglibs.standard.tag.rt.core implementation of SetTag - the arg to setTarget is an Object so it must have been evaluated before the setter is invoked.

The org.apache.taglibs.standard.tag.el.core implementation accepts a String and then searches the scope objects to locate the bean/Map whose id is passed in the setTarget method.

What I have to do now is to try to understand the differences between all of these implementations!

Which do you use as a standard? Is one of them redundant now in JSP 2.0?

Hi Bear,

Thanks for the reply - I understand this but do you know why this is inconsistent with the standard actions which take a string as the value supplied to the name attribute? e.g. <jsp:setProperty name="x".../>

According to the JSTL documentation on the Sun website, the type of the target attribute is String so what is the run-time type of the object passed to the setTarget method of the <c> tag?

Actually, I guess I _should_ check the source code myself!

Thanks again

Ian

Hi,

Please could someone explain why...

<c:set target="myBean" property="x" value="y"/>

throws an exception (invalid property), whereas...

<c:set target="${myBean}" property="x" value="y"/>

works perfectly!

Why should the target attribute have to be expressed in EL?

i'm sure there is a reasonable explanation but I just can't see it...

Thanks

Ian

Hola Alberto!

I have also been using that book in preparation for the exam and I can recommend Pro JSP by Simon Brown et al, as well as reading the JSP 2.0 spec and Servlet 2.4 spec published by Sun.

Good luck!

The servlet container will only create one instance of each servlet; that is why writing thread-safe code is so important...

Therefore, by definition, there can only be one ServletConfig for each servlet.

Help!

I know this question has been raised in various threads but I still cannot make Tomcat 5.0.27 agree with the Servlet 2.4 specification; I am sure this is due to something wrong in my set-up of the deployment descriptor but I am going round in circles trying to understand it.

My question concerns the <role-name> tag within <auth-constraint>. The spec says that a <role-name> of * is 'shorthand for all role names defined in the deployment descriptor' (p97).

I understand this to mean the sum of all the <role-name> elements inside <security-role> elements, in the deployment descriptor. In other words, if role XYZ is _not_ mentioned in the deployment descriptor then any user in role XYZ (in tomcat-users) will _not_ be allowed access to any resource collection where the role-name is set to *.

However, when I test this, I can achieve authorisation for ANY user in ANY role mentioned in the tomcat-users.xml file!

In my test, the resource being accessed from the client is a servlet so, in the doGet(...) method I use request.isUserInRole("xxx") on the roles actually described in the deployment descriptor and get 'false' returned in both cases.

The doGet(...) returns an HTML form which issues a POST request to a second servlet. This servlet has an auth-constraint applied to specific roles and, as expected, any user not in one of those roles is not authorised to access it.

I have tried everything I can think of so any suggestions/remarks would be much appreciated.

Thanks in advance!

Ian

Shankar,
Thanks for your reply but perhaps I did not fully explain my question...
If I 'include' another servlet and then look in the request passed into the 'included' servlet doXXX method then I do indeed see some attributes which the server has created - in other words I don't have to do anything except retrieve these attributes using the names given in the tutorial.
However, if I 'forward' to a servlet, there are no added attributes in the request when it arrives in the 'forwarded' resource.
This seems to be at odds with what the tutorial suggests - in fact there is also an objective in SCWCD 1.4 which mentions these attributes but I don't know why the forwarding mechanism is not establishing them.
Regards
Ian