objectbridge-developers — public list for developer issues

[OJB-developers] ObjectBridge & Torque

[Jason v. Z. <jv...@ze...>]

Hello,

To try and stimulate some cross-pollentation between the Torque and
ObjectBridge groups I've created a separate Torque mailing list so that
it will be easier to follow any discussions if anyone here is
interested.

The mailing lists are:

tur...@ja...
tur...@ja...

-- 
jvz.

Jason van Zyl
jv...@ap...

http://tambora.zenplex.org

Re: [OJB-developers] Help with MS SQL Server

[Chris G. <CGr...@de...>]

Anil,

You need to modify the build.xml file, changing the tag

<property name="HSSQLDB" value="+HSSQLDB"/>

to

<property name="HSSQLDB" value="-HSSQLDB"/>

and changing

<property name="MSSQLSERVER2000" value="-MSSQLSERVER2000"/>

to

<property name="MSSQLSERVER2000" value="+MSSQLSERVER2000"/>

This will cause the preprocessor that OJB uses to modify the db-setup.xml
file to include the correct information.  You also need to go into the
db-setup.sql file to make sure the JDBC connection info in the
MSSQLSERVER2000 section is setup correctly.

Cheers,

Chris Greenlee

> Hi,
> I am new to OJB. I need help configuring with MS SQL Server.
> I modified repository.xml file to use proper driver and commented out
> hsqldb, still when I run ant tests, its picking up hsqldb ? I would
> appreciate if anyone can help me out.
>
> Thanks,
>
> Anil Kona
> Software Engineer
> Motiva, Inc.
> ani...@mo...
> (925) 600-2928 (Work)
> (925) 209-7972  (Mobile)
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] Warning on Oracle

[Jakob B. <jbr...@ho...>]

hi eric,

i agree.
the warning about the missing constructor "[DEFAULT] WARN: Please define a
public constructor for class ..."
should also be changed to INFO.

jakob


----- Original Message -----
From: "Eric Bieschke" <EBi...@sa...>
To: <obj...@li...>
Sent: Monday, April 01, 2002 9:11 PM
Subject: Re: [OJB-developers] Warning on Oracle


> Given the amount of confusion over this WARNing, and the fact that this
> behavior is expected and not problematic; I'd vote for this message to log
> at level INFO rather than WARN.
>
> -- Eric Bieschke
>
>
> ----- Original Message -----
> From: David Sean Taylor <da...@bl...>
> To: <obj...@li...>
> Sent: Monday, April 01, 2002 12:16 AM
> Subject: [OJB-developers] Warning on Oracle
>
>
> Why do I get these messages?
> What kind of problems are there with Oracle8i....
>
> WARN: problems with platform ojb.broker.platforms.Platform
> Oracle8iImpl: ojb.broker.platforms.PlatformOracle8iImpl
> WARN: OJB will use PlatformDefaultImpl instead
>
>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] Help with MS SQL Server

[Anil K. <Ani...@mo...>]

Hi,
I am new to OJB. I need help configuring with MS SQL Server.
I modified repository.xml file to use proper driver and commented out =
hsqldb, still when I run ant tests, its picking up hsqldb ?
I would appreciate if anyone can help me out.

Thanks,

Anil Kona=20
Software Engineer
Motiva, Inc.
ani...@mo...
(925) 600-2928 (Work)
(925) 209-7972  (Mobile)

Re: [OJB-developers] Warning on Oracle

[Eric B. <EBi...@sa...>]

Given the amount of confusion over this WARNing, and the fact that this
behavior is expected and not problematic; I'd vote for this message to log
at level INFO rather than WARN.

-- Eric Bieschke


----- Original Message -----
From: David Sean Taylor <da...@bl...>
To: <obj...@li...>
Sent: Monday, April 01, 2002 12:16 AM
Subject: [OJB-developers] Warning on Oracle


Why do I get these messages?
What kind of problems are there with Oracle8i....

WARN: problems with platform ojb.broker.platforms.Platform
Oracle8iImpl: ojb.broker.platforms.PlatformOracle8iImpl
WARN: OJB will use PlatformDefaultImpl instead

[OJB-developers] Which CVS directory?

[John F. <jfr...@so...>]

I'm going to be using the PB layer directly within a Tomcat 4 servlet
environment.

If I'm looking to contribute code in anyway, which directory should I be
refreshing and then building from/running tests out of?  I see a few to
level dirs in CVS via the web browser interface:

objectbridge
ojb
ojb-1
ojb-1-0

Maybe a readme.txt at this level would help newbies like me.

Thanks,
 - John Freeborg

