4:42 p.m.
Hi there,
I'm looking at fixing hbm2doc to work with inner-classes and figure
the following changes to POJOClass are necessary as it stands:
- getShortName, getDeclarationName and getJavaTypeName need to return
X.Y for inner classes, not just Y
I'm not entirely sure of the distinction between getShortName and
getDeclarationName - the latter seems to account for meta attributes
whereas the former doesn't. Also, changing getJavaTypeName requires
altering the behaviour of ImportContextImpl such that:
ImportContextImpl.importType("a.b.X.Y") == "X.Y" (import a.b.X)
Obviously these changes will have repercussions in other areas of
hbm2x. Any thoughts on how to minimise damage?
Mark
8:45 p.m.
I'm looking at fixing hbm2doc to work with inner-classes and
figure
the following changes to POJOClass are necessary as it stands:
- getShortName, getDeclarationName and getJavaTypeName need to return
X.Y for inner classes, not just Y
ok; not sure if the classes know if they are inner classes.
I'm not entirely sure of the distinction between getShortName
and
getDeclarationName - the latter seems to account for meta attributes
whereas the former doesn't. Also, changing getJavaTypeName requires
altering the behaviour of ImportContextImpl such that:
ImportContextImpl.importType("a.b.X.Y") == "X.Y" (import a.b.X)
Again, how do you know wether a name is a class or an inner class?
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
3:04 p.m.
On 24/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com> wrote:
> I'm not entirely sure of the distinction between
getShortName and
> getDeclarationName - the latter seems to account for meta attributes
> whereas the former doesn't. Also, changing getJavaTypeName requires
> altering the behaviour of ImportContextImpl such that:
>
> ImportContextImpl.importType("a.b.X.Y") == "X.Y" (import
a.b.X)
Again, how do you know wether a name is a class or an inner class?
Looking at the uses of ImportContext, the FQCN being passed into
importType is of the form that is return by Class.getName. For
inner-classes, this uses the dollar syntax, e.g. "a.b.X$Y". If this
is definitely the case, then we can change ImportContextImpl to
support inner-classes as described above.
I'm happy to patch this, but was curious about any knock-on effects.
I've tried running the tools tests but get a heap of errors - is there
any special configuration I'm unaware of for them to pass?
Mark
3:19 p.m.
On 24/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com>
wrote:
> > I'm not entirely sure of the distinction between getShortName and
> > getDeclarationName - the latter seems to account for meta attributes
> > whereas the former doesn't. Also, changing getJavaTypeName requires
> > altering the behaviour of ImportContextImpl such that:
> >
> > ImportContextImpl.importType("a.b.X.Y") == "X.Y" (import
a.b.X)
>
> Again, how do you know wether a name is a class or an inner class?
Looking at the uses of ImportContext, the FQCN being passed into
importType is of the form that is return by Class.getName. For
inner-classes, this uses the dollar syntax, e.g. "a.b.X$Y". If this
is definitely the case, then we can change ImportContextImpl to
support inner-classes as described above.
maybe...need to run the testsuite to see if something blows because of
that change.
I'm happy to patch this, but was curious about any knock-on
effects.
I've tried running the tools tests but get a heap of errors - is there
any special configuration I'm unaware of for them to pass?
What errors do you see ?
Parts of the testsuite runs best against HSQLDB with
hibernate.default_schema set to PUBLIC.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
4:03 p.m.
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com> wrote:
What errors do you see ?
Parts of the testsuite runs best against HSQLDB with
hibernate.default_schema set to PUBLIC.
Many of the tests fail with:
Testcase: testVersion took 0.344 sec
Caused an ERROR
Duplicate class name 'Basic' generated for
'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name where generated
for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
org.hibernate.cfg.JDBCBinderException: Duplicate class name 'Basic'
generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name
where generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
at org.hibernate.cfg.JDBCBinder.createPersistentClasses(JDBCBinder.java:168)
at org.hibernate.cfg.JDBCBinder.readFromDatabase(JDBCBinder.java:91)
at
org.hibernate.cfg.JDBCMetaDataConfiguration.readFromJDBC(JDBCMetaDataConfiguration.java:40)
at
org.hibernate.tool.JDBCMetaDataBinderTestCase.setUp(JDBCMetaDataBinderTestCase.java:137)
Any ideas? I'm running Branch_3_2 with no local modifications.
Thanks,
Mark
4:05 p.m.
which db are you running against ?!
/max
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com>
wrote:
> What errors do you see ?
>
> Parts of the testsuite runs best against HSQLDB with
> hibernate.default_schema set to PUBLIC.
Many of the tests fail with:
Testcase: testVersion took 0.344 sec
Caused an ERROR
Duplicate class name 'Basic' generated for
'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name where generated
for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
org.hibernate.cfg.JDBCBinderException: Duplicate class name 'Basic'
generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name
where generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
at
org.hibernate.cfg.JDBCBinder.createPersistentClasses(JDBCBinder.java:168)
at org.hibernate.cfg.JDBCBinder.readFromDatabase(JDBCBinder.java:91)
at
org.hibernate.cfg.JDBCMetaDataConfiguration.readFromJDBC(JDBCMetaDataConfiguration.java:40)
at
org.hibernate.tool.JDBCMetaDataBinderTestCase.setUp(JDBCMetaDataBinderTestCase.java:137)
Any ideas? I'm running Branch_3_2 with no local modifications.
Thanks,
Mark
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
4:16 p.m.
..and you have the default_schema set to PUBLIC ?
This error should only occur if the database somehow is returning the same
table name twice (e.g. reverse engineering multiple schemas)
/max
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com>
wrote:
> What errors do you see ?
>
> Parts of the testsuite runs best against HSQLDB with
> hibernate.default_schema set to PUBLIC.
Many of the tests fail with:
Testcase: testVersion took 0.344 sec
Caused an ERROR
Duplicate class name 'Basic' generated for
'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name where generated
for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
org.hibernate.cfg.JDBCBinderException: Duplicate class name 'Basic'
generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'. Same name
where generated for 'org.hibernate.mapping.Table(PUBLIC.BASIC)'
at
org.hibernate.cfg.JDBCBinder.createPersistentClasses(JDBCBinder.java:168)
at org.hibernate.cfg.JDBCBinder.readFromDatabase(JDBCBinder.java:91)
at
org.hibernate.cfg.JDBCMetaDataConfiguration.readFromJDBC(JDBCMetaDataConfiguration.java:40)
at
org.hibernate.tool.JDBCMetaDataBinderTestCase.setUp(JDBCMetaDataBinderTestCase.java:137)
Any ideas? I'm running Branch_3_2 with no local modifications.
Thanks,
Mark
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
4:47 p.m.
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com> wrote:
..and you have the default_schema set to PUBLIC ?
This error should only occur if the database somehow is returning the same
table name twice (e.g. reverse engineering multiple schemas)
Adding default_schema=PUBLIC fixes a few, and then using
hibernate.connection.url=jdbc:hsqldb:. fixed some others. The
majority of the remaining tests fail with:
Expected were higher, Last: {TABLE_SCHEM=PUBLIC, REMARKS=null,
TABLE_CAT=null, TABLE_NAME=Group, TABLE_TYPE=TABLE} expected:<0> but
was:<1>
junit.framework.ComparisonFailure: Expected were higher, Last:
{TABLE_SCHEM=PUBLIC, REMARKS=null, TABLE_CAT=null, TABLE_NAME=Group,
TABLE_TYPE=TABLE} expected:<0> but was:<1>
Mark
4:49 p.m.
Adding default_schema=PUBLIC fixes a few, and then using
hibernate.connection.url=jdbc:hsqldb:. fixed some others. The
majority of the remaining tests fail with:
Expected were higher, Last: {TABLE_SCHEM=PUBLIC, REMARKS=null,
TABLE_CAT=null, TABLE_NAME=Group, TABLE_TYPE=TABLE} expected:<0> but
was:<1>
junit.framework.ComparisonFailure: Expected were higher, Last:
{TABLE_SCHEM=PUBLIC, REMARKS=null, TABLE_CAT=null, TABLE_NAME=Group,
TABLE_TYPE=TABLE} expected:<0> but was:<1>
These errors occur because the db still contains some tables which should
not be the case.
This can be caused by interrupting the testsuite before it can clean up or
a test that doesn't cleanup properly.
Workaround: delete the db (easy for hsqldb ;)
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
5:10 p.m.
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com> wrote:
These errors occur because the db still contains some tables which
should
not be the case.
This can be caused by interrupting the testsuite before it can clean up or
a test that doesn't cleanup properly.
Workaround: delete the db (easy for hsqldb ;)
Hmm, tried this, tried in-memory db, still failing.. I'm simply
running ant clean junit from within HibernateExt/tools, Hibernate3 and
HibernateExt freshly checked-out from Branch_3_2, and hibernate-3.2
sibling dir created from Hibernate3 ant dist. I'm going to have to
move onto patching now, but any ideas welcome..
Mark
5:14 p.m.
ok, submit a patch and i can run the testsuite for it.
I'll see if something stupid is broken in the ant junit testsuite.
running it from eclipse creates no unknown failures on my side.
/max
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com>
wrote:
> These errors occur because the db still contains some tables which
> should
> not be the case.
>
> This can be caused by interrupting the testsuite before it can clean up
> or
> a test that doesn't cleanup properly.
>
> Workaround: delete the db (easy for hsqldb ;)
Hmm, tried this, tried in-memory db, still failing.. I'm simply
running ant clean junit from within HibernateExt/tools, Hibernate3 and
HibernateExt freshly checked-out from Branch_3_2, and hibernate-3.2
sibling dir created from Hibernate3 ant dist. I'm going to have to
move onto patching now, but any ideas welcome..
Mark
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
4:54 p.m.
On 30/10/06, Max Rydahl Andersen <max.andersen(a)jboss.com> wrote:
ok, submit a patch and i can run the testsuite for it.
I'll see if something stupid is broken in the ant junit testsuite.
running it from eclipse creates no unknown failures on my side.
Your hibernate.properties commit seems to have helped along with
deleting testdb. The tests which are failing now (aside from the
expected ones and the Oracle-specific ones) are:
* org.hibernate.tool.ant.HibernateToolTest.testJPAPUnit:
Error: Problems in creating a configuration for JPA. Have you
remembered to add hibernate EntityManager jars to the classpath ?
* org.hibernate.tool.hbm2x.Hbm2JavaEjb3ForJDK50Test.*:
Error: The database is already in use by another process:
org.hsqldb.persist.NIOLockFile@3cc45d0c[file =C:\Documents and
Settings\mark\My
Documents\projects\oss\HibernateExt\tools\toolstestoutput\testdb\hsqldb.lck,
exists=true, locked=false, valid=false, fl =null]:
java.lang.Exception: The process cannot access the file because
another process has locked a portion of the file : C:\Documents and
Settings\mark\My
Documents\projects\oss\HibernateExt\tools\toolstestoutput\testdb\hsqldb.lck
* org.hibernate.tool.hbm2x.XMLPrettyPrinterTest.testCloseTag:
Failure: expected:<.../...> but was:<...></basic...>
* org.hibernate.tool.stat.StatisticsBrowserTest.testBrowser:
Error: Could not instantiate cache implementation
Are these known issues?
Mark
6387
days inactive
6394
days old
12 comments
2 participants
participants (2)
-
Mark Hobson -
Max Rydahl Andersen