hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-122) Global "on/off" property for SessionFactory-level cache

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-122


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-122
    Summary: Global "on/off" property for SessionFactory-level cache
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Markus Menner

    Created: Fri, 6 Jun 2003 1:41 AM
    Updated: Fri, 6 Jun 2003 1:41 AM

Description:
It would be nice to have a property to switch on/off SessionFactory-level cache (for example to check performance improvements caching vs. no-caching).

At the moment you have to remove/add the jcs-cache tags in the mapping files.





---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-121) Schema export and MySQL AUTO_INCREMENT problem

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-121


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-121
    Summary: Schema export and MySQL AUTO_INCREMENT problem 
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Richard Mixon

    Created: Thu, 5 Jun 2003 10:03 PM
    Updated: Thu, 5 Jun 2003 10:03 PM
Environment: Windows XP, J2SDK 1.4.1, Ant 1.5.2, June 5th build of Hibernate Tools from CVS.

Description:
(Originally posted on forum)
By: rnmixon ( Richard Mixon )
Schema export and MySQL AUTO_INCREMENT probl  
2003-06-05 17:27
The schema export utility is omitting AUTO_INCREMENT from the actual id property, and erroneously including AUTO_INCREMENT on one part of a two part unique key. I am using "native" id generation. Both parts of the key are many-to-one mappings. I have another table that is mapped the same way and have no problems with it.

Is this a bug in schema export? My mapping and the generated DDL are below for the good and bad examples.

Thanks much in advance - Richard (sorry for the verbose listing)

DDL - START (with wrong AUTO_INCREMENT spec)
create table PoAggrMeasurement (
id BIGINT not null,
version INTEGER not null,
aggregation BIGINT NOT NULL AUTO_INCREMENT,
classMeasurement BIGINT not null,
status BIGINT,
owner BIGINT,
createdBy DATETIME not null,
createdFromIP DATETIME not null,
createdOn BIGINT not null,
updatedBy BIGINT not null,
updatedFromIP VARCHAR(15) not null,
updatedOn VARCHAR(255) not null,
primary key (aggregation, classMeasurement),
unique (aggregation, classMeasurement)
);
DDL - END
DDL - START (with wrong AUTO_INCREMENT spec)
create table PoEnrollment (correct AUTO_INCREMENT)
id BIGINT NOT NULL AUTO_INCREMENT,
version INTEGER not null,
classOwner BIGINT not null,
studentOwner BIGINT not null,
status BIGINT,
owner BIGINT,
createdBy DATETIME not null,
createdFromIP DATETIME not null,
createdOn BIGINT not null,
updatedBy BIGINT not null,
updatedFromIP VARCHAR(15) not null,
updatedOn VARCHAR(255) not null,
primary key (id),
unique (classOwner, studentOwner)
);
DDL - END

MAPPING - START (causes wrong AUTO_INCREMENT spec)
<hibernate-mapping>
<class
name="com.ltoj.persistence.base.PoAggrMeasurement"
table="PoAggrMeasurement"
dynamic-update="false"
>

<id
name="id"
column="id"
type="long"
unsaved-value="null"
>
<generator class="native">
</generator>
</id>

<version
name="version"
type="int"
column="version"
/>

<many-to-one
name="aggregation"
class="com.ltoj.persistence.base.PoAggregation"
cascade="none"
outer-join="auto"
update="true"
insert="true"
>
<column
name="aggregation"
unique-key="userkey"
not-null="true"
/>
</many-to-one>

<many-to-one
name="classMeasurement"
class="com.ltoj.persistence.base.PoClassMeasurement"
cascade="none"
outer-join="auto"
update="true"
insert="true"
>
<column
name="classMeasurement"
unique-key="userkey"
not-null="true"
/>
</many-to-one>

<many-to-one
name="status"
class="com.ltoj.persistence.base.PoStatus"
cascade="none"
outer-join="auto"
update="true"
insert="true"
column="status"
not-null="false"
unique="false"
/>

<many-to-one
name="owner"
class="com.ltoj.persistence.base.PoAssociate"
cascade="none"
outer-join="auto"
update="true"
insert="true"
column="owner"
not-null="false"
unique="false"
/>