Re: [OJB-developers] Warning on Oracle

[Jakob B. <jbr...@ho...>]

hi david,

this is just a warning that there's no oracle specific platform class.
ojb will work normally with the default platform.

hth jakob

----- Original Message ----- 
From: "David Sean Taylor" <da...@bl...>
To: <obj...@li...>
Sent: Monday, April 01, 2002 10:16 AM
Subject: [OJB-developers] Warning on Oracle


> Why do I get these messages?
> What kind of problems are there with Oracle8i....
> 
> WARN: problems with platform ojb.broker.platforms.Platform
> Oracle8iImpl: ojb.broker.platforms.PlatformOracle8iImpl
> WARN: OJB will use PlatformDefaultImpl instead
> 
> 
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

[OJB-developers] db-setup.sql

[David S. T. <da...@bl...>]

Hi,

There is a strange (to me) format to the db-setup.sql file, prefixed
commands like:

e CREATE TABLE OJB_HL_SEQ (

Guessing there is some database-agnostic-script runner tool or
something...If so, how do I run it?
Is there documentation?

I've started to make my own database, and Im wondering how much of the
db-setup.sql file I will actually need.
Assuming I need everything from here down:

;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;
; OJB internal tables, do not modify !!!

Only added these two tables thus far, which were necessary for inserts
with autoincrement fields:

 CREATE TABLE OJB_SEQ (
 CREATE TABLE OJB_HL_SEQ (

Thanks,

David

[OJB-developers] Warning on Oracle

[David S. T. <da...@bl...>]

Why do I get these messages? 
What kind of problems are there with Oracle8i....

WARN: problems with platform ojb.broker.platforms.Platform
Oracle8iImpl: ojb.broker.platforms.PlatformOracle8iImpl
WARN: OJB will use PlatformDefaultImpl instead

[OJB-developers] finding the repository.xml on the file system

[David S. T. <da...@bl...>]

PersistenceBrokerFactory.createPersistenceBroker("repository.xml");
 
Is there a way to find the repository.xml on the file system and not in
the classpath?
 
Currently I seem to only have the choice of putting the repository.xml
on my classpath, and then it searches for it using loadResource
 
thanks
 
David

[OJB-developers] Build improvements

[Chris G. <CGr...@de...>]

Hey all,

In order to improve the build process for OJB, and maybe make things a
little easier both on users and developers, I think it might be a good
idea to use Maven (http://jakarta.apache.org/turbine/maven).  It would
take a bit of work, but if no one minds, I'd like to take a stab at it.
Jason van Zyl, one of the developers of Maven, has offered his help.

I think that looking forward to a 1.0 release of OJB, having a slick
build process for the source, docs, and website is a must.

Comments?

Chris Greenlee

[OJB-developers] AW: [Fwd: RE: next release]

[Mahler T. <tho...@it...>]

Hi Matthew,

sorry for the last mail, I just pressed "send" before typing anything.

> 
> within OJB, would it be possible to use the metadata to find 
> all objects 
> that could reference an object of a certain class.
>

Yes, The metadata layer is meant for such computations!

By ojb.broker.metadata.DescriptorRepository.getInstance().iterator()

you can obtain an Iterator over all ClassDescriptor objects in the
Repository.
You can walk through all ClassDecsriptors and check if they have
ReferenceDescriptors or CollectionDescriptors pointing to your class.

cu,

Thomas

 
> for instance. I have an object com.foo.SomeObject with ID=5
> 
> I want to write some generic code that goes through all the class 
> mappings and finds anyplace where another object has a mapped 
> instance 
> of SomeObject, then I'll generate the OQL to do a query to 
> see which of 
> that object references a SomeObject with ID=5.
> 
> thanks.
> Matthew
> 
> -----Original Message-----
> From: Thomas Mahler [mailto:tho...@ho...]
> Sent: Wednesday, March 27, 2002 1:33 PM
> To: Matthew Baird; ojb
> Subject: Re: next release
> 
> 
> Hi Matthew,
> 
> 
> <snip>
> 
> 
> 
>  > There is already a JTA implementation for the PersistenceBroker API
>  > contributed by another JBOSS / OJB user. It's working but 
> it's currently
>  > not part of the distribution. It also won't be included in the next
>  > release. If you like I can post you Armins's stuff!
>  >
>  >
>  >>Please do.
> 
> 
> attached you'll find Armin's code for JTA Integration. He 
> even included
> a sample ejb "OfferingManagerBean.java", which uses his JTA 
> infrastructure.
> 
> I like his well structured approach. There are some unresolved
> references in his code (e.g. to a Factory-class de.cal.base.Creator),
> but these can be replaced without too much efforts.
> 
> 
>  >>
>  >
>  > Jesper is working on a proposal for a complete JCA 
> integrated solution.
>  > We will take this as the base for further developments 
> towards JCA / JTA.
>  >
>  > But I can't give you any estimation when this will be finished.
>  >
>  > We want to make OJB the definite O/R solution for JBOSS! 
> That's why we
>  > take the JCA integration so serious.
>  >
>  >
>  >>You should talk to Oleg Nitz. I'm sure they would love to have a 
> JBossJDO solution, and yours could be it!.
>  >>
> 
> 
> Oleg is from the JBOSS team? Do you have his email address?
> 
> 
>  >
>  > If you had to guess on a 1.0 release when would that be?
>  >
> 
> 
> There are only very few features missing for 1.0.
> The biggest open issue is a redesign of the repository dtd.
> Once this is finished we are at 0.9
>   From 0.9 to 1.0 I want to have some kind of frozen zone 
> where only bug
> fixes and documentation may be added.
> 
> The JTA / JCA stuff is not scheduled for 1.0 but if we can finish it
> quickly we will of course include it.
> I want to have 1.0 released soon. May or June might be a 
> realistic estimate.
> 
> 
>  > If we pursue this, we are going to write a "castor to ojb" mapping 
> file translator that I'd love to contribute to help people move from 
> Castor to OJB.
>  >
> 
> 
> Yes, that could be helpful for several people !
> 
> cu,
> 
> 
> Thomas
> 
> 
> 
> 

[OJB-developers] AW: [Fwd: RE: next release]

[Mahler T. <tho...@it...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Thomas Mahler [mailto:tho...@ho...]
> Gesendet: Donnerstag, 28. M=E4rz 2002 07:28
> An: tom
> Betreff: [Fwd: RE: next release]
>=20
>=20
>=20
>=20
> -------- Original Message --------
> Subject: RE: next release
> Date: Wed, 27 Mar 2002 14:55:53 -0800
> From: "Matthew Baird" <Mat...@mo...>
> To: "Thomas Mahler" <tho...@ho...>
>=20
> within OJB, would it be possible to use the metadata to find=20
> all objects=20
> that could reference an object of a certain class.
>=20
> for instance. I have an object com.foo.SomeObject with ID=3D5
>=20
> I want to write some generic code that goes through all the class=20
> mappings and finds anyplace where another object has a mapped=20
> instance=20
> of SomeObject, then I'll generate the OQL to do a query to=20
> see which of=20
> that object references a SomeObject with ID=3D5.
>=20
> thanks.
> Matthew
>=20
> -----Original Message-----
> From: Thomas Mahler [mailto:tho...@ho...]
> Sent: Wednesday, March 27, 2002 1:33 PM
> To: Matthew Baird; ojb
> Subject: Re: next release
>=20
>=20
> Hi Matthew,
>=20
>=20
> <snip>
>=20
>=20
>=20
>  > There is already a JTA implementation for the PersistenceBroker =
API
>  > contributed by another JBOSS / OJB user. It's working but=20
> it's currently
>  > not part of the distribution. It also won't be included in the =
next
>  > release. If you like I can post you Armins's stuff!
>  >
>  >
>  >>Please do.
>=20
>=20
> attached you'll find Armin's code for JTA Integration. He=20
> even included
> a sample ejb "OfferingManagerBean.java", which uses his JTA=20
> infrastructure.
>=20
> I like his well structured approach. There are some unresolved
> references in his code (e.g. to a Factory-class de.cal.base.Creator),
> but these can be replaced without too much efforts.
>=20
>=20
>  >>
>  >
>  > Jesper is working on a proposal for a complete JCA=20
> integrated solution.
>  > We will take this as the base for further developments=20
> towards JCA / JTA.
>  >
>  > But I can't give you any estimation when this will be finished.
>  >
>  > We want to make OJB the definite O/R solution for JBOSS!=20
> That's why we
>  > take the JCA integration so serious.
>  >
>  >
>  >>You should talk to Oleg Nitz. I'm sure they would love to have a=20
> JBossJDO solution, and yours could be it!.
>  >>
>=20
>=20
> Oleg is from the JBOSS team? Do you have his email address?
>=20
>=20
>  >
>  > If you had to guess on a 1.0 release when would that be?
>  >
>=20
>=20
> There are only very few features missing for 1.0.
> The biggest open issue is a redesign of the repository dtd.
> Once this is finished we are at 0.9
>   From 0.9 to 1.0 I want to have some kind of frozen zone=20
> where only bug
> fixes and documentation may be added.
>=20
> The JTA / JCA stuff is not scheduled for 1.0 but if we can finish it
> quickly we will of course include it.
> I want to have 1.0 released soon. May or June might be a=20
> realistic estimate.
>=20
>=20
>  > If we pursue this, we are going to write a "castor to ojb" mapping =

> file translator that I'd love to contribute to help people move from=20
> Castor to OJB.
>  >
>=20
>=20
> Yes, that could be helpful for several people !
>=20
> cu,
>=20
>=20
> Thomas
>=20
>=20
>=20
>=20

Re: AW: [OJB-developers] regression tests

[Thomas M. <tho...@ho...>]

Hi Chris,

Chris Greenlee wrote:

> If you'd like, I'll write a task similar to the "update-jars" task in
> the jakarta-torque build file that will download the appropriate jars
> from their respective sites.
> =20


That's a very good idea. I was not aware that this is possible.
(But I have to admit that there is not much that ANT can do!)

thanks for your efforts,

Thomas


> Cheers,
> =20
> Chris
>=20
> -----Original Message-----
> From: Mahler Thomas [mailto:tho...@it...]
> Sent: Wednesday, March 27, 2002 6:16 AM
> To: 'Fabian B=FCttner'; obj...@li...
> Subject: AW: AW: [OJB-developers] regression tests
>=20
>=20
> Hi again Fabian,
> =20
> =20
>=20
> Well now I am the one responding late, since I was on holidays for two
> weeks :)
>=20
> I need three additional jar files to run the JUnitReport task
>=20
>         jakarta-ant-1.4.1-optional.jar
>=20
> from: http://jakarta.apache.org/ant <http://jakarta.apache.org/ant>  .
> This archive contains the task. And
>=20
>         xalan.jar              =20
>         xml-apis.jar
>=20
> from: http://xml.apache.org/xalan-j/ <http://xml.apache.org/xalan-j/>  .
> The first one contains the xalan xml transformator, the second the xml
> apis for several apache projects.
>=20
>=20
> =20
> Mhh, As I said in my last mail, I like the nice output of you
> JunitReport sample!
> But:=20
> ant-optional.jar is about 460 KB,
> Xalan and Xerces are even > 1Meg.
> =20
> I don't want to blow up the OJB source distribution by a factor 2 or 3
> only for some nice-to-have report-formatting!=20
>=20
>=20
> If there is interest I can write some new targets for build.xml that us=
e
> the <JUnit> and <JUnitReport> tasks.
>=20
> Yes, I'm still interested. Maybe we can just have the targets in the
> build.xml file, but don't provide the necessary jars...
> =20
> cu,
> =20
> Thomas
> =20
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
>=20
>=20
>=20

[OJB-developers] Re: next release

[Thomas M. <tho...@ho...>]

Hi Matthew,


<snip>



> There is already a JTA implementation for the PersistenceBroker API 
> contributed by another JBOSS / OJB user. It's working but it's currently 
> not part of the distribution. It also won't be included in the next 
> release. If you like I can post you Armins's stuff!
> 
> 
>>Please do.


attached you'll find Armin's code for JTA Integration. He even included 
a sample ejb "OfferingManagerBean.java", which uses his JTA infrastructure.

I like his well structured approach. There are some unresolved 
references in his code (e.g. to a Factory-class de.cal.base.Creator), 
but these can be replaced without too much efforts.


>>
> 
> Jesper is working on a proposal for a complete JCA integrated solution. 
> We will take this as the base for further developments towards JCA / JTA.
> 
> But I can't give you any estimation when this will be finished.
> 
> We want to make OJB the definite O/R solution for JBOSS! That's why we 
> take the JCA integration so serious.
> 
> 
>>You should talk to Oleg Nitz. I'm sure they would love to have a JBossJDO solution, and yours could be it!.
>>


Oleg is from the JBOSS team? Do you have his email address?


> 
> If you had to guess on a 1.0 release when would that be?
> 


There are only very few features missing for 1.0.
The biggest open issue is a redesign of the repository dtd.
Once this is finished we are at 0.9
 From 0.9 to 1.0 I want to have some kind of frozen zone where only bug 
fixes and documentation may be added.

The JTA / JCA stuff is not scheduled for 1.0 but if we can finish it 
quickly we will of course include it.
I want to have 1.0 released soon. May or June might be a realistic estimate.


> If we pursue this, we are going to write a "castor to ojb" mapping file translator that I'd love to contribute to help people move from Castor to OJB.
>


Yes, that could be helpful for several people !

cu,


Thomas

RE: AW: [OJB-developers] regression tests

[Chris G. <CGr...@de...>]

If you'd like, I'll write a task similar to the "update-jars" task in
the jakarta-torque build file that will download the appropriate jars
from their respective sites.
=20
Cheers,
=20
Chris

-----Original Message-----
From: Mahler Thomas [mailto:tho...@it...]
Sent: Wednesday, March 27, 2002 6:16 AM
To: 'Fabian B=FCttner'; obj...@li...
Subject: AW: AW: [OJB-developers] regression tests


Hi again Fabian,
=20
=20

Well now I am the one responding late, since I was on holidays for two
weeks :)

I need three additional jar files to run the JUnitReport task

        jakarta-ant-1.4.1-optional.jar

from: http://jakarta.apache.org/ant <http://jakarta.apache.org/ant>  .
This archive contains the task. And

        xalan.jar              =20
        xml-apis.jar

from: http://xml.apache.org/xalan-j/ <http://xml.apache.org/xalan-j/>  .
The first one contains the xalan xml transformator, the second the xml
apis for several apache projects.


=20
Mhh, As I said in my last mail, I like the nice output of you
JunitReport sample!
But:=20
ant-optional.jar is about 460 KB,
Xalan and Xerces are even > 1Meg.
=20
I don't want to blow up the OJB source distribution by a factor 2 or 3
only for some nice-to-have report-formatting!=20


If there is interest I can write some new targets for build.xml that use
the <JUnit> and <JUnitReport> tasks.

Yes, I'm still interested. Maybe we can just have the targets in the
build.xml file, but don't provide the necessary jars...
=20
cu,
=20
Thomas
=20

AW: AW: [OJB-developers] regression tests

[Mahler T. <tho...@it...>]

Hi again Fabian,
 
 

Well now I am the one responding late, since I was on holidays for two weeks
:)

I need three additional jar files to run the JUnitReport task

        jakarta-ant-1.4.1-optional.jar

from: http://jakarta.apache.org/ant <http://jakarta.apache.org/ant>  . This
archive contains the task. And

        xalan.jar               
        xml-apis.jar

from: http://xml.apache.org/xalan-j/ <http://xml.apache.org/xalan-j/>  . The
first one contains the xalan xml transformator, the second the xml apis for
several apache projects.


 
Mhh, As I said in my last mail, I like the nice output of you JunitReport
sample!
But: 
ant-optional.jar is about 460 KB,
Xalan and Xerces are even > 1Meg.
 
I don't want to blow up the OJB source distribution by a factor 2 or 3 only
for some nice-to-have report-formatting! 

If there is interest I can write some new targets for build.xml that use the
<JUnit> and <JUnitReport> tasks.

Yes, I'm still interested. Maybe we can just have the targets in the
build.xml file, but don't provide the necessary jars...
 
cu,
 
Thomas
 

[OJB-developers] [FYI: RE: next release]

[Thomas M. <tho...@ho...>]

-------- Original Message --------
Subject: RE: next release
Date: Tue, 26 Mar 2002 13:44:03 -0800
From: "Matthew Baird" <Mat...@mo...>
To: "Thomas Mahler" <tho...@ho...>

Matthew Baird wrote:

 > Hi... we're considering moving from Castor to ObjectBridge.
What are your specific problems with Castor?

1. No way to use it in a distributed mode, the cache is tied to the 
lockmanager and doesn't even have "evict" functionality.
2. Slow
3. not actively being developed. We are paying Oleg Nitz to add 
features/fix for us, but in honesty, I'd rather have him work on your 
code, it is much better.
4. bugs get re-introduced into the code a lot as they have very few test 
cases
5. No support for lazy loading or proxies
6. Inheritence doesn't really work.
7. Code is terribly over-complex and hard to read/modify.


 > We have over 200 mapped objects, we are *very* transaction
 > heavy.

OK!

 > we have over 2000 test cases (junit) for our application, that stress 
every aspect of it. We use 1-1, 1-many many-many relations. We are going 
to abstract our use from Castor, then implement an adapter to use the 
OMDG interface of Objectbridge, until JDO is ready. It will be 
interesting to see if the application "just works" through all the OQL 
we use.

The next revision will be released within the next week.

GREAT!

and when is
 > the full support for j2ee planned?
 >


We have already implemented several things to make J2EE integration
smooth (JNDI lookup of Datasources, BMP support, using ClassLoader
resource lookup instead of filesystem access).

But currently OJB does not provide JTA and JCA Integration.

There is already a JTA implementation for the PersistenceBroker API
contributed by another JBOSS / OJB user. It's working but it's currently
not part of the distribution. It also won't be included in the next
release. If you like I can post you Armins's stuff!

 > Please do.

Jesper is working on a proposal for a complete JCA integrated solution.
We will take this as the base for further developments towards JCA / JTA.

But I can't give you any estimation when this will be finished.

We want to make OJB the definite O/R solution for JBOSS! That's why we
take the JCA integration so serious.

 > You should talk to Oleg Nitz. I'm sure they would love to have a 
JBossJDO solution, and yours could be it!.

If you had to guess on a 1.0 release when would that be?

If we pursue this, we are going to write a "castor to ojb" mapping file 
translator that I'd love to contribute to help people move from Castor 
to OJB.

m

[OJB-developers] Re: next release

[Thomas M. <tho...@ho...>]

Hi Matthew,


Matthew Baird wrote:

> Hi... we're considering moving from Castor to ObjectBridge. 


What are your specific problems with Castor?


> We have over 200 mapped objects, we are *very* transaction 
> heavy. 



OK!

We run inside JBoss, so I was wondering what is the 
> estimate on the next revision to be released, 


The next revision will be released within the next week.

and when is 
> the full support for j2ee planned?
> 


We have already implemented several things to make J2EE integration 
smooth (JNDI lookup of Datasources, BMP support, using ClassLoader 
resource lookup instead of filesystem access).

But currently OJB does not provide JTA and JCA Integration.

There is already a JTA implementation for the PersistenceBroker API 
contributed by another JBOSS / OJB user. It's working but it's currently 
not part of the distribution. It also won't be included in the next 
release. If you like I can post you Armins's stuff!

Jesper is working on a proposal for a complete JCA integrated solution. 
We will take this as the base for further developments towards JCA / JTA.

But I can't give you any estimation when this will be finished.

We want to make OJB the definite O/R solution for JBOSS! That's why we 
take the JCA integration so serious.

best regards,

Thomas

Re: AW: [OJB-developers] regression tests

[Fabian <f_b...@ma...>]

Well now I am the one responding late, since I was on holidays for two weeks=
 :)

I need three additional jar files to run the JUnitReport task

         jakarta-ant-1.4.1-optional.jar

from: http://jakarta.apache.org/ant . This archive contains the task. And

         xalan.jar
         xml-apis.jar

from: http://xml.apache.org/xalan-j/ . The first one contains the xalan xml=
=20
transformator, the second the xml apis for several apache projects.

As I mentioned in my last mail, ojb currently uses a java-task to run the=20
regression tests. There is a special junit-task in the optional ant jar=
 file.
Using this task should make the build file flexible I think. This task can=
=20
run complete suites as well as single tests (see documentation at the ant=20
site) and can produce xml output as well as standard text.
The JUnitReport generated web site (other output than html can easily made=
=20
using a custom xslt-file for the xml transformation) reflects the choosen=20
test structure (suites vs. single tests).

If there is interest I can write some new targets for build.xml that use=20
the <JUnit> and <JUnitReport> tasks.

Fabian B=FCttner


At 15:31 12.03.02 +0100, Mahler Thomas wrote:
>Hi Fabian,
>
>I'm a bit late in responding to your mail.
>But I'm really interested in this kind of thing, as the presentation of=20
>results is quite readable and provides much better information than the=20
>console based version.
>
>I'll try to integrate this target into the OJB build.xml.
>
>Do we need the optional ant targets for JUNIT to do this?
>
>thanks,
>
>Thomas
>-----Urspr=FCngliche Nachricht-----
>Von: Fabian B=FCttner [mailto:f_b...@ma...]
>Gesendet: Dienstag, 19. Februar 2002 19:11
>An: obj...@li...
>Betreff: [OJB-developers] regression tests
>
>Hello,
>
>(Currently ojb uses the java task to perform regression tests)
>
>I'm using the junit/junitreport task when testing ojb.
>The junitreport task summarizes the junit output (format is xml) and=20
>transforms it into html.
>I find that the html presentation of the regression tests is much more=20
>readable than the pure text output of the currently used textual=
 TestRunner.
>
>I have attached a zip file containing an example junitreport result (set=20
>of html files). Click on AllTests to expand the broker tests. There can be=
=20
>multiple tests in the generated site (e.g. broker, odmg, jdo ...).
>
>Is there any interest in doing it this way in ojb?
>
>Below is a test target I have used:
>
>     <target name=3D"junit_reports" depends=3D"main, tests">
>         <junit fork=3D"yes" dir=3D"${test}/ojb">
>          <classpath>
>                 <pathelement path=3D"${runtime_classpath}" />
>             </classpath>
>             <formatter type=3D"xml" />
>             <test name=3D"test.ojb.broker.AllTests"/>
>             <! -- test name=3D"test.ojb.odmg.AllTests"/ -->
>             <! -- test name=3D"additional tests..."/ -->
>         </junit>
>         <junitreport>
>             <fileset dir=3D".">
>                 <include name=3D"TEST-*.xml"/>
>             </fileset>
>             <report format=3D"frames" toDir=3D"."/>
>         </junitreport>
>     </target>
>
>Fabian B=FCttner
><mailto:green@remove_no_spam.informatik.uni-bremen.de>green@remove_no_spam.=
informatik.uni-bremen.de=20
>
>

Re: [OJB-developers] ObjectCache and IdentityFactory]

