Tag Files seem to block TagSupport.findAncestorWithClass

Seems I stumbled upon a rather glaring hole in with JSP 2.0 Tag Files.
Say that I have normal JSP tags like this:
<x:outer ... >
    <x:inner .../>
    <x:inner .../>
    <x:inner .../>
</x:outer>outer and inner are related, and the inner tag "talks" to its parent tag using TagSupport.findAncestorWithClass.
If I wanted, I could use JSTL tags to do something like:
<x:outer ...>
    <c:forEach begin="1" end="3">
        <x:inner .../>
    <c:/forEach>
</x:outer>In this case, the inner tag would still be able to "see" the outer tag, skipping the forEach tag.
However if I have a tag file that wraps the inner tag:
<%@tag description="my inner tag wrapper"%>
<x:inner ... />and then:
<x:outer ...>
    <mytag:myinner ... />
</x:outer>The inner tag can no longer "see" the outer tag. When inner tag calls getParent, it just gets null.
Is that supposed to work that way?
One of the great things about Tag Files is that it lets you so easily create your own tags, and in cases like this, lets you default a bunch of boiler plate to make using other tags easier.
Any hints as to a possible workaround for this?

Alright, I did it the unorthodox way.
I found out that the JSP is unable to read the WEB-INF directory some some apparent reason and thus is unable to look up the TLD file. Tried loading the ResponseOverrideFilter for displaytag and I saw the Log4J logs being generated, so for sure the JARs are being loaded and working fine.
I placed the TLDs into the same directory as the JSPs and viola! My taglibs are all working.
It's not much of a solution, but at least for the moment I can get my work done and generate my tables for export on the JSPs.
I'm still puzzled to why it's inability to pick up the TLDs although it's already existing in the JAR(s), and WEB-INF and now I've to spoil it totally by placing a copy in the JSP directory.
It was trying to look for /projectroot/WEB-INF/c.tld whereby my WEB-INF is on the same level as projectroot.
Just did a <%@ taglib uri="c.tld" prefix="c" %>
<%@ taglib uri="displaytag-11.tld" prefix="display" %>And now the tags are fine.
I'm still looking for an explanation and guides to why this is happening to my SOWS. I've no idea who was the bright spark that earlier configured the system this way.
All I can look forward to is to rearchitect the design and redo this application to v2 on Hibernate 3 and JSF/AJAX.
regards,
Michael

Similar Messages

How to properly handle Exception thrown in a .tag file?

I've got a .jsp file that makes use of some custom tags, each defined in their own .tag file, and located in WEB-INF/tags. I'm having a lot of trouble with the scenario of cleanly dealing with an exception raised by scriptlets in either a .jsp file, and a .tag file. I'm using both Java and Tomcat 6....
Originally, I wanted to use .tag files in order to componentize common elements that were present in .jsp pages, as well as move ugly scriptlets out of .jsp pages, and isolate them in tag files with their associated page elements.
Things started getting hairy when I started exploring what happens when an exception is thrown (bought not handled) in a scriptlet in a .tag file. Basically, my app is a servlet that forwards the user to various .jsp pages based on given request parameters. The forwarding to the relevant .jsp page is done by calls to the following method:
servletContext.getRequestDispatcher("/" + pageName).forward(request, response);
Where 'pageName' is a String with the name of the .jsp I want to go to...
Calls to this method are enclosed in a try block, as it throws both a ServletException, and IOException...
When either my .jsp, or .tag throw an exception in a scriptlet, the exception is wrapped in a JSPException, which is then wrapped in a ServletException.
I can catch this exception in my servlet... but then what? I want to forward to an error page, however, in the catch block, I can't forward in response to this exception, as that results in an IllegalStateException, as the response has already been committed. So what do I do? How do I get from this point, to my "error.jsp" page?
It was suggested to me that I use the <% @ page isErrorPage="true" %> directive in my error.jsp,
and the in my real .jsp, use <%page errorPage="/error.jsp" %>.
This works great when the exception is thrown in my .jsp.... But when the exception is thrown in the .tag file... not so much...
My .jsp page was rendered up until the point where the <my:mytag/> (the tag with the offending raised exception) was encountered. Then, instead of forwarding to the error page when the error in the tag is encountered, the error page is rendered as the CONTENT of of my TAG. The rest of the .jsp is then NEVER rendered. I checked the page source, and there is no markup from the original .jsp that lay below the my tag. So this doesn't work at all. I don't want to render the error page WITHIN the half of the .jsp that did render... Why doesn't it take me away from the .jsp with the offending tag altogether and bring me to the error.jsp?
Then it was suggested to me that I get rid of those page directives, and instead define error handling in the web.xml using the following construct:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/error</location>
</error-page>
For this, I created a new servlet called ErrorServlet, and mapped it to /error
Now I could mangle the end of the URL, which causes a 404, and I get redirected to the ErrorServlet. Yay.
However, exceptions being thrown in either a .jsp or .tag still don't direct me to the ErrorServlet. Apparently this error handling mechanism doesn't work for .jsp pages reached via servletContext.getRequestDispatcher("/" + pageName).forward(request, response) ????
So I'm just at a total loss now. I know the short answer is "don't throw exceptions in a .jsp or .tag" but frankly, that seems a pretty weak answer that doesn't really address my problem... I mean, it would really be nice to have some kind of exception handler for runtime exceptions thrown in a scriptlet in .tag file, that allows me to forward to a page with detailed stacktrace output, etc, if anything for debugging purposes during development...
If anyone has a few cents to spare on this, I'd be ever so grateful..
Thanks!!
Jeff

