Welcome Guest  |  Register  |  Login
Login Name Password
  Search  
  Index  | Recent Threads  | Unanswered Threads  | Who's Online  | User List  | Help

  DataNucleus Forum
  Category: DataNucleus Support
  Forum: Environment : J2EE
  Thread: JPOX 1.1.0 RAR in Glassfish

Quick Go »

No member browsing this thread
Thread Status: Active
Total posts in this thread: 10
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 3755 times and has 9 replies Next Thread
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
JPOX 1.1.0 RAR in Glassfish
Hello,

has anyone had any luck integrating the JPOX RAR with Glassfish and could post their experience?

I've been running into some problems but managed to solve them with the help of the documentation and this forum. But now I'm stuck and have no clue how to proceed. I would really appreciate any comments / pointers / etc.

I am trying to use JPOX 1.1.0 integrated via JCA with Glassfish (build 48) and Derby. I have EJB 3.0 session beans running with CMT, accessing the JPOX-provided PMF through JNDI look-up.

My ra.xml file inside the RAR has the following transaction setting:
<resourceadapter>
...
<transaction-support>XATransaction</transaction-support>
...
</resourceadapter>

(I do need XA transactions.)

I heave learned that when JPOX is used with XA transactions, it needs two data source connections: one supporting XA transactions and the other supporting non-XA transactions. So I configure my "Connector Connection Pool" with these two properties (and nothing more):
ConnectionFactoryName = myXaDsName
ConnectionFactory2Name = myDsName

The first JNDI name is bound to a org.apache.derby.jdbc.EmbeddedXADataSource type data source, the other type is org.apache.derby.jdbc.EmbeddedDataSource.

The problem is that every time a transaction involving some operations on the PersistenceManager is to be commited I get a mysterious NoSuchElementException. The following stack trace is a result of calling a simplistic business method that does nothing more than call PersistenceManager's getObjectById() (please ignore the method names in the motoforge.domain.logic package -- they are currently meaningless).
JTS5067: Unexpected error occurred in commit
java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(AbstractList.java:427)
at org.jpox.resource.ManagedConnectionImpl.getPMHandle(ManagedConnectionImpl.java:492)
at org.jpox.state.StateManagerImpl.getPersistenceManager(StateManagerImpl.java:1149)
at motoforge.domain.EngineModel.jdoGetPersistenceManager(EngineModel.java)
at org.jpox.AbstractPersistenceManager.findStateManager(AbstractPersistenceManager.java:3035)
at org.jpox.AbstractPersistenceManager.disconnectSMCache(AbstractPersistenceManager.java:603)
at org.jpox.resource.ManagedConnectionImpl.preCommit(ManagedConnectionImpl.java:426)
at org.jpox.resource.ManagedTransaction.commit(ManagedTransaction.java:351)
at org.jpox.resource.ManagedConnectionImpl.commit(ManagedConnectionImpl.java:522)
at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:101)
at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:767)
at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2077)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:388)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:234)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:608)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:296)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:9
99)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:383
)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3653)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3445)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1247)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:1
92)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandle
rDelegate.java:71)
at $Proxy43.initDb(Unknown Source)
at motoforge.domain.logic.ejb.HqManagerBean.initDb(HqManagerBean.java:49)
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:585)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:1
84)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandle
rDelegate.java:71)
at $Proxy41.initDb(Unknown Source)
at motoforge.web.EngineOrderController.initDb(EngineOrderController.java:233)
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:585)
at com.sun.el.parser.AstValue.invoke(AstValue.java:151)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:283)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapt
er.java:71)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:95)
at javax.faces.component.UICommand.broadcast(UICommand.java:384)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:452)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:764)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:266)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)

Any thoughts?
Thanks in advance!

