hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1584) Trying to get a deleted object --> ObjectDeletedException

[Koda J. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1584?page=comments#action_23643 ] 

Koda Janh commented on HHH-1584:
--------------------------------

I'm also in favor of Session.get() returning null but even if you disagree at the very least, please document this behavior in the Javadoc for Session.get()

> Trying to get a deleted object --> ObjectDeletedException
> ---------------------------------------------------------
>
>          Key: HHH-1584
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1584
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>  Environment: Linux, Oracle, Tomcat
>     Reporter: Nicolas Ternisien

>
>
> As explained here :
> http://forum.hibernate.org/viewtopic.php?t=940989&highlight=objectdeletedexception
> When you try to get an entity in the same Session / Transaction, after delete it, the ObjectDeletedException is thrown.
> It will be easier if the get() method from Session interface only returns a null instance, instead of launching an exception. 
> This case forces developers to flush the current session, to remove the deleted instance from it. 
> So I think it can reduce speed of an application.
> JUnit test, stack trace and some other explanations are available in the forum page.
> Cheers.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (ANN-261) Allow specifying foreign key constraint name using annotations

[Jeff S. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/ANN-261?page=comments#action_23642 ] 

Jeff Schnitzer commented on ANN-261:
------------------------------------

I'd like to request that the priority of this be increased.  Without it, there appears to be no annotation equivalent of:

foreign-key="none"

This is a big problem if you're mapping entities stored in tables to entites stored in views.

> Allow specifying foreign key constraint name using annotations
> --------------------------------------------------------------
>
>          Key: ANN-261
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-261
>      Project: Hibernate Annotations
>         Type: Improvement

>   Components: binder
>     Versions: 3.1beta8
>     Reporter: Paul Barry
>     Priority: Minor
>  Attachments: hibernate-annotations-3.2.0.CR1-fk.patch, hibernate-annotations-fk.patch
>
>
> Using hbm.xml configuration for many-to-one, there is a foreign-key property that allows you to specify the name of the FK constraint.  It would be nice if there was something similar for annotations, such as @ManyToOne ( constraintName = "FK_WHATEVER").  Also, a sensible default would be nice to, for example FK_TABLE_NAME_COLUMN_NAME, rather than FK20708CF6792111.  I know Oracle has a 30 char limit for constraint names, so there would have to me some logic to find a way to abbreviate it.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1913) 2nd Level Cache Improvements

[Tony V. (JIRA) <no...@at...>]

2nd Level Cache Improvements
----------------------------

         Key: HHH-1913
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1913
     Project: Hibernate3
        Type: Patch

    Versions: 3.1.3    
    Reporter: Tony Voss
 Attachments: Hibernate_ReadOnlyCache-RetryTrans-CollCache.patch, Hibernate_ReadOnlyCache-RetryTrans-CollCache.zip

Implement cache-only fetch mode on Session.get(ID) methods, and fix a bug where cache wasn't used via the codepath we were using 

Allow the L2 cache to be started after the SessionFactory is started, instead of always at the same time 

Support transaction retries by splitting flushing code between a datastore phase and a cache phase, and add an interceptor call back to allow the user to interact with datastore phase exceptions and control the retry loop. 

Evict entries for all owning collections from the L2 cache when an entity is created or destroyed.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1806) No Dialect mapping for JDBC type: 3

