[GLASSFISH-3574] NullPointerException in appendFromClauseForInformixOuterJoin Created: 02/Sep/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Blocker
Reporter: bernd_zedv Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 3,574

 Description   

Sun Java System Application Server 9.1 (build b58-rc1)
Database is Informix 10 (This Exception does not appear with DERBY)
NetBeans 5.5.1

Mapping:
--------------------------------------------------------------------------------
@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public class Parent implements Serializable {

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long parentId;
......
@Entity
@PrimaryKeyJoinColumn(name="CHILDID")
public class Child extends Parent implements Serializable {
--------------------------------------------------------------------------------

Statement:

Collection<Parent> cP = em.createQuery("select o from Parent o ).getResultList();

Exception in thread "main" java.lang.NullPointerException
at
oracle.toplink.essentials.internal.expressions.SQLSelectStatement.appendFromClauseForInformixOuterJoin(SQLSelectStatement.java:178)
at
oracle.toplink.essentials.internal.expressions.SQLSelectStatement.appendFromClauseToWriter(SQLSelectStatement.java:450)
at
oracle.toplink.essentials.internal.expressions.SQLSelectStatement.printSQL(SQLSelectStatement.java:1310)
at
oracle.toplink.essentials.internal.expressions.SQLSelectStatement.buildCall(SQLSelectStatement.java:683)
at
oracle.toplink.essentials.descriptors.ClassDescriptor.buildCallFromStatement(ClassDescriptor.java:550)
at
oracle.toplink.essentials.internal.queryframework.StatementQueryMechanism.setCallFromStatement(StatementQueryMechanism.java:393)
at
oracle.toplink.essentials.internal.queryframework.ExpressionQueryMechanism.prepareReportQuerySelectAllRows(ExpressionQueryMechanism.java:1321)
at
oracle.toplink.essentials.queryframework.ReportQuery.prepareSelectAllRows(ReportQuery.java:988)
at
oracle.toplink.essentials.queryframework.ReadAllQuery.prepare(ReadAllQuery.java:398)
at
oracle.toplink.essentials.queryframework.ReportQuery.prepare(ReportQuery.java:904)
at
oracle.toplink.essentials.queryframework.DatabaseQuery.checkPrepare(DatabaseQuery.java:387)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.checkPrepare(ObjectLevelReadQuery.java:469)
at
oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:587)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:677)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:731)
at
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2218)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:937)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:909)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:346)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getResultList(EJBQueryImpl.java:447)
at javaapplication4.Main.main(Main.java:56)



 Comments   
Comment by gfbugbridge [ 02/Sep/07 ]

<BT6600180>

Comment by tware [ 04/Sep/07 ]

The following line does not look like it would even compile - it is missing a
quote...

Collection<Parent> cP = em.createQuery("select o from Parent o ).getResultList();

Is this the full query? I am surprised you are getting into that area of the
code without an outer join in the query.

Comment by tware [ 04/Sep/07 ]

I think I now see why you are getting an outer join.

It's because of the inheritance.

Sorry for any confusion.

Comment by tware [ 04/Sep/07 ]

Switching to Enhancement

Informix requires special outer join support and it appears that some of the
code written to support outer joins on Informix when using joins inheritance is
broken.

TopLink Essentials is certified against a set of databases that is similar to
the non-open-source TopLink version. As you can see from the following web page,
Informix is not a certified platform.

http://www.oracle.com/technology/products/ias/toplink/technical/support/database1013.html

What this means is that while we will endeavor to help users of this database
get the functionality they are looking for, the amount of testing that has been
done against this database is much lower than the certified databases.

We would be happy to provide a resource to help the interested members of the
community get this support working better.

Comment by bernd_zedv [ 08/Sep/07 ]

Since a couple of years Informix supports ANSI JOINS. Hibernate's Informix
adapter works this way and does this job fine.

There is that ... boolean isInformixOuterJoin() ... in Toplink code and my hope
was to find a workaround which e.g. influences Toplink to generate the ususal
SQL (ANSI) code even for Informix.

For some other reasons I cannot/want not switch to Hibernate persistence manager.

Comment by tware [ 10/Sep/07 ]

You could try subclassing the InformixPlatform. There are two methods that
affect how outer joins are written.

isInformixOuterJoin()
shouldPrintOuterJoinInWhereClause()

Overriding isInformixOuterJoin() to return false
and/or overriding shouldPrintOuterJoinInWhereClause() to return true

could help you generate the syntax you want.

When you have your new platform, you can use the toplink.target-database
persistence property and set its value to your fully qualified class name.

Comment by bernd_zedv [ 19/Sep/07 ]

After I changed
oracle.toplink.essentials.platform.database.InformixPlatform.isInformixOuterJoin()
to return false, ANSI SQL outer syntax is generated and no more
NullPointerExceptions arise.

Changing shouldPrintOuterJoinInWhereClause() does not work - it merely generates
weird " =* " in WHERE clause.

Thanks!
Bernd

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-4042] Support H2 Database Engine Platform in TopLink Essentials Created: 28/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: New Feature Priority: Blocker
Reporter: thomasmueller2 Assignee: tware
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,042

 Description   

Hi,

Could you please add support for the H2 Database Engine in TopLink Essentials?
The source code is here:

http://h2database.googlecode.com/svn/trunk/h2/src/tools/oracle/toplink/essentials/platform/database/H2Platform.java.txt

and should be committed to:

https://glassfish.dev.java.net/source/browse/glassfish/entity-persistence/src/java/oracle/toplink/essentials/platform/database/

Regards,
Thomas



 Comments   
Comment by aleksey_shipilev [ 01/Dec/09 ]
      • Issue 4042 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3628] Function REPLACE in named-query Created: 19/Sep/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Improvement Priority: Blocker
Reporter: laurentapo Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,628

 Description   

Hello,

Currently, in named-query, functions avaliable on string are : CONCAT,
SUBSTRING, TRIM, LOWER, UPPER, LENGTH, LOCATE.

Function REPLACE don't exist.

We must use named-native-query if you want to replace caracter.

I need this function to search case insensitive and without accent.

For example:
DépAssà => depassa

With existing functions, I can only use LOWER funtion but it not convert accent.

Thanks Laurent



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-4887] Support for SQL LIMIT / OFFSET with setMaxResults() / setFirstResult() Created: 24/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Improvement Priority: Blocker
Reporter: batzee Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,887

 Description   

Almost all web applications use pagination to split large tables into pages with
a relatively small number of rows each. In Toplink Essentials, setFirstResult()
and setMaxResults() can be used to achieve this.

At least for PostgreSQL and MySQL, and most likely for other RDBMs, a lot of I/O
effort can be saved by using the LIMIT and OFFSET sql clauses. Toplink
Essentials really should use it!!

(Hibernate has been doing this for a long time!!)



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-21486] Invoking a query in extended persistence context outside transaction clears it Created: 22/Jan/16  Updated: 25/Jan/16

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0, 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: pdudits Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 7 and JDK 8



 Description   

Entity gets detached after invocation of Query.getResultList within extended persistence context and @TransactionAttribute(NOT_SUPPORTED).

This violates JPA 2.1 spec basically in every section that refers to extended persistence context and managed state of entities: §3.1.1, §3.3, §3.3.1, §3.3.2, §3.10. and so on.

Example projects demonstrating this on embedded glassfish will be attached as soon as an issue number is assigned to this.



 Comments   
Comment by pdudits [ 22/Jan/16 ]

Test case is available at https://github.com/pdudits/GLASSFISH-21486.

Fails on Glassfish since v4, also on all Payara. Works with glassfish 3.1.2.2.

Comment by pdudits [ 25/Jan/16 ]

This bug is caused by GLASSFISH-19544:

There is explicit entityManagerDelegate.clear(); in QueryWrapper.getResultList, which is instantiated in EntityManagerWrapper, that disregards whether the current persistence context is an extended one.

Comment by pdudits [ 25/Jan/16 ]

GLASSFISH-20968 was similar issue with likely the same fix - wrapper cannot only decide on the fact if transaction is present, but also that context type is transactional.

Comment by pdudits [ 25/Jan/16 ]

Fix submitted to Payara under https://github.com/payara/Payara/pull/617. I've got CLA for glassfish signed as well, feel free to apply the patch.





[GLASSFISH-21438] java.lang.NoClassDefFoundError: javax/xml/parsers/ParserConfigurationException Created: 09/Oct/15  Updated: 30/Nov/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: grantjennings Assignee: Srini
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OSX 10.11



 Description   

This bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=463169

is in the release version of GF 4.1.1.

Eclipse Persistence Services - 2.6.1.v20150605
Bug was fixed in eclipselink on 2015-06-26

Applications dependent on moxy are undeployable.



 Comments   
Comment by Lvdberg [ 30/Nov/15 ]

Several attempts to get this working failed. Just moved back to 4.1....

Comment by khonraad [ 30/Nov/15 ]

Exactly the same problem here





[GLASSFISH-21535] The result of EntityManager.find() is not managed Created: 14/Apr/16  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: nabizamani Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
@Path("/employees")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
//@Stateless    //we can't use this because of bug in Glassfish 4.1, see http://stackoverflow.com/questions/25879898/glassfish-4-1-cant-run-restful-service-when-using-ear-ejb-web-module
@RequestScoped  //this is a workaround that works for us
public class Employees {
    
	@PersistenceContext(unitName = "myPU")
    private EntityManager em;
    
    @PUT
    @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
    @Path("/{empId}")
    public Response updateEmployeeFirstName(@NotNull @PathParam("empId") Long empId, @PathParam("firstName") String firstName) throws ParseException, JOSEException {
        Employee emp = em.find(Employee.class, empId);
    	if(emp != null){
    		System.out.println("em.contains(emp) ==> " + em.contains(emp)); //always false
    		emp.setFirstName(firstName);
    		//em.merge(emp);	//because emp is not managed this would be a workaround

    		//...
    	}else{
    		return Response.status(Status.NOT_FOUND).build();
    	}
    }
   
}

This issue is somehow related to https://java.net/jira/browse/GLASSFISH-20968, which is flagged as resolved - but that's false!

Dear Oracle team,
There are many GF issues open and many of the have a very high priority - these issues make GF even incompatible to the Java EE 7 spec!! Any other Java EE 7 server would have never been "certified" with all theses issues, especially because these issues break the Java EE 7 spec! Like another person mentioned in the other ticket "I still wonder if the TCK is so weak with regard to extended persistence context, or glassfish 4 was only declared passing it." How can this happen?

This issue is a blocker as it is breaking Java EE compliance! Furthermore, people who want to learn JPA, Java EE etc. will be confused a lot and might get a wrong impression of Java EE!



 Comments   
Comment by nabizamani [ 14/Apr/16 ]

Also see http://stackoverflow.com/questions/21356448/jpa-entity-found-by-find-in-a-stateful-ejb-extended-is-not-managed

Comment by nabizamani [ 14/Apr/16 ]

Little mistake: the parameter firstName does not come from @PathParam("firstName"). Instead it comes from a FormParam...





[GLASSFISH-21337] java.util.ConcurrentModificationException on Multitenant enviroment Created: 25/Mar/15  Updated: 05/Apr/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0, 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: dyego Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows , JDK 8, 4GB of ram, persistence.xml:

<persistence-unit name="My-ejbPU" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/mybase</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<shared-cache-mode>NONE</shared-cache-mode>
<validation-mode>NONE</validation-mode>
<properties>
<property name="javax.persistence.validation.group.pre-persist" value="javax.validation.groups.Default"/>
<property name="javax.persistence.validation.group.pre-update" value="javax.validation.groups.Default"/>
<property name="hibernate.validator.autoregister_listeners" value="false"/>
<property name="eclipselink.logging.level.sql" value="FINE"/>
<property name="eclipselink.logging.parameters" value="true"/>
<property name="eclipselink.multitenant.tenants-share-cache" value="true"/>
<property name="eclipselink.multitenant.tenants-share-emf" value="true"/>
<property name="eclipselink.target-database" value="MySQL"/>
<property name="eclipselink.cache.shared.default" value="true"/>
</properties>
</persistence-unit>



 Description   

On Multitenant TABLE_SUFIX enviroment, if you create a servlet to read image from database (for example) and your page CALL this servlet many times in one page (a gallary for example) the simultaneos call of jpa from a servlet you will recive :

Advertência: javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean
at com.sun.ejb.containers.EJBContainerTransactionManager.checkExceptionClientTx(EJBContainerTransactionManager.java:662)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:507)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy246.getStorages(Unknown Source)
at myservice.service.filestorage._EJB31_GeneratedFileStorageRepositoryIntf__Bean_.getStorages(Unknown Source)
at myservice.service.filestorage.FileStorageService.getFile(FileStorageService.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.service.log.LogInterceptor.classInterceptor(LogInterceptor.java:101)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.service.log.ContextInterceptor.classInterceptor(ContextInterceptor.java:43)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.interceptor.ServiceRegionalizeInterceptor.intercept(ServiceRegionalizeInterceptor.java:60)
at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy351.getFile(Unknown Source)
at myservice.service.filestorage._EJB31_GeneratedFileStorageServiceIntf__Bean_.getFile(Unknown Source)
at myservice.control.imagegallery.ImageGalleryServlet.processRequest(ImageGalleryServlet.java:50)
at myservice.control.imagegallery.ImageGalleryServlet.doGet(ImageGalleryServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at myservice.servlet.TenantFilter.doFilter(TenantFilter.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at myservice.servlet.NavigationHistoryFilter.doFilter(NavigationHistoryFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:412)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
at org.eclipse.persistence.descriptors.ClassDescriptor.notifyReferencingDescriptorsOfIsolation(ClassDescriptor.java:3921)
at org.eclipse.persistence.descriptors.CachePolicy.postInitialize(CachePolicy.java:177)
at org.eclipse.persistence.descriptors.ClassDescriptor.postInitialize(ClassDescriptor.java:3909)
at org.eclipse.persistence.internal.sessions.AbstractSession.updateTablePerTenantDescriptors(AbstractSession.java:1401)
at org.eclipse.persistence.sessions.server.ClientSession.<init>(ClientSession.java:136)
at org.eclipse.persistence.internal.sessions.IsolatedClientSession.<init>(IsolatedClientSession.java:38)
at org.eclipse.persistence.sessions.server.ServerSession.acquireClientSession(ServerSession.java:386)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(EntityManagerImpl.java:1933)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActiveSession(EntityManagerImpl.java:1232)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActiveSessionIfExists(EntityManagerImpl.java:1247)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.<init>(EJBQueryImpl.java:102)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.<init>(EJBQueryImpl.java:86)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.createQuery(EntityManagerImpl.java:1603)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createQuery(EntityManagerWrapper.java:456)
at myservice.service.LinkEntityManager.createQuery(LinkEntityManager.java:165)
at myservice.service.base.BaseRepository.getList(BaseRepository.java:73)
at myservice.service.filestorage.FileStorageRepository.getStorages(FileStorageRepository.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.service.log.LogInterceptor.classInterceptor(LogInterceptor.java:101)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.service.log.ContextInterceptor.classInterceptor(ContextInterceptor.java:43)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at myservice.interceptor.ServiceRegionalizeInterceptor.intercept(ServiceRegionalizeInterceptor.java:60)
at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 99 more



 Comments   
Comment by dyego [ 03/Apr/15 ]

This is a wclipselink BUG please close

Comment by Romain Grécourt [ 03/Apr/15 ]

can you share a link to the bug ?

Comment by dyego [ 05/Apr/15 ]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=463737

Very strange e important bug for multi tenant users





[GLASSFISH-21164] On deploy jpa validation Eclipselink do not recognize entity class if has lambda expressions inside a method Created: 13/Aug/14  Updated: 29/Jun/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: fantarama Assignee: Srini
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java jdk 1.8_05


Tags: eclipselink, jpa

 Description   

During deploy process if a jpa entity (@Entity) in one of his methods has a java 8 lambda expression the entity is not recognized has a jpa entity and skipped. This cause validation error during deployment if the entity is in relation with others.



 Comments   
Comment by Hong Zhang [ 13/Aug/14 ]

assign to persistence team for evaluation

Comment by Lukas Jungmann [ 13/Aug/14 ]

this is fixed in EclipseLink 2.6.0, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=429992 GF currently uses 2.5.2

Comment by fantarama [ 13/Aug/14 ]

Thanks, but is there a future plan to update GF to 2.6.0? Any workaround to be able to deploy the application?

Comment by caricsvk [ 22/May/15 ]

Eclipselink 2.6.0 is already shipped out (March 10, 2015). When do we expect to have it in glassfish nightly?

Comment by heruan [ 29/Jun/15 ]

EclipseLink 2.5.2 which is currently bundled with Glassfish 4.1 has major bugs such as ignored injection on EntityListeners and others. Update to EclipseLink 2.6.0 should be somehow planned with a milestone, but I can't find any reference on the roadmap.





[GLASSFISH-18699] Thread hang at ConcurrencyManager.releaseDeferredLock() Created: 08/May/12  Updated: 08/May/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: kokwei Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SPARC Solaris 5.8, Java(TM) SE Runtime Environment (build 1.6.0_30-b12), Toplink Essentials 2.1-b31g-fcs (10/19/2009), Glassfish v2.1-b60e-sunos



 Description   

We have a solution running in the client's Production environment. Under heavy load, the entire Glassfish Application Server instance will come to a halt with > 1000 threads in TIMED_WAITING (sleeping) state. The solution we have at the moment is to restart the entire application server which is a major problem in a Production environment.

Symptoms of the problem:
1) With nightly Glassfish restart:
a) Thread hang happens once every fortnight, or even up to 3 weeks.
2) Without nightly Glassfish restart:
a) Thread hang happens minimally twice a day, which translates to twice downtime during business hours
3) When system comes to a halt, a JVM head dump shows many threads of the following (with stacktrace):

java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at oracle.toplink.essentials.internal.helper.ConcurrencyManager.releaseDeferredLock(ConcurrencyManager.java:429)
at oracle.toplink.essentials.internal.identitymaps.CacheKey.releaseDeferredLock(CacheKey.java:373)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:614)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:451)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:421)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:387)
at oracle.toplink.essentials.queryframework.ReportQueryResult.processItem(ReportQueryResult.java:220)
at oracle.toplink.essentials.queryframework.ReportQueryResult.buildResult(ReportQueryResult.java:182)
at oracle.toplink.essentials.queryframework.ReportQueryResult.<init>(ReportQueryResult.java:98)
at oracle.toplink.essentials.queryframework.ReportQuery.buildObject(ReportQuery.java:594)
at oracle.toplink.essentials.queryframework.ReportQuery.buildObjects(ReportQuery.java:643)
at oracle.toplink.essentials.queryframework.ReportQuery.executeDatabaseQuery(ReportQuery.java:804)
at oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:628)
at oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:692)
at oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:746)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2248)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:952)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:924)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:367)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getResultList(EJBQueryImpl.java:478)
at com.sun.enterprise.util.QueryWrapper.getResultList(QueryWrapper.java:196)

Information on Software components being used:
1) Glassfish v2.1-b60e-sunos
2) Toplink essentials in $GLASSFISH_HOME/lib - 2.1-b60e-fcs (12/23/2008)
3) Toplink essentials packaged in our applications lib - 2.1-b31g-fcs (10/19/2009) <-- extracted from GFv2.1.1

Workarounds we have tried:
1) Referred to similar issue at http://java.net/jira/browse/GLASSFISH-4689
2) Implemented a SessionCustomizer that sets setCacheTransactionIsolation to CONCURRENT_READ_WRITE, the thread hang still happens

Would like to know if anyone is facing similar issue as above. We have so far been unable to re-produce in our test environments. We have also considered upgrading to EclipseLink but without the ability to re-produce we are rather sceptical that the problem would be addressed as we have no way to confirm it.






[GLASSFISH-9567] Need Probes for JPA Created: 17/Sep/09  Updated: 05/Jul/11

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Nazrul Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,567
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude

 Description   

Tracking bug.

We need probes for JPA (glassfish:jpa::).

References
----------
Dashboard: http://appserver.sfbay.sun.com/Wiki.jsp?page=GFv3ProbesDashboard



 Comments   
Comment by Nazrul [ 17/Sep/09 ]

Adding Prashanth to CC list

Comment by Mitesh Meswani [ 28/Sep/09 ]

Deferring to V3.1

Comment by kumara [ 03/Oct/09 ]

Will be addressed in the next release.

Comment by Mitesh Meswani [ 07/Oct/10 ]

Targeting for future release





[GLASSFISH-413] Need to improve DISTINCT EJBQL processing Created: 15/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: gyorke Assignee: gyorke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 413

 Description   

A solution for JPQL DISTINCT was implemented but a full analysis anf resolution
was not completed at the time. JPQL DISTINCT support should be readdressed
providing a thorough and more performant solution



 Comments   
Comment by marina vatkina [ 15/Mar/06 ]

Need more info

Comment by gyorke [ 16/Mar/06 ]

Code elements with tag: GF_ISSUE_395 should be re-evaluated as part of this bug.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1917] setFirstResult and setMaxResults should make use of SQL range constraints Created: 05/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,917

 Description   

Some platforms, e. g. SQLAnywhere, support SQL range constraints like:

select TOP 5 START 25 * from mytable ORDER BY mycolumn

(Actually SQLAnywhere allows START only if TOP is specified, and TOP only if
ORDER BY is specified!)

Currently TopLink doesn't forward setFirstResult and setMaxResults to the
database server, but tries to solve this constraints on its own. It could lead
to improved performance, if instead START and TOP would be forwarded to the
database server: The server then is in the best position to optimize at most.

It would be great if this optional feature would be provided. I would be the
first one to implement support for it into the SQLAnywherePlatform (as long as
the TopLink core takes respect of the fact that START and TOP only are valid
while ORDER BY is used).



 Comments   