[<Joa...@tp...>]

I'll keep this on-list, ok?

>>> Making it configurable is a good idea. We can have different
>>> behaviour for different environemnts (e.g. singlevm mode, C/S mode,
>>> running within a J2EE app server ...)
>
> Are you thinking of making this configurable at runtime?  Say, with
> an xml or properties file?

I've thought about OJB.properties. BaseConfiguration now neatly supports
this kind of stuff.

>> well, actually I like doing this kind of stuff every now and then
>> (everyone who did such a beast once probably understands, why I
>> don't like to do it all the time ;-).
>
> Kudos for taking it up. :)

ok, but before I start this I'd like to have your views:
- Which pools/Factories should the new class/classes replace/support? (
ServerPool, BrokerPool, ObjectCacheXXXImpl, ...?)
- How generic should it be? ("just what we need now", "what we might need
in the next 3 month", "does it make coffee?")
- Should it be generic enough to be useable outside of ojb? (almost the
same as the one above).
- What level of configurability would anyone need (No "magic numbers" at
all? everything configureable?)
- Should there really be one monster class or rather several specialized
classes with a common infrastructure?
- Whats your favourite colour?

and of course any thoughts that come to your mind.

btw, I realized, that although the new/old server is rather loaded during
the day it got some spare capacities at night (it takes just 7 minutes to
generate doxygen & javadoc for our project, compared to 2 minutes with the
old server). So I might still be able to set up some automated testing.
Anyone tried doxygen? It's pretty neat to view the interaction and class
hierarchies in bigger projects. I'll build doxygen documentation for ojb
for myself frequently, anyone interested in a sample? The first one is
always free.


regards
Joachim Sauer

Re: [OJB-developers] ObjectCache and IdentityFactory]

