hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-613) Problem with null composite-elements

[<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-613


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-613
    Summary: Problem with null composite-elements
       Type: Bug

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 final

   Assignee: 
   Reporter: William Drai

    Created: Fri, 9 Jan 2004 9:52 AM
    Updated: Fri, 9 Jan 2004 9:52 AM
Environment: Hibernate 2.1, MySQL 4.1.1

Description:
I have a mapping like this :

<class name="Foo">
  <id  ../>

  <map name="elements" table="ELEMENTS">
    <key column="FOO_ID" />
    <index column="ELEMENT_ID" />
    <composite-element class="Element">
      <property name="prop1" />
      <property name="prop2" />
    </composite-element>
  </map>
</class>

If I store an instance of Foo with one element in the map where prop1 and prop2 are null, all is ok in the database :

ELEMENT_ID | PROP1 | PROP2
 "element" |  null |  null

When I load this instance of Foo later, I get the "elements" map, but the entry has a key "element" and a null value, instead having a new empty Element instance.


William




---------------------------------------------------------------------
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/secure/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-541) DDL Enhance for drop column and schema usage fix

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

The following comment has been added to this issue:

     Author: Adrien
    Created: Fri, 9 Jan 2004 9:38 AM
       Body:

This bug fix the same problem as the one I submited :

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

Since this patch seems better than the quick one I proposed, you could note my old bug report as duplicate.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-541
    Summary: DDL Enhance for drop column and schema usage fix
       Type: Patch

     Status: Open
   Priority: Critical

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 5

   Assignee: Gavin King
   Reporter: Jan Blok

    Created: Wed, 10 Dec 2003 4:43 PM
    Updated: Fri, 9 Jan 2004 9:38 AM
Environment: Hibernate-2.1, all dbs 

Description:
[enh]-add Table.sqlAlterDropColumn method and enhance all dialect to support this new feature
[bug]-tablemetadata.initColumns does not use local schema field but
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-534
[bug]-TableMetadata does not take the schema in the hash key for entries in tables map (is little related to previous)
[enh]-add method to Table which constructs/returns schema.tablename
[enh]-overload Table constructor with one to supply all required arguments at once (like schema and table name)
[enh]-Table.sqlAlterStrings rename to  sqlAlterAddColumnStrings



---------------------------------------------------------------------
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/secure/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-612) SchemaExport: DB2 CLOB fails

[<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-612


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-612
    Summary: SchemaExport: DB2 CLOB fails
       Type: Bug

     Status: Unassigned
   Priority: Blocker

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1

   Assignee: 
   Reporter: Jan Riis

    Created: Fri, 9 Jan 2004 8:02 AM
    Updated: Fri, 9 Jan 2004 8:02 AM
Environment: DB2 vers. 7.2 on Win XP

Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.

    <class name="dk.acure.journal.model.Skema">
...
        <property name="xml" type="string" length="256000">
          <column name="xml" sql-type="CLOB"/>
        </property>
    </class>

generates:

create table Skema (
...
  xml CLOB,
);

But should be:
  xml CLOB (256000)

Length is mandatory in DB2 (as far as I can see)



---------------------------------------------------------------------
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/secure/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-474) adding Criteria.count() method

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

The following comment has been added to this issue:

     Author: Sebastien Cesbron
    Created: Fri, 9 Jan 2004 2:17 AM
       Body:
As it was mentionned on the issue 143, the count method should also be added to the query interface
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-474
    Summary: adding Criteria.count() method
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.1
             2.1 rc1

   Assignee: 
   Reporter: Chris Nelson

    Created: Sun, 16 Nov 2003 12:53 PM
    Updated: Fri, 9 Jan 2004 2:17 AM

Description:
Adds a count() method to the Criteria class that does a modified query to return the count without returning entire query.


---------------------------------------------------------------------
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/secure/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-611) Session.load() retrieves different Object instances when String keys are used

