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]>