[<Joa...@tp...>]

> We could even
>> create a pseudo-gc thread that throws away empty Soft/WeakReferences
>> perodically.
>
> There is one argument against threading: You should not use Threads
> in J2EE controlled environments.

Hm, I didn't know this, but it can definitely be made to work without
threads as well. A common strategy would be doing the cleanup in the
accessors (as you suggested). Do you know why you have to avoid threads? Is
this true even in "not-quite-J2EE" ( = plain tomcat for servlets/jsp)?

[snip]
>
> Making it configurable is a good idea. We can have different
> behaviour for different environemnts (e.g. singlevm mode, C/S mode,
> running within a J2EE app server ...)
>
> I like your suggestion very much. We need exactly this kind of
> refactorings to improve the overall code quality!

hm ... my TODO list is growing ;-)

well, actually I like doing this kind of stuff every now and then (everyone
who did such a beast once probably understands, why I don't like to do it
all the time ;-).

> cu,
>
> Thomas

regards
Joachim

AW: [OJB-developers] ObjectCache and IdentityFactory]

[Mahler T. <tho...@it...>]

Hi Joachim,

<snip pool refactoring ideas> I 
> think a unified
> Pool utility class would be A Good Thing. 

I definitely agree!

We could even 
> create a pseudo-gc
> thread that throws away empty Soft/WeakReferences 
> perodically. 