Comment by tware [ 05/Jan/07 ]

This same feature was requested on the Persistence mailing list. See a copy of
the email below:

Whether use methods:
>
>javax.persistence.Query.setFirstResult(int) and
>javax.persistence.Query.setMaxResults(int)
>
>such RDBMS-featured as operators SELECT... OFFSET X LIMIT Y?
>
>Their execution performance shows that is not present.
>
>Whether realization of it even for separate RDBMS is possible?

Comment by marina vatkina [ 05/Jan/07 ]
      • Issue 1825 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 05/Jan/07 ]

Changing the priority to that of 1825 which was closed as a duplicate

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1819] Serious limitation on entity relationships w/ composite keys Created: 20/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: zambizzi Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?forumID=56&threadID=20604


Issuezilla Id: 1,819

 Description   

Apparently the Java EE spec doesn't completely specify how relationships between
entities that have composite primary and foreign keys should be handled.

In Glassfish using Toplink, if there are two entities that both have composite
primary keys and they do not match perfectly, they cannot be joined together
in a @OneToMany or @ManyToOne relationship without throwing an exception.

For example, if entityA has a composite key made up of three fields, e.g. key1,
key2, key3....and entityB has as composite PK w/ two fields, key1 and key2 - a
@OneToMany with @JoinColumns(

{@JoinColumn(...), @JoinColumn(...)}

) always
results in a oracle.toplink.essentials.exceptions.ValidationException.

I would provide an use-case but apparently this issue is already well
known...and code snippets & examples, plus detailed explanations can all be
found on this post in the GF forums:

http://forums.java.net/jive/thread.jspa?forumID=56&threadID=20604

This issue of legacy data that has tables w/ multiple (sometimes unmatched)
primary and foreign keys is quite common. Hibernate handles this scenario
without a problem...so it only stands to reason that Toplink should also be able
to handle it.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1081] Using entity class with @ManyToOne(fetch = FetchType.LAZY) as session bean method return value produce serialization exception Created: 05/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: hazurek Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,081

 Description   

There are two classes with many-to-one relationship (it is
implemented as LAZY):

public class City implements Serializable
{
....
@ManyToOne(fetch = FetchType.LAZY)
public Region getRegion()
{
return region;
}

@Entity
@Table(name = "AO_REGION")
public class Region implements Serializable
{
...
}

City object is used as return value of session bean:

@Stateless
public class FacadeBean implements Facade
{
...
public City getCityById(int cityId)
{
return em.find(City.class, cityId);
}
...
}

So calling method getCityById from client generates exception:

Caused by: java.io.IOException: Mismatched serialization UIDs : Source (Rep.
IDRMI:ru.amfitel.test.bean.City:B1E9E01D2BAAFA14:AE31789539030075) =
AE31789539030075 whereas Target (Rep. ID
RMI:ru.amfitel.test.bean.City:657A6D7B12B930E8:9E8761A15FE9F9ED) =
9E8761A15FE9F9ED
at com.sun.corba.ee.impl.util.RepositoryId.useFullValueDescription
(RepositoryId.java:573)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.useFullValueDescription
(ValueHandlerImpl.java:386)
....

This can be worked around by defining field serialVersionUID in class City.
But this is not expected by spec, as it is said that (#2.1 of spec):

If an entity value is to be passed by value as detached object (e.g., through a
remote interface), the entity class must implement the Serializable interface.

There is nothing about serialVersionUID field.



 Comments   
Comment by hazurek [ 05/Sep/06 ]

Summary field is changed.

Comment by hazurek [ 06/Sep/06 ]

http://forums.java.net/jive/thread.jspa?threadID=2595&start=15&tstart=15#150038

Comment by pkrogh [ 14/Nov/06 ]

This is likely because lazy is done by dynamically weaving. The jars on the
client should also be woven (using the java agent). Or static weaving could be
done on both the client and the server.

Comment by hazurek [ 15/Nov/06 ]

What do you mean by 'weave'? I've try to get detached instance from Session
Bean to client(JUnit) and got an exception. When fetch = FetchType.EAGER all is
working, but when fetch = FetchType.LAZY exception is got. I have not even try
to access lazy field. What must I do to avoid this? What is wrong?

Comment by pkrogh [ 15/Nov/06 ]

This error is occuring because The classes are being woven for the lazy case,
and different versions of classes are created.

Because of this, the spec states that serialization is only supported if the
provider is on the client.

TopLink Essentials also requires that the client be started with the agent.

Changing the type to ENHANCEMENT.

Comment by hazurek [ 30/Nov/06 ]

But what is about:
3.2.4.2 Detached Entities and Lazy Loading
Serializing entities and merging those entities back into a persistence context
may not be interoperable
across vendors when lazy properties or fields and/or relationships are used.
A vendor is required to support the serialization and subsequent
deserialization and merging of detached
entity instances (which may contain lazy properties or fields and/or
relationships that have not been
fetched) back into a separate JVM instance of that vendor's runtime, where both
runtime instances have
access to the entity classes and any required vendor persistence implementation
classes.
When interoperability across vendors is required, the application must not use
lazy loading.

As I understand the behaviour that I described must be legal.
Please, somebody explain me what I'm doing wrong and how can I get entities
with lazy relations to standalone client.
Thank you.

Comment by pkrogh [ 01/Dec/06 ]

The important line is: "... back into a separate JVM instance of that vendor's
runtime, where both runtime instances have access to the entity classes and any
required vendor persistence implementation classes."

In this case the runtime classes on the client need to be woven with the agent.

Comment by hazurek [ 04/Dec/06 ]

Yes, I'm using separate JVM with my client app. But I do not want to
make lazy loading working on my client side. All that I want is to not
get an Exception when getting entity with lazy relationship on client.
So I want to get entity with partly initialized properties.
As I understand from
http://forums.java.net/jive/thread.jspa?threadID=2595&start=0&tstart=0#91679
it is possible. So what is wrong?

Comment by Sanjeeb Sahoo [ 04/Dec/06 ]

Raising the priority of this bug. It is a spec violation. The usecase is like this:
ear
lib/common.jar (contains City.class, Region.class, Facade.class.)
ejb.jar (contains FacadeBean.class and persistence.xml)
appclient.jar (contains Client.class)

City has a lazy mant to one relationship wih Region. While launching the
appclient, we get a CORBA marshall error that says mismatched serialization UIDs.

There is no way user can pass javaagent option to appclient container. There is
no need because the client is not trying to use the lazily fetched fields.

This is causing a lot of inconvenience to user. Please look into this ASAP.

– Sahoo

Comment by Sanjeeb Sahoo [ 04/Dec/06 ]

Changing it to a defect from enhancement.

– Sahoo

Comment by ijuma [ 07/Dec/06 ]

Adding myself to cc list.

Comment by pkrogh [ 08/Dec/06 ]

There is currently no spec endorsed way to serialize outside of the vendor.
This is an ENHANCEMENT.

This is an impotant ENHANCEMENT. Leaving at sev 2.

Comment by hazurek [ 10/Dec/06 ]

I've tried to use webapp deployed at Glassfish as client and got the same
exception. So this occurs also when using client of the same vendor.

Comment by tware [ 16/Jan/07 ]

In the absence of the ability to use an agent on the client, you should the
TopLink Essentials Static Weaving feature with the classes you deploy on the
client. To find instructions, go to the following link:

http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#LazyLoading

And look at the sections entitles: "Static Weaving Using the StaticWeave Class
on the Command Line" and "Static Weaving Using the weave Ant Task".

You can then package the weaved classes on your client and serialization should
be successful. This step puts the client VM into the state of being a "JVM
instance of that vendor's runtime" as mentioned by the specification.

Comment by tware [ 19/Jan/07 ]

See:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=2101

for an issue with static weaving and a workaround

Comment by vr143562 [ 06/Feb/07 ]

Using Glassfish build 33a here are some observations/corrections:
1. The class specified in step 2 of
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#StaticWeaving
should be oracle.toplink.essentials.weaving.StaticWeave
instead of oracle.toplink.weaving.StaticWeave
2. (Please confirm this) Along with toplink-essentials.jar; xercesImpl.jar also
needs to be in path. With glassfish, xercesImpl.jar is available under
<glassfish-install-location>/lib/ant/

Comment by vr143562 [ 06/Feb/07 ]

added myself to the interest list

--varun.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1434] Dynamic discovery of JDBC driver capabilities Created: 06/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: New Feature Priority: Critical
Reporter: bjb Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-1433 getMaxFieldNameSize should be dynamic Open
blocks GLASSFISH-1432 java2db not generating proper column ... Open
Issuezilla Id: 1,434

 Description   

At initialisation the session creatop,
(oracle.toplink.essentials.internal.sessions.AbstractSession ?) should include a
common "facility" to enable platform generic setup of JDBC sessions (based on
JDBC drivers metadata).

This facility will detect the database once (initialisation ?) and will then be
accessible from the Platform object (cf. shouldXXX).



 Comments   
Comment by bjb [ 06/Nov/06 ]

Blocking implementation of issue 1435 : getIdentifierQuoteString()

Will enable implementation of shouldEscapeName()

Comment by bjb [ 06/Nov/06 ]

Blocking implementation of issue 1433 : getMaxFieldNameSize()

Will enable one shot detection.

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-701] Sequence generator conflicts with existing primary key values Created: 02/Jun/06  Updated: 01/Nov/12

Status: Reopened
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: future release

Type: New Feature Priority: Critical
Reporter: craig_mcc Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 701

 Description   

When I build a persistence unit for a set of entity classes that correspond to
an existing database (again, in my case, I was using the TRAVEL example database
that ships with Creator 2 Update 1), I wanted to take advantage of the ability
to autogenerate primary key values. When I deployed an application using these
classes the first time, it created a SEQUENCE table for me (good). But the
starting value it stored in the SEQ_COUNT column was within a range of primary
key values that were used by existing rows in the database (bad), so I got a
"duplicate key" error the first time I tried to insert a new row.

Workaround is to manually adjust the stored sequence number to something larger
than the highest used key in any of the existing tables represented in this
persistence unit. But that is something the JPA architecture should do for me,
so I don't have to.



 Comments   
Comment by marina vatkina [ 07/Jun/06 ]

Hmmm... I'm confused... If you map entities to existing tables, we do not add
any more tables to the mapping, and your SEQUENCE table should already exist. If
you use java2db functionality to create or drop-and-create tables, the new tables
will be created and no pre-existing data should be found in them.

Can you please check?

Comment by marina vatkina [ 13/Jun/06 ]

Looks for me as a user error - the use of create-tables with existing tables.
If this is not the case, please provide a reproduceable test case and reopen the
issue

Comment by craig_mcc [ 14/Jul/06 ]

The use case was listed in the original report, but the important issues are
summarized again here:

  • The data tables already existed, because they were created
    for a previously existing application (in this case the database
    involved is the Travel Center example database that is shipped
    with Sun Java Studio Creator.
  • The SEQUENCE table did not previously exist, because this is the
    first time that these data tables were being accessed via a
    JPA persistence unit.
  • The first time an application is deployed using JPA to access these
    tables, a SEQUENCE table was created. However, no attempt was made
    to ensure that the sequence numbers about to be generated would not
    conflict with primary key values that were already assigned by the
    previous applications that populated these data tables.
  • As a result, any attempt to add a new row in any table supported by
    a JPA entity class runs the risk of creating a collision on a primary
    key value. Since a large number of potential uses for Glassfish
    involves creating JPA entity classes to work with existing database
    tables, this is definitely a sub-optimal result.

This is a P2 only because there is a workaround – go in with the command
console for the database in use and manually tweak the SEQ_COUNT value in the
one and only row of the SEQUENCE table. But that is not a user-friendly solution.

An upcoming version of Creator will feature support for JPA entity classes. I
am not interested in apologizing for this functionality in the underlying database.

Craig McClanahan
Architect, Java Studio Creator

Comment by Sanjeeb Sahoo [ 15/Jul/06 ]

Added myself to cc-list

Comment by ijuma [ 17/Jul/06 ]

Adding myself to cc list.

Comment by marina vatkina [ 17/Jul/06 ]

I feel that there is a disconnect here. You think that there is a bug in an
interesting feature - adding a SEQUENCE table to an existing set of tables, and
I'm saying that such feature does not exist: we either create all of the tables
(or at least try to), or use existing set of tables.

Please check your persistence.xml - does it have property
"toplink.ddl-generation" set to either "drop-and-create-tables" or
"create-tables"?

  • If not, no tables will be created at deployment. No exceptions.
  • If yes, all of them will be created (or at least attempted), again without any
    exception. Which means that those tables which names conflict with the existing
    ones will fail to be created, and those that don't (SEQUENCE in your case) will
    succeed.
    If you still have the server.log around, you should see error messages about
    failed statement execution. Those errors are also (unless there is another bug)
    displayed in the output of the asadmin deploy command.

While partial table creation is an interesting feature, it's not a bug in the
current implementation. Do you want to keep it as a feature request, or change
to a doc bug to add a warning to our docs about possible side effects of using
auto DDL generation?

Meanwhile I'm downgrading the bug.

Regards,
-marina

Comment by craig_mcc [ 17/Jul/06 ]

Yes, the persistence unit was set for create tables – deleting the existing
production tables would not have been a good thing. Yes, SEQUENCE is the only
table that was created; all the rest failed because the tables already existed.

However, the initial sequence number was set to a value such that, on the very
first attempt to insert a new row, I got a duplicate primary key error. Whose
fault was that? It sure isn't the developer's fault that their persistence
framework was not smart enough to recognize it was being configured (for the
first time) on data tables that already head existing rows.

Given that the vast majority of people who try JPA for the first time are going
to be dealing with existing database tables, I am not the only person who is
going to run into this problem. Sounds like I need to go over your head and
lean on Tony a bit to get this issue paid attention to, so that's what I'll do next.

Craig

Comment by marina vatkina [ 25/Jul/06 ]

Feature request

Comment by marina vatkina [ 06/Sep/06 ]

The requested feature will not be spec compliant if implemented by default (i.e.
without any extra hint or vendor specific annotation). Users of such
applications will not know that they are relying on a vendor-specific behavior.

The spec requires (see 9.1.37) that SEQUENCE has an initial value of 1 if the
initialValue is not specified. Does specifying the initialValue in the
annotation solves your problem?

Regards,
-marina

Comment by craig_mcc [ 06/Sep/06 ]

> The requested feature will not be spec compliant if implemented by default (i.e.
> without any extra hint or vendor specific annotation). Users of such
> applications will not know that they are relying on a vendor-specific behavior.

Wow, that's a pretty horrible spec bug, then. I'll forward a pointer to this to
the JSR-220 expert grup.

> The spec requires (see 9.1.37) that SEQUENCE has an initial value of 1 if the
> initialValue is not specified. Does specifying the initialValue in the
> annotation solves your problem?

No.

Consider a scenario where I am building an app in a big enterprise installation
that has multiple stagings for deploying an updated version of an existing app
(test, staging, and production). What are the chances that any single
initialValue will be appropriate for all of them? What happens when I redeploy
later and the "used" values have changed?

As it is, the only thing I can see the developer doing is going into the
SEQUENCE table with a SQL console, and manually changing the value. That means
several things:

  • They have to understand the cause of this problem in the first place.
  • They have to understand how to construct an appropriate SQL UPDATE
    statement.
  • They have to undertand how to use a SQL command tool to update the
    SEQUENCE table, which is implementation specific.

That is not an appropriate solution for a Java EE 5 release that bills itself
as being focused on ease of use.

Craig McClanahan

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Mitesh Meswani [ 01/Nov/12 ]

Not targeting for 4.0.

I think a RFE should be filled against JPA spec to discuss this further.





[GLASSFISH-16527] EclipseLink second level cache coordination using GMS as transport layer Created: 02/May/11  Updated: 01/Nov/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Critical
Reporter: Mitesh Meswani Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is a placeholder for work that needs to be done to implement the feature as described in persistence one pager here.

https://wikis.oracle.com/display/GlassFish/3.2Persistence#3.2Persistence-4.1.1%5C%26nbsp%3BEclipseLinksecondlevelcachecoordinationusingGMSastransportlayer



 Comments   
Comment by Mitesh Meswani [ 01/Nov/12 ]

Not doing for 4.0





[GLASSFISH-21195] CDI Injection in Entity Listener - NullPointerException Created: 15/Sep/14  Updated: 04/Aug/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: emresindir Assignee: Srini
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I just up to date glassfish 4.0 to 4.1. When inject cdi bean in entity listener, i get NullPointerException.

Excetion Details:
java.lang.NullPointerException
at org.eclipse.persistence.internal.sessions.cdi.EntityListenerInjectionManagerImpl.createEntityListenerAndInjectDependancies(EntityListenerInjectionManagerImpl.java:55)
at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListener.createEntityListenerAndInjectDependancies(EntityListener.java:137)
at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListener.constructListenerInstance(EntityListener.java:151)
at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListener.getListener(EntityListener.java:234)
at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListener.invokeMethod(EntityListener.java:350)
at org.eclipse.persistence.internal.jpa.metadata.listeners.EntityListener.prePersist(EntityListener.java:449)
at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyListener(DescriptorEventManager.java:748)
at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyEJB30Listeners(DescriptorEventManager.java:674)
at org.eclipse.persistence.descriptors.DescriptorEventManager.executeEvent(DescriptorEventManager.java:229)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectClone(UnitOfWorkImpl.java:4316)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNotRegisteredNewObjectForPersist(UnitOfWorkImpl.java:4293)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.registerNotRegisteredNewObjectForPersist(RepeatableWriteUnitOfWork.java:518)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4235)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:496)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:287)

Details:

public class MyEntityListener {

@Inject
UserSession userSession;

@PrePersist
public void prePersist(AbstractEntity entity)

{ UserOrganization organizastion = userSession.getUserOrganization(); //... //... }

@PreUpdate
public void preUpdate(AbstractEntity entity)

{ //... }

@PreRemove
public void preRemove(AbstractEntity entity)

{ //... }

}



 Comments   
Comment by emresindir [ 15/Sep/14 ]

My project works fine with Glassfish 4.0 but Glassfish 4.1 not. Actually i don't get any lifecycle exception when i deploy. And also i can inject my "UserSession" CDI bean anywhere, except EntityListener.

Edit
-----------------
OS: Linux Mint 17 Qiana (Cinnamon)
Java: JDK 1.7.0.60
IDE: Netbeans 8.0.1

Comment by azuchi [ 22/Sep/14 ]

I was just hit by that same issue too. (Ubuntu 14.04 LTS, JDK 1.8.0_05-b13.)
Works fine with Glassfish 4.0.

Comment by chzbrgla [ 23/Sep/14 ]

I am getting NullPointerException when injecting into an @EntityListener

It used to work on gf4.0, but is not working on gf4.1.

Ubuntu 14.04 LTS; JDK 1.7.0_67-b01

Comment by drame1499 [ 24/Sep/14 ]

Same Problem here. Glassfish 4.1 Build 13 on Ubuntu Server 14.04, JDK 1.7.0_67 Server 64Bit.

Comment by smillidge-c2b2 [ 24/Feb/15 ]

I suspect this is due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=438105 which was introduced in Eclipselink 2.5.2

Comment by jjsnyder83 [ 24/Mar/15 ]

I don't think this has anything to do with CDI so changing the component.

Comment by heruan [ 03/Aug/15 ]

Is this really due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=438105 ? Because that's closed but the issue persists.
I am not able to inject any @Context singleton in EntityListeners.

Comment by payara_steve [ 04/Aug/15 ]

AFAIK the EclipseLink version this is fixed in hasn't been released yet. Try the latest Payara Download http://payara.co.uk/downloads this has a patched EclipseLink jar with the specific bug fixed. If that works for you then the next EclipseLink version should work on GlassFish.

Comment by payara_steve [ 04/Aug/15 ]

Oops should check before I comment. The fix was in Eclipselink 2.6 so I would imagine this is fixed in GlassFish nightly.

Comment by drame1499 [ 04/Aug/15 ]

I do not experience this bug since upgrading to 2.6.0. I replaced the eclipselink osgi-modules in glassfish/modules with the 2.6.0 Version. Do not forget to delete /domains/domain1/osgi-cache after replacing osgi-modules. You can download the 2.6 Version here http://www.eclipse.org/eclipselink/downloads/index.php#2.6





[GLASSFISH-21161] NoClassDefFound on @Converter when inside a EJB JAR Created: 10/Aug/14  Updated: 07/Sep/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: atrajano Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

I have an attribute converter that converts Joda-Time LocalDate to a String

@Converter(autoApply = true)
public class LocalDateConverter implements
AttributeConverter<LocalDate, String> {

@Override
public String convertToDatabaseColumn(final LocalDate localDate) {
if (localDate == null)

{ return null; }
return localDate.toString();
}

@Override
public LocalDate convertToEntityAttribute(final String dbData) {
if (dbData == null) { return null; }

return LocalDate.parse(dbData);
}
}

And I have a @Singleton @Startup bean that has a @PostConstruct that fails because of a NoClassDefFound error for org.joda.time.LocalDate when working with an @PersistenceContext. However, if I don't use the entity manager org.joda.time.LocalDate resolves correctly and I can invoke its methods including .now()

If I put it in the WAR I have a different issue in that it says the web container has not started.



 Comments   
Comment by atrajano [ 10/Aug/14 ]

After looking a bit further, it appears that the classloader for converters do not use the same classpath as the EJB itself. So basically @Converter does not work at all when it is defined in an EJB JAR.

Comment by atrajano [ 10/Aug/14 ]

I have taken out the @Converter and everything works as expected.

Comment by Sanjeeb Sahoo [ 11/Aug/14 ]

From your comments it's clear that it's JPA entity manager module which is not using correct class loader to load org.joda.time.LocalDate.class. So, reassigning this to enity-persistence module to investigate. I strongly recommend attaching a test case and describing how you have packaged jodatime library.

Comment by atrajano [ 16/Aug/14 ]

Further experiments show that Converters function as expected for WAR only deployments, but not for EAR deployments.

WAR only example
https://github.com/trajano/jodatime-jpa-converter-example/tree/still-working

EAR which failed
https://github.com/trajano/jodatime-jpa-converter-example/tree/ear-fails

EAR which failed but works on Wildfly 8 is on master
https://github.com/trajano/jodatime-jpa-converter-example/

Comment by atrajano [ 16/Aug/14 ]

Relevant stack trace lines

Caused by: java.lang.NoClassDefFoundError: org/joda/time/LocalDate
	at net.trajano.example.jpa.LocalDateConverter.convertToDatabaseColumn(LocalDateConverter.java:1)
	at org.eclipse.persistence.internal.jpa.metadata.converters.ConverterClass.convertObjectValueToDataValue(ConverterClass.java:88)
	at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.getFieldValue(AbstractDirectMapping.java:776)
	at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.writeFromObjectIntoRow(AbstractDirectMapping.java:1281)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildRow(ObjectBuilder.java:1394)
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildRow(ObjectBuilder.java:1382)
	at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.insertObjectForWrite(DatabaseQueryMechanism.java:450)
	at org.eclipse.persistence.queries.InsertObjectQuery.executeCommit(InsertObjectQuery.java:80)
	at org.eclipse.persistence.queries.InsertObjectQuery.executeCommitWithChangeSet(InsertObjectQuery.java:90)
	at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:300)
	at org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
	at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
	at org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:798)
	at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
	at org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
	at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1730)
	at org.eclipse.persistence.internal.sessions.CommitManager.commitNewObjectsForClassWithChangeSet(CommitManager.java:226)
	at org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:125)
	at org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4200)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1439)
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithPreBuiltChangeSet(UnitOfWorkImpl.java:1585)
	at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:452)
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:846)
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.flush(EntityManagerWrapper.java:437)
	at net.trajano.example.jpa.AddEjb.addSomething(AddEjb.java:24)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
	... 85 more
