objectbridge-developers — public list for developer issues

[OJB-developers] Case insensitive search criteria

[Andrew P. <api...@op...>]

Howdy,  

I have a need to implement case insensitive queries.  In my application,
I need to store certain names in a case sensitive fashion, but need to
validate them ignoring case (I really don't want to store a second
lowercase version of the field).

In searching I figured I could use criteria.addSqlCriteria(..) but I
really really want to use field names and not table columns.

Before I go and try to implement a CaseInsensitiveFieldCriteria, is
there a better way to go??

Thanks and cheers
Andrew

[OJB-developers] Proposal for enhancing org.apache.commons.logging.Log

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

hi,

i'd like to propose some enhancements to the org.apache.commons.logging.Log
interface:

void debug(Object aMessage, Object aParameter)
void debug(Object aMessage, Object aParameter, Throwable anException);

the same extension should be done for methods info, error and fatal.

what's the benefit of this new methods:

a.) the ojb team (http://jakarta.apache.org/ojb) needs a lot of logging
where user objects are part of the logging-string.

logger.debug("deleting " + obj);

we had the problem that in some cases the toString() of the user object
failed, which alse broke our logging.
the proposed enhancements would allow as to use:

logger.debug("deleting", obj);

and all implementation details of the failsafe logging methods with
try/catch around toString() could be hidden.

b.) the toString() method of some objects may be  costly and it should only
be done when the loglevel mathes.
i know there are methods to query the loglevel isDebugEnabled() bit imho the
logging-call should be a simple one liner.

c.) java.util.logging of jdk 1.4 also supports parameters.

thanks

jakob

[OJB-developers] mapping abstract classes ?

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

hi,

i have a question regarding the mapping of abstract classes.

given the following class hierarchy:

Project
..ITProject (abstract)
....SoftwareProject
....HardwareProject

using the tables PROJECT, SW_PROJECT, HW_PROJECT.

i can use the following mapping:=20

   <class-descriptor
   class=3D"org.apache.ojb.broker.Project"
   table=3D"PROJECT"
   >
      <extent-class class-ref=3D"org.apache.ojb.broker.SoftwareProject" =
/>
      <extent-class class-ref=3D"org.apache.ojb.broker.HardwareProject" =
/>
   ...

and class-descriptors for SoftwareProject and HardwareProject.
if i want to query ITProjects i'll have to define a class-descriptor:

   <class-descriptor
   class=3D"org.apache.ojb.broker.ITProject"
   >
      <extent-class class-ref=3D"org.apache.ojb.broker.SoftwareProject" =
/>
      <extent-class class-ref=3D"org.apache.ojb.broker.HardwareProject" =
/>
   </class-descriptor>

this all works fine. what irritates me is the duplicate definition of =
extents.=20
so i tried the following mapping, which reflects the class hierarchy:

   <class-descriptor
   class=3D"org.apache.ojb.broker.Project"
   table=3D"PROJECT"
   >
      <extent-class class-ref=3D"org.apache.ojb.broker.ITProject" />

   ...

   <class-descriptor
   class=3D"org.apache.ojb.broker.ITProject"
   >
      <extent-class class-ref=3D"org.apache.ojb.broker.SoftwareProject" =
/>
      <extent-class class-ref=3D"org.apache.ojb.broker.HardwareProject" =
/>
   </class-descriptor>

