[jira] Created: (GERONIMO-5416) After login to Geronimo/Tomcat with j_security_check action, the user is not authenticated to ejb container
After login to Geronimo/Tomcat with j_security_check action, the user is not authenticated to ejb container --- Key: GERONIMO-5416 URL: https://issues.apache.org/jira/browse/GERONIMO-5416 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1.4 Environment: Windows, Linux with jdk 1.5 update 20, Geronimo 2.1.4 with Tomcat Web Container Reporter: Ralf Baumhof Priority: Minor After logging in to geronimo with j_security_check action, the user is authenticated to jsf and his role is known to jsf. But the user is not authenticated to ejb container. See also http://apache-geronimo.328035.n3.nabble.com/j-security-check-jaas-container-managed-security-login-to-tomcat-is-not-forwarde-to-ejb-container-tc921719.html#a921719 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5617) Timestamp precision (scale) openjpa -> Oracle
Timestamp precision (scale) openjpa -> Oracle - Key: GERONIMO-5617 URL: https://issues.apache.org/jira/browse/GERONIMO-5617 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: databases, persistence Affects Versions: 2.1.4 Environment: Geronimo 2.14 with JDK 1.5 update 20, on Window / Linux, Database Oracle 10g or 11 Reporter: Ralf Baumhof Timestamp precision should be up to 10 up -12 (nano second) with Datatype java.sql.Timestamp. On inserts to database only 10 up -3 is inserted. This is done with rounding at position 10 up -3. Example - the log lines beginning with a "#" the value of 5551110 is rounded to 12:16:06.006: 2010-09-21 12:16:06,646 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.646 $$ nanos vor update=64600 2010-09-21 12:16:06,646 INFO - (addition Millisekunden): 1 * 1110222 = 1110222 2010-09-21 12:16:06,646 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.001110222 $$ nanos nach update=1110222 2010-09-21 12:16:06,662 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.662 $$ nanos vor update=66200 2010-09-21 12:16:06,662 INFO - (addition Millisekunden): 2 * 1110222 = 2220444 2010-09-21 12:16:06,662 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.002220444 $$ nanos nach update=2220444 2010-09-21 12:16:06,662 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.662 $$ nanos vor update=66200 2010-09-21 12:16:06,662 INFO - (addition Millisekunden): 3 * 1110222 = 3330666 2010-09-21 12:16:06,662 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.003330666 $$ nanos nach update=3330666 2010-09-21 12:16:06,677 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.677 $$ nanos vor update=67700 2010-09-21 12:16:06,677 INFO - (addition Millisekunden): 4 * 1110222 = 4440888 2010-09-21 12:16:06,677 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.004440888 $$ nanos nach update=4440888 2010-09-21 12:16:06,693 INFO - $$vor update, timestamp.toString=2010-09-21 12:16:06.693 $$ nanos vor update=69300 2010-09-21 12:16:06,693 INFO - (addition Millisekunden): 5 * 1110222 = 5551110 ###2010-09-21 12:16:06,693 INFO - $$nach update, timestamp.toString=2010-09-21 12:16:06.00555111 $$ nanos nach update=5551110 ###2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54852010-09-21 12:16:06.006 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54842010-09-21 12:16:06.004 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54832010-09-21 12:16:06.003 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54822010-09-21 12:16:06.002 2010-09-21 12:16:36,583 INFO - $$ personAnschrift=4425 54812010-09-21 12:16:06.001 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog "Database Pools" because of missing jar files in jar selection listbox.
Unable to deploy Postgres Datasource from console dialog "Database Pools" because of missing jar files in jar selection listbox. Key: GERONIMO-3878 URL: https://issues.apache.org/jira/browse/GERONIMO-3878 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, databases, deployment Affects Versions: 2.1 Environment: Windows XP Professional and Ubuntu Reporter: Ralf Baumhof Trying to deploy a datasource with console dialog "Database Pools". - Select link "Console Navigation/Services/Database Pools". - Select link "Using the geronimo database pool wizard". - Enter some database name like for instance "vesuv" and select as Database Type: "PostgreSQL XA" or "PostgreSQL local". - Click the Next button. - Now, on the page where you specify the properties of the database pool, the listbox where you can select the driver jar is empty. If you choose another database type (on the previous dialog page), the list is filled with all entries from repository. The same steps have been made with Geronimo 2.02. There the database could be deployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog "Database Pools" because of missing jar files in jar selection listbox.
[ https://issues.apache.org/jira/browse/GERONIMO-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573172#action_12573172 ] Ralf Baumhof commented on GERONIMO-3878: As i mentioned in my last sentence "If you choose another database type (on the previous dialog page), the list is filled with all entries from repository". And because i have OF COURSE installed the jdbc driver in the repository, you can see it like all the other jars in repository. This means, if you choose DB2 as database type, you get a lot of entries in the listbox. If you choose Postgres you see really NOTHING ("the listbox where you can select the driver jar is empty") I'am sorry that i did not mention that i installed the Postgres jar driver, because this seemed to be a clear precondition for me. > Unable to deploy Postgres Datasource from console dialog "Database Pools" > because of missing jar files in jar selection listbox. > > > Key: GERONIMO-3878 > URL: https://issues.apache.org/jira/browse/GERONIMO-3878 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Environment: Windows XP Professional and Ubuntu >Reporter: Ralf Baumhof > Original Estimate: 120h > Remaining Estimate: 120h > > Trying to deploy a datasource with console dialog "Database Pools". > - Select link "Console Navigation/Services/Database Pools". > - Select link "Using the geronimo database pool wizard". > - Enter some database name like for instance "vesuv" and select as Database > Type: "PostgreSQL XA" or "PostgreSQL local". > - Click the Next button. > - Now, on the page where you specify the properties of the database pool, > the listbox where you can select the driver jar is empty. If you choose > another database type (on the previous dialog page), the list is filled with > all entries from repository. The same steps have been made with Geronimo > 2.02. There the database could be deployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog "Database Pools" because of missing jar files in jar selection listbox.
[ https://issues.apache.org/jira/browse/GERONIMO-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574508#action_12574508 ] Ralf Baumhof commented on GERONIMO-3878: Yes, that's right. It works if you donwload the driver directly. The dialog first does not work, if you try a test, it fails. But after this first failure, the dialog is ok. It always comes up with the corret postgres specific settings, and more over, the datasource is ok. The application works. But i'am still confused because of the following: - Why this strange behaviour - only for Postgres? With geronimo 2.0.2 you could download the driver separately, and then use the common libs dialog (now called repository) to deploy it. Then you will see it in the jars listbox. This still works - if you use another database type (like DB2). - This workaround is not suitable for a production system. In production we "NEVER" have a internet connection. People in the production system are used to get a jar, and then they deploy it using the dialoge. So, i could use the dialog of an other system with internet connection to create a plan and advice production to deploy the plan. But this will probably result in editing and changing the plan to the preferences of production systems. And this will result in errors. > Unable to deploy Postgres Datasource from console dialog "Database Pools" > because of missing jar files in jar selection listbox. > > > Key: GERONIMO-3878 > URL: https://issues.apache.org/jira/browse/GERONIMO-3878 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Environment: Windows XP Professional and Ubuntu >Reporter: Ralf Baumhof > Original Estimate: 120h > Remaining Estimate: 120h > > Trying to deploy a datasource with console dialog "Database Pools". > - Select link "Console Navigation/Services/Database Pools". > - Select link "Using the geronimo database pool wizard". > - Enter some database name like for instance "vesuv" and select as Database > Type: "PostgreSQL XA" or "PostgreSQL local". > - Click the Next button. > - Now, on the page where you specify the properties of the database pool, > the listbox where you can select the driver jar is empty. If you choose > another database type (on the previous dialog page), the list is filled with > all entries from repository. The same steps have been made with Geronimo > 2.02. There the database could be deployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3892) Persistence.CreateEntityManagerFactory leads to an JNDI Exception in EJB Container
Persistence.CreateEntityManagerFactory leads to an JNDI Exception in EJB Container -- Key: GERONIMO-3892 URL: https://issues.apache.org/jira/browse/GERONIMO-3892 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: naming, OpenEJB, persistence Affects Versions: 2.1, 2.0.2 Environment: Windows XP, Linux (Ubuntu) Reporter: Ralf Baumhof I have got a stateless session bean (ssb) which uses annotation @PersistenceUnit(unitName="Vesuv") protected EntityManagerFactory emf; This works fine. I can instantiate an entity manager and use it's persistence methods. However, the name of the persistence unit may vary in production dependant on the user logged on the the application. So an approach EntityManagerFactory emf = Persistence.CreateEntitiyManagerFactory("Vesuv") is much more suitable. But this statement does not work if i execute it in a class running in the geronimo ejb container (regardless of ssb or not). It works, if i execute it in a servlet in tomcat container. The error message is: "PersistenceException: There was an error during JNDI lookup of the name "Postgres.vesuv". Postgres.vesuv is the name of the datasource which is attached in persistence.xml to the persistence unit "Vesuv". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3878) Unable to deploy Postgres Datasource from console dialog "Database Pools" because of missing jar files in jar selection listbox.
[ https://issues.apache.org/jira/browse/GERONIMO-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574938#action_12574938 ] Ralf Baumhof commented on GERONIMO-3878: Ok, now we have got the things together. It works if: 1.) The group id of the artifact must be "postgresql". 2.) The file extension of the driver archive file must be .jar My file was a .zip archive file and the group id was DB (not postgresql). This does not matter in Geronimo 2.02. Thanks for your help. Perhaps you should mention this somewhere on the PostgreSQL specific datasource properties page. > Unable to deploy Postgres Datasource from console dialog "Database Pools" > because of missing jar files in jar selection listbox. > > > Key: GERONIMO-3878 > URL: https://issues.apache.org/jira/browse/GERONIMO-3878 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Environment: Windows XP Professional and Ubuntu >Reporter: Ralf Baumhof > Original Estimate: 120h > Remaining Estimate: 120h > > Trying to deploy a datasource with console dialog "Database Pools". > - Select link "Console Navigation/Services/Database Pools". > - Select link "Using the geronimo database pool wizard". > - Enter some database name like for instance "vesuv" and select as Database > Type: "PostgreSQL XA" or "PostgreSQL local". > - Click the Next button. > - Now, on the page where you specify the properties of the database pool, > the listbox where you can select the driver jar is empty. If you choose > another database type (on the previous dialog page), the list is filled with > all entries from repository. The same steps have been made with Geronimo > 2.02. There the database could be deployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: persistence Affects Versions: 2.1, 2.0.2 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) 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 org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577805#action_12577805 ] Ralf Baumhof commented on GERONIMO-3907: The same proble occurs, if i correct the annotations, but have an invalid foreign key in one column. The persist method is successfully, and later the commit fails. The call stack, the first line is from the DAO class which reports that the persist method was ok, the last line is from the JSF bean. [de.nrw.hagen.ggrz.bv.benutzer.db.BenutzerDAOImpl] >> $$ BenutzerDAO::generated id = 32 12:36:12,337 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy78.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) 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 org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardC
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577846#action_12577846 ] Ralf Baumhof commented on GERONIMO-3907: More over. Two nearly identical situations. In both cases the insert fails because of invalid foreign keys. In both cases the persist method first does not throw an exception. But in the first case (the working case) there are some additional inserts and updates which may force that the data is written to database a little bit earlier. In this case the exception is visible and catchable at the level of the service fassace. In the second case (the case described above) it is not visible - neither at the service fassade, nor at the JSF bean. This works (the exception can be caught at the service fassade): javax.ejb.EJBTransactionRolledbackException: The transaction has been marked rollback only because the bean encountered a non-application exception :javax.ejb.EJBTransactionRolledbackException : The transaction has been marked rollback only because the bean encountered a non-application exception :org.apache.openjpa.persistence.PersistenceException : The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:348) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:323) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy97.anlegenSchuldnerEintrag(Unknown Source) at de.nrw.hagen.ggrz.vesuv.schuldner.services.SchuldnerServiceManagerImpl.AnlegenSchuldnerJuristischePersonZSV(SchuldnerServiceManagerImpl.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 org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy96.AnlegenSchuldnerJuristischePersonZSV(Unknown Source) at de.nrw.hagen.ggrz.vesuv.schuldner.controler.SRegControlerBean.anlegenJPerson(SRegControlerBean.java:115) 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 org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292) at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterC
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578208#action_12578208 ] Ralf Baumhof commented on GERONIMO-3907: I have just upgraded my geronimo 2.1 with a new openjpa (1.0.2) version. The error is the same. The situation always occurs if you have only one insert on the database. So, the physical insert on database is performed AFTER the stateless session bean is executed (by ejb container on performing the commit with the jta datasource). If i throw an exception by myself it is recognized. Did you try this situation in your environment? The situation does not occur if i have several inserts on dependant objects. In this case OpenJPA writes to database earlier and the exception is thrown during one of the persist calls. The database is a postgresql 8.2 database. Is there a possibility to force OpenJPA always write through to the database on each persist call?? Much thanks in advance!! > Persistence Exception is not visible/lost for client. > -- > > Key: GERONIMO-3907 > URL: https://issues.apache.org/jira/browse/GERONIMO-3907 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0.2, 2.1 > Environment: Linux, Windows >Reporter: Ralf Baumhof >Priority: Blocker > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > I am trying an insert on a table. The Entity class is wrong annotated, one > column was renamed in the table. Then the following situation occurs. > The call to persist(entity) is successfully, no exception is thrown. On > leaving the ejb container and returning to tomact a commit is performed (it's > a managed datasource, so container performs commit). This leads to the insert > on database. This insert fails, a rollback is performed. On return to the JSF > bean no exception can be seen by the bean. In the same class i have got a > query method. If i replace the call to persist with the call to the query > method everything works ok. The exception is thrown and is visible at the > client site. > This is the geronimo console output. The last line comes from the JSB bean > which reports a successful insert. > 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; > transaction will roll back > > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy75.anlegenBenutzer(Unknown Source) > at > de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579354#action_12579354 ] Ralf Baumhof commented on GERONIMO-3907: Of course entityManager.flush() works. But this is not an appropriate solution. We have a big project and we can not rely on the programmers always to write flush after each persist call. What i mean is a configuration setting that always forces the EntityManager to write changes through to databse. I have tried to disable caching but this does not work. Now, i'am currently evaluating: . This seems to work. This means, data in the cache will expire at once. But will there be any serious side effects if we enable this setting I consider this problem as very serious because container transaction managment must be reliable. It's the main point for using an application server. > Persistence Exception is not visible/lost for client. > -- > > Key: GERONIMO-3907 > URL: https://issues.apache.org/jira/browse/GERONIMO-3907 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0.2, 2.1 > Environment: Linux, Windows >Reporter: Ralf Baumhof >Priority: Blocker > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > I am trying an insert on a table. The Entity class is wrong annotated, one > column was renamed in the table. Then the following situation occurs. > The call to persist(entity) is successfully, no exception is thrown. On > leaving the ejb container and returning to tomact a commit is performed (it's > a managed datasource, so container performs commit). This leads to the insert > on database. This insert fails, a rollback is performed. On return to the JSF > bean no exception can be seen by the bean. In the same class i have got a > query method. If i replace the call to persist with the call to the query > method everything works ok. The exception is thrown and is visible at the > client site. > This is the geronimo console output. The last line comes from the JSB bean > which reports a successful insert. > 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; > transaction will roll back > > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy75.anlegenBenutzer(Unknown Source) > at > de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) > 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
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579356#action_12579356 ] Ralf Baumhof commented on GERONIMO-3907: Sorry, i was wrong. The setting does not work. So, if there is no nearby solution for this problem, we must think about stopping the project and first port to an another application container. > Persistence Exception is not visible/lost for client. > -- > > Key: GERONIMO-3907 > URL: https://issues.apache.org/jira/browse/GERONIMO-3907 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0.2, 2.1 > Environment: Linux, Windows >Reporter: Ralf Baumhof >Priority: Blocker > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > I am trying an insert on a table. The Entity class is wrong annotated, one > column was renamed in the table. Then the following situation occurs. > The call to persist(entity) is successfully, no exception is thrown. On > leaving the ejb container and returning to tomact a commit is performed (it's > a managed datasource, so container performs commit). This leads to the insert > on database. This insert fails, a rollback is performed. On return to the JSF > bean no exception can be seen by the bean. In the same class i have got a > query method. If i replace the call to persist with the call to the query > method everything works ok. The exception is thrown and is visible at the > client site. > This is the geronimo console output. The last line comes from the JSB bean > which reports a successful insert. > 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; > transaction will roll back > > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy75.anlegenBenutzer(Unknown Source) > at > de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) > 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 org.apache.el.parser.AstValue.invoke(AstValue.java:131) > at > org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) > at > org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) > at > javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) > at ja
[jira] Created: (GERONIMO-3923) Login established without tomcat notification
Login established without tomcat notification - Key: GERONIMO-3923 URL: https://issues.apache.org/jira/browse/GERONIMO-3923 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1, 2.0.2 Environment: Windows, Linux Reporter: Ralf Baumhof I have set up a security realm (sql realm). In web.xml tomcat is advised to keep a watch an all pages lying in directory /pages. I use a form login. If the login form is designed to use j_security_check action, the servlet authentication works. The first try to access a page in /pages/* area leads to the login form and after successful login the page is diplayed. However, the application has strong security impacts, so we would prefer to use a JSF backing bean which performs a LoginContext method for login to geronimo. This also works. The login succeeds and i get a principal. But the application is not logged in at tomcat webcontainer. It's not possible to access the pages in /pages/* area. Is this a bug or a feature What must be done if one want's to use the LoginContext way??? According to the geronimo wiki i suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3923) Login established without tomcat notification
[ https://issues.apache.org/jira/browse/GERONIMO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Baumhof closed GERONIMO-3923. -- Resolution: Invalid Works as designed > Login established without tomcat notification > - > > Key: GERONIMO-3923 > URL: https://issues.apache.org/jira/browse/GERONIMO-3923 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.0.2, 2.1 > Environment: Windows, Linux >Reporter: Ralf Baumhof >Assignee: David Jencks > > I have set up a security realm (sql realm). In web.xml tomcat is advised to > keep a watch an all pages lying in directory /pages. I use a form login. If > the login form is designed to use j_security_check action, the servlet > authentication works. The first try to access a page in /pages/* area leads > to the login form and after successful login the page is diplayed. However, > the application has strong security impacts, so we would prefer to use a JSF > backing bean which performs a LoginContext method for login to geronimo. This > also works. The login succeeds and i get a principal. But the application is > not logged in at tomcat webcontainer. It's not possible to access the pages > in /pages/* area. Is this a bug or a feature What must be done if one > want's to use the LoginContext way??? According to the geronimo wiki i > suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594577#action_12594577 ] Ralf Baumhof commented on GERONIMO-3907: Today if have tested the new Geronimo release 2.1.1 (published on 28.04.2008). The problem is now fixed. If the server gets an error on trying a commit, this error is now thrown to the web bean. Exception text: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Root Cause: javax.transaction.TransactionRolledbackException : Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: Unable to commit: transaction marked for rollback Unfortunately there is no proper root cause attached to the exception. So the cause can only be seen in the server console, but can not be reported to the user. It would be very nice if you could change this in a later release. Thanks for your help. > Persistence Exception is not visible/lost for client. > -- > > Key: GERONIMO-3907 > URL: https://issues.apache.org/jira/browse/GERONIMO-3907 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.0.2, 2.1 > Environment: Linux, Windows >Reporter: Ralf Baumhof >Assignee: David Jencks >Priority: Blocker > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > I am trying an insert on a table. The Entity class is wrong annotated, one > column was renamed in the table. Then the following situation occurs. > The call to persist(entity) is successfully, no exception is thrown. On > leaving the ejb container and returning to tomact a commit is performed (it's > a managed datasource, so container performs commit). This leads to the insert > on database. This insert fails, a rollback is performed. On return to the JSF > bean no exception can be seen by the bean. In the same class i have got a > query method. If i replace the call to persist with the call to the query > method everything works ok. The exception is thrown and is visible at the > client site. > This is the geronimo console output. The last line comes from the JSB bean > which reports a successful insert. > 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; > transaction will roll back > > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) > at > org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) > at > org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) > at > org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) > at > org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) > at > org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) > at > org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) > at > org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) > at $Proxy75.anlegenBenutzer(Unknown Source) > at > de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.refl
[jira] Commented: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751548#action_12751548 ] Ralf Baumhof commented on GERONIMO-4671: Yes, the datasource is configured as type XA datasource > Error on Oracle XA Datasource deployment or server startup thow the > datasource works correctly > -- > > Key: GERONIMO-4671 > URL: https://issues.apache.org/jira/browse/GERONIMO-4671 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.1.4 > Environment: java 1.6 update 14, windows >Reporter: Ralf Baumhof >Priority: Minor > > We have configured oracle xa datasource with the following settings > (see also > http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245) > User Name: oracleuser(schema name) > Service Name: xe > Password:XXX > Confirm Password: XXX > Port:1521 > Data Source Name: oracle.jdbc.xa.client.OracleXADataSource > Network Protocol: TCP > Database Name: xe > TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = > localhost)(Port = 1521))(CONNECT_DATA = (SID = xe))) > Driver Type: thin > Server Name: localhost > The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, > linux) no errors have been reported. Now we are switching to geronimo 2.1.4 > and during deployment an exception is thrown. This exception is also thrown > on every server startup. > Exception during deployment: > Geronimo Application Server started > 2009-06-03 21:09:45,921 WARN [XSRFHandler] Blocked due to invalid > HttpServletRe > quest parameter. > 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked > HttpServletR > equest due to invalid FORM content. > 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error > javax.transaction.xa.XAException > at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705) > at > org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove > r(WrapperNamedXAResource.java:74) > at > org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM > anager(RecoveryImpl.java:98) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove > rResourceManager(TransactionManagerImpl.java:352) > at > org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe > covery(AbstractConnectionManager.java:70) > at > org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe > r.doStart(ManagedConnectionFactoryWrapper.java:166) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI > nstance.java:998) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j > ava:541) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB > eanDependency.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe > ndency.java:146) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe > ndency.java:120) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve > nt(BasicLifecycleMonitor.java:176) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas > icLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr > oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:294) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G > BeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI > nstance.java:555) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi > cKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio > nGBeans(ConfigurationUtil.java:456) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke > rnelConfigurationManager.java:188) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon > figuration(SimpleConfigurationManager.java:563
[jira] Commented: (GERONIMO-4981) Admin console abnormal when using java security policy
[ https://issues.apache.org/jira/browse/GERONIMO-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828515#action_12828515 ] Ralf Baumhof commented on GERONIMO-4981: On Windows and Ubuntu Linux we have got the same problem with geronimo 2.2. With jdk 1.5 update 20, no error is displayed in log or console. Using jdk 1.6 update 14 the following error msg is displayed: java.lang.SecurityException: Es wird versucht, ein Objekt hinzuzufügen, das keine Instanz von java.security.Principal für eine Principal-Gruppe eines Betreffs ist. at javax.security.auth.Subject$SecureSet.add(Subject.java:1074) at java.util.Collections$SynchronizedCollection.add(Collections.java:1577) at org.apache.catalina.connector.Request.setUserPrincipal(Request.java:1757) at org.apache.geronimo.tomcat.security.SecurityValve.invoke(SecurityValve.java:77) at org.apache.geronimo.tomcat.security.jacc.JACCSecurityValve.invoke(JACCSecurityValve.java:54) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:420) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) The policy file's content is as mentioned: grant { permission java.security.AllPermission; }; and was created with the policy toolkit. The startup statement which forces the error is: set JAVA_OPTS=-Xms96m -Xmx256m -XX:MaxPermSize=128M -DGERONIMO_CONF=/d:/home/geronimo2.2/var/config -Djava.security.manager="java.rmi.RMISecurityManager" -Djava.security.policy=/geronimo2.2/bin/java.policy > Admin console abnormal when using java security policy > -- > > Key: GERONIMO-4981 > URL: https://issues.apache.org/jira/browse/GERONIMO-4981 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.2 > Environment: OS: Linux x86 > Java: java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >Reporter: Forrest Xia > > If you add a file ".java.policy" in your user.home with content as this: > grant{ > permission java.security.AllPermission; > }; > then start geronimo 2.2, you will find the admin console app is abnormal, > there is no need to login, and no navigation bar shows up. > But geronimo 2.1.4 has no such problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly
Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly -- Key: GERONIMO-4671 URL: https://issues.apache.org/jira/browse/GERONIMO-4671 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: persistence Affects Versions: 2.1.4 Environment: java 1.6 update 14, windows Reporter: Ralf Baumhof Priority: Minor We have configured oracle xa datasource with the following settings (see also http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245) User Name: oracleuser(schema name) Service Name: xe Password:XXX Confirm Password: XXX Port:1521 Data Source Name: oracle.jdbc.xa.client.OracleXADataSource Network Protocol: TCP Database Name: xe TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = localhost)(Port = 1521))(CONNECT_DATA = (SID = xe))) Driver Type: thin Server Name: localhost The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, linux) no errors have been reported. Now we are switching to geronimo 2.1.4 and during deployment an exception is thrown. This exception is also thrown on every server startup. Exception: Geronimo Application Server started 2009-06-03 21:09:45,921 WARN [XSRFHandler] Blocked due to invalid HttpServletRe quest parameter. 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked HttpServletR equest due to invalid FORM content. 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error javax.transaction.xa.XAException at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705) at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove r(WrapperNamedXAResource.java:74) at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM anager(RecoveryImpl.java:98) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove rResourceManager(TransactionManagerImpl.java:352) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe covery(AbstractConnectionManager.java:70) at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe r.doStart(ManagedConnectionFactoryWrapper.java:166) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:998) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:541) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:563) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:544) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at o
[jira] Created: (GERONIMO-4672) Managed oracle datasource does not properly perform rollbacks
Managed oracle datasource does not properly perform rollbacks - Key: GERONIMO-4672 URL: https://issues.apache.org/jira/browse/GERONIMO-4672 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: persistence Affects Versions: 2.1.3 Environment: Geronimo 2.1.3 with java 1.5 on linux and windows Reporter: Ralf Baumhof The oracle datasource is configured with the following parameters: Type: thin Transactions: none jar file: ojdbc14.jar from oracle 10g Express db server: oracle 10g express, 11g express and 11g production The application uses OpenJpa for persistence layer. With PostgreSQL database Server all worked fine. When migrating to oracle we discovered that rollback is not properly performed. Test: In one table a column is dropped. The application tries to insert data. This result in an persistence exception. A rollback is performed (that's what the server tells in the log) but data inserted prior to the error point remains comitted. We solved the problem by configuring an XA datasource, but this version should also work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Baumhof updated GERONIMO-4671: --- Description: We have configured oracle xa datasource with the following settings (see also http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245) User Name: oracleuser(schema name) Service Name: xe Password:XXX Confirm Password: XXX Port:1521 Data Source Name: oracle.jdbc.xa.client.OracleXADataSource Network Protocol: TCP Database Name: xe TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = localhost)(Port = 1521))(CONNECT_DATA = (SID = xe))) Driver Type: thin Server Name: localhost The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, linux) no errors have been reported. Now we are switching to geronimo 2.1.4 and during deployment an exception is thrown. This exception is also thrown on every server startup. Exception during deployment: Geronimo Application Server started 2009-06-03 21:09:45,921 WARN [XSRFHandler] Blocked due to invalid HttpServletRe quest parameter. 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked HttpServletR equest due to invalid FORM content. 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error javax.transaction.xa.XAException at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705) at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove r(WrapperNamedXAResource.java:74) at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM anager(RecoveryImpl.java:98) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove rResourceManager(TransactionManagerImpl.java:352) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe covery(AbstractConnectionManager.java:70) at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe r.doStart(ManagedConnectionFactoryWrapper.java:166) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:998) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:541) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:563) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:544) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(Refl ectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionIn
[jira] Commented: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716533#action_12716533 ] Ralf Baumhof commented on GERONIMO-4671: As in geronimo 2.1.3 the datasource was configured through console dialog. During deployment the first exception is thrown. > Error on Oracle XA Datasource deployment or server startup thow the > datasource works correctly > -- > > Key: GERONIMO-4671 > URL: https://issues.apache.org/jira/browse/GERONIMO-4671 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.1.4 > Environment: java 1.6 update 14, windows >Reporter: Ralf Baumhof >Priority: Minor > > We have configured oracle xa datasource with the following settings > (see also > http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245) > User Name: oracleuser(schema name) > Service Name: xe > Password:XXX > Confirm Password: XXX > Port:1521 > Data Source Name: oracle.jdbc.xa.client.OracleXADataSource > Network Protocol: TCP > Database Name: xe > TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = > localhost)(Port = 1521))(CONNECT_DATA = (SID = xe))) > Driver Type: thin > Server Name: localhost > The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, > linux) no errors have been reported. Now we are switching to geronimo 2.1.4 > and during deployment an exception is thrown. This exception is also thrown > on every server startup. > Exception during deployment: > Geronimo Application Server started > 2009-06-03 21:09:45,921 WARN [XSRFHandler] Blocked due to invalid > HttpServletRe > quest parameter. > 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked > HttpServletR > equest due to invalid FORM content. > 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error > javax.transaction.xa.XAException > at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705) > at > org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove > r(WrapperNamedXAResource.java:74) > at > org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM > anager(RecoveryImpl.java:98) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove > rResourceManager(TransactionManagerImpl.java:352) > at > org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe > covery(AbstractConnectionManager.java:70) > at > org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe > r.doStart(ManagedConnectionFactoryWrapper.java:166) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI > nstance.java:998) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:268) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j > ava:541) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB > eanDependency.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe > ndency.java:146) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe > ndency.java:120) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve > nt(BasicLifecycleMonitor.java:176) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas > icLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr > oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:294) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G > BeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI > nstance.java:555) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi > cKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio > nGBeans(ConfigurationUtil.java:456) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke > rnelConfigurationManager.java:188) > at > org.apache.geronimo.kernel.config.SimpleConfigur