[Chris Means]

Hi,

I just upgraded to MyEclipse v2.6.2, after upgrading to 2.6.1.

In my web application:

Taglib entries that worked fine in 2.6.0 now give errors:

Kind Status Priority Description Resource In Folder Location
Error bad relative URL in web.xml: taglib-location = http://java.sun.com/jstl/core fast_search.jsp Fastbank ATM Locator/Web Root/tiles line 1

Here’s the URL (which worked fine in 2.6.0):

<%@ taglib uri=”http://java.sun.com/jstl/core&#8221; prefix=”c” %>

It doesn’t complain when I use this:

<%@ taglib uri=”/WEB-INF/c.tld” prefix=”c” %>

But, I rather liked not having to manage the extra .tld files.

I’ve also noticed (this was happening in 2.6.0 as well) that a file that I have in my WEB-INF/classes folder, keeps getting deleted when I perform a rebuild all. The file in question is “client-config.wsdd”. It’s needed for my Axis development, and it belongs in that folder.

Maybe the routines for rebuilding are deleting everything rather than just deleting class files that it has “domain” over.

I have to keep restoring it from CVS, and it’s getting a little tiresome.

Can we get the taglib entry to work as it “should”?

Thanks.

-Chris

[support-michael]

Problem-1: resolving TLD location
The problem appears to be with the the taglib element in your web.xml file. The taglib-location should be relative to your web-app and the TLD must be packaged with your application per the JSP spec, i.e. a jar or source TLD files. Following is an exerpt from our web.xml

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
    <taglib-location>/WEB-INF/c.tld</taglib-location>
  </taglib>

I confirmed that code completion and validation work as required for the above taglib mapping. We test using JSTL, Struts taglibs including the EL version, Webwork, and our own internal samples.

An appropriate JSP taglib directive can be either:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
or 
<%@ taglib prefix="c" uri="/WEB-INF/c.tld" %>

Both of these taglib directives are consistent with the spec and pass our tests. We typically use the former style of TLD directive. A big motivator for releasing 2.6.2 was to fix several outstanding JSP problems with taglib and web.xml reconciliation in which this type of problem was not properly detected and reported. I’m assuming behavior you were seeing in 2.6.0 was most likely a false positive.

Problem-2: Content of WEB-INF/classes deleted on rebuild/build-all
A MyEclipse web project is a special case of Java project in which the project’s output location is mapped to <project>/<webroot>/WEB-INF/classes. So like any Java project the default Eclipse behavior on rebuild/build-all actions is to delete the entire contents of the project’s output location. If you have resource files or other that need to be included into the project’s output location simply place them in your Java source directory at the corresponding directory depth in which they should reside in the output location.

The following link is from a recent thread on this topic: https://www.genuitec.com/forums/topic/web-project-rebuild-deletes-all-from-web-inf-classes-dir/

You can disable this default Eclipse behavior by setting the Java->Compiler->BuildPath preference “Scrub output folders on full build” to false. Be warned that doing this can lead to a an inconsistent output location and should be avoided in most cases.

Let me know if I’m missing something in this explanation and I’ll follow up ASAP.

Regards,

Michael
MyEclipse Support

[Chris Means]

Thanks Michael.

Problem 1:
I was missing the taglib references in my web.xml…though it worked just fine prior to 2.6.2….no matter…I’ll include them and see if that clears things up.

Problem 2:
I’ll move the wsdd into my Java Source folder and see if that fixes things…I understand the problem/issue.

Thanks for your help!

Maybe you have an idea what my newest problem is…I don’t know if it’s related to MyEclipse or not.

Since I’ve done the update to the latest version of Eclipse, I show 4 “repairs/updates” from Eclipse.org for v2.1.1 (which is the version I have). However, even if I perform the installs without error, if I perform another update check, those same four entries show up as needing to be performed. Here’s the list:

Eclipse Java Development Tools
Eclipse Platform
Eclipse Platform (Windows)
Eclipse Project SDK (Windows)

Any idea what’s up with this?

Thanks.

-Chris

[Scott Anderson]

Chris,

Since I’ve done the update to the latest version of Eclipse, I show 4 “repairs/updates” from Eclipse.org for v2.1.1

These warnings in the update manager are normal after installing MyEclipse. We ship mildly modified versions of each of these plugins in order to enable JSP debugging support. The warnings are just Eclipse telling you that the platform is looking for 2.1.1, but it found versions labeled 2.6.2 so it’s using them instead. That’s the behavior that you want. You shouldn’t worry about it or attempt to update them.

–Scott
MyEclipse Support

[Chris Means]

Scott,

OK. But then how will I know there’s a “legit” update/repair I need to apply?

Thanks.

[Scott Anderson]

Eclipse will only put out an update as part of a service release. We keep close tabs on that and will release an MyEclipse version for any new service release quickly.

–Scott
MyEclipse Support

[Chris Means]

Though I can’t say I’m keen on MyEclipse working this way, I guess I’ll have to review the overall benefits and decide what’s best for my needs.

In the meantime, should I stop the Install/Update process from even checking the standard Eclipse.org site? That way I’d avoid seeing updates I couldn’t and shouldn’t appy.

Thanks.

[Scott Anderson]

In the meantime, should I stop the Install/Update process from even checking the standard Eclipse.org site? That way I’d avoid seeing updates I couldn’t and shouldn’t appy.

That would actually be a good solution. Since we build and test MyEclipse for very specific versions of Eclipse (2.1.0 & 2.1.1), you really should not apply any Eclipse updates until we validate any new service builds just to ensure that your production environment is not interrupted by an incompatible modification.

–Scott
MyEclipse Support

[rgardner]

@support wrote:

Problem-1: resolving TLD location
The problem appears to be with the the taglib element in your web.xml file. The taglib-location should be relative to your web-app and the TLD must be packaged with your application per the JSP spec, i.e. a jar or source TLD files. Following is an exerpt from our web.xml

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
    <taglib-location>/WEB-INF/c.tld</taglib-location>
  </taglib>

I haven’t studied the spec, but it appears that this taglib directive is not required if the tld contains a matching uri. Tomcat compiles and executes JSP files correctly even without this taglib directive in web.xml, but the MyEclipse JSP compiler does not.

Like the original poster, I am using the jar files distributed with JSF EA4. Those jar files contain the tld. For example, the file jsf-ri.jar contains the file /META-INF/jsf_core.tld. This tld has in its <taglib> element the subelement <uri>http://java.sun.com/jsf/core</uri&gt;. Judging from the log files, it appears that when Tomcat loads the web app it scans the jar file, finds all the tlds and builds a mapping from the uri specified in the tld. It then maps that uri against the uri specified in the JSP taglib directive.

Anyway, it seems wrong that Tomcat can correctly compile and execute the JSP pages while MyEclipse cannot. And this happens on demo web apps supplied by Sun with JSF EA4.

[support-michael]

You’re correct. We reopened this issue this morning (Wed) after reseaching this topic for a similar forum post.

Micheal
MyEclipse Support

[support-michael]

We have resolved this issue and it will be available in the next service release. As a short term workaround please add explicit <taglib> entries to your web.xml file.

Michael
MyEclipse Support

[Author]

Posts