Caused by: java.lang.ClassNotFoundException: org.joda.time.LocalDate
	at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:830)
	at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:744)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
Comment by atrajano [ 07/Sep/14 ]

I found a work around which was to put the converters in a separate JAR file and add it into the WEB-INF/lib folder. This work around works with both Glassfish and WildFly





[GLASSFISH-21076] GF4 ignores the new org.glassfish.ejb.persistent.timer.TimerState class provided in the JPA persistence.xml configuration Created: 28/May/14  Updated: 18/Sep/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: cistox Assignee: Srini
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OSs: Windows 7 Enterprise or Windows Server 2008 R2 Standard
Database: Microsoft SQL Server Version: 10.50.4266


Tags: 4_0_1-approved, EJB, JPA, Timer, TimerState

 Description   

During the deployment of an EAR that make use of the EJB Timer GF4 seems to be aware of the new class org.glassfish.ejb.persistent.timer.TimerState which is configured as part of the persistence.xml JPA configuration (see ejb-timer-service-app), but while loading the timer application the following exception is raised "Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob" which clearly evidences that GF4 is still searching the old TimerState class used until GF 3.1.2.2

Following is the relevant log for your review:

[2014-05-28T09:51:15.801+0200] [glassfish 4.0] [CONFIG] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.metadata] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263475801] [levelValue: 700] [[
The access type for the persistent class [class org.glassfish.ejb.persistent.timer.TimerState] is set to [FIELD].]]

[2014-05-28T09:51:15.832+0200] [glassfish 4.0] [INFO] [ejb.portable_jndi_names] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263475832] [levelValue: 800] [[
EJB5181:Portable JNDI names for EJB TimerBean: [java:global/ejb-timer-service-app/TimerBean, java:global/ejb-timer-service-app/TimerBean!org.glassfish.ejb.persistent.timer.TimerLocal]]]

[2014-05-28T09:51:15.957+0200] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263475957] [levelValue: 800] [[
Loading application [ejb-timer-service-app] at [/ejb-timer-service-app]]]

[2014-05-28T09:51:15.972+0200] [glassfish 4.0] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263475972] [levelValue: 800] [[
ejb.timer_service_started]]

[2014-05-28T09:51:15.972+0200] [glassfish 4.0] [INFO] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263475972] [levelValue: 800] [[
==> Restoring Timers ... ]]

[2014-05-28T09:51:16.004+0200] [glassfish 4.0] [INFO] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476004] [levelValue: 800] [[
EclipseLink, version: Eclipse Persistence Services - 2.5.0.v20130507-3faac2b]]

[2014-05-28T09:51:16.035+0200] [glassfish 4.0] [FINE] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476035] [levelValue: 500] [[
Detected database platform: org.eclipse.persistence.platform.database.SQLServerPlatform]]

[2014-05-28T09:51:16.050+0200] [glassfish 4.0] [CONFIG] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476050] [levelValue: 700] [[
connecting(DatabaseLogin(
platform=>DatabasePlatform
user name=> ""
connector=>JNDIConnector datasource name=>null
))]]

[2014-05-28T09:51:16.050+0200] [glassfish 4.0] [CONFIG] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476050] [levelValue: 700] [[
Connected: jdbc:sqlserver://10.5.6.136:1433;xopenStates=false;sendTimeAsDatetime=true;trustServerCertificate=false;sendStringParametersAsUnicode=true;selectMethod=direct;responseBuffering=adaptive;packetSize=8000;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=CSIPortal;applicationName=Microsoft SQL Server JDBC Driver;
User: CSIPortal
Database: Microsoft SQL Server Version: 10.50.4266
Driver: Microsoft SQL Server JDBC Driver 3.0 Version: 3.0.1301.101]]

[2014-05-28T09:51:16.050+0200] [glassfish 4.0] [CONFIG] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476050] [levelValue: 700] [[
connecting(DatabaseLogin(
platform=>SQLServerPlatform
user name=> ""
connector=>JNDIConnector datasource name=>null
))]]

[2014-05-28T09:51:16.144+0200] [glassfish 4.0] [CONFIG] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476144] [levelValue: 700] [[
Connected: jdbc:sqlserver://10.5.6.136:1433;xopenStates=false;sendTimeAsDatetime=true;trustServerCertificate=false;sendStringParametersAsUnicode=true;selectMethod=direct;responseBuffering=adaptive;packetSize=8000;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=true;databaseName=CSIPortal;applicationName=Microsoft SQL Server JDBC Driver;
User: CSIPortal
Database: Microsoft SQL Server Version: 10.50.4266
Driver: Microsoft SQL Server JDBC Driver 3.0 Version: 3.0.1301.101]]

[2014-05-28T09:51:16.238+0200] [glassfish 4.0] [INFO] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.connection] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476238] [levelValue: 800] [[
file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App login successful]]

[2014-05-28T09:51:16.269+0200] [glassfish 4.0] [FINE] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App.sql] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476269] [levelValue: 500] [[
SELECT "TIMERID", "APPLICATIONID", "BLOB", "CONTAINERID", "CREATIONTIMERAW", "INITIALEXPIRATIONRAW", "INTERVALDURATION", "LASTEXPIRATIONRAW", "OWNERID", "PKHASHCODE", "SCHEDULE", "STATE" FROM "EJB_TIMER_TBL" WHERE (("OWNERID" = ?) AND ("STATE" = ?))
bind => [instance1, 0]]]

[2014-05-28T09:51:16.284+0200] [glassfish 4.0] [WARNING] [] [org.eclipse.persistence.session.file:/C:/server/production/glassfish4/glassfish/nodes/localhost-domain1/instance1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476284] [levelValue: 900] [[

Local Exception Stack:
Exception [EclipseLink-66] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Could not deserialize object from byte array.
Internal Exception: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[blob-->EJB__TIMER__TBL.BLOB]
Descriptor: RelationalDescriptor(org.glassfish.ejb.persistent.timer.TimerState --> [DatabaseTable(EJB__TIMER__TBL)])
at org.eclipse.persistence.exceptions.DescriptorException.notDeserializable(DescriptorException.java:1230)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:75)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.getObjectValue(AbstractDirectMapping.java:614)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.valueFromRow(AbstractDirectMapping.java:1215)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.buildCloneFromRow(AbstractDirectMapping.java:203)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildAttributesIntoWorkingCopyClone(ObjectBuilder.java:1811)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneFromRow(ObjectBuilder.java:1958)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:726)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:629)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:587)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:571)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:782)
at org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:848)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:490)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1155)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimersByOwnerAndState(TimerBean.java:212)
at org.glassfish.ejb.persistent.timer.TimerBean.findActiveTimersOwnedByThisServer(TimerBean.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy264.findActiveTimersOwnedByThisServer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.restoreEJBTimers(PersistentEJBTimerService.java:369)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.resetEJBTimers(PersistentEJBTimerService.java:1400)
at com.sun.ejb.containers.EJBTimerService.initEJBTimerService(EJBTimerService.java:236)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:205)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:187)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:758)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:143)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:137)
at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandMultInMultOut(CommandResource.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)
Caused by: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.eclipse.persistence.exceptions.ConversionException.couldNotBeConvertedToClass(ConversionException.java:95)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:446)
at org.eclipse.persistence.internal.helper.ConversionManager.convertClassNameToClass(ConversionManager.java:799)
at org.eclipse.persistence.internal.helper.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:42)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:73)
... 133 more
Caused by: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1761)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1611)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:443)
... 141 more
]]

[2014-05-28T09:51:16.893+0200] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476893] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public java.util.Set org.glassfish.ejb.persistent.timer.TimerBean.findActiveTimersOwnedByThisServer()]]

[2014-05-28T09:51:16.893+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476893] [levelValue: 900] [[

javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy264.findActiveTimersOwnedByThisServer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.restoreEJBTimers(PersistentEJBTimerService.java:369)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.resetEJBTimers(PersistentEJBTimerService.java:1400)
at com.sun.ejb.containers.EJBTimerService.initEJBTimerService(EJBTimerService.java:236)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:205)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:187)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:758)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:143)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:137)
at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandMultInMultOut(CommandResource.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-66] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Could not deserialize object from byte array.
Internal Exception: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[blob-->EJB__TIMER__TBL.BLOB]
Descriptor: RelationalDescriptor(org.glassfish.ejb.persistent.timer.TimerState --> [DatabaseTable(EJB__TIMER__TBL)])
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:479)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimersByOwnerAndState(TimerBean.java:212)
at org.glassfish.ejb.persistent.timer.TimerBean.findActiveTimersOwnedByThisServer(TimerBean.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 86 more
Caused by: Exception [EclipseLink-66] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Could not deserialize object from byte array.
Internal Exception: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[blob-->EJB__TIMER__TBL.BLOB]
Descriptor: RelationalDescriptor(org.glassfish.ejb.persistent.timer.TimerState --> [DatabaseTable(EJB__TIMER__TBL)])
at org.eclipse.persistence.exceptions.DescriptorException.notDeserializable(DescriptorException.java:1230)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:75)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.getObjectValue(AbstractDirectMapping.java:614)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.valueFromRow(AbstractDirectMapping.java:1215)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.buildCloneFromRow(AbstractDirectMapping.java:203)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildAttributesIntoWorkingCopyClone(ObjectBuilder.java:1811)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneFromRow(ObjectBuilder.java:1958)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:726)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:629)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:587)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:571)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:782)
at org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:848)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:490)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1155)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
... 110 more
Caused by: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.eclipse.persistence.exceptions.ConversionException.couldNotBeConvertedToClass(ConversionException.java:95)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:446)
at org.eclipse.persistence.internal.helper.ConversionManager.convertClassNameToClass(ConversionManager.java:799)
at org.eclipse.persistence.internal.helper.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:42)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:73)
... 133 more
Caused by: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1761)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1611)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:443)
... 141 more
]]

[2014-05-28T09:51:16.893+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.org.glassfish.ejb.persistent.timer] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476893] [levelValue: 900] [[
ejb.timer_service_init_error
javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:748)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:698)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy264.findActiveTimersOwnedByThisServer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.restoreEJBTimers(PersistentEJBTimerService.java:369)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.resetEJBTimers(PersistentEJBTimerService.java:1400)
at com.sun.ejb.containers.EJBTimerService.initEJBTimerService(EJBTimerService.java:236)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:205)
at com.sun.ejb.containers.EJBTimerService.getEJBTimerService(EJBTimerService.java:187)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:758)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:143)
at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:137)
at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandMultInMultOut(CommandResource.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-66] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Could not deserialize object from byte array.
Internal Exception: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[blob-->EJB__TIMER__TBL.BLOB]
Descriptor: RelationalDescriptor(org.glassfish.ejb.persistent.timer.TimerState --> [DatabaseTable(EJB__TIMER__TBL)])
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:479)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimersByOwnerAndState(TimerBean.java:212)
at org.glassfish.ejb.persistent.timer.TimerBean.findActiveTimersOwnedByThisServer(TimerBean.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 86 more
Caused by: Exception [EclipseLink-66] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Could not deserialize object from byte array.
Internal Exception: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[blob-->EJB__TIMER__TBL.BLOB]
Descriptor: RelationalDescriptor(org.glassfish.ejb.persistent.timer.TimerState --> [DatabaseTable(EJB__TIMER__TBL)])
at org.eclipse.persistence.exceptions.DescriptorException.notDeserializable(DescriptorException.java:1230)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:75)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.getObjectValue(AbstractDirectMapping.java:614)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.valueFromRow(AbstractDirectMapping.java:1215)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.buildCloneFromRow(AbstractDirectMapping.java:203)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildAttributesIntoWorkingCopyClone(ObjectBuilder.java:1811)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneFromRow(ObjectBuilder.java:1958)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:726)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:629)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:587)
at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:571)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:782)
at org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:848)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:490)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1155)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
... 110 more
Caused by: Exception [EclipseLink-3007] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.ConversionException
Exception Description: The object [com.sun.ejb.containers.TimerState$Blob], of class [class java.lang.String], could not be converted to [class java.lang.Class]. Ensure that the class [class java.lang.Class] is on the CLASSPATH. You may need to use alternate API passing in the appropriate class loader as required, or setting it on the default ConversionManager
Internal Exception: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.eclipse.persistence.exceptions.ConversionException.couldNotBeConvertedToClass(ConversionException.java:95)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:446)
at org.eclipse.persistence.internal.helper.ConversionManager.convertClassNameToClass(ConversionManager.java:799)
at org.eclipse.persistence.internal.helper.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:42)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at org.eclipse.persistence.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:73)
... 133 more
Caused by: java.lang.ClassNotFoundException: com.sun.ejb.containers.TimerState$Blob
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1761)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1611)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at org.eclipse.persistence.internal.helper.ConversionManager.convertObjectToClass(ConversionManager.java:443)
... 141 more
]]

[2014-05-28T09:51:16.893+0200] [glassfish 4.0] [INFO] [ejb.portable_jndi_names] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263476893] [levelValue: 800] [[
EJB5181:Portable JNDI names for EJB EJBSchedulerSessionBean: [java:global/CSIPortal-J2EE6/EJBScheduler-ejb/EJBSchedulerSessionBean, java:global/CSIPortal-J2EE6/EJBScheduler-ejb/EJBSchedulerSessionBean!com.portal.scheduler.EJBSchedulerSessionBeanLocal]]]

[2014-05-28T09:51:17.049+0200] [glassfish 4.0] [INFO] [ejb.portable_jndi_names] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263477049] [levelValue: 800] [[
EJB5181:Portable JNDI names for EJB LSCTServicesSessionBean: [java:global/CSIPortal-J2EE6/LSCTServices-ejb/LSCTServicesSessionBean, java:global/CSIPortal-J2EE6/LSCTServices-ejb/LSCTServicesSessionBean!com.contshipitalia.ejb.lsct.LSCTServicesSession]]]

[2014-05-28T09:51:17.205+0200] [glassfish 4.0] [INFO] [NCLS-COMUTIL-00017] [javax.enterprise.system.util] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263477205] [levelValue: 800] [[
com.contshipitalia.ejb.mct.NewCustomsDeclarationEntityPK actually got transformed]]

[2014-05-28T09:51:17.267+0200] [glassfish 4.0] [INFO] [NCLS-COMUTIL-00017] [javax.enterprise.system.util] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263477267] [levelValue: 800] [[
com.contshipitalia.ejb.mct.NewCustomsDeclarationEntity actually got transformed]]

[2014-05-28T09:51:17.267+0200] [glassfish 4.0] [INFO] [ejb.portable_jndi_names] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263477267] [levelValue: 800] [[
EJB5181:Portable JNDI names for EJB MCTNewServicesSessionBean: [java:global/CSIPortal-J2EE6/MCTServices-ejb/MCTNewServicesSessionBean, java:global/CSIPortal-J2EE6/MCTServices-ejb/MCTNewServicesSessionBean!com.contshipitalia.ejb.mct.MCTNewServicesSession]]]

[2014-05-28T09:51:18.141+0200] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478141] [levelValue: 900] [[
Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled]]

[2014-05-28T09:51:18.141+0200] [glassfish 4.0] [WARNING] [] [org.jboss.weld.interceptor.util.InterceptionTypeRegistry] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478141] [levelValue: 900] [[
Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled]]

[2014-05-28T09:51:18.640+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478640] [levelValue: 1000] [[
Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method
java.lang.RuntimeException: EJB Timer Service is not available
at com.sun.ejb.containers.BaseContainer.startApplication(BaseContainer.java:3951)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:163)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandMultInMultOut(CommandResource.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)
]]

[2014-05-28T09:51:18.640+0200] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478640] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.RuntimeException: EJB Timer Service is not available
at com.sun.ejb.containers.BaseContainer.startApplication(BaseContainer.java:3951)
at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:163)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployCommand.java:213)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandMultInMultOut(CommandResource.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)
]]

[2014-05-28T09:51:18.655+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478655] [levelValue: 1000] [[
Exception while loading the app]]

[2014-05-28T09:51:18.687+0200] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478687] [levelValue: 1000] [[
Undeployment failed for context /svc]]

[2014-05-28T09:51:18.749+0200] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(4)] [timeMillis: 1401263478749] [levelValue: 1000] [[
Exception while loading the app : EJB Timer Service is not available]]



 Comments   
Comment by sjkirkpatrick [ 18/Sep/14 ]

Encountered nearly identical issue, but was able to workaround by setting ejb-timer-service-upgraded property (in domain.xml) to false.





[GLASSFISH-20989] Merging parent entity with modified detached child leads to NPE Created: 18/Feb/14  Updated: 20/Feb/14

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Marek Handl Assignee: jjsnyder83
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A NullPointerException is thrown from EclipseLink code when merge is called on parent entity and cascaded to child entity which has been detached and modified.

The exception is thrown from inside EclipseLink code, but when the same scenario is executed on EclipseLink code without using Glassfish, the exception does not occur. It seems like Glassfish is not initializing something properly.

– Example –
Parent entity contains a list of children entities. The relation is OneToMany with CascadeType set to ALL.

ParentEntity parent = em.find(ParentEntity.class, parentId);
ChildEntity child = parent.getChildren().get(0);
em.detach(child);
child.setValue("new value");
em.merge(parent);

Note that merging the child entity before calling merge on parent entity does not prevent the exception.

– Stacktrace –

Caused by: java.lang.NullPointerException: null
	at org.eclipse.persistence.descriptors.changetracking.AttributeChangeTrackingPolicy.updateListenerForSelfMerge(AttributeChangeTrackingPolicy.java:130) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.mappings.CollectionMapping.mergeIntoObject(CollectionMapping.java:1560) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.mergeIntoObject(ObjectBuilder.java:3821) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.sessions.MergeManager.mergeChangesOfCloneIntoWorkingCopy(MergeManager.java:594) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.sessions.MergeManager.mergeChanges(MergeManager.java:313) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeCloneWithReferences(UnitOfWorkImpl.java:3524) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeCloneWithReferences(RepeatableWriteUnitOfWork.java:384) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeCloneWithReferences(UnitOfWorkImpl.java:3484) ~[org.eclipse.persistence.core.jar:na]
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.mergeInternal(EntityManagerImpl.java:542) ~[org.eclipse.persistence.jpa.jar:na]
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.merge(EntityManagerImpl.java:519) ~[org.eclipse.persistence.jpa.jar:na]
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.merge(EntityManagerWrapper.java:305) ~[container-common.jar:na]

– Reproducibility –
Issue does not occur in Glassfish 3.1.2.2.
Issue does not occur in embedded Glassfish 4.0.
Issue does not occur when the same scenario tested with EclipseLink 2.5.0 but without Glassfish.
Issue always occurs in Glassfish 4.0.



 Comments   
Comment by Marek Handl [ 18/Feb/14 ]

A Maven project for Eclipse demonstrating the issue can be found at http://www.filedropper.com/gfeltest

Note that it runs the problematic code in a PostConstruct method, but the result is the same even if the method is normally called via remote interface.

Comment by Marek Handl [ 20/Feb/14 ]

Whoever has the right to do it, please change the issue Component/s category to Persistence or similar. I must have entered cdi by mistake.

Comment by Romain Grécourt [ 20/Feb/14 ]

udpate component to entity / persistence





[GLASSFISH-2498] Allow Tomcat datasources to be looked up properly Created: 26/Feb/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,498

 Description   

The following forum post lists an issue connecting to Tomcat datasources:

http://forums.java.net/jive/thread.jspa?messageID=189962

Tomcat requires:
connector.setLookupType(JNDIConnector.STRING_LOOKUP) to be called on the context
before we do the lookup. This is different from the way we have to do it on
other servers.



 Comments   
Comment by cowwoc [ 23/Dec/08 ]