There is one argument against threading: You should not use Threads in J2EE
controlled environments.

This could
> be done in a single thread, even when you got 15 pools (which 
> would not be
> so easy, when using 15 different implementations). Of course 
> this generic
> pool would have to scale up and down (i.e. be able to act as a really
> simple pool with no gc-tricks as well as a gc-enabled pool with
> configurable lru-list and so on ...). What do you think of that?
> 

Making it configurable is a good idea. We can have different behaviour for
different environemnts (e.g. singlevm mode, C/S mode, running within a J2EE
app server ...)

I like your suggestion very much. We need exactly this kind of refactorings
to improve the overall code quality!

cu,

Thomas

RE: [OJB-developers] ObjectCache and IdentityFactory]

[<Joa...@tp...>]

[snip Cache memory leaks & gc-strategies]

I've been thinking about this topic for some time now. I think we need some
kind of generic pool. It should be configurable and smart. I've once
implemented such a beast which even provided a function to tell the cache
that the more recently used x% of the objects should not be gc-able. It is
quite some work to implemnt such things in a smart and performant way but
this work is usually needed only once. OJB has quite some pools, where each
has it's own implementation (from the simple PersistenceBrokerPool for the
Server to the ObjectCache, which is more sophisticated). I think a unified
Pool utility class would be A Good Thing. We could even create a pseudo-gc
thread that throws away empty Soft/WeakReferences perodically. This could
be done in a single thread, even when you got 15 pools (which would not be
so easy, when using 15 different implementations). Of course this generic
pool would have to scale up and down (i.e. be able to act as a really
simple pool with no gc-tricks as well as a gc-enabled pool with
configurable lru-list and so on ...). What do you think of that?