[daniel f. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1806?page=comments#action_23641 ] 

daniel flesner commented on HHH-1806:
-------------------------------------

this also appears to be broken on mysql 5.0.22 and mysql-connector-java 3.1.13. the following select "select avg(score), std(score), min(score), max(score) from score_raw" throws the same exception. hibernate version 3.1.3.

> No Dialect mapping for JDBC type: 3
> -----------------------------------
>
>          Key: HHH-1806
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1806
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2, 3.1.3
>  Environment: Oracle JDBC driver with the Hibernate DataDirectOracle9Dialect.
>     Reporter: amit bhayani

>
>
> Hibernate throws "No Dialect mapping for JDBC type: 3" when using Oracle JDBC driver with the Hibernate DataDirectOracle9Dialect.
> DataDirect Connect for JDBC Oracle driver returns the JDBC type DECIMAL for some result set columns however there was no mapping set up in the DataDirectOracle9Dialect for the DECIMAL JDBC type.
> The work arround for issue is to  add the following constructor to DataDirectOracle9Dialect
> public DataDirectOracle9Dialect() {
> super();
> registerColumnType( Types.DECIMAL, "number($p,$s)" );
> registerHibernateType(Types.DECIMAL, "big_decimal");
> }
> Can Hibernate Team add this constructor or something similar to the DataDirectOracle9Dialect?
> Version Info
> Hibernate: 3.1.3
> DataDirect
> Connect for JDBC
> Oracle driver: 3.5.40
> Forum reference http://forum.hibernate.org/viewtopic.php?t=959583&highlight=dialect+mapping+jdbc+type+3

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23640 ] 

Max Rydahl Andersen commented on HBX-706:
-----------------------------------------

you should just use the hibernate 3.2 builds with the codegen; not needed for running your apps.

> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
>          Key: HBX-706
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
>      Project: Hibernate Tools
>         Type: Bug

>   Components: ant
>     Versions: 3.1beta4
>  Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
>     Reporter: Alfie Kirkpatrick
>  Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
>         at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1912) Allow quoted aliases in HQL select clause

[Erik G (JIRA) <no...@at...>]

Allow quoted aliases in HQL select clause
-----------------------------------------

         Key: HHH-1912
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1912
     Project: Hibernate3
        Type: Improvement

  Components: query-hql  
    Versions: 3.2.0.cr3    
    Reporter: Erik G


It would be nice to have quoted identifiers in HQL select clause.

Use Case:
Using an HQL select query to generate reports. HQL is a powerful language and in many ways easier to use than SQL. When trying to use arbitrary HQL queries to generate a report and use the getReturnAliases() method on the Query to determine column-headers for a report, it would be great to have the ability to quote the aliases.

For example, take the query "select firstName, lastName from Customer c" 

if you wanted to introduce more readable aliases into the query, it would be natural to want to try 

"select firstName as `First Name`, lastName as `Last Name` from Customer c" but this does not seem to work.

I'd be happy to help with a fix if someone could point me in the right direction.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Reopened: (HHH-1911) evict has no effect with ReadWrite cache Strategy

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911?page=all ]
     
Steve Ebersole reopened HHH-1911:
---------------------------------


> evict has no effect with ReadWrite cache Strategy
> -------------------------------------------------
>
>          Key: HHH-1911
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>     Reporter: Michael Kopp

>
>
> I first found this when my own Persister informed the EntityUpdateAction to invalidate the cache.
> persister.isCacheInvalidationRequired()
> The EntityUpdateAction dutifully calls evict on the Cache, but that did  not effect the cache state in any way. I looked into it and found that evict is a noop in ReadWrite Cache.
> This breaks the consistence. The item is still in the cache after the update, unchange even after the transaction completed.
> The next load will return a wrong state!!!
> I digged a little more and found that the same thing happens on a delete too. the EntityDeleteAction calls evict but of course nothing happens.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1911) evict has no effect with ReadWrite cache Strategy

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911?page=all ]
     
Steve Ebersole resolved HHH-1911:
---------------------------------

    Resolution: Incomplete

> evict has no effect with ReadWrite cache Strategy
> -------------------------------------------------
>
>          Key: HHH-1911
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>     Reporter: Michael Kopp

>
>
> I first found this when my own Persister informed the EntityUpdateAction to invalidate the cache.
> persister.isCacheInvalidationRequired()
> The EntityUpdateAction dutifully calls evict on the Cache, but that did  not effect the cache state in any way. I looked into it and found that evict is a noop in ReadWrite Cache.
> This breaks the consistence. The item is still in the cache after the update, unchange even after the transaction completed.
> The next load will return a wrong state!!!
> I digged a little more and found that the same thing happens on a delete too. the EntityDeleteAction calls evict but of course nothing happens.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-1911) evict has no effect with ReadWrite cache Strategy

