[BUILD] trunk: Failed for Revision: 735207
Geronimo Revision: 735207 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090116/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090116
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 38 seconds
[INFO] Finished at: Fri Jan 16 21:42:09 EST 2009
[INFO] Final Memory: 643M/986M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090116/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.275
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:00.587)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:27.881)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.147)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:15.692)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:22.817)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:18.773)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:41.866)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.466)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:56.460)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:40.198)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:31.134)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:28.513)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:31.523)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.272)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.214)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:48.654)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.313)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:47.376)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:36.702) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:28.708)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Updated: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-559: --- Description: It seems that as a result of GERONIMODEVTOOLS-521 our jar(s) are signed. However as they are now they may likely cause more confusion with the end-user, rather then instill confidence. When the Eclipse installer discovers they are signed it asks the end-user if they trust the certificate(s). The one for the GEP feature displays too many nulls -- these values should be populated to mitigate possible confusion. I'll attach a screenshot to show what exactly I mean.(was: It seems that as a result of GERONIMODEVTOOLS-521 are feature jar(s) are signed. However as they are now they may likely cause more confusion with the end-user, rather then instill confidence. When the Eclipse installer discovers they are signed it asks the end-user if they trust the certificate(s). The one for the GEP feature displays too many nulls -- these values should be populated to mitigate possible confusion. I'll attach a screenshot to show what exactly I mean. ) > GEP signed feature jar(s) should not display nulls when asking the user if > they "trust" the certificate(s) > -- > > Key: GERONIMODEVTOOLS-559 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Delos Dai > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > It seems that as a result of GERONIMODEVTOOLS-521 our jar(s) are signed. > However as they are now they may likely cause more confusion with the > end-user, rather then instill confidence. When the Eclipse installer > discovers they are signed it asks the end-user if they trust the > certificate(s). The one for the GEP feature displays too many nulls -- these > values should be populated to mitigate possible confusion. I'll attach a > screenshot to show what exactly I mean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-559: --- Attachment: screenshot-2.jpg Also, the certificate should be valid much longer than 30 days that is shown in screenshot #2. > GEP signed feature jar(s) should not display nulls when asking the user if > they "trust" the certificate(s) > -- > > Key: GERONIMODEVTOOLS-559 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Delos Dai > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > It seems that as a result of GERONIMODEVTOOLS-521 are feature jar(s) are > signed. However as they are now they may likely cause more confusion with the > end-user, rather then instill confidence. When the Eclipse installer > discovers they are signed it asks the end-user if they trust the > certificate(s). The one for the GEP feature displays too many nulls -- these > values should be populated to mitigate possible confusion. I'll attach a > screenshot to show what exactly I mean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4501) Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
[
https://issues.apache.org/jira/browse/GERONIMO-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664757#action_12664757
]
Jarek Gawor commented on GERONIMO-4501:
---
I committed fixes to trunk (revision 735186) that make Axis2-based services
recognize the OASIS catalogs. I also added basic tests to exercise the OASIS
catalog support (revision 735188).
These changes should make the reported problem go away but I still need to
investigate/work on the OASIS catalog support for service references.
> Tomcat/Axis ignores jax-ws-catalog.xml while resolving wsdlLocation URLs
>
>
> Key: GERONIMO-4501
> URL: https://issues.apache.org/jira/browse/GERONIMO-4501
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.2
> Environment: Geronimo 2.2-SNAPSHOT, Tomcat/Axis
>Reporter: Janko Heilgeist
>Assignee: Jarek Gawor
>
> The problem description's context is identical to GERONIMO-4500 for the
> Jetty/CXF assembly. This time the catalog is completely ignored while
> resolving the wsdlLocation URL. The exception is:
> {noformat}
> 2009-01-07 17:45:17,701 ERROR [GBeanInstanceState] Error while starting;
> GBean is now in the FAILED state:
> abstractName="default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car?EJBModule=default/geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar/1231346713744/car,J2EEApplication=null,StatelessSessionBean=HelloWorldServiceEJB,j2eeType=WSLink,name=HelloWorldServiceEJB"
> java.io.FileNotFoundException: http://example.com/HelloWorld.wsdl
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
> at java.net.URL.openStream(URL.java:1007)
> at
> org.apache.geronimo.axis2.AxisServiceGenerator.readWSDL(AxisServiceGenerator.java:302)
> at
> org.apache.geronimo.axis2.AxisServiceGenerator.getServiceFromWSDL(AxisServiceGenerator.java:141)
> at
> org.apache.geronimo.axis2.Axis2WebServiceContainer.init(Axis2WebServiceContainer.java:145)
> at
> org.apache.geronimo.axis2.ejb.EJBWebServiceContainer.init(EJBWebServiceContainer.java:56)
> at
> org.apache.geronimo.axis2.ejb.EJBWebServiceGBean.(EJBWebServiceGBean.java:70)
> ...
> {noformat}
> The workaround that helped in the case of the Jetty/CXF assembly does not
> work with Tomcat/Axis.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-559: --- Attachment: screenshot-1.jpg > GEP signed feature jar(s) should not display nulls when asking the user if > they "trust" the certificate(s) > -- > > Key: GERONIMODEVTOOLS-559 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0, 2.1.4 >Reporter: Tim McConnell >Assignee: Delos Dai > Attachments: screenshot-1.jpg > > > It seems that as a result of GERONIMODEVTOOLS-521 are feature jar(s) are > signed. However as they are now they may likely cause more confusion with the > end-user, rather then instill confidence. When the Eclipse installer > discovers they are signed it asks the end-user if they trust the > certificate(s). The one for the GEP feature displays too many nulls -- these > values should be populated to mitigate possible confusion. I'll attach a > screenshot to show what exactly I mean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-559) GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s)
GEP signed feature jar(s) should not display nulls when asking the user if they "trust" the certificate(s) -- Key: GERONIMODEVTOOLS-559 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-559 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Reporter: Tim McConnell Assignee: Delos Dai Attachments: screenshot-1.jpg It seems that as a result of GERONIMODEVTOOLS-521 are feature jar(s) are signed. However as they are now they may likely cause more confusion with the end-user, rather then instill confidence. When the Eclipse installer discovers they are signed it asks the end-user if they trust the certificate(s). The one for the GEP feature displays too many nulls -- these values should be populated to mitigate possible confusion. I'll attach a screenshot to show what exactly I mean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664741#action_12664741 ] Tim McConnell commented on GERONIMODEVTOOLS-535: Hi Delos, thanks very much for working on this. However, I cannot commit the patch just yet for a couple of reasons 1) The patch works reasonably well with RAD 7.5 in that I can install the GEP from an update site (I used our unstable update site) using the RAD Software updates. I was also able to uninstall the GEP after installing it which is obviously good. However, the Geronimo branding does not show up under the "Help --> About Rational ..." like it does when installing the GEP into a base Eclipse Ganymede installation. As far as I know, RAD will allow our Geronimo branding, and it's important that we get it to display if at all possible so that users know they have installed the Geronimo server adapter and can easily view the included feature(s) and plugin(s). Usually when the branding doesn't work it's a good indication that the corresponding feature(s) were not installed correctly. 2) The patch does not work at all with RAD 7.5.1. Here are the errors below: Cannot complete the request. See the details. Unsatisfied dependency: [org.eclipse.jst.enterprise_ui.feature.feature.group 3.0.3.v200810010400-7Y7BFSrEPOwQPnUuwhYV60NEQtTn] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.jst.j2ee.ui/[1.1.204.v200811041823,1.1.204.v200811041823] Unsatisfied dependency: [org.eclipse.jdt.feature.group 3.4.1.r341_v20080709-0800-7o7tEAfEF_U5qyUgrb2HAp539P97] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.jdt.core/[3.4.2.v_883_R34x,3.4.2.v_883_R34x] Unsatisfied dependency: [org.eclipse.platform.feature.group 3.4.1.r341_v20080731-9I96EiDElYevwz-p1bP5z-NlAaP7vtX6Utotqsu] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.ui.views/[3.3.0.I20080509-2000,3.3.0.I20080509-2000] Unsatisfied dependency: [org.eclipse.jdt.feature.group 3.4.1.r341_v20080709-0800-7o7tEAfEF_U5qyUgrb2HAp539P97] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.jdt.compiler.tool/[1.0.100.v_883_R34x,1.0.100.v_883_R34x] Unsatisfied dependency: [org.eclipse.jst.web_core.feature.feature.group 3.0.3.v200810020322-7M7AEX2EFp_acwkiuz-bTpl] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.jst.j2ee/[1.1.204.v200811130630,1.1.204.v200811130630] Unsatisfied dependency: [org.eclipse.platform.feature.group 3.4.1.r341_v20080731-9I96EiDElYevwz-p1bP5z-NlAaP7vtX6Utotqsu] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.core.resources/[3.4.1.R34x_v20080902,3.4.1.R34x_v20080902] Unsatisfied dependency: [org.eclipse.help.feature.group 1.0.1.R34x_v20080827-7r7xEIxEI6Zu5nEqN7M3UBpglaat] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.help.base/[3.3.101.M20080728_34x,3.3.101.M20080728_34x] Unsatisfied dependency: [org.eclipse.wst.xml_ui.feature.feature.group 3.0.3.v200809292000-7F2ENZCwum8U9-9yPhHnPkSb2VAc] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.wst.common_ui.feature.feature.group/[3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX,3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX] Cannot find a solution where both "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUuV8Y]" and "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX]" are satisfied. Cannot find a solution where both "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUuV8Y]" and "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX]" are satisfied. Cannot find a solution where both "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUuV8Y]" and "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX]" are satisfied. Cannot find a solution where both "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUuV8Y]" and "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX]" are satisfied. Cannot find a solution where both "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUuV8Y]" and "org.eclipse.wst.common_ui.feature.feature.group [3.0.3.v200809301154-7C78ELcE8VrRVouGlyiT4DsUtVAX]" are satisfied. Unsatisfied dependency: [org.eclipse.wst.ws_core.feature.feature.group 3.0.3.v200810012109-7H7QECgED69XqKg9nufm2_7C5J] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.platform.feature.group/[3.4.0,4.0.0) Unsatisfied dependency: [org.eclipse.wst.web_ui.feature.feature.group 3.0.3.v200810010400-7R0EOzE8Ks9uCz0nqrQF6yCFSQyI] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.wst.common_ui.feature.feature.group/[3.
[jira] Updated: (GERONIMO-4482) a few improvements on XAExceptions during enlist resource, prepare, commit, rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4482: -- Affects Version/s: 2.1.4 > a few improvements on XAExceptions during enlist resource, prepare, commit, > rollback > > > Key: GERONIMO-4482 > URL: https://issues.apache.org/jira/browse/GERONIMO-4482 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > 1. during enlist resource, if there is XAException arisen, we should mark > status as rollback only because the enlist resource failed. > 2. during commit, convert XAER_RMERR, XAER_PROTO & XAER_INVAL to system > exceptions. > 3. if system exceptions arisen during internal prepare, we should roll back > the resource(s). > 4. during rollback, if XA_RBROLLBACK, XAER_RMERR,XAER_NOTA & XAER_RMFAIL > arisen, we expect the transaction to be rolled back eventually thus don't > throw anything. During commit, we throw rollback exceptions for these. > 5. if XAER_NOTA arisen from forget, means the resource already forgot the > transaction, thus we don't throw any exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4482) a few improvements on XAExceptions during enlist resource, prepare, commit, rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4482. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits tab > a few improvements on XAExceptions during enlist resource, prepare, commit, > rollback > > > Key: GERONIMO-4482 > URL: https://issues.apache.org/jira/browse/GERONIMO-4482 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > 1. during enlist resource, if there is XAException arisen, we should mark > status as rollback only because the enlist resource failed. > 2. during commit, convert XAER_RMERR, XAER_PROTO & XAER_INVAL to system > exceptions. > 3. if system exceptions arisen during internal prepare, we should roll back > the resource(s). > 4. during rollback, if XA_RBROLLBACK, XAER_RMERR,XAER_NOTA & XAER_RMFAIL > arisen, we expect the transaction to be rolled back eventually thus don't > throw anything. During commit, we throw rollback exceptions for these. > 5. if XAER_NOTA arisen from forget, means the resource already forgot the > transaction, thus we don't throw any exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4478) enhance exception handling during transaction rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4478: -- Affects Version/s: 2.1.4 > enhance exception handling during transaction rollback > -- > > Key: GERONIMO-4478 > URL: https://issues.apache.org/jira/browse/GERONIMO-4478 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Currently, for any XAException arisen, we convert it to SystemException. > 1. If the exception is XAException.XA_HEURRB (which means transcation has > been heuristically rolled back), we should not throw any exception as the > resulting behavior is same as expected behavior. > 2. JTA seems to assume that exceptions are not possible to be HEURMIX or > HEURCOM or HEURHAZ (JTA doesn't define any heursitic exceptions thrown from > the tm.rollback() method) so we'll just convert them to SystemException as it > is today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4471) improve heuristic exception handling in rollback when txmanager.commit is called
[ https://issues.apache.org/jira/browse/GERONIMO-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4471: -- Affects Version/s: 2.1.4 Fix Version/s: 2.1.4 > improve heuristic exception handling in rollback when txmanager.commit is > called > > > Key: GERONIMO-4471 > URL: https://issues.apache.org/jira/browse/GERONIMO-4471 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Improve heuristic exception handling during rollback, when txmanager.commit > is called by providing a rollbackResourcesDuringCommit method to throw > appropriate heuristic exceptions. The logic is: > 1. If XAException.XA_HEURRB arisen from XAResource rollback, this means > transaction has been heuristically rolled back, thus we just throw normal > RollbackException. > 2. If XAException.XA_HEURMIX arisen from XAResource rollback, this means > transaction has been heuristically rolled back and committed, thus we just > throw HeuristicMixedException. > 3. If XAException.XA_HEURCOM arisen from XAResource rollback, this means > transaction has been heuristically committed. In this case, if transaction > has ever been committed (via other XAResources enlisted), then we throw > HeuristicMixedException. > 4. Other XAExceptions, throw SystemExceptions. > 5. If no specific XAException or only XAException.XA_HEURRB, throw > RollbackException. > The rollbackResourcesDuringCommit method will be used during the commit > context instead of the current rollbackResources method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4478) enhance exception handling during transaction rollback
[ https://issues.apache.org/jira/browse/GERONIMO-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4478. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits. > enhance exception handling during transaction rollback > -- > > Key: GERONIMO-4478 > URL: https://issues.apache.org/jira/browse/GERONIMO-4478 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Currently, for any XAException arisen, we convert it to SystemException. > 1. If the exception is XAException.XA_HEURRB (which means transcation has > been heuristically rolled back), we should not throw any exception as the > resulting behavior is same as expected behavior. > 2. JTA seems to assume that exceptions are not possible to be HEURMIX or > HEURCOM or HEURHAZ (JTA doesn't define any heursitic exceptions thrown from > the tm.rollback() method) so we'll just convert them to SystemException as it > is today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4471) improve heuristic exception handling in rollback when txmanager.commit is called
[ https://issues.apache.org/jira/browse/GERONIMO-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4471. --- Resolution: Fixed see subversion commits tab > improve heuristic exception handling in rollback when txmanager.commit is > called > > > Key: GERONIMO-4471 > URL: https://issues.apache.org/jira/browse/GERONIMO-4471 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Improve heuristic exception handling during rollback, when txmanager.commit > is called by providing a rollbackResourcesDuringCommit method to throw > appropriate heuristic exceptions. The logic is: > 1. If XAException.XA_HEURRB arisen from XAResource rollback, this means > transaction has been heuristically rolled back, thus we just throw normal > RollbackException. > 2. If XAException.XA_HEURMIX arisen from XAResource rollback, this means > transaction has been heuristically rolled back and committed, thus we just > throw HeuristicMixedException. > 3. If XAException.XA_HEURCOM arisen from XAResource rollback, this means > transaction has been heuristically committed. In this case, if transaction > has ever been committed (via other XAResources enlisted), then we throw > HeuristicMixedException. > 4. Other XAExceptions, throw SystemExceptions. > 5. If no specific XAException or only XAException.XA_HEURRB, throw > RollbackException. > The rollbackResourcesDuringCommit method will be used during the commit > context instead of the current rollbackResources method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4449) Transaction.rollback method also calls beforeCompletion
[
https://issues.apache.org/jira/browse/GERONIMO-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun updated GERONIMO-4449:
--
Affects Version/s: 2.1.4
Fix Version/s: 2.2
2.1.4
> Transaction.rollback method also calls beforeCompletion
> ---
>
> Key: GERONIMO-4449
> URL: https://issues.apache.org/jira/browse/GERONIMO-4449
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.1.4, 2.2
>Reporter: Lin Sun
>Assignee: Lin Sun
> Fix For: 2.1.4, 2.2
>
>
> Per JTA 1.1 spec, page 33:
> The beforeCompletion method is called by the transaction manager prior to the
> start of the two-phase
> transaction commit process.This call is executed with the transaction context
> of the transaction that is being
> committed. An unchecked exception thrown by a registered Synchronization
> object causes the transaction to
> be aborted. That is, upon encountering an unchecked exception thrown by a
> registered synchronization
> object, the transaction manager must mark the transaction for rollback.
> The spec seems to indicate that beforeCompletion is not called during
> rollback, but afterCompletion is called during(or after) both rollback and
> commit.
> So I expect the following to pass:
> {code}
> public void testNormalSynchIsNotCalledOnRollback() throws Exception {
> normalSync = new CountingSync();
> tm.begin();
> tm.getTransaction().registerSynchronization(normalSync);
> tm.rollback();
> assertFalse(normalSync.beforeCompletionCalled());
> assertTrue(normalSync.afterCompletionCalled());
> }
> {code}
> In geronimo, we call beforeCompletion inside of the rollback method in
> TransactionImpl.java, which seems incorrect to me.
> Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4466) Improve exception during transaction manager commit when there are multiple XAResources
[ https://issues.apache.org/jira/browse/GERONIMO-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4466. --- Resolution: Fixed see subversion commits tab > Improve exception during transaction manager commit when there are multiple > XAResources > --- > > Key: GERONIMO-4466 > URL: https://issues.apache.org/jira/browse/GERONIMO-4466 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > When tm.commit is invoked and there are multiple XAResources enlisted. if > there are one or more XAExceptions arisen from one or more of these > XAResources during commit, the code simply throws SystemException. I propose > the following updates to provide more detailed exceptions: > 1. If the XAException is XAException.XA_HEURRB from one XAResource and there > is no other exceptions from other XAResources, we throw > HeuristicMixedException (because there are heuristic conditions and some are > committed some are rolled back), and call the XAResource to forget. > 2. If all XAResources report XAException.XA_HEURRB, we throw > HeuristicRollbackException, and call the these XAResources to forget > 3. If the XAException is XAException.XA_HEURRB from one or more XAResources > however one or more XAResource are able to commit something (either no > exception during commit, or throw XAException.XA_HEURMIX > /XAException.XA_HEURCOM to indicate something gets committed), we throw > HeuristicMixedException, and call the XAResources to forget. > 2. If the XAException is XAException.XA_HEURMIX from one XAResource, and no > matter what other heuristic exceptions reported by other XAResources, we > throw HeuristicMixedException, and call the XAResource to forget > 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the > transaction originator, but we want to call XAResource to forget. > Comments welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4466) Improve exception during transaction manager commit when there are multiple XAResources
[ https://issues.apache.org/jira/browse/GERONIMO-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4466: -- Affects Version/s: 2.1.4 Fix Version/s: 2.1.4 > Improve exception during transaction manager commit when there are multiple > XAResources > --- > > Key: GERONIMO-4466 > URL: https://issues.apache.org/jira/browse/GERONIMO-4466 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > When tm.commit is invoked and there are multiple XAResources enlisted. if > there are one or more XAExceptions arisen from one or more of these > XAResources during commit, the code simply throws SystemException. I propose > the following updates to provide more detailed exceptions: > 1. If the XAException is XAException.XA_HEURRB from one XAResource and there > is no other exceptions from other XAResources, we throw > HeuristicMixedException (because there are heuristic conditions and some are > committed some are rolled back), and call the XAResource to forget. > 2. If all XAResources report XAException.XA_HEURRB, we throw > HeuristicRollbackException, and call the these XAResources to forget > 3. If the XAException is XAException.XA_HEURRB from one or more XAResources > however one or more XAResource are able to commit something (either no > exception during commit, or throw XAException.XA_HEURMIX > /XAException.XA_HEURCOM to indicate something gets committed), we throw > HeuristicMixedException, and call the XAResources to forget. > 2. If the XAException is XAException.XA_HEURMIX from one XAResource, and no > matter what other heuristic exceptions reported by other XAResources, we > throw HeuristicMixedException, and call the XAResource to forget > 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the > transaction originator, but we want to call XAResource to forget. > Comments welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4461) Improve exception during transaction manager one phase commit
[ https://issues.apache.org/jira/browse/GERONIMO-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4461. --- Resolution: Fixed Fix Version/s: 2.1.4 see subversion commits tab > Improve exception during transaction manager one phase commit > - > > Key: GERONIMO-4461 > URL: https://issues.apache.org/jira/browse/GERONIMO-4461 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Currently, during transaction manager one phase commit, if there is > XAException arise from XAResource.commit, the code just throws > RollbackException. > We should provide a more detailed Exceptions, that is: > 1. If the XAException is XAException.XA_HEURRB, we throw > HeuristicRollbackException, and call XAResource to forget > 2. If the XAException is XAException.XA_HEURMIX, we throw > HeuristicMixedException, and call XAResource to forget > 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the > transaction originator, but we want to call XAResource to forget. > 4. Other XAException, throw RollbackException, same as the current code. > Thoughts? > Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4461) Improve exception during transaction manager one phase commit
[ https://issues.apache.org/jira/browse/GERONIMO-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4461: -- Affects Version/s: 2.1.4 > Improve exception during transaction manager one phase commit > - > > Key: GERONIMO-4461 > URL: https://issues.apache.org/jira/browse/GERONIMO-4461 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > Currently, during transaction manager one phase commit, if there is > XAException arise from XAResource.commit, the code just throws > RollbackException. > We should provide a more detailed Exceptions, that is: > 1. If the XAException is XAException.XA_HEURRB, we throw > HeuristicRollbackException, and call XAResource to forget > 2. If the XAException is XAException.XA_HEURMIX, we throw > HeuristicMixedException, and call XAResource to forget > 3. If the XAException is XAException.XA_HEURCOM, we don't need to inform the > transaction originator, but we want to call XAResource to forget. > 4. Other XAException, throw RollbackException, same as the current code. > Thoughts? > Lin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4438) TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread
[ https://issues.apache.org/jira/browse/GERONIMO-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4438: -- Affects Version/s: 2.2 2.1.4 Fix Version/s: 2.1.4 > TransactionSynchronizationRegistry.getTransactionKey should return null when > transaction is not associated with the current thread > -- > > Key: GERONIMO-4438 > URL: https://issues.apache.org/jira/browse/GERONIMO-4438 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > Fix For: 2.1.4, 2.2 > > > per JTA 1.1 spec, the TransactionSynchronizationRegistry.getTransactionKey > method should return null, if a transaction is not associated with the > current thread. The Geronimo transaction impl (v2.1.1) throws an > IllegalStateException which is incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4448) TransactionManager resume method should only resume valid transaction
[
https://issues.apache.org/jira/browse/GERONIMO-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lin Sun updated GERONIMO-4448:
--
Affects Version/s: 2.1.4
Fix Version/s: 2.1.4
> TransactionManager resume method should only resume valid transaction
> -
>
> Key: GERONIMO-4448
> URL: https://issues.apache.org/jira/browse/GERONIMO-4448
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: transaction manager
>Affects Versions: 2.1.4, 2.2
>Reporter: Lin Sun
>Assignee: Lin Sun
> Fix For: 2.1.4, 2.2
>
>
> Currently, the resume manager resumes pretty much any transaction as long as
> the transaction is not null and is an instance of TransactionImpl.
> I think this is incorrect. Per the jTA 1.1 spec, page 13:
> Suspending and Resuming a Transaction
> A call to theTransactionManager.suspend method temporarily suspends the
> transaction that is currently associated with the calling thread. If the
> thread is not
> associated with any transaction, anull object reference is returned;
> otherwise, a valid
> Transaction object is returned. TheTransactionobject can later be passed to
> the
> resume method to reinstate the transaction context association with the
> calling thread.
> TheTransactionManager.resumemethod re-associates the specified transaction
> context with the calling thread. If the transaction specified is a valid
> transaction, the
> transaction context is associated with the calling thread; otherwise, the
> thread is
> associated with no transaction.
> Transaction tobj = TransactionManager.suspend();
> ..
> TransactionManager.resume(tobj);
> A simple test below would reveal the prob:
> {code}
> public void testResume1() throws Exception {
> Transaction tx;
> assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
> tm.begin();
> assertEquals(Status.STATUS_ACTIVE, tm.getStatus());
> tx = tm.getTransaction();
> assertNotNull(tx);
> assertEquals(Status.STATUS_ACTIVE, tx.getStatus());
>
> tm.commit();
> assertEquals(Status.STATUS_NO_TRANSACTION, tm.getStatus());
> assertNull(tm.getTransaction());
>
> try {
> tm.resume(tx);
> fail();
> } catch (InvalidTransactionException e) {
> // expected
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [discuss] release txmanager 2.1.2
Good point - I agree the vote only passes if it doesn't cause any tck prob. Lin On Fri, Jan 16, 2009 at 9:50 AM, Donald Woods wrote: > Would like to see a full run of the TCK to make sure there are no > regressions before we release it > > > -Donald > > > Lin Sun wrote: >> >> Hi, >> >> I 'd like to release txmanager 2.1.2 as I made some changes to it >> recently. I am going to work on putting a vote out if there is no >> objection by end of tomorrow. >> >> If you are interested in the details of the changes, I think most of >> them are recorded as JIRAs: >> >> GERONIMO-4438 >> GERONIMO-4448 >> GERONIMO-4461 >> GERONIMO-4466 >> GERONIMO-4471 >> GERONIMO-4449 >> GERONIMO-4478 >> GERONIMO-4482 >> >> Thanks >> >> Lin >> >
[jira] Resolved: (GERONIMO-4474) Pull out the text in the JSP files to resource bundle files
[ https://issues.apache.org/jira/browse/GERONIMO-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-4474. Resolution: Fixed Applied patch jsp-localization-jetty-connector.patch to trunk (2.2-SNAPSHOT) as Rev735163. > Pull out the text in the JSP files to resource bundle files > --- > > Key: GERONIMO-4474 > URL: https://issues.apache.org/jira/browse/GERONIMO-4474 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Ivan >Assignee: Gang Yin >Priority: Minor > Fix For: 2.2 > > Attachments: jsp-localization-activemq-ra.patch, > jsp-localization-activemq.patch, jsp-localization-console.patch, > jsp-localization-console_v2.patch, jsp-localization-debugview.patch, > jsp-localization-debugview_v2.patch, jsp-localization-fix.patch, > jsp-localization-jetty-connector.patch, jsp-localization-monitoring.patch, > jsp-localization-monitoring_v2.patch, jsp-localization-openejb.patch, > jsp-localization-plancreator.patch, jsp-localization-plancreator_v2.patch, > jsp-localization-plugin.patch, jsp-localization-plugin_v2.patch, > jsp-localization-securityrealm.patch, jsp-localization-sysdb.patch, > jsp-localization-tomcat6-connector.patch > > > Currently in the admin console, some text are hard coded in the JSP files. > We need to pull them out to the resource bundle files, so that we could > deliver multi-language versions in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-4369: --- Assignee: Ivan (was: Joe Bohn) > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Ivan > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4369-11.13.patch, Geronimo-4369-11.17.patch, > Geronimo-4369-11.19.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
[ https://issues.apache.org/jira/browse/GERONIMO-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4519: -- Affects Version/s: 2.2 Fix Version/s: 2.2 > When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send > rollback request again to the XAResource > -- > > Key: GERONIMO-4519 > URL: https://issues.apache.org/jira/browse/GERONIMO-4519 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.1.4, 2.2 >Reporter: Lin Sun >Assignee: Lin Sun > Fix For: 2.1.4, 2.2 > > > as titled, when XAException is XA_RBROLLBACK from XAResource.end, which > indicates that XAResource has already rolled back the transaction, there is > no need > to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4519) When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource
When XAException.XA_RBROLLBACK arisen from XAResource.end, TM should not send rollback request again to the XAResource -- Key: GERONIMO-4519 URL: https://issues.apache.org/jira/browse/GERONIMO-4519 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.1.4 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1.4 as titled, when XAException is XA_RBROLLBACK from XAResource.end, which indicates that XAResource has already rolled back the transaction, there is no need to send rollback request to the XAResource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664600#action_12664600
]
David Jencks commented on GERONIMO-4468:
I would trust the code more than the documentation :-)
The element doesn't change the contents of any runtime classloaders,
so if a class is only visible by being in a jar in a jar-file element then it
won't be available at run time. I thought that we copied the run time
classloader to obtain the temporary classloader. Any class in a parent
classloader will presumably have been already loaded so it would have needed to
be pre-enhanced since the runtime enhancement cant know to deal with it. So
only stuff in the current classloader can possibly be subject to runtime
enhancement. So, I'm stll pretty sure that passing the list of classes _or_
passing the list of jars but not both is the correct behavior.
> elements are interpreted relatively to EAR root
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch,
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The elements in a persistence.xml are wrongly interpreted as
> relative to the EAR's root.
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> [...] A persistence unit is defined by a persistence.xml file. The jar file
> or directory whose META-INF directory contains the persistence.xml file is
> termed the root of the persistence unit. [...]
> {quote}
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> One or more JAR files may be specified using the jar-file elements [...] Such
> JAR files are specified relative to the root of the persistence unit [...].
> {quote}
> The attached EAR is correctly verified by the Glassfish verifier. Deploying
> it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
> while on the console OpenJPA throws exceptions because it tries to resolve
> the jar-file paths relative to the EAR's root:
> {quote}
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
> (No such file or directory)
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
> (No such file or directory)
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Quetions per plugin based farming.
On Jan 16, 2009, at 1:40 AM, Shawn Jiang wrote: Hello, I'm trying to use the guide in http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html to setup a plugin based farming. I have a couple of questions: 1, In Farm controller setup section. There's a instruction to get the controller assemblies. svn co https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/assemblies I found that there's nothing in the svn path above. 2, I found the source code of the controller in https://svn.apache.org/repos/asf/geronimo/sandbox/failover/ and I can build it locally to get the controller assemblies. My question is that when will this part of code be merged into the trunk code ? Will they become a part of geronimo 2.2 when geronimo 2.2 is released ? For me, if they are not a part of 2.2 release, it's not a good place to put them into a guide under http://cwiki.apache.org/GMOxDOC22/, any comments ? The code is really an example of one way to set up a controller. We might put it in samples but not in trunk. I set up an alternate controller configuration for my apachecon talk dunno if both should be samples? david jencks -- Shawn
[jira] Commented: (GERONIMO-4474) Pull out the text in the JSP files to resource bundle files
[
https://issues.apache.org/jira/browse/GERONIMO-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664590#action_12664590
]
Donald Woods commented on GERONIMO-4474:
{noformat}
Author: dwoods
Date: Wed Jan 14 10:19:35 2009
New Revision: 734466
URL: http://svn.apache.org/viewvc?rev=734466&view=rev
Log:
GERONIMO-4474 Pull out the text in the JSP files to resource bundle files.
Applied jsp-localization-tomcat6-connector.patch,
jsp-localization-securityrealm.patch and jsp-localization-activemq-ra.patch
from Gang Yin.
{noformat}
> Pull out the text in the JSP files to resource bundle files
> ---
>
> Key: GERONIMO-4474
> URL: https://issues.apache.org/jira/browse/GERONIMO-4474
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
>Affects Versions: 2.2
>Reporter: Ivan
>Assignee: Gang Yin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: jsp-localization-activemq-ra.patch,
> jsp-localization-activemq.patch, jsp-localization-console.patch,
> jsp-localization-console_v2.patch, jsp-localization-debugview.patch,
> jsp-localization-debugview_v2.patch, jsp-localization-fix.patch,
> jsp-localization-jetty-connector.patch, jsp-localization-monitoring.patch,
> jsp-localization-monitoring_v2.patch, jsp-localization-openejb.patch,
> jsp-localization-plancreator.patch, jsp-localization-plancreator_v2.patch,
> jsp-localization-plugin.patch, jsp-localization-plugin_v2.patch,
> jsp-localization-securityrealm.patch, jsp-localization-sysdb.patch,
> jsp-localization-tomcat6-connector.patch
>
>
> Currently in the admin console, some text are hard coded in the JSP files.
> We need to pull them out to the resource bundle files, so that we could
> deliver multi-language versions in the future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ASF Board Report
All, I've updated http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2009-01+-+January with information for our quarterly board report. Please review and update with any changes or additions. Final input needs to be made by Monday. So, I'll finalize over the weekend. Thanks! --kevan
Re: Using Nexus on zone?
On Jan 16, 2009, at 8:53 AM, Jason Dillon wrote: The process of adding artifacts is adding new bits to: https://svn.apache.org/repos/asf/geronimo/repository/trunk/ The nexus simply proxies/caches from this URL. K. So, is placing a binary in repository/trunk like doing a "release" of the binary? I need to be reassured that we have appropriate oversight by the PMC of these artifacts. We currently have that because the binaries are part of each server release. I'm not comfortable that we currently have that with this scheme. Not saying that it can't be done... As mentioned previously, the alternative is to release these binaries in a more normal fashion with a geronimo groupid (e.g. something like org.apache.geronimo.repository or org.apache.geronimo.patched- dependencies, etc.). Using this technique, we could follow a more normal release process into mainstream maven repositories (e.g. SNAPSHOT and release repositories), hold normal votes, etc. Anybody see a problem with this process? Beyond doing the groundwork? --kevan
Re: [discuss] release txmanager 2.1.2
On Jan 16, 2009, at 9:50 AM, Donald Woods wrote: Would like to see a full run of the TCK to make sure there are no regressions before we release it I think that's a good point. I ran targeted tests, but not a full run. G 2.1.4 would seem to be the best base for this, at the moment... --kevan
[jira] Created: (GERONIMODEVTOOLS-558) Testsuite not able to find DefaultSelenium class
Testsuite not able to find DefaultSelenium class Key: GERONIMODEVTOOLS-558 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-558 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Reporter: B.J. Reed Assignee: Tim McConnell Priority: Blocker Fix For: 2.2.0, 2.1.4 Running the testsuite from Eclipse, I get a java.lang.NoClassDefFoundError: com/thoughtworks/selenium/DefaultSelenium at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:441) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.apache.geronimo.testsuite.v22.ui.EclipseUITest.installServer(EclipseUITest.java:110) at org.apache.geronimo.testsuite.v22.ui.EclipseUITest.testEclipseUI(EclipseUITest.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at abbot.swt.junit.extensions.SWTTestCase.runBareWrapper(SWTTestCase.java:279) at abbot.swt.junit.extensions.SWTTestCase.access$2(SWTTestCase.java:276) at abbot.swt.junit.extensions.SWTTestCase$4.execute(SWTTestCase.java:253) at abbot.swt.junit.extensions.UserThread.run(UserThread.java:75) Testsuite runs fine when run from maven. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss] release txmanager 2.1.2
Would like to see a full run of the TCK to make sure there are no regressions before we release it -Donald Lin Sun wrote: Hi, I 'd like to release txmanager 2.1.2 as I made some changes to it recently. I am going to work on putting a vote out if there is no objection by end of tomorrow. If you are interested in the details of the changes, I think most of them are recorded as JIRAs: GERONIMO-4438 GERONIMO-4448 GERONIMO-4461 GERONIMO-4466 GERONIMO-4471 GERONIMO-4449 GERONIMO-4478 GERONIMO-4482 Thanks Lin
[jira] Reopened: (GERONIMO-4369) The new attribute values are overwrote while restarting the DB pool connector
[ https://issues.apache.org/jira/browse/GERONIMO-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened GERONIMO-4369: Manu T George commented on GERONIMO-4509: - I think this issue occurs because of the patch made in https://issues.apache.org/jira/browse/GERONIMO-4369. In ConfigManagerPortlet restartConfiguration was replaced by reloadConfiguration which appears to be causing this issue. I think that JIRA needs to be reopened > The new attribute values are overwrote while restarting the DB pool connector > - > > Key: GERONIMO-4369 > URL: https://issues.apache.org/jira/browse/GERONIMO-4369 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Geronimo 2.2 snapshot > JDK 1.5 > Windows XP >Reporter: Ivan >Assignee: Joe Bohn > Fix For: 2.1.4, 2.2 > > Attachments: Geronimo-4369-11.13.patch, Geronimo-4369-11.17.patch, > Geronimo-4369-11.19.patch > > > After editing the values in the db pool, then restart it in the console, the > new values lost. > When saving the new attribute values, such as user name, the gbeandata in > the configurationManager is not updated, so while restarting the connector, > the gbinstance copies those old values from it. So the new persistent values > do not take effect, > Do I miss anything, thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using Nexus on zone?
The process of adding artifacts is adding new bits to: https://svn.apache.org/repos/asf/geronimo/repository/trunk/ The nexus simply proxies/caches from this URL. --jason On Jan 16, 2009, at 7:56 PM, Kevan Miller wrote: On Jan 16, 2009, at 6:35 AM, Jason Dillon wrote: Any comments on using the nexus install on the zone for the custom artifacts we need for our builds? I'd like to make this live. Yes. I want to understand the process for adding artifacts to the repository. IMO, we must have community oversight of these resources and they must follow a "release" process. We currently have this, since the repository is part of each of our releases. --kevan
Re: Using Nexus on zone?
On Jan 16, 2009, at 6:35 AM, Jason Dillon wrote: Any comments on using the nexus install on the zone for the custom artifacts we need for our builds? I'd like to make this live. Yes. I want to understand the process for adding artifacts to the repository. IMO, we must have community oversight of these resources and they must follow a "release" process. We currently have this, since the repository is part of each of our releases. --kevan
Re: New selenium-m-p snap out...
On Jan 16, 2009, at 2:04 AM, Jason Dillon wrote: ... looks like it works fine with FF3. I'm gonna see how well it works in server/trunk and then will publish a release if it works. Excellent. Thanks Jason. --kevan
Using Nexus on zone?
Any comments on using the nexus install on the zone for the custom artifacts we need for our builds? I'd like to make this live. --jason
Quetions per plugin based farming.
Hello, I'm trying to use the guide in http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html to setup a plugin based farming. I have a couple of questions: 1, In Farm controller setup section. There's a instruction to get the controller assemblies. svn co https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/assemblies I found that there's nothing in the svn path above. 2, I found the source code of the controller in https://svn.apache.org/repos/asf/geronimo/sandbox/failover/ and I can build it locally to get the controller assemblies. My question is that when will this part of code be merged into the trunk code ? Will they become a part of geronimo 2.2 when geronimo 2.2 is released ? For me, if they are not a part of 2.2 release, it's not a good place to put them into a guide under http://cwiki.apache.org/GMOxDOC22/, any comments ? -- Shawn
[jira] Commented: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664451#action_12664451 ] Shawn Jiang commented on GERONIMO-4518: --- I guess this is a regression of https://issues.apache.org/jira/browse/GERONIMO-4442 The org.apache.geronimo.deployment.cli.StopServer will always try to connect the real IP instead of the "127.0.0.1" passed in. I'm trying to use a customized GeronimoRMIClientSocketFactory to limit the the connection to the host passed in. > Can't shutdown the server when host was set to 127.0.0.1 in > config-substitutions.properties > --- > > Key: GERONIMO-4518 > URL: https://issues.apache.org/jira/browse/GERONIMO-4518 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.2 > Environment: Windows XP + Sun JDK 1.5 >Reporter: Shawn Jiang > > 1, change the host in config-substitutions.properties to 127.0.0.1 > 2, start the server. > 3, shutdown the server. > *expected result*: the server could be shutdown. > *actual result*: the sever can't be shutdown with exception: > java.net.ConnectException: Connection refused: connect > -- > C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 > Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT > Using GERONIMO_TMPDIR: var\temp > Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre > log4j:WARN No appenders could be found for logger > (org.apache.geronimo.kernel.basic.BasicKernel). > log4j:WARN Please initialize the log4j system properly. > Username: system > Password: *** > Locating server on 127.0.0.1:1099... > Could not communicate with the server. The server may not be running or the > port number may be inco > rrect (Connection refused to host: 6.153.277.58; nested exception is: > java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664448#action_12664448
]
Ivan commented on GERONIMO-4468:
Another reason is that we may need it to build the tempclassloader, by default,
only those jars in the lib directory will be added to the classloader of that
ear. Or we will encounter the issue mentioned by Janko, not all the entity
classes are found.
Thanks for giving a comment ! Wish I do not make a mistake :-)
> elements are interpreted relatively to EAR root
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch,
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The elements in a persistence.xml are wrongly interpreted as
> relative to the EAR's root.
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> [...] A persistence unit is defined by a persistence.xml file. The jar file
> or directory whose META-INF directory contains the persistence.xml file is
> termed the root of the persistence unit. [...]
> {quote}
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> One or more JAR files may be specified using the jar-file elements [...] Such
> JAR files are specified relative to the root of the persistence unit [...].
> {quote}
> The attached EAR is correctly verified by the Glassfish verifier. Deploying
> it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
> while on the console OpenJPA throws exceptions because it tries to resolve
> the jar-file paths relative to the EAR's root:
> {quote}
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
> (No such file or directory)
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
> (No such file or directory)
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4468) elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1266#action_1266
]
Ivan commented on GERONIMO-4468:
I just refer to the doc in
http://cwiki.apache.org/confluence/display/GMOxDOC22/persistence.xml, it writes
:
When set to true, only listed classes and jars will be scanned for persistent
classes. Otherwise the enclosing jar or directory will also be scanned. This is
not applicable to Java SE persistence units. The following XML fragment
illustrate the use of exclude-unlisted-classes element.
Is that doc wrong ? I will check the specification about how it says about the
exclude-unlisted-classes.
> elements are interpreted relatively to EAR root
> --
>
> Key: GERONIMO-4468
> URL: https://issues.apache.org/jira/browse/GERONIMO-4468
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 2.1.3
>Reporter: Janko Heilgeist
>Assignee: Ivan
> Attachments: Geronimo-4468-01.patch, Geronimo-4468.patch,
> geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
>
>
> The elements in a persistence.xml are wrongly interpreted as
> relative to the EAR's root.
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> [...] A persistence unit is defined by a persistence.xml file. The jar file
> or directory whose META-INF directory contains the persistence.xml file is
> termed the root of the persistence unit. [...]
> {quote}
> EJB 3.0 persistence spec, section 6.2:
> {quote}
> One or more JAR files may be specified using the jar-file elements [...] Such
> JAR files are specified relative to the root of the persistence unit [...].
> {quote}
> The attached EAR is correctly verified by the Glassfish verifier. Deploying
> it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
> while on the console OpenJPA throws exceptions because it tries to resolve
> the jar-file paths relative to the EAR's root:
> {quote}
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
> (No such file or directory)
>
> org.apache.openjpa.persistence.PersistenceException:
> $HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
> (No such file or directory)
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4518) Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties
Can't shutdown the server when host was set to 127.0.0.1 in config-substitutions.properties --- Key: GERONIMO-4518 URL: https://issues.apache.org/jira/browse/GERONIMO-4518 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.2 Environment: Windows XP + Sun JDK 1.5 Reporter: Shawn Jiang 1, change the host in config-substitutions.properties to 127.0.0.1 2, start the server. 3, shutdown the server. *expected result*: the server could be shutdown. *actual result*: the sever can't be shutdown with exception: java.net.ConnectException: Connection refused: connect -- C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin>shutdown --host 127.0.0.1 Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:D:\dev\JDKs\sun_jdk1.5.0_15\jre log4j:WARN No appenders could be found for logger (org.apache.geronimo.kernel.basic.BasicKernel). log4j:WARN Please initialize the log4j system properly. Username: system Password: *** Locating server on 127.0.0.1:1099... Could not communicate with the server. The server may not be running or the port number may be inco rrect (Connection refused to host: 6.153.277.58; nested exception is: java.net.ConnectException: Connection refused: connect) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