regards
Joachim

P.S.: Sorry, Florian, for the useless mail. Notes sometimes got the "Send"
Button, where "New Mail" should be ;-)

AW: [OJB-developers] ObjectCache and IdentityFactory]

[Mahler T. <tho...@it...>]

Hi Florian,

> Hi Thomas,
 
<snip>
> 
> I'm quite sure about the memory leak. SoftReference objects 
> behave like all
> other objects, i.e. they are collected when there are no 
> references to the
> objects left. Lets look at ObjectCacheImpl:
> 
>     public void cache(Identity oid, Object obj)
>     {
>         if ((obj != null))
>         {
>             SoftReference ref = new SoftReference(obj);
>             objectTable.put(oid.toString(), ref);
>         }
>     }
> 
> This creates a new SoftReference with the object to cache 
> being the referent
> of the SoftReference. The referent is subject to special 
> handling by the GC,
> i.e. it can be collected if there are not other references to obj.

Ahh, now I get your point. We'll have to remove the SoftReferences from the
objectTable too, to make them collectable! I did not care about that in my
original implementation.
 
> The following code (in lookup) removes entries of the 
> Hashtable where the
> values have been collected:
> 
>         if (ref != null)
>         {
>             obj = ref.get();
>             if (obj == null)
>             {
>                 gcCount++;
>                 objectTable.remove(oid);
>             }
>         }