[Steve E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911?page=all ]
     
Steve Ebersole resolved HHH-1911:
---------------------------------

    Resolution: Fixed

No test case...

However, I seriously suggest you check out the following for the expetced call sequence:
http://fisheye.jboss.com/viewrep/Hibernate/trunk/Hibernate3/src/org/hibernate/cache/CacheConcurrencyStrategy.java?r=9247

> evict has no effect with ReadWrite cache Strategy
> -------------------------------------------------
>
>          Key: HHH-1911
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.3
>     Reporter: Michael Kopp

>
>
> I first found this when my own Persister informed the EntityUpdateAction to invalidate the cache.
> persister.isCacheInvalidationRequired()
> The EntityUpdateAction dutifully calls evict on the Cache, but that did  not effect the cache state in any way. I looked into it and found that evict is a noop in ReadWrite Cache.
> This breaks the consistence. The item is still in the cache after the update, unchange even after the transaction completed.
> The next load will return a wrong state!!!
> I digged a little more and found that the same thing happens on a delete too. the EntityDeleteAction calls evict but of course nothing happens.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1777) org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken

[suresh s. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1777?page=comments#action_23638 ] 

suresh soundararajan commented on HHH-1777:
-------------------------------------------

Put all the jars in your PRE_CLASSPATH of weblogic startup script and try again

> org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken 
> -------------------------------------------------------------------------------------
>
>          Key: HHH-1777
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1777
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.1.3
>  Environment: Hibernate 3.1.3,mysql-5.0.21-win32,mysql-connector-java-3.0.17-ga,jdk1.4.1_05,Struts 1.1,weblogic 8.1,MyEclipse 4.1.1GA
>     Reporter: Ranjit Patil
>  Attachments: AbstractBook.java, Book.hbm.xml, Book.java, BookListAction.java, BookListForm.class, HibernateSessionFactory.java, LibraryManager.java, hibernate.cfg.xml
>
>
> I have two tables book and customer. My index page has two links show book list and Show customer List.Currently I am working on only Book List. It calls BookListAction.java which in turn calls LibraryManager.java in which getAllBooks() has code something like this:
> public Book[] getAllBooks() {
> 		/* will hold the books we are going to return later */
> 		List books = new ArrayList();
> 		/* a Hibernate session */
> 		Session session = null;
> 		/* we always need a transaction */
> 		Transaction tx = null;
> 		/* get session of the current thread */
> 		session = HibernateSessionFactory.currentSession();
> 		tx = session.beginTransaction();
>                                          ----------Exception is thrown when the below line of code is executed---------------------
> 		List tmpBooks = session.createQuery(
> 				"select b from Book as b order by b.author, b.title").list();
>                                          -----------------------------------------------------------------------------------------------------------------
> 		for (Iterator iter = tmpBooks.iterator(); iter.hasNext();) {
> 			books.add((Book) iter.next());
> 		}
> 		tx.commit();
> 		return (Book[]) books.toArray(new Book[0]);
> 	}
> In eclipse it runs fine but when i deployed on weblogic i got following error when i clicked the show book list link:
> org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken [select b from de.laliluna.library.Book as b order by b.author, b.title]
> 	at org.hibernate.hql.ast.HqlLexer.panic(HqlLexer.java:57)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:287)
> 	at org.hibernate.hql.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:31)
> 	at antlr.CharScanner.(CharScanner.java:42)
> 	at antlr.CharScanner.(CharScanner.java:51)
> 	at org.hibernate.hql.antlr.HqlBaseLexer.(HqlBaseLexer.java:56)
> 	at org.hibernate.hql.antlr.HqlBaseLexer.(HqlBaseLexer.java:53)
> 	at org.hibernate.hql.antlr.HqlBaseLexer.(HqlBaseLexer.java:50)
> 	at org.hibernate.hql.ast.HqlLexer.(HqlLexer.java:26)
> 	at org.hibernate.hql.ast.HqlParser.getInstance(HqlParser.java:44)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:232)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:155)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:109)
> 	at org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:75)
> 	at org.hibernate.engine.query.HQLQueryPlan.(HQLQueryPlan.java:54)
> 	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71)
> 	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133)
> 	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112)
> 	at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1583)
> 	at de.laliluna.library.bl.LibraryManager.getAllBooks(LibraryManager.java:35)

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1911) evict has no effect with ReadWrite cache Strategy

