under WSAD you have to place a fully qualified name into the repository.xml to point to the right database. That instead of dbalias="../OJB" use something like dbalias="D:\\workspace\\ojb\\target\\test\\OJB"
WSAD is just to stupid to be told please use D:\\workspace\\ojb\\target\\test as base path for executing the samples... BTW: I'm also using VAJ, WSAD, OJB, Struts WebSphere 3.5 / OS390 and DB OS390. cheers, Thomas Boring, Jeff W, ALBAS wrote: > Thanks Charles! The fixed got me past the "no protocol" error. You don't happen to >have any advice with using the hsqldb "ORG" database within WSAD do you? I'm now >getting a "java.sql.SQLException: Table not found: S0002 Table not found: OJB_HL_SEQ" >error. I guess it can't locate the "OJB" database. I added the 3 files (OJB.data, >OJB.script & OJB.properties) from the target\test dir to a dir under my wsad project >workspace and edited the repository.xml file to point to this dir/db. Any >advice/hints or tips on this? > > Thanks, > > Jeff Boring > Custom & Web Services Development > AT&T Labs > [EMAIL PROTECTED] > > -----Original Message----- > From: Charles Anthony [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 8:33 AM > To: 'OJB Users List' > Subject: RE: PersistenceBroker or ODMG? > > > Jeff, > > The problem you raise has been discussed since then. Sorry I didn't reply to > your early mail; I hadn't encountered the issue then - I have now. > > The issue is to do with the XML parser; it doesn't like loading the XML/DTD > files from a path with a space in. Your repository.xml file is in a > directory path with several spaces : > C:\Program Files\IBM\Application Developer\workspace\OJB. > > This is not directly an OJB issue, nor one of WSAD. Try moving the OJB files > (or the workspace) to something like c:\workspace\OJB > > Cheers, > > Charles. > > > >>-----Original Message----- >>From: Boring, Jeff W, ALBAS [mailto:[EMAIL PROTECTED]] >>Sent: 04 October 2002 13:23 >>To: Jason Mihalick; OJB Users List >>Subject: RE: PersistenceBroker or ODMG? >> >> >>We are also using Struts! Perhaps we should stay in touch and >>compare notes? You see from my address that this is an AT&T >>project. Would you mind telling me what company your app is for? >> >>What IDE are you using? We are going from VAJava to WSAD. I >>have not been able to get any of the ojb tutorials to run >>inside WSAD, although they run fine at the command line. I >>know of 3 other developers from 2 different companies that get >>the same error I get ( [DEFAULT] FATAL: no protocol: >>repository.dtd java.net.MalformedURLException: no protocol: >>repository.dtd). No one has replied to my post here about this >>on 9/27/02. >> >>Jeff Boring >>Custom & Web Services Development >>AT&T Labs >>[EMAIL PROTECTED] >>-----Original Message----- >>From: Jason Mihalick [mailto:[EMAIL PROTECTED]] >>Sent: Friday, October 04, 2002 6:13 AM >>To: OJB Users List >>Cc: Boring, Jeff W, ALBAS >>Subject: Re: PersistenceBroker or ODMG? >> >> >>Jeff, >> >>Wow. You are targetting the same platforms as us! As of >>right now (which >>could change very soon depending on support for Struts), we are also >>targetting WAS 3.5. >> >>You bring up an interesting point. We have not considered locking >>strategies. I think that optimistic locking is what we need, >>but I was not >>aware that OJB does not support this. >> >>Also, since I have sent my prior messages, we have discovered >>Hibernate and >>I will be evaluating it today. Hibernate looks *very* >>promising. Some of >>the things I like about Hibernate vs. OJB: >> >>-> No need for additional system tables to support the API >>-> Threads I've read say that Hibernate is thinner, giving better >>performance >>-> Documentation is *excellent* >> >>-- >>Jason >> >>----- Original Message ----- >>From: "Boring, Jeff W, ALBAS" <[EMAIL PROTECTED]> >>To: "OJB Users List" <[EMAIL PROTECTED]> >>Sent: Thursday, October 03, 2002 10:43 AM >>Subject: RE: PersistenceBroker or ODMG? >> >> >>Jason/Suresh: >> >>I read with interest some of the messages in your tread. We are also >>considering PB, ODMG and Hibernate. Another similarity we have >>is DB2 7.1 on >>OS/390 and we are also using WebSphere v3.5 on the 390. >> >>For us, the lack optimistic locking support is driving us from >>OJB.ODMG. >>Have you considered this issue? What kind of locking strategy >>is your app >>using? >> >>Jeff Boring >>Custom & Web Services Development >>AT&T Labs >>[EMAIL PROTECTED] >> >>-----Original Message----- >>From: Jason Mihalick [mailto:[EMAIL PROTECTED]] >>Sent: Thursday, October 03, 2002 6:09 AM >>To: [EMAIL PROTECTED] >>Subject: Re: PersistenceBroker or ODMG? >> >> >>This was a response that I just sent directly to another >>person on the list. >>Hopefully it helps... >> >> >>======== >>Suresh, >> >>No, I have not changed to Castor. Half of my problems were fixed by >>refactoring my code to use the PersistenceBroker API instead >>of the ODMG >>API. I was having problems with aborting transactions with >>the ODMG API. >>That aside, I think I like the PersistenceBroker API much >>better anyway. >>The little bit of persistence code that I had written went >>down from about >>900 lines to 650 lines. From what I've seen so far, it seems >>like a fairly >>elegant API .... AND .... it appears to allow access to a >>JDBC Connection >>which is good for us since we will probably be making calls to Stored >>Procedures, which isn't possible under the ODMG API. >> >>The remaining problems that I need to resolve are the >>threading issues. I >>have read a couple of threads on the mailing list about how to >>remedy this. >>One person suggested that all I had to do was create a new >>PersistenceBroker >>for each query, since the PersistenceBrokers are pooled. I have not >>verified this yet, but it sounds promising. Right now, I just >>have Tomcat >>running with a single HttpProcessor thread and things are >>working. I'll >>attempt to remedy the threading issue on our next deliverable. >>I plan to >>continue using OJB assuming (1) that I don't have a lot of >>issues when I >>change our backing database from HSQL to DB2 v7.1 for OS/390, >>(2) I can get >>support from our other team members that OJB is the way-to-go, >>and (3) I can >>resolve the threading issue. >> >>As far as performance goes, it seems really good to me so far, >>but at this >>point we have only been dealing with small tables, few rows in >>the tables, >>and business logic that supports maintainence of the rows in >>the tables. We >>haven't started doing real query-intensive business logic yet. >> >>After I switched to the PersistenceBroker API, I must admit >>that my attitude >>about OJB changed significantly. I've stopped fighting it, >>and have really >>been quite productive with it. >> >>-- >>Jason >> >>----- Original Message ----- >>From: "Avadhanula, Suresh" <[EMAIL PROTECTED]> >>To: "Avadhanula, Suresh" <[EMAIL PROTECTED]>; "Jason Mihalick" >><[EMAIL PROTECTED]> >>Sent: Wednesday, October 02, 2002 2:51 PM >>Subject: RE: Initializing OJB >> >> >>Hi Jason >>Have you changed to Castor? Were the threading issues in OJB fixed in >>0.9.6? You reported that QueryByExample was missing in the latest >>release. Is this fixed? >>What is the performance you see with OJB? >> >>Thanks >>Suresh >> >>-----Original Message----- >>From: Avadhanula, Suresh >>Sent: Tuesday, October 01, 2002 3:46 AM >>To: 'Jason Mihalick' >>Subject: RE: Initializing OJB >> >> >>I just went thro your posts... I have just started using OJB so yet to >>encounter the threading issues. >> >>I am trying out OJB, hence havent exactly made up my mind to ditch >>Castor. Although I favour OJB so far. Having said that, here are thee >>reasons.. >> >>Cons: >>1) Castor uses only JDO which is not the standard JDO proposed by Java. >>2) I cannot swith between standards like ODMG, JDO and reflection >>(Persistence API). >>3) The code is not very clean and documented, hence if I want to change >>anything or figure out anything its a pain. I have had huge problems >>trying >> to store Maps (Hastables, HashMaps) using Castor-XML. I ended up >>using Apache SOAP's serializer in castor FieldHandler which defeats the >>whole purpose of using castor. >>4) There are no adequeate tools available except for SourceGenertor >>which is used only for Castor-XML and not JDO. >> >>Pros: >>1) Castor has been present for long time. >>2) Usage perspective, its pretty decent. >> >>Coming to OJB: >>You probably have more experience with OJB than I do. >>I am looking at OJB for the following reasons.. Standards, hence if I >>choose to go the JDO route or ODMG route.. I dont have to change a lot. >>The main reason I like OJB is PersistenceBrokerAPI (which is not a >>standard). The reason for that is, I need to have the SQL generated >>automatically. >>I like the >>Query = new QueryByExample(queryObject); // Where queryObject is a >>sample object with only some feilds filled in.. >> >>I was gonna end up writing something similar.. well not OJB gives it to >>me. >> >>As for as the threading issues.. I need to see if I run into the >>problems. I doubt that I would as I can request a new PersistenceBroker >>everytime as its all pooled >>internally. But I need to check. >> >>Hope that helps. >>-Suresh >> >> >> >>-----Original Message----- >>From: Jason Mihalick [mailto:[EMAIL PROTECTED]] >>Sent: Monday, September 30, 2002 6:33 PM >>To: Avadhanula, Suresh >>Subject: Re: Initializing OJB >> >> >>Would you mind me asking why you are shifting from Castor to >>OJB? I was >>just considering doing the opposite. See my last two posts as to why: >> >>http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@; >>jakarta.a >>pach >>e.org&msgNo=2809 >>http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@; >>jakarta.a >>pach >>e.org&msgNo=2831 >> >>Thanks, >>Jason >> >> >>----- Original Message ----- >>From: "Hemant Gokhale" <[EMAIL PROTECTED]> >>To: <[EMAIL PROTECTED]> >>Sent: Wednesday, October 02, 2002 8:26 PM >>Subject: PersistenceBroker or ODMG? >> >> >> >>>I am new to OJB and looking for some advice on choosing between the >>>PersistenceBroker and the ODMG API. Thanks in advance for your help. >>>We are developing a set of simple servlet based applications. And I >>>would like to use OJB for persistence. Our scalability >> >>requirements are >> >>>modest. I am looking at less than 10 simultaneous requests. >> >>I would like >>to >> >>>keep the code as simple and small as possible. I plan to use OJB in a >> >>single >> >>>VM mode (not client server). >>>I have looked at both the options of using the persistence broker >>>directly and using the ODMG API. My initial inclination was >> >>to use the >>ODMG >> >>>API. But on closer inspection I found using the >> >>PersistenceBroker directly >> >>>would be simpler and potentially faster. The added advantage of using >>>PersistenceBroker is that I can use auto-delete and >> >>auto-update features >>to >> >>>make my code even smaller. >>>The only problem with this approach is the possibility of two >>>threads modifying the same object in the object cache. I >> >>came up with the >> >>>following strategy to deal with this problem. >>>Can one of the more experienced people please tell me if this >>>approach with work? Or am I on a wrong track? >>> >>>* Create a pool of persistence brokers. The application is >> >>expected to >> >>>receive only a few simultaneous requests. So the pool is not >> >>expected to >> >>>grow very large. >>>* Inside actionObject.perform() method, before any database >>>interaction >>>* get a broker from the pool >>>* start a transaction tx >>>* Do all your db access using the tx >>>* At the end of all database interaction (still inside >>>actionObject.perform() method) >>>* either commit or abort the tx >>>* release the broker to the pool. >>> >>> >>>Thanks. >>> >>>-Hemant >>> >>>-- >>>To unsubscribe, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > This email and any attachments are strictly confidential and are intended > solely for the addressee. If you are not the intended recipient you must > not disclose, forward, copy or take any action in reliance on this message > or its attachments. If you have received this email in error please notify > the sender as soon as possible and delete it from your computer systems. > Any views or opinions presented are solely those of the author and do not > necessarily reflect those of HPD Software Limited or its affiliates. > > At present the integrity of email across the internet cannot be guaranteed > and messages sent via this medium are potentially at risk. All liability > is excluded to the extent permitted by law for any claims arising as a re- > sult of the use of this medium to transmit information by or to > HPD Software Limited or its affiliates. > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
