Win a copy of Pro Spring MVC with WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 this week in the Spring forum!

Jason Kiefer

Greenhorn
+ Follow
since Mar 21, 2003
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 Jason Kiefer

I found a better solution. Just use the ofType attribute in the *Interface nested elements to add your own types.
-Jason
Okay, so I went the the xdoclet source code, and found the answer to my own question.
It seems that Xdoclet figures out which output source files to create (localhome, local, etc) by looking at the superclass/interface of the input file. ie, if your bean implements the SessionBean interface, it knows not to create a primary key, but will create local, local home, home, etc . . .
Anyway, my Session beans do not implement SessionBean. They instead extend another class, which implements SessionBean. When my other class was not on my classpath, xdoclet couldn't resolve that it truely was a session bean, and therefore did not process it.
The soloution? Well, you could always add the type of the superclass to the subtask classes in the xdoclet code (not sure if it's configurable outside the source?), but I just implemented SessionBean in my child class.
-Jason
Hello. I am having trouble generating Session bean interfaces (local/home/DD) using xdoclet when reliant classes (Classes required for compilation) are not on the classpath.
Session bean interfaces are created as advertised whenever I add reliant classes to the classpath in ant.
I am though able to create CMP bean interfaces (local, home, DD) successfully without the reliant classes on the classpath, just not with session beans (even in the same run!).
Am I missing something? Any Ideas?
xdoclet: 1.23b
ant: 1.5.3
java: 1.4.1_03
Sorry to move this up, but I am still very confused about this issue. . .I still think that it is some kind of timeout or something. My problem is that I am not a server expert like you kind people out there, and I just can't figure out the problem on my own. Please Help!!
18 years ago
Mike -
I use struts as the framwork for this web application. I only put the :8080 in the url (using html:link tag from struts) on the introductory page to the application (non static) part of the website. From there, the :8080 is automatically reconstructed, mostly by using relative paths for navigation. I only used the :8080 becuase this is currently the only way the page works correctly (going around Apache, straight to tomcat).
Regarding the use of global variables, I have used none. In fact, I tried to stay away from any JSP code in the paged, instead I mostly use custom tags. There were a few places I used local variables to construct tables though . . (very minor code).
Please tell me more about threading. . .again, this page works perfectly when executing only through tomcat. The only time it has troubles is when it is accessed through apache.
18 years ago
David -
You will only see the problem on http://www.subsgalore.com/subsgalore/OrderInit.do
. (notice the hardcoded port 8080 is missing). One thing I should also mention is that the problem only happens on the page that is displayed during open busines hours (pst). You will know the page becuase the hours of the shop will not display, but an online ordering screen will instead appear.
Anyway, I tried your suggestions to no avail. I still think it has to do with some sort of timeout or space issue, either within tomcat, or between tomcat/apache.
And to answer your other query, it does not matter which part of the jsp page is deleted out. I even found that if rather than deleting out code, I could comment out with jsp comments (<%-- --%> and it would work fine, but with regular html comments (<!-- --> it would still be screwy.
At this point Im wondering if I should just forget about running the whole thing through apache, and just keeping it set up how it is currently (hardcoded 8080 port for the jsp portion of the website).
I'm still open to any help though! You guys rock!!
-Jason
18 years ago
Thanks for looking. I have since changed the described link to point to 8080. But, when I access the link on port 80 and continue to refresh, different parts of the same page show up. Sometimes the whole page will show correctly, other times 404 will show, and still other times half the page will show up.
The strangest part is that I have been able to make it work perfectly when I comment out a certain amount of any part of the jsp page. I have even been able to get it to work perfectly, then add 1 byte, and have it fail as described.
Does anybody else have any ideas?
18 years ago
Update - I do not have any problem accessing the page straight through tomcat (8080), but only when I go through apache/tomcat. I am using ajp13 for the worker connection. The setup file for ajp13 is as follows:
# Start setup file
#
workers.tomcat_home=C:\\Program Files\\Apache Group\Tomcat 4.1
workers.java_home=C:\\java\\jdk1.3.1
ps=\\
worker.list=ajp12, ajp13
# Definition for Ajp13 worker
#
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
#
worker.ajp13.socket_keepalive=0
worker.ajp13.socket_timeout=300
# End setup file
18 years ago
I'm running Apache/Tomcat on XP. I am having trouble serving a certain page when I becomes too large. I am pulling my hair out trying to figure out why.
It occurs on a JSP page. the page works fantastic when I remove a few random bytes from the HTML code, but when I put them back in, strange, random results occur. To see it, do the following:
1. go to www.subsgalore.com
2. click on online ordering (middle of page)
3. click on Order now (link at the bottom)
4. Keep refreshing this page, and notice the random results.
Is this some sort of timeout? When serving the page from localhost, the error does not occur, only when it is served from the internet.
Could it be my ISP? Any suggestions?
-Jason
18 years ago