Wojtek
----------------------------------------
[Edit 1 times, last edit by wojtek at May 17, 2006 6:29:19 PM]
[May 17, 2006 6:26:50 PM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
Male erik
Expert
Member's Avatar

Belgium
Joined: Mar 12, 2004
Post Count: 3114
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
never tried. raise a task request to certify JPOX JCA compatibility with Glassfish
----------------------------------------
Erik Bengtson
[May 20, 2006 8:14:40 AM] Show Printable Version of Post    View Member Profile    Send Private Message    Hidden to Guest [Link] Report threatening or abusive post: please login first  Go to top 
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Erik,

thanks for your response!
never tried. raise a task request to certify JPOX JCA compatibility with Glassfish

I must admit you're kinda scaring me here. So I may be the first to try this combination...? :)

Well anyway, in the meantime I continued with my experiments and the most recent discovery is that things seem to work fine (well, almost) if I do not close the PersistenceManager before the transaction is committed. So in the following flow:

  • Begin the transaction (CMT -- the container does this)
  • Obtain the PM from the PMF
  • Do something with the PM
  • Call pm.close()
  • Commit the transaction (CMT -- the container does this)
I seem to be forced to skip step 4. Is this what you would expect?

If I do skip it, I easily get
You are trying to get the PersistenceManager for an object when it is associated with X PersistenceManager(s)!
entries in the JPOX log, with X increasing with each one transaction.

Any suggestions?

If you don't mind, I will refrain from raising a task request to certify JPOX JCA compatibility with Glassfish until I'm more convinced that I'm not doing some fundamentally wrong here.

Wojtek
[May 20, 2006 12:01:41 PM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Well, the flow described above is what I've always seen in examples showing how JDO is used in a JEE environment. Now I have also checked the JDO spec and section 16.1.1 seems to confirm that pm.close() should indeed be called:
At the end of the business method, the PersistenceManager instance must be closed. This allows the transaction completion code in the PersistenceManager to free the instance and return it to the available pool in the PersistenceManagerFactory.


I actually came across another problem. Unfortunately I cannot say if it appears in application servers other than Glassfish. The problem is with including certain plugins in the RAR. I tried the Java5 plugin and couldn't get it to map Enums the way it was supposed to. What I found out is that Glassfish unpacks all the JARs contained in the RAR into one location. If the contents of the JARs overlap, things get overwritten. In this case, the contents of the META-INF/plugins directory provided by JPOX core and the plugin, which -- if I understand correctly -- are normally somehow "merged" at runtime, overwrote one another. I managed to achieve my goal by manually merging the datastoremapping.xml and jpoxtypes.xml files from the core and the plugin JARs, but it shouldn't work this way, should it?

Is this also an issue subject to Glassfish compatibility certification?

Other than that, the deeper I dig into JPOX, the more impressed I am. Good work!

Wojtek
[May 23, 2006 8:54:24 PM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
Male erik
Expert
Member's Avatar

Belgium
Joined: Mar 12, 2004
Post Count: 3114
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
For the unpacking thing raise the issue to the Glassfish project.

For the closing issue, I suggest you to disable reachability at commit as workaround. Anyway, if you dont need reachability at commit, you should always disable it to improve performance.
----------------------------------------
Erik Bengtson
[May 23, 2006 9:20:40 PM] Show Printable Version of Post    View Member Profile    Send Private Message    Hidden to Guest [Link] Report threatening or abusive post: please login first  Go to top 
Male sivakumart
Newbie




Joined: May 23, 2006
Post Count: 1
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Hi


I actually came across another problem. Unfortunately I cannot say if it appears in application servers other than Glassfish. The problem is with including certain plugins in the RAR. ... What I found out is that Glassfish unpacks all the JARs contained in the RAR into one location. If the contents of the JARs overlap, things get overwritten.


Are you referring to the case when a RAR has foo.jar and bar.jar, deployment of the connector module explodes the RAR and its constituent jars into ${domaindir}/applications/j2ee-modules/${rarname} causes common classes (ie common fully qualified class names) in foo and bar to be overwritten? If yes,this is how they behave in GlassFish by design. If I have misunderstood this issue, please send a mail to to the users mailing list at GlassFish [users@glassfish.dev.java.net] and/or raise an issue and we would be glad to understand this better.

Thanks
--Siva.
GlassFish Team
[May 23, 2006 10:41:17 PM] Show Printable Version of Post    View Member Profile    Send Private Message    Hidden to Guest [Link] Report threatening or abusive post: please login first  Go to top 
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Hallo,

Are you referring to the case when a RAR has foo.jar and bar.jar, deployment of the connector module explodes the RAR and its constituent jars into ${domaindir}/applications/j2ee-modules/${rarname} causes common classes (ie common fully qualified class names) in foo and bar to be overwritten?

Yes, this is precisely what I meant. Except in this case it is not really classes that are overwritten, but the META-INF/plugins/datastoremapping.xml and META-INF/plugins/jpoxtypes.xml files provided by both the JPOX core and the Java5 plugin JARs.

If yes,this is how they behave in GlassFish by design.

So this probably means that changing it is out of the question.

Erik, any chance for plugin "registration" to be changed in JPOX?

Wojtek
[May 24, 2006 8:39:17 AM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
Male erik
Expert
Member's Avatar

Belgium
Joined: Mar 12, 2004
Post Count: 3114
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
we can provide a pmf setting where you set the location of the files separated by a comma.

However, the way glassfish is handling the deployment, at runtime, will consume too many operating system file descriptors which can cause errors.

When the application server use a compressed file like a rar, instead of expanding it, only one file descriptor is used.

If you don't have file descriptors available, the JVM can crash, other processes running on the same machine can also crash, and other problems can pop up. If the JVM crashes and no file descriptors are available, you even dont get a core dump of the JVM.
----------------------------------------
Erik Bengtson
[May 24, 2006 10:02:25 AM] Show Printable Version of Post    View Member Profile    Send Private Message    Hidden to Guest [Link] Report threatening or abusive post: please login first  Go to top 
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Hi Erik,
For the closing issue, I suggest you to disable reachability at commit as workaround. Anyway, if you dont need reachability at commit, you should always disable it to improve performance.

I tried:
PersistenceByReachabilityAtCommit=false
It doesn't seem to help at all. First, I get a
INFO [JPOX.JDO] - <You are trying to get the PersistenceManager for an object when it is associated with 0 PersistenceManager(s)!>
and then the NoSuchElementException.

Wojtek
[May 24, 2006 6:57:41 PM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
Male wojtek
Newbie




Joined: May 17, 2006
Post Count: 16
Status: Offline
Reply to this Post  Reply with Quote 
Re: JPOX 1.1.0 RAR in Glassfish
Hello again,

I've noticed something new here. The behavior with the inability to properly close a PM is occurring if the PMF is obtained by the stateless session beans in the following way:
protected PersistenceManagerFactory pmf;
// ...
@PostConstruct
private void initPersistenceManagerFactory() {
try {
InitialContext ctx = new InitialContext();
pmf = (PersistenceManagerFactory) ctx.lookup("jdo/pmf");
} catch (NamingException e) {
throw new RuntimeException(e);
}
}
where "jdo/pmf" is the JNDI name of my JPOX connector resource. I began to wonder if this really is the right way to do that, and I tried this instead:
@Resource(mappedName="jdo/pmf")
protected PersistenceManagerFactory pmf;
This time, I first got a
[#|2006-06-20T10:40:04.914+0200|INFO|sun-appserver-pe9.0|javax.enterprise.resource.resourceadapter
|_ThreadID=19;_ThreadName=httpWorkerThread-8080-0;
|RAR7099: The mcf being used to allocate the connection and the MCF in the pool are not equal.|#]
and then
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean;
nested exception is: javax.jdo.JDOException: Problem getting PersistenceManager:
NestedThrowables:
javax.resource.spi.ResourceAllocationException: Error in allocating a connection.
Cause: No credentials found for ManagedConnectionFactory: org.jpox.resource.ManagedConnectionFactoryImpl@1c6d169
javax.jdo.JDOException: Problem getting PersistenceManager:
at org.jpox.resource.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.
java:181)
at motoforge.domain.dao.ejb.EngineOrderDaoBean.getEngineOrders(EngineOrderDaoBean.java:33)
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:585)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:1
84)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandle
rDelegate.java:71)
at $Proxy58.getEngineOrders(Unknown Source)
at motoforge.domain.logic.ejb.HqManagerBean.getEngineOrders(HqManagerBean.java:34)
...
(the stack trace goes on and on, if you think you need it, I will post the rest of it).

This leads me to suspect that maybe there's something wrong with my deployment? Does anyone have any ideas?

Thanks,
Wojtek
[Jun 20, 2006 8:51:53 AM] Show Printable Version of Post    View Member Profile    Send Private Message [Link] Report threatening or abusive post: please login first  Go to top 
[ Jump to Last Post ]
Show Printable Version of Thread  Post new Thread

RSS feeds Current timezone is GMT
Sep 3, 2010 4:41:17 PM

Powered by mvnForum 1.2.1 GA (Build: 20 November 2008)
Copyright © 2002-2008 by MyVietnam.net