Well, I develop and setup my small test application from scratch. There
is one persistent class, a Test class which has main method,
OJB.properties, repository.xml and repository.dtd.
It all goes well but when I change Executor to Internal Execution it
generates some warnings and exceptions as
Original Message
Subject:How to call a select store procedure in OJB
Date: Fri, 9 Jan 2004 14:56:15 -0800 (PST)
From: Suma Venkatesh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Hi
Iam working on using store procedures using OJB. I want
Hi Larry,
hmm, stack trace says:
Caused by: org.apache.ojb.broker.metadata.MetadataException: Can not
read repository class descriptor data, using repository: repository_user.xml
and
[org.apache.ojb.broker.metadata.RepositoryXmlHandler] DEBUG:
class-descriptor
Hi again,
maybe the problem could be the isolation-level set on
descriptor-repository element level (repository.xml file), this level is
used as default level in class-descriptor.
Do you set isolation-level attribute on this level? How does your
repository.xml file look like?
Should be
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 10:32 AM
Subject: Re: ODMG Update Collection Problem
Hi,
Ralf Geiger wrote:
Hi,
According to the mailing list I know that lots of people have similar
Daniel --
The Query interface defines a setDistinct(boolean) method. Set this to
true and you should see better results.
Ron Gallagher
Atlanta, GA
[EMAIL PROTECTED]
-Original Message-
From: Daniel Perry [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 9:41 AM
To: OJB Users List
Hi Aamir,
first, the following lines can be completely nonsense (never used
Netbean, don't have a clue in ClassLoader problematic ;-))
But this sounds like a typical ClassLoader problem. On OJB startup the
classes specified in OJB.properties file are loaded. Maybe the OJB
config files or/and
hi edson,
[EMAIL PROTECTED] wrote:
hi edson,
frankly, i'm still confused...
Sorry... I think I don't have sufficient english skills to make more clear...
i understand that collection-proxies do not seem to help because of the
way you built your gui :(
Thanks, I think you had some
Hi! Just more 2c:
When running app in NetBeans using Internal Execution Mode, it always set working
directory
to %NETBEANS_HOME%\bin (hipotetical path - adapt to your OS of preference). I don't
know if
there is a way to change this programmatically, and you can have trouble with this
kind of
i saw the sample code you posted some days ago. now it's clear how you do it.
The first step ;-)
ojb needs this field (better: the collection referenced by this field) to handle
the m:n-implementors in case of an m:n-relationship.
That's just the case. If I use the artifact of
hi edson,
[EMAIL PROTECTED] wrote:
i saw the sample code you posted some days ago. now it's clear how you do it.
The first step ;-)
ojb needs this field (better: the collection referenced by this field) to handle
the m:n-implementors in case of an m:n-relationship.
That's just the case.
i do not see where this happens ?
Here (note: the if(!true.equals( bellow is in my patched version of OJB that is
working
fine):
...
private void storeCollections(Object obj, Vector vecCds) throws
PersistenceBrokerException
{
// get all members of obj that are collections and
Interesting is that this code is right (will only occur if cds.getCascadeStore()
returns true):
private void storeCollectionObject(CollectionDescriptor cds, Object otherObject)
{
// if cascade store: store associated object
if (cds.getCascadeStore())
{
Really, executing again withou my patch, I've seen that is not the keys, but the field
it
self. Sorry...
The line getting in trouble is
Object col = cds.getPersistentField().get(obj);
because there is no persistent field at all.
I'm a bit lost in too much code, techs, newbie
It turns out that my application was picking up an old repository.xml,
one that was actually just the user fragment. So, it started with a
class-descriptor. Since there was no DTD declared in the file, there
was no default value for isolation-level and, thus, the parser returned
null.
Thanks. I've downloaded it and will look at it later this weekend.
Is OpenEMed an example of a typical OJB application?
David Forslund [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
http://OpenEMed.org (a sourceforge project) uses OJB as its default
persistent store. It doesn't
I posted this right around new years, but I have not seen any responses
since then and some of these questions are still eating at me. Can anyone
provide any answers to some of the questions that I've asked?
Thanks in advance.
Sean Dockery [EMAIL PROTECTED] wrote in message
news:[EMAIL
Hi Danilo,
The problem lies in the support for primitive data types, since a
primitive type cannot be null, the value 0 is interpreted as null.
It seems that non primitive data types also react the same way (even
if they shouldn't, so from my point of view it is a bug)
I checked in two tests
I'm working on a fairly simple sample program (modified from the
tutorial1 code shipped with OJB) and I'm running into some
unexplainable (by me :-) behavior relating to a 1:N relation.
The relationship is a simple 1:N from a Person object to a Trait
object. I've attached the
19 matches
Mail list logo