<property
name="auditInfo"
type="com.ltoj.persistence.base.PoAuditInfoType"
update="true"
insert="true"
>
<column
name="createdBy"
length="8"
not-null="true"
/>
<column
name="createdFromIP"
length="15"
not-null="true"
/>
<column
name="createdOn"
not-null="true"
/>
<column
name="updatedBy"
length="8"
not-null="true"
/>
<column
name="updatedFromIP"
length="15"
not-null="true"
/>
<column
name="updatedOn"
not-null="true"
/>
</property>

<!--
To add non XDoclet property mappings, create a file named
hibernate-properties-PoAggrMeasurement.xml
containing the additional properties and place it in your merge dir.
-->

</class>

<query name="PoAggrMeasurement.all"><![CDATA[
from am in class com.ltoj.persistence.base.PoAggMeasurement
]]></query>

</hibernate-mapping>
MAPPING - END
MAPPING - START (correct AUTO_INCREMENT spec)
<hibernate-mapping>
<class
name="com.ltoj.persistence.base.PoEnrollment"
table="PoEnrollment"
dynamic-update="false"
>

<id
name="id"
column="id"
type="long"
unsaved-value="null"
>
<generator class="native">
</generator>
</id>

<version
name="version"
type="int"
column="version"
/>

<many-to-one
name="classOwner"
class="com.ltoj.persistence.base.PoClass"
cascade="none"
outer-join="auto"
update="true"
insert="true"
>
<column
name="classOwner"
unique-key="userkey"
not-null="true"
/>
</many-to-one>

<many-to-one
name="studentOwner"
class="com.ltoj.persistence.base.PoStudent"
cascade="none"
outer-join="auto"
update="true"
insert="true"
>
<column
name="studentOwner"
unique-key="userkey"
not-null="true"
/>
</many-to-one>

<many-to-one
name="status"
class="com.ltoj.persistence.base.PoStatus"
cascade="none"
outer-join="auto"
update="true"
insert="true"
column="status"
not-null="false"
unique="false"
/>

<many-to-one
name="owner"
class="com.ltoj.persistence.base.PoAssociate"
cascade="none"
outer-join="auto"
update="true"
insert="true"
column="owner"
not-null="false"
unique="false"
/>

<property
name="auditInfo"
type="com.ltoj.persistence.base.PoAuditInfoType"
update="true"
insert="true"
>
<column
name="createdBy"
length="8"
not-null="true"
/>
<column
name="createdFromIP"
length="15"
not-null="true"
/>
<column
name="createdOn"
not-null="true"
/>
<column
name="updatedBy"
length="8"
not-null="true"
/>
<column
name="updatedFromIP"
length="15"
not-null="true"
/>
<column
name="updatedOn"
not-null="true"
/>
</property>

<!--
To add non XDoclet property mappings, create a file named
hibernate-properties-PoEnrollment.xml
containing the additional properties and place it in your merge dir.
-->

</class>

</hibernate-mapping>
MAPPING - END 


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-120) Cannot set breakpoints in debugger.

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Thu, 5 Jun 2003 9:15 PM

Correct, you just disable the reflection optimizer.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-120


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-120
    Summary: Cannot set breakpoints in debugger.
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: Keith Ackley

    Created: Thu, 5 Jun 2003 8:20 AM
    Updated: Thu, 5 Jun 2003 9:15 PM
Environment: Windows XP, JDK 1.4.1_02, Eclipse 2.1

Description:
I have upgraded my sample project to Hibernate 2. The application works fine but I can no longer set breakpoints in my classes that are mapped to the database. I get the following error dialog in Eclipse:

"Attempting to install a breakpoint in the type ex1.Name$$ProxiedByCGLIB$$0 that has no line number attributes. The breakpoint cannot be installed. Class files must be generated with the line number attributes.

Reason:
 Absent Line Number Information"

It appears that the proxy class generated for my class ex1.Name does not contain the debugging information generated by the "-g" option. I do not get the error for instances that I create only instances created by Hibernate.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-120) Cannot set breakpoints in debugger.

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Marcelo Alves
    Created: Thu, 5 Jun 2003 4:04 PM
       Body:
Hmmm, how about disable CGILIB to debug ?

In hibernate.properties :

  hibernate.cglib.use_reflection_optimizer = false


---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-120


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-120
    Summary: Cannot set breakpoints in debugger.
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Keith Ackley

    Created: Thu, 5 Jun 2003 8:20 AM
    Updated: Thu, 5 Jun 2003 8:20 AM
Environment: Windows XP, JDK 1.4.1_02, Eclipse 2.1

Description:
I have upgraded my sample project to Hibernate 2. The application works fine but I can no longer set breakpoints in my classes that are mapped to the database. I get the following error dialog in Eclipse:

"Attempting to install a breakpoint in the type ex1.Name$$ProxiedByCGLIB$$0 that has no line number attributes. The breakpoint cannot be installed. Class files must be generated with the line number attributes.

Reason:
 Absent Line Number Information"

It appears that the proxy class generated for my class ex1.Name does not contain the debugging information generated by the "-g" option. I do not get the error for instances that I create only instances created by Hibernate.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-120) Cannot set breakpoints in debugger.

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-120


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-120
    Summary: Cannot set breakpoints in debugger.
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Keith Ackley

    Created: Thu, 5 Jun 2003 8:20 AM
    Updated: Thu, 5 Jun 2003 8:20 AM
Environment: Windows XP, JDK 1.4.1_02, Eclipse 2.1

Description:
I have upgraded my sample project to Hibernate 2. The application works fine but I can no longer set breakpoints in my classes that are mapped to the database. I get the following error dialog in Eclipse:

"Attempting to install a breakpoint in the type ex1.Name$$ProxiedByCGLIB$$0 that has no line number attributes. The breakpoint cannot be installed. Class files must be generated with the line number attributes.

Reason:
 Absent Line Number Information"

It appears that the proxy class generated for my class ex1.Name does not contain the debugging information generated by the "-g" option. I do not get the error for instances that I create only instances created by Hibernate.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-119) Possible bug with versioning and collections

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Wed, 4 Jun 2003 1:25 AM

Actually, this is all okay, it is a different check that finds the dirty collection reference.

Tale a look at PersistentCollectionType.isDirty()

I tested that version numbers are correctly incremented.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-119


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-119
    Summary: Possible bug with versioning and collections
       Type: Bug

     Status: Closed
   Priority: Critical
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             core

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Mon, 2 Jun 2003 7:08 PM
    Updated: Wed, 4 Jun 2003 1:25 AM

Description:
I ran into this problem when writing an audit interceptor based on our earlier discussions. Basically searchForDirtyCollections does not seem to return true when a collection reference has changed (i.e. the user set the collection to be a different collection from the one loaded). Looking at the code, searchForDirtyCollections just checks to see if the entry is dirty consequently when a collection is newly wrapped it does not appear dirty to that method. 

The upshot is that if the object is versioned and a collection reference is changed it will not update the version number. This is not major problem because users can always use addAll and clear to avoid changing the reference. 

Just thought you might like to know. 

Regards, 

Ali Ibrahim 
Vecna Technologies 

from:

https://sourceforge.net/forum/forum.php?thread_id=877654&forum_id=128638



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-118) Support for Java expressions in HQL

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Mon, 2 Jun 2003 6:58 PM

Java constants in HQL have been supported for a long time!

(And are even mentioned in the documentation.)

You may need to use the fully qualified class name.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-118


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-118
    Summary: Support for Java expressions in HQL
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core

   Assignee: Gavin King
   Reporter: Leonardo Quijano

    Created: Mon, 2 Jun 2003 10:47 AM
    Updated: Mon, 2 Jun 2003 6:58 PM

Description:
I don't know if this has been already posted, but here I go. 
It'd be useful to have something like this in HQL:

FROM foo in class Foo
WHERE (foo.someProperty != Foo.A_CONSTANT)

instead of 

FROM foo in class Foo
WHERE (foo.someProperty != 354627)

Of course, it could be orthogonal, kind of:

FROM foo in class Foo
WHERE (foo.someProperty != foo.getComplexValue())

Or it could be just constants.
Is this feasible?