this mapping fails because ITProject has no table :(

so i came up with the following:=20
if the extent-class references an 'abstract' class (one without table), =
the search should continue with the extents-classes of the 'abstract' =
class.
the only drawback i see so far is performance caused by checking all =
extent-classes.

what do think of it ?

jakob

[OJB-developers] moving to Jakarta

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

Hi all,

The shift to Jakarta is now complete.
OJB is now an official Jakarta subproject.
Our new url is : http://jakarta.apache.org/ojb

All OJB related activities will be organized in the Jakarta environment. 
The SourceForge presence will be reduced to a minimum.

All OJB users and developers are requested to register to our new 
Jakarta mailinglists, as we won't maintain the sourceforge mailinglists.
Here is the link to the mailinglist subscription page: 
http://jakarta.apache.org/ojb/mail-lists.html

I shut down all Mailinglists, Tracker and Forum functionality on our old 
SourceForge site.

best regards,
Thomas

[OJB-developers] Re: ORA-01000

[Matthew b. <mat...@ya...>]

 Hi Martin. I don't see this problem because I use the J2EE stuff. I agree it's a problem. I think your solution, considering how ojb works, is acceptable. I don't have commit status at the moment although I DID send in my apache agreement :( I would commit the change if I did.
I think caching statements is a bad idea. I'm a firm believer that the driver should do stuff like that. The J2EE implementation does generated SQL statement caching, which I think is where the win is.
When I get commit I'll write some tests for oracle then if everything works out, I'll commit. 
THANKS! for finding and working out the problems, that's how we get better, right?
m
  Martin Fuzzey <fu...@be...> wrote: Matthew and all,

Following the thread at :

http://sourceforge.net/mailarchive/forum.php?thread_id=796595&forum_id=4880

In cvs r1.8 of StatementManager.java the ORA-01000 problem still exists.
I can reproduce it easilly simply by repeating "SELECT *" type calls using :
Query query = new QueryByCriteria(IFdp.class, null);
try {
return m_broker.getCollectionByQuery(query);
} catch(PersistenceBrokerException ex) {
throw new IOException(ex.toString());
}

(for me the problem occurs after about 6 loops but that will depend on the 
Oracle configuration and the object model).

I too tried to fix this by adding a stmt.close() to 
StatementManager.closeResources() and, as was pointed out in the above 
thread, this causes errors elesewhere due to cached statements.

On Oracle it is definitely necessary to close unused statements. Closing 
the statement will close any associated result set but NOT the reverse.

Here is my analysis and suggested correction for the problem (I'm new to 
OJB so maybe I've missed something).

StatementsForClass caches several statements for each class (for uodate, 
insert, delete and primary key lookup). It provides accessor methods which 
return the cached statement or create it if necessary. These statements 
must not be closed when an iterator is discarded. However there is also a 
getGenericStmt() method which does NOT do caching. In particular this 
method is used for select * type queries (JdbcAccess.executeQuery()). Hence 
statements obtained in this way (encapsulated in a ResultStateAndStatement 
object) DO need to be closed.

What I did was to add a method to StatementsForClassIF :

public boolean isCached(Statement stmt);

This is implemented in StatementsForClass :
public boolean isCached(Statement stmt) {
if (stmt == selectByPKStmt ||
stmt == insertStmt ||
stmt == updateStmt ||
stmt == deleteStmt) {
return true;
}
return false;
}

Then in StatementManager during closeResources() we need to see if the 
statement to be closed has been cached by any of the StatementForClass 
objects (fortunately StatementManager already knows them) and close it if 
it is NOT cached :

public void closeResources(Statement stmt, ResultSet rs)
{
/**
* MBAIRD
* We need to close the resultset and statement in order to 
reclaim resources, and help Oracle
* which will eventually throw an ORA-01000 (open cursor problem).
*/
try
{
if (stmt != null) // MF
{
closeIfNotCached(stmt);
}

if (rs != null)
{
rs.close();
}
}
catch (SQLException ignored)
{
LoggerFactory.getDefaultLogger().warn("closing resultset had 
error: "+ ignored.getMessage());
}
rs = null;
stmt = null;
}

private void closeIfNotCached(Statement stmt) {
boolean doClose = true;
for (Iterator it = statementTable.values().iterator(); 
it.hasNext();) {
StatementsForClassIF sfc = (StatementsForClassIF) it.next();
if (sfc != null) {
if (sfc.isCached(stmt)) {
doClose = false;
LoggerFactory.getDefaultLogger().debug("Not closing 
stmt as cached");
break;
}
}
}
if (doClose) {
try {
stmt.close();
} catch(SQLException ignored) {
LoggerFactory.getDefaultLogger().warn("closing statement 
had error: "+ ignored.getMessage());
}
}
}

I'm not sure this is the most elegant solution but it works for me.

Martin



---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup

Re: [OJB-developers] ORA-01000

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

On Wed, 2002-06-19 at 13:27, Martin Fuzzey wrote:
> Matthew and all,

The mailing lists and code are now @ jakarta, please repost there.

http://jakarta.apache.org/ojb/
 
> Following the thread at :
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=796595&forum_id=4880
> 
> In cvs r1.8 of StatementManager.java the ORA-01000 problem still exists.
> I can reproduce it easilly simply by repeating "SELECT *" type calls using :
>          Query query = new QueryByCriteria(IFdp.class, null);
>          try {
>              return m_broker.getCollectionByQuery(query);
>          } catch(PersistenceBrokerException ex) {
>              throw new IOException(ex.toString());
>          }
> 
> (for me the problem occurs after about 6 loops but that will depend on the 
> Oracle configuration and the object model).
> 
> I too tried to fix this by adding a stmt.close() to 
> StatementManager.closeResources() and, as was pointed out in the above 
> thread, this causes errors elesewhere due to cached statements.
> 
> On Oracle it is definitely necessary to close unused statements. Closing 
> the statement will close any associated result set but NOT the reverse.
> 
> Here is my analysis and suggested correction for the problem (I'm new to 
> OJB so maybe I've missed something).
> 
> StatementsForClass caches several statements for each class (for uodate, 
> insert, delete and primary key lookup). It provides accessor methods which 
> return the cached statement or create it if necessary. These statements 
> must not be closed when an iterator is discarded. However there is also a 
> getGenericStmt() method which does NOT do caching. In particular this 
> method is used for select * type queries (JdbcAccess.executeQuery()). Hence 
> statements obtained in this way (encapsulated in a ResultStateAndStatement 
> object) DO need to be closed.
> 
> What I did was to add a method to StatementsForClassIF :
> 
> 	public boolean isCached(Statement stmt);
> 
> This is implemented in StatementsForClass :
>      public boolean isCached(Statement stmt) {
>          if (stmt == selectByPKStmt ||
>              stmt == insertStmt ||
>              stmt == updateStmt ||
>              stmt == deleteStmt) {
>              return true;
>          }
>          return false;
>      }
> 
> Then in StatementManager during closeResources() we need to see if the 
> statement to be closed has been cached by any of the StatementForClass 
> objects (fortunately StatementManager already knows them) and close it if 
> it is NOT cached :
> 
>      public void closeResources(Statement stmt, ResultSet rs)
>      {
>          /**
>           * MBAIRD
>           * We need to close the resultset and statement in order to 
> reclaim resources, and help Oracle
>           * which will eventually throw an ORA-01000 (open cursor problem).
>           */
>          try
>          {
>              if (stmt != null) // MF
>              {
>                  closeIfNotCached(stmt);
>              }
> 
>              if (rs != null)
>              {
>                  rs.close();
>              }
>          }
>          catch (SQLException ignored)
>          {
>              LoggerFactory.getDefaultLogger().warn("closing resultset had 
> error: "+ ignored.getMessage());
>          }
>          rs = null;
>          stmt = null;
>      }
> 
>      private void closeIfNotCached(Statement stmt) {
>          boolean doClose = true;
>          for (Iterator it = statementTable.values().iterator(); 
> it.hasNext();) {
>              StatementsForClassIF sfc = (StatementsForClassIF) it.next();
>              if (sfc != null) {
>                  if (sfc.isCached(stmt)) {
>                      doClose = false;
>                      LoggerFactory.getDefaultLogger().debug("Not closing 
> stmt as cached");
>                      break;
>                  }
>              }
>          }
>          if (doClose) {
>              try {
>                  stmt.close();
>              } catch(SQLException ignored) {
>                  LoggerFactory.getDefaultLogger().warn("closing statement 
> had error: "+ ignored.getMessage());
>              }
>          }
>      }
> 
> I'm not sure this is the most elegant solution but it works for me.
> 
> Martin
> 
> 
> ----------------------------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
-- 
jvz.

Jason van Zyl
ja...@ap...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

[OJB-developers] ORA-01000

[Martin F. <fu...@be...>]

Matthew and all,

Following the thread at :

http://sourceforge.net/mailarchive/forum.php?thread_id=796595&forum_id=4880

In cvs r1.8 of StatementManager.java the ORA-01000 problem still exists.
I can reproduce it easilly simply by repeating "SELECT *" type calls using :
         Query query = new QueryByCriteria(IFdp.class, null);
         try {
             return m_broker.getCollectionByQuery(query);
         } catch(PersistenceBrokerException ex) {
             throw new IOException(ex.toString());
         }

(for me the problem occurs after about 6 loops but that will depend on the 
Oracle configuration and the object model).

I too tried to fix this by adding a stmt.close() to 
StatementManager.closeResources() and, as was pointed out in the above 
thread, this causes errors elesewhere due to cached statements.

On Oracle it is definitely necessary to close unused statements. Closing 
the statement will close any associated result set but NOT the reverse.

Here is my analysis and suggested correction for the problem (I'm new to 
OJB so maybe I've missed something).

StatementsForClass caches several statements for each class (for uodate, 
insert, delete and primary key lookup). It provides accessor methods which 
return the cached statement or create it if necessary. These statements 
must not be closed when an iterator is discarded. However there is also a 
getGenericStmt() method which does NOT do caching. In particular this 
method is used for select * type queries (JdbcAccess.executeQuery()). Hence 
statements obtained in this way (encapsulated in a ResultStateAndStatement 
object) DO need to be closed.

What I did was to add a method to StatementsForClassIF :

	public boolean isCached(Statement stmt);

This is implemented in StatementsForClass :
     public boolean isCached(Statement stmt) {
         if (stmt == selectByPKStmt ||
             stmt == insertStmt ||
             stmt == updateStmt ||
             stmt == deleteStmt) {
             return true;
         }
         return false;
     }

Then in StatementManager during closeResources() we need to see if the 
statement to be closed has been cached by any of the StatementForClass 
objects (fortunately StatementManager already knows them) and close it if 
it is NOT cached :

     public void closeResources(Statement stmt, ResultSet rs)
     {
         /**
          * MBAIRD
          * We need to close the resultset and statement in order to 
reclaim resources, and help Oracle
          * which will eventually throw an ORA-01000 (open cursor problem).
          */
         try
         {
             if (stmt != null) // MF
             {
                 closeIfNotCached(stmt);
             }

             if (rs != null)
             {
                 rs.close();
             }
         }
         catch (SQLException ignored)
         {
             LoggerFactory.getDefaultLogger().warn("closing resultset had 
error: "+ ignored.getMessage());
         }
         rs = null;
         stmt = null;
     }

     private void closeIfNotCached(Statement stmt) {
         boolean doClose = true;
         for (Iterator it = statementTable.values().iterator(); 
it.hasNext();) {
             StatementsForClassIF sfc = (StatementsForClassIF) it.next();
             if (sfc != null) {
                 if (sfc.isCached(stmt)) {
                     doClose = false;
                     LoggerFactory.getDefaultLogger().debug("Not closing 
stmt as cached");
                     break;
                 }
             }
         }
         if (doClose) {
             try {
                 stmt.close();
             } catch(SQLException ignored) {
                 LoggerFactory.getDefaultLogger().warn("closing statement 
had error: "+ ignored.getMessage());
             }
         }
     }

I'm not sure this is the most elegant solution but it works for me.

Martin

Re: [OJB-developers] RE: migration to jakarta

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

+1

jakob
----- Original Message -----
From: "Mahler Thomas" <tho...@it...>
To: "'Florian Bruckner'" <bf...@fl...>; "OJB Developers List"
<oj...@ja...>
Cc: <obj...@li...>
Sent: Tuesday, June 18, 2002 9:12 AM
Subject: AW: [OJB-developers] RE: migration to jakarta


> Hi all,
>
> I suggest we take this opportunity to change the test package names to
> org.apache.ojb.* as Chris suggested some time ago.
>
> This will allow us to perform white box testing by accessing package scope
> attributes and methods.
>
> See Chris original message and my reply below:
>
> Thomas
>
> > Chris Greenlee wrote:
> > > +1.  I like the idea of using the WebShop classes as a basis.
> > >
> > > When/while we do this, would it be a good idea to start
> > moving tests from
> > > the test.ojb package into the ojb package?  That way we can
> > include tests of
> > > protected methods where useful.
> > >
> >
> > Good idea. There is only one caveat:
> > currently all compiled classes are written to target/classes.
> > Once we put test classes into the same packages as the production
> > classes we have compile them into different subdirectories say:
> > target/classes/production
> > target/classes/test
> >
> > so we can avoid to include test classes into the binary distribution
> > ojb-xxx.jar
> >
> > Thomas
> >
> > > Cheers,
> > >
> > > Chris Greenlee
>
> --------------------------------------------------------------------------
--
>                    Bringing you mounds of caffeinated joy
>                       >>>     http://thinkgeek.com/sf    <<<
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] RE: migration to jakarta

[Florian B. <bf...@fl...>]

> I suggest we take this opportunity to change the test package names to
> org.apache.ojb.* as Chris suggested some time ago.

I second that motion.

AW: [OJB-developers] RE: migration to jakarta

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

Hi all,

I suggest we take this opportunity to change the test package names to
org.apache.ojb.* as Chris suggested some time ago.

This will allow us to perform white box testing by accessing package scope
attributes and methods.

See Chris original message and my reply below:

Thomas

> Chris Greenlee wrote:
> > +1.  I like the idea of using the WebShop classes as a basis.
> > 
> > When/while we do this, would it be a good idea to start 
> moving tests from
> > the test.ojb package into the ojb package?  That way we can 
> include tests of
> > protected methods where useful.
> > 
> 
> Good idea. There is only one caveat:
> currently all compiled classes are written to target/classes.
> Once we put test classes into the same packages as the production 
> classes we have compile them into different subdirectories say:
> target/classes/production
> target/classes/test
> 
> so we can avoid to include test classes into the binary distribution 
> ojb-xxx.jar
> 
> Thomas
> 
> > Cheers,
> > 
> > Chris Greenlee

Re: [OJB-developers] Informix Support

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

Hi,

Domagoj Jugovic wrote:
> Hi everybody !
> 
> I just would like to hear some directions about adding support for other 
> databases in ojb (I must use Informix).
> 
> 
> If src/test/setup/db-setup.sql is removed now, does it mean that we 
> don't need the switches in build.properties ?

right, I'm currently on providing a new way to generate the OJB database 
against all supported target rdbms.

> The ".profile" file is now concerned with the database configuration. As 
> I see the data from this file now gets transfered to repository.xml 
> (jdbc-connection-descriptor) when calling ant junit target.
> 
> For now I see that this should be done :
> 
>   - for Torque : - a DB adapter for Torque for using Informix.
>                       - velocity templates for generating SQL for Torque
> 
>   - for OJB :  -  new "Informix.profile" file.
> 
> 

right!


> OJB was working with Informix before, so I presume that it only needs 
> Informix.profile ?
> 

I think so !

> Please tell me if something else is needed and I will try to make 
> Informix support for ojb.
> 

If torque can handle informix there should not be further problems !
(SOme time ago OJB already worked with Informix)

> 
> 
> 
> And one another question. In ojb 0.9 (not before) there is junit task 
> used in build.xml.
> Some of you probably had problems with : "Could not create task // 
> classNotFoundException" when running junit tests,   because of 
> Delegating Class Loader implementation of AntClassLoader (see:  
> http://jakarta.apache.org/ant/faq.html#delegating-classloader ), which 
> means that you must have classes that require external library ant that 
> library in the same classpath. (In this case the loaded optional task 
> JUnitTask could'n find classes from junit.jar from ojb/lib because 
> JUnitTask class would be loaded by ClassLoader that is parent of 
> AntClassLoader ).
> 
> I am interested in your solutions to this problem?
> 
> I just filled up the enviroment variable CLASSPATH with jars from ojb/lib.
> 
>                                 Thanx.
> 

the build.sh and build.bat script contain code to load all jars under 
ojb/lib into the Classpath...

HTH,
Thomas

> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 

RE: [OJB-developers] Storing references (or updating collections on referenced objects) -> defining the correct PBImp behavior !

[Matthew B. <ma...@so...>]

 your reference from project --* users is not set up to auto-update, so if
you did something like this:

project.addUser(user);

calling update on project will not persist the new user into the collection.

that's my guess :)

This is more proof we need more test cases. I wrote a test case that showed
that disassociation of relationships didn't work, fixed it with my patch,
tested all on HSQLDB and SQL Server then checked it in.

m

-----Original Message-----
From: Leandro Rodrigo Saad Cruz
To: Matthew Baird
Cc: obj...@li...
Sent: 6/17/02 11:05 AM
Subject: [OJB-developers] Storing references (or updating collections on
referenced objects) -> defining the correct PBImp behavior !

Hi all. this email is mainly for MBAIRD because of his comments in
PBImpl.java

I'm trying to store and object that should be part of a collection of
another object but the collection is not updated by PBImpl.java. 
To make it more concrete here is an example

<class-descriptor class="Project" table="PROJECT">
   <field-descriptor id="1" 
 		name="id" 
		column="PROJECT_ID" 
		jdbc-type="INTEGER" 
		primarykey="true" 
                autoincrement="true"/>

   <collection-descriptor name="users"
	element-class-ref="User"
        auto-retrieve="true"
        auto-update="false"
        auto-delete="true">
      <inverse-foreignkey field-id-ref="2"/>
   </collection-descriptor>
</class-descriptor>

<class-descriptor class="User" table="USER">

    <field-descriptor id="1" 
		name="id" 
		column="USER_ID" 
		jdbc-type="INTEGER" 
		primarykey="true" 
		autoincrement="true"/>
    <field-descriptor id="2" 
		name="project_id" 
		column="PROJECT_ID" 
		jdbc-type="INTEGER"/>

    <reference-descriptor name="project" 	
			class-ref="Project" 
			auto-retrieve="true" 
			auto-update="true">
      <foreignkey field-id-ref="2" />
    </reference-descriptor>

</class-descriptor>

When I add a User to a existing Project the collection users in Project
is not updated by PBImpl.java.

When I was looking up PBImpl src I saw a comment in asserFKAssignment()
:
      /**
       * MBAIRD
       * we have 'disassociated' this object from the referenced object,
the object representing the ord is now null,
       * so set the fk to null.
       *
       * Note: I can't believe this wasn't tested (as of June9/2002),
attaching and removing objects seems to be a
       * pretty important piece of functionality.
       *
       */

I don't understand if PBImpl should update collections on referenced
objects or we must do it by hand ?

Can some help me define the correct behavior ?

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br


_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] RE: migration to jakarta

[Florian B. <bf...@fl...>]

> I think it is a matter of package names. Feel free to test out your new
> commit access by fixing the testbed :-)

Of course, that could be the problem (just read Jakob's message). Think we
have to decide how to proceed, either change the package declaration in the
classes or change the directory structure for the tests.


regards,
Florian

Re: [OJB-developers] Move to Jakarta complete

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

hi jason,

there's a problem with the test-package

the package name is: test.ojb.broker 
but in the java files i see: package test.org.apache.ojb.broker;

this confuses eclipse :(

jakob

----- Original Message ----- 
From: "Jason van Zyl" <jv...@ze...>
To: "ojb" <obj...@li...>
Sent: Monday, June 17, 2002 9:43 PM
Subject: [OJB-developers] Move to Jakarta complete


> Hi Guys,
> 
> The code has been moved over, the mailing lists have been set up and
> CVSView is working. All the info you need should be below. I have given
> access to those for whom an agreement has been received. I only know
> this from Jim Jagalieski so you telling me isn't good enough. I'm
> waiting back for a complete list. Right now the following people have
> access: 
>    
> Oleg
> Florian
> Thomas
> Jakob
> Joachim
> 
> I have pinged Jim to get the full list. There's nothing I can do until
> Jim gives me the official list.
> 
> Repository:
> jakarta-ojb
> 
> CVS Access on Windows
> http://jakarta.apache.org/site/cvsonwin32.html
> 
> CVS Access on Unix
> http://jakarta.apache.org/site/cvsonunix.html
> 
> Example:
> 
> export CVS_RSH=ssh
> export CVSROOT:ext:jv...@cv...:/home/cvs
> cvs co jakarta-ojb
> 
> NOTE: it is /home/cvs and not /home/cvspublic. This is the most common
> mistake people make when moving from anonymous access to committer level
> access.
> 
> Mailing Lists:
> ojb...@ja...
> oj...@ja...
> 
> to subscribe:
> 
> ojb...@ja...
> ojb...@ja...
> 
> ViewCVS:
> http://cvs.apache.org/viewcvs.cgi/jakarta-ojb/
> 
> Let me know if you are having any problems. I will deal with them as
> fast as I can. Please subscribe to the new lists and welcome to Jakarta!
> 
> -- 
> jvz.
> 
> Jason van Zyl
> jv...@ap...
> 
> http://tambora.zenplex.org
> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

[OJB-developers] Move to Jakarta complete

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

Hi Guys,

The code has been moved over, the mailing lists have been set up and
CVSView is working. All the info you need should be below. I have given
access to those for whom an agreement has been received. I only know
this from Jim Jagalieski so you telling me isn't good enough. I'm
waiting back for a complete list. Right now the following people have
access: 
   
Oleg
Florian
Thomas
Jakob
Joachim

I have pinged Jim to get the full list. There's nothing I can do until
Jim gives me the official list.

Repository:
jakarta-ojb

CVS Access on Windows
http://jakarta.apache.org/site/cvsonwin32.html

CVS Access on Unix
http://jakarta.apache.org/site/cvsonunix.html

Example:

export CVS_RSH=ssh
export CVSROOT:ext:jv...@cv...:/home/cvs
cvs co jakarta-ojb

NOTE: it is /home/cvs and not /home/cvspublic. This is the most common
mistake people make when moving from anonymous access to committer level
access.

Mailing Lists:
ojb...@ja...
oj...@ja...

to subscribe:

ojb...@ja...
ojb...@ja...

ViewCVS:
http://cvs.apache.org/viewcvs.cgi/jakarta-ojb/

Let me know if you are having any problems. I will deal with them as
fast as I can. Please subscribe to the new lists and welcome to Jakarta!

-- 
jvz.

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

http://tambora.zenplex.org

[OJB-developers] Storing references (or updating collections on referenced objects) -> defining the correct PBImp behavior !

[Leandro R. S. C. <le...@ib...>]

Hi all. this email is mainly for MBAIRD because of his comments in
PBImpl.java

I'm trying to store and object that should be part of a collection of
another object but the collection is not updated by PBImpl.java. 
To make it more concrete here is an example

<class-descriptor class="Project" table="PROJECT">
   <field-descriptor id="1" 
 		name="id" 
		column="PROJECT_ID" 
		jdbc-type="INTEGER" 
		primarykey="true" 
                autoincrement="true"/>

   <collection-descriptor name="users"
	element-class-ref="User"
        auto-retrieve="true"
        auto-update="false"
        auto-delete="true">
      <inverse-foreignkey field-id-ref="2"/>
   </collection-descriptor>
</class-descriptor>

<class-descriptor class="User" table="USER">

    <field-descriptor id="1" 
		name="id" 
		column="USER_ID" 
		jdbc-type="INTEGER" 
		primarykey="true" 
		autoincrement="true"/>
    <field-descriptor id="2" 
		name="project_id" 
		column="PROJECT_ID" 
		jdbc-type="INTEGER"/>

    <reference-descriptor name="project" 	
			class-ref="Project" 
			auto-retrieve="true" 
			auto-update="true">
      <foreignkey field-id-ref="2" />
    </reference-descriptor>

</class-descriptor>

When I add a User to a existing Project the collection users in Project
is not updated by PBImpl.java.

When I was looking up PBImpl src I saw a comment in asserFKAssignment()
:
      /**
       * MBAIRD
       * we have 'disassociated' this object from the referenced object,
the object representing the ord is now null,
       * so set the fk to null.
       *
       * Note: I can't believe this wasn't tested (as of June9/2002),
attaching and removing objects seems to be a
       * pretty important piece of functionality.
       *
       */

I don't understand if PBImpl should update collections on referenced
objects or we must do it by hand ?

Can some help me define the correct behavior ?

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br

[OJB-developers] LockNotGrantedException Error

[Hoang, H. <Hai...@co...>]

I don't know what I've done wrong but I keep getting the
LockNotGrantedException Error.  Here is the code and the error message:

I am using the ojb-0-9 build.  Thanks.

	public Collection getAllPermissions() throws DataBackendException
	{
		try
        {
            // 1. open a transaction
            Transaction tx = odmg.newTransaction();
            tx.begin();

            // 2. get an OQLQuery object from the ODMG facade
            OQLQuery query = odmg.newOQLQuery();

            // 3. set the OQL select statement
            query.create("select allPermissions from " +
PermissionImpl.class.getName() + " order by name");

            // 4. perform the query and store the result in a persistent
Collection
            Collection permissions = (Collection) query.execute();
            tx.commit();

            return permissions;
        }
        catch (Exception e)
        {
            throw new DataBackendException("getAllPermissions() failed", e);
        }
	}


org.odmg.LockNotGrantedException
	at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:183)
	at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:243)
	at
com.htg.base.bo.PermissionManagerImpl.getAllPermissions(PermissionManagerImp
l.java:131)
	at com.htg.base.test.PermissionTest.main(PermissionTest.java:30)
[ODMG] ERROR: null
org.odmg.QueryException
	at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:257)
	at
com.htg.base.bo.PermissionManagerImpl.getAllPermissions(PermissionManagerImp
l.java:131)
	at com.htg.base.test.PermissionTest.main(PermissionTest.java:30)
rethrown as com.htg.base.util.DataBackendException: getAllPermissions()
failed
	at
com.htg.base.bo.PermissionManagerImpl.getAllPermissions(PermissionManagerImp
l.java:138)
	at com.htg.base.test.PermissionTest.main(PermissionTest.java:30)
Caused by: org.odmg.QueryException
	at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:257)
	at
com.htg.base.bo.PermissionManagerImpl.getAllPermissions(PermissionManagerImp
l.java:131)
	... 1 more

[OJB-developers] errors on build

[<tr...@th...>]

ECHO Not implemented 

in create-db.sql  (that is all that's in the file) so throws errors.  when building.  This is just after checking out.

Travis 

[OJB-developers] Update

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

Hi,

Sorry the move is taking so long. The creation of the mailing lists is
taking an embarrassingly long time. The wheels fell of somewhere but I'm
trying to get them going. If the mailing lists aren't up then all the
import/commit messages create problems.

If people need to commit changes I will will follow them and make the
adjustments manually so that you're all not sitting around waiting for
me to finish.

We should also keep both repos going for a couple of days just we have a
few more eyeballs checking to make sure I didn't mess something up in
the transfer.

-- 
jvz.

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

http://tambora.zenplex.org

Re: [OJB-developers] Re: problems with OJB

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

hi matthew,

i once had a long discussion about tx caches with Carsten Spräner
Car...@vi...
unfortunately i've lost these threads due to space limits in hotmail .

jakob

----- Original Message -----
From: "Matthew Baird" <ma...@so...>
To: "'Jakob Braeuchi'" <jbr...@ho...>; "'Mahler Thomas '"
<tho...@it...>; "Matthew Baird" <ma...@so...>;
"'Objectbridge (E-Mail) '" <obj...@li...>
Sent: Sunday, June 16, 2002 6:39 PM
Subject: RE: [OJB-developers] Re: problems with OJB


> I'd like to support 1 (the way OJB works now), and the array of
data-objects
> in the cache, not the business object itself (as Jakob mentions).
>
> I will then have to handle the update scenario as outlined in my previous
> email.
>
> Any objections?
>
> -----Original Message-----
> From: Jakob Braeuchi [mailto:jbr...@ho...]
> Sent: Sunday, June 16, 2002 8:32 AM
> To: 'Mahler Thomas '; Matthew Baird; 'Objectbridge (E-Mail) '
> Subject: [OJB-developers] Re: problems with OJB
>
> hi matthew,
>
> > load BAR (VM1)
> > serialize BAR to VM2 set some attributes
> > serialize BAR back to VM1 for update
> > load FOO, now the FOO refers to the old BAR, not the updated BAR.
>
> i think this is always a problem when serializing objects.
>
> i'm not a big cache expert but imho strategies 4 and 5 are not to be
> preferred.
> 5 relies too much on the developer of the business object.
>
> 4 may result in bad performance
>
> 3 when using a setter on the proxy where does the data go ?
> p.setName("tom"); you propose to ignore this setter but when later
issueing
> getName() do i get "tom"
> or the previous data ?
>
> 2 afaik castor uses a similar strategy but they store an array of
> data-objects in the cache not the business object itself.
> after the commit castor updates these data-objects in the cache.
>
> jakob
>
>
> _______________________________________________________________
>
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________________________
>
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] Informix Support

[Domagoj J. <do...@la...>]

Hi everybody !

I just would like to hear some directions about adding support for other 
databases in ojb (I must use Informix).


If src/test/setup/db-setup.sql is removed now, does it mean that we don't 
need the switches in build.properties ?
The ".profile" file is now concerned with the database configuration. As I 
see the data from this file now gets transfered to repository.xml 
(jdbc-connection-descriptor) when calling ant junit target.

For now I see that this should be done :

   - for Torque : - a DB adapter for Torque for using Informix.
                       - velocity templates for generating SQL for Torque

   - for OJB :  -  new "Informix.profile" file.


OJB was working with Informix before, so I presume that it only needs 
Informix.profile ?

Please tell me if something else is needed and I will try to make Informix 
support for ojb.




And one another question. In ojb 0.9 (not before) there is junit task used 
in build.xml.
Some of you probably had problems with : "Could not create task // 
classNotFoundException" when running junit tests,   because of Delegating 
Class Loader implementation of AntClassLoader 
(see:  http://jakarta.apache.org/ant/faq.html#delegating-classloader ), 
which means that you must have classes that require external library ant 
that library in the same classpath. (In this case the loaded optional task 
JUnitTask could'n find classes from junit.jar from ojb/lib because 
JUnitTask class would be loaded by ClassLoader that is parent of 
AntClassLoader ).

I am interested in your solutions to this problem?

I just filled up the enviroment variable CLASSPATH with jars from ojb/lib.

								Thanx.

[OJB-developers] DescriptorRepository and ReverseDb

[Florian B. <bf...@fl...>]

Hi!

I have good news and bad news:

First the good news: There was only one reference to
DescriptorRepository.getInstance() left in ClassDescriptor and I was able to
resolve that dependency in my local copy. Therefore I can now open more than
one repository in my GUI.

Now for the bad news: I really need some help with DescriptorRepository. For
the last two days I tried to modify the classes so I can open a repository
XML file without the classes described there being already on the classpath.
Unfortunately I failed because I was not able to defer the class resolving
until the classes are really used. Partially because I didn't understand the
relations in DescriptorRepository and friends (e.g. concerning proxies,
especially dynamic proxies). Partially because I do not have a clue how to
solve issues without unwanted sideeffects.

E.g. if I modify ClassDescriptor so I do not have to set a Class object but
just the fully qualified class name and resolve the class only if I need it,
how should this be handled in DescriptorRepository, which has an HashMap
containing mappings from Class to ClassDescriptor. I do not have a Class at
that time, so I would have to insert a mapping String->ClassDescriptor. But
if the class is finally resolved (in ClassDescriptor), the mapping in the
HashMap would have to be updated as well.

Another problem was concerning extents. Extents are exposed to the rest of
the world with the Vector containing the extent Class objects. If I want to
defer class resolving, this Vector would have to contain Strings with the
class name. But this would break things in the rest of OJB, because there it
is expected that the Vector contains only Class objects.

There are a number of other dependencies on the Class object but I do not
remember all and I already discarded all my changes because there was
nothing working at all anymore.

To bring it to the point - I am completely stuck here and really badly need
some help.

best regards,
Florian

RE: [OJB-developers] Re: problems with OJB

[Matthew B. <ma...@so...>]

I'd like to support 1 (the way OJB works now), and the array of data-objects
in the cache, not the business object itself (as Jakob mentions).

I will then have to handle the update scenario as outlined in my previous
email.

Any objections?

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...] 
Sent: Sunday, June 16, 2002 8:32 AM
To: 'Mahler Thomas '; Matthew Baird; 'Objectbridge (E-Mail) '
Subject: [OJB-developers] Re: problems with OJB

hi matthew,

> load BAR (VM1)
> serialize BAR to VM2 set some attributes
> serialize BAR back to VM1 for update
> load FOO, now the FOO refers to the old BAR, not the updated BAR.

i think this is always a problem when serializing objects.

i'm not a big cache expert but imho strategies 4 and 5 are not to be
preferred.
5 relies too much on the developer of the business object.

4 may result in bad performance

3 when using a setter on the proxy where does the data go ?
p.setName("tom"); you propose to ignore this setter but when later issueing
getName() do i get "tom"
or the previous data ?

2 afaik castor uses a similar strategy but they store an array of
data-objects in the cache not the business object itself.
after the commit castor updates these data-objects in the cache.

jakob


_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] Re: problems with OJB

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

hi matthew,

> load BAR (VM1)
> serialize BAR to VM2 set some attributes
> serialize BAR back to VM1 for update
> load FOO, now the FOO refers to the old BAR, not the updated BAR.

i think this is always a problem when serializing objects.

i'm not a big cache expert but imho strategies 4 and 5 are not to be
preferred.
5 relies too much on the developer of the business object.

4 may result in bad performance

3 when using a setter on the proxy where does the data go ?
p.setName("tom"); you propose to ignore this setter but when later issueing
getName() do i get "tom"
or the previous data ?

2 afaik castor uses a similar strategy but they store an array of
data-objects in the cache not the business object itself.
after the commit castor updates these data-objects in the cache.

jakob

Re: [OJB-developers] problems with OJB

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

Hi Matthew

Matthew Baird wrote:
> I'm sending this specifically to you two guys because you are the most
> active developers for the core of OJB.
> 
> We have big problems with objects being updated and cache consistency.
> 
> If you load an object in one VM, serialize it to another VM, then update
> fields and send it back and call store(x), you will end up with objects
> referencing that object becoming stale.
> 
> ie
> 
> FOO references BAR
> 
> load BAR (VM1)
> serialize BAR to VM2 set some attributes
> serialize BAR back to VM1 for update
> load FOO, now the FOO refers to the old BAR, not the updated BAR.
> 

IMHO this is a general architectural problem, not necessarily OJB specific.

What exactly are you trying to do? Are your clients OJB-ODMG clients or 
are the J2EE clients working against SessionBean controllers (and the 
Session is working against OJB interanlly)?
Or something else?

The big question is: how to manage distributed transaction accross 
multiple VMs.

I have several ideas how to approach this scenario:
- Use OJB c/s more (with servlet or SessionBean session bean facade to 
the server)
- before reaching objects to another VM remove them from the local cache
- Use proxies for all references
- have some additional methods to interact with the cache to place 
updated objects into the cache
- Extend the OJB ODMG implementation to support long transactions:
   when the client sends its modified BAR object back to the server the 
server must lock it to the current ODMG transaction.
In the current implementation we are always recording the state of the 
object to be locked into the ObjectEnvelopes field map.
To support long transactions we should rather record the latest commited 
state of the object into the map.
This would be very easy to implement (the method 
setInitialModificationState must be modified slightly).


> I'm looking at what it will take to fix this now, but I wanted you two big
> brains to start thinking about it as well. This is a subtle bug (in some
> cases) that is hard to write test cases for. 

I am not sure if it is really a bug. A serialized copy of BAR *is not 
the same* as the original BAR. But this is because Java has no notion of 
Object Identity. EJB entity beans provide object identity via PrimaryKey 
objects.
OJB works with the Identity concept.

> I'm seeing it because we seem
> to be the major users of OJB in J2EE where it's location transparency. 

I recently had some similar requests. Until shortly most people used OJB 
in Fat-client or servlet apps.

> the
> JDO API built on top of the PB will never really be right until this works.
> Luckily this is all encapsulated inside the PB.
> 
> I'm trying to come up with a more unified view of how getting objects and
> updating objects from the PB might work. It might be a smart thing to expose
> "read" and "write" get operations on the PB. I'm not sure right now.
> 

I think we need some more in-depth analysis of the problem. Mabye we 
need a whitepaper "how to use OJB with EJB SessionBeans". Maybe we also 
need some changes to PB and/or ODMG implementation.

cheers,
Thomas


> thoughts?
> m
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
>