[Michael K. (JIRA) <no...@at...>]

evict has no effect with ReadWrite cache Strategy
-------------------------------------------------

         Key: HHH-1911
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1911
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.1.3    
    Reporter: Michael Kopp


I first found this when my own Persister informed the EntityUpdateAction to invalidate the cache.

persister.isCacheInvalidationRequired()

The EntityUpdateAction dutifully calls evict on the Cache, but that did  not effect the cache state in any way. I looked into it and found that evict is a noop in ReadWrite Cache.
This breaks the consistence. The item is still in the cache after the update, unchange even after the transaction completed.
The next load will return a wrong state!!!

I digged a little more and found that the same thing happens on a delete too. the EntityDeleteAction calls evict but of course nothing happens.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1910) Polymorphic Components

[Joe K. (JIRA) <no...@at...>]

Polymorphic Components
----------------------

         Key: HHH-1910
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1910
     Project: Hibernate3
        Type: New Feature

  Components: core  
    Reporter: Joe Kelly


Please add support for mapping polymorphic components (i.e. polymorphism in the <component> element). This has been requested and suggested in numerous Hibernate user forum threads. Here's a sampling of these threads:
http://forum.hibernate.org/viewtopic.php?t=949827&highlight=component+subclass
http://forum.hibernate.org/viewtopic.php?t=947207&highlight=component+discriminator
http://forum.hibernate.org/viewtopic.php?t=929436&highlight=component+discriminator
http://forum.hibernate.org/viewtopic.php?t=926027&highlight=component+discriminator
http://forum.hibernate.org/viewtopic.php?t=930136&highlight=abstract+component

I realize that you can create a CompositeUserType to solve this problem. In fact, I have done this on numerous occasions. However, this requires writing code, which is not nearly as convenient as writing a little bit of XML.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Alfie K. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23637 ] 

Alfie Kirkpatrick commented on HBX-706:
---------------------------------------

I suspect this issue has gone away in newer builds. The hbm2java task certainly got further than before before it hit the noclassdef error.

I'd like to help with more testing but I don't have time to get the latest tools, install in my maven repo with any new dependencies, etc, etc. I also have a slight worry that the latest tools beta runs against Hibernate 3.2 which is itself in beta so even if it does fix the bug we may be stuck with it on the current released version. And I have workarounds in place for it.

I'll start in the forum next time. Apologies.

Thanks!
Alfie.

> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
>          Key: HBX-706
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
>      Project: Hibernate Tools
>         Type: Bug

>   Components: ant
>     Versions: 3.1beta4
>  Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
>     Reporter: Alfie Kirkpatrick
>  Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
>         at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23636 ] 

Max Rydahl Andersen commented on HBX-706:
-----------------------------------------

you need to use the latest hibernate (or at least the hibernate that comes with the tools).

Could we take this discussion to the forums until we actually figure out that a bug exists ? :) thank you.

> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
>          Key: HBX-706
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
>      Project: Hibernate Tools
>         Type: Bug

>   Components: ant
>     Versions: 3.1beta4
>  Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
>     Reporter: Alfie Kirkpatrick
>  Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
>         at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Alfie K. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23635 ] 

Alfie Kirkpatrick commented on HBX-706:
---------------------------------------

Thanks for the quick reply...

I changed to the following dependencies (the latest on public maven repos):

<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate</artifactId>
	<version>3.2.0.cr2</version>
</dependency>

<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate-tools</artifactId>
	<version>3.2.0.beta6</version>
	<scope>compile</scope>
</dependency>

I now get a:

java.lang.NoClassDefFoundError: org/hibernate/engine/query/sql/NativeSQLQueryReturn
        at java.lang.Class.getDeclaredMethods0(Native Method)