What causes the exception?
What sort of exception are you raising from the tag files?
Have you got an example of a tag file that you can share, and a jsp that invokes it so people can duplicate the issue without thinking too much / spending too much time?
My first instinct would be that the buffer is being flushed, and response committed before your Exception is raised.
What you describe is pretty much standard functionality for Tomcat in such cases.

JSP 2.x - Tag files with body-content="JSP"

I've been looking at the JSP 2.1 draft and see that, as with the previous JSP release, it is not allowed for tag-files to have body-content="JSP". I've tried to find a good answer for that on the web, but there's no one who can enlighten me. I've tried to tweak the source of Apache Tomcat 6.0.13 (Validator.ValidateVisitor and TagFileProcessor.TagFileDirectiveVisitor, both in org.apache.jasper.compiler) to accept body-content="JSP" in tag files - with great success. It is possible to have scriptlets within tags from tag files and it works as expected.
My reason for wanting scriptlets in the body-content of tags from tag files is that it would encourage a more contextual, nested (and in my eyes, a more beautiful) structure of JSP-pages, as opposed to the JSTL flat structure, where f.ex. the sql:query tag does not reside within a sql:setDataSource tag, but instead refers to the datasource through an EL-variable. I suppose that it has been constructed in this way only to make it possible for programmers to include scriptlets in-between sql:query tags that use the same datasource.
Not that it is not possible to nest tag-file tags, but I suspect that many programmers then would like to keep a flat structure so as to maintain the possibility of inserting scriptlets where needed - outside any tag which is based on a tag-file.
So, why is it not allowed for tag-files to have body-content="JSP"?

Thanks for the reply, evnafets.
I'm aware that scriptet-code is generally being discouraged, although I don't understand why. I think that having a standard tag-library is a wonderful idea, but in the case of JSTL, I'm not that pleased. It relies heavily on EL, which I see as an unnecessary abstraction.
Let me give you an example. The JSTL does database-connections and queries in this way:
<sql:setDataSource var="datasource" url="jdbc:oracle:thin:@localhost:1521:TEMP" driver="oracle.jdbc.OracleDriver" user="scott" password="tiger" />
<sql:query sql="SELECT * FROM EMP" dataSource="datasource" var="resultset" />This could also be accomplished without EL in a hierarchical structure:
<sql:dataSource url="jdbc:oracle:thin:@localhost:1521:TEMP" driver="oracle.jdbc.OracleDriver" user="scott" password="tiger">
<sql:query sql="SELECT * FROM EMP">
BodyContent <% perhapsWithScriptlets; %>
</sql:query>
</sql:dataSource>...using TagSupport.findAncestorWithClass for the query to reference the datasource which it is enclosed in. (in Tomcat, the class would be called dataSource_tag. BTW, why is this not standardised in JSP?)
I would then also like to be able to use scriptlet-code inside the tags as I could if the tags were written as tag-classes, extending BodyTagSupport, and being defined in a formal, cumbersome TLD file.
Why the difference in functionality between SimpleTagSupport and BodyTagSupport - or rather; why is it then not possible to specify that a tag-file should extend BodyTagSupport rather than SimpleTagSupport?

JSP 2.0 Tag files outputting elements with conditional attributes

It appears to be impossible to conditionally output element-attributes in JSP 2.0 XML Tag files. Here's an example:
Tagfile text.tagx:
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="1.2">
<jsp:directive.attribute name="name" required="true" type="java.lang.String"/>
<jsp:directive.attribute name="id" required="false" type="java.lang.String"/>
<jsp:text>
    <input type="text" name="${name}" id="${id}" />
</jsp:text>
</jsp:root>Seems simple enough. This tag has a name-attribute and an optional id-attribute. But what if I want the id-attribute of the 'input' element not to be outputted when the id-parameter is empty!
It appears there's no elegant way to do this but to revert to CDATA blocks and/or output-escaping. Is this an oversight in the API or am I missing something?
I've also tried the following but it didn't work (in Tomcat anyway):
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="1.2" xmlns:c="http://java.sun.com/jsp/jstl/core">
<jsp:directive.attribute name="name" required="true" type="java.lang.String"/>
<jsp:directive.attribute name="id" required="false" type="java.lang.String"/>
<jsp:text>
    <jsp:element name="input">
      <jsp:attribute name="type" value="text"/>
      <jsp:attribute name="name" value="${name}"/>
      <c:if test="${!empty id}">
        <jsp:body>
          <jsp:attribute name="id" value="${id}"/>
        </jsp:body>
      </c:if>
    </jsp:element>
</jsp:text>
</jsp:root>Any ideas on how to do this?

I wonder why no one has responded to this post!!!! I am trying to do the same thing, to no avial. In XSLT this is how it works, I would have thought JSTL would do the same thing. D'oh!

Spec oversight? Using dynamic-attributes in XML tag files