Leonardo


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-93) Ability to specify fields to insert (dynamic-insert)

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Mon, 2 Jun 2003 7:17 PM

I have added a dynamic-insert attribute to all class mappings that removes null fields from the INSERT.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-93


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-93
    Summary: Ability to specify fields to insert (dynamic-insert)
       Type: New Feature

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0 final
   Versions:
             2.1
             2.0 final

   Assignee: Gavin King
   Reporter: Chris Winters

    Created: Wed, 21 May 2003 8:52 AM
    Updated: Mon, 2 Jun 2003 7:17 PM
Environment: n/a

Description:
It would be useful to specify the fields to use for an INSERT, similar 'dynamic-update' and the Interceptor method (findDirty) for doing this with updates, although unlike 'dynamic-update' I don't think there's a way for Hibernate to do this itself. The Interceptor would probably be the only means for specifying the fields.

Here's an application: our database has a good deal of application logic in defaults, check constraints and triggers. We'd like to be able to look at an object before it's INSERTed, check a list of fields (which the object can tell us -- it doesn't need to be in the mapping) to see if they're null and if so DO NOT include them in the INSERT. The database will then set the fields properly and the app will be happy.

I haven't looked into the code to see how this would affect object synchronization -- we'll need to refetch after the INSERT to ensure the object and database are in the same state, and I don't know if this is already done.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-119) Possible bug with versioning and collections

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-119


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-119
    Summary: Possible bug with versioning and collections
       Type: Bug

     Status: Assigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core

   Assignee: Gavin King
   Reporter: Gavin King

    Created: Mon, 2 Jun 2003 7:08 PM
    Updated: Mon, 2 Jun 2003 7:08 PM

Description:
I ran into this problem when writing an audit interceptor based on our earlier discussions. Basically searchForDirtyCollections does not seem to return true when a collection reference has changed (i.e. the user set the collection to be a different collection from the one loaded). Looking at the code, searchForDirtyCollections just checks to see if the entry is dirty consequently when a collection is newly wrapped it does not appear dirty to that method. 

The upshot is that if the object is versioned and a collection reference is changed it will not update the version number. This is not major problem because users can always use addAll and clear to avoid changing the reference. 

Just thought you might like to know. 

Regards, 

Ali Ibrahim 
Vecna Technologies 

from:

https://sourceforge.net/forum/forum.php?thread_id=877654&forum_id=128638



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-118) Support for Java expressions in HQL

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Leonardo Quijano
    Created: Mon, 2 Jun 2003 7:07 PM
       Body:
Didn't try the fully qualified class name thing before...maybe I wasn't in my best moment, hehe. ;)

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-118


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-118
    Summary: Support for Java expressions in HQL
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core

   Assignee: Gavin King
   Reporter: Leonardo Quijano

    Created: Mon, 2 Jun 2003 10:47 AM
    Updated: Mon, 2 Jun 2003 6:58 PM

Description:
I don't know if this has been already posted, but here I go. 
It'd be useful to have something like this in HQL:

FROM foo in class Foo
WHERE (foo.someProperty != Foo.A_CONSTANT)

instead of 

FROM foo in class Foo
WHERE (foo.someProperty != 354627)

Of course, it could be orthogonal, kind of:

FROM foo in class Foo
WHERE (foo.someProperty != foo.getComplexValue())

Or it could be just constants.
Is this feasible?

Leonardo


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-116) JOnASTransactionManagerLookup

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Van caneghem
    Created: Mon, 2 Jun 2003 12:18 PM
       Body:
Nicolas VAN CANEGHEM

I have another pb with jboss. When I start Hibernate with jmx and JBoss, Hibernate spend a lot of time after loading classes and mapping. I don't know why neither where.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-116


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-116
    Summary: JOnASTransactionManagerLookup
       Type: Patch

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0 final
   Versions:
             2.0 final

   Assignee: Gavin King
   Reporter: Van caneghem

    Created: Fri, 30 May 2003 8:15 AM
    Updated: Sat, 31 May 2003 3:11 AM

Description:
Could you add this class?

====>
package net.sf.hibernate.transaction;

import java.util.Properties;

import javax.transaction.TransactionManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import net.sf.hibernate.HibernateException;

