Re: xml parser problems

2003-05-27 Thread Armin Waibel
Hi Leandro,

I made some modifications in
RepositoryPersistor (using InputSource)
and MetadataManager but this
shouldn't change the behaviour of the
classes - do I overlook something?

regards,
Armin

- Original Message -
From: "Leandro Rodrigo Saad Cruz" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, May 27, 2003 10:54 PM
Subject: xml parser problems


> Hi all. I noticed that OJB started to look for repository.dtd outside
> the app classpath. Why ? now I have to put the repository.dtd file on
my
> app root directory instead of WEB-INF/classes.
>
> --
> Leandro Rodrigo Saad Cruz
> IT - Inter Business Tecnologia e Servicos (IB)
> http://www.ibnetwork.com.br
> http://jakarta.apache.org/ojb
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: xml parser problems

2003-05-27 Thread Thomas Mahler
I'm not aware of any changes in this area.
It works still fine for me.
Thomas

Leandro Rodrigo Saad Cruz wrote:
Hi all. I noticed that OJB started to look for repository.dtd outside
the app classpath. Why ? now I have to put the repository.dtd file on my
app root directory instead of WEB-INF/classes.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Torque and ojbcore-schema.xml

2003-05-27 Thread Mauricio CASTRO
Hi,

How do I use torque with src/schema/ojbcore-schema.xml? How can I use Torque
to generate tables from the repository_user.xml?


Thank you.
Mauricio Castro.


"Until they become conscious they will never rebel, and until after they
have rebelled they cannot become conscious"
--Orwell 1984

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Logging issues/suggestions

2003-05-27 Thread Mauricio CASTRO
Great!

>
> P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server would
help
> a lot of newbies as well :-) (I'm assuming this is the problem - that .tgz
> is being interpreted as a TAR archive instead of a GZIP archive. An entry
> like this into Apache's mime.types might help: "application/x-gzip  tgz")


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Logging issues/suggestions

2003-05-27 Thread Michael Hart
Hi,

I'm not sure if this should be considered a developer issue or not, so if
it's more relevant to the developer's list, let me know and I'll move it
over there.

It seems to me that while the logging in OJB is currently pretty good, it
could be improved quite a bit by a number of small enhancements before going
to RC4:


1. Changing line 247 in OJB.properties that currently reads:
org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=WARN
to:
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=WARN

because AFAICS the first line doesn't do anything. (users can then change
the level to DEBUG if they want to see interesting output)

Note that in the log4j.properties file, JdbcAccessImpl is there (commented)
instead of the incorrect JdbcAccess.


2. Making sure PoorMansLoggerImpl actually checks the logging level before
returning false for isDebugEnabled() (instead of always returning false,
which stops a number of classes from outputting debug statements, including
SqlGeneratorDefaultImpl). Log4J works fine, but PoorMansLoggerImpl should as
well.


3. Including logging statements in JdbcAccessImpl.java after each statement
is bound (usually before it's executed). If the PreparedStatement
implementation has overridden the toString method in a useful way (as does
the PostGres JDBC driver, and I'm sure others), then you can see the SQL
without needing P6Spy. For example, lines 258-259 could become:

broker.serviceStatementManager().bindStatement(stmt, query, cld, 1);
logger.debug("Executing SQL: " + stmt);
ResultSet rs = stmt.executeQuery();

I've made this change in my local version of JdbcAccessImpl.java and it
works a treat.

HSQLDB doesn't have the toString method in their PreparedStatement
implementation, but if you download the source, then you can see that it's a
very easy fix. Just add this method to
src/org/hsqldb/jdbcPreparedStatement.java:

public String toString()
{
return this.build();
}

(unfortunately jdbcPreparedStatement.build() is a private method so the
above method cannot be implemented in a subclass).


Do these suggestions sound useful to anyone, or am I way off track?

Cheers,

Michael

P.S. Oh yeah, and fixing the MIME type for .tgz on the web-server would help
a lot of newbies as well :-) (I'm assuming this is the problem - that .tgz
is being interpreted as a TAR archive instead of a GZIP archive. An entry
like this into Apache's mime.types might help: "application/x-gzip  tgz")


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Archive contains obsolescent base-64 headers?

2003-05-27 Thread Michael Hart
There are a lot of messages about this issue in the archives:

Rename it to db-ojb-1.0.rc3.tgz and use:

tar -xzf db-ojb-1.0.rc3.tgz

(Actually, the renaming probably isn't strictly necessary, but it will keep
you from getting confused later)

-Original Message-
From: Mauricio CASTRO [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 28 May 2003 5:37 AM
To: [EMAIL PROTECTED]
Subject: tar: Archive contains obsolescent base-64 headers?



[EMAIL PROTECTED] ojb]$ tar -xf db-ojb-1.0.rc3.tar
tar: Archive contains obsolescent base-64 headers
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors




"Until they become conscious they will never rebel, and until after they
have rebelled they cannot become conscious"
--Orwell 1984

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: How to handle SQLException in OJB?

2003-05-27 Thread Michael Hart
Hi Leon,

It looks like you're logging level is not set correctly - you need to set
the logging level of JdbcAccessImpl to FATAL because the printStackTrace
occurs when set to ERROR or below.

If you're using the default logger (PoorMansLoggerImpl), then you want to
change your logging levels in OJB.properties:

# Note that this is NOT JdbcAccess, but rather JdbcAccessImpl
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=FATAL


After this, you can catch a PersistenceBrokerException and check whether it
is an SQL exception or not:

try
{
Collection allProducts = broker.getCollectionByQuery(query);
}
catch (PersistenceBrokerException pbx)
{
// The PersistenceBrokerSQLException is nested in pbx and the 
// SQLException is nested in that (ie pbx.getCause().getCause())
if (pbx.getCause() instanceof PersistenceBrokerSQLException) {
System.out.println("SQL problem " + pbx.getCause());
}
}

Cheers,

Michael

-Original Message-
From: Leon [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 28 May 2003 1:38 AM
To: OJB Users List
Subject: Re: How to handle SQLException in OJB?

Here is it. I am using PersistenceBroker.

Thanks.

...

tx.begin();

broker.store(registryvo);

tx.commit();

} catch (SQLException e) {

e.printStackTrace();

} catch (PersistenceBrokerException e) {

if (log.isEnabledFor(Priority.INFO)) {

log.info(

"* Something went wrong while insert a record to account
**");

}

e.printStackTrace();

throw new DataAccessException("Error in RegistryDAO.insert():" +

e.toString(), e);

}

- Original Message -
From: "Michael Hart" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, May 27, 2003 11:12 AM
Subject: RE: How to handle SQLException in OJB?


> > I already tried that but it is unreachable catch block.
>
> It could be from the logger - have you disabled output from that? (or at
> least set the log-level to something high-ish)
>
> The default logger (PoorMansLoggerImpl) will print a stack trace if a
> Throwable is logged (perhaps log4j does as well), so this may be your
> problem.
>
> Which code is causing the problem? Can you give a sample? Are you using
> PersistenceBroker or ODMG or JDO?
>
> Cheers,
>
> Michael
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



What broker gets used by proxies?

2003-05-27 Thread David Warnock
Hi,

If I do the following pseudo code what broker is used to fill the proxies?

  get a broker
  execute a query and get back some contact objects.
  close the broker
  access the proxied list of emailaddresses for a contact
Does the contact remember which broker was used to fill itself and use 
that again to get the proxied objects?

OR

Does the contact get a new broker, use it and close it?

If it is the first of these then I guess I am going to get potential 
multi-user issues as someone else may have started to use that broker by 
the time contact needs to load it's proxied objects.

So do I need to keep hold of a broker until I have finished all the 
operations on all the objects I get from that broker?

Thanks

David
--
David Warnock, Sundayta Ltd. http://www.sundayta.com
iDocSys for Document Management. VisibleResults for Fundraising.
Development and Hosting of Web Applications and Sites.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


xml parser problems

2003-05-27 Thread Leandro Rodrigo Saad Cruz
Hi all. I noticed that OJB started to look for repository.dtd outside
the app classpath. Why ? now I have to put the repository.dtd file on my
app root directory instead of WEB-INF/classes.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



tar: Archive contains obsolescent base-64 headers?

2003-05-27 Thread Mauricio CASTRO


[EMAIL PROTECTED] ojb]$ tar -xf db-ojb-1.0.rc3.tar
tar: Archive contains obsolescent base-64 headers
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors




"Until they become conscious they will never rebel, and until after they
have rebelled they cannot become conscious"
--Orwell 1984

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]