objectbridge-developers — public list for developer issues

[OJB-developers] new release 0.7.235

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

Hi all,

after a long struggle with the serialization of metadata (due to a bug
in the java api!) I finally managed to do some creative work.
And here is the result:
A brand new release with a major new feature:
M:N mapping support! 
There is also some documentation on it (see tutorial3.html for details).

I decided to replace the default db engine instantDB with the OpenSOurce
engine HSQLDB (aka HypersonicSQL):
- instantDB became a commercial product with release 4.0
- HSQLDB is opensource and also hosted on SourceForge
- it runs much faster than instantDB
- and has a much smaller footprint

There have been quite a lot contributions and suggestions that went into
this release.
I'd like to say thanks to all of you, for you contributions and for your
patience...

>From the release notes:

Changes in Release 0.7.235:

new features:
- Implemented a Manageable HashSet
- Support for n:m associations
- Implemented a non persistent lockmanager for the singlevm mode
- Provided a replacement for JDK1.3 dynamic Proxies for JDK1.2. Works
with VA Java! 
- Integrated Rainers cache implementations
- Extended PB API with: GetDescriptorFor(Class), SetDescriptorFor(Class,
ClassDescriptor)
- Implemented report queries that take SQL statements as input and
return collections of Object[]. 
- Integrated Rainers implementation of a HIGH/LOW SequenceManager
- Implemented a mechanism to allow arbitrary select statements, that
returns primary key values (or all primitive attributes) for a certain
class. The Result of the statement can then wrapped by an Iterator that
returns the identified objects.
- Replaced instantDB (now a comercial product) with HSQLDB.
- Made type of returned Collection in OQL queries configurable.
Integrated Charles contribution of a ManageableArrayList
- Introduced new Usecase "Edit Product" to tutorial 1 and 2.
- Provide class diagrams for client/server document

bug fixes:
- Workaround for bug 4171142 of Sun's Java bug parade (problem with
serialisation of metadata)
- fixed Minor bugs in DmapImpl 
- fixed a SequenceManager bug that resulted in multiple assignment of
ids.
- fixed bug in RsIterator.getObjectFromRs(...) if result == null
- fiexed bug: Rowreader not used with JDBCAccess.materializeObject(...)
- fixed bug: OJB Lockentry primary too big for db2
- Changed declaration of column TIMESTAMP_ in table OJB_LOCKENTRY to
BIGINT (LONG)
- fixed bug in IndirectionHandler with primitive types

refactorings:
- Removed superfluous class CriteriaEception
- Removed Named Roots stuff from tutorial 2. 

enJoy,

Thomas

Re: [OJB-developers] using one transaction with multiple brokers

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

Hi Leandro,

You really want to have a look at the OJB internals ? ;-) Ok, here we
go:

there are 2 transaction concepts in OJB:
1. the PersistenceBroker (PB) transactions. They are simple JDBC
transactions.
(see PB.beginTransaction(), PB.commitTransaction(),
PB.abortTransaction().
a PB instance can execute only 1 transaction at a given point in time.

So if you want to have multiple PB transactions at a time you need
multiple PB instances.
The ojb.broker.server.PersistenceBrokerServer is an example for this
scenario.
The ojb.broker.server.PersistenceBrokerClient uses a round robin scheme
to address multiple server to obtain multiple transactions. Refer to the
document http://objectbridge.sourceforge.net/system/clientserver.html
for details.

But: a PB instance can not participate in transactions of another PB
instance. (As they are merely JDBC tranactions).

2. There are also the object level transactions of the ODMG
implementation. You can do all kind of manipulations with those:
let multiple threads work with a given tx, or 
let one thread work with multiple tx, etc.
have a look at
http://objectbridge.sourceforge.net/javadoc/org/odmg/Transaction.html#join()
for details.

The OJB ODMG transactions use PersistenceBroker transactions only during
their commit phase. So there are no open JDBC transactions during a ODMG
transaction!

This will also allow us to easily integrate OJB into a 2Phase commit
environment. But this is not yet implemented.

HTH

Thomas

Leandro Rodrigo Saad Cruz wrote:
> 
> Hi all !
> 
> Is it possible to spam one transaction to multiple brokers ??
> 
> 1 case : using teh same VM
> 2 case : usinf diferent VM's
> 
> Basically I'd like to start one transaction on the behalf of one broker
> and let other brokers participate one the same transaction !
> 
> --
> Leandro Rodrigo Saad Cruz
> IT - Inter Business Tecnologia e Servicos (IB)
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] Nasty bug

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