I have a couple of tagfiles that generate form elements with specific conventions for the 'name' and 'value' attribute. Basically, a data binding framework.
Dynamic attributes are useful because you can delegate all the usual html attributes to the generated HTML form element: SELECT, INPUT, id, class etc.
The usual way to do this is to concatenate all the "pass-through" attributes to a string, and append this string to the element generated:
<input type="hidden" name="foo" ${dynattrs}/>I'm wondering how to do this in a tagfile in XML format (mytag.tagx), since the XML format forbids syntax like in the example above.
jsp:attribute won't help much, if it's nested inside a c:forEach: it won't apply to the right element.

Ran into the same problem with 'optional attributes'. (see post "JSP 2.0 Tag files outputting elements with conditional attributes" http://forum.java.sun.com/thread.jspa?forumID=45&threadID=681033)
Found a solution that is not very elegant but does work and saves you the trouble of reverting to Java Tags. Consider the following tag-file that outputs an html input-tag with conditional attributes:
<?xml version="1.0" encoding="utf-8"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="1.2"
     xmlns:c="http://java.sun.com/jsp/jstl/core">
     <jsp:directive.attribute name="name" required="true" type="java.lang.String"/>
     <jsp:directive.attribute name="id" required="false" type="java.lang.String"/>
     <jsp:directive.attribute name="value" required="false" type="java.lang.String"/>
     <jsp:directive.attribute name="disabled" required="false" type="java.lang.Boolean"/>
     <jsp:directive.attribute name="hint" required="false" type="java.lang.String"/>
     <jsp:directive.attribute name="cssClass" required="false" type="java.lang.String"/>
     <jsp:text><![CDATA[<input type="text" name="]]><c:out value="${name}"/><![CDATA["]]></jsp:text>
     <c:if test="${!empty id}"><![CDATA[ id="]]><c:out value="${id}"/><![CDATA["]]></c:if>
     <c:if test="${!empty cssClass}"><![CDATA[ class="]]><c:out value="${disabled?(cssClass + '-disabled'):cssClass}"/><![CDATA["]]></c:if>
     <c:if test="${disabled}"><![CDATA[ disabled="disabled"]]></c:if>
     <c:choose>
          <c:when test="${!empty value}"><![CDATA[ value="]]><c:out value="${value}"/><![CDATA["]]></c:when>
          <c:when test="${!empty hint}"><![CDATA[ value="]]><c:out value="${hint}"/><![CDATA[" onfocus="if(this.value==']]><c:out value="${hint}"/><![CDATA[')this.value='';"]]></c:when>
     </c:choose>
     <jsp:text><![CDATA[/>]]></jsp:text>
</jsp:root>In answer to your question: Yes, it looks like an oversight. Using the jsp:attribute tag in a c:forEach doesn't work because the attribute is then applied to the forEach tag. You would have to put the attribute-tag inside a jsp:body tag (inside the forEach). Then it would apply not to the forEach tag but to the tag enclosing the forEach. However, this doesn't work either, or at least it doesn't work in Tomcat 5.5. Could be a bug though, JSP 2.0 is still very buggy (for instance, using a tagfile inside another tagfile from the same taglib doesn't seem to work either...)
Anyway, if you ever find a good solution please let me know by posting to this topic!
TIA

Tag files for rendering JSF components

Hi people!
     It is possible to render component JSF using Tag-Files? (WEB-INF/tags).
I am having problems with context, seems that the JSF does not recognize pageContext.
Ex:
My Tag-File
<%@ attribute name="nameproperty" required="true" rtexprvalue="true" %>
<%@ attribute name="size"           required="true" rtexprvalue="true" %>
<h:inputText id="${nameproperty}"      size="#{size}" />
My JSP
<%@ taglib tagdir="/WEB-INF/tags" prefix="mayTags"%>
<f:subview id="id001" >
     <myTags:myText propriedade="name_test" size="30" />
</f:subview>
In this in case that the size always is empty, because it does not recognize the target pageContext, but if I to place the size in the target of request already recognizes.
EX:
<%@ attribute name="nameproperty"      required="true" rtexprvalue="true" %>
<%@ attribute name="size"           required="true" rtexprvalue="true" %>
<c:set var"size" value="${size}" scope="request" >
<h:inputText id="${nameproperty}"      size="#{size}" />
In part it decides my problem, but it causes another error, is that if in my JSP it will have two fields (this is more than common) calling tag-file, there the size placed in request is always of it I finish field.
Ex:
<%@ taglib tagdir="/WEB-INF/tags" prefix="mayTags"%>
<f:subview id="paisMan" >
     <myTags:myText propriedade="name_test" size="30" />
     <myTags:myText propriedade="name_test_2" size="70" />
</f:subview>
In this case all the two inputText would have size 70.
It has some thing that I can make to solve this problem?
Thanks for any help.
Pedro Neves - Brazil

You are right in saying that decoding has nothing to
do with rendering per se.I will go even further than Erik did, and dispute this statement.
Consider that you are generating an <input> tag for a text field. Among other things, you have to generate a "name" attribute. Who decides what to put there? The renderer that actually created the markup.
The "renderer" really does
two completely different things. But both should
nevertheless be separate from the component
implementation itself. You could still have the
renderer doing the decoding part, which arguably would
rarely change, and somehow delegate the actual
rendering to an implementation in a tag file.Whether you implement decoding in a separate class or inside the component, what request parameter name do you look for? It is not reasonable to assume that ALL possible renderers will choose the same parameter name ... hence, decoding and encoding are inextricably linked (the code doing the decoding has to know what kind of markup the code doing the encoding actually created). In JavaServer Faces, the current APIs create that linkage by requiring that the decode and encode be done by the same class (either the component, if you are not delegating, or the renderer if you are).
Craig