[<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-611


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-611
    Summary: Session.load() retrieves different Object instances when String keys are used
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2

   Assignee: 
   Reporter: Scott Russell

    Created: Thu, 8 Jan 2004 11:59 PM
    Updated: Thu, 8 Jan 2004 11:59 PM
Environment: HIbernate 2.1, Informix database

Description:
When using Session.load() to load an Object from the database that has a (whitespace-trimmed) string key, different Objects are returned from Parent-Child relationships, which load associated Objects using the full whitespace-padded string key.

I noticed this when loading an Child object using Session.load(), and then loading the Parent using Session.load(), and comparing the loaded child with the child in the Parent's collection of children. Although both the loaded Child and the collection-element child refer to the same database record, they exist in the session as different Objects because the former is referenced by its trimmed key, whereas the latter appears to be referenced by its full length key (ie. as loaded from the database column, padded with empty spaces). This causes countless problems, as one naturally expects that the same object would be used within the same session.

eg. 

Child c1 = (Child) Session.load(Child.class, "A");
c1.setValue("a_value");

Parent p = (Parent) Session.load(Parent.class, "B");

Child c2 = p.getChild("A");  // returns null
Child c3 = p.getChild("A       ");  // returns expected child

c3.getValue();   // Returns original loaded value, not "a_value",
                 // as one would expect




---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 8 Jan 2004 9:09 PM
       Body:
>>>
So how can I re-associate the object with the present session? Doing something like:

session.lock(objectWithCollection, LockMode.NONE); 
<<<

That works.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 9:09 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Travis Savo
    Created: Thu, 8 Jan 2004 8:17 PM
       Body:
Agreed. This only seems to happen when an object has been serialized (to a remote JCS cache for instance... so the session in question may be on an entirely different box).

So how can I re-associate the object with the present session? Doing something like:

session.lock(objectWithCollection, LockMode.NONE);

dosn't seem to fix the problem, because it's not the object we want associated with the session... it's the Set on the object that we want.

session.lock(objectWithCollection.getCollection(), LockMode.NONE);

dosn't work either: It says there's no persister for a net.sf.hibernate.collection.Set.

Suggestions here? I'll jump through flaming hoops to reassociate a session with a collection if I have to, just point me in the right direction if you could.

Thanks so much.

-Travis Savo <ts...@if...>
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 8:17 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 8 Jan 2004 8:07 PM
       Body:
The "no session" case usually occurs if the collection was serialized.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 8:07 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Travis Savo
    Created: Thu, 8 Jan 2004 8:00 PM
       Body:
When the session is closed, I get:
net.sf.hibernate.HibernateException: Session is currently disconnected

Which is quite different than 'No Session', is it not?
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 8:00 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 8 Jan 2004 6:46 PM
       Body:
I would say this has nothing to do with the original bug, and is probably just due to you closing the session before accessing the collection.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 6:46 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Travis Savo
    Created: Thu, 8 Jan 2004 6:33 PM
       Body:
My bad, it's a one-to-many relationship. Here's the relevant mapping (with sensitive information changed):

<set name="releases" table="DB.DBTableRemoved" lazy="true"> 
				<jcs-cache usage="read-only"/>
				<key column="N_IFILM_ID"/>
				<one-to-many class="com.ifilm.persistent.Release"/>
			</set>

Is there anything more I can provide to help troubleshoot this?

-Travis Savo <ts...@if...>
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 6:33 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Travis Savo
    Created: Thu, 8 Jan 2004 6:26 PM
       Body:
I'm running 2.1.1 (after having upgraded from 2.1 beta and going through the steps of replacing old jars with new ones), and am still getting this error on a regular basis (I was getting it more on 2.1 beta, so something must have changed because the frequency has gone down). The situtations surrounding it appear to be identical (key many-to-one, JCS cache, resin 2.1.6)

Where might I look to see why this is happening? I'm comfortable with running Hibernate from a debug session and putting a break point/watch on things.

Included is the relevant portion of the stack trace.

16:02:29,860 ERROR LazyInitializationException:25 - Failed to lazily initialize a collection - no Session
net.sf.hibernate.LazyInitializationException: Failed to lazily initialize a collection - no Session
        at net.sf.hibernate.collection.PersistentCollection.initialize(PersistentCollection.java:213)
        at net.sf.hibernate.collection.PersistentCollection.read(PersistentCollection.java:69)
        at net.sf.hibernate.collection.Set.iterator(Set.java:131)
        at com.caucho.jstl.el.ForEachTag.getIterator(ForEachTag.java:315)
        at com.caucho.jstl.el.ForEachTag.doStartTag(ForEachTag.java:162)
        at _product._includes._featured_0media__jsp._jspService(_featured_0media__jsp.java:292)
        at com.caucho.jsp.JavaPage.service(JavaPage.java:75)
        at com.caucho.jsp.Page.subservice(Page.java:497)

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Thu, 8 Jan 2004 6:26 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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/secure/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-143) Criteria.count() and Query.count()

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