CCing myself

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2452] Allow for constant values to be passed to a constructor expression in JPQL Created: 19/Feb/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: r_sudh Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://glassfish.dev.java.net/servlets/ReadMsg?list=persistence&msgNo=2873


Issuezilla Id: 2,452

 Description   

Please consider this enhancement request to enable passing constant values to a
constructor expression in JPQL. This will enable such JPQL as below.

SELECT DISTINCT new myPackage.MyClass(c.id, c.desc, true) FROM Entry c

Thanks
-sud



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3452] Build container based test framework for JPA in GlassFish Created: 30/Jul/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,452

 Description   

At the moment, GlassFish JPA testing only occurs through non-container based
JUnit tests.

That kind of testing does not allow us to test things like JTA, integration
with other EE technologies and an multiple classloader environment.

We should build a framework that allows JUnit style tests (or tests based on
another framework) to be written in a simple way by developers.

If such a test framework already exists for other GlassFish components, perhaps
we can leverage it with help of the people that currently maintain it.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3353] Wrong JPAQL -> SQL translation /...IN (?1, ?2, ?3).../ Created: 15/Jul/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: pljosh Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,353

 Description   

Hi there, I have problem with a large query, so I will only demonstrate what is
wrong on an abstract query:

SELECT l.id, /more fields from many relations/
FROM Loan l, /more relations/
WHERE l.loanStatus NOT IN (?1,?2,?3,?4) AND
/many other conditions/

And here is how it was translated for Oracle database:

SELECT
t0.ID, /more fields from many relations/
FROM
LOANSCHEDULEENTRY t4,
ACCOUNTENTRY t3,
DICTLOANSTATUS t2,
PROPOSAL t1,
LOAN t0
WHERE
(((( NOT IN (?, ?, ?, ?) AND /many, many other conditions/

As you can see, there is a mistake in translation, the generated SQL is
basically wrong, there should be something before "NOT IN (?,?,?,?)".

That problem is very annoying, in fact WHERE ... IN (...) is totally useless, as
in every query, TopLink fails to translate it properly into SQL

P.S.
tested on GF v2 b45 and b55-fc



 Comments   
Comment by pljosh [ 15/Jul/07 ]

Oh one thing I've just noticed. The Bug only exists, when the parameters are
entity objects, this is how I can modify the query so it does work:

SELECT l.id, /more fields from many relations/
FROM Loan l, /more relations/
WHERE l.loanStatus.id NOT IN (?1,?2,?3,?4) AND
/many other conditions/

Now it is translated better, I mean I do not get exceptions anymore, and SQL
looks more or less correct.

Before I was setting parameters like this:

query.setParameter(
1,
em.getReference(DictLoanStatus.class, DictLoanStatus.READY))

Now, after changing "l.loanStatus" into "l.loanStatus.id" I set parameter like this:
query.setParameter(1, DictLoanStatus.READY)

I am just lucky I could replace my query in the way I did, but the defect is
dangerous anyway.

Comment by gfbugbridge [ 15/Jul/07 ]

<BT6580782>

Comment by pljosh [ 16/Jul/07 ]

Because there is a workaround, I am changing the priority P2 -> P3.
But this is not the only problem with JPAQL->SQL translation in TopLink
Essentials, someone should take a closer look at the issue anyway.

Comment by ijuma [ 20/Jul/07 ]

Adding myself to cc list.

Comment by pkrogh [ 24/Jul/07 ]

Using Entities here is beyond what the spec supports.

4.6.8 In Expressions
...

in_expression ::=
state_field_path_expression [NOT ]IN ( in_item

{, in_item}

* | subquery)
in_item ::= literal | input_parameter

The state_field_path_expression must have a string, numeric, or enum value.
...
...

I am changing this to be an enhancement as it is useful, but beyond what is
supported by the spec.

Comment by pljosh [ 25/Jul/07 ]

In that case, TopLink should at least throw some exception if the JPA query is
invalid.
Right now it silently creates wrong SQL without any word about what's wrong with
the query...

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2220] Should add support for native queries reading into non-entity objects Created: 25/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkeith Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,220

 Description   

It would be really nice if you could pass in a non-entity class to
a native query. It would be equivalent to a SELECT INTO in JP QL.

For example, EmployeeAccount is not an entity class:

List list = em.createNativeQuery("SELECT * FROM EMP_ACCT",
EmployeeAccount.class)
.getResultList();
List<EmployeeAccount> empAcctList = (List<EmployeeAccount>) list;

The same proviso would be in effect as with the JP QL SELECT INTO clause, which
is that there must be a constructor for the given class that takes the same
number and types of arguments as returned for each returned tuple.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2172] Need ability to provide custom implementation of ArchiveFactory Created: 22/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: shaane Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,172

 Description   

The glassfish persistence engine uses
oracle.toplink.essentials.ejb.cmp3.persistence.ArchiveFactoryImpl to access the
contents of the archive like the persistence.xml. It would be great to have a
mechanism to plugin a user specific implementation of the ArchiveFactory. This
would enable implementation like the one discussed at:
https://glassfish.dev.java.net/servlets/ReadMsg?list=persistence&msgNo=2720

In the mail thread I had suggested that we could use the Jar's Service provider
mechanism to provide a different implementation of the Factory. However, after
discussing further internally, we feel that the following algorithm could be
used to locate the archive factory:

  • Search for a property set in Persistence.createEntityManagerFactory(puName,
    properties). If the property giving the impl classname exists, construct a
    factory using that class name and use that.
  • else search for an implementation using the Jar's Service provider mechanism.
    By default it could return the current class name

This implementation would be enough for our current requirements. However, our
internal discussions led to the following possible enhancements:

  • Instead/Apart from taking ArchiveFactory impl classname, we could take an
    ArchiveFactoryWrapper impl classname. ArchiveFactoryWrapper instances (much like
    ServletRequestWrapper instances) would be passed the default implementation in
    the constructor. The wrapper can handle only the calls that it wants to handle
    and delegate the rest of the calls to the default implementation.


 Comments   
Comment by Sanjeeb Sahoo [ 22/Jan/07 ]

added myself to cc
– Sahoo

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2049] Uni-directional OneToMany without Join Table Created: 12/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mbayly Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,049

 Description   

Allow a uni-directional OneToMany mapping to be setup without requiring a
@JoinTable by specifying @JoinColumn in the owning side of the relationship.

This is as supported by Hibernate and as described in the example in the book
"Enterprise JavaBeans 3.0, 5th Edition (Bill Burke)" ch7(p.130)

@Entity
public class Customer implements java.io.Serializable {
...

private Collection<Phone> phoneNumbers = new ArrayList<Phone>( );
...
@OneToMany(cascade=

{CascadeType.ALL}

)
@JoinColumn
(name="CUSTOMER_ID")

public Collection<Phone> getPhoneNumbers( )

{ return phoneNumbers; }

public void setPhoneNumbers(Collection<Phone> phones)

{ this.phoneNumbers = phones; }

}



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by vonderbeck [ 17/Mar/08 ]
      • Issue 2049 has been confirmed by votes. ***
Comment by ijuma [ 15/Oct/08 ]

This should be part of Glassfish V3 final (not prelude). See:

http://wiki.eclipse.org/EclipseLink/Development/JPA2.0/uni-directional_onetomany_mapping

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2020] TopLink should support JDBC 3.0 escape functions Created: 11/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,020

 Description   

Every SQL dialect has its own syntax for functions like CONCAT("Hot", "Java").
To allow writing applications that are using these functions without knowledge
about the actual dialect's syntax (function name, parameter sequence, etc.),
JDBC 3.0 provides escape functions like

{fn concat("Hot", "Java"}

. Following the
constraints found in JDBC 3.0, a driver MUST support a list of such functions
provided in the specification, to be "JDBC 3.0 compliant". Java EE 5, the
embrace around EJB 3.0, clearly says that JDBC 3.0 compliance is mandatory for a
server product to be "Java EE 5 compliant".

Following this argument chain, I was expecting the Java EE 5 reference
implementation, GlassFish, to make strong use of that JDBC escape functions,
since it should be fairly easy and straightforward to map JPA's QL functions
more or less 1:1 on JDBC escape functions. The benefit would be: Easyness of
implementation, and high performance – since the application server itself (or:
the JPA provider) doesn't need to spend time into any logic of function name
conversion, and since the JDBC driver can just forward the SQL string to the
server, which can do the parsing and analyzing of the function (instead of
parsing on the client, which might be a slow machine compared to the fat server).

I was a bit astonished to see that TopLink doesn't make use of passing through
the unchanged JDBC escape functions. In fact, it depends of there beeing a
platform implementation that does the translation on the JDBC-client side (here
i. e. the application server). Moreover, it seems to be impossible to tell
TopLink that a client doesn't like to do a translation: The minimum translation
is to have a platform implementation that translates from TopLink's internal
representation into JDBC escape functions - which is some kind of total overhead.

So I think that it would be valueable improvement to enable a pass through mode,
that allows writing of very thin DatabasePlatform implementations: Do not force
a platform to translate names and do lots of plumbing, but just use JDBC 3.0
escape functionality instead as a default.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2005] Fields in tables get generated 'wrong', in the wrong order, and not as they are programmed. Created: 11/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: kevinava Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 2,005

 Description   

I'm using Toplink-Essentials (Glassfish v2, b30) and Netbeans 5.5 to communicate
with the database. And it generate the tables ok, but the fields get
generated in the wrong order, that is not in the same order as in my code.
Note! This only happens when you use a Class for a variable.
Example: private Room room;, see code below for more examples.

The program I make works fine, its not that but the QL and SQL code looks kinda
shit when fields in tables are messed up/wrong order.

I've tested several diffrent classes, but the same 'bug' on all of them, and

This also happens with the TopLink-Essentials that follows J2EE SDK Update 2 and
the latest TopLink-Essentials from the Glassfish Project.

RIGHT:
10:56:09.481-ServerSession(16795115)Connection(31248093)Thread(Thread[main,5,main])-CREATE
TABLE TESTTBL (ID INTEGER GENERATED ALWAYS AS IDENTITY NOT NULL, D1
VARCHAR(255), D2 VARCHAR(255), D VARCHAR(255), ROOM_ID VARCHAR(255), PRIMARY KEY
(ID))

Code 'wrong' not as it should be logical at least, but fields get generated right:
package test;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;

/**
*

  • @author kevinava
    */
    @Entity
    public class TestTbl implements Serializable {
    private int id;
    private String d1;
    private String d2;
    private String d;
    private Room room;

/** Creates a new instance of TestTbl */
public TestTbl() {
}

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
public int getId()

{ return id; }

public void setId(int id) { this.id = id; }

/* When the get and set D is here, the fields gets generated right. */
public String getD() { return d; }

public void setD(String d) { this.d = d; }

public String getD1() { return d1; }

public void setD1(String d1) { this.d1 = d1; }

public String getD2() { return d2; }

public void setD2(String d2) { this.d2 = d2; }


@ManyToOne
public Room getRoom() { return room; }

public void setRoom(Room room) { this.room = room; }

}

WRONG: [TopLink Fine]: 2007.01.11
10:56:09.481-ServerSession(16795115)Connection(31248093)Thread(Thread[main,5,main])-CREATE
TABLE TESTTBL (ID INTEGER GENERATED ALWAYS AS IDENTITY NOT NULL, D2
VARCHAR(255), D VARCHAR(255), D1 VARCHAR(255), ROOM_ID VARCHAR(255), PRIMARY KEY
(ID))

The code that generates messed up fields, but is logically right:

/*
* TestTbl.java
*
* Created on January 10, 2007, 7:57 PM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/

package test;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;

/**
*
* @author kevinava
*/
@Entity
public class TestTbl implements Serializable {
private int id;
private String d1;
private String d2;
private String d;
private Room room;

/** Creates a new instance of TestTbl */
public TestTbl() {
}

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
public int getId() { return id; }

public void setId(int id)

{ this.id = id; }

public String getD1()

{ return d1; }

public void setD1(String d1)

{ this.d1 = d1; }

public String getD2()

{ return d2; }

public void setD2(String d2)

{ this.d2 = d2; }

/* When the get and set D is here, the fields gets generated wrong. */
public String getD()

{ return d; }

public void setD(String d)

{ this.d = d; }

@ManyToOne
public Room getRoom()

{ return room; }

public void setRoom(Room room)

{ this.room = room; }

}



 Comments   
Comment by guruwons [ 11/Jan/07 ]

First, there is no rule like the generated columns should be in the same order
as the source code order of fields/methods.
Second, the reflection API doesn't gurantee the order of returned fields or
methods by Class.getDeclaredFields() or Class.getDeclaredMethods().

Therefore, I don't think this is bug. But it would be good idea to follow the
order if possible(but not guranteed due to the second reason).

So I change this to Enhancement...

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2844] groovy needs work with JPA weaving Created: 17/Apr/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: kylechen Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,844

 Description   

Please refer glassfish GLASSFISH-2741, this issue has been resolved by not using temp
class loader when weaving is turning off, it however dose not resolve the issue
that entities written by groovy script not working with weaving, the compiled
groovy script entities (java class) can't be resolved in temp class loader.

Debug shows groovy context class loader has different behavior from regular
Context classloader, the regular context classloader load all precompiled
binary classes from the classpath at runtime. While groovy seems do not have
any classpath allow to be configured during bootstrap, the java binary for each
groovy script will be compiled and loaded at runtime. During EMF predeploy
stage, JPA expects to resolve the entity class(groovy script)specified in
persistence.xml from Groovyclassloader(context class loader)which may not have
those compiled entities yet hence cause class not be found exception.

What not clear in here is that why using temp class loader can't resolve the
entity(written in Groovy script) but no-using temp class Loader can.

Two possibility solutions for this issue(not proofed yet):-
1. If we can figuire out above mentioned unclear, then we can perhaps still
user tempclassloader to weave the class.

2. If using temploader during the weaving is not possible, then we need to
figure it out to make GroovyClassLoader dynamic weaving the class in the
loading time. How to change groovy compile time behavior is documented at the
website http://blackdragsview.blogspot.com/2006/11/chitchat-with-groovy-
compiler.html, ApsectJ may have same mechanism to weaving aspects by using
Groovy(so far, I have not found any articles to discuss this technique).

Based on the documentation, we may need focus on the method setClassgenCallBack
in the class CompilationUnit when we create our own JPA GroovyClassLoader and
set this JPAGroovyClassLoader

http://www.bluemarsh.com/java/jswat/ is good tool to allow debug groovy script
and java class as well.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2776] Need getParameters() and getNamedParameters() calls on native Query interface Created: 03/Apr/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkeith Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 2,776

 Description   

It would be really helpful both for debugging, testing, tooling, and just the
increased flexibility that it would offer, if the following methods were
defined and available on the EJBQuery interface:

Map getParameters()
Map getNamedParameters()

The first call returns position keys, the second one keys by name, etc.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3985] Support for WeakReferences in Entity Manager in TopLink essentias Created: 08/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: abien Assignee: gyorke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File feedback.zip     Zip Archive TopLinkEssentialsWeakTest.zip     Text File TopLinkEssentialsWeakTest.zip     Text File toplink_modification.zip     Text File toplink_modification_II.zip    
Issuezilla Id: 3,985

 Description   

This issue was discussed already in the persistence@glassfish.dev.java.net.

Short Description:

The EntityManager holds all JPA-entities in hits internal cache with "hard
references", which causes Memory Leaks in stateful environment, where the
Entities remain persistent between transactions (e.g. Netbeans RCP, Eclipse RCP
clients, Seam, or frameworks with Context.Extended).

The attached patch (all modified classes, from yesterdays head), consists all
classes and modifications, and makes TopLink configurable.



 Comments   
Comment by abien [ 08/Jan/08 ]

Created an attachment (id=1297)
Modified classes (according to the explanation of Gordon Yorke)

Comment by abien [ 08/Jan/08 ]

Created an attachment (id=1298)
Simple Unit Tests, which just verifies, whether thie configuration is working

Comment by gyorke [ 08/Jan/08 ]

Changing subcomponent.

Comment by gyorke [ 15/Jan/08 ]

The UnitOfWork (Persistence Context) is more than a first level cache and that
should be reflected in the property name. Otherwise the property may be used
without an appreciation for the hard to detect side-effect of change loss. The
property should be moved to the config package with the other properties as we
will want customers to be able to browse the javaDocs and see these properties
as an option.
In the UnitOfWork the deletedObjects should not be touched as a deleted
object will probably be dereferenced by the client and may be lost if garbage
collected. The 'newAggregates' list should also have weak references in the
case the parent of an embeddable object is released.
Private visibility is generally not used in TopLink code for class
attributes. Protected provides similar restrictions but does not restrict
extension through subclassing which has been quite useful in the past.
With the IdentityHashtable it is the keys that should be weak in most
cases.with the newObjectsOriginalToClone both the key and the value should be
weak. Also for performance reasons it would be better to have the weak
IdentityHashtable be a subclass. That way the Hashtable code will remain
micro-optimized. At some point in V3 there is a plan to migrate to the JDK
collections and having a separate type will make that easier.
The IdentityMapManager.buildNewIdentityMap() will need to be updated as well.

Comment by gyorke [ 15/Jan/08 ]

Created an attachment (id=1307)
feedback

Comment by abien [ 22/Jan/08 ]

Created an attachment (id=1310)
Further modifications (according to the comment of Gordon York)

Comment by abien [ 22/Jan/08 ]

1. Property renamed to: toplink.persistence.context.reference.mode
2. In UnitOfWork the deleteObjects is untouched - it uses the "hard references"
3. newAggregates uses now WeakKeyIdentityHashtable (with weak keys, and hard values)
4. The referenceMode reference was changed from private to protected
5. IdentityHashtable is abstract now. HardIdentityHashtable,
WeakKeyIdentityHashtable and WeakKeyAndValueIdentityHashtable inherit from it.
However, because each hashtable accesses the Entries directly I just replicated
the code to the subclasses. Each of the Hashtable accesses the Entry either
directly , or using the WeakReference (then with accessors).
6. newObjectsOriginalToClone is realized with weak keys and values.
7. The implementation of the method buildIdentityMap in the IdentityMapManager
was reused from Gordon's code.
8. I'm not sure whether in the class InheritancePolicy always the Hashtable with
the hard references has to be used:

public SQLSelectStatement
buildClassIndicatorSelectStatement(ObjectLevelReadQuery query) {
// ...
// 2612538 - the default size of HardIdentityHashtable (32) is appropriate
//Hard, or potentially Weak?
HardIdentityHashtable clonedExpressions = new HardIdentityHashtable();
9. Because IdentityHashtable is abstract now, I had to changed some additional
classes to instantiate the HardIdentityHashtable instead.
10. The basic test was extended with identity assertions.

Comment by abien [ 24/Jan/08 ]

Extended tests provided (identity assurance with weak settings)

Comment by abien [ 24/Jan/08 ]

Created an attachment (id=1312)
Unit Test (update)

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3959] Let database wrapper decide for generation strategy Created: 04/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,959

 Description   

The JPA 1.0 specification chapter "9.1.9 GeneratedValue Annotation" says:

"The AUTO value indicates that the persistence provider should pick an
appropriate strategy for the particular database."

Currently TopLink always decides for TABLE strategy always, so in fact there is
no difference between AUTO and TABLE virtually, and the database is not taken
into account.

I think it would be beneficial if TopLink would ask the database wrapper what
the preferred strategy is, and use TABLE in the case the wrapper does not decide
(e. g. returns AUTO itself or doesn't implement such a callback).

I could imagine that on MAXDB for example, SEQUENCE is a better choice than
TABLE, since it works virtually the same but uses a technology optimized for
creating IDs. Also, on SYBASE for example, IDENTITY would be faster than TABLE
since it prevents transferring IDs over the LAN.

As it seems, this is what the spec authors originally had in mind. It would be
great if the next GlassFish release would support that.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3880] Generics id does not work Created: 29/Nov/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: marekmosiewicz Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,880
Status Whiteboard:

as91ur1-na


 Description   

Parametrized primary key like this
@Entity
public class Entity<K> implements Serializable{
K id;
@Id
public K getId()

{ return id; }

;
public void setId(K id)

{ this.id = id; }

}
Will throw ClassCastException:
Internal Exception: java.lang.ClassCastException:
sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to
java.lang.Class
at
oracle.toplink.essentials.exceptions.PersistenceUnitLoadingException.exceptionSearchingForPersistenceResources(PersistenceUnitLoadingException.java:143)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createEntityManagerFactory(EntityManagerFactoryProvider.java:169)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:110)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)

There is check in Toplink for ParametrizedType generics but in this case it is
VariableType class descriptor.

Marek Mosiewicz
http://www.jotel.com.pl experienced developers



 Comments   
Comment by marina vatkina [ 29/Nov/07 ]

This is not a bug - th id field according to the spec can only be

The primary key (or field or property of a composite primary key) should be one of
the following types: any Java primitive type; any primitive wrapper type;
java.lang.String; java.util.Date; java.sql.Date. In general, however, approximate
numeric types (e.g., floating point types) should never be used in primary keys.
Entities whose primary keys use types other than these will not be portable. If
generated primary keys are used, only integral types will be portable. If
java.util.Date is used as a primary key field or property, the temporal type
should be specified as DATE.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3863] SQL Like support for numerics Created: 20/Nov/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: mohsen Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.oracle.com/forums/thread.jspa?threadID=584228&tstart=0


Issuezilla Id: 3,863

 Description   

Hi,
Would you please add support for LIKE for numerics? It's a good idea to have
this if underling persistence platform (Oracle for example) have this feature,
otherwise it will raise an exception.
See the related topic on TopLink forum:
http://forums.oracle.com/forums/thread.jspa?threadID=584228&tstart=0
Thanks.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3789] Generated value for non-id field Created: 21/Oct/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: r_sudh Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,789

 Description   

Apparently the JPA spec does not require the capability of have an
auto-generated column for a non-id field. But this would be a useful extension
in toplink. So I'm logging this as an enhancement request.

For background on this see the following mailing list thread.

http://www.nabble.com/using-generated-value-with-a-non-Id-field-t4339169.html



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3705] JPQL with inherited enums Created: 27/Sep/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bernd_zedv Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 3,705

 Description   

I am using glassfish_v2_b58g - don't know to match this with 9.x version - sorry.

My Enums are defined in a @MappedSuperclass extended by two levels of derived
classes.

Writing my first JPQL queries I had problems to figure out how to use enum
literals. Finally I figured out that I a) need to specify fully-qualified names
and b) have to point to exactly the class defining the enum. Using the more
descriptive names of derived classes does not work and results in (sorry)
misleading error messages (although the toplink messages are very good in general).

Instead of writing:
"select o from SubClass o where o.attrib = packg.SubClass.Enum.Member"
I have to write:
"select o from SubClass o where o.attrib = packg.MappedSuperClass.Enum.Member"

Where I expected the Enums to be available in SubClass by enheritance too.

Maybe this could be done with a next version/release?

Thanks for this great product!
Bernd



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-4015] toplink.jdbc.Schema style property required Created: 18/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: ahardy66 Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,015

 Description   

It would be good if there was a property available to specify the name of the
database schema to complement the toplink.jdbc.url property.

Imho these configuration items belong together and having them together would
cut down on the configuration time required at deployment.

This is what makes it an enhancement over the schema property of the
persistence-unit-defaults property in the ORM.



 Comments   
Comment by ahardy66 [ 21/Jan/08 ]

This enhancement would offer the ability to specify the schema in code, by
adding the 'toplink.jdbc.schema' property to the map passed as a parameter to
Persistence.createEntityManagerFactory()

This is useful in the project I am working on currently, something that seems
like a reasonably common thing to do. My testing framework runs a suite of
integration tests one after the other against different databases, e.g. oracle,
informix, mysql, to ensure that the application is tested against all
environments it is deployed on.

To change the schema name in the test configuration each time by editing an
orm.xml file requires me to code and integrate an extra algorithm or configure
another maven plug-in into the test.

This doubles the effort required. It would be more intuitive, easy and elegant
if I could just add it to the mechanism which changes the other JDBC parameters
(url, username, password).

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3611] pagination throws java.lang.OutOfMemoryError Created: 15/Sep/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bodrin Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Text File pagination_exc.txt    
Issuezilla Id: 3,611

 Description   

The problem is in Java SE with MySQL database.

I have inserted 1 000 000 rows in a table and then tried to copy all of them to
another table in different DB and got java.lang.OutOfMemoryError.
After investigating the issue I found that the pagination does not work.

Here is the entity mapped to the table:
--------------------------------------------------
@Entity
public class Transaction implements Serializable {

@Id
@SequenceGenerator(name = "SEQ_TRANSACTION", sequenceName = "SEQ_TRANSACTION",
allocationSize = 1)
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "SEQ_TRANSACTION")
protected long id;

private String payerIban;

private String payerBic;

private String payeeIban;

private String payeeBic;

protected BigDecimal ammount;

protected int journalPeriod;

@Temporal(TemporalType.DATE)
protected Date transactionDate;

@Temporal(TemporalType.TIME)
protected Date transactionTime;

// constructors, getters and setters...
--------------------------------------------------

The the persistence.xml:
--------------------------------------------------
<persistence-unit name="rts_wallet-persistence"
transaction-type="RESOURCE_LOCAL">
<provider>
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider
</provider>
<class>Transaction</class>
<properties>
<property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/mpayrts"/>
<property name="toplink.jdbc.user" value="mydb"/>
<property name="toplink.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="toplink.jdbc.password" value="mypass"/>
<property name="toplink.logging.level" value="FINER"/>
</properties>
</persistence-unit>
--------------------------------------------------

When I try to execute the following query it works:
--------------------------------------------------
int pageSize = 500;
int offset = 310000;

List<Transaction> list = rtsEM.createQuery(
"select t from Transaction t").setFirstResult(offset)
.setMaxResults(pageSize).getResultList();
--------------------------------------------------

But, If it set offset = 320000; ... the result is:
--------------------------------------------------
[TopLink Fine]: 2007.09.15
05:23:58.718-ServerSession(11124894)Connection(11985823)Thread(Thread[main,5,main])-SELECT
ID, PAYEEBIC, AMMOUNT, PAYERBIC, JOURNALPERIOD, PAYERIBAN, TRANSACTIONDATE,
PAYEEIBAN, TRANSACTIONTIME FROM TRANSACTION
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.mysql.jdbc.Buffer.getBytes(Buffer.java:198)
at com.mysql.jdbc.Buffer.readLenByteArray(Buffer.java:318)
at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1360)
at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:2326)
at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:436)
at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2033)
at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1436)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1770)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3255)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1293)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1419)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:711)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:486)
at
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:437)
at
oracle.toplink.essentials.threetier.ServerSession.executeCall(ServerSession.java:465)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:213)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:199)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:270)
at
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:600)
at
oracle.toplink.essentials.internal.queryframework.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2207)
at
oracle.toplink.essentials.internal.queryframework.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2173)
at
oracle.toplink.essentials.queryframework.ReportQuery.executeDatabaseQuery(ReportQuery.java:774)
at
oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:609)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:677)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:731)
at
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2219)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:937)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:909)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:346)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getResultList(EJBQueryImpl.java:453)
at TestPagination.main(TestPagination.java:47)

--------------------------------------------------

Note that in MySQL there is a LIMIT clause and one could say:
select * from transaction LIMIT 320000,500;

But, as you can see into the log above the query does not look aware of this.



 Comments   
Comment by bodrin [ 15/Sep/07 ]

Created an attachment (id=1146)
pagination exception

Comment by gfbugbridge [ 15/Sep/07 ]

<BT6605255>

Comment by ijuma [ 20/Sep/07 ]

Adding myself to cc list.

Comment by pkrogh [ 28/Sep/07 ]

A good enhancement.

Comment by bodrin [ 30/Jan/09 ]

After investigating MySQL query log I have found what is the actual problem.
Toplink Essentials does not use the LIMIT clause of the SELECT statement, but
uses OPTION SQL_SELECT_LIMIT.

So, if you want to select 500 records at offset 320000 Toplink generates the
following statements:

2 Query SET OPTION SQL_SELECT_LIMIT=320500
2 Query SELECT * FROM subscription ORDER BY ID ASC
2 Query SET OPTION SQL_SELECT_LIMIT=DEFAULT

This way it selects (offset + pageSize) number of rows always starting from the
begging and if you select your last page - you actually will select all the
records.
So, it seams that this is not the right approach to implement pagination at all.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-2620] Process OrderBy when retrieving List from the Session Cache Created: 15/Mar/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vr143562 Assignee: tware
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Attachments: Zip Archive orderby-issue.zip    
Issuezilla Id: 2,620

 Description   

Glassfish v2 build 39, Java2DB, JavaSE mode

Scenario:

  • ManyToMany or OneToMany relationship, with a List to represent the associated
    collection.
  • @OrderBy is set on the relationship field.
  • Populate and Persist the relationship
  • Read the associated List and check if the List is in the order specified by
    @OrderBy

Observation:
1. The order in the retrieved List is as per the order specified in the @OrderBy
only if the Session Cache is NOT Shared
=> use <property name="toplink.cache.shared.default" value="false"/> in
persistence.xml
When this property is set to false, the list is retrieved from the DB and is
Ordered as per @OrderBy
2. If this property is set to true (default) the Session Cache is shared and the
List is retrieved from the cache and is in the order in which it was initially
populated.
3. On forcing a read from the DB using em.refresh() the associated List of was
in the order specified by the @OrderBy annotation

Now:

  • As per footnote 4 on page 19 of the spec - section 2.1.1 and this above
    observation, users have the following options when they want to retrieve Lists
    in the order prescribed by @OrderBy:
    a. Maintain the Order of the List themselves (so it is cached in the right order)
    b. Refresh the Session Cache using em.refresh() (if they do not want to worry
    about maintaining order during creation/modification of the List)
    c. Disable Session Cache using <property name="toplink.cache.shared.default"
    value="false"/> in persistence.xml

It seems like OrderBy is not of much use unless the provider is forced to go to
the DB for retrieval. This is a request for Processing OrderBy when retrieving
List from the Session Cache. That way @OrderBy would work without having to use
any of the above options a, b or c. Less things to remember for the programmer
as well.



 Comments   
Comment by vr143562 [ 15/Mar/07 ]

Created an attachment (id=795)
unzip the test case. To use the test, define
a environment variable S1AS_HOME that points to glassfish installation dir. Run
the test by invoking "ant se-java2db" from the command-line.

Comment by vr143562 [ 15/Mar/07 ]

On running the attached test case, you'll find that the test failed. You can
modify the test case by uncommenting the property <property
name="toplink.cache.shared.default" value="false"/> in
descriptor/persistence.xml and then run the test again - It passes this time.

Comment by chasetec [ 28/May/08 ]
      • Issue 2620 has been confirmed by votes. ***
Comment by jthoennes [ 04/Jan/11 ]

Are there any plans to correct this issue?

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-6932] log warning when a PU is being ignored Created: 15/Dec/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vince kraemer Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,932

 Description   

in http://www.netbeans.org/issues/show_bug.cgi?id=155026, the user creates an
entity class, but hasn't used it in their app.

Since the PU has 'toplink.ddl-generation' set to 'create-tables', the user
deployed their app and expected to see the tables created in their DB.

They got confused by the optimization that we do when the PU isn't 'used' in the
app.

The optimization is probably correct... but it would be nice to warn the user
that a PU in their app is being ignored or optimized away, since it is unused.



 Comments   
Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-11306] org.eclipse.persistence.jpa.modelgen.jar is missing the service definition file Created: 13/Dec/09  Updated: 09/Feb/13

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: stoty Assignee: Mitesh Meswani
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,306
Tags: 3_1-exclude

 Description   

The org.eclipse.persistence.jpa.modelgen.jar included in glassfishv3 is missing
the META-INF/services/javax.annotation.processing.Processor file.

That file is present in the 2.0.0 download from eclipse.org
(eclipselink-jpa-modelgen_2.0.0.v20091127-r5931.jar)

This makes it impossible to auto-generate the canonical metamodel from within
Eclipse, as it can't find the annotation processor.

This URL shows the procedure to follow in eclipse:

http://wiki.eclipse.org/UserGuide/JPA/Using_the_Canonical_Model_Generator_%28ELUG%29

Also, when running the generator from the command line the "-processor
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor" switch
must be specified, but it is not necessary with the correct jar file.

The glassfish version as shown by the admin console: "GlassFish v3 (build 74.2)"



 Comments   
Comment by Mitesh Meswani [ 16/Dec/10 ]

The bug describes two issues.

1. The user experience of metamodel generation is not pleasant from within Eclipse.
2. The annotation processor needs to be explicitly specified using -processor while running using CLI.

Using EclipseLink Dali should address the first one.
Targeting the second issue for 3.2

Comment by Mitesh Meswani [ 09/Feb/13 ]

Filled EcliseLink issue to track the enhancement required to modelgen.jar
https://bugs.eclipse.org/bugs/show_bug.cgi?id=400377





[GLASSFISH-3251] em.getReference acts like em.find which causes performance issues Created: 25/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: pljosh Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,251

 Description   

I found that em.getReference acts the same way as em.find, I mean it does fetch
entity from database. That causes great performance issues, because everywhere I
need only a reference, TopLink is fetching entire entity which I do not really
need.

That issue was discussed on "users" mailing list:
https://glassfish.dev.java.net/servlets/BrowseList?list=users&by=thread&from=843385

Following Tom Ware's suggestion, I am entering this issue as ENHANCEMENT, but
for me, it should be a DEFECT. Yes, I know "JPA spec." says:

"Get an instance, whose state may be lazily fetched."

but I believe, the JPA intention was that it may be lazily fetched only because
that entity could have been in cache already, so there would be no reason not to
provide initialized entity.
As Sahoo from SUN said /in the thread mentioned above/

"[...] I agree with you that implementing getReference() this way defeats the
purpose of having that API. I don't know the rational behind the current
implementation."



 Comments   
Comment by pljosh [ 03/Jul/07 ]

Can anyone, please, try to estimate when that issue could be fixed?
In my team, we are trying to resolve performance problems, in many cases the
source of all evil is the fact, that em.getReference is fetching entire object,
with all its dependencies, look at this example:

private void acquireLoans(BankStatement bankStatement) {
for (BankStatementEntry entry : bankStatement.getEntries()) {
String description = entry.getDescription();
Matcher matcher = LOAN_CODE_PATTERN.matcher(description);
String loanCode = matcher.find() ? matcher.group() : null;
if (loanCode != null)

{ List loanIds = em.createQuery( "SELECT l.id FROM Loan l WHERE l.proposal.loanCode=?1") .setParameter(1, loanCode).getResultList(); if (!loanIds.isEmpty()) entry.setLoan(em.getReference(Loan.class, loanIds.get(0))); }

}
}

Instead of having one simple query per entry, em.getReference is fetching ENTIRE
Loan, Proposal and dozen of other entities, which multiplied by entires count
gives hundreds of SQL queries produced by TopLink.

Everyday I am considering changing the "issue type" into "DEFECT" as this is
really against Persistence API.

Comment by pkrogh [ 05/Jul/07 ]

This section of the specification was intentionally written in this way so that
providers could implement getReference() by doing a find() or by lazily
fetching it. This is an enhancement, that does not fit into the schedule for
this release, but will be looked at for future releases.

Your example usecase is one that showcases the usefulness of lazy loading
getReference() the best, but I would argue that if performance is a concern,
there are things that you could do with this case, that would give you a much
bigger bang for your buck.

  • Using Lazy loading of relationships. By making your relationships load
    lazily, you will cut down on the SQL that gets generated by your getReference()
    call, and also improve performance in the other parts of your app.
  • Caching. By querying for PKs directly you are avoiding cache hits that
    could make getReference() and find() calls much faster.
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3240] Using PostgreGIS's PGobject types does not work in v2 Created: 22/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: batzee Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux
URL: http://postgis.refractions.net


Attachments: GZip Archive GlassfishIssue3240.tar.gz    
Issuezilla Id: 3,240

 Description   

In Toplink JPA v1, it was possible to use a mapping as follows:

@Column(name="geodata")
private PGgeometry geodata;

To use PostGIS's geometry types in an EJB3 application. It worked right out of
the box, without having to configure anything.

In v2 (tested with builds 41d and 50e) this is not possible anymore. It gives
the following exception:

javax.ejb.EJBException
at
com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:3858)
at
com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3758)
at
com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3560)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1343)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1305)
at
com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2844)
at
com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
at
com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
at
com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:524)
Caused by: Exception [TOPLINK-3002] (Oracle TopLink Essentials - 2.0 (Build
b50e-beta3 (06/21/2007))): oracle.toplink.essentials.exceptions.ConversionException
Exception Description: The object [POINT(9.94833 53.5377)], of class [class
org.postgis.PGgeometry], from mapping
[oracle.toplink.essentials.mappings.DirectToFieldMapping[currentPosBin-->shipaction.current_pos]]
with descriptor [RelationalDescriptor(com.vesseltracker.ejb.entity.Shipaction
--> [DatabaseTable(shipaction)])], could not be converted to [class [B].
at
oracle.toplink.essentials.exceptions.ConversionException.couldNotBeConverted(ConversionException.java:87)
at
oracle.toplink.essentials.internal.helper.ConversionManager.convertObjectToByteArray(ConversionManager.java:323)
at
oracle.toplink.essentials.internal.helper.ConversionManager.convertObject(ConversionManager.java:163)
at
oracle.toplink.essentials.internal.databaseaccess.DatasourcePlatform.convertObject(DatasourcePlatform.java:178)
at
oracle.toplink.essentials.mappings.converters.SerializedObjectConverter.convertDataValueToObjectValue(SerializedObjectConverter.java:81)
at
oracle.toplink.essentials.mappings.foundation.AbstractDirectMapping.getAttributeValue(AbstractDirectMapping.java:352)
at
oracle.toplink.essentials.mappings.foundation.AbstractDirectMapping.valueFromRow(AbstractDirectMapping.java:716)
at
oracle.toplink.essentials.mappings.DatabaseMapping.readFromRowIntoObject(DatabaseMapping.java:1022)
at
oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildAttributesIntoObject(ObjectBuilder.java:281)
at
oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:530)
at
oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:451)
at
oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:421)
at
oracle.toplink.essentials.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:387)
at
oracle.toplink.essentials.queryframework.ReportQueryResult.processItem(ReportQueryResult.java:220)
at
oracle.toplink.essentials.queryframework.ReportQueryResult.buildResult(ReportQueryResult.java:182)
at
oracle.toplink.essentials.queryframework.ReportQueryResult.<init>(ReportQueryResult.java:98)
at
oracle.toplink.essentials.queryframework.ReportQuery.buildObject(ReportQuery.java:594)
at
oracle.toplink.essentials.queryframework.ReportQuery.buildObjects(ReportQuery.java:643)
at
oracle.toplink.essentials.queryframework.ReportQuery.executeDatabaseQuery(ReportQuery.java:804)
at
oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:628)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:692)
at
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:746)
at
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2233)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:952)
at
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:924)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:361)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getSingleResult(EJBQueryImpl.java:502)
at
com.vesseltracker.ejb.jobs.AlertingJobImpl.findCurrentShipaction(AlertingJobImpl.java:128)
at
com.vesseltracker.ejb.jobs.AlertingJobImpl.processAlerts(AlertingJobImpl.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2884)
at
com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2813)
... 6 more



 Comments   
Comment by batzee [ 22/Jun/07 ]

Created an attachment (id=985)
Testcase (Project for Ecliipse 3.2 with WTP 1.5)

Comment by batzee [ 22/Jun/07 ]

The attached testcase should work on Glassfish 1, but on v2 it should produce
the above exception.

When deploying, take care to:

  • put postgis.jar and postgresql-8.2-505.jdbc3.jar into the glassfish/lib dir
  • create a Connection Pool using the PGSimpleDataSource (ConnectionPoolDS gives
    problems with JDK1.6)
Comment by gfbugbridge [ 22/Jun/07 ]

<BT6573112>

Comment by pkrogh [ 27/Jun/07 ]

This appears to be a regression.

Comment by pkrogh [ 03/Jul/07 ]

Hi,

I suspect that the reason you are experiencing this issue now and were not in
previous releases is that TopLink Essentials is now behaving in a spec
compliant manner in this regard and wasn't in the previous release. Previously
TopLink Essentials was not serializing types that it should have been
serializing (instead just treating it as a Basic). The JPA spec states that
only primative types be treated as basic mappings, and other non entities be
serialized. I suspect that prior to this change treating this type as a Basic
worked fine, but doesn't as soon as we try to serialize it.

I am making this a feature enhancement as it really is an extension to the
spec, and will require some new API to make this work.

As a workaround you can add a session customizer that searches for the mapping
and removes the serialized converter from it. Something like:

Persistence.xml entry:
~~~~~
<property name="toplink.session.customizer" value="mypackage.MyCustomizer"/>

Customizer Class :
~~~~~
package mypackage;
import oracle.toplink.essentials.sessions.Session;
import oracle.toplink.essentials.mappings.DirectToFieldMapping;
import oracle.toplink.descriptors.RelationalDescriptor;

/**

  • PUBLIC:
  • This interface is to allow extra customization on a TopLink Session
    */
    public class MyCustomizer extends SessionCustomizer {
    public void customize(Session session) throws Exception { RelationalDescriptor descriptor = session.getDescriptor(<class to take converter>); DirectToFieldMapping mapping = (DirectToFieldMapping) descriptor.getMappingForAttributeName(<mapping to be converted>); mapping.setConverter(null); }

    }

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3153] XMLTYPE column always returns NULL using native sql query Created: 08/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: zoetsekas Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,153

 Description   

When a create a native query and try to query a Oracle XMLTYPE column I get a
null value. For example:

SELECT extract(history_xml_data,
'/test/submission-letter/text()').getStringVal() as xhda_xml_data FROM
T_XML_HISTORY_DATA;

where history_xml_data is a column of type XMLTYPE.

List result =
getEntityManager().createNativeQuery(sql,TXmlHistoryData.class).getResultList()



 Comments   
Comment by gfbugbridge [ 08/Jun/07 ]

<BT6567901>

Comment by pkrogh [ 12/Jun/07 ]

TopLink Essentials does not currently support mapping to XMLTYPE. I have made
this bug a feature enhancement.

To take the mappings out of the equation, and see what is returned, try
exceuting the query like this: getEntityManager().createNativeQuery(sql);

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3126] Support pessimistic locking in Derby Created: 04/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,126

 Description   

Currently the DerbyPlatform does not have a working implementation of
Pessimistic locking.

As a result the pessimistic lock query hint cannot be used in Derby.

The
oracle.toplink.essentials.testing.tests.cmp3.advanced.EntityManagerJUnitTestSuite.testPessimisticLockHintStartsTransaction()
has an example of this syntax and currently throws a warning when Derby is the
Platform.

When this is fixed, that warning should be removed.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-3127] Support pessimistic locking on PostGreSQL Created: 04/Jun/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,127

 Description   

Currently the PostGreSQLPlatform does not have a working implementation of
Pessimistic locking.

As a result the pessimistic lock query hint cannot be used in PostGreSQL.

The
oracle.toplink.essentials.testing.tests.cmp3.advanced.EntityManagerJUnitTestSuite.testPessimisticLockHintStartsTransaction()
has an example of this syntax and currently throws a warning when PostGreSQL is the
Platform.

When this is fixed, that warning should be removed.

