Todd Farmer

Ranch Hand
+ Follow
since May 28, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Todd Farmer

I can tell that the precompile process is able to access the Java code for the custom tags, because the business logic encapsulated in the tags is visible in the precompiled JSPs. It still seems to be naming the PageContext object variable incorrectly.

Odd.

Todd Farmer
19 years ago
That's what I was afraid of. That means I probably need to create a new PK, since my current PK is specific to a company (company_id). Company_id then likely becomes a FK to some other table (that has a PK of company_id and attributes of Company that are static in nature, maybe name).

The good thing is that I am using Hibernate, so changing those relationships will be easy...in that application. Changing it in the Perl legacy code will be less fun.

Thanks for the suggestion!

Todd Farmer
Scott,

Thanks for the reply and for the link. I appreciate the pointers on how to get from where I am today to where I should be/want to be, but I'm still looking for some guidance on determining what a good data model would look like for my scenario. I'd love pointers to tutorials, books or other resources that you may recommend that would help me define an appropriate data model to migrate to.

Thanks!

Todd Farmer
Well, I pulled the custom tag code out to a separate project and used that .jar file (including the .tld) as a dependency for my web project. When I ran the Maven Tomcat plug-in, I ended up with the same result. Bummer.

I guess it is still possible (OK, likely) that I'm doing something wrong and missing some needed configuration to precompile successfully. I've already upgraded from Tomcat 5.0 to 5.5, and that didn't resolve anything. Next step has to be to try pre-compilation using Ant to try to isolate the Maven Tomcat plug-in, I guess.

Todd Farmer
19 years ago
I have a Hibernate application that supports a fairly standard publishing workflow. An end user provides information and submits it for review. Authorized users review, validate and correct the user-supplied data and publish the approved data. While the database schema and the object model for each step is identical, they have to be persisted independently so that one can be changed without affecting others. For example, a user can be modifying the user-supplied data, but this data can't affect that which has already been approved and published without being pushed through the entire process.

My initial database model has a series of three tables with identical columns. For example, a user supplies information on a company, and it is entered into the COMPANY_INITIAL table. When the user submits the company profile, the contents are copied to the COMPANY_REVIEW table. Authorized users make changes as needed (pushing changes back to the COMPANY_INITIAL table is an issue), and once the profile is approved, it migrates to the COMPANY_PRODUCTION table.

OK, now for the question.

I'm trying to determine the best practices approach to dealing with these virtually identical domain objects and database tables. My first attempt feels like a hack. I've used Hibernate's support for naming strategies to reuse the domain objects against the different tables. Of course, this means I have to have multiple sessions (one for each naming strategy). And, of course, to make matters worse, there are tables that do not follow that naming strategy, so I have to hack the naming strategy itself to not modify those table names.

I know I could duplicate the mapping documents and subclass the Company domain object for the _REVIEW and _PRODUCTION stages, but then I've got a lot of duplicate code (and mapping documents). That doesn't seem right, either.

I've thought about migrating to a database schema where all versions of a profile are stored in one table (COMPANY) and there is a discriminator that tells me what state a particular row is in. I'm not sure that's the right solution, and it would require a number of changes to the existing data structure and code.

Any thoughts or guidance on best practices principles or Hibernate concepts that would help out here?

Thanks,

Todd Farmer
That's a really good question. The custom tags I developed haven't been factored out to a separate .jar file (they are under the WEB-INF/classes folder), which is different than the Struts and JSTL code.

I'm using the Maven Tomcat plug-in, so I'm not explicitly setting the classpath for the pre-compile step. I can imagine the loose class files are not being included in the classpath used by the Tomcat plug-in.

I'll try pulling the tags out into a separate .jar file and listing that as a Maven dependency and seeing if that resolves my issue.

Thanks for the good suggestion!

Todd Farmer
19 years ago
I finally figured out the root cause of the problem. It appears that when I precompile .jsp files that contain custom tags, I end up with this problem. Removing the custom tags allows the precompilation to work correctly. The standard Struts and JSTL tags appear precompile fine; it's just my custom tags that do not.