Thanks, Alfie.


> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
>          Key: HBX-706
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
>      Project: Hibernate Tools
>         Type: Bug

>   Components: ant
>     Versions: 3.1beta4
>  Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
>     Reporter: Alfie Kirkpatrick
>  Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
>         at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Max R. A. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-706?page=comments#action_23634 ] 

Max Rydahl Andersen commented on HBX-706:
-----------------------------------------

please try and use a more uptodate version and tell me if the problem persists.
(because i don't understand why all those things should affect the tools)

> Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
> --------------------------------------------------------------------------------------------------------
>
>          Key: HBX-706
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
>      Project: Hibernate Tools
>         Type: Bug

>   Components: ant
>     Versions: 3.1beta4
>  Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
>     Reporter: Alfie Kirkpatrick
>  Attachments: hibernate-problem.zip
>
>
> I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 
> org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> [snip]
> Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
>         at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
> [snip]
> I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.
> I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.
> I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).
> .. and it worked fine!
> So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.
> You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.
> I'd suggest a couple of possible fixes/improvements:
> - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM
> - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ
> I can't think of a way to track down the underlying cause of this issue. It's a very odd one.
> Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-706) Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

[Alfie K. (JIRA) <no...@at...>]

Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform
--------------------------------------------------------------------------------------------------------

         Key: HBX-706
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-706
     Project: Hibernate Tools
        Type: Bug

  Components: ant  
    Versions: 3.1beta4    
 Environment: Hibernate 3.1, database is Oracle (but not relevant to this)
    Reporter: Alfie Kirkpatrick
 Attachments: hibernate-problem.zip

I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. 

org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
[snip]
Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version
        at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223)
[snip]

I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options.

I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained.

I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?).

.. and it worked fine!

So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me.

You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven.

I'd suggest a couple of possible fixes/improvements:

- Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM

- Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ

I can't think of a way to track down the underlying cause of this issue. It's a very odd one.

Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HHH-1696) add outer join support for aliases on detached cirteria

[Benoit Goudreault-E. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1696?page=all ]

Benoit Goudreault-Emond updated HHH-1696:
-----------------------------------------

    Attachment: HHH-1696.patch

I've attached a simple patch against 3.1.3 that implements this feature.  Actually, what the patch does is implement relevant functions in Criteria in the DetachedCriteria class.  Those are:

- All variants of createAlias()
- All variants of createCriteria()
- All variants of setLockMode()
- setComment() (not used much, I suppose, but why not?)

It wasn't clear whether setFlushMode() and setCacheMode() should be applied to DetachedCriteria.  My guess is that those are more properties of the executable criteria, like setFirstResult()/setMaxResult(), and aren't part of the query itself, but rather, of the execution environment.

> add outer join support for aliases on detached cirteria
> -------------------------------------------------------
>
>          Key: HHH-1696
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1696
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1.3, 3.2.0 cr1
>  Environment: Hibernate 3.1, SQLServer2000
>     Reporter: Mark Brocato
>  Attachments: HHH-1696.patch
>
>
> Recently, support for aliasing via an outer join was added to the Criteria class.  The method
> createAlias(String associationPath, String alias, int joinType) 
> , however, is not defined for DetachedCriteria.  Adding this functionality would be extremely helpful for applications that expose detached criteria as their query api, and also for subqueries.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HBX-705) query result shows exception when executing update query

[Max R. A. (JIRA) <no...@at...>]

query result shows exception when executing update query
--------------------------------------------------------

         Key: HBX-705
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-705
     Project: Hibernate Tools
        Type: Bug

  Components: eclipse  
    Versions: 3.2beta6    
    Reporter: Max Rydahl Andersen


for query "delete Person" on an empty db the following is shown in queyr result view:


java.lang.NullPointerException
	at org.hibernate.impl.SessionFactoryImpl.getReturnAliases(SessionFactoryImpl.java:657)
	at org.hibernate.impl.AbstractQueryImpl.getReturnAliases(AbstractQueryImpl.java:158)
	at org.hibernate.console.HQLQueryPage.getPathNames(HQLQueryPage.java:110)
	at org.hibernate.eclipse.console.views.QueryPageViewer.addColumnsToTable(QueryPageViewer.java:249)
	at org.hibernate.eclipse.console.views.QueryPageViewer.createTable(QueryPageViewer.java:204)

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1909) Incomplete insert and update using <<insert="false" update="false">>

[Peppe (JIRA) <no...@at...>]

Incomplete insert and update using <<insert="false" update="false">>
--------------------------------------------------------------------

         Key: HHH-1909
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1909
     Project: Hibernate3
        Type: Bug

  Components: core  
    Versions: 3.0 final    
    Reporter: Peppe
    Priority: Critical


Hi, I've seen lots of people have problems using complex mappings.
This is my situation, I've three mappings:

<hibernate-mapping>
    <class name="unibiblio.dati.anagrafica.DAO.Persone" table="persone">
        <composite-id name="id" class="unibiblio.dati.anagrafica.DAO.PersoneId">
            <key-property name="idUtente" type="java.lang.Integer">
                <column name="id_utente" />
            </key-property>
            <key-property name="codbib" type="java.lang.Integer">
                <column name="codbib" />
            </key-property>
        </composite-id>
        <many-to-one name="dizTitolidistudio" class="unibiblio.dati.anagrafica.DAO.DizTitolidistudio" update="false" insert="false" fetch="select">
            <column name="lingua" length="2" />
            <column name="codice_titolostudio" length="1" />
        </many-to-one>
        <many-to-one name="dizLingue" class="unibiblio.dati.anagrafica.DAO.DizLingue" fetch="select">
            <column name="lingua" length="2" />
        </many-to-one>
        <many-to-one name="dizProfessioni" class="unibiblio.dati.anagrafica.DAO.DizProfessioni" update="false" insert="false" fetch="select">
            <column name="lingua" length="2" />
            <column name="codprofessione" length="2" not-null="true" />
        </many-to-one>
        <property name="userName" type="string">
            <column name="user_name" length="30" />
        </property>
        <property name="password" type="string">
            <column name="password" length="30" />
        </property>
        .
        .
        .
        .
        .
        .
    </class>
</hibernate-mapping>


<hibernate-mapping>
    <class name="unibiblio.dati.anagrafica.DAO.DizTitolidistudio" table="diz_titolidistudio">
        <composite-id name="id" class="unibiblio.dati.anagrafica.DAO.DizTitolidistudioId">
            <key-property name="lingua" type="string">
                <column name="lingua" length="2" />
            </key-property>
            <key-property name="codiceTitolostudio" type="string">
                <column name="codice_titolostudio" length="1" />
            </key-property>
        </composite-id>
        <many-to-one name="dizLingue" class="unibiblio.dati.anagrafica.DAO.DizLingue" update="false" insert="false" fetch="select">
            <column name="lingua" length="2" not-null="true" />
        </many-to-one>
        <property name="titolo" type="string">
            <column name="titolo" length="50" not-null="true" />
        </property>
        <set name="persones" inverse="true">
            <key>
                <column name="lingua" length="2" />
                <column name="codice_titolostudio" length="1" />
            </key>
            <one-to-many class="unibiblio.dati.anagrafica.DAO.Persone" />
        </set>
    </class>
</hibernate-mapping>


<hibernate-mapping>
    <class name="unibiblio.dati.anagrafica.DAO.DizProfessioni" table="diz_professioni">
        <composite-id name="id" class="unibiblio.dati.anagrafica.DAO.DizProfessioniId">
            <key-property name="lingua" type="string">
                <column name="lingua" length="2" />
            </key-property>
            <key-property name="codprofessione" type="string">
                <column name="codprofessione" length="2" />
            </key-property>
        </composite-id>
        <many-to-one name="dizLingue" class="unibiblio.dati.anagrafica.DAO.DizLingue" update="false" insert="false" fetch="select">
            <column name="lingua" length="2" not-null="true" />
        </many-to-one>
        <property name="professione" type="string">
            <column name="professione" length="50" />
        </property>
        <set name="persones" inverse="true">
            <key>
                <column name="lingua" length="2" />
                <column name="codprofessione" length="2" not-null="true" />
            </key>
            <one-to-many class="unibiblio.dati.anagrafica.DAO.Persone" />
        </set>
    </class>
</hibernate-mapping>

The problem is when I try to insert a new persone it make an incomplete SQL statement because 
<<update="false" insert="false">> in <many-to-one name="dizTitolidistudio"> and <many-to-one name="dizProfessioni">
causes hiding setting of columns "codice_titolostudio" and "codprofessione" in the generated SQL

Deleting that tag, of course, give me the exception
	ERROR [STDERR] org.hibernate.MappingException: Repeated column in mapping for entity: unibiblio.dati.anagrafica.DAO.Persone column: lingua (should be mapped with insert="false" update="false")
	
I workarounded this extracting "codice_titolostudio" and "codprofessione" as properties in Persone and setting them with 
classes but I don't like this. Am I wrong or is it a bug?



-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] Hibernate session issue

[Misra, P. <pra...@fm...>]

I face a problem while using Hibernate.
I do a search on owner names and get a list of owner id and names and
when I click on a particular owner it takes me to the view screen.
To view the details of owner, the method(code piece) which I use is -=20

		session =3D
HibernateSessionFactory.getInstance().currentSession();
		tx =3D session.beginTransaction();
		TFmsOwnerInformation tOwner =3D new
TFmsOwnerInformation();
		tOwner =3D (TFmsOwnerInformation) session.load(
					TFmsOwnerInformation.class, new
Long(ownerId));
		list.add(tOwner);

In the finally I do=20
finally {
	if(tx !=3D null) tx.commit();
	if (session !=3D null) session.close();
}

But If I do session.close() in finally I get an error saying:=20
15:12:44,199 ERROR [LazyInitializationException] could not initialize
proxy - the owning Session was closed
org.hibernate.LazyInitializationException: could not initialize proxy -
the owning Session was closed

To avoid this error I used session.flush(). But this created another
problem. I have a Update button on the view screen. After I click on
Update(the update screen loads the data by calling the same method) and
then save the data, I come back to the view screen. Hence the same
method is used for view and update screen to load. But it used to
display stale data in the view screen/update screen a lot of times.

To avoid this a method was added by us -
HibernateSessionFactory.closeHibernateFactory(); before session =3D
HibernateSessionFactory.getInstance().currentSession();
closeHibernateFactory() ::

	public static synchronized void closeHibernateFactory() {
			=09
			s_instance =3D null;
			Session s =3D (Session) s_session.get();
			s =3D null;
			s_session.set(s);	=09
	=09
	}

But this method again instantiates all the mapping files. Can anybody
please give me a solution to this?

Thanks & Regards,=20
Pragyan

------------------------------------------------------------------------
-----------------
This e-mail, and any attachment hereto, is privileged, confidential and
proprietary information of Fidelity Business Services India Pvt. Ltd. or
any of the Fidelity Investments group companies and is intended for use
only by the individual or entity to whom it is addressed. If you are not
the intended recipient of this e-mail, or if you have otherwise received
this e-mail in error, please immediately notify the sender and
permanently delete the original mail, any print outs and any copies -
including the attachments. Any dissemination, distribution or copying of
this e-mail is strictly prohibited. All e-mails sent from or to Fidelity
Business Services India Pvt. Ltd. may be subject to our monitoring
procedures.

[Hibernate-issues] [Hibernate-JIRA] Closed: (HHH-1908) ClassMetadata new method: List<Annotation> getPropertyAnnotations(String propName)

[Max R. A. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1908?page=all ]
     
Max Rydahl Andersen closed HHH-1908:
------------------------------------

    Resolution: Rejected

sorry, but hibernates classmetadata cannot return Annotation (would tie it to jdk 5) and even as important it doesn't really make sense to expose non-hibernate related information in here.

