objectbridge-developers Mailing List for ObJectRelationalBridge (Page 8)
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: Oleg N. <on...@ib...> - 2002-06-06 14:50:10
|
Georg Schneider wrote: > Hi Oleg, > You mean you would construct a CollectionDescriptor for the N-side and not > add it to the ClassDescriptor of the N-side? I mean that we wouldn't require CollectionDescriptor for the N-side in repository.xml, but we will generate it at runtime and add to ClassDescriptor in memory. Oleg > Cheers > Georg > On Thu, 6 Jun 2002, Oleg Nitz wrote: >> Hi Jacob and Georg, >> >> It is convenient to have bidirectional relationship for OJB internals >> (this makes things more uniform and simple), >> but it may be inconvenient for user. >> I propose the following trick: if there is no inverse relationship we >> generate it automatically. We may even allow user to use it in query >> conditions. For example "~rel" would mean inverse relation for "rel". >> What do you think? >> >> Oleg >> >> Georg Schneider wrote: >> > Hi jacob, >> >> > Could you give me the basic reason for that requirement or please point me >> > to your discussion with Oleg (I missed that one :-) ). >> > Nevertheless I think that this is quite a big intrusion into the java code >> > and since all of the information needed is already in the >> > CollectionDescriptor of the M-side, I don't see a reason for doing it. >> >> > Cheers >> >> > Georg >> >> >> >> > _______________________________________________________________ >> >> > Don't miss the 2002 Sprint PCS Application Developer's Conference >> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> > _______________________________________________ >> > Objectbridge-developers mailing list >> > Obj...@li... >> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> >> >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> _______________________________________________ >> Objectbridge-developers mailing list >> Obj...@li... >> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> > _______________________________________________________________ > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Georg S. <ge...@me...> - 2002-06-06 14:37:34
|
Hi Oleg, You mean you would construct a CollectionDescriptor for the N-side and not add it to the ClassDescriptor of the N-side? Cheers Georg On Thu, 6 Jun 2002, Oleg Nitz wrote: > Hi Jacob and Georg, > > It is convenient to have bidirectional relationship for OJB internals > (this makes things more uniform and simple), > but it may be inconvenient for user. > I propose the following trick: if there is no inverse relationship we > generate it automatically. We may even allow user to use it in query > conditions. For example "~rel" would mean inverse relation for "rel". > What do you think? > > Oleg > > Georg Schneider wrote: > > Hi jacob, > > > Could you give me the basic reason for that requirement or please point me > > to your discussion with Oleg (I missed that one :-) ). > > Nevertheless I think that this is quite a big intrusion into the java code > > and since all of the information needed is already in the > > CollectionDescriptor of the M-side, I don't see a reason for doing it. > > > Cheers > > > Georg > > > > > _______________________________________________________________ > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: David F. <dw...@la...> - 2002-06-06 14:30:13
|
Any clue as to the appropriate modifications? I'm using the broker interface and am using the standard sql for OJB_SEQ as defined by OJB-0.8.400 I'm not sure what to change. thanks, Dave At 09:59 AM 6/6/2002 -0400, Carlos Perez wrote: >I had the same problem with Oracle when using the ODMG API. I removed my >usage of the API and it works with the Broker. My suspicion is that you >have to modify the db-setup.sql to create the right OJB tables. > >Carlos > >-----Original Message----- >From: David Forslund [mailto:dw...@la...] >Sent: Wednesday, June 05, 2002 4:27 PM >To: obj...@li... >Subject: [OJB-developers] OJB_SEQ with Oracle > > >Are people using the OJB_SEQ table with sequences in Oracle? > >When I try to create a sequence in Oracle, I get a failure: > >It is calling getNextId in SequenceManagerDefaultImpl and fails with a > SQLexception: ORA-00001: unique contraint (COAS_SERER.SYS_C005581) >violated. >The table is created using the standard sql for SequenceEntry and the >default xml repository mapping >to OJB_SEQ. > >It is doing an insert of all the variables into the table but must be >rejecting them >because the key has already been filled and it things I'm trying to create >another key >with the same value. > >I think this was working with an earlier version of OJB. This problem is >with OJB-0.8.400 > >Thanks, > >Dave > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Oleg N. <on...@ib...> - 2002-06-06 14:25:15
|
Hi Jacob and Georg, It is convenient to have bidirectional relationship for OJB internals (this makes things more uniform and simple), but it may be inconvenient for user. I propose the following trick: if there is no inverse relationship we generate it automatically. We may even allow user to use it in query conditions. For example "~rel" would mean inverse relation for "rel". What do you think? Oleg Georg Schneider wrote: > Hi jacob, > Could you give me the basic reason for that requirement or please point me > to your discussion with Oleg (I missed that one :-) ). > Nevertheless I think that this is quite a big intrusion into the java code > and since all of the information needed is already in the > CollectionDescriptor of the M-side, I don't see a reason for doing it. > Cheers > Georg > _______________________________________________________________ > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Jakob B. <jbr...@ho...> - 2002-06-06 14:21:57
|
hi georg, this was a 'private' discussion, meaning we did not use the mailing-list. btw. im working on solution to solve this problem... jakob ----- Original Message ----- From: "Georg Schneider" <ge...@me...> To: "Jakob Braeuchi" <jbr...@ho...> Cc: <obj...@li...> Sent: Thursday, June 06, 2002 3:24 PM Subject: Re: MtoN-followup > Hi jacob, > > Could you give me the basic reason for that requirement or please point me > to your discussion with Oleg (I missed that one :-) ). > Nevertheless I think that this is quite a big intrusion into the java code > and since all of the information needed is already in the > CollectionDescriptor of the M-side, I don't see a reason for doing it. > > Cheers > > Georg > > > |
|
From: Carlos P. <Ca...@ad...> - 2002-06-06 13:56:36
|
I had the same problem with Oracle when using the ODMG API. I removed my usage of the API and it works with the Broker. My suspicion is that you have to modify the db-setup.sql to create the right OJB tables. Carlos -----Original Message----- From: David Forslund [mailto:dw...@la...] Sent: Wednesday, June 05, 2002 4:27 PM To: obj...@li... Subject: [OJB-developers] OJB_SEQ with Oracle Are people using the OJB_SEQ table with sequences in Oracle? When I try to create a sequence in Oracle, I get a failure: It is calling getNextId in SequenceManagerDefaultImpl and fails with a SQLexception: ORA-00001: unique contraint (COAS_SERER.SYS_C005581) violated. The table is created using the standard sql for SequenceEntry and the default xml repository mapping to OJB_SEQ. It is doing an insert of all the variables into the table but must be rejecting them because the key has already been filled and it things I'm trying to create another key with the same value. I think this was working with an earlier version of OJB. This problem is with OJB-0.8.400 Thanks, Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Georg S. <ge...@me...> - 2002-06-06 13:25:01
|
Hi jacob, Could you give me the basic reason for that requirement or please point me to your discussion with Oleg (I missed that one :-) ). Nevertheless I think that this is quite a big intrusion into the java code and since all of the information needed is already in the CollectionDescriptor of the M-side, I don't see a reason for doing it. Cheers Georg |
|
From: Jakob B. <jbr...@ho...> - 2002-06-06 12:23:31
|
hi georg, > Up to the last release this was possible, but now the entire MtoN-code > has been changed. Now an object A can have a collection of objects B, > but at the same time object B has to have a collection of objects A, > effectively linking A and B tightly together. If you want to have object > A to be part of a collection in an object C, you have to provide a > collection in object B pointing to objects C ..... yes that's true the relationship has to be bidirectional. i had long discussions with oleg nitz and we both came to this conclusion. but i see that tight coupling can be a problem. jakob ----- Original Message ----- From: "Georg Schneider" <ge...@me...> To: "Mahler Thomas" <tho...@it...> Cc: <jbr...@ho...>; <obj...@li...> Sent: Thursday, June 06, 2002 1:50 PM Subject: MtoN-followup > Hi Jacob and Thomas > > This is the follow-up to my previous mail talking about the > M:N-Relationship issue: > > OK, the basic issue is, that an object should be able to form part of > different collections. The basic example I give is that you could have > an Inventory object which contains a list of Articles, and ShoppingCart > objects which also contain a list of Articles. > I don't think that this is a minor feature, but it is simply the way > objects can be used in Java. > > Up to the last release this was possible, but now the entire MtoN-code > has been changed. Now an object A can have a collection of objects B, > but at the same time object B has to have a collection of objects A, > effectively linking A and B tightly together. If you want to have object > A to be part of a collection in an object C, you have to provide a > collection in object B pointing to objects C ..... > > Object B shouldn't have to know that it is part of a collection in an > M:N scenario. > > The only testcase for that MtoN-issue is testMNLoading() in MtoNMapping > which uses the Person-Project relationship, where Person has a > collection of Projects and Project has a collection of Persons. > > I have assembled a testcase which should check the form of > MtoN-relationships where the N-Class doesn't have a collection of > M-Objects. Of course it fails right away, but it would be a starting > point to analyze how to fix things. > > I have attached the following things: > > 1.) a method testMultipleMtoNRelations() which should go into the > MtoNMapping.java file > > 2.) the files Inventory.java and ShoppingCart.java which go into the same > directory > > 3.) the mapping for both classes which has to be added to > repository_junit.xml > > 4.) the create statement for the tables and indirection tables which has > to go into db-setup.sql > > Cheers > > Georg > |
|
From: Georg S. <ge...@me...> - 2002-06-06 11:51:01
|
Hi Jacob and Thomas
This is the follow-up to my previous mail talking about the
M:N-Relationship issue:
OK, the basic issue is, that an object should be able to form part of
different collections. The basic example I give is that you could have
an Inventory object which contains a list of Articles, and ShoppingCart
objects which also contain a list of Articles.
I don't think that this is a minor feature, but it is simply the way
objects can be used in Java.
Up to the last release this was possible, but now the entire MtoN-code
has been changed. Now an object A can have a collection of objects B,
but at the same time object B has to have a collection of objects A,
effectively linking A and B tightly together. If you want to have object
A to be part of a collection in an object C, you have to provide a
collection in object B pointing to objects C .....
Object B shouldn't have to know that it is part of a collection in an
M:N scenario.
The only testcase for that MtoN-issue is testMNLoading() in MtoNMapping
which uses the Person-Project relationship, where Person has a
collection of Projects and Project has a collection of Persons.
I have assembled a testcase which should check the form of
MtoN-relationships where the N-Class doesn't have a collection of
M-Objects. Of course it fails right away, but it would be a starting
point to analyze how to fix things.
I have attached the following things:
1.) a method testMultipleMtoNRelations() which should go into the
MtoNMapping.java file
2.) the files Inventory.java and ShoppingCart.java which go into the same
directory
3.) the mapping for both classes which has to be added to
repository_junit.xml
4.) the create statement for the tables and indirection tables which has
to go into db-setup.sql
Cheers
Georg
|
|
From: Georg S. <ge...@me...> - 2002-06-06 09:02:25
|
Hi Thomas and Jacob (and all others :-) ),
I think the following two issues are extremely important and should be
fixed as soon as possible. Since it might take some time to explain them
in detail I will first give a short introduction to both issues:
1.) Collections of Interfaces are not working: Currently there is no
testcase which checks this. If you look at the mapping for
test.ojb.broker.ProductGroup it contains a collection-descriptor with an
element-class-ref="test.ojb.broker.Article" which is wrong because if
you look at the ProductGroup class, it takes objects of interface
InterfaceArticle so the line should actually be
element-class-ref="test.ojb.broker.InterfaceArticle"
Ones you do that the whole junit testsuite blows up. I'll explain the
details and a possible fix further down.
2.) M:N relationships aren't working as they should. IMHO an M:N
relationship means that an object can be part of various "different"
collections. This was possible up to release 0.9 but has now been
changed. Let me be more specific. Let's say we have a class Article, a
Class ShoppingCart which contains a collection of Articles and another
class Inventory which also contains a collection of Articles. I'll
provide a TestCase for this + an explanation in my next mail.
ad 1.)
Please contact me if anything I write seems to be confusing or doesn't
seem clear (my thoughts might get carried away :-) )
The basic problem somewhat converges on one function in
ObjectReferenceDescriptor
public FieldDescriptor[] getForeignKeyFieldDescriptors(ClassDescriptor
mif)
this function is called on various occassions to obtain an array of
FieldDescriptors that contain the fields pointing to the 1 part of a 1:n
relationship.
The first problem is that, when the collection items are of an
"Interface" type (i.e. mif describes an interface) there are no
FieldDescriptors and a NullPointerException is thrown further down when
calling
..mif.getFieldDescriptorByIndex(...
so what we need is a concrete class which does have the fields. The
easiest way is to put the following code at the beginning of the
function:
if (mif.isInterface()) {
Vector extentClasses = mif.getExtentClasses();
Class itemClass = (Class) extentClasses.get(0);
mif = mif.getRepository().getDescriptorFor(itemClass);
}
This simply takes the first concrete class and uses their fields.
Unfortunately this is not the end of the story. The problem is that with
interfaces (as opposed to base classes) the "Fields" of one concrete
class can not be used to set the foreign-key "Fields" of another class
implementing the same Interface.
This is a rather subtle problem and it becomes easier to understand when
you look at the set(..) method in PersistentFieldDefaultImpl. There it
says:
try
{
f.set(obj, value);
}
catch (IllegalArgumentException ex)
f would be the the field obtained via the getForeignKeyFieldDescriptors
method mentioned above, obj is the concrete object for which the field
is set (the fk-field of the n-side) , and value is the value it is set
to (the primary key value of the 1-side).
As long as the item-class of the collection is a concrete class or a
base-class, but not an interface everything is fine. Java lets you use
the "Field"-objects of a base class, when setting them on a derived
class.
The same doesn't hold true if we are talking of different classes
implementing a common interface. The same "Field"-object obtained for
one class can not be used to set the field in another class also
implementing the interface. The consequence is an
IllegalArgumentException being thrown.
Going back to ObjectReferenceDescriptor the consequence is, that a new
array of FieldDescriptors has to be computed and returned for each
concrete classdescriptor (mif). This means the following if statements
has to be taken out (just the if, not the block itself)
if (foreignKeyFieldDescriptors == null)
{
......
}
because it computes the array only the first time and returns it
directly on subsequent calls (for performance reasons I suppose). For
performance reasons one could use a Hashtable to store already computed
FieldDescriptor arrays for concrete ClassDescriptors.
Now that we have a function that always returns the right array of
FieldDescriptors we have to make sure that it is also called with the
right class-descriptors.
The one place where that has to be changed is in TransactionImpl
In the method lockCollections(....
the following lines
ClassDescriptor itemCld =
this.getBroker().getClassDescriptor(cds.getItemClass());
FieldDescriptor[] itemFkFields = cds.getForeignKeyFieldDescriptors(itemCld);
are being called before the while (colIterator.hasNext()) loop
They have to be moved into the loop to work correctly:
while (colIterator.hasNext())
{
Object item = colIterator.next();
ClassDescriptor itemCld =
this.getBroker().getClassDescriptor(item.getClass());
FieldDescriptor[] itemFkFields =
cds.getForeignKeyFieldDescriptors(itemCld);
.......
So to come to a conclusion, in order to see the problem and its possible
fix you have to do the following:
1.) change the collection-descriptor in the mapping for ProductGroup to
element-class-ref="test.ojb.broker.InterfaceArticle"
this will make you see the problem when running the unit-tests
2.)
In ObjectReferenceDescriptor
in the method getForeignKeyFieldDescriptors(...
a) take out the if
b) put
if (mif.isInterface()) {
Vector extentClasses = mif.getExtentClasses();
Class itemClass = (Class) extentClasses.get(0);
mif = mif.getRepository().getDescriptorFor(itemClass);
}
at the beginning
3.) in TransactionImpl move the 2 lines into the loop as explained
above.
Cheers
Georg
|
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-05 22:14:33
|
Hi all, I think this question is for you thomas ! I'm having some problems mapping MtoN relations using indirection tables ! The repository.dtd that I have indirection-tables are atts of collection-descriptors. However I see this error message when ojb starts [Error] repository.xml:78:83: Attribute "indirection_table" must be declared for element type "inverse-foreignkey". is this right ? can you give an example to map A and B using table AB ? -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: David F. <dw...@la...> - 2002-06-05 20:27:31
|
Are people using the OJB_SEQ table with sequences in Oracle? When I try to create a sequence in Oracle, I get a failure: It is calling getNextId in SequenceManagerDefaultImpl and fails with a SQLexception: ORA-00001: unique contraint (COAS_SERER.SYS_C005581) violated. The table is created using the standard sql for SequenceEntry and the default xml repository mapping to OJB_SEQ. It is doing an insert of all the variables into the table but must be rejecting them because the key has already been filled and it things I'm trying to create another key with the same value. I think this was working with an earlier version of OJB. This problem is with OJB-0.8.400 Thanks, Dave |
|
From: Thomas M. <tho...@ho...> - 2002-06-05 20:20:12
|
Hi Leandro, These exceptions are declared in the interface PersistentField. Thus you will have to change the class PersistentFieldPropertyImpl too! I think it is OK to rethrow a PersistenceBrokerException here ! hth, Thomas Leandro Rodrigo Saad Cruz wrote: > I hope you can help me here ! > > I noticed that PBImpl has to deal with a large number of checked > exceptions because PersistentFieldDefaultImpl throws > IllegalAccessException in set() and get(). > As far as I know, PFDImpl is just a wrapper around Field, with the > semantics. What I would like to change is : make set() and get() in > PFDImpl throw PersistenceBrokerException in order to simplify error > handling in PBImpl but this changes the semantics of PFDImpl somewhat ! > > Any suggestions ? > > > On Wed, 2002-06-05 at 16:35, Thomas Mahler wrote: > >>hi Leandro, >> >>Leandro Rodrigo Saad Cruz wrote: >> >> >> >>>I trying to make ojb-1-0 work with my app. I can help you with the docs >>>if you want. >>> >>> >> >>fine! we have to make all existing documents match the new repository >>syntax. Please don't edit the src/doc/html files but only the files in >>the xdocs folder. The html docs will be generated from the xdocs! >> >> >> >>>I agree with you. One thing I'd like to change in OJB is exception >>>handling. There are many places where Throwable is caught ! That is no >>>good ! We could change the way exceptions are handled and provide better >>>error reporting/logging ! >>> >>>I voluntier to do that ! >>> >>> >> >>That's an important issue! feel free to work on this! >> >>cheers, >> >>Thomas >> >> >> >>>>cheers, >>>> >>>>Thomas >>>> >>>> >>>> >> >> >>_______________________________________________________________ >> >>Don't miss the 2002 Sprint PCS Application Developer's Conference >>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >>_______________________________________________ >>Objectbridge-developers mailing list >>Obj...@li... >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> |
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-05 20:11:12
|
I hope you can help me here ! I noticed that PBImpl has to deal with a large number of checked exceptions because PersistentFieldDefaultImpl throws IllegalAccessException in set() and get(). As far as I know, PFDImpl is just a wrapper around Field, with the semantics. What I would like to change is : make set() and get() in PFDImpl throw PersistenceBrokerException in order to simplify error handling in PBImpl but this changes the semantics of PFDImpl somewhat ! Any suggestions ? On Wed, 2002-06-05 at 16:35, Thomas Mahler wrote: > hi Leandro, > > Leandro Rodrigo Saad Cruz wrote: > > > > > > I trying to make ojb-1-0 work with my app. I can help you with the docs > > if you want. > > > > > fine! we have to make all existing documents match the new repository > syntax. Please don't edit the src/doc/html files but only the files in > the xdocs folder. The html docs will be generated from the xdocs! > > > > > > I agree with you. One thing I'd like to change in OJB is exception > > handling. There are many places where Throwable is caught ! That is no > > good ! We could change the way exceptions are handled and provide better > > error reporting/logging ! > > > > I voluntier to do that ! > > > > > That's an important issue! feel free to work on this! > > cheers, > > Thomas > > > > > >>cheers, > >> > >>Thomas > >> > >> > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-05 19:54:08
|
On Wed, 2002-06-05 at 16:35, Thomas Mahler wrote: > hi Leandro, > > Leandro Rodrigo Saad Cruz wrote: > > > > > > I trying to make ojb-1-0 work with my app. I can help you with the docs > > if you want. > > > > > fine! we have to make all existing documents match the new repository > syntax. Please don't edit the src/doc/html files but only the files in > the xdocs folder. The html docs will be generated from the xdocs! > > > > > > I agree with you. One thing I'd like to change in OJB is exception > > handling. There are many places where Throwable is caught ! That is no > > good ! We could change the way exceptions are handled and provide better > > error reporting/logging ! > > > > I voluntier to do that ! > > > > > That's an important issue! feel free to work on this! > > cheers, > > Thomas > > > > > >>cheers, > >> > >>Thomas > >> > >> > Ok. I'll do that as soon as my app work with ojb-0.9. I started to work with PersistenceBrokerImpl exceptions -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Thomas M. <tho...@ho...> - 2002-06-05 19:41:29
|
-------- Original Message -------- Subject: [objectbridge - Help] Date: Wed, 05 Jun 2002 12:40:24 -0700 From: no...@so... To: no...@so... Read and respond to this message at: http://sourceforge.net/forum/message.php?msg_id=1587370 By: thma ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge and visit: http://sourceforge.net/forum/monitor.php?forum_id=43067 |
|
From: Thomas M. <tho...@ho...> - 2002-06-05 19:35:50
|
hi Leandro, Leandro Rodrigo Saad Cruz wrote: > > I trying to make ojb-1-0 work with my app. I can help you with the docs > if you want. > fine! we have to make all existing documents match the new repository syntax. Please don't edit the src/doc/html files but only the files in the xdocs folder. The html docs will be generated from the xdocs! > > I agree with you. One thing I'd like to change in OJB is exception > handling. There are many places where Throwable is caught ! That is no > good ! We could change the way exceptions are handled and provide better > error reporting/logging ! > > I voluntier to do that ! > That's an important issue! feel free to work on this! cheers, Thomas > >>cheers, >> >>Thomas >> >> |
|
From: Thomas M. <tho...@ho...> - 2002-06-05 19:35:50
|
Hi Joachim, Joa...@tp... wrote: > Hy, > > I once again stumbled over a case where the root exception is lost. This > time it's in the ODMB-Implementation and throwing a ODMB-Exception which > make the case a bit more complicated. > > My question is: Is it possible/legal to modify or subclass the > ODMG-Exceptions while still beeing a compliant Implementation? (I don't > have the ODMG-Standard (actually, I just found Version 1.2 of the Standard > from 1993 some days ago for 2 Euro and bought it, but it doesn't have > Java-Mappings in this Version ;-)). I did not find any statement in the ODMG spec that disallows subclassing for exceptions. So IMO it will be pretty OK to provide our own exceptions. > > If this is not possible, we could introduce an Exception-Helper that let > us set the cause for non-OJB-Exceptions without changeing their code. This > class would do almost the exact same thing as what my Patch for > PersistenceBrokerException does. > > I'd like to ask you what you think of such a class. Additionally I'd like > to ask if this counts as a new "Feature" and therefore is forbidden, due > to feature freeze. > Mor me this is clearly a bug fix and not a new feature. Also, I don't think we have a real code freeze. I just placed a remark in the release-notes requesting user not to urge us to implement new features until 1.0. This will reduce the pressure on the development team and allow us to concentrate on fixing bugs, stabilizing the codebase, completing documentation etc. (If you have a cool new feature I don't see why it should not be added before 1.0). cheers, Thomas > regards > Joachim Sauer > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-05 18:02:39
|
On Tue, 2002-06-04 at 04:51, Mahler Thomas wrote: > Hi all, Hi > =20 > after some minor problems I managed to assemble a new release. > As I had to fix several bugs to get this release stable, I did not find t= he > time to keep the documentation up to date. > In particular the documentation regarding the repository is out of sync d= ue > to the redesigned repository.dtd. I trying to make ojb-1-0 work with my app. I can help you with the docs if you want. > =20 > Lasse Lindg=E5rd wrote a stylesheet to transform existing repositories to= the > new syntax. I hope this will help users to migrate quickly! >=20 > >From the relase notes: >=20 > Changes in Release 0.9 >=20 >=20 >=20 > new features: > ... > bug fixes: > ... > Refactorings: > ... >=20 > With this release we are feature complete for the 1.0 release! >=20 > For 1.0 you should not expect more features to be added. >=20 I agree with you. One thing I'd like to change in OJB is exception handling. There are many places where Throwable is caught ! That is no good ! We could change the way exceptions are handled and provide better error reporting/logging ! I voluntier to do that ! >=20 > cheers, > =20 > Thomas > =20 --=20 Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Jason v. Z. <jv...@ze...> - 2002-06-05 13:36:14
|
> On Wed, 2002-06-05 at 08:38, Mahler Thomas wrote: > Hi Jason: > > One more question: shall we do the package renaming *before* you setup up > the new repository? > Or is it better to do it later? I can do it once the code is moved. I've got some scripts to handle it. > cheers, > > Thomas -- jvz. Jason van Zyl jv...@ap... http://tambora.zenplex.org |
|
From: Chris G. <CGr...@de...> - 2002-06-05 13:20:42
|
Hear, hear! +1 for b, and please do the code beautifier. :) Cheers, Chris > > +1 for b, and maybe do the code beautifier to remove extra lines at the > same time :) > tr...@th... wrote: +1 for b > > Travis |
|
From: Jakob B. <jbr...@ho...> - 2002-06-05 13:17:22
|
hi , i vote for b.) jakob ----- Original Message ----- From: "Thomas Mahler" <tho...@ho...> To: "Jason van Zyl" <jv...@ze...>; "ojb" <obj...@li...> Sent: Tuesday, June 04, 2002 10:58 PM Subject: [OJB-developers] Shifting to Jakarta > Hi Jason, > > I fixed all the problems at last and released ojb-0-9 today! > So now we can begin our shift to Jakarta. > > 1. The OJB developer list. below you find a list of our active > developers. Please set up CVS on the jakarta servers for all of them. > > armin_w (armin waibel) > arobinson (Andrew Robinson) > baserose (Leandro Rodrigo Saad Cruz) > brj (Jakob Braeuchi) > ceperez (Carlos E. Perez) > cgreenlee (Chris Greenlee) > chrath (Christian Rath) > dariusschier (Darius Schier) > dpeugh (David Dixon-Peugh) > florianbruckner (Florian Bruckner) > gcole (George Cole) > hhoang (Hai Hoang) > jvanzyl (Jason van Zyl) > mattbaird (Matthew Baird) > mpoeschl (Martin Poeschl) > neoflux (Matthew Porter) > olegnitz (Oleg Nitz) > pinkcoder (Angela Robertson) > prophecyslides (Travis Reeder) > saua (Joachim Sauer) > thma (Thomas Mahler) > vtx1800 (Dale Davis) > > The sourceforge account is also the email account (user vtx1800 can be > reached by vt...@us...). > > [I removed two accounts, namely > bigrana (Daniele de Petris) > garf (Jon Garfunkel) > as they have been absent for more than year now. ] > > 2. Moving of the code > This may be a bit tricky as there is permanent activity on our CVS > repository. > I see two options: > > a. start to migrate the ojb0.9 state of the repository (marked by a > version lable "rel-0-9") to see if everything is OK. > If everything is fine we can checking the changes since rel-0-9. > This approach will allow developers to checkin stuff while you set up > everything in parallel. Disadvantage: getting things in sync will be > quite a burden. > > b. we have to define a frozen zone where no one should checkin stuff > into the *old* sf repository. You do the migration of the code. > After you have finished this job, everyone is informed to work against > the *new* repository. > This will reduce migration problems like running out of sync. > Disadvantage: the developers can't check in code for some time. > > (I vote for b. But of course it's up to you.) > > I hope I did not forget any important issues :-) > > thanks for your help, > > Thomas > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Mahler T. <tho...@it...> - 2002-06-05 12:38:27
|
Hi Jason: One more question: shall we do the package renaming *before* you setup up the new repository? Or is it better to do it later? cheers, Thomas |
|
From: <Joa...@tp...> - 2002-06-05 12:21:33
|
Hy, I once again stumbled over a case where the root exception is lost. This time it's in the ODMB-Implementation and throwing a ODMB-Exception which make the case a bit more complicated. My question is: Is it possible/legal to modify or subclass the ODMG-Exceptions while still beeing a compliant Implementation? (I don't have the ODMG-Standard (actually, I just found Version 1.2 of the Standard from 1993 some days ago for 2 Euro and bought it, but it doesn't have Java-Mappings in this Version ;-)). If this is not possible, we could introduce an Exception-Helper that let us set the cause for non-OJB-Exceptions without changeing their code. This class would do almost the exact same thing as what my Patch for PersistenceBrokerException does. I'd like to ask you what you think of such a class. Additionally I'd like to ask if this counts as a new "Feature" and therefore is forbidden, due to feature freeze. regards Joachim Sauer |
|
From: Jakob B. <jbr...@ho...> - 2002-06-05 05:50:50
|
hi georg, your testcase and the fix are now in cvs. how can a bug like this survive such a long time ? it's due to the lack of a decent testcase ! my own private 'testcase' has a proxy reference from person to person (theBoss) so it simply didn't matter if the wrong class was taken to build the proxy :( thanks a lot jakob ----- Original Message ----- From: "Georg Schneider" <ge...@me...> To: "Mahler Thomas" <tho...@it...> Cc: <obj...@li...> Sent: Tuesday, June 04, 2002 4:30 PM Subject: [OJB-developers] reference proxies not working > Hi Thomas, > > I just tried out the new release and I noticed that reference proxies are > still not working due to a bug I mentioned in the following posting > > http://sourceforge.net/mailarchive/forum.php?thread_id=664723&forum_id=4880 > > Please correct me if I am wrong, but there seems to be no testcase testing > reference proxies, so I constructed one and attached it to this posting. > If you run that testcase you should see an IllegalArgumentException being > thrown, which should disappear when fixing the code as mentioned in the > posting (btw, there is a typo in my posting, it should be > referencedProxy=null, and not referenceProxy=null :-) ) > > The get the testcase running you have to do 3 things: > > 1.) put the ArticleWithReferenceProxy.java file from the attachement into > the test/ojb/broker/ directory (the class simply extends Article, so I can > put a new mapping into the repository) > > 2.) add the mapping-xml from the attachement to the repository_junit.xml > file. The mapping is basically a copy of the mapping for the > Article-class, the major difference being the addition of proxy="true" for the reference-descriptor > for productGroup > > 3.) add the method testReferenceProxies() from the attachement to the > ProxyExample class in the test/ojb/broker/ directory > > > Cheers > > Georg > |
9 messages has been excluded from this view by a project administrator.