Hi Rainer,

There is already a task on my todo-list covering these issues.
In my next code walkthrough I will cleanup this and similar bugs...

thanks for you patience...

Thomas

> "Bischof, Rainer" wrote:
> 
> Thomas,
> 
> I just discovered a really ugly bug (don't know if this is already
> known):
> 
> When a transaction is committed the method broker.store(Object obj,
> boolean insert)  is called. This method calls
> JdbcAccess.executeInsert(ClassDescriptor mif, Object obj) or
> JdbcAccess.executeUpdate(ClassDescriptor mif, Object obj) but does not
> check for the return value !
> Since all Exceptions are caught inside these methods and only the
> return value true/false indicates if the operation was successful.
> That means that any SQLExceptions thrown are caught but not handled
> properly, the transaction is committed and the calling client
> application does not receive any exception.
> The same bug is also found in the delete process.
> 
> Should be priority 1, I guess.
> 
> I general I think it is better to handle exceptions at the highest
> level possible. In this case I would prefer the JdbcAccess methods to
> throw an exception and have PersistenceBroker catch it and wrap it
> into a PersistenceBrokerException.
>

[OJB-developers] using one transaction with multiple brokers

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

Hi all !

Is it possible to spam one transaction to multiple brokers ??

1 case : using teh same VM
2 case : usinf diferent VM's

Basically I'd like to start one transaction on the behalf of one broker
and let other brokers participate one the same transaction !

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

[OJB-developers] Nasty bug

[Bischof, R. <rai...@ed...>]

Thomas,
 
I just discovered a really ugly bug (don't know if this is already known):
 
When a transaction is committed the method broker.store(Object obj, boolean
insert)  is called. This method calls
JdbcAccess.executeInsert(ClassDescriptor mif, Object obj) or
JdbcAccess.executeUpdate(ClassDescriptor mif, Object obj) but does not check
for the return value !
Since all Exceptions are caught inside these methods and only the return
value true/false indicates if the operation was successful.
That means that any SQLExceptions thrown are caught but not handled
properly, the transaction is committed and the calling client application
does not receive any exception.
The same bug is also found in the delete process.
 
Should be priority 1, I guess.
 
I general I think it is better to handle exceptions at the highest level
possible. In this case I would prefer the JdbcAccess methods to throw an
exception and have PersistenceBroker catch it and wrap it into a
PersistenceBrokerException. 
 

Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 

AW: [OJB-developers] Integrating with Turbine

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

Hi Leandro,

> Hi all.
> I'm trying to integrate OJB qith Turbine framework
> (http://jakarta.apache.org/turbine)! 
> Turbine is a good framework because you can decide you persistence
> strategy. The default way is to use torque, a tool that comes with
> turbine, to generate a persistence layer using Peers () based on a xml
> schema description of all Business Objects. I know how to use 
> torque an
> I could make torqe generate the same code it does for 
> Turbine, using OJB
> as Persistence API. Anyone is interested ??
> 

Yes, that can be quite interesting.
I'm planning to have a special page for contributions, i.e. code that does
not go into the OJB codebase, but may be useful for developers.
It may contain utility classes as Paging support or
integration code for certain databases or
integration code for certain application frameworks.

Right now I'm collecting these things (there is already some code for a
Struts integration).
So if you want to contribute your code, just contact me.

Thanks for your good ideas,

Thomas

AW: [OJB-developers] Using Log4j

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

Hi Leandro,


> > I have been looking around for a preprocessor for a while that would
> > allow to remove logging instrumentation from production 
> code, but allow
> > a detailed logging in development mode.
> 
> Hi thomas, have you ever looked at aspectj ???
> I think AOP (Aspect Oriented Programmig) would replace a preprocessor
> with some benefits ! see http://aspectj.org
> 
> let me know what you think !
> 

I'm quite interested in AOP, MOP and Reflective Architectures in general. In
fact the OJB PersistenceBroker uses a MetaLevel Architecture. 
Of course AOP is much more generic than a home grown preprocessor. 
But I want to keep things simple. Using the CodeSwitcher is very simple.
It's one Java class with say 150 lines of code. It can do everything we need
right now. And it's easily to integrate into the ANT build scripts (took
only 5 minutes).