.tagx Tag files in Weblogic 9.2

Hi,
          We are trying to run one of our applications deploying it to a Weblogic Server 9.2. We are running into problems, as we use .tagx tag files and they do not seem to be recognized. Our .jsp page tries to invoke them as:
                    <%@ taglib tagdir="/WEB-INF/tags/taglibname/" prefix="taglibname" %>
          <taglibname:tag ...>...</taglibname:tag>
                              We have XML tag files named /WEB-INF/tags/taglibname/tag.tagx files, but still we get:
                    javax.servlet.jsp.JspException: ServletException in '/WEB-INF/jsp/chains/index.jsp': Failed to compile JSP /WEB-INF/jsp/chains/index.jsp
          index.jsp:1:5: No tag library could be found with this URI. Possible causes could be that the URI is incorrect, or that there were errors during parsing of the .tld file.
          <%@ taglib tagdir="/WEB-INF/tags/layout/" prefix="layout" %>
              ^----^
                              If we define a simple .tld file for the tag, the problem shifts, as the tagfile element for tlds does not allow defining attributes, and we zillions of "This attribute is not recognized." messages when trying to use the tags.
          Any ideas? Should we use .tag files instead of .tagx or...?
          Alex

Hi,
          Does this happens if you invoke the tag from a .jspx page?
          I was under the heavy impression that .tagx were to be used by .jspx files, but maybe I am wrong.
          Regards,
          LG

WLS does not handle reusable jar with tag-files?

I want to encapsulate some tag-files in a re-usable jar that can be included in multiple applications. According to all the documentation that I've found what I need to do is create a jar file containing:
META-INF/taglib.tld
META-INF/tags/myTag.tag
where the taglib.tld contains (among other things):
<uri>myTag</uri>
<tag-file>
<name>someName</name>
<path>META-INF/tags/myTag.tag</path>
</tag-file>
Then I am supposed to take that jar file and put it in my web application under WEB-INF/lib,
and in my index.jsp I can refer to <%@taglib prefix="myt" uri="myTag">
However when I do this (on wls 12c) the application seems to deploy ok but when I try to access index.jsp I get:
weblogic.servlet.jsp.CompilationException: Failed to compile JSP /index.jsp
index.jsp:14:4: No tag library could be found with this URI. Possible causes could be that the URI is incorrect, or that there were errors during parsing of the .tld file.
<%@taglib prefix="tags" uri="myt" %>
Related facts:
1. When I deploy these projects in Glassfish it works . as I expected based on the documentation with no errors.
2. If I copy the tag files and tld with no modification directly into the web application as:
<my web app>/WEB-INF/taglib.tld
and <my web app>/META-INF/tags/myTag.tag
then it does work. However, that prevents me from packaging the tag-files as a re-usable jar.
(Facts 1 & 2 seem to imply that the files are correct and that WebLogic is not handling the jar correctly?)
3. I've seen suggestions that there needs to be a <taglib> entry in web.xml. I have tried this and...
- the text I've seen on the web generates an error. It seems to need to be within a <jsp-config> entry in web.xml.
- even with this I still get the same error.
Does anyone have a suggestion for how to get Weblogic to handle tag-files inside a re-usable jar?
Do you have an example jar you can point me to just to see that it works on my system?
Is there some special configuration needed by Weblogic to tell it to handle this construct?
And finally, the error message is saying that one of two things is wrong:
Either:
A) it cannot find the referenced taglib file, or
B) the tld file failed to compile.
Is there any way for me to find out which of these is happening? The error messages in WLS do not seem to give any more info, so I cannot easily distinguish between these possibilities.
Thanks for your assistance.

After 3 days of seeing this error, immediately after posting this request the problem disappeared. Sigh.
So for now this problem is closed. If it comes back I'll re-post.

Ojspc (with JDeveloper 10.1.3.2.0) keeps recompiling .tag files.

I find it takes an extremely long time to compile my web application with 75 .jsp files (14188 non-blank lines) and 24 .tag files (438 non-blank lines). About 24 minutes, in fact. I attribute this to the utility insisting on recompiling each and every .tag file for every .jsp that uses them.
During translation, I see the javac process start up several times, and I inspected the javacXXX temporary file that gets created (it stores the VM arguments for each compilation) whenever Oracle needs to compile a page. Now compilation is supposed to happen after translation, but it still happens repeatedly for the same .tag file. If the .tag file is used in each of the 75 .jsp files, then it gets compiled 75 times! I even tried adding the temporary directory where Oracle outputs its .class files for these .tag files to the compilation classpath, and it didn't have any effect.
I also can't precompile the .tag files in an attempt to force it to use already compiled .tag files, as ojspc doesn't seem to want to translate/compile them on its own (but only as a result of a .jsp that needs them).
Here are the options in my build.xml:
<target name="ojspc">
    <path id="ojspc.classpath">
      <fileset dir="${source.web.path}/WEB-INF/lib">
        <include name="*.jar" />
      </fileset>
      
      <pathelement path="${build.root}/oracle/generatedJava" />
    </path>
    <property name="ojspc.classpath" refid="ojspc.classpath" />
    <mkdir dir="${build.root}/oracle" />
    <mkdir dir="${build.root}/oracle/generatedClass" />
    <mkdir dir="${build.root}/oracle/generatedJava" />
    <oracle:compileJsp verbose="true"
      appRoot="${build.webapp.path}"
      dir="${build.root}/oracle/generatedClass"
      srcDir="${build.root}/oracle/generatedJava"
      addClassPath="${ojspc.classpath}">
      <fileset dir="${build.webapp.path}">
        <include name="**/*.jsp" />
      </fileset>
    </oracle:compileJsp>
