Java Runtime Error

[Guest.Visitor]

This strategy uses a singleton called Profile.java, did you change the URL in that file and recompile so that it points to your AS/400 and user profile?

[Guest.Visitor]

Java Runtime Error

Hi don, Well, I already change the parameters for all profile.java to my username, password and ip address of our as400. In fact this programs works on section 4 OO Strategies, Chapter 16 Mapping and Chapter 17 Frameworks. and also profile.java on com.midrangecomputing.objectToRelational package and in section 5 chapter 20 there is profile.java and i change it and run make.bat to recompile all java sources. But still theres a runtime error. I want to figure this out so that I can start my client server project. Thanks a lot Sky

[Guest.Visitor]

Java Runtime Error

DisplayCustomer uses the Customer class. Customer extends RDBObject. The "Error occurred attempting to retrieve file description" message is thrown by RDBObject's initRecordLevelAccess() method after it attempts to set the record format with its setFormat method. Note that setFormat is abstract (coding to a common interface) and that abstract method is implemented by the Customer class. All setFormat does in Customer is set RecordFormat from a parm. During runtime, the record format name come from two static class variables in Customer: fileName and libraryName. In the original code those variables are set to QCUSTCDT01 and DENONCOURT. Direct question: did you change the fileName and libraryName class variables in Customer to point to a file/lib that exists on your system? Changing the discussion completely, and I hope Joe Pluta isn't listening, but whereas my object to relational design pattern takes advantage of record-level access, there are a lot more sophisticated strategies available that use JDBC (Joe is a staunch RLA advocate). With JDBC object to relational mapping you have essentially three options: DAO, EJB, and JDO (Data Access Objects, Enterprise JavaBeans, and Java Data Objects). DAO is the simplist and there are examples all over the net. EJB is overly complex (for entity beans anyway) although there's hundreds of books on it. And JDO is pretty slick and somewhere between the complexity of DAO and EJB. One simple advantage of JDBC is that you can test on a local PC without the requirement of an iSeries connection. If you're really interested in a very simple DAO method, send me a personal email request to denonco@attglobal.net and I'll send you a code example. For JDO you can read my on-line tutorial at www.e-promag.com (search for JDO).

[J.Pluta]

Java Runtime Error

Don said: "Changing the discussion completely, and I hope Joe Pluta isn't listening, but whereas my object to relational design pattern takes advantage of record-level access, there are a lot more sophisticated strategies available that use JDBC (Joe is a staunch RLA advocate)." Actually, I'm a staunch believer of the right tool for the right job. I think JDBC still is a poor choice compared to RLA for work that requires navigating to and updating individual records by key, which is the bulk of our business logic. JDBC on the other hand is quite powerful for queries, especially complex ad hoc queries. The JDBC 2.0 API in particular has a number of features that make it even more palatable, especially the syntax revolving around updatable result sets, where you can update the curent row, or even update the "insert row" to write a record. JDBC is trying real hard to grow to be RLA some day. As to the "more sophisticated strategies", they're all fine and dandy, I suppose, but nearly all overkill. I'm publishing a manual very soon that shows the basics of RLA and JDBC, and how you can easily create classes that can use either approach, or both, or even dynamically switch between them at runtime without affecting a single line in your application program. Note that Don doesn't suggest EJB. He does point to DAO or JDO. These are newer strategies. But not too long ago EJB was the end all and be all. SO is DAO or JDO the way to go now? Which will last? Which will die? Will there be a new one to supersede these? The heck with that. Write your own simple access wrapper, tier your applications properly so that you separate database access from business logic, and then use the technique you're most comfortable with: RLA, JDBC, client/server, it doesn't matter. Don't lock yourself into something, because the "right answer" seems to change from day to day. Hmmm. This seems to be a reasoable topic for a column! Thanks, Don! Joe

[Guest.Visitor]

Java Runtime Error

I tried to compiled and run this program but I got this problem. This program was from from JAVA Apps Strategies for I Series by Don Denocourt. Any Idea why its not working. I have already run most of the java program from that book and all works fine. Only this section give me some headache. Any help will be greately appreciated. Thanks C:JavaforAS400Section5_GUIChap19_GUI>runDisplayCustomer C:JavaforAS400Section5_GUIChap19_GUI>java -classpath .;....jt400.jar;.... Rdb2Obj.jar; DisplayCustomer Error occurred attempting to retrieve file description: java.net.NoRouteToHostEx ception: Host unreachable: connect java.lang.NullPointerException Exception occurred during event dispatching: java.lang.NullPointerException at DisplayCustomer.actionPerformed(DisplayCustomer.ja va:56) at java.awt.Button.processActionEvent(Button.java:329 ) at java.awt.Button.processEvent(Button.java:302) at java.awt.Component.dispatchEventImpl(Component.jav a:2593) at java.awt.Component.dispatchEvent(Component.java:24 97) at java.awt.EventQueue.dispatchEvent(EventQueue.java: 339) at java.awt.EventDispatchThread.pumpOneEventForHierar chy(EventDispatchTh read.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarch y(EventDispatchThre ad.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispa tchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThre ad.java:85)

[Guest.Visitor]

Java Runtime Error

I should have known, Joe's always listening. As to DAO, all that is is a design pattern, and I think one that would lend itself to RLA/JDBC wrappering. The idea is to have two sets of classes: Business Entity classes A factory class that return one entity or a Collection of entitie or a Iterator of entities The Business Entity classes will probably have a common base class, that common base class can easily handle the JDBC/RLA selection. My RDB object wrappering design pattern in my book had a similar strategy but perhaps I should modify it to follow the one of the now more common DAO design patterns. Joe already knows this but I'd thought I'd elaborate for others.