AFAIK you need a special compiler and debugger for apsectJ. This is a no go
for IDE's like VisualAge for Java...

but nevertheless: thanks for your suggestion!

Thomas

Re: [OJB-developers] Errors with PK-only objects

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

OOps,

that's a bug !
I'll place it on the to do list !

thanks,

Thomas

> "Bischof, Rainer" wrote:
> 
> Thomas,
> 
> I am not sure if this has been raised before:
> There is a problem with OJB when working with objects that contain
> only the attributes that make up the PK and no other attributes , e.g.
> if you model a reference table as an object.
> 
> When the broker tries to save such an object it issues an update
> statement which contains no set-clause, something like "update t_ref
> where pk1=1 and pk2=2". This of course is invalid SQL.
> 
> Pls see the stacktrace below.
> 
> Thx
> Rainer Bischof
> EDS - Electronic Data Systems
> European Automotive Solution Center - Distributed Solutions
> Email: rai...@ed...
> 
> 
> java.sql.SQLException: []Incorrect syntax near the keyword 'WHERE'.
> 
>  at com.inet.tds.TdsConnection.a(Unknown Source)
> 
>  at com.inet.tds.TdsStatement.a(Unknown Source)
> 
>  at com.inet.tds.TdsStatement.byte(Unknown Source)
> 
>  at com.inet.tds.TdsStatement.executeUpdate(Unknown Source)
> 
>  at
> ojb.broker.accesslayer.JdbcAccess.executeUpdate(JdbcAccess.java:218)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1086)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:306)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.storeCollections(PersistenceBrokerImpl.java:388)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1093)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:306)
> 
>  at
> ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1037)
> 
>  at ojb.odmg.states.StateOldDirty.commit(StateOldDirty.java:102)
> 
>  at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114)
> 
>  at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:210)
> 
>  at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:345)

[OJB-developers] Integrating with Turbine

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

Hi all.
I'm trying to integrate OJB qith Turbine framework
(http://jakarta.apache.org/turbine)! 
Turbine is a good framework because you can decide you persistence
strategy. The default way is to use torque, a tool that comes with
turbine, to generate a persistence layer using Peers () based on a xml
schema description of all Business Objects. I know how to use torque an
I could make torqe generate the same code it does for Turbine, using OJB
as Persistence API. Anyone is interested ??

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

Re: [OJB-developers] Using Log4j

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

On Thu, 2001-11-22 at 09:01, Thomas Mahler wrote:
 
> I have been looking around for a preprocessor for a while that would
> allow to remove logging instrumentation from production code, but allow
> a detailed logging in development mode.

Hi thomas, have you ever looked at aspectj ???
I think AOP (Aspect Oriented Programmig) would replace a preprocessor
with some benefits ! see http://aspectj.org

let me know what you think !

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

[OJB-developers] Errors with PK-only objects

[Bischof, R. <rai...@ed...>]

Thomas,
 
I am not sure if this has been raised before:
There is a problem with OJB when working with objects that contain only the
attributes that make up the PK and no other attributes , e.g. if you model a
reference table as an object.
 
When the broker tries to save such an object it issues an update statement
which contains no set-clause, something like "update t_ref where pk1=1 and
pk2=2". This of course is invalid SQL.
 
Pls see the stacktrace below.
 
Thx
Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 

 
 
java.sql.SQLException: []Incorrect syntax near the keyword 'WHERE'.
 
 at com.inet.tds.TdsConnection.a(Unknown Source)
 
 at com.inet.tds.TdsStatement.a(Unknown Source)
 
 at com.inet.tds.TdsStatement.byte(Unknown Source)
 
 at com.inet.tds.TdsStatement.executeUpdate(Unknown Source)
 
 at ojb.broker.accesslayer.JdbcAccess.executeUpdate(JdbcAccess.java:218)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1
086)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:3
06)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.storeCollections(PersistenceBroker
Impl.java:388)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1
093)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:3
06)
 
 at
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1
037)
 
 at ojb.odmg.states.StateOldDirty.commit(StateOldDirty.java:102)
 
 at ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:114)
 
 at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:210)
 
 at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:345)

Re: [OJB-developers] Using Log4j

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

