Hi ,
> Yes, this looks like it would work for us. Unfortunately the PersistenceBroker tutorial in the latest CVS does not run and I need to produce a working example of use in the next three hours. > Yes, I don't have to update this stuff, but your problem is really a configuration problem. Comment in <!-- include user defined mappings here --> &user; in the repository.xml file. If this cause trouble you could copy the tutorial_1 related class-descriptor from repository_user.xml to repository.xml HTH regards, Armin > Problem : "Product not found in OJB Repository". I've put the trace below. > > It looks to me as if this is a simple configuration error, but I will need to look more into it. My question is this : am I likely to move faster by modifying the release code or is it worth trying to fix the tutorial bug? To eyes familiar with OJB, does this look like a difficult error? > > > org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException: org.apache.ojb.tutorial1.Product not found in OJB Re > pository > at org.apache.ojb.broker.metadata.DescriptorRepository.getDescriptorFor(Des criptorRepository.java:305) > at org.apache.ojb.broker.metadata.DescriptorRepository.getDescriptorFor(Des criptorRepository.java:318) > at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBr okerImpl.java:615) > at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBr okerImpl.java:599) > at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.store(Delegat ingPersistenceBroker.java:151) > at org.apache.ojb.tutorial1.UCEnterNewProduct.apply(UCEnterNewProduct.java: 42) > at org.apache.ojb.tutorial1.Application.run(Application.java:89) > at org.apache.ojb.tutorial1.Application.main(Application.java:57) > > > ----- Original Message ----- > From: Armin Waibel <[EMAIL PROTECTED]> > Date: Friday, January 31, 2003 1:58 am > Subject: Re: externally managed connection pools > > > Hi, > > > > hope I understood your problem. > > > > First a short description how OJB handles connections. > > The connection life cycle is managed by the ConnectionManager, > > contact the DB/connection pooling/not pooling is done by > > the ConnectionFactory. The ConnectionManager call the > > ConnectionFactory to obtain a connection. > > Both "services" are pluggable (in current CVS, in last release you > > have to make minor changes in PersistenceBrokerImpl > > to make ConnectionManager pluggable), thus it's easy > > for you to write your own implementations. > > The PB and the services managed by the PB use the > > ConnectionManager to get a valid connection. Each PB instance > > use its own ConnectionManager instance. PB instances > > are pooled by the PersistenceBrokerFactory. > > > > > So we need to get a connection like this > > > > > > application.getConnection( userid, action ); > > > > > > where <action> could map very nicely to an OJB's > > > UseCase. > > > > Does <action> mean something like READ, > > WRITE,READ_WRITE? > > > > > One approach might be ( I'm reaching here ) to create a > > > general PersistenceBroker with subclasses for each > > > role and then to assign to each UseCase the > > > appropriate broker subclass. > > > > > > Is this possible - is it a reasonable use of OJB? > > > If so, does this mean we have to fully implement a > > > PersistenceBroker, or is there a PersistenceBroker > > > already in existence that we can morph to our > > > special needs? > > > > Only subclassing the PB does not solve the problem, > > because the StatementManager does use the ConnectionManager. > > Thus a solution could be to implement your own ConnectionManager, > > or subclassing the existing one. Additionally subclass the PB > > implementation > > class and let your connectionManager know about the performed action. > > Think there are still some pitfalls, but that's the idea from my side > > ;-) > > > > HTH > > regards, > > Armin > > > > > > ----- Original Message ----- > > From: "sboston" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, January 31, 2003 3:12 AM > > Subject: externally managed connection pools > > > > > > > > > > We've been looking at a number of persistence > > > options for our application and OJB looks like it > > > might work for us. But I'm not sure how much work > > > it will be. > > > > > > The problem is that our client has a web > > > application framework with role-based connection > > > pool. The idea is that any data access performed > > > will be performed using connection parameters that > > > will resolve to the appropriate permissions. > > > > > > So we need to get a connection like this > > > > > > application.getConnection( userid, action ); > > > > > > where <action> could map very nicely to an OJB's > > > UseCase. > > > > > > One approach might be ( I'm reaching here ) to create a > > > general PersistenceBroker with subclasses for each > > > role and then to assign to each UseCase the > > > appropriate broker subclass. > > > > > > Is this possible - is it a reasonable use of OJB? > > > If so, does this mean we have to fully implement a > > > PersistenceBroker, or is there a PersistenceBroker > > > already in existence that we can morph to our > > > special needs? > > > > > > We have a ludicrously tight schedule, so the effort > > > required is a crucial factor in our decision. > > > > > > > > > ----------------------------------------------------------------- > > ---- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