/**
 * TransactionManager lookup strategy for JOTM
 * @author Low Heng Sin
 */
public class JOnASTransactionManagerLookup implements TransactionManagerLookup {

	private static final Log log = LogFactory.getLog(JOnASTransactionManagerLookup.class);

	/**
	 * @see net.sf.hibernate.transaction.TransactionManagerLookup#getTransactionManager(Properties)
	 */
	public TransactionManager getTransactionManager(Properties props) throws HibernateException {
		try {
			Class clazz = Class.forName("org.objectweb.jonas_tm.Current");
			return (TransactionManager) clazz.getMethod("getTransactionManager", null).invoke(null, null);
		}
		catch (Exception e) {
			throw new HibernateException( "Could not obtain JOnAS transaction manager instance", e );
		}
	}

	public String getUserTransactionName() {
		return "java:comp/UserTransaction";
	}

}



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-118) Support for Java expressions in HQL

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-118


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-118
    Summary: Support for Java expressions in HQL
       Type: Improvement

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Leonardo Quijano

    Created: Mon, 2 Jun 2003 10:47 AM
    Updated: Mon, 2 Jun 2003 10:47 AM

Description:
I don't know if this has been already posted, but here I go. 
It'd be useful to have something like this in HQL:

FROM foo in class Foo
WHERE (foo.someProperty != Foo.A_CONSTANT)

instead of 

FROM foo in class Foo
WHERE (foo.someProperty != 354627)

Of course, it could be orthogonal, kind of:

FROM foo in class Foo
WHERE (foo.someProperty != foo.getComplexValue())

Or it could be just constants.
Is this feasible?

Leonardo


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-117) Support for more SQL functions in SELECT

[<leg...@at...>]

The following comment has been added to this issue:

     Author: David Channon
    Created: Mon, 2 Jun 2003 7:29 AM
       Body:
I accept the issue. I can see it has a high priority. See how we go - I cannot say that it will be done for v2.0 release.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-117


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-117
    Summary: Support for more SQL functions in SELECT
       Type: Improvement

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: David Channon
   Reporter: Gavin King

    Created: Sun, 1 Jun 2003 7:58 PM
    Updated: Sun, 1 Jun 2003 7:59 PM

Description:
Currently, Hibernate supports exactly five (hardcoded) SQL functions in the HQL SELECT clause. They are the aggregate functions COUNT(), AVG(), SUM(), MIN(), MAX()

A number of users would like to be able to specify an arbitrary SQL function in the SELECT. The problem here is that we need to know the return type of the function to be able to read it from the result set.

I propose that the Dialect classes include a collection of mappings from function names to Hibernate types (eg. CURRENT_DATE -> Hibernate.DATE). That way, we can support the most commonly used SQL functions, and others can be easily added by users providing extensions to the Dialect.


So, we would like to allow:

SELECT CURRENT_DATE(), TRUNC(foo.amount), ......


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-117) Support for more SQL functions in SELECT

[<leg...@at...>]

Message:

   The following issue has been re-assigned.

   Assignee: David Channon (mailto:dch...@bi...)
   Assigner: Gavin King (mailto:ga...@in...)
       Date: Sun, 1 Jun 2003 7:59 PM
    Comment:
Are you interested in this issue, David?

The work required would be:

* additions to Dialect and subclasses
* changes to SelectParser
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-117


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-117
    Summary: Support for more SQL functions in SELECT
       Type: Improvement

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: David Channon
   Reporter: Gavin King

    Created: Sun, 1 Jun 2003 7:58 PM
    Updated: Sun, 1 Jun 2003 7:59 PM

Description:
Currently, Hibernate supports exactly five (hardcoded) SQL functions in the HQL SELECT clause. They are the aggregate functions COUNT(), AVG(), SUM(), MIN(), MAX()

A number of users would like to be able to specify an arbitrary SQL function in the SELECT. The problem here is that we need to know the return type of the function to be able to read it from the result set.

I propose that the Dialect classes include a collection of mappings from function names to Hibernate types (eg. CURRENT_DATE -> Hibernate.DATE). That way, we can support the most commonly used SQL functions, and others can be easily added by users providing extensions to the Dialect.


So, we would like to allow:

SELECT CURRENT_DATE(), TRUNC(foo.amount), ......


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-117) Support for more SQL functions in SELECT

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-117


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-117
    Summary: Support for more SQL functions in SELECT
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Gavin King

    Created: Sun, 1 Jun 2003 7:58 PM
    Updated: Sun, 1 Jun 2003 7:58 PM

Description:
Currently, Hibernate supports exactly five (hardcoded) SQL functions in the HQL SELECT clause. They are the aggregate functions COUNT(), AVG(), SUM(), MIN(), MAX()

A number of users would like to be able to specify an arbitrary SQL function in the SELECT. The problem here is that we need to know the return type of the function to be able to read it from the result set.

I propose that the Dialect classes include a collection of mappings from function names to Hibernate types (eg. CURRENT_DATE -> Hibernate.DATE). That way, we can support the most commonly used SQL functions, and others can be easily added by users providing extensions to the Dialect.


So, we would like to allow:

SELECT CURRENT_DATE(), TRUNC(foo.amount), ......


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-76) Add support for HypersonicSQL IDENTITY type

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sun, 1 Jun 2003 7:49 PM

Excellent.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-76


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-76
    Summary: Add support for HypersonicSQL IDENTITY type
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: WON'T FIX

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: Mathias Bogaert

    Created: Wed, 14 May 2003 10:11 AM
    Updated: Sun, 1 Jun 2003 7:49 PM
Environment: 2.0 RC6

Description:
From the Hibernate manual:

Each table can contain one auto-increment column, known as the IDENTITY column. An IDENTITY column is always treated as the primary key for the table. Support has been added for CREATE TABLE <tablename>(<colname> IDENTITY, ...) to allow IDENTITY used on it's own as a type. This is translated internally to (<colname> INTEGER IDENTITY, ...) which is the default syntax.

Currently, I cannot use Hibernate2 and Hypersonic with the Long as identity column. This is a blocked bug for me.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-107) JdbcDatabaseInfo improvement

[<leg...@at...>]

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Sun, 1 Jun 2003 7:47 PM
    Comment:
Ah. Thanks. I changed this to a patch, because I didn't notice it as one initially.
    Changes:
          type changed from Improvement to Patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-107&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-107


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-107
    Summary: JdbcDatabaseInfo improvement
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Teodor Danciu

    Created: Mon, 26 May 2003 3:51 AM
    Updated: Sun, 1 Jun 2003 7:47 PM

Description:
The JdbcDatabaseInfo class tries to load all the
database metadata information when it is instantiated.
We found this inconvenient since in our Oracle database
we already have thousands of tables and retrieving the
whole metadata is time-consuming and inefficient in
case of simple updates (one or two tables).
We made some modifications in the JdbcDatabaseInfo
class so that the metadata information for each table be
loaded only when needed. Once the metadata for a table
loaded, it is kept in memory for later use.



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-111) fields defined as formulas...

[<leg...@at...>]

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Sun, 1 Jun 2003 7:44 PM
    Comment:
This is not a bug. I have renamed it a feature request. "computed" columns are not currently supported.
    Changes:
          type changed from Bug to New Feature
          summary changed from Invalid sql alias computation for fields with formulas... to fields defined as formulas...
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-111&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-111


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-111
    Summary: fields defined as formulas...
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Fabio Parise

    Created: Thu, 29 May 2003 4:58 AM
    Updated: Sun, 1 Jun 2003 7:44 PM

Description:
Trying to define a computed field (i.e. 'status1000' as the result of the following computation: status+1000; where 'status' is a table column) in this way:

<property column="STATUS+1000" length="10" name="status1000" not-null="true" type="java.lang.Long" update="false" insert="false"/>

if the first 7 chars of the attribute 'column' contains some non-valid chars for sql aliases, the produced SELECT statement will fail.

In the example the alias for the computed field is 'STATUS+16_', which is not a valid sql alias.

SELECT WkfPr0_.pkid as pkid, ..., WkfPr0_.STATUS+1000 as STATUS+16_ FROM WKF_PROCESS_CLASS WkfPr0_ WHERE WkfPr0_.pkid=?