-------- Original Message --------
Subject: Re: [OJB-developers] Using Log4j
Date: Wed, 01 Jan 1997 00:51:17 +0100
From: Thomas Mahler <tho...@ho...>
Organization: NOORG
To: "Bischof, Rainer" <rai...@ed...>
References:
<412...@es...>

Hi all,

integrating a proper logging mechanism is on the OJB todo list for one
year now...
I have been thinking of using Log4j, as I have been using it for other
projects as well and like its simple api. There are also a lot of useful
LogAppenders available that address a lot of peoples needs.

The Lumberjack approach sounds quite promising. I will have a look at
it.

The main reason why I did not start with integrating logging until now
is performance.
There are many performance critical parts in OJB that would be dead slow
if logging is enabled in a production environment.

I have been looking around for a preprocessor for a while that would
allow to remove logging instrumentation from production code, but allow
a detailed logging in development mode.

I just found a very simple preprocessor in the HypersonicSQL project.
It allows you to do things like:

//#ifdef DEBUG
String logMsg = ...; // computing logmessages is often very time
consuming
logger.debug(logMsg);
//#endif

by running the CodeSwitcher with a -DEBUG switch you can then disable
logging. (The CodeSwitcher just modifies the above code to:
//#ifdef DEBUG
/*
String logMsg = ...; // computing logmessages is often very time
consuming
logger.debug(logMsg);
*/
//#endif

I already used this preprocessor to turn on JDK1.3 Proxies by default
and to use a JDK1.2 based replacement if required.

Thanks for your suggestions,


Thomas

Re: AW: [OJB-developers] lazy loading

[Georg S. <ge...@me...>]

Thx Thomas,

> For the time beeing you can do the following:
>
> 1. before loading a productgroup with say 10.000 associated Articles you
> disable cascading loading Articles by calling setCascadeRetrieve(false) on
> the repective CollectionDescriptor.
>
> 2. load the productgroup with getObjectByQuery(...). No ARticles (also no
> proxies) will loaded !!!
>
> 3. reset cascade load by setCascadeRetrieve(true) to rest step 1.)

Good idea, but what happens if I later want to access the articles. I
could do this by calling getObjectByQuery again, but that time the object
would come from the cache. Does the cache handle this situation correctly
(i.e. reloads the articles)?

Greetings

Georg

AW: [OJB-developers] lazy loading

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

Hi Georg,


> -----Urspr=FCngliche Nachricht-----
> Von: Georg Schneider [mailto:ge...@me...]
> Gesendet: Donnerstag, 22. November 2001 11:57
> An: obj...@li...
> Betreff: [OJB-developers] lazy loading
>=20
>=20
> Hi,
> I have a question regarding lazy loading. Let's say I have the
> ProductGroup and Article class from tutorial3 and there are 100.000
> articles. If I am only interested in the description of the=20
> ProductGroup,
> does the lazy-loading mechanism via proxies load the identities (via =
a
> join with the Article table I suppose) which I actually don't need =
and
> when having 100.000 or more can be very slow,

Yes, proxies are based on Identities. So each proxy has an internal =
identity
representing the real object.

 or is this=20
> deffered until
> the point where I actually want to look at the Articles.
>=20

There have been feature requests to have something like
"collection-proxies". This way there would be only one proxy object for =
all
Articles associated to a ProductGroup.=20
This feature request is already on the todo-list.

For the time beeing you can do the following:

1. before loading a productgroup with say 10.000 associated Articles =
you
disable cascading loading Articles by calling setCascadeRetrieve(false) =
on
the repective CollectionDescriptor.

2. load the productgroup with getObjectByQuery(...). No ARticles (also =
no
proxies) will loaded !!!

3. reset cascade load by setCascadeRetrieve(true) to rest step 1.)

HTH,

Thomas



> sincerly
>=20
> Georg
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

[OJB-developers] lazy loading

[Georg S. <ge...@me...>]

Hi,
I have a question regarding lazy loading. Let's say I have the
ProductGroup and Article class from tutorial3 and there are 100.000
articles. If I am only interested in the description of the ProductGroup,
does the lazy-loading mechanism via proxies load the identities (via a
join with the Article table I suppose) which I actually don't need and
when having 100.000 or more can be very slow, or is this deffered until
the point where I actually want to look at the Articles.

sincerly

Georg