At this point, I have no idea why this is the case. I sure would like to be able to use custom tags and precompilation. I wonder if there is something I am doing wrong, or if I need to register my custom tags somehow with the JSPC step to make this work.

Todd Farmer
19 years ago
I've managed to compare the .java files created by JSPC in the precompilation step to the .java files created when I deply the .jsp files as part of my WAR file. I've found the differences that are causing the problem. Here's a snippet from a method in an inner class of one of the .java files created by the JSPC precompilation:



This private inner class extends org.apache.jasper.runtime.JspFragmentHelper, which has a protected field _jspx_page_context (a javax.servlet.jsp.PageContext type).

The .java file created by Tomcat when the same .jsp file is deployed as part of the WAR file looks different, and uses this _jspx_page_context field from the superclass in place of the pageContext variable:



I'm still at a loss as to why the generated .java files are different when using JSPC to precompile the .jsp files and when Tomcat does it during deployment. I'm using the Maven Tomcat plug-in. I may try to use an Ant script to see if I have the same problems, but I don't see any reason to believe I will get different results.

Any suggestions?

Todd Farmer
[ August 17, 2005: Message edited by: Todd Farmer ]
19 years ago
I have been attempting to pre-compile my JSP files in Tomcat 5.0. I am using Struts with Tiles, and my JSP files are all contained under the WEB-INF folder, so they are not directly accessible. Some of the pages work fine after the pre-compilation, but others do not. Specifically, I get a ServletException that looks something like this:



Any idea why this may be happening? The exception information is not particularly helpful.


Thanks!

Todd Farmer
19 years ago
Activation.jar is the Java Activation Framework, and you can download it from the Sun website at http://java.sun.com/products/javabeans/glasgow/jaf.html. I am running AXIS on 1.5. Here's a snippet from HappyAxis:



I can't say that it's running without issues, but I think all the issues I'm observing are a result of my code rather than the VM version.

HTH,

Todd Farmer
19 years ago
I figured out my problem, so I'm documenting it here in case others encounter the same problem. I was using the 1.0 DTD for the validation.xml and validator-rules.xml. After much searching, I finally found the DTD for 1.1.3 (at http://jakarta.apache.org/commons/dtds/). Upgrading the DTD for these files and obtaining the validator-rules.xml from the most recent Struts sample application in the full source distribution fixed the problems and the JavaScript validation works great now.

Todd Farmer
19 years ago
I'm trying to implement JavaScript validations using the Validator Plug-In for Struts. I am only using the standard validations, and they all work fine on the server-side. When I added the <html:javascript ...> tag to the JSP, the JavaScript code appears in the HTML. I hooked it up to the <html:form> onsubmit attribute, and it appears to try to attempt validation, but fails at the following line:

oRequired = new required();

FireFox carps that "required is not defined." IE also does not validate.

I'm somewhat familiar with JavaScript, and I admit that I am lost on what this is trying to do. Am I missing something (like a .js include) that should make this work?

I am using Struts 1.2.4 with Validator 1.1.4 on Tomcat 5.0.30.

Thanks!

Todd Farmer
19 years ago

Originally posted by Cendy Nguvy:

In validator-rules.xml, change "org.apache.struts.action.ActionErrors" to "org.apache.struts.action.ActionMessages" for each methodParams.



That worked great, thanks!

Todd Farmer
19 years ago
I am also having the same problem. I am using Tomcat 5.0.30 on JDK 1.5.0_04 with Struts 1.2.4. I have a DynaValidatorActionForm:



Here's the action:



And here's the validator.xml entry:



I am using Struts modules. Here is the error:


I've tried changing the validation routine to use one of the other pre-packaged routines (such as required) and get the same error. I've also downloaded and included ORO and other dependencies, with the same results.

Any help that can be provided would be appreciated.

Todd Farmer
19 years ago
Thanks!

Todd Farmer
19 years ago