Ian Ohlander

I noticed that one of your directories was called "Wed-inf". Is that on purpose? Or were you trying for WEB-INF, as in the web.xml files taglibrary location?

Ok, just wanted to give an update for future reference purposes. If anyone else seems to have similar problems with jbuilder and tag libraries, I hope this will help.
As I mentioned above, I got the tag libraries working in just the tomcat standalone server. My goal was then to get a simple tag library to work in jbuilder. I'm still surprised that now that I know how to do it, I still have not been able to find anything in the jbuilder documentation, newsgroups, etc.
I followed Jignesh's suggestions very closely to the letter- with one exception- the DateTime.jar file had been changed. There was no "currentTime" tag. So, and this was the mistake I made that in hindsight is incredibly obvious and indeed, foolish, I used an unzip program to look at the structure of the DateTime.jar and saw a tag named "DateTimeTag.class". So I used that name, "DateTimeTag" for the tag. And I kept getting an error message. Then, one evening a month ago, I was going to sleep and it suddenly occurred to me that another name was probably being mapped to that tag in the tld. No sooner said than checked. And I was right. It is referred to as "DateTime". So it compiled and ran fine.
So now I had a working tag library in JB. That told me that my JB environment was correct and that my procedures were correct. So back to my original problem. I have a tag library called cocTags.jar, with a validated tld and two tags: alphDisplay.class and categoryDisplay.class. I included it as part of a library, set the xml tld descriptor to refer to the tld. I had the proper jar tld structure. And yet I was getting a "no such tag found" error.
Ok, so if I am doing everything correctly, and I followed all the procedural suggestions I could find, especially here, especially that which worked with the other tag library (and that really helped because it gave me a model to look at- I could check what was being done here and there, and when I found no discrepency in the methods, then that left only one plact to look), then my problem must reside in my assumptions. Recall that I said "assume you have a working tag library, with a proper tld."
Therein lay the problem. You see, the tags worked. They worked in the standalone of tomcat, not in an jar form. But now that I was using them as part of a jar, the situation was different. My tld mapping to the tag class and my jar directory structure did not coincide! In other words, it was getting the library, found the tld and went looking for the tag. But an error I had made in the tld and the jar's structure made it unable to find the tag. Of course, that seems like a most basic thing, now. But tracking it down was a pain, mainly because I had a faulty premise, and if you proceed from a faulty premise, then even if your logic (or in this case, procedure) is correct, your outcome will not be what you want.
So here it is: the definitive (and how's that for arrogant. I have problems making the most basic part work. But I mean, in other words, the very clear steps to using tags in JB- or at least how I did it.)
1. Create your tag library- the tag classes
2. Make your tld.
3. Make sure your tld refers to the tag properly.
4. Make sure the tld's reference matches the prospective jar's structure.
For example, if you have the following in your tld:
<tag> <name>alphaDisplay</name> <tagclass>coctags.alphaDisplay</tagclass>
then alphaDisplay.class should reside in directory called coctags that is in the root of the jar.
On the other hand, if you had:
<tag> <name>alphaDisplay</name> <tagclass>alphaDisplay</tagclass>
then alphaDisplay.class should just be in the jar's root. Even though the tag may be part of a package (say coctags), your tld does not have to refer to it as "coctags.alphaDisplay". That was where my problem lay. I kept having it refer to "coctags.alphaDisplay" when alphaDisplay.class was in the jar's root, becasue I thought that since it was part of that package, that was how it had to be.
So bottom line is, make sure the jar structure matches what the tld specifies. And validation will not catch that.
5. Make the jar.
6. In JB, under the project properties/required libraries, either create a new library or use an existing one. If creating one, name it something, and then add the necessary jars to the library.
7. (Optional, but is a best practice) Point your web.xml taglibrary descriptor to the jars (they will be under WEB-INF/lib).
8. add a tag library refernce in your jsp under some name and mapping to either the actual jar file or to the taglibrary descriptor name referred to in the web.xml file.
9. Finally, jut use your tags, making sure to use the proper names that the tld specifies.
And that's it, I think. End of story. I felt dumb, but at the same time glad it was tracked down. I could not have done it without your help, people. That's why I am posting this: so anyone else doing a search on the subject can find something more explicit that what I found, and that also mentions some of the pitfalls and assumptions that can contribute to the error.

Here's something wierd. Of all the steps you showed me, the only one necessary is changing the directory to J2EE_HOME. So I wanted to check if there was something wrong with my J2EE_HOME variable. So (and this is something I thought I should do anyway if I was to use your technique) I set the properties from the dos-prompt to open to: %J2EE_HOME%\bin.
Now, when I open up a dos-prompt it goes to the J2EE_HOME directory. So the variable is working. This makes no sense. IF the variable correctly is putting directory on the path then all the files (exe, bat) should be accessible from anywhere, right?
Hmmm.

Ok, that works. Thank you. AT least I have a recourse. So do you simply create a batch file that does that? I can do that.
But what I don't understand is why, when I followed the instructions (and since typing "java" works properly, as JAVA_HOME is on the path) why refering to the j2ee.bat file that is in J2EE_HOME/bin isn't automatically resolved?
Maybe there is a detail I missed, or my path isn't exactly right. Do they look right to you?
I appreciate your help. At least it's not hopeless.

(I searched the web and the archives using this as my search string and couldn't find anything:
how AND to AND install AND j2ee AND in AND windows AND xp
So if I am repeating something from before, I'm sorry.)
I recently installed Windows Xp. I have, also recently, decided to learn j2ee. So I got a book on the subject, downloaded the newest j2se, j2se sdk 1.4.01 and j2eesdk 1.3.1 and installed them both. I then went to sun's site and followed their instruction for getting j2ee up and running in Windows:

1. If you have installed a previous version of the J2EE SDK product, you must delete or un-install the previous version from your computer before proceeding with the new version. When you are ready, run the setup program.
Double-click on the icon of the j2sdkee-1_3_1-win.exe file, and follow the instructions provided by the setup program. By default, the setup program installs the software in C:\j2sdkee1.3.1.
2. Set the environment variables.
Before running the J2EE SDK, you must set these environment variables:
J2EE_HOME - the directory where you installed this release.
JAVA_HOME - the directory where the Java 2 SDK Standard Edition is installed.
PATH - include the bin directory beneath the directory where you've installed this release.
If you need help with setting these variables, see Setting Environment Variables.
3. See "Where do I go from here?"

Point 3 takes you to the j2ee tutorial, where after making sure the variables are set properly, you simply type: j2ee -verbose.
But I keep getting this error:
"j2ee is not recognized as an internal or external command, operable program, or batch file."
I have check my environment variables 3 times. They are:
J2EE_HOME=C:\j2sdkee1.3.1
JAVA_HOME=C:\j2sdk1.4.0_01
Path=%SYSTEMROOT%\system32;%SYSTEMROOT%;%SYSTEMROOT%\COMMAND;C:\xml_tools\xalan-j_2_3_1\bin;%SYSTEMROOT%\system32\WBEM;%J2EE_HOME%\bin;%JAVA_HOME%\bin
where the directories for j2se and j2ee are where they were installed at the outset.
Am I mising something? If I type "java" at the command prompt I get the usual list of possible command line additions. So the path is set. But it won't recognize "j2ee" or "j2ee -verbose".
Any ideas?
[ August 02, 2002: Message edited by: Ian Ohlander ]

Part of the solution as to which data structure you will use will depend on how often, in what order, and so on, you will be accessing this information.
So, for example, if you are just going to iterate through the data for table generation, then things like arrays, vectors, stacks, queues or linked lists will work (though in the case of stacks or queues that is not, obviously, their primary advantage.)
But if you need to access individuals pieces of data at random times then obviously more will be needed. Hashtables, for example, search in constant time, that is, the time to access the data is (relatively) the same regardles of the size of the table. (I say relatively because if hashing collisions- where two items map to the same place- occur, one has to be "rehashed" to another place. So the time to access will be different, but not significantly so.)
There are priority queues, where the information is stored according to some criterion of value (for example, bills, according to date due then are stacked for payment), black-red trees, ordered arrays, 2-3-4 trees, heaps, and graphs.
Based on you basic description the following are the ones you will probably want to look at.
Arrays have quick insertion and constant time access if the index is known. But they have slow search capabilities, deletion, and are of fixed size. You can get around this with Vectors, but of course you tried this.
Ordered arrays have quicker searches than unsorted and the same disadvantages.
Stacks are Last In First Out but are slow for access of middle items by repeated pops(You can get around this if you create one from a linked list- just add a push() method that keeps linking to the head and then becoming the head, and the pop() keeps returning the head. In this case you can iterate through it like a linked list- and it is a linked list, so you might as well use that, unless you need both traits.)
Queues are First In First Out, same advantages and disadvantages (and you can do the linked list thing again, with modifications).
Linked Lists are fast on iteration but slow on searches (since, like arrays, you search by starting at the beginning and looking until you find what you want) and might be more memory intensive (not sure, though).
Binary Trees, obviously more complex, are fast at everthing. Deletion is complex (but, as for all of these, you can find implementions to use so it's not that much of a problem). I believe its search time (in # times through the main workhorse algorithm) is no more than log2 (n) where n is the number of items in the tree- that is worst case, which is really good. The only really better time (without some really strange, comlicated algorithm) is O(c), where the time is the same no matter what (almost- see above).
Hashtables as I mentioned are really good at speedy accessing, but only as long as you know the key. Otherwise you have to get all the keys (or objects) and check them to see if they're what you want- and then it is just like an array, etc. It's deletion is slower, and it uses memory inefficiently.
So, if iteration is your game, use arrays or linked lists (limited only by memory, really), or trees. If random searches for specific items only, then hashtables or trees. If you will be adding to or deleting from alot, then trees (in all their complex forms) and, if not alot of deleting, hashtables.
For specific implementations, check the java.util.Collections for the specialized types. You can find implementations of others (like red-black trees) on the web.
hope that helps,
[ July 20, 2002: Message edited by: Ian Ohlander ]

Thanks Jignesh. I tried it (exactly what you listed, using datetime.jar, etc, just to make it work) with only a couple differences that I think may be because of the version I am using. Like When creating a JSP, there is no create runtime configuration box, or when creating the project PTagTest in PTagTestDir, the resulting directory structure doesn't match what you listed. Oh, and the new? version of datetime.jar doesn't have a tag called currentTime, but instead something else (can't remember now, but caught it in the tld). But with those minor changes (especially that last) I hoped for success. I followed your steps exactly.
Still same error as before: can't find class ... as I mentioned above. So I uninstalled and reinstalled JB6, and still no dice.
I am going to get Borland's customer support in this since this is getting ridiculous. Unless you can think of something that I haven't done.
Thanks again,
Ian

Well I'm back still with the original problem. As I mentioned in the last post, I was able to get my tags to work. But that was with what had become the 2nd part of my project- just to get them to work in Tomcat as a standalone. With that success (and what looked like some promising leads on the internet, including some openTools) I figured I could get the rest, that it would only be a matter of time and why did I want to bother all the nice people here anyway when I was going to get it any moment.
Hubris, as they say. I am in some serious need of help, here. This is not a project that is time sensitive, except that I just want to get the dang thing to work. I love java programming, got certified as a Java 2 programmer in February, and now and absolutely loving JSP and servlet programming. I want to do this.
But this JBuilder is really starting to get to me. I really have liek using it, but I don't understand why they have to make the process of using custom tags so complicated.
So to those who can help, please, help me.
I have a tag library that I know works- It works when I use it in Tomcat, exactly as I want it to. So assume, now, that I have this library, called coctags.jar (alphaDisplay.class, categoryDisplay.class, META-INF (a directory) and in that, taglib.tld, which has been validated.) Now I wish to use this tag library in a new project. What do I do? What are the steps, pure and simple, to use these tags in this new project in JBuilder 6?
Please, anyone who has used JB this way, help me. I'm dyin' here. This can't be that hard. Otherwise, I'm seriously rethinking my decision to use JB for projects.
Thank you,

Thank you so much. I knew it was something I had looked at so long that I didn't even notice.
I owe you guys.
Thanks.

OK, I tried your suggestions. Let me explained how.
First of all, keep in mind that I now have two "projects" (not JBuilder projects, but rather two avenues I am pursuing.)
1. Try to get my taglibs to work in JBuilder using a tag library jar. This involved creating the jar, adding it to the necessary libraries for this project, and adding the tld (in addition to its place in the jar) to /WEB-INF
2. Try to get my taglibs to work period, using just the classes, tlds, and Tomcat 4.0 standalone. This came out of the fact the 1 wasn't happening and I wanted to see if the problem was the jar deployment process. This involved simply putting the tld in WEB-INF/tlds, the *Display.classes in WEB-INF/classes/coctags/, and making sure my JSp referred to the tld properly.
Simon, in 2, I changed the taglib directive to reflect the fact that coctags.tld resided in WEB-INF/tlds/. Still, I get the same error. I was going to use an XML mapping in web.xml, to decouple the talib directly from the jsp, but first I just wanted to make it work. Still nothing, so far. The same error: tag with that name not found in taglib with prefix coc. As I said, my tld looks alright, I think I have the right directory structure, and the taglib directive is getting the coctags.tld. It's just not finding the tag alphDisplay in that tld (or maybe it can't find the class.) But I printed the directory structure. Is the tld referring to the classes properly? Are they in the right place?
Jignesh,
Good suggestion. I didn't know that (in project 1) my jar file had to have the taglib named taglib.tld, as opposed to something else. The META-INF directory is there, but the tld was not named properly. So I changed the name, and I also changed the tld to add the uri element. I simply used "coc". Then in my jsp file, I changed the taglib directive to say:
<%@taglib uri="coc" prefix="tags"%>
Naturally, as you can see, I changed my prefix (to avoid any naming complications), so my reference to it later has been changed to:
<tags: alphaDisplay resultSet="<%=cNqBean.getResultSet(true,0)%>">
Finally, I added the uri change to the tld that resided in /WEB-INF (for JBuilder, as suggested above).
In this case, I get the error: "Could not find file /coc".
So, again, in case this was a problem in JBuilder, I added the URI change to the tld in project 2 (the tomcat, JAR-less edition), and made the appropriate changes to the jsp (referring to it as "coc".)
At this point, I have made about 4 or 5 changes, all of them straightforward, and seemingly with little room for mistake. But mistakes there must be, either in the changes or in the original structure. I could understand if project 1 wasn't working. It involves a rather complicated IDE, with necessary libraries, etc. But project 2 should be rather simple. TLD in the appropriate place, classes in the appropriate place, tld referring to classes properly, and jsp referring to the tld properly. As I mentioned, in project 2, the only thing I am usure of is the location of the tag classes themselves. I honestly can't see any other problem. Of course, that doesn't really mean anything.
Thank you all for your help. I really do appreciate it. But does anyone have any ideas?

That last part of my post wasn't very clear. I thought maybe the whole .jar deployment process was flawed somewhere, so I tried to do it without a jar, in Tomcat 4.0. I created the appropriate dir in webapps, place my tagTest.jsp in it, also created a WEB-INF/tlds dir and put coctags.tld in that. Then, in webapps/chamberofcommerce I made a classes/coctags dir, and put the two compiled tag classes in that. I modified my tagTest.jsp to get the taglib from /WEB-INF/tlds/. I didn't modify my coctags.tld because it showed the tag classes to be found at coctags.*Display.
So I have:
webapps/ chamberofcommerce/ tagTest.jsp WEB-INF/ tlds/ coctags.tld classes/ chamberofcommerce/ connectAndQueryBean.class coctags/ alphaDisplay.class categoryDisplay.class
But, as I said, I still get the same error message. 'No such tag found in taglib coc.'
At this point, I am frustrated because, as far as I can tell, I have set things up properly. But it must be the case that I am missing something, and have been looking at it too long, so that the thing wrong doesn't even register- it looks normal.
Any ideas?
Thanks.

Ok, I must be dumb or something, because I cannot get this to work.
In JB I created two tags: alphaDisplay and categoryDisplay, both declared as part of package coctags. I initially made my own coctags.tld file, based on those I found in books, and it looked alright (that is to say, it validated properly.) I tried making a jar file with JB, but had problems. So I simply used winzip. I put my two generated classes in a folder, along with another folder, META-INF, with the tld., and zipped it up. Then changed the extension to .jar, added it to the needed libraries of my coc project, and added the coctags.tld to c:/coc/defaultroot/WEB-INF/. Then my tagTest.jsp looked like this:
<%@taglib uri="/WEB-INF/coctags.tld" prefix="coc"%> <html> <head> <title> tagTest </title> </head> <jsp:useBean id="cNqBean" scope="page" class="chamberofcommerce.ConnectAndQueryBean" /> <jsp:setProperty name="cNqBean" property="*" /> <body> <h1> Testing My cocTags </h1> Testing alphaTags <coc: alphaDisplay resultSet="<%=cNqBean.getResultSet(true,0)%>"> </body> </html>
But I kept getting an error message:
"tagTest.jsp": org.apache.jasper.JasperException: No such tag in the tag library imported with prefix coc

I checked my tld, and it looked exactly how it was supposed to. But I used an openTool taglib generator on the tags and used the following, just in case I made a mistake. Mine was exactly the same, but here it is.
<?xml version="1.0" encoding="UTF-8"?> <!-- Generated by Taglib Descriptor Wizard --> <!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>coctags</shortname> <tag> <name>alphaDisplay</name> <tagclass>coctags.alphaDisplay</tagclass> <bodycontent>empty</bodycontent> <info></info> <attribute> <name>resultSet</name> <required>true</required> <rtexprvalue>true</rtexprvalue> </attribute> </tag> <tag> <name>categoryDisplay</name> <tagclass>coctags.categoryDisplay</tagclass> <bodycontent>empty</bodycontent> <info></info> <attribute> <name>resultSet</name> <required>true</required> <rtexprvalue>true</rtexprvalue> </attribute> </tag> </taglib>
Still get the same error message. I know the library is being used by JB. The structure pane shows that coctags directory and the two tags are part of the project. But still nothing.
I also tried this using just tomcat (in the webapps dir) and no jar file, thinking maybe I was having trouble with the jar. Just a simple tlds directory in WEB-INF with coctags.tld in it. Classes holds a directory called coctags, which has the two compiled classes. I get the same error message.
What am I doing wrong?

Thank you. I will try your suggestion when I can.
I really get the impression that Borland wants you to use their InternetBeans tag library, instead of another. Very frustrating.
Appreciate all your help.

Forgot about that short circuiting effect. Now it seems more clear why a person would use it. To force the second boolean to be evaluated no matter what.

basically, the inner do-while keeps reading in a new char and testing to make sure it isn't either CR or LF. If it is, it gets another. Once it has a valid char (not CR or LF) it tests and makes the appropriate comment.
The boolean expression using a bitwise comparison of the boolean expressions c==\n and c==\r. Basically, this just treats the individual booleans as 2 bits and OR's them together. It has the exact same effect as c==\n || c==\r, so I don't really know why a person would use it. I usually reserve bitwise comparisons when the bits of my numbers hold crucial information (a simple array). From what I've read, do-while is not good coding, since the condition test is not immediately visible to the person reading the code. "while(test){}" is much clearer to the reader. You can do anything a do-while can do with a simple while (provided you initialize certain values you want to test for, about the only advantage I know of, for do-while.)