</target>There's nothing particularly memorable about the ant output. Everything succeeds. But 24 minutes for 15k lines of JSP sounds pretty ridiculous... this whole endeavor was an attempt to reduce initial page hit lags after deployment, but ..... 24 minutes??? :)
Thanks,
Scott

Marco,
the bug is published and visible in Metalink.
- Select "Document Id" in "Quick find"
- enter the bug number: 4556035
- click "Go"
Bug 4556035 is fixed in JDeveloper 10.1.3.3
It's also included in http://www.oracle.com/technology/products/jdev/htdocs/10.1.3.3/fixlist.htm
Regards,
Didier.

WLS 9.2.2: JSP recompile for every page load with JAR'ed tag files

I have a small custom tag library of three tag files. With the server running in development mode and the tag files in a JAR (included in WEB-INF/lib), the server appears to be doing a JSP recompile on every page load. However, it only compiles on the first page load if the tag files are included in WEB-INF/tags (no JAR). Also, running the server in production mode with the JAR'ed tag files avoids the recompile for every page load.
          Is that how the server should behave?
          For whatever it's worth, I'm also using Eclipse 3.3.2 with WTP and WebLogic Server Tools 1.1.2. The server is running the Sun JVM (1.5_10).

Vikram,
          I went back and created a simple example to test. Below I'm posting the Java source code generated from the two relevant files: index.jsp, and hello.tag.
          __index.java:
          package jsp_servlet;
          import java.io.*;
          import java.util.*;
          import javax.servlet.*;
          import javax.servlet.http.*;
          import javax.servlet.jsp.*;
          import javax.servlet.jsp.tagext.*;
          public final class __index extends weblogic.servlet.jsp.JspBase implements weblogic.servlet.jsp.StaleIndicator {
          private static void _releaseTags(javax.servlet.jsp.tagext.JspTag t) {
          while (t != null) {
          if(t instanceof javax.servlet.jsp.tagext.Tag) {
          javax.servlet.jsp.tagext.Tag tmp = (javax.servlet.jsp.tagext.Tag)t;
          t = ((javax.servlet.jsp.tagext.Tag) t).getParent();
          try {
          tmp.release();
          } catch(Exception ignore) {}
          else {
          t = ((javax.servlet.jsp.tagext.SimpleTag)t).getParent();
          public boolean _isStale(){
          boolean stale = staticIsStale((weblogic.servlet.jsp.StaleChecker) getServletConfig().getServletContext());
          return _stale;
          public static boolean _staticIsStale(weblogic.servlet.jsp.StaleChecker sci) {
          if (sci.isResourceStale("/index.jsp", 1207926672370L ,"9.2.2.0","America/Denver")) return true;
          if (sci.isResourceStale("/null", 1207926783245L ,"9.2.2.0","America/Denver")) return true;
          return false;
          private static void _writeText(javax.servlet.ServletResponse rsp, javax.servlet.jsp.JspWriter out, String block, byte[] blockBytes)
          throws java.io.IOException {
          if (!_WL_ENCODED_BYTES_OK || _hasEncodingChanged(rsp)){
          out.print(block);
          } else {
          ((weblogic.servlet.jsp.ByteWriter)out).write(blockBytes, block);
          private static boolean _hasEncodingChanged(javax.servlet.ServletResponse rsp){
          String encoding = rsp.getCharacterEncoding();
          if ( "ISO-8859-1".equals(encoding) || "Cp1252".equals(encoding) || "ISO8859_1".equals(encoding) || "ASCII".equals(encoding) ){
          return false;
          if (_WL_ORIGINAL_ENCODING.equals(encoding)) {
          return false;
          return true;
          private static boolean WLENCODED_BYTES_OK = true;
          private static final String WLORIGINAL_ENCODING = "ISO-8859-1";
          private static byte[] _getBytes(String block){
          try {
          return block.getBytes(_WL_ORIGINAL_ENCODING);
          } catch (java.io.UnsupportedEncodingException u){
          WLENCODED_BYTES_OK = false;
          return null;
          private final static String wlblock0 ="\n \n<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \n\t\t\"http://www.w3.org/TR/html4/loose.dtd\">\n \n";
          private final static byte[] wlblock0Bytes = getBytes( wl_block0 );
          private final static String wlblock1 =" \n \n\t";
          private final static byte[] wlblock1Bytes = getBytes( wl_block1 );
          private final static String wlblock2 ="\n";
          private final static byte[] wlblock2Bytes = getBytes( wl_block2 );
          private final static String wlblock3 ="\n\n<html>\n<head>\n\t<meta http-equiv=\"Content-Type\" content=\"text/html; charset=ISO-8859-1\" />\n\n\t<title>Tag File Test</title>\n</head>\n<body> \n\t";
          private final static byte[] wlblock3Bytes = getBytes( wl_block3 );
          private final static String wlblock4 ="\n</body>\n</html>";
          private final static byte[] wlblock4Bytes = getBytes( wl_block4 );
          static private javelin.jsp.JspFunctionMapper jspxfnmap = javelin.jsp.JspFunctionMapper.getInstance();
          public void _jspService(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response)
          throws javax.servlet.ServletException, java.io.IOException {
          javax.servlet.ServletConfig config = getServletConfig();
          javax.servlet.ServletContext application = config.getServletContext();
          javax.servlet.jsp.tagext.JspTag _activeTag = null;
          Object page = this;
          javax.servlet.jsp.JspWriter out;
          javax.servlet.jsp.PageContext pageContext = javax.servlet.jsp.JspFactory.getDefaultFactory().getPageContext(this, request, response, null, true , 8192 , true );
          response.setHeader("Content-Type", "text/html; charset=ISO-8859-1");
          out = pageContext.getOut();
          javax.servlet.jsp.JspWriter _originalOut = out;
          javax.servlet.http.HttpSession session = request.getSession( true );
          try {;
          response.setContentType("text/html; charset=ISO-8859-1");
          {_writeText(response, out, _wl_block0, _wl_block0Bytes);}
          {_writeText(response, out, _wl_block1, _wl_block1Bytes);}
          {_writeText(response, out, _wl_block2, _wl_block2Bytes);}
          {_writeText(response, out, _wl_block3, _wl_block3Bytes);}
          jsp_servlet._tags.__hello_tag __tag0 = null ;
          int __result__tag0 = 0 ;
          if (__tag0== null )__tag0 = new jsp_servlet._tags.__hello_tag ();
          __tag0.setJspContext(pageContext);
          __tag0.setParent(null);
          activeTag=_tag0;
          __tag0.doTag();
          {_writeText(response, out, _wl_block4, _wl_block4Bytes);}
          } catch (Throwable __ee){
          if(!(__ee instanceof javax.servlet.jsp.SkipPageException)) {
          while ((out != null) && (out != _originalOut)) out = pageContext.popBody();
          releaseTags(activeTag);
          pageContext.handlePageException(__ee);
          __hello_tag.java:
          package jsp_servlet . _tags ;
          import java.io.*;
          import java.util.*;
          import javax.servlet.*;
          import javax.servlet.http.*;
          import javax.servlet.jsp.*;
          import javax.servlet.jsp.tagext.*;
          public final class __hello_tag extends javax.servlet.jsp.tagext.SimpleTagSupport {
          private static void _releaseTags(javax.servlet.jsp.tagext.JspTag t) {
          while (t != null) {
          if(t instanceof javax.servlet.jsp.tagext.Tag) {
          javax.servlet.jsp.tagext.Tag tmp = (javax.servlet.jsp.tagext.Tag)t;
          t = ((javax.servlet.jsp.tagext.Tag) t).getParent();
          try {
          tmp.release();
          } catch(Exception ignore) {}
          else {
          t = ((javax.servlet.jsp.tagext.SimpleTag)t).getParent();
          public static boolean _staticIsStale(weblogic.servlet.jsp.StaleChecker sci) {
          if (sci.isResourceStale("/META-INF/tags/hello.tag", 1207926783175L ,"9.2.2.0","America/Denver")) return true;
          return false;
          protected static final String tagxTagInfo = "-84,-19,0,5,116,0,5,104,101,108,108,111,116,0,29,106,115,112,95,115,101,114,118,108,101,116,46,95,116,97,103,115,46,95,95,104,101,108,108,111,95,116,97,103,116,0,5,101,109,112,116,121,112,112,112,112,119,5,0,0,0,0,3,116,0,10,106,115,112,67,111,110,116,101,120,116,119,1,0,116,0,28,106,97,118,97,120,46,115,101,114,118,108,101,116,46,106,115,112,46,74,115,112,67,111,110,116,101,120,116,113,0,126,0,4,119,1,1,112,119,2,1,0,112,112,116,0,7,106,115,112,66,111,100,121,119,1,0,116,0,36,106,97,118,97,120,46,115,101,114,118,108,101,116,46,106,115,112,46,116,97,103,101,120,116,46,74,115,112,70,114,97,103,109,101,110,116,113,0,126,0,6,119,1,1,112,119,2,1,0,112,112,116,0,6,112,97,114,101,110,116,119,1,0,116,0,31,106,97,118,97,120,46,115,101,114,118,108,101,116,46,106,115,112,46,116,97,103,101,120,116,46,74,115,112,84,97,103,113,0,126,0,8,119,1,1,112,119,2,1,0,112,112,119,4,0,0,0,0,112,112,";
          protected JspContext jspContext ;
          public void setJspContext ( JspContext ctx ){
          super . setJspContext ( ctx );
          java.util.List nested = null ;
          java.util.List atBegin = null ;
          java.util.List atEnd = null ;
          this.jspContext = new javelin.jsp.JspContextWrapper(ctx, nested, atBegin, atEnd, null);
          }public JspContext getJspContext() {
          return this.jspContext;
          private java.io.Writer jspxsout;
          private javax.servlet.jsp.tagext.JspTag _activeTag;
          private static void _writeText(javax.servlet.ServletResponse rsp, javax.servlet.jsp.JspWriter out, String block, byte[] blockBytes)
          throws java.io.IOException {
          if (!_WL_ENCODED_BYTES_OK || _hasEncodingChanged(rsp)){
          out.print(block);
          } else {
          ((weblogic.servlet.jsp.ByteWriter)out).write(blockBytes, block);
          private static boolean _hasEncodingChanged(javax.servlet.ServletResponse rsp){
          String encoding = rsp.getCharacterEncoding();
          if ( "ISO-8859-1".equals(encoding) || "Cp1252".equals(encoding) || "ISO8859_1".equals(encoding) || "ASCII".equals(encoding) ){
          return false;
          if (_WL_ORIGINAL_ENCODING.equals(encoding)) {
          return false;
          return true;
          private static boolean WLENCODED_BYTES_OK = true;
          private static final String WLORIGINAL_ENCODING = "ISO-8859-1";
          private static byte[] _getBytes(String block){
          try {
          return block.getBytes(_WL_ORIGINAL_ENCODING);
          } catch (java.io.UnsupportedEncodingException u){
          WLENCODED_BYTES_OK = false;
          return null;
          private final static String wlblock0 ="\n<center><h1>Hello World</h1></center>";
          private final static byte[] wlblock0Bytes = getBytes( wl_block0 );
          static private javelin.jsp.JspFunctionMapper jspxfnmap = javelin.jsp.JspFunctionMapper.getInstance();
          public void doTag() throws JspException, java.io.IOException {
          javax.servlet.jsp.PageContext pageContext = (javax.servlet.jsp.PageContext) getJspContext();
          javax.servlet.http.HttpServletRequest request = (javax.servlet.http.HttpServletRequest) pageContext.getRequest ();
          javax.servlet.http.HttpServletResponse response = (javax.servlet.http.HttpServletResponse) pageContext.getResponse();
          javax.servlet.http.HttpSession session = pageContext.getSession();
          javax.servlet.ServletContext application = pageContext.getServletContext();
          javax.servlet.ServletConfig config = pageContext.getServletConfig();
          javax.servlet.jsp.JspWriter out = jspContext.getOut();
          javax.servlet.jsp.tagext.JspTag _activeTag = null;
          try {
          {_writeText(response, out, _wl_block0, _wl_block0Bytes);}
          } catch ( Throwable t ){
          if( t instanceof javax.servlet.jsp.SkipPageException )
          {throw (javax.servlet.jsp.SkipPageException)t;}
          if( t instanceof java.io.IOException )
          {throw (java.io.IOException)t;}
          if( t instanceof IllegalStateException )
          {throw (IllegalStateException)t;}
          if( t instanceof javax.servlet.jsp.JspException )
          {throw (javax.servlet.jsp.JspException)t;}
          throw new javax.servlet.jsp.JspException(t);
          finally {
          ((javelin.jsp.JspContextWrapper)jspContext).syncEndTagFile();
          Edited by Stephen Davison at 04/11/2008 9:02 AM

[weblogic-9.1] JSP 2.0 tag file gets compiled but not reloaded

I am trying to use a JSP 2.0 tag file on weblogic 9.1. Everything works as expected until I reload the page after changing the tag file. Consider the following files, simple.jsp and simple.tag:
h5. /simple.jsp
<%@ page language="java" %>
<%@ taglib prefix="sandbox" tagdir="/WEB-INF/tags" %>
<html>
<body>
This output comes from the jsp.
<sandbox:simple>
</sandbox:simple>
</body>
</html>h5. /WEB-INF/tags/simple.tag
<%@ tag language="java" %>
<div>This output comes from a tag file
</div>The output of a call to simple.jsp is:
<html><head>
</head><body>
This output comes from the JSP.
<div>This output comes from a tag file</div>
</body></html>So far, so good. Now I change the content of simple.tag to
<%@ tag language="java" %>
<div>This output comes from *simple.tag*<div>On a new call to simple.jsp,
1. Weblogic notices that the file has been changed,
2. generates the TagHandler .java file
3. compiles the .java file
But the new class file seems not to be loaded by weblogic; the resulting HTML does not change. It is not a browser cache issue, as I can see Javelin compilation errors. E.g., changing the tag file content to
<%@ tag language="j" %>
<div>This output comes from simple.tag</div>leads to the following (expected) error:
Compilation of JSP File '/sandbox/simple.jsp' failed:
simple.tag:1:18: "j" is not a valid setting for the language attribute.
<%@ tag language="j" %>
^-^
Changes to the .jsp file are reflected in the HTML output.
Am I missing something? Is there any flag I have to set in my weblogic configuration?

You are right in saying that decoding has nothing to
do with rendering per se.I will go even further than Erik did, and dispute this statement.
Consider that you are generating an <input> tag for a text field. Among other things, you have to generate a "name" attribute. Who decides what to put there? The renderer that actually created the markup.
The "renderer" really does
two completely different things. But both should
nevertheless be separate from the component
implementation itself. You could still have the
renderer doing the decoding part, which arguably would
rarely change, and somehow delegate the actual
rendering to an implementation in a tag file.Whether you implement decoding in a separate class or inside the component, what request parameter name do you look for? It is not reasonable to assume that ALL possible renderers will choose the same parameter name ... hence, decoding and encoding are inextricably linked (the code doing the decoding has to know what kind of markup the code doing the encoding actually created). In JavaServer Faces, the current APIs create that linkage by requiring that the decode and encode be done by the same class (either the component, if you are not delegating, or the renderer if you are).
Craig

Firefox in my Mac is suddenly taking a long time to activate, my Mac seems to block as if it was a PC

Firefox in my Mac is suddenly taking a long time to activate, my Mac seems to block as if it were a PC

It may be some dodgy settings or plugins causing that, I would say job one is to check out your extensions, as these can cause all sorts of issues. First, disable them all temporarily and see if that fixes the problem. If it does, turn them back on in turn and see if one in particular is causing the issue. If you find one, ditch it!
If the app is still slow, I would recommend backing up all your bookmarks, and then dumping any settings associated with the app. If you don't feel comfortable doing this manually, you may want to use a tool like Appcleaner to uninstall all of the application's files, and then reinstall a fresh copy from firefox.com.
Hope that helps!

"tagged file is not of valid format"

I'm getting a weird error starting up JDEV 3.1.681 ( waiting for 3.2! ):
"Tagged file is not of valid format"
and my Workspace is brought up... but the PROJECT has been disassociated! I re-include the Project and things seem to be OK... then a couple of days later, I get the same problem.
Any permanent fix? ( while keeping JDev? )

Hi,
Big projects have sort of been a problem in the past, but it's always difficult to reproduce and track down the source of the problem. Doesn't help that the error doesn't mention which file is the problem.
In general, we advise people to put their Business Components in one project, and their client code in a separate project. This is mostly for deployment purposes, so it's easier to encapsulate the business logic or server tier code from the client side code.
I know that the DAC wizard allows you to create it all in one project, which was put in there for backwards compatibility with JDev 2.0 when BC4J was hidden in the same project. Under the covers as it were.
This may or may not be the cause of the problems you're seeing. It might be worthwhile to create a new project in your workspace, remove all your client files for the application from the original project, and add them to the second project. I think you'll have a tougher time moving the BC4J objects, so I would leave those and just move the application files (panels, dialogs, etc.).
After you do that, make sure that the new project has the correct libraries in it. By default, it will just have jdev-runtime, connectionmanager, and Oracle 8.1.6 JDBC, I think. You'll probably need to add the Infobus libraries, JBO runtime, and any others used by your first project. Once you have the library list correct for the client project, you can clean out the library list for the BC4J project so it's only what BC4J needs.
By the way, you mention you have a lot of entity objects for LOVs. If you're just doing lookups, you don't need the entity object. You can create a view object based strictly on a query against the database. IT eliminates some overhead. On the other hand, if you have a lot of them, it might be a real pain to change them all.
Sorry not to be able to provide a more definitive answer on the errors and the access violations.

Search strategy for JSP tag files

Hello everyone,
I've been trying to find a solution to this for some time, but couldn't find a clean one. Maybe somewhere here has any ideas for a solution...
Consider a JSP taglib which is composed of hundreds of .tag files. The library is referenced in JSP using the "*tagdir*" option of the taglib directive, which simply points to /WEB-INF/tags/ (where the .tag files are located).
Our standard server software distribution includes that tag library, as well as JSP pages that make up the server's web user interface. Those JSP pages use the taglib extensively.
Now, we want to be able to distribute upgrades to the JSP pages and the tablib, but allow customers to easily customize some tag files without worring about loosing their changes if they apply a future upgrade.
If it were possible for JSP pages to declare two overlapping taglib directives (same prefix) pointing to two different tagdirs, it would allow us to place our hundreds of .tag files in one "standard" directory, and allow customers to place customized .tag files in another "customized" directory. That way JSP files would always use the same prefix for our tags, but the actual .tag file inserted would be coming either from the customers's "customized" tagdir or from our "standard" tagdir (depending if they chose to override a tag with a customized version or not).
Is this possible? How do people deal with taglib customization and maintenance issues?
Thank you!

Thanks for the reply!
We use the ClickOnce smart client deployment to the user's machine and we would not want to touch/change anything on the user's machine. So, we can't rely on an environment variable being set.
It almost seems that the DB Support Team has to not only talk to the Tech Support team and arrange for deploying the right version of the tnsnames.ora file on their users machines, but also talk to the App Deployment Team and provide the most recent version of this file to be used for deployment. So I guess if this file is checked in a code repository, the DB Support team can notify the Tech Support Team and the App Deployment Team to refresh respectively all user machines and application deployment configuration files.
Alternatively, as one of the app deployment instructions of App Deployment team can be: "check out the most recent version of tnsnames.ora from the repository before deploying the application".
Any thoughts?
Thanks.
Regards,
gkk1969

Evaluting parameter in a TAG file

I am a VERY newbie at JSP...
My pb : I have a tag file header.tag under WEB-INF/tags.
It contains :
<%@ attribute name="titre" required="true" %> <title>MyApp: ${titre}</title>
I use it this way :
<html><head> <%@ taglib tagdir="/WEB-INF/tags" prefix="h" %> <h:header titre="connection" /></head>...
I cannot get my "titre" attribute evaluated: my page still display "MyApp: ${titre}" as title.
I do not understand: the code seems so close from tutorial's examples.
What did I make wrong???
Thanks for help.

Sorry for bad formatting, 'got some pbs with forum refresh ...
So, the TAG file :
<%@ attribute name="titre" required="true" %>
<title>MyApp: ${titre}</title>
The JSP file : <html>
<head>
<%@ taglib tagdir="/WEB-INF/tags" prefix="h" %>
<h:header titre="connection" />
</head>

Tag Files seem to block TagSupport.findAncestorWithClass

Similar Messages

Maybe you are looking for