Stary Kapec

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

Recent posts by Stary Kapec


I am 25 and working in a big company as a junior programmer. I am getting more and more frustrated about my job. All I do is maintenance programming, so my only role is to look for and fix bugs and/or refactoring. The code I work on is old, written in horrible style and totally undocumented. I hardly understand what's going on about it and I have little knowledge about the business of the applications I am to work on.
I've been working in the company for about 4 months. I have more then a year total experience. I'm bachelor in IT and SCJP (95%) I'm about to do SCWCD.
I don't really feel that my knowledge and skills are increasing. Especially I don't work on any cutting edge techs. Just plain old java and old struts.
Every day I struggle myself to get the job done and I hardly succeed. I'm beginning to doubt if I'm suitable to the programmer's job at all.

What do you think? Should I start thinking on leaving the company.. or wait and see, maybe I'll get use to it? I am very well paid.
[ June 30, 2007: Message edited by: Pawel Matczak ]
16 years ago
Hi all,

Could anybody explain me why I get runtime error: Outer$B; no valid constructor
during deserialization?

Singleton object as all objects has state. Static methods can perform only stateless operations as opposed to methods on singleton object.
JSP syntax errors will be detected at translation time, not JAVA syntax errors.
JAVA syntax will be checked by the compiler at compilation.
JSP syntax is checked by container.
It is neither compile nor runtime time. It is translation time error.

You write your jsp and it is the container responsibility to translate the jsp file into java file (servlet source code). It happens before compilation because at this time no source file exist, so there is nothing to compile.

Such translation will fail if there is an error in jsp syntax. Example: you'll forget to end your scriptlet or you'll use some directive that does not exist.
Hi Rancy

Here scripting variable is nothing but the variable declared by the id attribute of useBean action.

Yes I agree and the name of the variable is as the value of an id attribute.

And ofcourse getProperty and setProperty actions use it.

Here I disagree.

In findAttribute method, value of 'id' is used as the parameter to it. This explains why scripting variable is created.

Yes, the value of an id attribute is used, but only the value. The created reference variable plays no role here.

Not only can we use this variable name in getProperty and setProperty but we use it in expressions as well as scriptlets in the JSP page.

Yes, in scriptles the variable can be used. But actions were introduced to avoid using scriptlets. So it is not a real advantage.

In EL expressions still the variable is not used.


In the above example p element points to an attribute not any scripting variable.
Here is what Rancy Chadha wrote:

Type if specified, it defines the type of the scripting variable defined.

It is very clear from specs that type attribute is only for the type of scripting variable which is used to point at the object

What is the reason for the scripting variable? Both jsp:getProperty and jsp:setProperty neither use it but obtain the reference from pageContext.findAttribute invocation.
So why is the new reference (scripting variable) created at all?

When using <jsp:getProperty>, the application server translates <jsp:getProperty> with something like

((Employee) pageContext.getAttribute("p",PageContext.REQUEST_SCOPE)).getName()

Not exactly, findAttribute method is used instead

((Employee) pageContext.findAttribute("p")).getName()
Hi, Thanks for your response...

Below jsp/TestStandardActions.jsp

When I call jsp:getProperty under the hood there is a cast to causing ClassCastException even though I declared the type to So every use of jsp:getProperty inserts a cast to a class declared in the class attribute.

Getting back to your example with two jsp pages.

Suppose the first page did not found a bean in a session scope and created new one an Employeee instance. Next there is request to the second page. The bean was found and was assigned to the reference of type Person. Next jsp:getProperty was invoked according to what I written above ClassCastException would occur (due to cast an Employee instance to Director class). So I still don't see the point of type attribute.

Well... I assumed Director extends directly from Person, and Employee extends from Person too. Maybe wrong. But If Director extended from Employee there would be no need for type attribute neither.

Could you show me your example because I must misunderstand it.
[ May 16, 2007: Message edited by: Jasiek Motyka ]
On the servlet I create and set as a request attribute a new Person object.

In fact in that instance something like below would not work:

<jsp:useBean id="per" class="" scope="request" />

So the type attribute to the rescue:

<jsp:useBean id="per" type="" class="" scope="request" />

But still when I want to get property I get ClassCastException

<jsp:getProperty name="per" property="name" />

So what is the advantage of the type attribute. The object is implicitly cast to Employee

Could you give me a better example?
[ May 15, 2007: Message edited by: Jasiek Motyka ]
Thanks for the response. But I still have doubts.
I know how to use bean standard actions.

But I don't know what is the reason for the fact that useBean action declares bean object (as scripting variable)
There is no way to access that variable but using scripting variables.
Look for the example:

name property comes from
id property comes from

Despite I declared the type for Person the above code still works! So what is the reason for the type attribute? It only affects the type of the scripting variable.
But using scripting variables by scripting elements is bad and was to be eleminated by introducing standard actions.
Here is a snippet of the generated servlet by tomcat:

public final class SimplePage_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {

As you can see the generated servlet extends a class org.apache.jasper.runtime.HttpJspBase.

It is a tomcat specific class that we should not care about as long as it implements javax.servlet.jsp.HttpJspPage and it is the class that is overriding void servlet(HttpServletRequest, HttpServletResponse) method so it invokes _jspService()

Here is link to the class implementation:

See how the service method is implemented it is very trivial:

94 public final void service(HttpServletRequest request, HttpServletResponse response)
95 throws ServletException, IOException
96 {
97 _jspService(request, response);
98 }
[ May 12, 2007: Message edited by: Jasiek Motyka ]

I far as I understand standard action were introduced to avoid scripting elements.

UseBean action declares and initializes scripting variable but what for? There is no way to access the variable but using scriptlets or scripting expressions.

Another doubt. I know there are also getProperty and setProperty actions that operate on the declared bean but on the low level I do not clearly understand how they work.
jsp:getProperty for example uses findAttribute so
it actually operates on an attribute, not on a scripting variable so for example something like this should work in my opinion but it doesn't, Why?:

Person p = new Person(); p.setName("jasiu");
pageContext.setAttribute("ppp", p, PageContext.SESSION_SCOPE);
<jsp:getProperty name="ppp" property="name" />
[ May 12, 2007: Message edited by: Jasiek Motyka ]
Cracow, Poland

17 years ago
class A {}
class B extends A {}
class C { B b; }

C has-a B, but my doubt is if C has-a A is also true, because B extends A