Message:

   The following issue has been closed.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-143
    Summary: Criteria.count() and Query.count()
       Type: New Feature

     Status: Closed
   Priority: Minor
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Alexey Kaigorodov

    Created: Wed, 18 Jun 2003 10:53 PM
    Updated: Thu, 8 Jan 2004 2:34 PM

Description:
Add method count in classes Criteria and Query.
Example:

final int PAGE_SIZE;
int position;
...
Query query = ... // build complex query with many parameters
int pageNum = position / PAGE_SIZE + 1;
int pageCount = query.count() / PAGE_SIZE + 1; // <-- HERE
System.out.println("Page " + pageNum + " from " + pageCount);
query.setFirstResult(position);
query.setMaxResults(PAGE_SIZE);
List page = query.list();
System.out.println(page);

Not necessary will twice create the similar Query or Criteria. 
By Criteria always easy build sql count query.
For Query.count() throw exception if create sql count query impossible.


---------------------------------------------------------------------
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/secure/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-610) column names that are keywords are not enclosed in hyphens

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

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Thu, 8 Jan 2004 1:43 PM

Please read the documentation. Especially Section "5.3. SQL quoted identifiers"
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-610
    Summary: column names that are keywords are not enclosed in hyphens
       Type: Bug

     Status: Closed
   Priority: Critical
 Resolution: REJECTED

    Project: Hibernate2
   Versions:
             2.1

   Assignee: 
   Reporter: Andreas Schildbach

    Created: Thu, 8 Jan 2004 1:27 PM
    Updated: Thu, 8 Jan 2004 1:43 PM
Environment: MySQL 3.23
Tomcat 4.1
Windows XP

Description:
I've got a database column named "key" in a legacy database schema under MySQL.

Since "key" seems to be a reserved keyword under MySQL, you have to prepend it with the table-name and ".", like in "where keys.key=?" instead of "where key=?".

The MySQLDialect does not do that ==> Hibernate errors.

Unfortunately I am not allowed to change the DB schema. This means I cannot use Hibernate at the moment.



---------------------------------------------------------------------
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/secure/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-610) column names that are keywords are not enclosed in hyphens

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

The following comment has been added to this issue:

     Author: Andreas Schildbach
    Created: Thu, 8 Jan 2004 1:28 PM
       Body:
The summary is misleading, sorry. I think that an alternative way to prepending column names with table-name plus "." is to put the column name in hyphens - but I'm not sure.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-610
    Summary: column names that are keywords are not enclosed in hyphens
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
   Versions:
             2.1

   Assignee: 
   Reporter: Andreas Schildbach

    Created: Thu, 8 Jan 2004 1:27 PM
    Updated: Thu, 8 Jan 2004 1:28 PM
Environment: MySQL 3.23
Tomcat 4.1
Windows XP

Description:
I've got a database column named "key" in a legacy database schema under MySQL.

Since "key" seems to be a reserved keyword under MySQL, you have to prepend it with the table-name and ".", like in "where keys.key=?" instead of "where key=?".

The MySQLDialect does not do that ==> Hibernate errors.

Unfortunately I am not allowed to change the DB schema. This means I cannot use Hibernate at the moment.



---------------------------------------------------------------------
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/secure/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-610) column names that are keywords are not enclosed in hyphens

[<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-610


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-610
    Summary: column names that are keywords are not enclosed in hyphens
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
   Versions:
             2.1

   Assignee: 
   Reporter: Andreas Schildbach

    Created: Thu, 8 Jan 2004 1:27 PM
    Updated: Thu, 8 Jan 2004 1:27 PM
Environment: MySQL 3.23
Tomcat 4.1
Windows XP

Description:
I've got a database column named "key" in a legacy database schema under MySQL.

Since "key" seems to be a reserved keyword under MySQL, you have to prepend it with the table-name and ".", like in "where keys.key=?" instead of "where key=?".

The MySQLDialect does not do that ==> Hibernate errors.

Unfortunately I am not allowed to change the DB schema. This means I cannot use Hibernate at the moment.



---------------------------------------------------------------------
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/secure/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-490) Make getMetaAttributes() support meta-inheritance

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

The following issue has been updated:

    Updater: Max Rydahl Andersen (mailto:xa...@xa...)
       Date: Thu, 8 Jan 2004 8:57 AM
    Comment:
tset
    Changes:
             security changed from Devel Team
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-490
    Summary: Make getMetaAttributes() support meta-inheritance
       Type: Improvement

     Status: Open
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: Max Rydahl Andersen
   Reporter: Max Rydahl Andersen

    Created: Sat, 22 Nov 2003 6:11 AM
    Updated: Thu, 8 Jan 2004 8:57 AM

Description:
Currentl getMetaAttributes() does not obey the inherit attribute on <meta> - it should.


---------------------------------------------------------------------
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/secure/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-490) Make getMetaAttributes() support meta-inheritance

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

The following issue has been updated:

    Updater: Max Rydahl Andersen (mailto:xa...@xa...)
       Date: Thu, 8 Jan 2004 8:51 AM
    Comment:
test
    Changes:
             security changed to Devel Team
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-490
    Summary: Make getMetaAttributes() support meta-inheritance
       Type: Improvement

     Status: Open
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: Max Rydahl Andersen
   Reporter: Max Rydahl Andersen

    Created: Sat, 22 Nov 2003 6:11 AM
    Updated: Thu, 8 Jan 2004 8:51 AM

Description:
Currentl getMetaAttributes() does not obey the inherit attribute on <meta> - it should.


---------------------------------------------------------------------
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/secure/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: (HBI-20) Compatibility Documentation - missing details on problem with Weblogic Support

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Thu, 8 Jan 2004 1:04 AM

Some users have reported problems working with WebLogic's JNDI server. Others have not. Try searching the (new + old) forums.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HBI-20
    Summary: Compatibility Documentation - missing details on problem with Weblogic Support
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate 1.2

   Assignee: 
   Reporter: Nick Minutello

    Created: Wed, 7 Jan 2004 12:57 PM
    Updated: Thu, 8 Jan 2004 1:04 AM

Description:

Regarding http://www.hibernate.org/34.html

Are there some more details on the problem with Hibernate on Weblogic?

I find no mention of this anywhere else in the FAQ, Jira or Wiki - perhaps I missed something?

Is this it still current?




---------------------------------------------------------------------
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/secure/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-589) websphere 5.1 transaction manager lookup

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

Message:

   The following issue has been re-assigned.

   Assignee: Daniel Bradby (mailto:db...@ci...)
   Assigner: Gavin King (mailto:ga...@hi...)
       Date: Thu, 8 Jan 2004 1:03 AM
    Comment:
Daniel, would you please take a look at this one?

Thanks.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-589
    Summary: websphere 5.1 transaction manager lookup
       Type: Bug

     Status: Open
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: Daniel Bradby
   Reporter: Edina Pimp

    Created: Tue, 30 Dec 2003 1:38 PM
    Updated: Thu, 8 Jan 2004 1:03 AM
Environment: websphere 5.1

Description:
WebSphere 5.1 changed the name of the TransactionManagerFactory class.  Class is now:

  com.ibm.ws.Transaction.TransactionManagerFactory

As a result, the net.sf.hibernate.transaction.WebSphereTransactionManagerLookup strategy will need to be updated to look for this class.  I can provide working patch if needed.




---------------------------------------------------------------------
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/secure/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-485) DYNAMIC_PREPARE and @@identity

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 8 Jan 2004 1:01 AM
       Body:
I'm sorry - I simply do not see how it is *our* problem that Sybase has a bug in their JDBC driver. You pay money to Sybase, make them fix their bugs.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-485
    Summary: DYNAMIC_PREPARE and @@identity
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Richard Scranton

    Created: Thu, 20 Nov 2003 1:22 PM
    Updated: Thu, 8 Jan 2004 1:01 AM

Description:
Using the Sybase jConnect jdbc driver version 4.5 or 5.5, if the connection property DYNAMIC_PREPARE is set to "true", "select @@identity" will always return a "0".  This is an artifact of the Sybase implementation of prepared statements.  Statements compiled at the server become stored procedures marked by the "DYN" token, and appear named as dyn100, dyn101, etc in the
captured TDS stream.  The value of @@identity is lost at the end of a procedure, so a sequence of prepared statements like:

insert into Yadda (val1,val2) values ( 1,2 )
select @@identity

will execute as expected when DYNAMIC_PREPARE is false.  If it is set to true, the statement "select @@identity" will return "0".  Sybase suggests something like this workaround to get the expected behavior:

String nl=System.getProperty("line.separator");
PreparedStaement ps=conn.prepareStatement(
        "insert into Yadd (val1,val2) values ( 1,2 )"
        + nl
        + "select @@identity");

Leaving DYNAMIC_PREPARE set false gives away throughput if the queries being sent and parsed are of significant size.  TDS dumps show they are being sent and parsed with each invocation.  Setting DYNAMIC_PREPARE to true allows reuse of the parsed queries.



---------------------------------------------------------------------
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/secure/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-609) replicate() with joined-subclass

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

Message:

   The following issue has been re-assigned.

   Assignee: Gavin King (mailto:ga...@hi...)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-609
    Summary: replicate() with joined-subclass
       Type: Bug

     Status: Open
   Priority: Major

    Project: Hibernate2
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Greg Barton

    Created: Tue, 6 Jan 2004 12:53 PM
    Updated: Thu, 8 Jan 2004 12:58 AM
Environment: Hibernate 2.1.1, Postgres 7.4

Description:
Attempt to call Session.replicate() on a persistent object mapped using joined-subclass.  A net.sf.hibernate.JDBCException is thrown because HIbernate attempts to access the "version" column in the underlying table.  That column is only present in the superclass table of the class being being replicated.

Exception generated:
net.sf.hibernate.JDBCException: could not retrieve version: [***id of object***]
        at net.sf.hibernate.persister.AbstractEntityPersister.getCurrentVersion(AbstractEntityPersister.java:1141)
        at net.sf.hibernate.impl.SessionImpl.replicate(SessionImpl.java:3698)
        at.... 


---------------------------------------------------------------------
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/secure/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-596) AbstractQueryImpl.setParameterList may have 0 length list

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 8 Jan 2004 12:57 AM
       Body:
Yeah, if thats all that can be done, I suppose so...
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-596
    Summary: AbstractQueryImpl.setParameterList may have 0 length list
       Type: Bug

     Status: Open
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: Max Rydahl Andersen
   Reporter: Chris Mercer

    Created: Fri, 2 Jan 2004 12:57 PM
    Updated: Thu, 8 Jan 2004 12:57 AM
Environment: Hibernate 2.1.1, mysql

Description:
Here is the source code for the method

public Query setParameterList(String name, Collection vals) throws HibernateException {
		setParameterList(name, vals, guessType( vals.iterator().next() ) );
		return this;
	}

The problems comes in when the vals collection is size 0.  The vals.iterator().next() will fail with a NoSuchElementException. 
 



---------------------------------------------------------------------
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/secure/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-589) websphere 5.1 transaction manager lookup

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

The following issue has been updated:

    Updater: Edina Pimp (mailto:edi...@ya...)
       Date: Wed, 7 Jan 2004 4:29 PM
    Comment:
just a diff
    Changes:
             Attachment changed to diff.txt
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-589
    Summary: websphere 5.1 transaction manager lookup
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Edina Pimp

    Created: Tue, 30 Dec 2003 1:38 PM
    Updated: Wed, 7 Jan 2004 4:29 PM
Environment: websphere 5.1

Description:
WebSphere 5.1 changed the name of the TransactionManagerFactory class.  Class is now:

  com.ibm.ws.Transaction.TransactionManagerFactory

As a result, the net.sf.hibernate.transaction.WebSphereTransactionManagerLookup strategy will need to be updated to look for this class.  I can provide working patch if needed.




---------------------------------------------------------------------
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/secure/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-589) websphere 5.1 transaction manager lookup

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

The following issue has been updated:

    Updater: Edina Pimp (mailto:edi...@ya...)
       Date: Wed, 7 Jan 2004 4:28 PM
    Comment:
full .java version
    Changes:
             Attachment changed to WebSphereTransactionManagerLookup.java
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-589
    Summary: websphere 5.1 transaction manager lookup
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Edina Pimp

    Created: Tue, 30 Dec 2003 1:38 PM
    Updated: Wed, 7 Jan 2004 4:28 PM
Environment: websphere 5.1

Description:
WebSphere 5.1 changed the name of the TransactionManagerFactory class.  Class is now:

  com.ibm.ws.Transaction.TransactionManagerFactory

As a result, the net.sf.hibernate.transaction.WebSphereTransactionManagerLookup strategy will need to be updated to look for this class.  I can provide working patch if needed.




---------------------------------------------------------------------
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/secure/Administrators.jspa

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