[Knut Erik Ballestad]

In some situations the JSP editor does not understand import of a Java type, like e.g:

<%@ page import="my.pkg.Class" %>

– the name of the class is underlined in red.
– the class DOES EXIST in the project classpath
– other classes in the same package imports just fine

If I instead of using imports on this class uses fully qualified class name, everything works OK:

my.pkg.Class myInstance = new my.pkg.Class();

I am using Eclipse 3.1M6 and MyeclipseIDE 3.8.4beta on Sun JDK 1.5.0, but I have also observed the problem om Eclipse 3.0.1 + Myeclipse 3.8.4 + JDK 1.5.0. I have not tested other configurations.

[Riyad Kalla]

Well this would certainly be a bug if we can find a reproducable case. I have no run across this before. Is there anything odd about the class? Is it from another project?

[Knut Erik Ballestad]

@support-rkalla wrote:

Well this would certainly be a bug if we can find a reproducable case. I have no run across this before. Is there anything odd about the class? Is it from another project?

Well, not exactly anything odd, but here is how it is used in my setting:
– I use an ant script (using middlegen) that reads my database metadata to generate a Hibernate mapping. The generated hibernate source output folder is set up as one out of totally three eclipse source folders for this project. This makes the Java compiler etc recognize the class as expected.
– I use the hibernate objects directly in my web pages. In the JSP editor, the first import statement is not accepted, but all other import statements, including ones importing from the same package works OK.
– If I does a cut – save – paste at another position, the editor still marks the same import in red.

If I right-click ‘Myeclipse – Run Validation’, I get this response:

Validation of resource /mywebapp/MyPage.jsp is complete.

The only strange thing I can find is that the MyEclipse context meny lists four choices:

Run Validation
Remove all validation markers
Run Validation
Remove all validation markers

[Riyad Kalla]

– I use an ant script (using middlegen) that reads my database metadata to generate a Hibernate mapping. The generated hibernate source output folder is set up as one out of totally three eclipse source folders for this project. This makes the Java compiler etc recognize the class as expected.

Are you manually refreshing your proejct after running your Ant script AND do you have Project > Build Automatically selected? Any external process (almost always Ant scripts) that generate files require the project to be refreshed so the changed files can be recognized by Eclipse, which does not use an automatic polling model like NetBeans to detect changes in the FS.

[Knut Erik Ballestad]

Are you manually refreshing your proejct after running your Ant script AND do you have Project > Build Automatically selected? Any external process (almost always Ant scripts) that generate files require the project to be refreshed so the changed files can be recognized by Eclipse, which does not use an automatic polling model like NetBeans to detect changes in the FS.

Yes, I refresh my project manually, and build automatically is selected.

The problem does not go away even if I perform a ‘Project – clean’, restarts Eclipse, or both.

[Riyad Kalla]

Is there anyway you can send me this project? File > Export > To ZIP, support@genuitec.com ATTN Riyad? I really want to figure out what is going on here…

[Knut Erik Ballestad]

OK, exporting to file system now.
Will zip it up and send it to you ASAP.

[Knut Erik Ballestad]

@support-rkalla wrote:

Is there anyway you can send me this project? File > Export > To ZIP, support@genuitec.com ATTN Riyad? I really want to figure out what is going on here…

Did you figure out anything from my project contents?

Update:
On Eclipse 3.1M7 + ME3.8.4forM7 I do not get into this problem – but another one has shown it’s face instead 🙂

Now I do not get any ‘faulty’ indications of compiler errors, but instead I do not get any compiler error markings at all!
– If i Import a non-existing class, no errors are shown in the JSP editor.

[Riyad Kalla]

Now I do not get any ‘faulty’ indications of compiler errors, but instead I do not get any compiler error markings at all!
– If i Import a non-existing class, no errors are shown in the JSP editor.

This is a known problem, we will have it fixed in M2.

Did you figure out anything from my project contents?

I tried a few times to login and get the resources and was unable to. I am glad to hear the error was fixed however.

[Knut Erik Ballestad]

Still some strange stuff happening in ME3.8.4 for M7:

E.g. that I have a JSP taglib with a tag that behaves very much like <bean:define in the standard Struts tag library, except that I have added some behaviour of my own.

When Using

<bean:define id="test">ABCDEFGHIJK</bean:define>

to define a String variable, and then displaying it’s content like this in the JSP:

test=<%=test%>

everything works as expected.

If I define the variable using my taglib

<mytaglib:define id="test" otherParams......>ABCDEFGHIJK</bean:define>

to define a String variable it works OK, and my tag code is executed OK
If I then try to display the defined content like this in the JSP:

test=<%=test%>

I get this error message in the console:

An error occurred at line: 19 in the jsp file: /MyJsp.jsp
Generated servlet error:
test cannot be resolved

Shouldn’t the JSP editor warn me if I try to use variables that cannot be resolved?

Strange2:

<bean:write name="test" scope="page"/>

…writes out the variable OK.

The page variable is defined just as inside of Struts bean:define

pageContext.setAttribute("test", "value", PageContext.PAGE_SCOPE);

[Riyad Kalla]

Shouldn’t the JSP editor warn me if I try to use variables that cannot be resolved?

Yes, this is a known bug with M7 that compiler errors are not being shown.

[Knut Erik Ballestad]

If I define a bean for use in my JSP page like this:

<jsp:useBean id="myBean class="mypkg.MyClass"/>

I can then add JSP code like this:

<% myBean.setValue("abc");

and it will work just fine.

The issue is that content assist doesn’t recognize that I have defined an instance of MyClass.
If I instead define the myBean instance like this:

<% mypkg.MyClass myBean = new mypkg.MyClass();%>

content assist works as expected.

[Riyad Kalla]

Correct, most autocomplete for beans defined with jsp:useBean are special-case autocomplete that KNOWS that useBean defines a bean, in our case our autocomplete is more general and relies on real-time analysis… consider a taglib like Struts bean taglib, you and I know it does somethign very similar to jsp:useBean, but no IDEs know what it does, so you won’t get autocomplete for it’s beans… same goes for JSTL core tags… basically there is no way to know what a taglib is doing, and we have no put in place the special-case of recognizing the jsp:useBean tag and allowing autocomplete for it, but this is a filed enhancement we may look into in the future.

[Knut Erik Ballestad]

@support-rkalla wrote:

Correct, most autocomplete for beans defined with jsp:useBean are special-case autocomplete that KNOWS that useBean defines a bean, in our case our autocomplete is more general and relies on real-time analysis… consider a taglib like Struts bean taglib, you and I know it does somethign very similar to jsp:useBean, but no IDEs know what it does, so you won’t get autocomplete for it’s beans… same goes for JSTL core tags… basically there is no way to know what a taglib is doing, and we have no put in place the special-case of recognizing the jsp:useBean tag and allowing autocomplete for it, but this is a filed enhancement we may look into in the future.

OK, but couldn’t you just “behind the scenes” insert the actual java code that the taglib consists of, and base the autocomplete functionality on that?

– This would at least work for all taglibs that you have source code for, which for most proactical purposes would be more than good enough.

I guess you wouldn’t even need the source code, as long as the java classes are compiled with debug info in them, to achieve this?

[Author]

Posts