Yes, exactly! 

> If the entry is processed by this code the SoftReference will be gc'd
> because there is no reference left to it (normal gc behaviour).

OK.

> The problem is, when you have entries in the Hashtable that, 
> at some point
> in time, get collected, but there is never ever again a lookup of the
> object. In this case the entry in the Hashtable remains and 
> therefore a
> couple of objects (Identity, Map.Entry, SoftReference) remain 
> in memory.

Ooops, you are right, this will happen. We have to ensure that all obsolete
Softreferences are deleted from the map!

> Other implementations of such caches or WeakHashMap/SoftHashMaps work
> differently. They maintain an instance of 
> java.lang.ref.ReferenceQueue and
> pass this instance to all created SoftReference/WeakReference objects.
> Whenever the referent of a Soft/WeakReference is collected, the
> SoftReference/WeakReference is added to the ReferenceQueue.
> 
> Now, whenever you modify the map (by put, remove etc.) the 
> ReferenceQueue is
> processed and the entries are removed. This leads to another 
> typical issue
> in such implementations: Usually the KEY of the map is 
> encapsulated in a
> Soft/WeakReference. This is done to make cleaning up 
> efficient, because you
> can only access a map by keys, but has the disadvantage that 
> not the objects
> that might be larger in size (usually the value) are 
> collected if memory is
> running low.
> 
> There are some other disadvantages with this approach (like 
> entries never
> get thrown out when you do not modify a map over some time, 
> unpredictable
> processing time of modification operations), and in general 
> the more I look
> into these implementations the more I get the feeling that all of them
> contain somewhat ugly hacks that prevent them from being a 
> reliable and
> calculable solution for a cache (i.e. efficient lookup, efficient in
> modification and retrieval of the cache, calculable and 
> constant time of
> lookup and modification, ...)
> 

Here my idea:
We can check if a SoftReference is valid by (ref.get() != null)
It won't be difficult to write a method that traverses the complete
objectTable and removes all invalid Sofreferences.

This cleanup method could be called every 1000 calls of lookup or so...

What do you think?


> best regards,
> Florian
>