GLASSFISH-3032 contains a suggestion about how to fix this.



 Comments   
Comment by tware [ 12/Jun/07 ]
      • Issue 3166 has been marked as a duplicate of this issue. ***
Comment by guruwons [ 13/Feb/08 ]

In the latest build pessimistic locking is possible due to the check-ins of the issue
2021. It is now using FOR UPDATE instead of FOR UPDATE OF *.
So it's needed to recheck the test case and remove that warning.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-481] add query hint to disable jpql validation Created: 27/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: jielin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 481

 Description   

There are some restrictions to jpql in the EJB 3.0 persistence specification
for the query language that disallow some things that will work on some
databases. As a result, JPQL validation will disallow writing queries that
could provide correct results on certain databases.

An example is: IN

From the spec:

in_expression ::=
state_field_path_expression [NOT] IN ( in_item

{, in_item}

* | subquery)
in_item ::= literal | input_parameter
The state_field_path_expression must have a string, numeric, or enum value

On an Oracle database IN can be used with Dates. With a hint to disable
validation, it would be possible to write a JPQL query that would correctly
return values that used an IN with a Date.



 Comments   
Comment by marina vatkina [ 27/Mar/06 ]

Reassigned

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-450] Generated SQL and identifiers which are database reserved words Created: 21/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: stvconsultants Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 450

 Description   

If an entity has a column with a name that is a reserved word of the database on
which it it stored, exceptions will be thrown all over the place when trying to
access that entity.

Ordinarily I would just design a different column name for the entity, but in
order to integrate with an existing application, the column names are fixed. So
I have

@Entity()
class MyTable {

private Integer id;

private String year;

@Id()
public Integer getId()

{ return id; }

public void setId(Integer id)

{ this.id = id; }

// I cannot to @Column(name="YEAR_") as we are mapping an existing table
public String getYear()

{ return year; }

public void setYear(String year)

{ this.year = year; }

}

In any rate, if the generated SQL quoted the identifiers, there wouldn't be a
problem, i.e.
SQL> select YEAR from MYTABLE
will not work but
SQL> select "YEAR" from MYTABLE
will always work

I think that the CMP should always ensure that the developer does not have to
worry about the reserved words of the datasource on which the application is
deployed, but if there are good reasons for not quoting always, at least is
there any way either a toplink specific property can be added to ensure all
identifiers are quoted always (so that people concerned over performance hits
with all those extra "s don't need to take the hit) or can some other solution
be suggested.

Here is one exception where the datasource is a derby database:

org.apache.derby.client.am.SqlException: Syntax error: Encountered "YEAR" at
line 1, column 49.
org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source)
org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source)
org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown
Source)
org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown
Source)
org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source)
org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source)
org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
org.apache.derby.client.am.Statement.executeQueryX(Unknown Source)
org.apache.derby.client.am.Statement.executeQuery(Unknown Source)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:709)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:486)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:437)
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.executeCall(UnitOfWorkImpl.java:1368)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:213)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:199)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:270)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:574)
oracle.toplink.essentials.internal.queryframework.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:1988)
oracle.toplink.essentials.internal.queryframework.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:1954)
oracle.toplink.essentials.queryframework.ReportQuery.executeDatabaseQuery(ReportQuery.java:699)
oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:609)
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:796)
oracle.toplink.essentials.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:850)
oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork.internalExecuteQuery(RepeatableWriteUnitOfWork.java:130)
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:925)
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:897)
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:319)
oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.getResultList(EJBQueryImpl.java:402)

<snipping from when the exception hits my stateless session bean>



 Comments   
Comment by stvconsultants [ 21/Mar/06 ]

The annotation

@Column(name="\"YEAR\"")

gets things working again, but that is too much of a hack for something that
should be elegant

Comment by marina vatkina [ 21/Mar/06 ]

Changing to entity-persistence category.
Adding "" around identifiers is very tricky. The spec defaults the identifier name
to the property or field name. Which means that SQL will be generated as "year", and
it won't work on case sensitive databases.

Comment by stvconsultants [ 21/Mar/06 ]

So are we left with my @Column(name="\"YEAR\"") hack?

or can we have a vendor specific string in persistence.xml to turn on quoting?
(as that wouldn't impact the persistence spec which I know is very frozen now)

Comment by marina vatkina [ 21/Mar/06 ]

@Column solution seems to be the best choice. The property will also need to say
whether the identifier need to be converted to upper case before adding the "".
Which means that you'll probably need 2 properties or a property with more than
one value.
I'll make it an ehnacement for now.

thanks,
-marina

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-399] java2db : Java 2 MySQL 2 type mapping to be updated Created: 14/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bjb Assignee: guruwons
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 399

 Description   

Taking this as reference :
http://fisheye5.cenqua.com/viewrep/glassfish/entity-persistence/src/java/oracle/toplink/essentials/platform/database/MySQL4Platform.java?r=1.5

For MySQL4 some of the default type mapping has to be updated to fit the default
Java type to the closest MySQL data type (of course, user is free to customize
the type in persistence, but default mapping should not involve "data loss" as
much as possible, at least as long as the database make it possible).

FYI, I've removed the 64000 as there is no reason not to rely on default "65535"
(aka "64k" and loose 1535 byte of storage each time).

Hence the following changes are anticipated :

Instead of :
fieldTypeMapping.put(Boolean.class, new FieldTypeDefinition("TINYINT(1) default
0", false));
put :
fieldTypeMapping.put(Boolean.class, new FieldTypeDefinition("BOOL DEFAULT
FALSE", false));

Instead of:
fieldTypeMapping.put(String.class, new FieldTypeDefinition("VARCHAR", 255));
put VARCHAR is limited to has max length of 255 on pre 5.0 mysql
fieldTypeMapping.put(String.class, new FieldTypeDefinition("TEXT", 255));
(default size of 255 will switch the real type to "TINY TEXT" that is 255 char
max width, personally I would have removed this contraints....)

Instead of :
fieldTypeMapping.put(java.sql.Blob.class, new FieldTypeDefinition("BLOB", 64000));
put :
fieldTypeMapping.put(java.sql.Blob.class, new FieldTypeDefinition("BLOB");
(here this will put 65535 which is the default)

fieldTypeMapping.put(java.sql.Clob.class, new FieldTypeDefinition("TEXT", 64000));
put
fieldTypeMapping.put(java.sql.Clob.class, new FieldTypeDefinition("TEXT"));
(default for TEXT is 65535)

Last thing that needs to be looked deeply is the TIMESTAMP :
fieldTypeMapping.put(java.sql.Timestamp.class, new
FieldTypeDefinition("DATETIME", false));

Precision of DATETIME is not matching java.sql.TimeStamp, so data is lost here
when storing the data to the DBMS. A better type has to be found TIMESTAMP might
be a good candidate but behaviour has to be taken care.



 Comments   
Comment by pramodgo [ 17/Mar/06 ]

Thank for the detailed issue report.
At this point of time I am changing the Issue type to "ENHANCEMENT."

Will have to revisit all the platforms and check these settings for each and
every field type.

Comment by pramodgo [ 17/Mar/06 ]

...

Comment by bjb [ 21/Mar/06 ]

Dear pramodgo,
I think cleaning all the SQL platform is a good idea.

Meanwhile, could it be possible at least to apply on th head the boolean and
string fix suggested ?

This would just save us time

Rgs,
JB

Comment by guruwons [ 12/Mar/07 ]

I'm reviewing the default data types of MySQL platform.

For Boolean, BOOL and BOOLEAN is synonym for TINYINT(1), so there is no need to
change it.

For String, TEXT(255) does not work on MySQL 4.0(4.1 support this).
@Column(length=n) can be used for VARCHAR which is translated into
corresponding TEXT type beginging with MySQL 4.1. Hence, it should be unchanged.

For Blob and Clob, BLOB(64000) and TEXT(64000) is interpreted as BLOB and TEXT.
But I think it should be LONGBLOB and LONGTEXT because the maximum size of
BLOB/TEXT is limited within 65,535 bytes.

For Timestamp, type TIMESTAMP does not support nanoseconds either. There is no
better type now in MySQL.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-378] java2db generating not valid DDL script, semi-column is missing. Created: 09/Mar/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bjb Assignee: pramodgo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 378

 Description   

Having the following :

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence">
<persistence-unit name="test" transaction-type="JTA">
<jta-data-source>jdbc/__default</jta-data-source>
<properties>
<property name="ddl-generation" value="dropandcreate"/>
<property name="create-ddl-jdbc-file-name" value="create.sql"/>
<property name="drop-ddl-jdbc-file-name" value="drop.sql"/>
<property name="toplink.platform.class.name"
value="oracle.toplink.essentials.platform.database.DerbyPlatform"/>
<!-- <property name="toplink.logging.level" value="FINEST"/> -->
</properties>
</persistence-unit>
</persistence>

And looking at the generated create.sql, each SQL statement are not separated by
a semi-column (, thus the generated DDL script is not valid and can not be
exacuted without manual correction by adding the missing semi-column.

This problem is existing on Derby, but it is anticipated that other java2db
flavor are behaving like that ! Please, fix this issue on derby and then double
check on other platforms as well.

Regards,
JB



 Comments   
Comment by marina vatkina [ 09/Mar/06 ]

The generated DDL is intended for JDBC execution.

Comment by bjb [ 09/Mar/06 ]

Tnx for the quick review of this issue.

I am sorry to insit, but if I copy paste this in a JDBC tool like SquirreL SQL,
the Derby JDBC database driver indicates the synthax is bad ! So, for me this is
not valid JDBC code. Am I missing something here ?

Having the semi-column (and in general a valid DDL script) will definitively
help people to do rapid development with Glassfish. Because it will help with
interroperability between glassfish artefacts and other tools.

So please reconsider fixing this. Maybe you can push this under "enhancement",
if you preffer ... although I do personally consider a DDL not beeing able to be
executed outside of GF as an issue.

Regards,
JB

Comment by marina vatkina [ 09/Mar/06 ]

Let's have it as an enhancement. Actually for CMP we generate 2 sets of files -
one for jdbc execution and one for command- or tool-based, but we didn't have
time to make major changes in TopLink code to allow that.

Regards,
-marina

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-1924] Support using Satement.getGeneratedKeys() Created: 06/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,924

 Description   

TopLink can take advantage of automaticcally created IDs, for example by
using "SELECT @@identity" after an INSERT. Unfortunately this means having a
second SQL command forwarded to the server after each INSERT (including parsing
etc.).

JDBC has explicit support for getting created keys: Statement.getGeneratedKeys
() will return a ResultSet with all automatically generated keys. It would be
great, if a future verson of TopLink would allow a driver to decide whether the
current solution is used (subsequent SELECT) or the JDBC method is used (which
might be faster, but is not supported with all platforms).



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1913] Special treatments should not be part of standard code Created: 05/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,913

 Description   

ExpressionOperator (and other classes) should always implement the standard
way, but no specialties. For example, the EJB QL operation "LOCATE" has the
parameters "a,b,c". SQLAnywhere platform's SQL dialect supports exactly that
parameter sequence. I was a bit surprised to find out that SQLAnywhere platform
must implement its own Locate2 operator to get the parameters in this sequence:
The reason is simple: ExpressionOperator implements a special, changed sequence
(c,a,b or something like that) which seems to be needed by some of the drivers.

In fact, this is no clean programming style. The default should always be a
clean implementation. Changing parameter sequences should always be a driver
specific thing and should not be part of the core code.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1912] ExpressionOperator should be free of vendor specific operators Created: 05/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: markuskarg Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,912

 Description   

The ExpressionOperator class currently contains several factory methods for
vendor specific operators like "sybaseLocateOperator()". Since TopLink
implements a modular concept utilizing the idea of having an abstract core and
specific drivers, all specifics should go into the driver solely. In turn, the
vendor specific methods should be removed from ExpressionOperator.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1884] Provide a setting that allows entity-persistence-tests to be run without native sequencing Created: 04/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,884

 Description   

Some DBs do not support native sequencing. (e.g. SQLAnywhere)

It is important to be able to run the entity-persistence-tests on these
databases.

We should allow the tests to be run without native sequencing.

We could do this in a number of ways:

1. Provide a preprocessing step for the code that gets rid of the SEQUENCE and
IDENTITY generators and replaces them with AUTO
2. Isolate the classes that use SEQUENCE and IDENTITY sequences in a separate
persistence unit and only run the tests that use them when the platform
supports native sequencing
3. Add a native sequencing test package and only test SEQUENCE and IDENTITY in
that package. Only run that package when the platform supports native
sequencing.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1719] Support Mapping Oracle XMLType in Essentials Created: 11/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,719

 Description   

XMLType is a special type on Oracle databases that allows you to store XML
documents and perform special queries on them.

Retreiving XMLType from the database requires some special code because it the
JDBC driver returns an object of type oracle.sql.OPAQUE and that type requires
a live connection in order to be translated to an XMLType. The point where
TopLink currently access the type is too late for that connection to be
guaranteed available.

We should support this kind of type.

  • Allow the user to map their XML Documents to an XMLType field in an Oracle
    database
  • Generate appropriate INSERT and UPDATE SQL statements
  • Provide support for querying based on the XMLType field.

The following operators should be supported:

extract – extract takes an xpath expression and returns another XMLType which
corresponds to some piece of the original document that matches the xpath
expression. (see above example)

extractValue – like extract, takes an xpath expression but returns either a
string or numerical value based on the contents of the nodes returned by the
xpath expression. eg
SELECT * FROM EMPLOYEE WHERE extractValue(RESUME, ‘//education/school/text()’)
= ‘Carleton’

existsNode – takes an xpath expression and returns the number of nodes which
match the expression. eg
SELECT * FROM EMPLOYEE WHERE existsNode(RESUME, ‘//education/degree/node()’) > 1

isFragment – returns 0 if the document is a full, well formed xml document and
1 otherwise.
SELECT * FROM EMPLOYEE e WHERE e.RESUME.isFragment() = 0

getStringVal(), getNumberVal() – gets the value of the XMLType as either a
String or a Number respectively
SELECT * FROM EMPLOYEE WHERE extract(RESUME, ‘//education’).getStringVal()
= ‘<school>Carleton</school><degree>BCS</degree>’
SELECT * FROM EMPLOYEE WHERE extract(RESUME, ‘//years-experience/text
()’).getNumberValue() > 5



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Sanjeeb Sahoo [ 20/Sep/07 ]

A very good feature to have. A few comments:
1. XMLType is supported in some other databases as well, e.g., DB2 Version 9+,
SQLServer 2005+. So, this feature should not limit itself to Oracle database
users only.

2. It should allow something like this:

@Entity class Employee

{ ... @XMLType Education education; // XMLType is a TopLink Essentials extension }

Education.class uses JAXB for Java/XML binding.

3. We should also allow user to specify path expressions to navigate to any
level in the embedded object tree, and the runtime should convert it to
appropriate XPATH.

– Sahoo

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1279] Identify messages logged at SEVERE level and add causes and solutions Created: 10/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: marina vatkina Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 1,279

 Description   

This is a task that can either be solved by directly providing the information
to the Error Message Reference doc writer (see e.g.
http://docs.sun.com/app/docs/doc/819-4739), or by adding some comments in a
predefined format to the existing message list.

Here is an example of added caused and solutions/checks for a CMP message (note
the 'diag.cause' and 'diag.check' keys under the actual message):

GEN.update_not_allowed=JDO74043: Bean ''

{0}

'' method

{1}

: Update operations are
not allowed for this bean
type.
JDO74043.diag.cause.1=Create, remove, or update is called on a read-only bean.
JDO74043.diag.check.1=Do not attempt to update read-only beans.
JDO74043.diag.check.2=If update is required, the bean must be deployed as two
different EJBs: as a read-o
nly bean, and as an updateable bean. All updates must be done on the second bean.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1278] Add message prefixes to all logged messages and exceptions Created: 10/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: marina vatkina Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 1,278

 Description   

Adding such previxes, that consist of some chars that define the module and the
number of the message in the list of the messages, achieves 2 goals - easier
support and ability to record messages in the message guide.

This would also follow GF rules for other modules



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1252] Several entity-persistence tests should be integrated into the FullRegressionTestSuite Created: 04/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,252

 Description   

There are several tests in entity-persistence-tests that were originally
developed as Oracle-internal tests that should be integrated into
FullRegressionTestSuite

UpdateAllQueryAdvancedJunitTest
JoinedAttributeAdvancedJunitTest
JUnitTestCase.suite(ReportQueryAdvancedJUnitTest
ReportQueryMultipleReturnInheritanceTestSuite
JoinedAttributeInheritanceJunitTest
IsolatedCacheTestSuite

They potentially require some updates to work correctly in JUnit since they are
currently run on a proprietary framework.

These tests should be tested both on Derby and on Oracle when they are
integrated.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1209] change entity-persistence-tests so all ddl generaiton uses the JPA ddl generation feature Created: 29/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,209

 Description   

Currently the entity-persistenct-tests use a combination of TopLink Table
Creators and DDL generation.

We should remove the TableCreators and simply use DDL generation.

Each JUnit test suite has some code in a setup method that looks similar to the
following:

new AdvancedTableCreator().replaceTables.JUnitTestCase.getServerSession());

We should replace this code with an appropriate call into the DDL generation
framework. This will make the test code more maintainable, and remove any
inconsistencies when DDL generation and TableCreators are both used.



 Comments   
Comment by marina vatkina [ 29/Sep/06 ]

What should be the call to the DDL generation? Which tests use it already?

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1200] Add query hint for multi-level join fetch Created: 28/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: djclarke Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,200

 Description   

Currently the JP QL grammar does not allow multi-level JOIN FETCH clauses for
multi-level. This prevents deeper joins from being specified and can lead to an
N+1 query explosion.

EXAMPLE MODEL:

Employee

  • id
  • manager (Employee)
  • address (Address)

I would like to query for Employees and JOIN FETCH its related address, manager,
and manager's address. JP QL does not currently allow me to JOIN FETCH the
manager's address.

SELECT e FROM Employee e JOIN FETCH e.address JOIN FETCH e.manager JOIN FETCH
e.manager.address

will result in an IllegalArgumentException for tyhe '.' after manager in
'e.manager.address'.

The underlying TopLink Essentials implementation does not have this limitation
and I would like to see us expose this functionality.

WORK-AROUND: The following TopLink specific API allows for additional join
fetches to be specified.

String jpql = "SELECT e FROM Employee e JOIN FETCH e.address JOIN FETCH
e.manager";
Query query = getEntityManager().createQuery(jpql);

ReportQuery rq = (ReportQuery)((EJBQueryImpl)query).getDatabaseQuery();
ReportItem eItem = (ReportItem)rq.getItems().get(0); // Assumes
knowledge of the SELECT clause
Expression manager = rq.getExpressionBuilder().get("manager");

eItem.getJoinedAttributeManager().addJoinedAttributeExpression(manager.get("address"));

List<Employee> emps = query.getResultList();

SOLUTION:

Ideally allowing the 'e.manager.address' in JP QL would be the simplest solution
but I could understand the JPA certification tests may ensure complete
compliance with the specified grammar.

To address this we should add an additional query hint: 'toplink.join-fetch'

This query hint would allow a more JPA compliant and cleaner looking solution to
be implemented. It would look like the following to users:

String jpql = "SELECT e FROM Employee e JOIN FETCH e.address JOIN FETCH
e.manager";
Query query = getEntityManager().createQuery(jpql);
query.setHint("toplink.join-fetch", "e.manager.address");

List<Employee> emps = query.getResultList();

The value of the query hint would need to start with a returned item (i.e. 'e')
to allow the proper item in the report-query result to be identified and then
contain a JP QL like expression to identify the returned element.

If traversing many levels each level to be JOIN FETCHed must be added. The
implementation could ensure this and either throw and exception or automatically
add each level not found already.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1181] Move persistence configuration properties to a common location Created: 21/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,181

 Description   

Most of the properties that can be used to configure persistence units in
TopLink essentials are held in classes in the oracle.toplink.essentials.config
package.

Some properties that can be used to configure are contained in other packages
and should be moved into the config package.

Examples:

oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider - many
properties
oracle.toplink.essentials.internal.weaving.TopLinkWeaver - WEAVING_OUTPUT_PATH,
WEAVING_SHOULD_OVERWRITE



 Comments   
Comment by marina vatkina [ 21/Sep/06 ]

While this is a good idea, it might be too late to completely fix it - the
strings in EntityManagerFactoryProvider are used by the container code and are
documented as the references on the TopLink (and GF, but the plan is to fix
those) web pages.

-marina

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1169] @Basic(optional=false) and dll generation doesn't generate not null column. Created: 20/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mgervais Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 1,169

 Description   

Hi,
I'm using MySQL.
If a property is tag with @Basic(optional=false), generated column doesn't have
a not nul constraint. On the contrary, if I use @Column(nullable=false) the
column is generated with the not null constraint.
Mickael



 Comments   
Comment by marina vatkina [ 25/Sep/06 ]

The spec defines this attribute as "it may be used in schema generation".

Comment by ijuma [ 02/Nov/06 ]

Adding myself to cc list.

Comment by pkrogh [ 15/Nov/06 ]

Changing this to an ENHANCEMENT. Definately useful for DDL gen to support NOT
NULL on Basics.

Comment by guruwons [ 16/Nov/06 ]

Quoting my message in the following thread,
http://www.nabble.com/Not-null-OneToOne-relation-tf2577677.html#a7193375

I think the strict meaning of the optional() element and @Column.nullable()
element are different. The former is a logical one which means that the field of
the entity object can be null or not, but the latter one has a physical meaning
that the corresponding database column can be nullable and this is used to
generate DDLs.

optional() value may be used by a provider to check the field before
synchronizing to database.
What I know is that current implementation doesn't utilize the optional() value

  • I'm not sure this a hint (@Basic specifies this as a hint). If this is just a
    hint, users should not rely on it.
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1159] Allow support for @Timestamp with @Version annotations Created: 19/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: asavitsky Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,159

 Description   

Currently, there's no way to specify both @Timestamp and @Version on the same
persistent field (to get a version [property of date/timestamp type). Here's the
combinations I've tried, and the results I've got:

1. Property of type Date - TopLink suggests that a version property should be of
Timestamp type:
@MappedSuperclass
public abstract class UpdatableEntity {
@Temporal (TemporalType.TIMESTAMP) // or TemporalType.DATE - same result
@Version
@Column (name = "MODIFIED_ON", nullable = false)
private Date modifiedOn;

@SuppressWarnings ("unused")
@PrePersist
@PreUpdate
private void modificationInterceptor()

{ setModifiedOn(new Date()); }

public Date getModifiedOn()

{ return modifiedOn; }
public void setModifiedOn(Date modifiedOn) { this.modifiedOn = modifiedOn; }
}

Exception [TOPLINK-7168] (Oracle TopLink Essentials - 10g release 4 (10.1.4.0.0)
(Build 060629Dev)): oracle.toplink.essentials.exceptions.ValidationException
Exception Description: The attribute [modifiedOn] of type [class java.util.Date]
on the entity class [class com.tdsecurities.app.model.Section] is not valid for
a version property. The following types are supported: int, Integer, short,
Short, long, Long, Timestamp.
at
oracle.toplink.essentials.exceptions.ValidationException.invalidTypeForVersionAttribute(ValidationException.java:947)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataValidator.throwInvalidTypeForVersionAttribute(MetadataValidator.java:169)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.processVersion(BasicAccessor.java:425)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.process(BasicAccessor.java:225)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessor(ClassAccessor.java:490)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessorFields(ClassAccessor.java:503)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessors(ClassAccessor.java:529)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclass(ClassAccessor.java:1085)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.MappedSuperclassAccessor.process(MappedSuperclassAccessor.java:48)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclasses(ClassAccessor.java:1095)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.process(ClassAccessor.java:457)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.processAnnotations(MetadataProcessor.java:194)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.processORMetadata(EntityManagerSetupImpl.java:1000)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:497)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:152)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:259)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:237)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:908)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:875)
... 13 more

2. Property of type java.sql.Timestamp - TopLink suggests that a temporal coulmn
could only be of Date or Calendar type:
@MappedSuperclass
public abstract class UpdatableEntity {
@Temporal (TemporalType.TIMESTAMP)
@Version
@Column (name = "MODIFIED_ON", nullable = false)
private Timestamp modifiedOn;

@SuppressWarnings ("unused")
@PrePersist
@PreUpdate
private void modificationInterceptor() { setModifiedOn(new Timestamp(new Date().getTime())); }
public Timestamp getModifiedOn() { return modifiedOn; }

public void setModifiedOn(Timestamp modifiedOn)

{ this.modifiedOn = modifiedOn; }
}

Caused by: Exception [TOPLINK-7165] (Oracle TopLink Essentials - 10g release 4
(10.1.4.0.0) (Build 060629Dev)): oracle.toplink.essentials.exceptions.ValidationE
xception
Exception Description: The type [class java.sql.Timestamp] for the attribute
[modifiedOn] on the entity class [class com.tdsecurities.app.model.Section] is not
a valid type for a temporal mapping. The attribute must be defined as
java.util.Date or java.util.Calendar.
at
oracle.toplink.essentials.exceptions.ValidationException.invalidTypeForTemporalAttribute(ValidationException.java:940)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataValidator.throwInvalidTypeForTemporalAttribute(MetadataValidator.java:162)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.processTemporal(BasicAccessor.java:406)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.processDirectToFieldMapping(BasicAccessor.java:269)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.process(BasicAccessor.java:239)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessor(ClassAccessor.java:490)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessorFields(ClassAccessor.java:503)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessors(ClassAccessor.java:529)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclass(ClassAccessor.java:1085)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.MappedSuperclassAccessor.process(MappedSuperclassAccessor.java:48)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclasses(ClassAccessor.java:1095)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.process(ClassAccessor.java:457)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.processAnnotations(MetadataProcessor.java:194)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.processORMetadata(EntityManagerSetupImpl.java:1000)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:497)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:152)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:259)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:237)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:908)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:875)
... 13 more

3. Property of type Calendar - again, the suggestion is to use Timestamp!
@MappedSuperclass
public abstract class UpdatableEntity {
@Temporal (TemporalType.TIMESTAMP) // or, again, TemporalType.DATE
@Version
@Column (name = "MODIFIED_ON", nullable = false)
private Calendar modifiedOn;

@SuppressWarnings ("unused")
@PrePersist
@PreUpdate
private void modificationInterceptor() { setModifiedOn(Calendar.getInstance()); }
public Calendar getModifiedOn() { return modifiedOn; }
public void setModifiedOn(Calendar modifiedOn) { this.modifiedOn = modifiedOn; }

}

Caused by: Exception [TOPLINK-7168] (Oracle TopLink Essentials - 10g release 4
(10.1.4.0.0) (Build 060629Dev)): oracle.toplink.essentials.exceptions.ValidationE
xception
Exception Description: The attribute [modifiedOn] of type [class
java.util.Calendar] on the entity class [class
com.tdsecurities.app.model.Section] is not valid
for a version property. The following types are supported: int, Integer, short,
Short, long, Long, Timestamp.
at
oracle.toplink.essentials.exceptions.ValidationException.invalidTypeForVersionAttribute(ValidationException.java:947)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataValidator.throwInvalidTypeForVersionAttribute(MetadataValidator.java:169)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.processVersion(BasicAccessor.java:425)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.BasicAccessor.process(BasicAccessor.java:225)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessor(ClassAccessor.java:490)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessorFields(ClassAccessor.java:503)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processAccessors(ClassAccessor.java:529)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclass(ClassAccessor.java:1085)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.MappedSuperclassAccessor.process(MappedSuperclassAccessor.java:48)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.processMappedSuperclasses(ClassAccessor.java:1095)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.accessors.ClassAccessor.process(ClassAccessor.java:457)
at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.processAnnotations(MetadataProcessor.java:194)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.processORMetadata(EntityManagerSetupImpl.java:1000)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:497)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:152)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:259)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:237)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:908)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:875)
... 13 more

If there's any other way to achieve what I'm aiming for, let me know.



 Comments   
Comment by pkrogh [ 19/Sep/06 ]

1. The spec defines Version locking as supportable with The following
attribute types: int, Integer, short, Short, long, Long, Timestamp. Using
Temporal type doesn't change the attribute type.

2. According to section 9.1.20, Temporal types are only supported on
attributes of type util.Date or util.Calendar.

3. same as 1.

Your correct solution would look something like this:
@Version
@Column (name = "MODIFIED_ON", nullable = false)
private Timestamp modifiedOn;

However, I am not aware of any technical reason why either of these scenarios
can't be supported. I have downgraded the bug. It could also be made an
enhancement request.

Comment by marina vatkina [ 21/Sep/06 ]

This would be an enhancement

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1127] Static shouldIgnoreCaseOnFieldComparisons on DatabasePlatform should be an instance variable Created: 11/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: chris_delahunt Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,127

 Description   

oracle.toplink.essentials.internal.databaseaccess.DatabasePlatform defines a
static shouldIgnoreCaseOnFieldComparisons boolean that indicates field/table
case should matter. This needs to be changed to be an instance variable (non-
static) so that it can be set per Persistence Unit rather than globably, and
allow different databasePlatforms (such as sybase and other case sensitive
databases) to override the default.

This involves large refactoring as this boolean is used in places that do not
have access to the DatabasePlatform instance.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1122] Supply behavior similar to Hibernate @IndexColumn Created: 08/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: tware
Resolution: Unresolved Votes: 11
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 1,122

 Description   

It is currently not easily possible to implement a collection with List
semantics that purely depends on insertion order. (The current "List" is really
more like SortedSet since it depends on properties of the collection elements,
not their position.)

In Hibernate, this problem is solved by the @IndexColumn annotation.

@Entity
public class Quiz implements Serializable {
@IndexColumn(name = "question_position", base=1)
@OneToMany private List<Question> questions;
. . .
}

This would make a join table such as the following:

Quiz | Question | question_position
-----------------------------------
1001 | 20552 | 1
1001 | 20207 | 2
. . .

As suggested by
http://forums.java.net/jive/thread.jspa?threadID=17660&messageID=146178#146178,
I am requesting this enhancement.



 Comments   
Comment by pventura [ 09/Sep/06 ]
      • Issue 1122 has been confirmed by votes. ***
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by ijuma [ 15/Oct/08 ]

Something like this should be part of Glassfish V3 final (not prelude). See:

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/ordered_lists

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1117] Toplink Essentials distributed 2nd level cache Created: 08/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: jabbah Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,117

 Description   

Create a pluggable architecture for cache implementations (like
org.hibernate.cache.CacheProvider) in order to plugin existing cache
implementations capable of a distributed cache. (EHCache, SwarmCache)



 Comments   
Comment by ijuma [ 08/Sep/06 ]

Adding myself to cc list.

Comment by guruwons [ 10/Sep/06 ]

Adding Wonseok Kim to cc list.

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by ijuma [ 20/Jul/07 ]
      • Issue 1117 has been confirmed by votes. ***
Comment by ijuma [ 15/Oct/08 ]

It's worth noting that Toplink was replaced by EclipseLink in V3 and EclipseLink
supports a clustered cache (although it's not pluggable).

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1114] Loggers are updated in the middle of deploy Created: 07/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: marina vatkina Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 1,114

 Description   

The loggers properties (both, the AbstractSessionLog and the session
logger) are reset again in updateServerSession that happens in the middle of
deploy() processing.
The problem is that there are assumptions that logging setting can change in
between predeploy and deploy, and before calling updateServerSession again and
again.

We need to streamline this and decide if it's worth resetting loggers at those
points.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1067] Add support for Oracle NVARCHAR2 columns Created: 01/Sep/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: raccah Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,067

 Description   

We don't support these now, but we should.



 Comments   
Comment by pkrogh [ 06/Sep/06 ]

I changed this to an Enhancement.

Supporting 'N' Types requires Oracle Specific JDBC calls, that are not
currently supported by TopLink Essentials. Support for N types sounds like a
good feature request.

Note: Adding this support will likely require changes to the build system to
compile classes with references to Oracle JDBC specific classes.

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-263] Use a properties file for persistence provider specific properties Created: 15/Feb/06  Updated: 07/Mar/12

Status: Reopened
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 263

 Description   

Have a property file which look like this:
<provider-class-name1>.<provider-property-A>=<valueA>
<provider-class-name1>.<provider-property-B>=<valueB>
<provider-class-name2>.<provider-property-C>=<valueC>
<provider-class-name2>.<provider-property-D>=<valueD>

This can be loaded in PersistenceUnitLoaderImpl and then we can just pass the
properties specific to a provider in the map paremeter of
createContainerEntityManagerFactory().

Thanks,
Sahoo



 Comments   
Comment by djclarke [ 29/Sep/06 ]

I am unsure of the value of this enhancement. Currently the persistence.xml
provides properties where vendor specific details can be provided. Going forward
as more advanced extensions are supported additional implementation specific
files will be required. I don't see the need to add in yet another file.

If there is some concrete usecases that would warrant this additional file
please provide them and re-open.

Comment by Mitesh Meswani [ 29/Sep/06 ]

This enhancement was filled as a reminder to generalize handling of various
persistence provider in Glassfish. Reopening.
Please note that this is not an issue with Toplink

Comment by Sanjeeb Sahoo [ 07/Mar/12 ]

Assigning to jpa team for taking due action





[GLASSFISH-179] Use 'TransactionSynchronizationRegistry' interface instead of TransactionManager Created: 22/Jan/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Microsoft Word lhillis_essentials_issue159_060704.merge_diffs    
Issuezilla Id: 179

 Description   

Look at
oracle.toplink.essentials.transaction.sunas.SunAS9TransactionController.class.
It contains following line:
public static final String JNDI_TRANSACTION_MANAGER_NAME =
"java:pm/TransactionManager";

A provider, inorder to be portable, should not rely on TransactionManager
interface. Instead it should use TransactionSynchronization interface that is
newly introduced in Java EE 5 platform. A standard JNDI name of an object
implementing this interface is java:comp/TransactionSynchronizationRegistry.
More information on this topic is available at
http://blogs.sun.com/roller/page/NewYearWish?anchor=new_transactionsynchronizationregistry_interface_in_java



 Comments   
Comment by pkrogh [ 10/Feb/06 ]

reassign to marina

Comment by marina vatkina [ 01/Mar/06 ]

The current structure expects a TXMgr to be able to do more than there is
avalable from TransactionSynchronizationRegistry.

Comment by tware [ 12/Jul/06 ]

Created an attachment (id=307)
diff file for fix

Comment by tware [ 12/Jul/06 ]

adding target release

Comment by tware [ 12/Jul/06 ]

unset accidentally set target release

NOTE: Diff file Wed Jul 12 13:06:00 +0000 2006:
lhillis_essentials_issue159_060704.merge_diffs does not belone with this bug

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1576] Create EntityManagers with different username/password Created: 24/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: alexs12345678 Assignee: tware
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,576

 Description   

Hi!

As it is written in the Java 5 EE javadoc it should be possible to use
properties to create an EntityManager with .createEntityManager(Map properties).

I would like to use this to define different username/passwords for the
EnitityManagers I create.

But the following does not work:

Map<String, String> connectProps = new HashMap<String, String>();
connectProps.put(TopLinkProperties.JDBC_USER, "myusername");
connectProps.put(TopLinkProperties.JDBC_PASSWORD,"myuserpassword");
EntityManager emf = Persistence.createEntityManagerFactory("default",
connectProps);

The new EntityManagers use the same username/password as before.
I found in the Open JPA Documentation that it should be possible there to
create an EntityManager with username/password,
(see
http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#jpa_overview_
emfactory_em).

Best regards,
Alex Schaefer



 Comments   
Comment by alexs12345678 [ 24/Nov/06 ]

Corrected type of issue from DEFECT to ENHANCEMENT REQUEST

Comment by tware [ 28/Nov/06 ]

It should be possible to somehow make use of a ClientSession with a
ConnectionPolicy to specify different ways of connecting for different EMs.

The level of work for this change is more at the "Feature" level rather than
the "Enhancement" level.

Comment by tware [ 28/Nov/06 ]

Related to issue 1575. Implementing one of these two Features should provide
most of the functionality.

Comment by alexs12345678 [ 04/Dec/06 ]

Sorry for the wrong code example, here is a better one:

Map<String, String> connectProps = new HashMap<String, String>();
connectProps.put(TopLinkProperties.JDBC_USER, "myusername");
connectProps.put(TopLinkProperties.JDBC_PASSWORD,"myuserpassword");
EntityManager em = entityManagerFactory.createEntityManager(connectProps);

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1575] Create more than one EntityManagerFactory for the same PersistenceUnit Created: 24/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: alexs12345678 Assignee: tware
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,575

 Description   

Hi,

when I try to create more than one EntityManagerFactory for the same
PesistenceUnit (to use different user/passwords for login) I run into the
problem that toplink only creates only one EntityManagerFactory and returns it
via Persistence.createEntityManagerFactory(..) even if I use a different
properties object.

I use the following code:

Map<String, String> connectProps1 = new HashMap<String, String>();
connectProps1.put(TopLinkProperties.JDBC_USER, "user1");
connectProps1.put(TopLinkProperties.JDBC_PASSWORD,"password1");

EntityManagerFactory myemf1 = Persistence.createEntityManagerFactory("default",
connectProps1);

EntityManager em1 = myemf1.createEntityManager();

List userstring1 = em1.createNativeQuery("select user from dual").getResultList
();
String usi1 = userstring1.toString();
System.out.println(usi1);

Map<String, String> connectProps2 = new HashMap<String, String>();
connectProps2.put(TopLinkProperties.JDBC_USER, "user2");
connectProps2.put(TopLinkProperties.JDBC_PASSWORD,"password2");

EntityManagerFactory myemf2 = Persistence.createEntityManagerFactory("default",
connectProps2);

EntityManager em2 = myemf2.createEntityManager();

List userstring2 = em2.createNativeQuery("select user from dual").getResultList
();
String usi2 = userstring2.toString();
System.out.println(usi2);

But Toplink essentials does only creates one EntityManagerFactory (when
executing myemf1.createEntityManager() I think ) and starts the database
connections, but the second Persistence.createEntityManagerFactory("default",
connectProps2) call seems to be ignored.
The result from "select user from dual" is in both cases "user1"

By the way:
It seems that Hibernate can create more than one EntityManagerFactory per
PesistenceUnit.

Best regards and thanks for any feedback,
Alex Schaefer



 Comments   
Comment by tware [ 28/Nov/06 ]

Related to issue 1576. Implementing one of these two Features should provide
most of the functionality.

Changing to "Feature"

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by franos13 [ 30/Aug/07 ]

That seems to be possible with Hibernate.
So why TopLink couldn't do the same !

Comment by tware [ 30/Aug/07 ]

The fact that another provider has chosen to implement this functionality does
not make it a bug in TopLink Essentials. Resetting to Feature.

This is definitely a desirable feature.

Comment by antodasana [ 18/Aug/08 ]

Hello.

Just in case you find interesting my comments:

I am currently developing JPA in J2SE and this issue is the reason I can not use
TopLink Essentials. I have a 'logon' screen with connections to different
databases and once I open a connection by creating an 'em factory', no matter
the properties 'map' I send to 'Persistence' this will always return the same
'em factory', and this makes TopLink unusable in my case.

Maybe this is a bug in the specification: what makes sense is having different
connections for different connection properties, once multiple factories are
permitted by the specification (see comments bellow).

TopLink Essentials was my initial choice but because of this issue I found
myself forced to move to OpenJPA. I guess my case is far from being the only one.

Thanks for your time and regards.
Antonio Sánchez.

--------------

From: JSR 220: Enterprise JavaBeansTM,Version 3.0 - Java Persistence API - Final
Release - Pg. 115. 5.3 Obtaining an Entity Manager Factory.

"More than one entity manager factory instance may be available simultaneously
in the JVM.[35]

[35] This may be the case when using multiple databases, since in a typical
configuration a single entity manager only communicates with a single database.
There is only one entity manager factory per persistence unit, however."

Comment by ailitche [ 19/Aug/08 ]

There is a workaround in Eclipselink 1.0 (Eclipselink is a new persistence
provider for GF, it's a superset of TopLink Essentials
http://www.eclipse.org/eclipselink/downloads/)

Eclipselink still doesn't allow multiple EntityManagerFactories corresponding
to the same persistence unit and using different connection string, but it
allows creating EntityManagers with individual connection strings (as long as
the database platform is the same: can't connect on em to Oracle, another to
Sybase).
EntityManagerFactory must be configured to use exclusive isolated connection
for each EntityManager.

Map<String, String> connectProps1 = new HashMap<String, String>();
connectProps1.put(PersistenceUnitProperties.JDBC_USER, "user1");
connectProps1.put(PersistenceUnitProperties.JDBC_PASSWORD,"password1");
// shared cache should not be used - each em has its own cache.
connectProps1.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT,"false");
// exclusive connection should be used by each em.
connectProps1.put
(PersistenceUnitProperties.EXCLUSIVE_CONNECTION_MODE,ExclusiveConnectionMode.Iso
lated);

EntityManagerFactory myemf1 = Persistence.createEntityManagerFactory("default",
connectProps1);

// uses connection properties specified in the factory.
EntityManager em1 = myemf1.createEntityManager();

Map<String, String> connectProps2 = new HashMap<String, String>();
connectProps2.put(PersistenceUnitProperties.JDBC_USER, "user2");
connectProps2.put(PersistenceUnitProperties.JDBC_PASSWORD,"password2");

EntityManager em2 = myemf1.createEntityManager(connectProps2);

Note that because each EntityManager uses its own exclusive connection it must
be explicitly closed when no longer needed to avoid connection leakage.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1570] property for default lazy loading Created: 23/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: mkeith Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,570

 Description   

A number of people have asked for the ability to set the default for all
relationship mappings (not just many-valued ones) to be lazy. A persistence
unit property, such as:

<property
name="toplink.essentials.fetchmode.default.all-relationships-lazy"
value="true"/>

If any relationship were actually specified to have a fetchmode of EAGER then
it would override the default setting.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1440] DefaultTableGenerator should be more pluggable Created: 07/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bjb Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,440

 Description   

This one is blocking because there is no simple way of overriding defaults. For
instance TableDefinition creation. Ths reason is that DefaultTableGenerator has
a method that is getTableDefFromDBTable with private modifier. The method should
have been protected in order to allow overriding by subclass or call a protected
method like :
protected void TableDefinition createTableDefinition(){
return new TableDefition();
}

Having a more pluggable DefaultTableGenerator would mean enabling improvment
into java2db and ease patch submission.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1438] should an empty <id> xml mapping override the annotations on an id field/property Created: 07/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vr143562 Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 1,438

 Description   

Glassfish V2 Build 24.

As per Section 10.1.3.22:
"The id subelement [of <entity><attributes></attributes></entity>] overrides the
mapping for the specified field or property."

Now, consider the scenario where an Entity class E1 exists with @GeneratedValue
and @TableGenerator annotations on its id field and has the following mapping in
the orm.xml
<entity class="E1">
<attributes>
<id name="identifier" />
</attributes>
</entity>
(Note that NO other mapping elements are defined in the orm.xml under <id>;
options do exist to define <generated-value>, <table-generator> etc under <id>)

Current Result: The @GeneratedValue and the @TableGenerator annotations apply on
the id field and are not overridden by the empty children of <id>.

