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.
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(DescriptorRepository.java:305)
at
org.apache.ojb.broker.metadata.DescriptorRepository.getDescriptorFor(DescriptorRepository.java:318)
at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:615)
at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:599)
at
org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.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]