if the field involved in the formula has a longer name i.e. MYSTATUS --> formula=MYSTATUS+1000, the computed alias is MYSTATU16_, which is a valid alias.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-115) Save after refresh object with unloaded lazy collections

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 31 May 2003 3:06 AM

Thanks - 1 line fix and a test in CVS.

I *thought* I had already taken care of this, but I had only done so for evict(), not for refresh().
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-115


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-115
    Summary: Save after refresh object with unloaded lazy collections
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0 final

   Assignee: Gavin King
   Reporter: Ivlev Dmitry

    Created: Thu, 29 May 2003 11:56 PM
    Updated: Sat, 31 May 2003 3:06 AM

Description:
Save after refresh object with unloaded lazy collections delete unloaded objects! Step by step:
- I have class with childs (lazy collection)
- I load class (childs are not loaded)
- I refresh object (object refreshed but unloaded lazy collection becams empty collection)
- I modify object fileds and don't touch childs
- I save object (object is saved and all childs are DELETED!!!)



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-116) JOnASTransactionManagerLookup

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 31 May 2003 3:11 AM

What is your name? (To add to changelog and @author tag)
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-116


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-116
    Summary: JOnASTransactionManagerLookup
       Type: Patch

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.0 final
   Versions:
             2.0 final

   Assignee: Gavin King
   Reporter: Van caneghem

    Created: Fri, 30 May 2003 8:15 AM
    Updated: Sat, 31 May 2003 3:11 AM

Description:
Could you add this class?

====>
package net.sf.hibernate.transaction;

import java.util.Properties;

import javax.transaction.TransactionManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import net.sf.hibernate.HibernateException;

/**
 * TransactionManager lookup strategy for JOTM
 * @author Low Heng Sin
 */
public class JOnASTransactionManagerLookup implements TransactionManagerLookup {

	private static final Log log = LogFactory.getLog(JOnASTransactionManagerLookup.class);

	/**
	 * @see net.sf.hibernate.transaction.TransactionManagerLookup#getTransactionManager(Properties)
	 */
	public TransactionManager getTransactionManager(Properties props) throws HibernateException {
		try {
			Class clazz = Class.forName("org.objectweb.jonas_tm.Current");
			return (TransactionManager) clazz.getMethod("getTransactionManager", null).invoke(null, null);
		}
		catch (Exception e) {
			throw new HibernateException( "Could not obtain JOnAS transaction manager instance", e );
		}
	}

	public String getUserTransactionName() {
		return "java:comp/UserTransaction";
	}

}



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-110) Provide a way to use hibernate.cfg.xml without JNDI

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Axel Fontaine
    Created: Sat, 31 May 2003 1:46 AM
       Body:
Ok, removed the name attribute from <session-factory> did the trick !
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-110


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-110
    Summary: Provide a way to use hibernate.cfg.xml without JNDI
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: Axel Fontaine

    Created: Thu, 29 May 2003 4:42 AM
    Updated: Thu, 29 May 2003 8:55 PM

Description:
Currently hibernate.cfg.xml can not be used as a drop-in replacement for hibernate.properties

This is really a shame!
There is really no reason why this shouldn't be the case.

And it is much nicer than all the config.addClass(XYZ) statements, as it moves this out of the code.

So, why not factor out the JNDI specific part in its own subclass?


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-104) Unable to locate dialect when only specified in properties file

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Axel Fontaine
    Created: Sat, 31 May 2003 1:31 AM
       Body:
Ok, thank you !
But just to let you know: I copy-pasted this out of the Hibernate2 documentation, so maybe it should be updated.

Thx,
Axel
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-104


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-104
    Summary: Unable to locate dialect when only specified in properties file
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Axel Fontaine

    Created: Sun, 25 May 2003 4:34 PM
    Updated: Sun, 25 May 2003 4:34 PM
Environment: WinXP SP1, Eclipse 2.1, Hibernate 2.0 beta 6, McKoi 1.0.1

Description:
When using the following property file:

hibernate.dialect = net.sf.hibernate.dialect.McKoiDialect
hibernate.connection.driver_class = com.mckoi.JDBCDriver
hibernate.connection.url = jdbc:mckoi://localhost/
hibernate.connection.username = dbadmin
hibernate.connection.password = dbpass

