- This topic has 11 replies, 4 voices, and was last updated 20 years, 5 months ago by Riyad Kalla.
-
AuthorPosts
-
javachangMemberHi,
I am using Eclipse3.0 and myEclipse 3.8.
when I load my JSP files, I got compile “cannot load class…” error. but the class is in current project and other developers work fine with it (they use myEclipse2.6), after input <%@ page language=”java” %> in the first line, most of compile errors were gone. but still some of current class cannot be loaded. myEclipse2.6 works fine with same code.I got another problem, after loading my code from CVS, some projects name is inserted a “>”, for example, my project name is “ApplicationWeb”, but right now the name is “>ApplicationWeb” and no error message for the project.
thanks
John
Riyad KallaMemberJohn,
The > in the name is a CVS annotation provided by Eclipse to show outgoing changes. You can turn this off via Window > Preferneces > Workbench > Label Decorations > CVS (checkbox)As for the “cannot load class”, what is the entire error message? Where is this class located in your project? What is your src dir for this project? What is your output dir for this project?
lbmMemberHi rkalla,
I was looking for a solution, because I got the same problem with the same setup (Eclipse 3.0 and MyEclipse Build id: 200407091200-3.8-Beta2). That’s how i git here.
On each jsp page, the first taglib line like
<%@ taglib uri=”http://jakarta.apache.org/struts/tags-bean” prefix=”bean” %>is marked as problem. The line above eg. creates this problem:
cannot load class: org.apache.struts.taglib.bean.CookieTeithe tld files are all available in the “WEB-INF” folder…
the class is part of the struts package wich is in my WEB-INF/lib folder (and of course included in the Java Build Path)
On an other machine with same set-up there’s no problem… (??)
Riyad KallaMemberEclipse 3.0 and MyEclipse Build id: 200407091200-3.8-Beta2
What is the Build ID of Eclipse 3?
the tld files are all available in the “WEB-INF” folder…
This is not necessary as Struts provides the TLDs to ME and the app server in its META-INF directory in the struts.jar file.
Do you have any web.xml entries for the struts taglibs?
Also is this the version of Struts that shipped with ME (1.1) or is this a nightly build of 1.2 from the Struts site? I ask because the URIs completely changed between the two releases.
lbmMemberHi Riyard,
The Eclipse Build id is: 200406251208
Just for the fun of it, I deleted the tld’s in the lib folder, but the behaviour is still the same.
There are no Struts tlds defined in the web xml.
I am working with the Struts 1.1 release.
Thanks, Thorsten
Riyad KallaMemberOk your Eclipse 3 build ID is right, your Struts release is right and removing the TLDs is right… this sounds silly but can you do the following:
1) Double check that struts.jar is in your Java Build Path and in your WEB-INF/lib folder
2) Find the struts.jar listed in your project and expand it such that you can find the “org.apache.struts.taglib.bean.CookieTei” class
3) In your Java Build Path, do you have the J2EE 1.3 Library Set added to your build path OR do you have the servlet-api.jar and jsp-api.jar files from Tomcat added individually?What app server are you deploying too?
kitmMember@support-rkalla wrote:
@lbm wrote:
the tld files are all available in the “WEB-INF” folder…
This is not necessary as Struts provides the TLDs to ME and the app server in its META-INF directory in the struts.jar file.
Do you have any web.xml entries for the struts taglibs?
Riyad,
This seems to me to mean that a struts project should not have any of the struts*.tld files in it’s <docroot>/WEB-INF directory and should not have any <taglib/> entries in it’s web.xml and then the jsps will resolve their “<%@ taglib…” entries to those in the struts.jar. When I try this, all my jsps come up with errors.
However, I just noticed that that lbm’s jsp has
<%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean" %>
whereas my jsps have
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
I tried changing my uri to /META-INF… and META-INF… and just struts-bean.tld, but no luck. Exactly what should be in my “<%@ taglib uri=…” so that ME and my app server will resolve to the tld files that are in the struts.jar and I don’t have to include them in my app’s WEB-INF dir? I don’t imagine I want an http reference to an actual web domain (jakarta.apache.org) but something that resolves locally.
Thanks,
-Kit
Riyad KallaMemberKit, I think the problem here is confusion with what the URI parameter does…
You are correct with your first statement, no TLDs or <taglib> entries needed *because* struts.jar contains the TLDs in its META-INF dir AND because the TLD’s themselves define a default URI for the taglibs. The URI is a universal resource identifier… its exactly that, just a unique ID. If you decided to add taglib entries to your web.xml file that mapped the struts-html.tld library to the URI “hamsandwich” then in your JSP pages you would have:
<%@ taglib uri=”hamsandwich” prefix=”bean” />Keeping that in mind, the value for URI that you want to use in your pages is the default URI that the TLD files define in the struts.jar/META-INF/tlds directory. If you are infact running Struts 1.1, then the URIs are as follow:
http://jakarta.apache.org/struts/tags-bean
http://jakarta.apache.org/struts/tags-html
http://jakarta.apache.org/struts/tags-logic
http://jakarta.apache.org/struts/tags-nested
http://jakarta.apache.org/struts/tags-template
http://jakarta.apache.org/struts/tags-tilesThese are the URIs you should/can use in your JSP pages, and of course use whatever prefix you like.
If this doesn’t work, open up your struts.jar/META-INF/tlds directory and open up the file, the top of them will look something like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd"> <taglib> <tlibversion>1.0</tlibversion> <jspversion>1.1</jspversion> <shortname>tiles</shortname> <uri>http://jakarta.apache.org/struts/tags-tiles</uri>
Notice the last line, that’s the default URI. If you are using an nightly build of 1.2 or a release of 1.2, this URI will likely be something like:
http://struts.apache.org/tags….Since they changed the URIs for the newer builds (after they become a top-level apache project).
Let me know if that worked.
kitmMemberRiyad,
You ROCK! That worked like a charm. And thanks for the URI lesson. I think I was assuming it was like resolving the URL for a DTD in a DOCTYPE reference (which, IIRC actually *do* pull from a public URL if defined with one – or are those also resolved based on a locally mapped directory and I’m completely out in left field?). So, is the TLD’s URI resolved using JNDI? I guess I’m still not clear on the exact mechanism of pairing up the default <uri/> in the TLD file with the uri=”…” in the <%@ taglib … %> entry in the JSP.
I was hesitant to submit this because I knew I could (and maybe should) have dug up the answer in the Sun taglib docs or some similar forum, but I was hoping you would save me the time and aggravation. And you came through without even spanking me for being lazy and hitting you up with a general J2EE question! 😀
I’ve now cleaned up the WEB-INF and web.xml for both of my projects. I love simplifying things!
Thanks!
-Kit
Riyad KallaMemberYou ROCK! That worked like a charm.
Awesome, now you are back in action.
I think I was assuming it was like resolving the URL for a DTD in a DOCTYPE reference (which, IIRC actually *do* pull from a public URL if defined with one – or are those also resolved based on a locally mapped directory and I’m completely out in left field?).
Yes you are right, DOCTYPE references actually point to the file used to validate the document, so the parser has to “go get it” before it validates the document. Some programs (like ME) can use a cache, but the basic idea is the same. But with a URI you are just giving the resource an ID, how its loaded and where it is found is actually determined by other factors I talk about below (spec-defined).
So, is the TLD’s URI resolved using JNDI? I guess I’m still not clear on the exact mechanism of pairing up the default <uri/> in the TLD file with the uri=”…” in the <%@ taglib … %> entry in the JSP.
Good question, its not JNDI (something different, another one of the 200 acronyms we get to learn as developers) but just a straight name mapping. Basically the web app spec says “Ok, you need to give all tag libraries unique identifiers”, so we do… in Struts case they provide unique ones for you that happen to be based on their web address, then the spec says “Ok now an application server that is hosting that tag library must create a mapping between the unique identifier and the actual library by either a) looking in the web.xml file for <taglib> entries telling us what mappings to create or by b) looking in the JAR files and using the default URIs from the tag libraries”
So now we have the spec telling us 1) That we need to ID the taglibs and 2) Once we do that, we need to load the unique ID to taglib mappings by looking in certain locations…. once all that is done, when the JSP compiler/interpreter comes along and sees a <%@taglib /> entry in a JSP page, it asks the application server “OK, this page wants taglib ‘http://jakarta.apache.org/struts/tags-bean'” and the app server goes and looks in its registry of taglibs and says “Ok, I got it right here” and gives it back to the page.
MyEclipse does something identical to give you autocomplete and validation with the taglibs, we kind of ‘act’ like an application server in that sense and follow what the spec says is valid behavior for finding/using taglibs. That keeps your dev environment nice and in-sycn with your deployment environment.
I’ve now cleaned up the WEB-INF and web.xml for both of my projects. I love simplifying things!
I know exactly what you mean.
I’m glad you are up and running now.
lbmMemberHi!
I habe some kind of given up 🙂
Because the project is still a pretty small prototype I opened a new one and ported the packages to this one. Now everything is ok again.
I think the whole thing came up because of some kind of buildpath problems because I could manually find the needed classes in the struts jars.However, after porting to a new installation (about one hour time; less than trying to fix that
, I as think 😉 ) the whole thing works.Thank you,
Thorsten
Riyad KallaMemberThorsten,
That is very strange that it works now, but I’m happy atleast that you are able to work again. Please come back if something happens. -
AuthorPosts