Mikael Rundqvist

Greenhorn
+ Follow
since Sep 18, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mikael Rundqvist

Hi all,
I try to use the internal tomcat-server of Forte 2.0 with external taglibs.
I have tried to follow the instruction from
Jakarta
but I get the following error when I run (which from what it seems start or restart the mini-tomcat included in the forte IDE) the JSP-page below from within Forte

Resulting error message is:


DateAndTime.jsp [1:0] Unable to open taglibrary http://jakarta.apache.org/taglibs/datetime-1.0 : Could not locate TLD META-INF/taglib.tld


I have tried to browse to the resourse location
http://jakarta.apache.org/taglibs/datetime-1.0 : Could not locate TLD META-INF/taglib.tld but it doesn't seem to be there.
I have the docBase element set to
C:\Mina dokument\Mickes dokument\Universitetet\www\Javascript
in the server.xml file
In my web.xml file I have included the following two taglib elements

I have also downloaded the jar-files for the two libraries above and placed the jar-files in my docBas-directory.
My questions:
Q1. Where do my WEB-INF directory reside when running from Forte?
Q2. What is wrong with my reference to the tag-library from my JSP-file?
Q3. Whats the experiences of Forte 3.0 and the internal tomcat-server?
/best regards
Mikael
21 years ago
JSP
Hi,
from what I have experienced so far XML satisfies two very important goals for portable software. Open standard and almost total commitment from the industry to follow and support the standard. If you search on the web for the suffix ML (as in markup language and exclude HTML) you come up with lots of new proposed standards based on XML to describe many different domains. I am currently doing my master thesis which involves the rule engine JESS (Java Expert System Shell) and have been thinking of saving the rules I have designed in som XML format. So last friday I searched the Web to see if there was some proposal for such a standard an voila I found SRML (Simple Rule Markup Language). Of course since XML is really a meta-language the possibility that different standards arises still exists but creating a map between the different standards might not be as hard as between two propriatary formats described with a propriatary meta-language.
Hi Celina,
from what I have experienced it seems that at least Tomcat requires that the class have a default constructor (e.g. a non-argument constructor). I think the definition of what a java-bean is also states that there must exist a default constructor for the class. To handle the problem you can do a work-around where you demand that jsp-pages which are to use your bean has to make a call to a method that set your internal variable the first thing they do before the bean can be used in other ways.
The variable that has to be set can either come from an html form, a config file or be hard-coded in the jsp-file. See syntax for <%= and use the id of the bean that you have instantiated.
------------------
22 years ago
I will try to clarify a bit what I meant:
I have created two java-beans which belong to the default package but I created to different JAR-files in <docBase>/WEB-INF/lib for them. Then when I wanted to access the beans through the <jsp:useBean id="test1" class="test1"> and <jsp:useBean id="test2" class="test2"> the bean identified by test2 generates an "cannot create bean" error when the page is auto-compiled.
I managed to locate and fix the problem when I put the two beans in the same jar-file and made a correct manifest-file stating that both classes where beans.
Hope that clarifies the pre-conditions for my question.
22 years ago
I have found the problem myself. I exchanged where the directory of the source files and of the class files. My path should be H:\work\pernilla\exec\
Yet another example of the saying:
"Always, always get your classpath right otherwise you can't sleep at night"
The question still remains about a max length of classpath.
22 years ago
Can someone confirm or reject if I am right about the below:
"Tomcat requires that all classes which are placed in the default package are deployed in one and the same jar-file placed under <context-root>/WEB-INF/lib/ for the class to be found"
/best regards Mikael
22 years ago
Hi,
I am having a bit of a problem when running a product called jess (Java Expert System Shell). Jess comes as a jar-file to be included in your classpath. I decided to place it in c:\Program Files\Jess60a8\. I have also installed a product called JessWin which comes as source code. I have compiled this product and placed it in c:\Program Files\JessWin1.13.
Together with those products I have a rather big application called NAM (AXE Number Analysis Management). This product is built up by multiple jar-files all placed in the lib-directory of the application home directory (C:\Program Files\AXE Number Analysis Manager\) e.g. c:\Program Files\AXE Number Analysis Manager\lib.
I have made alterations and additions to some of the NAM code and placed all output class-files under h:\work\pernilla\...
What I want is to shadow the original class files with the ones coded by me and placed as described above in h:\work\pernilla\.
To achieve this I have created a bat file with the following command:
javaw -classpath "H:\work\pernilla\;c:\Program Files\JessWin1.13\;c:\Program Files\Jess60a8\jess.jar;c:\Program Files\AXE Number Analysis Manager\lib\axenam.jar;c:\Program Files\AXE Number Analysis Manager\lib\flexlm.jar;c:\Program Files\AXE Number Analysis Manager\lib\vbjorb.jar;c:\Program Files\AXE Number Analysis Manager\lib\jctable450K.jar;c:\Program Files\AXE Number Analysis Manager\lib\sfc.jar;c:\Program Files\AXE Number Analysis Manager\lib\jhall.jar;c:\Program Files\AXE Number Analysis Manager\lib\jaxp.jar;c:\Program Files\AXE Number Analysis Manager\lib\parser.jar;c:\Program Files\AXE Number Analysis Manager\lib\mml.jar;c:\Program Files\AXE Number Analysis Manager\lib\jndi.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_cs.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_dsa.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_ls.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_nsa.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_sm.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_smssr.jar;c:\Program Files\AXE Number Analysis Manager\lib\pcsall.jar;." JessWin
To say that the classpath gets long is an understatement.
Some packages can now be found in two places:
a. Under H:\work\pernilla\
b. in c:\Program Files\AXE Number Analysis Manager\axenam.jar
In both H:\work\pernilla\ and in the jar-file there is a deep package structure named "SE.ericsson.epk.NAM".
When i run the bat-file I get the JessWin GUI and the Jess clips system (a knowledgebased system) up and running.
From Jess it is possible to create instances of classes through a lisp-like language called clips.
Here's where my problem start:
1. I have created new classes in a package under H:work\pernilla with the same package hierarchy that exists in axenam.jar. Those classes cannot be loaded by the system class loader.
2. I am able to start the NAM-application from JessWin clips-prompt but when I do so only the classes in axenam.jar are found.
I have e.g. made additions to the GUI and this is not shown.
I have printed the "java.class.path" property from the Jess prompt through the command:
(printout t (call System getProperty "java.class.path"))
and get the following output
H:\work\pernilla\;c:\Program Files\JessWin1.13\;c:\Program Files\Jess60a8\jess.jar;c:\Program Files\AXE Number Analysis Manager\lib\axenam.jar;c:\Program Files\AXE Number Analysis Manager\lib\flexlm.jar;c:\Program Files\AXE Number Analysis Manager\lib\vbjorb.jar;c:\Program Files\AXE Number Analysis Manager\lib\jctable450K.jar;c:\Program Files\AXE Number Analysis Manager\lib\sfc.jar;c:\Program Files\AXE Number Analysis Manager\lib\jhall.jar;c:\Program Files\AXE Number Analysis Manager\lib\jaxp.jar;c:\Program Files\AXE Number Analysis Manager\lib\parser.jar;c:\Program Files\AXE Number Analysis Manager\lib\mml.jar;c:\Program Files\AXE Number Analysis Manager\lib\jndi.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_cs.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_dsa.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_ls.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_nsa.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_sm.jar;c:\Program Files\AXE Number Analysis Manager\lib\nms_cif_smssr.jar;c:\Program Files\AXE Number Analysis Manager\lib\pcsall.jar;.
This seems to be all good and well but as described above classes under H:\work\pernilla\... simply can't be found.
Is there any limitations to the length of the classpath property?
If so shouldn't that instead cause things further down the classpath being unavaible not those classes placed under packages in h:\work\pernilla?
I know this is rather intricate problem but I hope for help from interrested readers of this forum.
22 years ago