It seems that different persistence providers could decide to either apply the
annotations or have the above <id> mapping override the annotations such that no
mappings apply to the id field. This can make this feature non-portable?

The behaviour of this scenario can be determined after the spec clearly defines it.



 Comments   
Comment by vr143562 [ 12/Nov/06 ]

corrected typo in "Summary" - changed filed to field

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1437] <table-generator> defined under the <id> tag should probably override the @TableGenerator Annotation defined on an Entity Class. Created: 07/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vr143562 Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: Zip Archive tg-under-id-element-override-bug.zip    
Issuezilla Id: 1,437

 Description   

Glassfish V2 Build 24.

As per Section 10.1.3.22:
"The id subelement [of <entity><attributes></attributes></entity>] overrides the
mapping for the specified field or property."

Please note that the overriding rules for the elements under the <id> subelement
are not defined by the spec.

TableGenerators are global to a persistence unit (as per sections 9.1.38,
10.1.2.6 and 10.1.3.12). As a result, a table generator defined using
<entity><attributes><id><table-generator> in a xml mapping file, can be used by
other entities in the same persistence unit.

Therefore, the provider must allow a table generator defined by using
<entity><attributes><id><table-generator> to override a table generator of the
same name defined by using the @TableGenerator Annotation on the Entity class
(as opposed to the id field/property).

This currently results in a Validation Exception that describes a conflict in
Table Generator names between annotations and the xml mapping file.

A test case is attached to this bug to illustrate this. To use the test, define
a environment variable S1AS_HOME that points to glassfish installation dir. Run
the test by invoking "ant se-java2db" from the command-line.



 Comments   
Comment by vr143562 [ 07/Nov/06 ]

Created an attachment (id=573)
unzip the test case and follow the instructions in the first description

Comment by vr143562 [ 12/Nov/06 ]

This is a enhancement request and not a bug. Kindly read all references above to
"must" as "should probably".

thanks.

varun.

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1431] Firebird / Interbase support Created: 06/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bjb Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-1432 java2db not generating proper column ... Open
Issuezilla Id: 1,431

 Description   

A support of Firebird / Interbase has to be brought for GF.

Firebird is the opensource branch of Interbase, quoting their sites :

« Firebird is a relational database offering many ANSI SQL standard features
that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers
excellent concurrency, high performance, and powerful language support for
stored procedures and triggers. It has been used in production systems, under a
variety of names since 1981. »

Firebird is bundled on all Sun Cobalt products.



 Comments   
Comment by bjb [ 06/Nov/06 ]

I've got an early implementation but I am blocked because of bad SQL escaping

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by bjb [ 19/Sep/07 ]

Please either consider either to fix 1432 so that we can contribute our
implementation to GF or if you preffer simply implement the database support on
your own. In both case this will be perfect for us.

Rgs,
JB

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1432] java2db not generating proper column escaping Created: 06/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: bjb Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-1434 Dynamic discovery of JDBC driver capa... Open
depends on GLASSFISH-1431 Firebird / Interbase support Open
Issuezilla Id: 1,432
Status Whiteboard:

LOW


 Description   

According to jdbc, any generated column names you should use
getIdentifierQuoteString() on the java.sql.DatabaseMetaData of the connection to
do name escaping.

Not doing that means that when using "restricted" keywords, the query/DDL will
fail !

Example of impact :
For method appendDBString(...) of class
oracle.toplink.essentials.tools.schemaframework.FieldDefinition instead of
containing :

try {
writer.write(getName());
writer.write(" ");
....

should contain :

try {
writer.write(getName());
writer.write(" ");
....

try {
session.getPlatform().printFieldName(writer, session, name);
writer.write(getName());
writer.write(" ");

This also means that a new method printFieldIdentityClause(...) inside
oracle.toplink.essentials.internal.databaseaccess.DatabasePlatform should be added :

public void printFieldIdentityClause(Writer writer, AbstractSession session,
String fieldName) throws ValidationException {
if (shouldEscapeName())

{ writer.write(getIdentifierQuoteString()); writer.write(name); writer.write(getIdentifierQuoteString()); }

else

{ writer.write(name); }

}

All the method writeField* of the same class has also to be updated in the same
way. Other classes known in toplink essential to create DDL or query should also
use

public boolean shouldEscapeName(){
// false if the connection's meta getIdentifierQuoteString() is null or a
whitespace or throws an exception
// true elsewhere !
}



 Comments   
Comment by marina vatkina [ 09/Nov/06 ]

This is not a p1, as the easy work around would be to specify the identifier
name as "\"XXX\"".

Comment by bjb [ 11/Nov/06 ]

Hi Marina,

First there was a copy/paste error in my example, please see the corrected
example bellow :
«
For method appendDBString(...) of class
oracle.toplink.essentials.tools.schemaframework.FieldDefinition instead of
containing :

try {
writer.write(getName());
writer.write(" ");
....

should contain :

try {
session.getPlatform().printFieldName(writer, session, name);
writer.write(" ");
....
»

Sorry to insist, but I see no way of doing manual quoting of java2db generated
queries from a DatabasePlatform component at this time (see issue's
dependencies) without updating DefaultTableGenerator or FieldDefinition and
TableDefinition. Can you detail the steps you proposed ?

If applicable, any applicable workaround will undoubtly lower the priority of
this issue. But until it is confirmed, as beeing blocking and as per the
priority definition it has to stay a P1.

Please note that auto-quoting should also be applied to TableDefinition name.
There are some update here and there to anticipate as the getFullName() is
sometime used as "full name" (candidate for quoting) and sometime as "name
prefix" as for instance in FK (not candicate for quoting, but should quote the
concatenated result).

Best Regards,
JB

Comment by pkrogh [ 14/Nov/06 ]

Downgrading to a P3 - considering making this an ENHANCEMENT. Escaping names
is not always the right thing to do, as it is more than simply 'protecting'
from reserved words. In many databases it causes the database to enforce case
sensitivity. Always escaping will produce undesirable results. There is no JPA
switch to specify that escaping be used, so it is up the user to determine when
each field should be escaped.

There are a few straight forward solutions:
1. Don't use reserved words. This is by far the approach that I recommend.
2. If you must use reserved words, you will need to escape them yourself as
Marina mentioned. Each time that you specify a reserved word field (in
Annotations or XML) you need to specify it escaped.

I would challenge that this is not a bug, but a feature request as it requires
API beyond what the spec describes to work. This request would need to be
thought out though - would it only apply to defaults? Would fields that are
explicitly defined without the escapes be modified to add them?

Comment by pkrogh [ 14/Nov/06 ]

NOTE: Section 4.4.1 of the Persistence spec recommends against the use of
reserved words.

Comment by bjb [ 14/Nov/06 ]

Hello Poul,

The restricted keywords I am talking about are not part of the list of the
reserved identifier of the list defined by JSR220 on
ejb-3_0-fr-spec-persistence.pdf §4.1.1. These are other keywords, DBMS specific
that according to the JDBC and some DBMS (here Firebird and Interbase) must be
quoted with char specified in the meta data of the JDBC connection to be
accepted and generate valid SQL.

For instance in Interbase/Firebird, the list is
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_reserved
As an example Interbase/Firebird got the folowing as reserved words (to be used
quoted only), SQL reserved words excluded and JPA reserved identifier excluding
: version, password, role, event, file, filter, help, length, second, page,
release, ... My test EAR on FirebirdPlatform has shown 50% of impacted classes
on such cases because of the quite "common-ness" of those words..

I agree escaping is not always the right thing to do. But isn't Platform class
there to let people choose whether it is or it is not needed in their DBMS ?
That is the reason in my example I delegate the call to Plaform, cf :
session.getPlatform().printFieldName(writer, session, name);

This means, default platform
(oracle.toplink.essentials.internal.databaseaccess.DatabasePlatform ) will go on
with usual way (ie, unquote the fields on existing platform) == nothing change
for the rest of the world. But Platform implementer (like me for
Firebird/Interbase), can then override in Platform the field name writing to fit
with their DBMS requirements and their JDBC driver indications.

I am simply asking here for delagation of name field printing in Platform like
it is already done for : printFieldTypeSize, printFieldUnique,
printFieldIdentityClause, printFieldNullClause and printFieldNotNullClause (only
talking about the ones used in the impacted method).

Is there anything wrong with my approach or my understanding of Toplink Essential ?

About your points :
1-"Not using reserved keywords" technique, is not acceptable in real world. If
your software has to be DBMS portable (Java EE5/JPA), how do you know
per-advance that list of "unsupported" keywords without getting rid of the
portability ? All I know is that when using Firebird I have to quote the name
field (or any other name) that are keywords, and that is the job of the code
accesing the JDBC (hence the JPA of toplink). That is all.

2- "escape them yourself" ? As I've previously, how do I do that code speaking?
Touching the entity beans @column name would mean again breaking the
portability. The only solution left is to have a Platform class doing the job.
As mentioned in my earlier post, I got no idea how to do that without having the
name field print delegation to Platform class I asked for. Any working solution
are welcome and would definitively lower the priority of this one.

Anyway, I am fine with this as ENHANCEMENT. But this is still blocking. I've
been told that only blocking issue are P1. This one is blocking me. So I still
think it is P1. If you know anyworkaround that will enable me to create a
Firebird Platform implementation that do what is required to do here

Best Regards,
JB

Comment by marina vatkina [ 20/Nov/06 ]

JB,

You had never told us if explicit escaping doesn't work. Other users were
perfectly fine with specifying column names as e.g. "\"ORDER\"" for the
reserved SQL identifier "ORDER". You'll need to specify it everywhere it will
otherwise default to "ORDER", but otherwise you should be OK.

Do I miss the actual point?

thanks,
-marina

Comment by bjb [ 21/Nov/06 ]

Hi Marina,

True, as suggested by Poul, adding an extra character in persistence.xml will
undoublty add an extra character in any generated SQL string (java2db or jpa) in
persistence.xml. So if the goal was to deploy an EAR to an existing platform,
the sugested workaround would be fine.

But here the goal is to implement a DBMS Platform, a major issue on this
platform is keyword quoting because quoting is not limited to JPA or SQL
keywords but include much more keywords. See previous post on reasons why this
is required and blocking. Feel free to ask for any point for clarification.

In the meanwhile there is the open question, I rephrase :

How do I patch all generated SQL (Java2DB & queries) from a Platfrom class to
include manual quoting so that I can deploy any EAR to this target ?

Answering this will definitively remove the "blocking" tag in this issue.

Best Regards,
JB

Comment by marina vatkina [ 21/Nov/06 ]

Hi JB,

First of all let's clear up the name confusion.
1. His name is Peter .
2. java2db is a mode (from-java-to-database) in which the tables are created in
the database by the TopLink Essentials (TLE) code prior to running the application.

Now to the actual problem. Portability can be from one database to another
database and from one persistence provider to another. If it's the latter, there
is no guarantee that the 2nd provider quotes all identifiers. If it's the
former, different databases have different sets of reserved words and what's
working on one database can easily fail on another.

If the developer understands this complexity, they can add the necessary
overrides in the orm.xml or a user-defined mapping descriptor. (You mention
persistence.xml several times, but it can only point to a different descriptor,
not the actual column and table names, so it's probably a typo).

That said, if you are willing to provide a patch that doesn't break any existing
functionality but solves your problems, we would (after proper review) gladly
accept it .

Best Regards,
-marina

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by pkrogh [ 08/Mar/07 ]

Reprioritized based on BUG triage. P4 LOW.

Comment by bjb [ 19/Mar/07 ]

Downgrading to P4 is not acceptable !

This is blocking a platform support to me, plus this issue is present on most
platform.

This issue is simply about making Toplink Essencial follow the JDBC
specifications. There is something called getIdentifierQuoteString() on JDBC
that must be used when accesing identifiers, toplink has to use it.

Marina explanation is unclear, she writes about portability, right, but use of
getIdentifierQuoteString) has ben specificaly done to do proper escaping on
names so that portability is retained on names whatever database you are working
on (please do correct me if I understand any specification in the wrong way).

So what is the point we are debating here ? My point is simply about making
toplink platform implementation the more JDBC friendly possible. "do not
reinvent the wheel" was the moto sentense at SunTech on this monday in paris,
did I again miss something

Marina, I would be glad to provide a patch, if I had time, and the basic
facility to plug on was there. The problem is that at the place where the
"metadata" access is needed (in the platform), I don't have any idea how to get
them without creating a manual connection This looks bad to me, so I
anticipate ther might be some "big picture" work. Thus, maybe some toplink team
work first. Once the metadata facility is there, I woud be able to use it and
patch the existing code to make use of it and improve existing default platform
implementations ...

Comment by bjb [ 19/Sep/07 ]

Now that v2 is out, we really need this to be fixed for next release.

As a reminder this is required to increase database support of toplink essential.

Rgs,
JB

Comment by pkrogh [ 28/Sep/07 ]

This is not as high priority as a number of the other bugs because there are
many useable work arounds.

This is valid enhancement that we would be happy to help you implement if you
need this asap.

Comment by bjb [ 10/Oct/07 ]

Hello Peter,

What you need to bring is :

  • delagation of any name printing in Platform like
    it is already done for : printFieldTypeSize, printFieldUnique,
    printFieldIdentityClause, printFieldNullClause and printFieldNotNullClause...
    (see example at begin of this issue)
  • optionally (to make portable Platform implementation), access to driver
    metadata from the Platform

Once, done, I'll be glad to implement the rest of those issues.

FYI, the only workaround I know is to use "the freezy-famous JPA
implementation". But, if you know any real world work around with toplink
essential that does not impact all applications code and retain JavaEE
portability, I would be glad to test it too.

Thanks & Regards,
JB

Comment by chris_delahunt [ 27/Nov/07 ]

Hello bjb,

This feature cannot be taken on lightly. Such a feature would brings about
problems with different database versions expanding on "restricted" keywords,
making platform support even more difficult than just handling changing
functions. One database version update may potentially add a key word not
included in the provided platform, breaking any user who would rely on this
feature.

Also, having a field such as
@Basic
String name;
The Spec states the default column NAME. Having it change depending on the
database to default to "NAME" will cause additional portability issues for
Native queries, as "Select name from Employee" is completely different
than "Select \"NAME\" from Employee", and even the results of "Select * from
Employee" would be different. This is discussed in glassfish GLASSFISH-600 in much
more detail. I believe this functionality would be useful, but should be
evaluated and possibly included with the fix for 600.

As with glassfish issue 600, the workarounds for this are to define column
names with quotes instead of relying on the defaults. This will ensure
database portability ie:

@Basic @Column(name="\"NAME\"")
String name;

Or use column names that are less likely to be reserved ie name="name1".

If you wish to generally use the defaults, you can override specific column
names using orm.xml when deploying to databases for columns where the default
is a reserved word - this way no code needs to change.

As for your patch suggestion, your implementation could rely on the platform to
define the identifierQuoteString. There should be no need to get the quote
identifier dynamically from the metadata, or if it is neccessary, set it at
loggin.

Before I include this into 600, can you specify how this relates/depends on
1432?

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1422] Update TableCreators in entity-persistence-tests to use ForeignKeyConstraint object Created: 03/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: guruwons Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,422

 Description   

While fixing issue 1072, FieldDefinition.setForeignKeyFieldName() in schema
framework becomes deprecated and it is recommended to use ForeignKeyConstraint
object which can handle composite foreign key.

TableCreators in entity-persistence-tests testing framework are using only
FieldDefinition.setForeignKeyFieldName() to generate foreign key constraints. It
is required to find the usages of it and convert them to use
ForeignKeyConstraint object and TableDefinition.addForeignKeyConstraint() both
for single field foreign key and composite foreign key constraints.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1420] Allow entity-persistence-tests to automatically clean up Created: 03/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,420

 Description   

The following is a suggestion from Craig Russell that would allow test clean up
to happen in a much more intuitive way:

It might be worthwhile to look at adding some behavior to the toplink
base class JUnitTestCase to allow a subclass to acquire an
EntityManager that will be cleaned up by the tearDown method in the
base class.

Maybe add a protected field EntityManager em to the base class.
Subclass tests could either clean up their own EntityManager using a
try finally pattern or if they assigned the base class em field could
simply throw an exception and exit. At the end of the test, if the em
field is not null, the base class tearDown would clean it up.

This pattern provides for cleaning up the EntityManager without
duplicating or adding code to each test case.

From my experience, it's difficult to look at a test case that does
its own cleanup, because each test writer's ideas of what needs to be
cleaned up tends to be different. Some tests use a try catch where
the catch cleans up, some don't clean up at all, some use try finally.

It's more efficient to have common code that can evolve as our
understanding of how to clean up evolves.



 Comments   
Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1354] Update copyright dates in TopLink Essentials class comments Created: 20/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Task Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,354

 Description   

Source files in TopLink Essentials that have not been changed since 2005 have
the following comment:

// Copyright (c) 1998, 2005, Oracle. All rights reserved.

These files should be updated to reflect the correct year.



 Comments   
Comment by marina vatkina [ 20/Oct/06 ]

...

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1346] some exceptions found by SchemaManager should be reported to the user Created: 19/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,346

 Description   

SchemaManager is designed to ignore exceptions that occur when it is used. The
reason for this design is that ignoring these exceptions allows users to simply
run SchemaManager without knowing the state of their database and not have a
large number of irrelevant exceptions logged. (for instance exceptions that
would occur when we try to drop a table that may not exist)

This behavior potentially masks some legitimate exceptions that occur in JPA
when DDL generation is enabled. (for instance if a field is defaulted to a
reserved word in a database - i.e. a field that is defaulted to number)

We should examine all the places where exceptions can be thrown in
SchemaManager and determine which exceptions that could be thrown are relevant
and which are irrelevant and then warn users when the relevant ones occur.

This option should be configurable.



 Comments   
Comment by tware [ 19/Oct/06 ]

Setting to New

Comment by guruwons [ 17/Nov/06 ]

If there is an error in adding constraints, the following DDL SQLs are not
executed and DDL generation finishes. So generations of another constraints and
sequence tables are skipped.

For example, as you can see below, DDL generation doesn't continue if an error
occurs in adding foreign key constraint.

[TopLink Warning]: 2006.11.17
07:07:26.663-ServerSession(10589182)Thread(Thread[main,5,main])-Exception
[TOPLINK-4002] (Oracle TopLink Essentials - 9.1 (Build $

{build_id}

)):
oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Constraint 'USERENTITYCHILD_ID' is
invalid: there is no unique or primary key constraint on table 'APP.CHILDCLASS'
that matches the number and types of the columns in the foreign key.Error Code: -1
Call:ALTER TABLE USERENTITY ADD CONSTRAINT USERENTITYCHILD_ID FOREIGN KEY
(CHILD_ID) REFERENCES CHILDCLASS (ID)
Query:DataModifyQuery()
[TopLink Finest]: 2006.11.17 07:07:26.669-Thread(Thread[main,5,main])-The
default table generator could not locate or convert a java type (null) into a
database type for database field (USERENTITY.CHILD_ID). The generator uses
java.lang.String as default java type for the field.
[TopLink Finest]: 2006.11.17
07:07:26.698-ServerSession(10589182)Thread(Thread[main,5,main])-end
deploying Persistence Unit pu; state Deployed; deploymentCount 1

I think if we want ignore errors, above case should ignore only the error and
continue to execute another DDL SQLs.

Comment by guruwons [ 17/Nov/06 ]

How about adding a new property like
"toplink.ddl-generation.throw-exception"(tentative name)? If the value is true
and there is an error in CREATE TABLE, ALTER TABLE, etc(other case?) it throws
an exception.

Comment by marina vatkina [ 20/Nov/06 ]

You won't see this problem when running in GF - the code (under cmp module
support/ejb) executes the .jdbc file and collects all the exception messages,
then reports them back to the user. It's always a warning. But in a Java EE
world things are different - there is a difference in deployment vs. execution
and all
the tables can be fixed manually in between or the exceptions can be ignored.

If the current behavior is stop at the 1st problem, it should be changed to
collect all problems. Then the property will help to decide what to do with the
result.

My $.02.

-marina

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1660] LAZY 1:N relationship: adding related entities without loading the whole collection Created: 05/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: vicnov Assignee: tware
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,660

 Description   

From forum: http://forums.java.net/jive/thread.jspa?forumID=56&threadID=20764

In the current code, if I add a new entity to a lazily-loaded collection
(OneToMany relationship), the whole collection is loaded from database.
This is critical when we have many child entities in the collection.

I think that there is no reason to load all child entities (in LAZY
relationship) in order to insert just one entity.

Here is my example (2 entities and a simple test):
///////////////

@Entity
public class ForumTopic {
...
@OneToMany(mappedBy = "topic", fetch = FetchType.LAZY)
private Collection<ForumPost> posts;
...
}

///////////////

@Entity
public class ForumPost {
...
@ManyToOne
private ForumTopic topic;
...
}

///////////////

ForumPost post=new ForumPost();
ForumTopic topic=em.find(...);
Collection<ForumPost> postsInTopic=topic.getPosts();
postsInTopic.add(post);
post.setTopic(topic);
///////////////

When "postsInTopic.add(post)" is being executed, I see that all posts in this
topic are being fully loaded because Toplink Essentials shows the following log:

SELECT ... FROM forum_post WHERE (topic_id = ?)

I tested with glassfish-persistence-installer-v2-b26.jar, also the same behavior
was with "v1" builds.



 Comments   
Comment by jrengifo [ 10/Jan/07 ]
      • Issue 1660 has been confirmed by votes. ***
Comment by mf125085 [ 11/Jan/07 ]

Adding myself to interest list.

Comment by marina vatkina [ 12/Feb/07 ]

resetting the default owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-1606] Add an option to ReadAllQuery to allow it to return multiple references to the same result when used with fetch joining Created: 29/Nov/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tware Assignee: tware
Resolution: Unresolved