Re: [OJB-developers] Using Log4j

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

On Wed, 2001-11-21 at 14:10, ber...@wa... wrote:
> Hi Thomas,

Hello, I new to this list and OJB

> 
> Did you ever thought about using Log4j in your project.
> (http://jakarta.apache.org/log4j/docs/manual.html)
> 
> Looking at the source I see quite often see things like
> 
> catch (Exception e )
> {
>    System.err.println(e.)
>    .....
> }
> 
> or
> if (debug)
> {
>    System.err.println(xxx)
> }
> 
> I've used log4j in some of my projets and it has the following
advantages:

I've used it too and it's a wonderfull tool !

> 
> You can have a better control on wat should be printed out  with 4
levels
> of logging debug, info, warn, error
> You can use a configuration file (property file or xml) to change the
level
> of logging so you don't need the setDebug and if (debug)
> You can use te same configuration file to tell the format of a line,
for
> example adding a time stamp, the threat name,...
> My favorite is that you can control where message are going to, the
> console, a file, unix syslogd.
> 
> The main disadvantage is that you are creating a dependency on a
external
> package but it comes from the Jakarta project and is well supported.

We could wrap Log4J inside OJB to minimize coupling between both
projects

> 
> and of course that some code need to be changed, but most of it is
> repetitive; Add a static Category class member to some classes and
> replace the  System.err with CAT.info or CAT.debug,....
> 
> Thank you for the great code you are writing
> 
> Bertrand

There is another tool that I think is very promissing AspectJ (see
http://aspectj.org). We can used it as a logger mechanism and other
things too !

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

Re: [OJB-developers] SQL schema ??

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

Hi Leandro,

the DDL is contained in the file src/test/setup/sql1.txt.
This file is a Script used by the OJB build process.
You just have to change the lines for loading the jdbc driver class and
the connect url to match you environment.
Then you just call build.sh tests and you get the database tables and
all test data generated for you.

If you want to run the Junit applications against postgres you have to
edit the file src/test/ojb/repository.xml.
You must comment out the default JDBCConnectionDescriptor and uncomment
the Postgres JdbcConnectiondescriptor.

enJoy,

Thomas


Leandro Rodrigo Saad Cruz wrote:
> 
> Hi all ! where can I find SQL schema for OJB internal tables ???
> I'm using PostgreSQL :)
> 
> --
> Leandro Rodrigo Saad Cruz
> IT - Inter Business Tecnologia e Servicos (IB)
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] SQL schema ??

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

Hi all ! where can I find SQL schema for OJB internal tables ???
I'm using PostgreSQL :)

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)

RE: [OJB-developers] Using Log4j

[Bischof, R. <rai...@ed...>]

Bertrand,

you are right this package namespace issue involves putting the lumberjack
classes into the JVM installation path. This is something that is OK for a
developer's machine but not 10'000s of client machines or for a server where
you don't have access to all files.

That's why we moved all classes of this lumberjack package into the
namespace of our project when we used it. That way you still have
modifications when you finally want to use the JDK1.4 logging but this is
reduced to modifications in the import statements. At least for our project
this was OK...

I am not really happy about this workaround but I guess it is better than to
introduce something that will render useless in a few months.