that said we have talked about allowing some construct for 3rd party (including our own tools and lucene integration) to hook structured information into hibernate's metamodel.

> ClassMetadata new method: List<Annotation> getPropertyAnnotations(String propName)
> ----------------------------------------------------------------------------------
>
>          Key: HHH-1908
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1908
>      Project: Hibernate3
>         Type: New Feature

>  Environment: All
>     Reporter: Nigel White

>
>
> I'm beginning to use org.hibernate.metadata.ClassMetadata
> It's very useful having all the information about a persistent class available.
> There is still quite a lot of information locked up in the class that isn't accessible through ClassMetadata.
> Of course I have my own introspection utilities which examine our persistent classes, so that we can do a lot of automated stuff, but it would be good if we didn't need to - if we could rely on Hibernate's metedata.
> So what I'm thinking of is a way of returning all the annotations that were applied either to a Field, or that Field's getter.
> [code]
> List<Annotation> getPropertyAnnotations(String propName);
> List<Annotation>[] getPropertiesAnnotations();
> [/code]
> For instance, we have an annotation against a Field that says that Field is the description for that entity (eg, country name, customer name etc) that would be displayed in a combobox/select. We have other annotations too, so we use our own introspection scheme.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1908) ClassMetadata new method: List<Annotation> getPropertyAnnotations(String propName)

[Nigel W. (JIRA) <no...@at...>]

ClassMetadata new method: List<Annotation> getPropertyAnnotations(String propName)
----------------------------------------------------------------------------------

         Key: HHH-1908
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1908
     Project: Hibernate3
        Type: New Feature

 Environment: All
    Reporter: Nigel White


I'm beginning to use org.hibernate.metadata.ClassMetadata

It's very useful having all the information about a persistent class available.

There is still quite a lot of information locked up in the class that isn't accessible through ClassMetadata.

Of course I have my own introspection utilities which examine our persistent classes, so that we can do a lot of automated stuff, but it would be good if we didn't need to - if we could rely on Hibernate's metedata.

So what I'm thinking of is a way of returning all the annotations that were applied either to a Field, or that Field's getter.

[code]
List<Annotation> getPropertyAnnotations(String propName);

List<Annotation>[] getPropertiesAnnotations();
[/code]

For instance, we have an annotation against a Field that says that Field is the description for that entity (eg, country name, customer name etc) that would be displayed in a combobox/select. We have other annotations too, so we use our own introspection scheme.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1907) make ComponentType operate more like EntityType

[Steve E. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907?page=comments#action_23631 ] 

Steve Ebersole commented on HHH-1907:
-------------------------------------

Also make the notion of EntityMode extensible, at least internally, while in here changing this code.  The end-game being to eventually allow users to plugin in their own entity modes

> make ComponentType operate more like EntityType
> -----------------------------------------------
>
>          Key: HHH-1907
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Reporter: Steve Ebersole
>     Assignee: Steve Ebersole

>
>
> Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here.  So where do we move it?  Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed.  Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...
> Why is this important?  Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped.  This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.
> Also, this change should allow us to cleanup how property accessors are built

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Created: (HHH-1907) make ComponentType operate more like EntityType

[Steve E. (JIRA) <no...@at...>]

make ComponentType operate more like EntityType
-----------------------------------------------

         Key: HHH-1907
         URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907
     Project: Hibernate3
        Type: Improvement

  Components: core  
    Reporter: Steve Ebersole
 Assigned to: Steve Ebersole 


Specifically, we need to move all the code directly dealing with property-access, instantiation, etc out of here.  So where do we move it?  Well, EntityType for example moves this stuff off to the persisters; the type then just looks up the persister when needed.  Not sure we actually need a persister per-se for handling components; perhaps just ComponentMetamodel is enough...

Why is this important?  Well the way ComponentType is currently structured leads to the need for certain configuration properties to be classloader scoped (static on Environment) instead of SessionFactory scoped.  This is painful for two in particular: 1) whether to use reflection optimization and 2) bytecode provider.

Also, this change should allow us to cleanup how property accessors are built

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira