JSTL help

i'm trying to setup the jakarta jstl libraries with idea and am having some trouble. I can't seem to get idea to resolve the tag libraries.

I have c:\<cataline-home>\webapps\myapp\WEB-INF\jslt.jar with all the other jars and .tld files.

I then tried to setup an external resource in idea to

URI = http://java.sun.com/jsp/jstl/core
path = C:/apache-tomcat/webapps/myapp/WEB-INF/lib/c.tld

I've never used jstl, but i was able to use the struts libraries with ides 3.x.

so what is my (probably newbie) mistake with jslt??

0
6 comments

Hi Charles,

I'm using JSTL, too, and it is working quiet fine.

From what you write I can't tell what the exact problem is, just as a minor tweak try putting the .tld directly into WEB-INF, but the jars into WEB-INF/lib.
Additionally my external resources URI is http://java.sun.com/jstl/core, so could you please check it back with the URI defined in your c.tld?

Anyway, if you could give some more information it would be helpful.

Robert

0

I got it now. The problem wast that we keep all source in a different directory, not under jsp container. Then the ant process copies the jsp to the correct location (I didn't do this, it was like this when I started working here).

Anyway if I open the .jsp file under my src/ dir it can not resolve them.

If I open the .jsp that is under the webapps/ dir then it resolves them fine.

Thanks for letting me know that it could be done, kind of gave me hope to keep trying :)



0

I am facing the same situation and I filed a bug report early last week on
this (Taglibs not resolving). Like yourself, I came onto a project that
laid out the source code directories in a similar manner. Our source JSPs
are stored in one location and Ant copies them to a different location
(under the container) during a build.

To test your theory, I added a new content folder to my project for the JSPs
located in the container (ie. Weblogic). These are the ones placed here by
Ant. Sur enough, the tags resolved.

This is still a problem. I can't go edit the JSPs under the container for
the sake of getting the tags resolved. They will be overwritten during each
build. Yes, I could be careful and copy and paste to the true source JSPs,
but this is looking for trouble. All it takes is one time to forget to copy
and paste and my changes are lost.

What I didn't understand was that I enabled web app support and pointed to
the web app directory in the container. It would seem that Idea would be
able to find the tags since I am telling it where to look. Why it cares
where my JSP is located is beyond my knowledge. Maybe it is looking for the
tags in a directory relative to the JSP. But if that's the case, why then
am I specifying the web app directory in Project Properties? It's almost as
if we are supposed to store our JSPs in the runtime deployment structure.

I'm not sure if they will close the bug report as a non-issue and there is
no problem. I hope not. Resolving tags is a great feature that we now cant
benefit from. It also goes further than that. My JSPs are now littered with
false red "errors" in the gutter. I can't spot true problems at a glance.
I can't press Ctrl-P to see the attributes available to the tags. None of
it.

Anyone else have suggestions on this?




"charles decroes" <spam@decroes.com> wrote in message
news:26100357.1059654337713.JavaMail.javamailuser@localhost...

I got it now. The problem wast that we keep all source in a different

directory, not under jsp container. Then the ant process copies the jsp to
the correct location (I didn't do this, it was like this when I started
working here).
>

Anyway if I open the .jsp file under my src/ dir it can not resolve them.

>

If I open the .jsp that is under the webapps/ dir then it resolves them

fine.
>

Thanks for letting me know that it could be done, kind of gave me hope to

keep trying :)
>
>
>
>


0

i was just going to reverse my ant copy to have it copy from the output to the source directory. I have another weird issue. My tag resolves fine but my does not. The both work from the container though. Here is an example see if anyone notices what i'm doing wrong. <%@ taglib prefix="c_rt" uri="http://java.sun.com/jstl/core_rt" %> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %> ]]>

if i change it to a regular c:forEach and lose the <%= idea resolves it fine.

0

I dont use the Sun URIs. I use this, and it works fine.

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

But it still doesn't resolve. Reversing the Ant copy? (still laughing).
Yes, a hack indeed. And dangerous. If you work in a team environment and
maybe some folks start making mods to what they think is the true source
location, you will be stomping on each other's changes.


Hell, I tried specifying the full path:

<%@ taglib
uri="/bea/wlserver6.1/config/DTVDOMAIN/applications/DTVAPP/WEB-INF/struts-ht
ml.tld" prefix="html" %>

I think this is even a worse hack. It's plain stupid. Now you're stuck on
partcular app server. Migrate or upgrade and you're screwed.

This is such a pain in the ass situation. Very frustrating.



"charles decroes" <spam@decroes.com> wrote in message
news:5225780.1059682360160.JavaMail.javamailuser@localhost...

<hack>

>

i was just going to reverse my ant copy to have it copy from the output to

the source directory.
>

</hack>

>

I have another weird issue.

>

My <c:forEach> tag resolves fine but my <c_rt:forEach> does not. The both

work from the container though. Here is an example see if anyone notices
what i'm doing wrong.
>
>

<%@ taglib prefix="c_rt" uri="http://java.sun.com/jstl/core_rt" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>

>

<c_rt:forEach items='<%=pageBean.getAllExternalContacts() %>'

var="contact">
>

if i change it to a regular c:forEach and lose the <%= idea resolves it

fine.


0

the only reason the ant thing may work for me is that i would make the change only on my machine. So it would only affect my sandbox (we don't share sandboxes). I could then do checkins and be ok.

It's a pretty bad kludge, I haven't done it yet, i'm just ignoring idea's red text

0

Please sign in to leave a comment.