Besides: Some comments about limited functionality are not really
limitations, like it can only log to console, file and socket. Yes it is
true but you can write your own handler that logs to your printer, your
logserver or your CDRom if you like.
Support for the future de-facto standard will be high in all areas, even if
it is probably weaker than Log4J. 
Same thing as with the common comparison between JSP and the templating
systems (http://www.servlets.com/soapbox/problems-jsp.html). The best does
not always win ...

In the end it's up to Thomas to decide as I guess he will have to perform
the work....

Regards

Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions


-----Original Message-----
From: ber...@wa... [mailto:ber...@wa...]
Sent: Mittwoch, 21. November 2001 18:08
To: Bischof, Rainer; obj...@li...
Subject: RE: [OJB-developers] Using Log4j



Rainer,

I don't about this "LumberJack" project because the logging api didn't
exist when I started using log4j.
There is an interesting comment about log4j and the jdk 1.4 on the log4j
web page,
http://jakarta.apache.org/log4j/docs/critique.html
maybe you will understand it all, I don't.
The project you are referring about is mentioned in the document.
They argue that, as sun has put the api in the java namespace it is not
trivial to emulate it for earlier version.

One thing that might be important is that Log4j is a stable and mature
package, used in project like Tomcat and Jboss.

Bertrand



 

                    "Bischof,

                    Rainer"               To:     ber...@wa...,
obj...@li...     
                    <rainer.bischo        cc:

                    f...@ed...>            Subject:     RE: [OJB-developers]
Using Log4j                                       
 

                    21/11/2001

                    17:51

 

 





Bertrand,

as you may know the upcoming JDK 1.4 will introduce a complete logging
framework. I know this does not really help if you  are tied to pre-1.4
versions.
But there is a logging package called "LumberJack" out there on
http://sourceforge.net/projects/javalogging/ which implements the same API
as the upcoming JDK 1.4.
If we use this API we can easily switch to the new logging framework when
1.4 is the de-facto standard.

cu
rb


Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions


-----Original Message-----
From: ber...@wa... [mailto:ber...@wa...]
Sent: Mittwoch, 21. November 2001 17:11
To: obj...@li...
Subject: [OJB-developers] Using Log4j


Hi Thomas,

Did you ever thought about using Log4j in your project.
(http://jakarta.apache.org/log4j/docs/manual.html)

Looking at the source I see quite often see things like

catch (Exception e )
{
   System.err.println(e.)
   .....
}

or
if (debug)
{
   System.err.println(xxx)
}

I've used log4j in some of my projets and it has the following advantages:

You can have a better control on wat should be printed out  with 4 levels
of logging debug, info, warn, error
You can use a configuration file (property file or xml) to change the level
of logging so you don't need the setDebug and if (debug)
You can use te same configuration file to tell the format of a line, for
example adding a time stamp, the threat name,...
My favorite is that you can control where message are going to, the
console, a file, unix syslogd.

The main disadvantage is that you are creating a dependency on a external
package but it comes from the Jakarta project and is well supported.

and of course that some code need to be changed, but most of it is
repetitive; Add a static Category class member to some classes and
replace the  System.err with CAT.info or CAT.debug,....

Thank you for the great code you are writing

Bertrand





_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers




_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

RE: [OJB-developers] Using Log4j

[<ber...@wa...>]

Rainer,

I don't about this "LumberJack" project because the logging api didn't
exist when I started using log4j.
There is an interesting comment about log4j and the jdk 1.4 on the log4j
web page,
http://jakarta.apache.org/log4j/docs/critique.html
maybe you will understand it all, I don't.
The project you are referring about is mentioned in the document.
They argue that, as sun has put the api in the java namespace it is not
trivial to emulate it for earlier version.

One thing that might be important is that Log4j is a stable and mature
package, used in project like Tomcat and Jboss.

Bertrand



                                                                                                                              
                    "Bischof,                                                                                                 
                    Rainer"               To:     ber...@wa..., obj...@li...     
                    <rainer.bischo        cc:                                                                                 
                    f...@ed...>            Subject:     RE: [OJB-developers] Using Log4j                                       
                                                                                                                              
                    21/11/2001                                                                                                
                    17:51                                                                                                     
                                                                                                                              
                                                                                                                              




Bertrand,

as you may know the upcoming JDK 1.4 will introduce a complete logging
framework. I know this does not really help if you  are tied to pre-1.4
versions.
But there is a logging package called "LumberJack" out there on
http://sourceforge.net/projects/javalogging/ which implements the same API
as the upcoming JDK 1.4.
If we use this API we can easily switch to the new logging framework when
1.4 is the de-facto standard.

cu
rb


Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions


-----Original Message-----
From: ber...@wa... [mailto:ber...@wa...]
Sent: Mittwoch, 21. November 2001 17:11
To: obj...@li...
Subject: [OJB-developers] Using Log4j


Hi Thomas,

Did you ever thought about using Log4j in your project.
(http://jakarta.apache.org/log4j/docs/manual.html)

Looking at the source I see quite often see things like

catch (Exception e )
{
   System.err.println(e.)
   .....
}

or
if (debug)
{
   System.err.println(xxx)
}

I've used log4j in some of my projets and it has the following advantages:

You can have a better control on wat should be printed out  with 4 levels
of logging debug, info, warn, error
You can use a configuration file (property file or xml) to change the level
of logging so you don't need the setDebug and if (debug)
You can use te same configuration file to tell the format of a line, for
example adding a time stamp, the threat name,...
My favorite is that you can control where message are going to, the
console, a file, unix syslogd.

The main disadvantage is that you are creating a dependency on a external
package but it comes from the Jakarta project and is well supported.

and of course that some code need to be changed, but most of it is
repetitive; Add a static Category class member to some classes and
replace the  System.err with CAT.info or CAT.debug,....

Thank you for the great code you are writing

Bertrand





_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

RE: [OJB-developers] Using Log4j

[Bischof, R. <rai...@ed...>]

Bertrand,

as you may know the upcoming JDK 1.4 will introduce a complete logging
framework. I know this does not really help if you  are tied to pre-1.4
versions.
But there is a logging package called "LumberJack" out there on
http://sourceforge.net/projects/javalogging/ which implements the same API
as the upcoming JDK 1.4. 
If we use this API we can easily switch to the new logging framework when
1.4 is the de-facto standard.

cu
rb


Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions


-----Original Message-----
From: ber...@wa... [mailto:ber...@wa...]
Sent: Mittwoch, 21. November 2001 17:11
To: obj...@li...
Subject: [OJB-developers] Using Log4j


Hi Thomas,

Did you ever thought about using Log4j in your project.
(http://jakarta.apache.org/log4j/docs/manual.html)

Looking at the source I see quite often see things like

catch (Exception e )
{
   System.err.println(e.)
   .....
}

or
if (debug)
{
   System.err.println(xxx)
}

I've used log4j in some of my projets and it has the following advantages:

You can have a better control on wat should be printed out  with 4 levels
of logging debug, info, warn, error
You can use a configuration file (property file or xml) to change the level
of logging so you don't need the setDebug and if (debug)
You can use te same configuration file to tell the format of a line, for
example adding a time stamp, the threat name,...
My favorite is that you can control where message are going to, the
console, a file, unix syslogd.

The main disadvantage is that you are creating a dependency on a external
package but it comes from the Jakarta project and is well supported.

and of course that some code need to be changed, but most of it is
repetitive; Add a static Category class member to some classes and
replace the  System.err with CAT.info or CAT.debug,....

Thank you for the great code you are writing

Bertrand





_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] Using Log4j

[<ber...@wa...>]

Hi Thomas,

Did you ever thought about using Log4j in your project.
(http://jakarta.apache.org/log4j/docs/manual.html)

Looking at the source I see quite often see things like

catch (Exception e )
{
   System.err.println(e.)
   .....
}

or
if (debug)
{
   System.err.println(xxx)
}

I've used log4j in some of my projets and it has the following advantages:

You can have a better control on wat should be printed out  with 4 levels
of logging debug, info, warn, error
You can use a configuration file (property file or xml) to change the level
of logging so you don't need the setDebug and if (debug)
You can use te same configuration file to tell the format of a line, for
example adding a time stamp, the threat name,...
My favorite is that you can control where message are going to, the
console, a file, unix syslogd.

The main disadvantage is that you are creating a dependency on a external
package but it comes from the Jakarta project and is well supported.

and of course that some code need to be changed, but most of it is
repetitive; Add a static Category class member to some classes and
replace the  System.err with CAT.info or CAT.debug,....

Thank you for the great code you are writing

Bertrand

Re: [OJB-developers] features

[Georg S. <ge...@me...>]

Hi Thomas,

Thx for your prompt answer. This sounds like a very reasonable time scale
to me. At the moment I am trying to get aquainted with the code. I like
it!

Sincerly

Georg

On Wed, 1 Jan 1997, Thomas Mahler wrote:

> Hi Georg,
>
> thanks for your interest in OJB!
>
> Georg Schneider wrote:
> >
> > Hi,
> > I am working on a project where we have been using castor so far.
> > Unfortunately polymorphism is not very high on castors development agenda
> > and since I also regard this as one of the basic features of any
> > object-oriented design effort I was very pleased to find it in OJB. I have
> > been looking through the OJB documentation and I was quite impressed with
> > the clear design. I have also taken a look at your TODO list and I was
> > wondering if you could give a rough time estimate for the inclusion of the
> > following features:
> > - m:n relations
>
> I will start working on support m:n relations this week. When there are
> no other priority 1 tasks interfering there should be something running
> until 7th of December.
>
> > - path expressions in OQL
> >
>
> Path expressions are an important feature and I hope to start on them
> after m:n and automatic foreign key assignment. So maybe January 2002 is
> a good estimate.
>
> For the time beeing OJB supports a direct SQL interface that allows
> Object loading based on arbitrary SQL statements.
>
> > I would appreciate very much if you could give me some idea about the time
> > horizon.
> >
>
> In general I don't like to make promises on when a certain feature will
> be implemented.
> OJB is based on the contributions of volunteers an of my efforts to keep
> everything in sync and to maintain the overall design. If there are no
> contributions coming in, I have to implement things on my own.
> That's OK for me, but I'm obviously the OJB "bottleneck".
> Once I start to commit myself to certain deadlines the pressure on this
> bottleneck grows!
>
> But OJB should be fun to work on and not be stress!
>
> Of course people intending to use OJB need some reliability on when they
> can use the tool for certain features.
>
> --  Thomas
>
> > thanks in advance
> >
> > Georg
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>

RE: [OJB-developers] features

[Bischof, R. <rai...@ed...>]

Thomas,

>yesterday evening I started to cleanup my code so that you could start
>working on it.
>But everything went so smooth, that I completely finished this
>InMemoryLockManagement within an hour...

That's what I mean with "responsive"!!!

Thx
Rainer



Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 

AW: [OJB-developers] features

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

Hi Rainer, hi all,

> -----Urspr=FCngliche Nachricht-----
> Von: Bischof, Rainer [mailto:rai...@ed...]
> Gesendet: Montag, 19. November 2001 23:09
> An: Thomas Mahler
> Cc: obj...@li...
> Betreff: RE: [OJB-developers] features
>=20
>=20
> All,
>=20
> I just had a closer look at the locking stuff as it is=20
> implemented right
> now.
> The only class that makes locks persistent is the=20
> AbstractLockStrategy.

right !

> Unfortunately all LockStrategies inherit from that which=20
> limits re-use of
> the useful code in and around the LockStrategies.
>=20
> What about the following approach for the new in-memory locking:
> * We extract those parts of the AbstractLockStrategy that=20
> store / retrieve
> the persistent locks. These parts go into a=20
> PersistentLockServiceImpl which
> implements a LockService interface. We create a similar class
> InMemoryLockServiceImpl that does the same without accessing=20
> the DB. (does
> anybody have a better name for the last class??)=20
>=20
> * We change the AbstractLockStrategy not to perform DB access=20
> itself but to
> use an implementation of the LockService interface for these=20
> activities.
> =20

I have used exactly this approach in my proposition!

> * The LockStrategyFactory configures the LockStrategies=20
> created to use the
> appropriate LockService implementation (persistent/in-memory).
>=20

I made things configurable through the OJB.properties file.

> That way we can re-use the complete LockMgrDefaultImpl, LockEntry,
> LockStrategyFactory, the different Lockstrategies and their=20
> configuration.
> Most of the logic in AbstractLockStrategy can be re-used in the
> PersistentLockServiceImpl. We should not have any API changes=20
> at all. It
> seems to be a clean approach.
>=20

Yes I came to the same conclusion that it is not necessary to exchange =
the
whole LockManager, but only the parts dealing with lock persistence.

> Have I missed something? Looks just too easy. I'm sure I=20
> missed something...
> Any comments?
>=20
>=20
> Thomas,=20
> is this similar to your intended approach or do you have another =
idea?
> I guess it's not that much work for you to provide me a method =
"String
> getLockServiceClass()" in=20
> PersistenceBrokerFactoryConfiguration, right? That
> way I only have one area to work on and don't have to find my=20
> way through
> the configuration stuff as well.
> Or do we need to have different locking approaches for=20
> different classes?
> Than I have no idea how to get that information per class as=20
> I have not
> really looked into the XML configuration classes... ;-)
>=20
> Regarding the timing: I hope to find some time for this end=20
> of next week so
> it might have a chance to go into the next release if it=20
> passes the unit
> tests.=20
>

yesterday evening I started to cleanup my code so that you could start
working on it.
But everything went so smooth, that I completely finished this
InMemoryLockManagement within an hour...

But nevertheless I will make a prerelease build and post it to you so =
that
you may have a look on it. Maybe you detect any tuning options, etc.

Thanks,

Thomas

 =20