objectbridge-developers Mailing List for ObJectRelationalBridge (Page 25)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Jakob B. <jbr...@ho...> - 2002-04-22 09:05:25
|
hi again john,
i had a look at multiple orderBy. it's easy to do. the main problem is how
to define ASC and DESC ?
do we separate ASC/DESC or do we include it in the fieldNames ?
- orderBy(String[] fieldNames, boolean[] order);
ie: orderBy(new String[]{"name", "salary"}, new boolean[] {true,false});
this is simple but not readable.
include ASC / DESC in the fieldNames array:
- orderBy(String[] fieldNamesOrder);
ie: orderBy(new String[]{"name ASC", "salary DESC"});
this is readable but needs parsing.
there's a third approach:
- addOrderBy(String fieldName, boolean isAscending)
ie: addOrderBy("name",true);
addOrderBy("salary", false);
this is the solution i prefer. it could also be used for groupBy.
any comments ???
greetings jakob
----- Original Message -----
From: "Jakob Braeuchi" <jbr...@ho...>
To: "John Freeborg" <jfr...@so...>; "ojb"
<obj...@li...>
Sent: Saturday, April 20, 2002 6:16 PM
Subject: Re: [OJB-developers] Multiple fields for Criteria.orderBy()?
> hi john,
>
> i just returned from my 2 weeks holidays.
> i've implemented 'groupBy' with an array of fields, so it will be easy for
> me to do so for 'orderBy' also.
>
> greetings jakob
>
> ----- Original Message -----
> From: "John Freeborg" <jfr...@so...>
> To: "ojb" <obj...@li...>
> Sent: Tuesday, April 16, 2002 8:45 PM
> Subject: [OJB-developers] Multiple fields for Criteria.orderBy()?
>
>
> I just ran across wanting to perform a query where I have multiple
> fields listed for sorting, e.g.:
>
> SELECT areaCode, exchange, number, state, cost FROM phoneNumbers ORDER
> BY areaCode, exchange
>
> However, OJB 0.8.375 at the PersistenceBroker layer doesn't seem to
> allow this as Criteria.orderBy() and SqlGenerator.getOrderByClause()
> clearly want to deal with just a single field name.
>
> Anyone already working on this functionality?
>
> I was thinking of simplying adding an array like capability just like
> the Criteria.groupBy() which would adapt well to existing code.
>
> Regards,
> - John Freeborg
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
|
|
From: Jakob B. <jbr...@ho...> - 2002-04-20 16:26:45
|
hi, i just returned from my two weeks sunny holidays. i'll have a look at SqlGenerator as soon as i have synced with the repository and as time allows... greetings jakob ----- Original Message ----- From: "Thomas Mahler" <tho...@ho...> To: <Joa...@tp...> Cc: <obj...@li...>; "Jakob Braeuchi" <jbr...@fr...>; "Jakob Braeuchli" <jbr...@ho...> Sent: Thursday, April 04, 2002 10:12 PM Subject: Re: [OJB-developers] Support-Tracker 529608 (Non-Decomposed N-N & CollectionProxy Bug) > Hi Joachim, > > this is still an open issue. I have not started working on it and I > don't think that others have done so. > > As a workaround you might consider to turn off proxies. > > Jakob is our SqlGenerator expert maybe he can help? > > cu, > > Thomas > > Joa...@tp... wrote: > > > Hy, > > > > a co-worker has just been hit by the bug mentioned in the Subject > > > (http://sourceforge.net/tracker/index.php?func=detail&aid=529608&group_id=13 647&atid=213647). > > > > I was wondering if anyone was looking into this or anyone knows a quick > > fix. Otherwise I'd have to dig into this. I don't know exactly much > (read: > > "nothing") about the SqlGenerator, so I'd much prefer if someone who > > already knows it could look into it. > > > > btw: unfortunately I can't do the refactoring I planned to right now, > > 'cause we have some pressure on our product, so we can't focus on > > code-cleanup. Currently I'm working on the PersistenceBrokerServlet. > > > > regards > > Joachim Sauer > > > > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > > > > > > > > > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Jakob B. <jbr...@ho...> - 2002-04-20 16:13:08
|
hi john, i just returned from my 2 weeks holidays. i've implemented 'groupBy' with an array of fields, so it will be easy for me to do so for 'orderBy' also. greetings jakob ----- Original Message ----- From: "John Freeborg" <jfr...@so...> To: "ojb" <obj...@li...> Sent: Tuesday, April 16, 2002 8:45 PM Subject: [OJB-developers] Multiple fields for Criteria.orderBy()? I just ran across wanting to perform a query where I have multiple fields listed for sorting, e.g.: SELECT areaCode, exchange, number, state, cost FROM phoneNumbers ORDER BY areaCode, exchange However, OJB 0.8.375 at the PersistenceBroker layer doesn't seem to allow this as Criteria.orderBy() and SqlGenerator.getOrderByClause() clearly want to deal with just a single field name. Anyone already working on this functionality? I was thinking of simplying adding an array like capability just like the Criteria.groupBy() which would adapt well to existing code. Regards, - John Freeborg _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Jason v. Z. <jv...@ze...> - 2002-04-19 15:22:29
|
On Fri, 2002-04-19 at 09:30, Mahler Thomas wrote:
> Hi Martin,
>=20
> I like your changes. They help to keep the directory structure clearer!
> Performing the Preprocessor on the build/src files and not on the origina=
l
> files is also a good idea!
>=20
> I did not manage to get the build-maven.xml file exceuted.
> I installed maven.b2 as described in the install.html.
> (${maven.home} and ${lib.repo} exist. My ${lib.repo} directory contains a=
ll
> the maven jars.)
>=20
> I change to my OJB checkout directory:
> cd ojb-1-0
>=20
> then I call
> ant -buildfile build-maven.xml
>=20
> I get all kind of maven internal errors. Also running other targets in th=
is
> buildfile results in errors.
>=20
> what am i doing wrong?
try:
ant -debug -f build-maven.xml
The lack of error reporting is a problem and arises from the fact that I
am trying not to bind directly to Ant. So all the executors (analagous
to an ant task) are simple beans and I rely on the TaskAdapter in ant to
convert the bean to an Ant task but it doesn't do a very good job. The
reason for sticking with straight beans is to allow maven to be used
from ant, a CLI or a GUI tool. So, the error reporting sucks but it does
work and with the debug option we can figure out what's going on.
I'm going to fix the error reporting problem by either altering the
classes using BCEL (because ant1 just sucks at working with beans) or
use aspectj. Haven't decided yet but it's on the list of things to fix
in maven.
> cu,
>=20
> Thomas
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Martin Poeschl [mailto:mpo...@ma...]
> > Gesendet: Donnerstag, 18. April 2002 14:25
> > An: obj...@li...
> > Betreff: [OJB-developers] !!repo and build system changes!!
> >=20
> >=20
> > source files moved from /src to /src/java
> > test code moved from /src to /src/test
> >=20
> > the build system now copies all sources to /build/src
> > this prevents the preprocessor from changing the original=20
> > source files :-)
> >=20
> > martin
> >=20
> >=20
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
--=20
jvz.
Jason van Zyl
jv...@ap...
http://tambora.zenplex.org
|
|
From: Mahler T. <tho...@it...> - 2002-04-19 13:31:42
|
Hi Martin,
I like your changes. They help to keep the directory structure clearer!
Performing the Preprocessor on the build/src files and not on the =
original
files is also a good idea!
I did not manage to get the build-maven.xml file exceuted.
I installed maven.b2 as described in the install.html.
(${maven.home} and ${lib.repo} exist. My ${lib.repo} directory contains =
all
the maven jars.)
I change to my OJB checkout directory:
cd ojb-1-0
then I call
ant -buildfile build-maven.xml
I get all kind of maven internal errors. Also running other targets in =
this
buildfile results in errors.
what am i doing wrong?
cu,
Thomas
> -----Urspr=FCngliche Nachricht-----
> Von: Martin Poeschl [mailto:mpo...@ma...]
> Gesendet: Donnerstag, 18. April 2002 14:25
> An: obj...@li...
> Betreff: [OJB-developers] !!repo and build system changes!!
>=20
>=20
> source files moved from /src to /src/java
> test code moved from /src to /src/test
>=20
> the build system now copies all sources to /build/src
> this prevents the preprocessor from changing the original=20
> source files :-)
>=20
> martin
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Georg S. <ge...@me...> - 2002-04-19 13:13:52
|
Hi Thomas, I think I found a nasty bug related to the SequenceManager which shows up in multithreaded environments: In the constructor of PersistenceBrokerImpl a SequenceManager is obtained by the following line: m_SequenceManager = SequenceManagerFactory.getSequenceManager(this); If this is the first time, SequenceManagerFactory will instantiate a new SequenceManger and give it the this-pointer. Subsequent calls to getSequenceManager will return the same SequenceManager instance. The problem is that once the PersistenceBrokerImpl is finished with its tasks it will get returned to the Broker-Pool and is now available for another thread, but it also forms part of the SequenceManager which will get returned from the factory for new PersistenceBrokerImpl instances. The result is that > 2 threads are accessing the same connection and wrecking havoc on it. My short-term solution is to create a PersistenceBroker at the beginning of the program which I never use again. The real solution would be to create a new PersistenceBroker in the SequenceManagerFactory the first time it is being called. Unfortunately each call to create a new PersistenceBroker calls the SequenceManagerFactory itself again and we are getting into a nice circle (Stack Overflow). I suppose there should be a constructor in PersistenceBrokerImpl that doesn't create a SequenceManager. Regards Georg |
|
From: <Joa...@tp...> - 2002-04-18 17:57:31
|
Hey, sorry to post this here again, but the matter is rather important for us and I don't know enough about the internals to find out how to solve it. but I still got a problem with a non-decomposed N:M mapping in combinatin with extents. It just plainly doesn't work, although there seems to be code for it. Details about the problem can be found in my previous mail to ojb-users (archived at http://sourceforge.net/mailarchive/message.php?msg_id=1444264). After some more debugging I found out that the Tables that are used in the Query originate from the Query object, which is not re-created for each extending class, but reused; so the query is missing the table for the special class. regards Joachim Sauer |
|
From: Mahler T. <tho...@it...> - 2002-04-18 12:47:31
|
Hi Leandro, > > hi all. I don't really know for sure but I think there is > nowhere in OJB > that java.util.Dates are converted to java.sql.Dates before database > insertion. Yes that's not implemented right now. it's on the todo list for a long time... > here is a patch that corrects this behavior. > I didn't applyied it because I'm not sure if this is the *right* place > to include this logic > I would prefer to have all type conversions in single place: the ConversionStrategy implementations. A conversion from java.util.Date to java.sql.Date is not a platform specific thing, but a typical type conversion from/to the RDBMS. cheers, Thomas > -- > Leandro Rodrigo Saad Cruz > IT - Inter Business Tecnologia e Servicos (IB) > http://www.ibnetwork.com.br > |
|
From: Martin P. <mpo...@ma...> - 2002-04-18 12:25:34
|
source files moved from /src to /src/java test code moved from /src to /src/test the build system now copies all sources to /build/src this prevents the preprocessor from changing the original source files :-) martin |
|
From: Mahler T. <tho...@it...> - 2002-04-18 09:01:30
|
<<SourceForge Project Info - S.O.D.A. - Simple Object Database Access.url>> http://sourceforge.net/projects/sodaquery |
|
From: Leandro R. S. C. <le...@ib...> - 2002-04-17 20:11:40
|
hi all. I don't really know for sure but I think there is nowhere in OJB that java.util.Dates are converted to java.sql.Dates before database insertion. here is a patch that corrects this behavior. I didn't applyied it because I'm not sure if this is the *right* place to include this logic -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Thomas M. <tho...@ho...> - 2002-04-17 19:19:39
|
Hi Georg, I just checked my todo mail folder. Your patch is not lost! In fact it's quite close to the front of this FIFO-queue ;-) cu, Thomas Mahler Thomas wrote: > Hi Georg, > > I'll check what happened to your patch! > > If you could see my ever growing OJB todo list you would understand=20 why... > I'm hardly managing to answer all OJB related emails... > > No chance to check in all patches... > > No chance to work on the code base... > > Thomas > > >>-----Urspr=FCngliche Nachricht----- >>Von: Georg Schneider [mailto:ge...@me...] >>Gesendet: Mittwoch, 17. April 2002 16:09 >>An: Mahler Thomas >>Cc: obj...@li... >>Betreff: bug in PersistenceBrokerImpl? >> >> >>Hi Thomas, >> >>On March 6th I sent a post with the same subject line. I tried the new >>release 0.8.375 and the same thing happens again. Is there a >>reason, why >>you didn't put the patch in? >> >>Thx >> >>Georg >> >> > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Mahler T. <tho...@it...> - 2002-04-17 14:16:18
|
Hi Georg, I'll check what happened to your patch! If you could see my ever growing OJB todo list you would understand = why... I'm hardly managing to answer all OJB related emails... No chance to check in all patches... No chance to work on the code base... Thomas > -----Urspr=FCngliche Nachricht----- > Von: Georg Schneider [mailto:ge...@me...] > Gesendet: Mittwoch, 17. April 2002 16:09 > An: Mahler Thomas > Cc: obj...@li... > Betreff: bug in PersistenceBrokerImpl? >=20 >=20 > Hi Thomas, >=20 > On March 6th I sent a post with the same subject line. I tried the = new > release 0.8.375 and the same thing happens again. Is there a=20 > reason, why > you didn't put the patch in? >=20 > Thx >=20 > Georg >=20 |
|
From: Georg S. <ge...@me...> - 2002-04-17 14:09:21
|
Hi Thomas, On March 6th I sent a post with the same subject line. I tried the new release 0.8.375 and the same thing happens again. Is there a reason, why you didn't put the patch in? Thx Georg |
|
From: Chris G. <CGr...@de...> - 2002-04-17 13:51:09
|
What do you mean by a generator? We've just implemented (and are in the process of testing) an ant task that converts the OJB repository.xml into Torque project-schema format. We're using Torque as it stands to generate DDL, etc. from that. Is that similar to what you've done? Cheers, Chris > -----Original Message----- > From: Martin Poeschl [mailto:mpo...@ma...] > Sent: Wednesday, April 17, 2002 6:09 AM > To: obj...@li... > Subject: [OJB-developers] [proposal] dir layout changes >=20 >=20 > i'm working on a maven (=20 > http://jakarta.apache.org/turbine/maven/ ) integration for ojb >=20 > i propose to change the dir layout and follow mavens suggestions >=20 > * move all java sources from /src to /src/java > * move all junit tests from /src to /src/test >=20 > if it's ok for you i'll do the changes and make sure both=20 > build systems (maven and the existing one)=20 > will work >=20 > other changes >=20 > i wrote a generator for the repository and basic java classes=20 > (only getter and setter methods at the=20 > moment) > the generator is part of turbine-torque (=20 > http://jakarta.apache.org/turbine/torque ) at the moment. > torque also provides ant-tasks to generate sql and create the=20 > database for you :-) >=20 > i propose to use the generator for the tutorials. >=20 > you'll have to set the properties for the db and run a ant=20 > script to generate everything, compile=20 > the sources and setup the db. this will make it easier to run=20 > the tutorials with dbs other than hsqldb. >=20 > martin >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From:
<Car...@vi...> - 2002-04-17 13:06:51
|
Hi, we are using OJB to access an existing db and it works create. But now we came to a point where we would like to implement some locking for updates to prevent users from destroying there data each other. (concurrency problem ) BRJ has implemented a locking mechanism for optimistic locking and I think it works create if you have extra columns in the database for locking such as version fields etc. Unfortunately the database we have to access does not have any special fields for a locking mechanism. So we would like to implement the locking via the changed attributes and manipulate the update statement in that way that we enhance the filter criteria so that the changed values must have the original value in the database. Example: UPDATE <table> set Field1=<newValue> where pk=<pkValue> AND Field1=<oldValue>; To get this work the locking mechanism must be implemented outside from OJB. My first idea is to define an UpdateLockManager- Interface. Such an ULM can be registered to the Class in the ClassDescriptor. If the JDBCAccess-Class finds a ULM for a specific class in the executeUpdate-Method than it would get a ready bound PreparedStatement from the ULM and executes it. Otherwise everything will work as now. The strategy do register an ULM in the repository would minimize the changes in OJB but could bring many threading problems to the implementation of the ULM. Another way could be to define another update-Method in the broker interface where you can give an ULM per call. This surely makes the threadsafe implementation of an ULM easier. Maybe it is helpful for the ULM to get some call backs from the ClassDescriptor or from the broker if something happens with the objects. So a Listener interface on the broker could be useful as well. What do you think about the ideas? sp...@vi... |
|
From: Mahler T. <tho...@it...> - 2002-04-17 12:18:48
|
Hi Martin, > > i'm working on a maven ( > http://jakarta.apache.org/turbine/maven/ ) integration for ojb > > i propose to change the dir layout and follow mavens suggestions > > * move all java sources from /src to /src/java > * move all junit tests from /src to /src/test > > if it's ok for you i'll do the changes and make sure both > build systems (maven and the existing one) > will work OK ! > other changes > > i wrote a generator for the repository and basic java classes > (only getter and setter methods at the > moment) > the generator is part of turbine-torque ( > http://jakarta.apache.org/turbine/torque ) at the moment. > torque also provides ant-tasks to generate sql and create the > database for you :-) > > i propose to use the generator for the tutorials. > > you'll have to set the properties for the db and run a ant > script to generate everything, compile > the sources and setup the db. this will make it easier to run > the tutorials with dbs other than hsqldb. I would like to see this running before we decide about it. I agree that the existing OJB preprocessor mechanism is not beautiful. But it gets the job done! cu, Thomas > martin > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Martin P. <mpo...@ma...> - 2002-04-17 11:09:28
|
i'm working on a maven ( http://jakarta.apache.org/turbine/maven/ ) integration for ojb i propose to change the dir layout and follow mavens suggestions * move all java sources from /src to /src/java * move all junit tests from /src to /src/test if it's ok for you i'll do the changes and make sure both build systems (maven and the existing one) will work other changes i wrote a generator for the repository and basic java classes (only getter and setter methods at the moment) the generator is part of turbine-torque ( http://jakarta.apache.org/turbine/torque ) at the moment. torque also provides ant-tasks to generate sql and create the database for you :-) i propose to use the generator for the tutorials. you'll have to set the properties for the db and run a ant script to generate everything, compile the sources and setup the db. this will make it easier to run the tutorials with dbs other than hsqldb. martin |
|
From: John F. <jfr...@so...> - 2002-04-16 21:57:10
|
I'd like to bring up two points regarding OJB exception handling for
discussion among the experts on this list.
Item 1
Perusing the source I've noticed in some places very wide exception
catching with substitution of an unrelated exception. For example, the
RsIterator.next() method below caused me to chase a red herring
NoSuchElementException for awhile. My root problem was a
NullPointerException in some logging stuff deep in a cache class.
My personal preference is to have things fail early and hard if they are
going to. With that in mind, I'd volunteer to hunt down these patterns
and try to constrain them to handle only the exceptions that they expect
& can deal with. In this example we would simply catch and map only the
PersistenceBrokerException that getObjectFromResultSet() could throw.
Thoughts?
public synchronized Object next() throws NoSuchElementException
{
try
{
if (!hasCalledCheck)
hasNext();
hasCalledCheck =3D false;
if (hasNext)
{
Object obj =3D getObjectFromResultSet();
return obj;
}
else
throw new NoSuchElementException();
}
catch (Exception ex) // change to (PersistenceBrokerException
ex)
{
logger.error(ex);
throw new NoSuchElementException();
}
}
Item 2
Some class methods that could fail internally with a
PersistenceBrokerException sometimes (IMHO) inappropriately mask the
exception with an unrelated one. This could have serious ramifications.
For example PersistenceBroker.getCollectionByQuery() could simply return
a smaller collection than really exists with no other indication of a
problem to the caller because when it was using an iterator to load up
the collection, the underlying RsIterator.hasNext() method got a
PersistenceBrokerException (or a SQLException), but masked it (see the
code below).
The root of this problem seems to be an "impedence mismatch" between
wanting to re-use the standard java.util.Iterator interface, but also
trying to surface serious problems as early as possible.
One solution would be to revise the PB interface and start exposing an
RsIterator interface with methods that throw PBEs as necessary. Gets to
the heart of the issue for me, but certainly busts a lot of existing
code.
Another solution would be to create a similiar PBE, but derived from
RuntimeException instead. I'm not so crazy about this, but it is better
than the status quo which seems dangerous IMHO.
Thoughts?
public synchronized boolean hasNext()
{
try
{
if (!hasCalledCheck)
{
hasCalledCheck =3D true;
hasNext =3D m_rs.next();
if (!hasNext)
{
releaseDbResources();
}
}
}
catch (Exception ex)
{
hasNext =3D false;
}
//#ifdef DEBUG
logger.debug("hasNext() -> " + hasNext);
//#endif
return hasNext;
}
Regards,
- John Freeborg
|
|
From: John F. <jfr...@so...> - 2002-04-16 18:45:44
|
I just ran across wanting to perform a query where I have multiple fields listed for sorting, e.g.: SELECT areaCode, exchange, number, state, cost FROM phoneNumbers ORDER BY areaCode, exchange However, OJB 0.8.375 at the PersistenceBroker layer doesn't seem to allow this as Criteria.orderBy() and SqlGenerator.getOrderByClause() clearly want to deal with just a single field name. Anyone already working on this functionality? I was thinking of simplying adding an array like capability just like the Criteria.groupBy() which would adapt well to existing code. Regards, - John Freeborg |
|
From: Leandro R. S. C. <le...@ib...> - 2002-04-16 18:05:18
|
Hi all. I noticed that Log4jLoggerImpl is throwing NPE because it is not configured inside it's constructor. I also noticed that there was a change to include a methods called configure(), but this method is never called ! Anyone knows which is the right thing to do ? use configure() or use configFile = PersistenceBrokerFactory.getConfiguration().getLoggerConfigFile(); ??? -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Thomas M. <tho...@ho...> - 2002-04-16 17:09:30
|
DONE ! John Freeborg wrote: > The sample OJB.properties file has the wrong class name for the log4j > based logger. The line: > > # Bertrand implemented a log4j based logger: > #LoggerClass=ojb.broker.util.Log4jLoggerImpl > > should be: > > # Bertrand implemented a log4j based logger: > #LoggerClass=ojb.broker.util.logging.Log4jLoggerImpl > > The class should be ojb.broker.util.logging.Log4jLoggerImpl (the extra > logging package level is missing). > > Can someone submit a fix to CVS? > > Thanks, > - John > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: <ubu...@ya...> - 2002-04-16 16:49:57
|
Hello everybody out there in happy-ojb-country ;)
I switched my project to the latetest release 0.8.735 und i like it a lot,
especially the new collectionProxy feature.
However, i found a problem with
proxyReference("java.lang.IllegalArgumentException: field type mismatch"),
which i was able to reproduce with a new Test in ProxyExample.java.
I was not able to solve the problem, but i collected some information
which
is hopefully useful for you.
1.) detailed error message
2.) new test in RandomProxy
3.) definitions from repository_junit.xml
4.) ArticleWProxyReference.java (attached)
5.) ProductGroupWProxyReference (attached)
maybe somebody could help me...
cu
Uli
1.) detailed error message
[junit] ...[DEFAULT] ERROR: field type mismatch
[junit] java.lang.IllegalArgumentException: field type mismatch
[junit] at java.lang.reflect.Field.set(Native Method)
[junit] at
ojb.broker.metadata.PersistentFieldDefaultImpl.set(PersistentFieldDefaultImpl.java:114)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveReference(PersistenceBrokerImpl.java:539)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.retrieveReferences(PersistenceBrokerImpl.java:510)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1100)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBrokerImpl.java:1181)
[junit] at
test.ojb.broker.ProxyExamples.testReferenceProxies(ProxyExamples.java:295)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at
junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at
junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] [DEFAULT] ERROR: field: productGroup, type: interface
test.ojb.broker.InterfaceProductGroup
[junit] [DEFAULT] ERROR: value: ----
[junit] group Id: 1
[junit] name: Beverages
[junit] description: Alles leckere zum S³ffeln
[junit] articles in group: null, type: class $Proxy0
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] ERROR: expected
type: interface test.ojb.broker.InterfaceProduct
Group
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] ERROR: actual
type: class $Proxy0
2.) new test in RandomProxy
public void testReferenceProxies()
{
try
{
Object[] pkvals = new Object[1];
pkvals[0] = new Integer(2);
Identity id = new Identity( ArticleWProxyReference.class, pkvals);
ArticleWProxyReference awpr =
(ArticleWProxyReference)broker.getObjectByIdentity(id);
assertNotNull( "awpr is null", awpr);
assertEquals( "awpr.pgid", 1, awpr.getProductGroupId());
InterfaceProductGroup pg = awpr.getProductGroup();
assertNotNull( "ProductGroup is null", pg);
}
catch (Throwable t)
{
t.printStackTrace();
fail(t.getMessage());
}
}
3.) definitions from repository_junit.xml
<!-- Definitions for test.ojb.broker.Article -->
<ClassDescriptor id="142">
<class.name>test.ojb.broker.ArticleWProxyReference</class.name>
<table.name>Artikel</table.name>
<FieldDescriptor id="1">
<field.name>articleId</field.name>
<column.name>Artikel_Nr</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
<autoincrement>true</autoincrement>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>articleName</field.name>
<column.name>Artikelname</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="3">
<field.name>supplierId</field.name>
<column.name>Lieferanten_Nr</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="4">
<field.name>productGroupId</field.name>
<column.name>Kategorie_Nr</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="5">
<field.name>unit</field.name>
<column.name>Liefereinheit</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="6">
<field.name>price</field.name>
<column.name>Einzelpreis</column.name>
<jdbc_type>FLOAT</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="7">
<field.name>stock</field.name>
<column.name>Lagerbestand</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="8">
<field.name>orderedUnits</field.name>
<column.name>BestellteEinheiten</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="9">
<field.name>minimumStock</field.name>
<column.name>MindestBestand</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<ReferenceDescriptor id="1">
<proxyReference>true</proxyReference>
<rdfield.name>productGroup</rdfield.name>
<referenced.class>test.ojb.broker.ProductGroupWProxyReference</referenced.class>
<fk_descriptor_ids>4</fk_descriptor_ids>
</ReferenceDescriptor>
</ClassDescriptor>
<!-- Definitions for test.ojb.broker.ProductGroupWProxyReference -->
<ClassDescriptor id="143">
<class.name>test.ojb.broker.ProductGroupWProxyReference</class.name>
<table.name>Kategorien</table.name>
<FieldDescriptor id="1">
<field.name>groupId</field.name>
<column.name>Kategorie_Nr</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
<autoincrement>true</autoincrement>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>groupName</field.name>
<column.name>KategorieName</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="3">
<field.name>description</field.name>
<column.name>Beschreibung</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
</ClassDescriptor>
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Sie brauchen mehr Speicher für Ihre E-Mails? - http://premiummail.yahoo.de |
|
From: John F. <jfr...@so...> - 2002-04-16 16:28:14
|
The sample OJB.properties file has the wrong class name for the log4j
based logger. The line:
# Bertrand implemented a log4j based logger:
#LoggerClass=3Dojb.broker.util.Log4jLoggerImpl
should be:
# Bertrand implemented a log4j based logger:
#LoggerClass=3Dojb.broker.util.logging.Log4jLoggerImpl
The class should be ojb.broker.util.logging.Log4jLoggerImpl (the extra
logging package level is missing).
Can someone submit a fix to CVS?
Thanks,
- John
|
|
From: Georg S. <ge...@me...> - 2002-04-16 14:45:55
|
Hi, Back from my vacation I downloaded version 0.8.375 and tried to compile it. It didn't work because the classpath wasn't set properly. I don't know much (close to nothing) about ant, but I think that the classpath attribute in the preprocess target should actually be classpathref: <java fork="no" classname="org.hsqldb.util.CodeSwitcher" failonerror="true" classpathref="compilation-classpath"> ^ | instead of classpath Now it compiles sincerly Georg |
9 messages has been excluded from this view by a project administrator.