hibernate complains that it can't find the dialect net.sf.hibernate.dialect.McKoiDialect


Adding this to the code makes it work:
Configuration config = new Configuration();
config.setProperty("hibernate.dialect", MckoiDialect.class.getName());


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-110) Provide a way to use hibernate.cfg.xml without JNDI

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Axel Fontaine
    Created: Sat, 31 May 2003 1:27 AM
       Body:
Yes, but it still logs a stack trace to the console !
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-110


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-110
    Summary: Provide a way to use hibernate.cfg.xml without JNDI
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: Axel Fontaine

    Created: Thu, 29 May 2003 4:42 AM
    Updated: Thu, 29 May 2003 8:55 PM

Description:
Currently hibernate.cfg.xml can not be used as a drop-in replacement for hibernate.properties

This is really a shame!
There is really no reason why this shouldn't be the case.

And it is much nicer than all the config.addClass(XYZ) statements, as it moves this out of the code.

So, why not factor out the JNDI specific part in its own subclass?


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-116) JOnASTransactionManagerLookup

[<leg...@at...>]

Message:

   The following issue has been re-assigned.

   Assignee: Gavin King (mailto:ga...@in...)
   Assigner: Gavin King (mailto:ga...@in...)
       Date: Fri, 30 May 2003 10:27 AM
    Comment:
sure ;)
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-116


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-116
    Summary: JOnASTransactionManagerLookup
       Type: Patch

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0 final

   Assignee: Gavin King
   Reporter: Van caneghem

    Created: Fri, 30 May 2003 8:15 AM
    Updated: Fri, 30 May 2003 10:27 AM

Description:
Could you add this class?

====>
package net.sf.hibernate.transaction;

import java.util.Properties;

import javax.transaction.TransactionManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import net.sf.hibernate.HibernateException;

/**
 * TransactionManager lookup strategy for JOTM
 * @author Low Heng Sin
 */
public class JOnASTransactionManagerLookup implements TransactionManagerLookup {

	private static final Log log = LogFactory.getLog(JOnASTransactionManagerLookup.class);

	/**
	 * @see net.sf.hibernate.transaction.TransactionManagerLookup#getTransactionManager(Properties)
	 */
	public TransactionManager getTransactionManager(Properties props) throws HibernateException {
		try {
			Class clazz = Class.forName("org.objectweb.jonas_tm.Current");
			return (TransactionManager) clazz.getMethod("getTransactionManager", null).invoke(null, null);
		}
		catch (Exception e) {
			throw new HibernateException( "Could not obtain JOnAS transaction manager instance", e );
		}
	}

	public String getUserTransactionName() {
		return "java:comp/UserTransaction";
	}

}



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-116) JOnASTransactionManagerLookup

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-116


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-116
    Summary: JOnASTransactionManagerLookup
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0 final

   Assignee: 
   Reporter: Van caneghem

    Created: Fri, 30 May 2003 8:15 AM
    Updated: Fri, 30 May 2003 8:15 AM

Description:
Could you add this class?

====>
package net.sf.hibernate.transaction;

import java.util.Properties;

import javax.transaction.TransactionManager;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import net.sf.hibernate.HibernateException;

/**
 * TransactionManager lookup strategy for JOTM
 * @author Low Heng Sin
 */
public class JOnASTransactionManagerLookup implements TransactionManagerLookup {

	private static final Log log = LogFactory.getLog(JOnASTransactionManagerLookup.class);

	/**
	 * @see net.sf.hibernate.transaction.TransactionManagerLookup#getTransactionManager(Properties)
	 */
	public TransactionManager getTransactionManager(Properties props) throws HibernateException {
		try {
			Class clazz = Class.forName("org.objectweb.jonas_tm.Current");
			return (TransactionManager) clazz.getMethod("getTransactionManager", null).invoke(null, null);
		}
		catch (Exception e) {
			throw new HibernateException( "Could not obtain JOnAS transaction manager instance", e );
		}
	}

	public String getUserTransactionName() {
		return "java:comp/UserTransaction";
	}

}



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira