Phil Kurian

Ranch Hand
+ Follow
since Feb 26, 2006
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 Phil Kurian

Hi

I'm having a bit of trouble using the jstl c:set command for setting properties on javaBeans.

The jsp I've written is as below. The bean I'm using has a single property called "name" and it's a String. The relevant public getters and setters have been written





Unfortunately I get the following error in Tomcat

org.apache.jasper.JasperException: Invalid property in <set>: "name"

As far as I can tell the JSP can access the bean, as I am able to use the jsp:setProperty and jsp:getProperty methods successfully.

Could anyone give me some direction on what I'm doing wrong?

thanks
[ July 10, 2006: Message edited by: Phil Kurian ]

I think Phil is refrering the old version of the TLD specification. As per the JSP 2.0, there is no jspversion element in the tld. For the JSP 2.0, there is no XML DD document, the scema is definded using XSD. The <body-content> is mandatary as per JSP 2.0 for <tag>.



Now I'm getting confused.

The JSP spec I've been looking at is the JSP 2.0 spec on JCP. According to that spec jsp-version (note the hyphen) is mandatory and body-content is not.

Seems to be the same in SCWCD exam study kit (deshmukh et al).

Unless both of them are wrong (which is quite possible) it seems body-content is not mandatory unless using simple tags.

In case of a distributable application each JVM has their own instance of ServletContext and ServletContext is not shared across applications and there is only one default context in distributed environment have you refered to the default context as a load balancing server (physical or virtual)



Yes, there each JVM has it's own context, and it is good practice to ensure that the context on each JVM is identical (i.e. same context-params, no attributes).
I'm not entirely familiar with the terminology of default context, but I know that a load balancing server is a completely different concept. Load balancing is a feature thrown in by Web App servers, and is usually vendor specific. On Websphere for instance receives all requests, and then redirects the request to the server with the least load. All of this is hidden from the user.

This stuff isn't really applicable to the exam. All you should really know is , the rules you need to follow if you make your app distributable. These rules basically boil down to ensuring your servlet context is consistent across all JVM, that objects bound to a session are serializable, and that you may want to use a HttpSessionActivationListener for informing when the session migrates from JVM to JVM
Rather general question, but here's a start.

A distributable application is an app (for the SCWCD purposes a web-app) which run on multiple servers. Usually the purpose for this is for load-balancing.

Lets say, the app is distributed across two servers A and B (it can be more than 2). In such a situation, the code, config files etc on both these servers would be identical.

When the user makes a request it passes through a load balancing server (physical or virtual) which directs the request to one of these servers.
Which server is chosen is at the discretion of the the load balancing server. This is completely transparent to the user.

What is important however is that whilst the user makes more requests, these requests will not necessarily be directed to the same server.

e.g. request1 -> server A
request2 -> server B
request3 -> server B
request4 -> server B
request5 -> server A
....
etc.

This has important implications for the developer of the web app. If it's a distributed app, the developer has to make sure that the application doesn't rely on servletContext attributes. This is because any attributes added to the servlet context are NOT migrated to the servlet context objects on the other web servers. Also, if the user is using a session, and the next request ends up going to a different server, the session migrates to the other server. This has implications for the objects bound to this session.

Hope that helps

Hello all,
So in short
1.The <body-content> is not mandatory
2. Its default value is JSP
3.But for simple tag its scriptless



1 and 2 are correct.

Simple tags will default to JSP also. But will cause an error, so you'll need to explicitly define it to something else.

Remember the TLD is an xml document. So the rules which apply for the custom tags will also be applied to the simple tags (i.e. same xml doc from the containers point of view).

[ July 03, 2006: Message edited by: Phil Kurian ]
[ July 03, 2006: Message edited by: Phil Kurian ]

For classic tag's, the default value is "JSP".




Whilst true, this is NOT limited to classic tags.

It will default to JSP for simple tags also. which causes an error!

Look at the results I have below:

With the following TLD


I get the following error

org.apache.jasper.JasperException: /simpletag.jsp(9,8) The TLD for the class pk.CharConvSimpleTag specifies an invalid body-content (JSP) for a SimpleTag.

It's quite clear That if you are using simple tags you MUST specify a body-content which is something other that JSP, as the tld will automatically default to JSP if not specified (which causes an error)
I agree with Santou

Whilst most companies will use a framework of some sorts, it is invaluable to learn the underlying mechanisms which drive these frameworks - namely servlets, jsp, javabeans and design patterns.

Frameworks are primarily there to take the tedious work out of creating web apps, and to enforce them into a reputable design pattern e.g. MVC.

It's good to know how to use them - and it's good to also know how to use data mappers (e.g. hibernate, ibatis etc). but you'll find your skill in using them and ability troubleshooting bugs will increase massively if you understand the stuff in the SCWCD.

Not to mention, frameworks always seem to cycle though the flavour of the month syndrome - one month the hot technology is struts, then it's JSF, then it's tapestry, then it's back to JSF ....... At the end of the day, they're still all based on J2EE and the stuff in the SCWCD.
Sorry I have to disagree with these answers.

According to the Specification <body-content> is NOT mandatory and it does default to JSP.

The xml definition is as follows

<!ELEMENT tag
(name, tag-class, tei-class?,
body-content?, display-name?, small-icon?, large-icon?,
description?, variable*, attribute*, example?) >

Which indicates that body-content can occur 0 or 1 times (i.e. the (?)).

If body-content is left out then it will default to JSP.

Note that it is pseudo-mandatory for simple tags. This is because simpletags cannot have scripts in the body content, so JSP is not a valid option. Hence if using tag files, the deployer must not rely on the default value of JSP. The deployer must specify a value for <body-content> namely "tagdependent" or scriptless.

On examining the specification docs, it appears there isn't even a defined term for "scriptless". It appears to be just a convention used for overriding JSP.
[ July 02, 2006: Message edited by: Phil Kurian ]
To extend on what Gaurav said,

A javax.servlet.Servlet is the basic interface for writing Servlets.

javax.servlet.GenericServlet is an implementation of this interface.

javax.servlet.http.HttpServlet is a sub-interface of javax.servlet.Servlet. It adds a few http specific methods such as doGet, doPost.

Also, an additional service method has been added which recieves a HttpServlet Request and HttpServletResponse. This method examines the request and determines its form (i.e. get post head etc) and calls the relevant http servlet method (i.e. doGet, doPost etc).

Similar to what Gaurav said. A http servlet is just a servlet with some added functionality for use with the http protocol.
I haven't tried this out for myself, but let's not forget here that these listener objects run as threads.

If you remember back to when you did you SCJP exam, there is little that can be said about the ordering of threads without synchronization.

Therefore if an attribute is replaced by a new binding object, the result could be unpredictable.

Whilst the valueUnbound may be triggered on the replaced object before the valueBound on the replacement object, it may not be printed in that order. As the valueBound method may get scheduled before the valueUnbound method. That will depend on the thread scheduler.

I will have to verify this for myself, so I urge you to investigate this also, in the chance that I may be wrong.
You'll get that error in Tomcat. Make your class public.

default accessibility will not work.

good luck
Thanks,

I actually tried reading the bytes in one by one and it all made sense.

cheers
Hi All,

Not sure if it's just my naivity (stupidity or whatever) but I am having a bit of a drama reading the database file provided.

I attempted to browse through it using a text editor so I could get an idea of the format. However wordpad and notepad fails to recognise a lot of the characters - particularly in the header. I had similar problems when I tried viewing it in vi on linux. (e.g. first line of header looks something like this:

^@^@^B^B^@^@^@F^@^Dname etc)

Is this normal? Will it make more sense when a java program reads the bytes in? Do I need to change the character encoding or something... or do I have a corrupted file?
Sorry, I agree with Enthuware.

The program will not compile.

I don't know how you got yours to work, but when I test it out, the program fails to compile. It complains about trying to access a protected member.

Please check that you are doing the following:

1)You have declared variable i in A.java as protected.

2)A.java and B.java are separate files.

3)You have declared the package statements correctly. (if they're both in the same package then the code will compile fine).

4) You have the correct directory structure

*
|
*-p1
| |
| A.class
|
*-p2
| |
| B.class

The answer is (It won't compile) because although i has protected accessibility, it still cannot access the protected variable by referencing the parent class. It can only access the protected variable through inheritance.

So in the class B. the statement B.i = 10; is perfectly legal because B inherits i (protected accessibility)

However in the class B, the statement A.i = 10; is illegal because i is not visible to ALL classes outside the package. (protected accessibility only allows the subclass in another package to inherit the member - it does not make the protected member in the superclass visible to classes outside the package, regardless of whether they are subclasses or not).

Consequently the statement super.i = 10 would also be illegal from class B.

If you want to get a better explanation of this, I recommend K.S and B.B. It describes this concept of protected accessibility really well. (Chapter 1 or 2 I think)

Good luck
[ April 03, 2006: Message edited by: Phil Kurian ]